Blog Entry

There are several customers that have reported problems when trying to run ConsoleOne remotely against domain data that is stored on Linux.

The data/information in this blog can also be found as a TID. #3036467. I am posting on my blog and a few other places in order to get the word out. We want to share our ideas for a solution and see what other solutions are suggested.

Here is the problem:

How to avoid data corruption when running remote ConsoleOne against domain data store at Linux.

The resolution depends on the platform of the workstation that the ConsoleOne is running on and the type of connection that the workstation has with the Linux server.

If the Linux server is OES, you will need to turn on "CROSS PROTOCOL LOCKS" on the OES server. Enabling this lock will make OES recognize file lock issues through both SAMBA and NCP client connections. This lock can be enabled through ncpcon. In ncpcon, type "set CROSS_PROTOCOL_LOCKS=1" or add this line "CROSS_PROTOCOL_LOCKS 1" to the /etc/opt/novell/ncpserv.conf file. There is a limitation to this too. It only applies to Windows workstations. The Novell Client for Windows allows the ncp protocol to correctly enforce this. The Novell Client for Linux does not have this functionality yet.

If the Linux server is SLES, and the connection is SAMBA, meaning ConsoleOne is running on a Windows workstation, run the GroupWise 7.0.2 or newer code. This has been modified to enforce the advisory lock.

Note: Do not run Linux version of ConsoleOne on a remote Linux server or SLED until the Novell Client for Linux defect is fixed.

Note: Do not run Linux version of ConsoleOne on remote Linux workstation using NFS connection to the Linux server.

Our intention is for the next generation of GroupWise administration to use its own client/server technology to eliminate the problems above.

>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

We have also requested the additional documentation be made available and the readme updated.

>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

Now that we have explained the problem and the work around, we are working on a few ideas on how to either prevent the problem or at least alert the administrator to the potential of a problem. Here are a few of the current proposals:

One suggestion: We should look into the possibility of detecting that the connection is over a mount and display some UI at run time. The UI would alert the Administrator to a possible problem.

Another related suggestion: The snapins could look for the uid.run file in the domain directory and assume it is a Linux machine if it exists. If it does we could throw up a warning telling them to make sure they have configured the cross protocol locks correctly.

This type of solution has a few disadvantages:

1) It will become a nuisance because it will come up every time.

2) In spite of our desire for customers to do otherwise, many people run their agents as a root user. Therefore, the uid.run file may not be present.

3) From what I understand, this issue only affects OES flavors of Linux using NSS volumes. The snapins would not only have to search for the uid.run file, but would also have to determine if the distribution was OES and the domain was on an NSS volume.

Another Proposal

An additional question has been submitted: Can the C1 GW snapins create files on the fly? My suggestion would be to have the snapins search for a file, if it does not exist, prompt the user for OS and whether the volume is NSS. From the answers given, show error message if necessary and then write a file so that the message will not be shown again for that specific domain.

There may be an OS call that could be made to interrogate the volume info rather than prompting the user to tell us whether or not it's NSS.

>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

That is the discussion so far. Anyone have any other suggestions or preferences?

Dean