Search Results

Search found 3 results on 1 pages for 'mechcow'.

Page 1/1 | 1 

• ODBC error state S1092: postgresql through ODBC

  - by mechcow

  While performing an upgrade, our in-house software started to report the following strange error. It is a C++ application talking to a remote postgresql database, defined through ODBC: ODBC error state S1092, native error 0. [unixODBC][Driver Manager]Invalid attribute/option identifier Both the client and the server are Centos 5.4 Xen guests with the following RPMs installed: postgresql-libs-8.1.18-2.el5_4.1 postgresql-odbc-08.01.0200-3.1 postgresql-8.1.18-2.el5_4.1 postgresql-server-8.1.18-2.el5_4.1 Its possible the schema changed as part of the upgrade, could this explain the error message? What does this error message actually indicate, and do you know any likely causes of it?

  Read the article

• Using LDAP to store customer data

  - by mechcow

  We wish to store some data in 389 Directory Server LDAP that doesn't fit that well into the standard set of schema's that come with the product. Nothing too amazing, things like: when the customer joined are they currently active customer certificate[1] which environment they are using My question is this: should we register with OID and start writing up our own custom schema OR is there a standard schema definition not provided by Directory Server that we can download and use that would fit our needs? Should we munge/hack existing attributes and store the data among there (I'm strongly opposed to this, but would be interested in arguments about why its better than extending)? [1] I know there is a field for this userCertificate but we don't want to use it to authenticate the user for the purposes of binding Using CentOS 5.5 with 389 Directory Server 8.1

  Read the article

• Xen guests accessing LUNs

  - by mechcow

  We are using RHEL5.3 with a Clarion SAN attached by FC. Our situation is that we have a number of LUNs presented to Hosts and we want to dynamically present the LUNs to Xen Guests. We are not sure on what the best practice approach is to set this up. The Xen guests will form a cluster together and need the LUNs only for data partitions, i.e. when they are actively running services. So one approach would be to always present all disks to all Xen guests, and then rely up on the cluster software, and mount itself, to not mount the disk twice in two locations. This sounds kinda risky and also is not very secure (one cracked guest can see/destroy all the data). Another approach would be to dynamically add and remove the disks from the Xen guests at the dom0 level (using xm block-attach). This could work but sounds slightly complicated, I'm wondering whether Red Hat Cluster Suite supports this in some way or whether there are scripts to do this. Yet another approach would be to have the LUNs endpointed at the Xen guests themselves - I'm not sure whether this is technically possible since the multipathing has to be done at the Host level.

  Read the article

1