This week 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
/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.
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?
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.
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!
Have tried to make this work for 2 days on a new GW8 system and frankly, it doesn’t. Changing the path in domain properties just gets ignored, the next time GW starts the /groupwise/domain path is what is being used by C1 on the server console, and Windows machines mapped to the domain share still can’t manage gateways and agents. Bummer….
I’m not sure what’s happening for you then Skeptic. I’ve done this at many many sites (one just this week). Something is keeping your domain path from being “saved” in ConsoleOne – have you tried making the change from a Windows ConsoleOne to see if that fixes it?
If I am following the domain path issue in C1 as related by both you and “skeptic” correctly, I have run into the same problem as “skeptic”. Novell’s response was that they could not reproduce the domain path problem that we are having, yet others on NGWList and TTP are having the same problem as what we have been experiencing here. Wish I knew what the difference is between what we and others are doing wrong verses what you and Novell are doing right. Sigh….
Danita, I am having the same problem as both sceptic and John. I think it appears related to it being a sym link. I’m wondering if doing it as an NCP mount to the local volume (linux ncpmount command) would be treated differently as it’s then not a symlink?
Skeptics should be sure their instances of ConsoleOne are running as the same user as their GW agents … or the admin messages get left in the queues ….
I’ve used this model successfully as well 🙂
I am having problems as well with this. I have set the mount point to /mnt and done the command ln -s /media/nss/ server. If i browse to the mnt/server/domain directory to set it in c1 it automatically switches to /media/nss/vol/dom directory. If i manually type /mnt/server/domain dir it says path not found when i try and do a rebuild. This is happening to me on two different oes linux servers im running groupwise domains and post offices on and its making it very hard to do any maintenance on them at this point.
So, if you have made /mnt your Linux path, and your domain is in /mnt/server/VOL/dom (notice that VOL is indeed in all caps on your server and I can’t tell if you are doing that), then in ConsoleOne you should type in:
You don’t mention that you are putting the UNC path in. If you do, it should automatically switch you to the proper location. It will then look like /mnt/server/VOL/domain on Linux (as it should) and it should still show the UNC path if you view the domain from a Windows ConsoleOne. You should not put in the local Linux path for this, but the UNC path – maybe that’s what’s missing?
In windows c1 I have \\server\VOL\domain…the mnt point in linux is set to /mnt, on c1 on linux the path come up (when you select a domain to attach to) as /mnt/VOL/domain which gives error opening domain database (presumably because the server name is missing) If I manually slip the server name in so it reads /mnt/server/VOL/domain i get the following groupwise domain database cannot be accessed properly /VOL/domain…so im not sure what it wrong
Pingback: The installation routine crashed when I upgraded a domain! I lived to tell the tale. | Caledonia