This month, “On the Desktop” is something of a grab bag of tricks to make your personal computing life easier.
Trick One: Unbelievably Brain-Dead Easy SAMBA and NFS File Sharing
If you want to share data between your Windows boxes and your Linux machine and use your home Linux box as a simple file server for, you can spend several afternoons reading a pile of manuals, or you can use my brain-dead simple /etc/samba/smb.conf and /etc/exports files.
If you just want to have a couple of simple shares in Samba, like access to the root of the /home directory, or even direct access to the entire root filesystem, with no worries about setting user permissions and access control lists, use a smb.conf file that looks like this:
[global] workgroup = workgroup cups options = raw map to guest = Bad User domain master = no restrict anonymous = no preferred master = no max protocol = NT server signing = Auto domain logons = no local master = yes passdb backend = smbpasswd netbios name = sles9 encrypt passwords = yes
[myshare] path = / read only = no force user = root force group = root guest account = root case sensitive = no guest only = yes guest ok = yes browseable = yes printable = no
With this configuration, I’ve set up a single file share, myshare, which forces all connections to be the local root user, thus eliminating the need for any kind of file system security settings. Any Windows or Samba connection to this share will have read and write privileges, with no user logons required. In this example I have set the entire root file system to be the top level share using the path variable, but you could easily change this to /home or another already created directory like /home/jason/mp3, if you’re concerned you or someone else might accidentally screw up your box by copying files places they shouldn’t be.
Now, before all you security dweebs get your panties in a whirl, I’m going to add the disclaimer that I do not recommend these settings for a server or Linux workstation in a production enterprise environment. However, if this is a home server and the firewall on your router is turned on and wireless WEP key encryption is enabled, or if this is a lab machine behind a segregated VLAN or a closed-off subnetwork that only you or a select bunch of people have access to, I don’t foresee any problems with the configuration.
Besides the path variable within the share options, you’ll want to change the workgroup and netbios name variables under the [global] section to reflect the actual Windows workgroup name. (If you’re using the default at home, it’s workgroup, and the NETBIOS broadcast name of your machine, respectively). In this example, I set it to be the same as the hostname of my box, called sles9.
Simply copy this file over to /etc/samba.conf, and provided the Samba packages are installed on your system, restart the Samba daemons by issuing a /etc./init.d/smb restart as root. (If you’re using Debian or Ubuntu, the command will be /etc/init.d/samba restart.) Presto! You now have a file share you can browse and connect to from any Windows or Linux Samba client on your local network.
Setting up an NFS share that is easily mountable by another Linux or UNIX box is even more brain-dead easy than Samba. Check out my one-line /etc/exports file:
This exports the root filesystem, /. I’ve set allowable network clients to wildcard (*), and have set the filesystem as read/write (rw), using the default synchronization settings (sync) and allowing remote root users to perform functions as the local root user (no_root_squash).
Now again, I don’t recommend this for a security-conscious production network, but for your home box secured behind a firewall, who cares? As in the Samba example, you can export a different directory path, such as /home/jason instead of /. To begin sharing, simply run /etc/init.d/nfsserver restart as root.
On the client side, to access this share from another Linux machine (such as a virtual box running in VMWare) create the following entry into your /etc/fstab:
192.168.0.100:/ /mnt/nfs nfs defaults 1 1
In this example, 192.168.0.100 is the IP address of my Linux machine with the /etc/exports file shown previously, the colon is a separator, and the / is the remote file system to be mounted. (/ could just as easily be /home/jason, if the server exported that directory.) /mnt/nfs is the name of a directory I created locally (be sure it has read/write permissions as needed so other users on the local box can access it) to serve as the mount point of the remote file system. The rest of the stuff on that line is all default settings for a read/writeable NFS mount.
Once you’ve saved the file, chances are your Linux distribution will auto-mount the share and the share will be mounted automatically from now on during boot. If you want to manually mount it, simply issue a mount /mnt/nfs as root from a terminal prompt.
Trick Two: Making SUSE DVDs
SUSE is one of my favorite Linux flavors to play with. It’s a rock-solid platform for software development and one of the richest Linux distros around. Unfortunately, unless you buy a boxed copy of SUSE Linux, you won’t get any DVDs. Because of its frequent beta cycles, the OpenSUSE project doesn’t issue DVD ISO files for burning that you can download, and the Novell web site doesn’t have DVD ISO’s for any of its commercial Linux distributions either. Stuffing CDs during long Linux installations is a real drag, when you could just as easily have a single DVD and just walk away and come back when it’s done.
Fortunately, there’s a solution, and it’s called makeSUSEdvd, a script file written by a dedicated, but mysterious SUSE hacker from Belgium named “houghi”. houghi’s makeSUSEdvd script only works on Linux, so you’ll need a functioning Linux machine (but it doesn’t have to be a SUSE box) to run it on.
First, of course, you’ll want to download the ISO files for a SUSE distro onto your Linux box and shove them into a directory of your choosing. makeSUSEdvd works with all versions of SUSE, including the OpenSUSE.org and commercially packaged versions of SUSE Linux, SUSE Linux Enterprise Desktop, and SUSE Linux Enterprise Server, as well as beta releases. The key to this working correctly, however, is to make sure that each ISO file is named starting with the letters “SUSE”, so if they aren’t named that already, you’ll want to rename each ISO file along the lines of SUSE-SLES-10-CD-i386-BETA8-CD1.ISO, and so on.
Next, be sure the mkisofs program is installed. If you can burn CD’s on your box or if you have any of the CD burning programs installed, like k3b, chances are mkisofs is already on your system. If you don’t have it, you need to install the cdrtools package from your Linux distro’s software repository, or download it manually from Jorg Schilling’s site at ftp://ftp.berlios.de/pub/cdrecord/alpha/.
Next, you’ll need a program called create_package_descr, which you must pull down from the SourceForge site at http://sourceforge.net/project/showfiles.php?group_id= 146800& package_id=163260. gunzip the file and copy it to your /usr/bin or /usr/local/bin directory. makeSUSEdvd uses create_package_descr to catalog all of the .rpm files on the SUSE DVD from the CD images.
Finally, you’ll need the makeSUSEdvd script itself, also available from SourceForge, at http://sourceforge.net/project/showfiles.php?group_id= 146800& package_id=163319. If you’ve got an RPM-based distro such as SUSE, Red Hat, or Mandrake, download the RPM version, and install it with rpm-Uvh makeSUSEdvd-0.26-1.noarch.rpm as root. Otherwise, download the .tgz file, unpack it, and copy the script to a directory in your PATH, such as /usr/bin or /usr/local/bin.
Once all these steps are done, issue the makeSUSEdvd command as root from the directory you’ve moved the ISO files into. Once the script is completed (it can take several minutes depending on how fast your computer is), a finished SUSE DVD .iso file will appear in a directory called DVD_DIR under /tmp. Burn this file with your favorite DVD burning program and install.
Trick Three: Getting VMWare Products to Work in Ubuntu (and Debian)
In a previous “On the Desktop” column (http://www.linux-mag.com/2006-01/desktop.html), I described how to get Windows running on the free VMWare Player and explained why I carnally love VMWare as a systems integrator. Well, since then, VMWare has also released its next-generation VMWare Server e.x.p product for free as well, making it an even more highly-desirable platform for Linux distro evaluation and testing. As a writer for Linux Magazine, I wouldn’t want to do my job without VMWare — it would make evaluating and writing about all these desktop Linux distributions very difficult indeed.
Unfortunately, in that column about VMWare Player, I didn’t have time to research how to get VMWare stuff (VMWare Workstation, VMWare Tools, VMWare Server) running in Ubuntu and Debian, probably the two of the most important community distros on my watch list. To correct that oversight, here’s how its done.
During the installation process, VMWare’s install scripts expect certain source directories under /usr/src to be present, which under a typically-configured Ubuntu system don’t exist. Without them, the install scripts can’t properly compile all the kernel modules needed to support VMWare.
In Ubuntu, the first thing you’ll need to do is fire up a terminal window and issue the commend sudo apt-get install build-essential. That will install all of the basic support needed to compile software, including compilers and development libraries. On a Debian system, you can simply issue the command as apt-get install build-essential as root.
Next, you need to determine the precise kernel version that is running on the system. Issue the following command:
root@ubuntu:~# uname –a
You’ll receive the output like the following:
Linux ubuntu 2.6.12-9-386 #1 Mon Oct 10 13:25:32 BST 2005 i686 GNU/Linux
This tells you you’re running on kernel 2.6.12 for the 386 architecture. So you’ll need the matching kernel sources for the VMWare install script to compile against…