Chinquapin Tech Blog

This document will describe the setup of an Ubuntu 10.04 terminal server that authenticates to an AD server using Likewise Open and uses Samba to connect to home directories that are hosted by an OS X 10.6 server.

Background

Our school uses primarily Apple computers, but there is also a fair number of Linux terminal clients and faculty/office Windows machines. Because Apple’s implementation of Samba is not keeping up with the times (Windows 7 clients could not join an Open Directory samba domain until version 10.7 of OS X Server, which has other issues at this point), we decided to move to an AD authentication server. However, given that Apple products still work best on Apple file servers (iphoto libraries and other iLife files seem to require HFS+ formatted HDs and sharing seems to be most stable and fast between Macs using AFP, rather than SMB or NFS), we are housing our home and group folders on an Apple Xserve.

There are a number of articles that describe how to setup a dual-directory server (AD + OD) and the pros/cons of such a system, though I think the clearest comes from Bombich (if you do anything with Macs, this site is invaluable). The other doc comes from Apple–and there is a good summary of the steps involved on pg. 103 of the Admin guide.
http://www.afp548.com/netboot/mactips/activedir.html
http://images.apple.com/server/macosx/docs/Open_Directory_Admin_v10.6.pdf (pg 103)

Virtual Machine Guidelines

VMware’s ESXi 4.1 hypervisor is free and seems to work pretty well. When setting up a virtual machine for a terminal server, there are a number of options that do not have immediately obvious answers. The first of which is the number of vCPUs you assign to the virtual machine. Most of the literature suggests that you should always start with 1 vCPU and add more only if necessary. This recommendation comes from the fact that multiple vCPUs for one VM results in often unnecessary processor overhead. However, in a terminal server environment or multithread environment (eg SQL server), there seems to be some suggestion that you can gain better performance out of 2 vCPUs. The general consensus seems to suggest that you should analyze performance and see which is better. For our system, we have two quad core processors, which means 8 physical CPUs, which translates to 64 vCPUs (8 vCPUs per physical CPU). We have plenty of vCPUs, and we only have two VMs, so we are trying 2 vCPUs for each VM (one VM is running Windows Server 2008R2 and the other is 64bit Ubuntu 10.04). We will update these notes if further testing is done during heavily loaded conditions.

As far as memory–VMs have a certain amount of memory overhead and they also create swap files the size of the physical memory on the virtual hard disk, so you have to make sure you have enough room on your virtual hard disk to account for this. We have 24 GB of memory. 5GB is provisioned for the Windows Server and 20GB is provisioned for the Ubuntu server. Notice that this total is higher than 24 GB. ESXi will provide as much memory as required by the VMs–but typically 100% of that memory will not be used, so you can over-provision without a problem typically. You can also use reservations and priority settings to control how memory is managed and divvied up, but for our 2 machine setup, this isn’t really necessary that I can tell.

Thin provisioning your hard drives is a good way to potentially save hard disk space, though I did notice a performance hit when copying files. The current Ubuntu setup is a thin provisioned 250GB virtual hard disk that allows for lots of local profile space, but also ample room for additional test VMs to be placed on the 1TB datastore. The Windows Server is setup on a 100GB thick provisioned virtual hard drive on the 146GB datastore. This leaves some unused space on that datastore that could be used for test VMs.

Setting up Ubuntu 10.04 LTS

1. Download the 64bit alternate cd version of Ubuntu. The alternate CD is important for installing LTSP
2. Start up the VM and load the iso image
3. Press F4 and select LTSP server
4. Run through the installation
5. Set a static IP

   sudo gedit /etc/network/interfaces

   add the following underneath auto eth0

   iface eth0 inet static
   address 10.10.10.X
   netmask 255.255.252.0
   gateway 10.10.10.254

   Restart the computer or manually disconnect auto eth0 and bring eth0 up

   sudo /etc/init.d/networking restart
   sudo ifup eth0

6. Setup Likewise Open to connect to Active Directory server
   1. This documentation of Likewise Open is quite good: http://www.likewise.com/resources/documentation_library/manuals/open/likewise-open-guide.html
   2. Make sure that your DNS server is set to the AD server. You can check /etc/resolv.conf to make sure.

      sudo gedit /etc/resolv.conf

      nameserver 10.10.10.249

      Also edit nsswitch.conf and move ‘dns’ to be the first entry in the ‘hosts:’ line as shown

      # /etc/nsswitch.conf
      #
      # Example configuration of GNU Name Service Switch functionality.
      # If you have the `glibc-doc-reference' and `info' packages installed, try:
      # `info libc "Name Service Switch"' for information about this file.
      
      passwd:         compat
      group:          compat
      shadow:         compat
      
      hosts:          files dns mdns4_minimal [NOTFOUND=return] mdns4 mdns
      networks:       files
      
      protocols:      db files
      services:       db files
      ethers:         db files
      rpc:            db files
      
      netgroup:       nis

      Download Likewise Open (64 bit Debian version): http://www.likewise.com/community/index.php/download using the localadmin account

   3. Open terminal and change to the directory that you downloaded the file to, make it executable, and run it.

      cd /home/localadmin/Downloads
      chmod a+x likewiseopen-version.sh
      sudo ./likewiseopen-version.sh

      At this point a domain join gui will pop up and allow you to join the domain. Make sure the default domain check box is checked. If this gui fails, double check the files mentioned above and try running the commain line domain join

      sudo /opt/likewise/bin/domainjoin-cli join chinquapin.local administrator

      If you used the command line tool to join the domain, you will want to change the behavior Likewise Open to use the default domain so that users don’t have to add the domain name before their usernames in order to log in. You can test this after restarting the computer after you have joined the domain by typing

      id someusername

      and if you get back that user out of your AD you are good. Otherwise, you’ll need to do the following to fix

      sudo /opt/likewise/bin/lwconfig AssumeDefaultDomain true
      /opt/likewise/bin/lwsm refresh lsass

7. Install the Free-NX server as a better way to access the server than using desktop based VNC

   sudo add-apt-repository ppa:freenx-team
   sudo apt-get update
   sudo apt-get install freenx

8. Install VMWare tools

Right click on the VM host in vSphere Client and go to Guest–>Install/Upgrade VMWare tools then run the following commands in Terminal on the client

sudo mkdir /media/cdrom
sudo mount /dev/cdrom /media/cdrom
cp /media/cdrom/VMware*.tar.gz /tmp
sudo umount /media/cdrom
cd /tmp
tar xzvf VMware*.gz
cd vmware-tools-distrib/
sudo ./vmware-install.pl

Accept all the defaults.

9. The 64 bit version of Ubuntu comes with a 64 bit version of the thin-client image, which doesn’t work on our 32-bit thin client hardware. So you need to build a new 32-bit image. Note: You may need to remove the existing i386 folder (sudo rm -R /opt/ltsp/i386) which appears to be created using the 10.04-2 release, whereas the 10.04-1 release does not include it.

   sudo ltsp-build-client --arch i386

10. Apply the 1720 client resolution fix. Download the file from email, make it executable, and run it:

    cd /home/localadmin/Downloads
    chmod a+x 1720_fix.sh
    sudo ./1720_fix.sh

At this point you should have an LTSP server that can authenticate to the AD server and boot up a thin-client. Various lock-down procedures, software installs, and default profile building steps should follow.

Home Directories

Network home directories that can be accessed from Windows clients, Mac clients, and Linux clients are not a piece of cake. As mentioned earlier, the choice to host home directories on an Apple Xserve was based on the fact that most clients are OS X and AFP seems to work best for mac clients. Additionally, sharing and workgroup management through OS X Server is much easier than through Windows Server or Linux. NFS is by far the easiest sharing protocol to use with Linux, though I believe the least secure. Unfortunately, the NFS server included in OS X Server 10.6 appears to have broken compatibility with Ubuntu. I can mount an OS X NFS share successfully, but only the admin user can browse the share, despite global read permissions. This problem does not exist using OS X Server 10.5. The exact same mount options in /etc/exports provide a working mount with 10.5 but an unbrowseable mount in 10.6. I’m not sure what the problem is, but there are various other options for mounting, including using pam_mount to mount Samba shares (issues with Apple’s Samba server version here), using automount (same Samba issue), or doing simple shortcuts. The good news is that the standard Ubuntu GUI seems to be able to mount Apple Samba shares without a problem and without having to pass username/password information (since it already has that).

At this point, I could delve into a discussion about the merits of local profiles vs. network profiles–but will spare you that larger discussion. While we have tried various options, my current attitude is that when you are dealing with multiple OSs, multiple connection types (wired/wireless), and multiple file server types (afp, smb, nfs, etc.), it is best to stick with local profiles and train your students to save into an automounted network home folder. This means they will only have the files that they want and not all the other litter that accompanies roaming profiles. In a thin-client environment, you already have a built-in roaming profile system–as all thin-clients talk to one server, serving the same profile out. On Windows and OS X, not having roaming profiles means that students will not have the luxury of having their preferences travel with them from machine to machine. This luxury seems to be made more and more irrelevant these days with the dominance of cloud applications, but regardless, I have simply not been satisfied with any roaming profile setup on a wireless network–and it seems to make the most sense to have profiles behave the same way (local or roaming) across your entire network–thus we use local profiles for wired machines as well.

For our LTSP setup, we have a startup script that creates shortcuts and bookmarks to the user’s mapped network drive. For OS X, we use the built-in mapping capabilities of Workgroup Manager in OS X Server. For Windows, we have a network drive automapped on login with a startup script.

Within Ubuntu you can run startup applications by placing them in an autostart folder. You can create an Ubuntu .desktop item that will run the application. For user specific startup applications, place the .desktop file in ~/.config/autostart/ (where ~ designates a user’s home directory) and make sure it is executable. For system-wide startup programs, place the .desktop file in: /usr/share/gnome/autostart/ or /etc/xdg/autostart/. Here is an example .desktop file to start the Papercut-NG client program on login:

[Desktop Entry]
Type=Application
Exec=alltray "/opt/papercut/linux-client/pc-client-linux.sh --use-pre-authentication --silent"
Hidden=false
NoDisplay=false
X-GNOME-Autostart-enabled=true
Name[en_US]=Papercut
Name=Papercut
Comment[en_US]=Papercut client
Comment=Papercut client

In addition to the above .desktop startup file, to get Papercut client working, you have to copy the pc-shared-secret.dat file and the linux-client folder from the master papercut server. I would put both of these items in a directory called /opt/papercut. You then need to give read/execute access to the linux-client files and install the alltray program (which places the papercut client in the tray):

sudo apt-get install alltray
sudo chmod -R o+rx /opt/papercut/linux-client

In order to get network Home locations mounted with shortcuts in Nautilus and on the desktop, I created a startup application that creates those shortcuts. There are two files: 1) the .desktop file that goes in the /usr/share/gnome/autostart directory and 2) the actual shell script (loginShortcuts.sh) that creates the shortcuts, which can be placed anywhere–though I put it in a new folder /opt/chinquapin/.

loginShortcuts.desktop

[Desktop Entry]
Type=Application
Encoding=UTF-8
Exec=/opt/chinquapin/loginShortcuts.sh
Name=Network Shortcuts

loginShortcuts.sh

#!/bin/sh

if [ $LOGNAME != localadmin ];
then

#This is the Papercut-NG client using pre-authentication
/opt/papercut/linux-client/pc-client-linux.sh --pre-authenticate --user "$LOGNAME" --shared-secret-file "/opt/papercut/pc-shared-secret.dat"

#Create the Network Home desktop shortcut if it doesn't already exist
if ! [ -e "/home/local/CHINQUAPIN/$LOGNAME/Desktop/Network Home.desktop" ];
	then
echo "#!/usr/bin/env xdg-open

[Desktop Entry]
Version=1.0
Type=Link
Icon[en_US]=/usr/share/icons/gnome/scalable/places/folder_home.svg
Name[en_US]=Network Home
URL=smb://aristotle/home/$LOGNAME
Name=Network Home
Icon=/usr/share/icons/gnome/scalable/places/folder_home.svg" > "/home/local/CHINQUAPIN/$LOGNAME/Desktop/Network Home.desktop"
chown $LOGNAME "/home/local/CHINQUAPIN/$LOGNAME/Desktop/Network Home.desktop"
fi

#Create the Shared folder desktop shortcut if it doesn't already exist
if ! [ -e "/home/local/CHINQUAPIN/$LOGNAME/Desktop/Shared.desktop" ];
	then
echo "#!/usr/bin/env xdg-open

[Desktop Entry]
Version=1.0
Type=Link
Icon[en_US]=/usr/share/icons/gnome/scalable/places/gnome-fs-smb.svg
Name[en_US]=Shared
URL=smb://aristotle/shared
Name=Shared
Icon=/usr/share/icons/gnome/scalable/places/gnome-fs-smb.svg" > "/home/local/CHINQUAPIN/$LOGNAME/Desktop/Shared.desktop"
chown $LOGNAME "/home/local/CHINQUAPIN/$LOGNAME/Desktop/Shared.desktop"
fi

#Create the Network Home and Shared folder bookmarks in Nautilus if they don't already exist
if ! grep -q "Network Home" ~/.gtk-bookmarks;
	then
	echo "smb://aristotle/home/$LOGNAME Network Home">> ~/.gtk-bookmarks
	chown $LOGNAME ~/.gtk-bookmarks
fi

if ! grep -q "Shared" ~/.gtk-bookmarks;
	then
	echo "smb://aristotle/shared Shared">> ~/.gtk-bookmarks
	chown $LOGNAME ~/.gtk-bookmarks
fi
fi

exit

While this method is hardly the most elegant, it seems to work fine. There is also a way to implement startup scripts in the actual LTSP chroot, but in this case you are running the application on the thin-client rather than the server, which adds all sorts of unnecessary complications.