Volume Number: 25
Issue Number: 03
Column Tag: Networking
by Noah Gift
In the last two articles, we got familiar with using virtualization to build a Samba /LDAP environment that our Macs could talk to. For many people those two articles would be enough to setup a simple home file sharing and authentication system. And because our Ubuntu virtual machine is just a file, it is simple to keep copies of this configuration laying around in case something goes wrong.
In part two we reached a stopping point after we got basic authentication working with OpenLDAP. In this article we tackle how to fully configure and tweak OS X to work with OpenLDAP, and Samba, including automounting a network home directory via Samba or NFS served out from the virtual machine. It is almost a little too science fiction to talk about without seeing some examples, so I have included quite a few.
In the first two articles, we downloaded a pre-configured Ubuntu virtual machine here: http://examples.oreilly.com/9780596515829/vm/
All of the following steps will be based on the assumption that you have been continuing to work from either this Samba/OpenLDAP server, or a similar one you configured.
OS X has been around for almost a decade, with first version OS X server coming out in 1999. Many Systems Administrators have wrestled with trying to get OS X to behave more like Unix and Linux for all of this time. With 10.4 Tiger, a few changes brought OS X very close to acting like traditional Unix machines, and finally with Leopard becoming POSIX and SUSv3 compliant.
One of the new, and welcome, changes is a working automounting system just like your favorite Unix or Linux system. To demonstrate how useful this is, we are going to go back to our virtual machine to create an NFS exported file system, and then automount it on our Mac.
Step 1: Install NFS on the Ubuntu virtual machine:
sudo apt-get install nfs-kernel
(Note, if you are not familiar with the apt-get command on Ubuntu, it is a package installer, that works a lot like Fink or Mac Ports on the Mac)
Step 2: Add an entry into /etc/exports (again, on the virtualized server)
#directory exported host(options) /usr/export *(rw,sync,insecure)
(Note, we are using * instead of specifying a host or range of IP addresses. This is insecure and exports the volume to the world. This is not recommended unless you are testing a configuration behind a firewall. Also, note that we use the option "insecure". This is because OS X uses a different port than Linux to communicate over NFS. If this option is not set on the server, an OS X client will not be able to mount a NFS volume without a special client side NFS configuration.)
Step 3: Back on the OS X machine, browse to /net/192.168.1.200/usr/export (or whatever the IP address is)
# cd /net/192.168.1.200/usr/export/
This is the beauty of automounting. You simply browse to a hostname/ip address, and the shares just mount. We can see this in action by looking at the output of the df command:
# df -h Filesystem Size Used Avail Capacity Mounted on /dev/disk0s2 93Gi 81Gi 12Gi 88% / devfs 110Ki 110Ki 0Bi 100% /dev fdesc 1.0Ki 1.0Ki 0Bi 100% /dev map -hosts 0Bi 0Bi 0Bi 100% /net map auto_home 0Bi 0Bi 0Bi 100% /home trigger 0Bi 0Bi 0Bi 100% /net/192.168.1.200/usr trigger 0Bi 0Bi 0Bi 100% /net/192.168.1.200/usr/export 192.168.1.200:/usr/export 2.0Gi 461Mi 1.4Gi 25% /net/192.168.1.200/usr/export
Step 4: Try to create a file
# touch foo touch: foo: Permission denied
We get permission denied because NFS uses two levels of security. The first layer of security is host/ip based. We passed that layer of security, and were able to mount the volume. The reason we can't write to the file though, is that owner/group permissions are not set to allow my user account to write. Let's fix this now.
In the last section we were able to setup a NFS server and mount it on our client, but we weren't able to write to it yet because we didn't have proper permission. Let's fix this, by creating a LDAP/Samba User account, and then changing permissions so we write to on when we automount it on the Mac.
Step 1: Use the smbldap-useradd command to create a mactech account
$ sudo smbldap-useradd mactech
Step 2: Use the smbldap-passwd command to set the password
$ sudo smbldap-passwd mactech Changing UNIX password for mactech New password: Retype new password:
Step 3: Verify the account works
py4sa@py4sa:~$ su - mactech Password: mactech@py4sa:~$ pwd /home/mactech mactech@py4sa:~$ id uid=30003(mactech) gid=513(Domain Users) groups=513(Domain Users)
This command-line tool creates an account that simultaneously is able to authenticate to Samba, and LDAP. Now, we can go back to our exported volume, and change the ownership to reflect a uid(user id) of 30003, and a gid(group user id) of 513. Note, that the group is called Domain Users, which is a default Samba/LDAP group. All new user accounts get added to this account.
Step 4: Changing ownership of /usr/export to our new mactech user
mactech@py4sa:~$ exit logout py4sa@py4sa:~$ sudo chown -R 30003:513 /usr/export/ [sudo] password for py4sa:
Now, let's test this out on the Mac by changing to our newly created mactech user, and attempting to write to this automounted volume.
Step 5: Authenticating, Mounting, and Writing as an Samba/LDAP user. This takes place on your client OS X machine.
Change to the mactech user:
# su mactech Password: bash: /home/mactech/.bashrc: Input/output error
Enter the export directory and set off the automount:
bash-3.2$ cd /net/192.168.1.200/broadcasthost/localhost/ bash-3.2$ cd /net/192.168.1.200/usr/export/
List the contents of the directory:
bash-3.2$ ls foo
Create a new file in this directory:
bash-3.2$ touch test.txt
No error, so list the contents again:
bash-3.2$ ls -la total 31 drwxr-xr-x 3 mactech Domain Users 4096 Nov 5 13:34 . dr-xr-xr-x 3 root wheel 2 Nov 5 12:21 .. -rwxrw-rw- 1 mactech Domain Users 6148 Oct 14 02:40 .DS_Store drwxr-xr-x 2 mactech Domain Users 4096 Oct 14 02:06 foo -rw-r--r-- 1 mactech Domain Users 0 Nov 5 13:34 test.txt
There are a couple of things to point out. First, our shell complained when we logged into the mactech user, because there is no home directory path that matches /home/mactech on our Mac, like it does on the Ubuntu machine. We are going to fix that in the next section, but for now, if we move past this, we can see that yes, we can create a test file. And, if we look at the permissions, they are set to the username and group that we would expect. Ok, on to fixing the home directory.
In both the last article, and this article, we ran into problems when using LDAP user accounts, because when we created a user account in LDAP on the linux machine, the path to mount the home directory didn't exist on our Macs. In addition, it makes sense that we would want to share common network mounted home directories between the two platforms.
Fortunately, with a little help from symbolic links, it is quite easy to accomplish a cross platform home directory.
Step 1: Create a home directory in /net/192.168.1.200/usr/export/
While still logged in as the mactech user:
$ mkdir -p /net/192.168.1.200/usr/export/home/mactech
Step 2: On the Ubuntu server create symbolic link from /usr/export to /export
py4sa@py4sa:/$ sudo ln -s /usr/export/ /export
This allows us to create a common path to a home directory that we can also symbolically link on the Mac when it is mounted.
Step 3: Change the LDAP record for mactech to reflect the new location
py4sa@py4sa:/$ sudo smbldap-usermod -d /export/home/mactech mactech
Step 4: Create a symbolic link on OS X from the automount directory to /export
# sudo ln -s /net/192.168.1.200/usr/export /export
Step 5: Log in via the command line to the mactech account on OS X to verify it works, and verify the mount point.
# su - mactech Password: $ $ pwd /export/home/mactech $ df -h Filesystem Size Used Avail Capacity Mounted on /dev/disk0s2 93Gi 80Gi 13Gi 87% / devfs 111Ki 111Ki 0Bi 100% /dev fdesc 1.0Ki 1.0Ki 0Bi 100% /dev map -hosts 0Bi 0Bi 0Bi 100% /net map auto_home 0Bi 0Bi 0Bi 100% /home trigger 0Bi 0Bi 0Bi 100% /net/192.168.1.200/usr trigger 0Bi 0Bi 0Bi 100% /net/192.168.1.200/usr/export 192.168.1.200:/usr/export 2.0Gi 461Mi 1.4Gi 25% /net/192.168.1.200/usr/export
Ah, everything works this time. Now, let's make a test file just to be sure.
Step 6: Creating a test file
$ touch mycommondir.txt $ ls -lan total 16 drwxr-xr-x 2 30003 513 4096 Nov 5 14:50 . drwxr-xr-x 3 30003 513 4096 Nov 5 13:36 .. -rw-r--r-- 1 30003 513 0 Nov 5 15:10 mycommondir.txt
When we login to the Linux machine, we should see this same file and have access to it because the uid/gid are the same between the systems. Before we do that though, let's use fast user switching to login to this NFS mounted network account. After all this is a Mac, not just a command line only Operating System.
Step 7: Use fast user switching to login to the mactech account, and verify it works. (Note, using fast user switching is important because you need to keep your virtual machine running).
Your Mac should take a few seconds, and then you should get a home directory that looks like this:
Figure 1: NFS Mounted Mac Home Directory
What is cool about this, is that it automatically created "Mac stuff" for us, including the Desktop, Pictures, Downloads, and Library folder, yet kept the test file we created mycommondir.txt. Now when you are ready to log out of this account, we can test what happens when we ssh into our virtual machine as the mactech user. Want to guess what we see?
Step 8: ssh into Virtual Machine as mactech user
$ ssh mactech@192.168.1.200 mactech@py4sa:~$ pwd /export/home/mactech mactech@py4sa:~$ ls -lan total 144 drwxr-xr-x 8 30003 513 4096 2008-11-05 15:28 . drwxr-xr-x 3 30003 513 4096 2008-11-05 13:36 .. drwx------ 2 30003 513 4096 2008-11-05 15:14 Desktop drwx------ 2 30003 513 4096 2008-11-05 15:12 Downloads -rw-r--r-- 1 30003 513 6148 2008-11-05 15:14 .DS_Store drwx------ 12 30003 513 4096 2008-11-05 15:15 Library -rw-r--r-- 1 30003 513 4096 2008-11-05 15:14 ._mactech_home_dir.png -rw-r--r-- 1 30003 513 98015 2008-11-05 15:14 mactech_home_dir.png -rw-r--r-- 1 30003 513 0 2008-11-05 15:10 mycommondir.txt drwxr-xr-x 3 30003 513 4096 2008-11-05 15:13 Pictures drwx------ 3 30003 513 4096 2008-11-05 15:12 .Spotlight-V100 drwx------ 2 30003 513 4096 2008-11-05 15:28 .ssh mactech@py4sa:~$
Awesome! We have a common NFS mounted home directory that "just works" on OS X and Linux, and we did it all with a virtual machine.
In this third of a four-part series, we created a common NFS mounted home directory by leveraging the power of LDAP, Linux, NFS and the automount daemon. As a result, we now have a recipe for a complete cross platform authentication and network home directories.
Because we used an LDAP/Samba configuration that was configured to work together, we are able to create Samba shares that work with Linux, OS X, or Windows. These could be home directories, and common mount points via Samba, or you could do as we demonstrated in this article, and share out the same directory via Samba and NFS.
The beauty of this configuration is its flexibility, as we can use this one virtual machine to accomplish several different, yet robust configurations. In addition, due to the use of symbolic links, and the automounter, we didn't need to touch LDAP on OS X, other then our initial work in the second article. One thing we didn't cover in detail that bares a mention though, is that NFS requires a thorough understanding of Unix permissions. If you run into problems deploying this in a wider environment, remember to review that you have intentionally configured a proper umask, and group and user permissions. This is the most common problem when first dealing with common NFS home directories for first-timers.
In the final article, we will close the gaps of dealing with LDAP and Samba on OS X. We will briefly talk about OS X's extended attributes and Managed Preferences, and then get into configuring a project management and version control tool, trac, to work with LDAP. We will also briefly talk about how LDAP works with Apache authentication, and how the PHP LDAP admin tool can make dealing with LDAP much easier. Remember, all of this works with the exact same username and password, too, and that is the fun part of setting up centralized authentication.
Noah Gift. "How To Build A Dirt Easy NAS with Samba". Red Hat Magazine, http://www.redhatmagazine.com/2007/06/26/how-to-build-a-dirt-easy-home-nas-server-using-samba/.
Noah Gift and Grig Gheorghiu "LDAP Crud". IBM Developerworks, http://www.ibm.com/developerworks/aix/library/au-ldap_crud/.
Noah Gift. "Getting Started With Open Directory". O'Reilly. http://www.macdevcenter.com/pub/a/mac/2007/06/01/discover-the-power-of-open-directory.html
Noah Gift and Jeremy Jones. "Python For Unix and Linux Systems Administration". O'Reilly . ISBN: 0596515820
Noah Gift has been a Mac user since his family bought a Macintosh Performa 6300 in 1992, and started connected to BBS networks immediately and then eventually the World Wide Web in 1993 when it become open to the public. He is the co-author of "Python For Unix and Linux System Administration" by O'Reilly, and the upcoming "Google App Engine In Action" by Manning.
Noah has a couple of decades of experience in the Television and Film industry starting off as an editor for ABC Network News as a teenager. He contributed to the first feature animated film for Disney Feature Animation and Sony Imageworks. He also had stints at Turner Studios and Caltech, where he worked for the Nobel Prize-winning President as a Mac expert. He has a Master's degree in CIS, and is LPI and ACSA certified. He currently works for WetaDigital in New Zealand. Many of his projects and writing are available at www.noahgift.com. He can be contacted at noah.gift@giftcs.com
