Cool Solutions

ConsoleOne with data store on Linux

Dean Lythgoe

By:

April 9, 2009 1:43 pm

Reads: 9978

Comments:21

Score:0

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

VN:F [1.9.22_1171]
Rating: 0.0/5 (0 votes cast)

Categories: Uncategorized

Disclaimer: This content is not supported by Novell. It was contributed by a community member and is published "as is." It seems to have worked for at least one person, and might work for you. But please be sure to test it thoroughly before using it in a production environment.

21 Comments

  1. By:adamwgray

    Dean:

    You could ssh to the remote server and run it there. That will work on SLED, Linux, or Mac as the client and it connects to SLES or OES.

    simply

    ssh -Y user@server
    cd /usr/ConsoleOne/bin
    ./ConsoleOne

    Presto. You are running your console one without worry of corruption. Also, you can use vnc loaded on the server. Not great with the lack of encryption and all. I will only use the vnc route across a vpn or slow connection. For fast connection ssh forwarding is great.

    -AG

    VN:F [1.9.22_1171]
    Rating: 0.0/5 (0 votes cast)
    • By:dlythgoe

      Thanks Adam – this is a great suggestion! However, not exactly the problem. The problem is not just how to do it successfully, but is to help prevent inexperienced Linux users from doing something they did not intend.

      Having many options certainly helps and we appreciate and welcome any/all comments. The more information on what can and should be done, will help avoid some of the pit falls.

      Dean

      VN:F [1.9.22_1171]
      Rating: 0.0/5 (0 votes cast)
  2. By:iblackwood

    Hi Dean,

    Is Cross_protocol_locks required if Samba is not used ? Say only NCP and local (Linux C1 on GW Server) ?

    On the subject of running C1 on the GW Linux server directly, this works fine until your GroupWise system goes beyond one box. Then you end up mounting remote file systems to manage it – which gives the same file locking challenges…

    You might want to blog on the Linux C1′s GW mount prefix to all – I see bulk confusion where people change paths in Linux C1 (linux path) and then have issues in Windows C1 (UNC path) accessing the same domains and POs. :-)

    Cheers
    Ian

    VN:F [1.9.22_1171]
    Rating: 0.0/5 (0 votes cast)
    • By:dlythgoe

      Response provided by Patti Brooks….GroupWise Engineering QA

      CROSS_PROTOCOL_LOCKS only affects OES NCP (not SAMBA).

      Running a Linux ConsoleOne on the local Linux box (or via ssh) is fine, but you should not run a Linux ConsoleOne against a remote Linux store.

      Corrections to the TID:
      - The uid.run file is created, even if the agents are being run as root.
      - Should remove SAMBA from: “Enabling this lock will make OES recognize file lock issues through both SAMBA and NCP client connections.”

      Dean

      VN:F [1.9.22_1171]
      Rating: 0.0/5 (0 votes cast)
  3. By:dlythgoe

    Engineering is now suggesting the following solution:

    A proposal for 8.0.1

    When the Linux agents are launched, they will auto-detect if the CROSS_PROTOCOL_LOCKS is set. If it is not set, then the setting will be made on the server and added to the ncpserv.conf file and then eDir is restarted so that the setting takes effect.

    Then a ncpChecked file is written to the domain or post office directory so that the check isn’t made again. In ConsoleOne, if a uid.run file is present, but the ncpChecked file is not, then a warning will display.

    Thoughts??

    Dean

    VN:F [1.9.22_1171]
    Rating: 0.0/5 (0 votes cast)
  4. By:bbecken

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

    What generation/version/codename of GroupWise are you referring too?

    Right now we are able to limit our Support Personnal’s access to certain Domains/Post Offices. I hope the new version incoprorates options to limit/lock Support people out of “Domain Settings” so that cannot override Domain settings. I’d also like to see a GroupWise “Changelog” so that when a Support person changes a settings, I can see Who made the change.

    VN:F [1.9.22_1171]
    Rating: 0.0/5 (0 votes cast)
    • By:dlythgoe

      There is some outstanding prioritization work that is still being done. We have targeted both the Windermere and/or Monterrey release for this functionality. The functionality is basically allowing access to domain databases over TCP/IP and not a mapped drive. It does not refer to being able to control ‘actual’ access to a domain or from performing certain actions. In fact, some of the design we have been talking about has to do with ‘Roles’ and allowing certain administrative tasks to be completed by people other than administrators.

      Hope that explains the functionality intent we are designing.

      Dean

      VN:F [1.9.22_1171]
      Rating: 0.0/5 (0 votes cast)
  5. By:bbecken

    Since HP2 is suppose to be released in May/June is there a changelog of what is being fixed and not being fixed?

    VN:F [1.9.22_1171]
    Rating: 0.0/5 (0 votes cast)
    • By:dlythgoe

      When we release the Hot Patch, we will also post a change log/readme where all of the fixes and changes made to the hot patch will be listed. That has become our standard practice for Hot Patches. Not so much for Support Packs or major releases just because of the volume of changes involved. However, we will still provide documentation on the newest features, largest changes and significant changes in functionality.

      Dean

      VN:F [1.9.22_1171]
      Rating: 0.0/5 (0 votes cast)
  6. By:DGerisch

    It has the advantage that the problem is solved for every admin in the system as soon as the newest code is used.

    VN:F [1.9.22_1171]
    Rating: 0.0/5 (0 votes cast)
  7. By:paulgear

    I can’t believe it has taken Novell this long and there’s still no web-based administration interface for GroupWise. One of the proverbial jokes amongst Novell sysadmins is that every new product requires a new interface, and you still have to keep the old one around for all the things that weren’t migrated to it. Here’s just a short list of the crazy things a Novell site will probably need to administer their site:

    NetWare: nwconfig, NRM
    SLES: yast2
    eDirectory: ConsoleOne AND iManager (you can’t afford to be missing either one)
    NSS: nssmu and MAYBE iManager if it works
    ndps: ConsoleOne AND the old nwadmin
    iPrint: iManager
    NCS: NRM AND ConsoleOne
    GroupWise: ConsoleOne
    ZCM: its own web interface
    IDM: IDM admin console based on Eclipse

    When are we going to see a concerted effort at administrative consolidation? Pick an interface (a browser-based one if you know what’s good for you) make it as reliable and functional as possible, and make ALL of your products use it. Those of us out here on the front lines trying to support Novell products are sick of being the laughingstock.

    VN:F [1.9.22_1171]
    Rating: 0.0/5 (0 votes cast)
    • By:dlythgoe

      Paul,

      You are right. This is certainly an area that needs more focus and direction. Your comments and input have been passed onto the Product Management leadership team. Many may argue that the ‘variety’ appeals to them because each tool/product has unique requirements. The counter argument is that consistency goes a long way towards understanding and direction. I happen to be in the latter camp.

      The debate seems to be ‘which’ one? In a previous blog post we suggested going to iManager and this option to standardize on this particular technology was met with a very mixed support. That said – I believe it is essential we choose one, stick with it, improve it and make it work.

      Dean

      VN:F [1.9.22_1171]
      Rating: 0.0/5 (0 votes cast)
  8. By:dknudson

    Thanks for all the info and we really appreciate you listening to us, taking suggestion in style, and letting us know where things are at ! I am not sure this is the place to ask about this specific issue, but it involves ConsoleOne running on Windows desktops… We frequently have an issue when a new user is created in eDirectory and a Groupwise account is created during the setup of the account. Many times the Groupwise database for that user must not be getting created on the Groupwise server, but the edir account does and the Groupwise info is populated, but of course the user can’t login to groupwise… Running GWCheck on the newly created account shows the error that the user database is missing and if fails to fix. We have to then delete the Groupwise account and re-create it to fix the issue. This seems to happen frequently, but not consistantly. This can’t be a rights issue since it works okay sometimes, but it seems like there is some kind of disconnect during the creation of a new edir account and groupwise account from the workstation? Is there a know issue/fix, or is this something you haven’t heard of?
    Thanks!
    Dan

    VN:F [1.9.22_1171]
    Rating: 0.0/5 (0 votes cast)
    • By:dlythgoe

      Dan,

      I engaged our lead admin engineer on your post. He said: I have not heard of any problems like this. Do you have Dan’s email. I have several questions I would like to run by him.

      So – will you contact me directly at my email address and I will facilitate a discussion with the engineer directly. Send your contact info to dlythgoe@novell.com.

      Thanks,

      Dean

      VN:F [1.9.22_1171]
      Rating: 0.0/5 (0 votes cast)
    • By:tjacksonbcg

      Dan – Do you by chance have GWAVA Reload? I ran into the same exact issue. The issue occurred whenever Reload would backup the account (user.db?) before the user ever logged into the mailbox. If the user happened to login shortly after us creating the account everything was fine. We just make it practice to login to the account once after we create it. My initials thinking was that it was related to the C1 user creation process but that turned out to not be the case.

      Hope this helps!

      Tim J

      VN:F [1.9.22_1171]
      Rating: 0.0/5 (0 votes cast)
  9. By:dknudson

    Yes! Yes, I do have GWAVA Reload… That sounds strange?
    I think I will need to contact GWAVA support and verify this… Makes sense if that is what is happening since it seems so intermittent. We have Reload backing up every hour, so this could be the case very easily! Thanks so much for the info – I will investigate a bit further on this.

    Thank you,
    Dan

    VN:F [1.9.22_1171]
    Rating: 0.0/5 (0 votes cast)
    • By:tjacksonbcg

      Dan – Please let us know if you end up finding a fix if it is in fact Reload. My workaround works, but I’d rather not have to login every time I create an account.

      Thanks,
      Tim

      VN:F [1.9.22_1171]
      Rating: 0.0/5 (0 votes cast)
  10. By:dknudson

    Maybe Dean can help with this somehow?
    ——————————————————-
    GWAVA Support:
    After consulting with the product lead I’ve found out more about this particular problem. What happens is that the Reload process (using dbcopy) checks the ngwguard database and it thinks there is a user there, however there hasn’t been a database created yet. So smartpurge goes in and creates a bad database. We’ve actually contacted Novell about the issue and it’s not exactly high on their list of priorities to fix. So it is actually a problem with GroupWise and not Reload specifically. Probably the simplest way to get around this is to send some type of “Welcome” email to that user before Reload does it’s backup. That way there is a database created for that user and a corrupt one doesn’t get created. Or run gwcheck on that account after it’s become corrupted, I wouldn’t go this route myself.

    VN:F [1.9.22_1171]
    Rating: 0.0/5 (0 votes cast)
    • By:dlythgoe

      I’ll look into it…thanks for the heads up!

      Dean

      VN:F [1.9.22_1171]
      Rating: 0.0/5 (0 votes cast)
      • By:dlythgoe

        ok – I looked into it….

        We are pretty sure this is the same problem…it sounds like the same thing, but with slightly different details and it was reported to us by GWAVA. If it is this same thing…I have excellent news….:)

        1. It is fixed in GroupWise 2012
        2. It is bug #640650
        3. Actually, it has to do with a utility called ‘gwtmstmp’ and not smartpurge per se. Smart Purge does utilize this utility, so we think this is the same issue.

        Sounds like it is time to upgrade!! :)

        Dean

        VN:F [1.9.22_1171]
        Rating: 0.0/5 (0 votes cast)
  11. By:dknudson

    Thanks so much for checking into this one Dean !
    Sometimes its hard to track down issues between products, so this really helps.

    I have had the beta of Groupwise 2012 up and running for a few months, so I guess we will have to get the new release and get GW 8 upgraded soon :)

    Thanks so much! Have a good weekend,
    -Dan

    VN:F [1.9.22_1171]
    Rating: 0.0/5 (0 votes cast)

Comment

RSS