Administering Your Linux GroupWise Domain from Linux and Windows

0 Likes

At GWAVACon it was made very clear to me that the documentation for GroupWise administration "mount points" either is not clear enough, or just needs more visibility! I promised at least 5 different groups of session attendees that I would come right back and post a blog entry about this to try to clear up the confusion - so here I am!



First let’s discuss the actual issue. A site either migrates a domain to Linux or creates a new domain on Linux, and wants to administer it from ConsoleOne both on the Linux server itself, and from Windows PCs attached to the server. Many folks I spoke to could get it to work one way or the other, but not for both. So let’s fix that right now!



Here’s the basic problem. Linux doesn’t really understand UNC paths. Linux sees ALL drives that it has access to in the context of its own file system. For example, if on your Linux server you want to do the equivalent of "mapping a drive" to a NetWare server, you create a directory on your Linux server, and "mount" that NetWare volume to that location. On Linux, this might very well look like:



/mnt/server/vol2/domain for NetWare


or



/mnt/server/d$/domain for Windows


This actually seems to be a relatively easy concept for most GroupWise administrators to grasp once they are exposed to the idea. It’s the "local" GroupWise domain that causes great consternation. Let’s look at a couple of issues with the local GroupWise domain. Our domain exists at /grpwise/domain.







Click to view.


Domain with Linux Path





If we leave the domain location as the Linux Path, ConsoleOne on the local Linux server will work perfectly, and all snapins for the GWIA, WebAccess Agent and the like will be available without problem. However, if we leave this Linux path there, a Windows PC can map to the domain, open ConsoleOne, etc., but all of the snapins for the GWIA and WebAccess will be missing, because /grpwise/domain/wpgate/gwia means nothing to the Windows box! In other words, ConsoleOne reads the information in the domain properties to build paths to all other GroupWise components.



So, what if we change the path in ConsoleOne to the UNC path of \\server\grpwise\domain?







Click to view.


Domain with UNC Path




If you now map your Windows drive to \\server\grpwise\domain you will be able to connect to the domain and edit your gateways with no problems. However, on the Linux server itself, the gateways will not have their proper snapin tabs, because the Linux server has no idea where \\server\grpwise\domain is.



Enter the "Linux mount directory" setting in the Linux ConsoleOne. In ConsoleOne on Linux, go to Tools|GroupWise System Operations|System Preferences|Linux Settings and enter a "mount point" for your domains. This can really be anywhere you like, but it’s fairly common for /mnt to be the "mount point location" for placing links to external systems.



If you have entered \\server\grpwise\domain as the UNC path for your domain, after you have a mount point of /mnt defined in ConsoleOne, looking at the properties of the domain will now show /mnt/server/grpwise/domain as shown in the next figure.







Click to view.


Domain with a new Linux mount point





Now, it’s important to note that what we see here in this figure ONLY happens on the Linux machine. The Windows PCs still see the location of the domain in UNC format.



If you look in your /mnt directory though, it’s unlikely that you see an /mnt/server/grpwise/domain directory! This is accomplished either by "mounting" a drive in Linux (i.e., to an external NetWare, Windows or Linux server), or simply creating a symbolic link (symlink) to the local path for your domain. Since our domain is at /grpwise/domain on our local server, we can do the following in the /mnt directory location:



ln -s / server


This assumes that my server name is "server". This command creates a symlink to show the files from "/" under the "server" directory. Now ConsoleOne can find my domain at /mnt/server/grpwise/domain, and the Windows boxes can map a drive to \\server\grpwise and also see the domain there with no problems.



NSS volumes on OES servers cause a bit of a twist here too. The UNC path of \\server\MAIL\grpwise\domain might actually be a path on your OES server of /media/nss/MAIL/grpwise/domain (with "MAIL" being the volume name for your server). In this case, your mount point in the /mnt directory would need to be /mnt/server/MAIL/grpwise/domain, so you would issue this command in the /mnt directory:



ln -s /media/nss/ server


This would mount the /media/nss/ directory into /mnt/server/ and show you all of the volumes for that server, including the MAIL volume. Don’t forget that NSS volumes are all shown in all caps in the Linux file system, so be sure to keep your case proper in both the UNC path and in the mount point.



Hope this helps to clear up a few things!



Danita

Tags:

Labels:

How To-Best Practice
Comment List
  •  
    SLES 10 sp4 OES 2 sp3 (old I know)
    I have a production box, called "GROUPWISE" in this case, its "ln -s /media/nss GROUPWISE". It works as expected. However I also have a test server named "five". So naturally one would think it should be "ln -s /media/nss five". No, this doesn't work, I have to make it "ln -s /media/nss FIVE".
    Maybe its me, but I don't believe this is mentioned here...
  •  
    On NCS, clustered volumes are usually each associated to their own virtual servers.

    Instead of using symlinks, I add an entry into my /etc/fstab file for each clustered volume in my cluster, thus:

    vol1 /mnt/vserver-vol1/vol1 nssvol noauto,rw,name=vol1,ns=unix 0 0
    vol2 /mnt/vserver-vol2/vol2 nssvol noauto,rw,name=vol2,ns=unix 0 0

    where vserver-vol1 is the name of my virtual server for volume 1,
    and vserver-vol2 is the name of my virtual server for volume 2.

    In this instance, I set my ConsoleOne mount point to /mnt and set my UNC path for my domain on vol1, using console1 on windows to \\vserver1-vol1\vol1\

    Otherwise, I use the same ideas and concepts that you suggest.

  •  
    Danita, thanks for great article, but honest, this GW admin is far from being what our customers would like and expect.
    Hope Novell is seriously considering next/new GW admin tool
Related
Recommended