the bytes

Edit:

Please see the information I posted in the comments below before enabling the autofs feature on a mobile OSX device.

Background

Both at home and works(s), I use nfs for sharing directories, a lot.  I choose nfs a couple reasons:  1)  every Linux/UNIX supports it (and even Windows *can*) and 2) it’s easy to set up.  Sure, it has it’s problems, but so does every other way of sharing files.   If your environment is sane and you know the limitations, nfs can be configured in a few minutes and works very reliably.

There’s a very handy tool called autofs that works well with nfs.  It’s an automounter, but not like the ones most folks are familiar with.  Forget making your usb stick or cd/dvd magically accessible, although it can do that too, autofs can mount essentially anything on demand/access, including network shares.  In my case, I use it with nfs so when I access directories, nfs mounts attach and are ready for use.  After an idle period (no applications using the shares/devices and no shells open in the), autofs also unmounts them, too, eliminating the mess caused by forgetting to unmount your shares or devices.

Recently, I acquired a Macbook Pro running Snow Leopard (OS X 10.6).  It’s a nice addition to my hardware collection and connects easily to TV or stereo (DVI -> hdmi cable and 1/8″ audio -> RCA input cable, respectively).  Only my Atrix has been as easy to connect to them, but using the macbook, I can get anything on the screen without using accessories.

My desktop has quite a few disks of storage in it, and a lot of it has backups, videos, or audio files that I already use on other networked computers here, so naturally I’d like to include the mac in the group of systems I share my data with.  NFS shares to subnets or specific IPs, so I first created a Location (in Network Preferences) that sets a static IP when connecting to my home wireless network, giving me a specific target IP to share the directories to.

Exporting NFS Shares

The Linux side of nfs version 3 sharing is easy to configure.  Edit /etc/exports and start up the nfs deamon.  I’m going to show three shares here and how to export and then automatically mount them on the macbook.  In the following output, three directories are shared to one IP address and they are shared with read/write access, asynchronous writes (faster), and with squashing root on the client end.  I write them as ip/subnet to show that CIDR notation can be used when sharing over nfs.

# cat /etc/exports

/mnt/desktop/video    192.168.1.40/32(rw,root_squash,async)
/mnt/desktop             192.168.1.40/32(rw,root_squash,async)
/mnt/image                192.168.1.40/32(rw,root_squash,async)

Configuring OS X automounter

Because I want my shares to automatically mount on access on the mac, I am not going to configure the nfs mounts using fstab or Disk Utility -> File -> NFS Mounts to define them.  I’m going to use the automounter files that are part of the OS X base install.  The main automounter file on OS X is found at /private/etc/auto_master or can be referenced by the /etc/auto_master name, too, and contains a lot of entries that very few people use. I started by commenting out all the entries except /-, which is something that I don’t know is used or not:

#
# Automounter master map
#
#+auto_master                # Use directory service
#/net                                 -hosts                -nobrowse,hidefromfinder,nosuid
#/home                               auto_home        -nobrowse,hidefromfinder
#/Network/Servers               -fstab
/-                                       -static

Now I add a line where I can define the shares from my desktop/server system, named daemon.  The first column shows a mount point that will automatically be created by the automounter.    The second column tells it to parse a file named auto.daemon.  I named the file after the system its defining mounts from and used a dot in the filename rather than the mac way of using an underscore:

/daemon                 auto.daemon

The next step is to create the file that defines the individual shares exported from the nfs server.   I added an entry in /etc/hosts, which is on a different firewalled subnet but reachable through a static route on my gateway, so I could reference the server by hostname:

### Added to make automounter use hostnames instead of IP’s
192.168.11.2    daemon

For the auto.daemon file, three things need defined in a specific order: mount name, mount options, and path to the nfs share on the network.  Mount options can be omitted if a default set works, but I am specifying them here.  Also, I have three shares exported, but I can use two entries in auto.daemon to define them because I am using wildcards , which I’ll explain later:

#cat /etc/auto.daemon
video     -rw,soft,resvport,rsize=32768,wsize=32768        daemon:/mnt/desktop/video
*           -rw,soft,resvport,rsize=32768,wsize=32768      daemon:/mnt/&

First I’ll explain the mount options.  I am mounting the shares read/write and using soft mounts.  Soft mounts will timeout and return an error if the server is not reachable; the alternative to soft is hard mounting, which will wait forever for the server to come online unless a timeout value is given.  The resvport option specifies that the server is running the nfs server on a privileged port, one below 1024.  By default, OS X tries to reach nfs servers on higher port numbers, which would require the “insecure” option to be added to my /etc/exportfs options for each share listed above.  The rsize and wsize values set chunk size for nfs reads and writes, respectively.

The third column of the output is the nfs path.  Since I created an entry for daemon in /etc/hosts, I can use daemon:/<path to share>, which for video is the exported daemon:/mnt/desktop/video directory.  I’ll discuss the second path containing the & in a moment.

The first column in the output above lists the mount points for shares.  The mount points will be created on access and be found inside of the /demon directory that automounter creates.  The first entry, video will allow me to access /daemon/video, which will show the contents of daemon:/mnt/desktop/video.  On the Mac, software will see this no different than a local directory.

The second line of the auto.daemon output above uses wildcards in two places, for both the mount points and for the nfs path.  The asterisk (*) at the beginning simply catches any entry under /daemon that is not explicitly defined before the wildcard line.  So, for example, I can cd /daemon/desktop or /daemon/image without having lines for each of them.  The ampersand (&) at the end of the line in the nfs path appends the value of the asterick to the nfs path.  Thus, cd /mnt/image expands to daemon:/mnt/image.

The asterisk and ampersand entries have some limitations, though.  First, the share path is required to be exported.  My server may have a /mnt/usbstick directory, but cd /daemon/usbstick will fail if /mnt/usbstick is a mount point or directory that is not listed in /etc/exports on daemon.  Second, shares expanded with wildcards must reside at the same absolute paths on the host exporting them.  So, for example, if the host is exporting /usbstick, a /mnt/usbstick -> /usbstick symlink on the server will not let me cd /daemon/usbstick on my client; bind mounting directories would, however work.  Third, a wildcard mount point must be the last entry of the automounter map file.  Since the file is parsed top down with first to match logic, if the wildcard line is first, no other lines will be used.

After editing auto_master and/or any map files for mounts, the automounter needs to be restarted.  The mountpoints I defined, both /daemon and those I explictly specified in auto.daemon will then show:

#automount -vc
automount: /daemon updated
automount: no unmounts

#ls /daemon

video

The Results

To show the ease and speed of NFS, I’ll issue a couple commands just I would normally use.  The setup here is this:  the macbook is connected to a linksys running DD-WRT.  The server (daemon) is connected to another system over 100 MB ethernet, and that system also connects to the DD-WRT router over wireless.  Traffic from the laptop to the server thus follow this path:

laptop -> DD-WRT -> static routing rule -> wireless connection -> iptables on middle man -> iptables on daemon

Run as root (sudo su -) on the mac

#mount |grep daemon

map auto.daemon on /daemon (autofs, automounted, nobrowse)

This shows that the automounter has /daemon running, but there are no submounts active inside the /daemon stub.

#time ls /daemon/video

<directory listing of 73 entries omitted>

real    0m0.293s
user    0m0.006s
sys     0m0.011s

To show ls was the slow part and not the mounting:

#umount /daemon/video

#time cd /daemon/video

real    0m0.058s
user    0m0.000s
sys     0m0.000s

Finally, lets remove the time it took to cd and get a time for just the nfs mounting:

#cd /

#umount /daemon/video

#mkdir /video

#time mount -t nfs -o resvport,soft,rsize=32768,wsize=32768 daemon:/mnt/desktop/video /video

real    0m0.043s
user    0m0.001s
sys     0m0.006s

I’d like to take a look at what I will use.  For reference, I’m Ted, and I’m a Linux systems guy and I don’t code much other than scripting.  Whether you call me an admin or engineer doesn’t matter, I made things work together and I made Linux run well, whether it be big or small.  Using Linux is a certainty for me; once the choice is made, the next step is looking into Linux to see what’s of use (or useable) there.

One solid requirement is a package manager that works.  There has been much debate about the “best” approach to installing software and most distributions have the ability to use different formats of package files.  Hurray for getting some interoperability between distributions!  Overall, many distributions seem to generally handle packages and system changes alright, but in case of any glitch there can be major issues that result in total breakage.  Since I consider stability important, a total system crash is unacceptable unless something very bad happened, i.e. disk or other hardware problem or important disk commits were interrupted.  Ideally, an easy way to repair problems should always be offered, but you’ll see this isn’t the case, just read on.

I tried out Ubuntu the other day on a work desktop, a 64 bit Optiplex with 3 GB of memory and a dual head but nothing-special ATI card.  I was going to use the distribution because it is what an IT manager had available for install, so I gave it a try.  It was one version out of date so after the install, it suggested I upgrade, which I was okay with. After giving the go ahead, I was shown that on a rather fast connection, the process would  take over four hours and decided it would be better to use my computer at least part of  the day since it was my first day on site; I’d run the upgrade overnight.  I killed the  process after it started  downloading, but surely not after enough to have really done anything to the system.  Things stopped working, so I rebooted and voila, no longer did the login manager work.  I was presented with no options and a broken GDM login manager.

Could I have fixed it using a virtual terminal?  Yes, but how is that even needed on a Linux made for desktops since a normal user wouldn’t want to control-alt-f1, login, sudo apt-get anything?  Before anyone comments on that to themselves, consider the newest or least technical Linux user you’ve ever met, then ask yourself what would they at that point do?

Canceling the process may be unusual and unpredicted, but so are power outages.  To the system, the power could have been cut or a child or pet could have bumped the system. It doesn’t know I killed it, so it wasn’t punishing me for breaking “the process” because it doesn’t know I did anything wrong.  It also never warned me not to interrupt the process and never said it was changing the installed system: it said it was downloading files, and it was only perhaps 30 seconds into a process it said would take 4+ hours, or .2% complete.  That one fifth of one percent was enough to fail the distribution for me based on lack of communication and inability to effectively handle an interruption of process; and the failure is heavily underscored by the fact the distribution is so commonly recommended to new users.  New users cannot fix distribution failures and experienced users should not be expected to tolerate them.

Let’s return to focus now.  What will I use to manage the distribution packages on my desktop?  Something besides the Ubuntu label and their affiliated single click auto-magic process.

I was tired of mounting and unmounting ISO’s from temrinal, so I made a simple script to do the work for you in Thunar. It probably isn’t the best, but you don’t have to run some install.sh script, you just have to follow a couple of steps and you are good.

thumount.tar

Thanks to Ted: There is a working ebuild for media-sound/pianobar. Make sure you add this one to ‘/usr/local/portage/media-sound’. (A great replacement to the flash based Pandora radio).

Okay…. This has to be a fairly new thing because it took a lot to get the file system to mount in Linux and allow me to navigate. There were a few things needed before all of this worked; to include manually building/emerging an ebuild. Hopefully this will help streamline the support for the few Xoom + Gentoo users out there.

You will need this ebuild and file so that you can build mtpfs.

mtpfs.tar.gz (This is the ebuild)
mtpfs-0.9.tar.gz (Copy this file to /usr/portage/distfiles)

First, I had to make sure that the device was detected. It has to be in debug mode.

simply plug in the usb cable and run mtp-detect and you should get a ton of crap like the following:

If there are any errors, then I would make sure that you have mtp support built properly.

Now, your make.conf needs /usr/local/portage as one of your PORTDIR_OVERLAYS, then add your ebuild to /usr/local/portage/sys-fs/mtpfs.

Next, you will need to build it manually. THIS IS NOT THE RECOMMENDED WAY OF BUILDING ANYTHING ELSE. ;( People don’t hate me for this)

# cd /usr/local/portage/sys-fs/mtpfs
# ebuild mtpfs-0.9.ebuild manifest
# ebuild mtpfs-0.9.ebuild unpack
# mv /var/tmp/portage/sys-fs/mtpfs-0.9/work/mtpfs-0.9.orig /var/tmp/portage/sys-fs/mtpfs-0.9/work/mtpfs-0.9
# ebuild mtpfs-0.9.ebuild prepare
# ebuild mtpfs-0.9.ebuild configure
# ebuild mtpfs-0.9.ebuild compile
# ebuild mtpfs-0.9.ebuild install
# ebuild mtpfs-0.9.ebuild postinst
# ebuild mtpfs-0.9.ebuild qmerge
# ebuild mtpfs-0.9.ebuild clean

Once you have that completed, then make your mount point, and run the following to mount your Xoom:

# mtpfs -o allow_other /mnt/xoom

Everything should work perfectly.

Chive is a newer, lightweight SQL database manager comparable to phpMyAdmin. In essence, it is a web gui that allows you to complete all of your SQL needs without the hassle of dealing with the terminal. I can’t remember what I was doing, but I stumbled across Chive while I was playing around with Arch Linux, and really started liking its simplicity and speed. In fact, Chive was so much faster than phpMyAdmin that I canned it and started using Chive regularly.
There isn’t an ebuild in portage (or one of its overlays) yet, but it really isn’t that hard to install it either. I installed it in my webapps folder and created an additional alias in my http.conf, and it worked like a charn in Gentoo.

First things, make sure that your dev-lang/php has (at least) these use flags; apache2 curl gd gdbm json mysql pdo. If not, then re-emerge.

Next, as root, navigate to /usr/share/webapps and run the following command:

wget -O - http://launchpad.net/chive/0.4/0.4.0/+download/chive_0.4.1.tar.gz|tar -xzp

Lasly, add this to the end of /etc/apache2/httpd.conf:

Alias /chive "/usr/share/webapps/chive"

<directory "/usr/share/webapps/chive">
Options Indexes MultiViews
AllowOverride None
Order allow,deny
Allow from all
</directory>

To read more about Chive, check out their home page.

After wondering how difficult it would be to configure my own web server that could also handle mail, I decided to start a small project at home involving my desktop. I wanted to see if I could replicate the servers that I currently use to host this site, but on a much smaller scale in terms of hardware. Until now, I didn’t realize how simple it was to actually configure a server with apache, mysql, php, and roundcube (for webmail).

This post will cover how I configured my Arch linux desktop to function as a web server and webmail server. Arch linux has provided a detailed guide that was used and helped out greatly. Although it proved a great help, this post is a summary of it and a few other miscellaneous articles.

The basic requirements for a linux box to function as a web server are apache, sql and php.  In Arch linux, you can install the required packages using the following command:

Next, you will need to configure a couple of things. (Most of the packages come pre-configured, however, you will just need to verify the configuration.)  First, you need to make sure that your ‘HOSTNAME’ configurations match in both /etc/rc.conf and /etc/hosts.

Next, you will need to comment the following line in /etc/httpd/conf/httpd.conf (should be around line 91).

At the end of the LoadModule section (around line 121) add the following:

and add this line to the end of the Include section (around line 473):

This will get the basic functions in place to start your Apache server running PHP. This is in no way a secure setup, and you will need to make any additional changes to your httpd.conf and other security files to make your system more secure. To test your install, first start your services with:

# /etc/rc.d/httpd start

and then you need to make a simple index.php file in ‘/srv/http/’ and point your browser to http://localhost/.

A good example for a PHP page is the following:

The Next section will cover mysql, myphpadmin and roundcube webmail server setup.

I guess the newest update of usbmuxd (1.0.6) fixed the problems with KDE (or better defined, amarok) not able to see the iPhone 4′s music.  It was a little shocking when I plugged my iPhone in to charge it and to my surprise; amarok is displaying my phones music collection.  For some time, the device has been detected via lsusb, but this was definitely a delightful gift.  I didn’t change anything except run the normal ArchLinux updates and since the latest release of usbmux, there have been no other major updates in the libimobiledevice chain.  (I only assume it was the usbmuxd update because it was announced) Sadly, there is still no noticed progress on a write access to the file system.  Another interesting announcement was the release of “iTunes Filesharing” in the git master.  I will have to check this out and see if this allows the transfer of music.

Support for CAC readers in linux is out there, but isn’t advertised very well.  Additionally, I found that getting support for the new 144K CAC cards isn’t the easiest.  If you don’t already know, coolkey is now being replaced with cackey.  After talking with the developers of the new cackey software, I found that it wasn’t very easy to obtain their software.  So, in order to get the software, you needed a functioning CAC card and reader to log into their website, however, if you are stuck like I was, that was impossible since you need their software to get everything to work.  It was a horrible catch 22.  After obtaining a copy, I decided to load it up here so that I could share (and so that I didn’t delete the package and get stuck without it again).

It is fairly easy to set everything up, the only part that sucks is loading the certificates into your browser.  Their are a couple of plugins for Firefox that supposedly allow you to load certificates faster, however, I haven’t explored that far, I just manually added all of them myself.

First, download cackey (contact for a copy).  I would recommend creating a folder in your root directory to extract it in.  I use ‘/work/’ to compile all of my downloaded code.

Next, you need to make sure that you have the required files to get cackey to work. For gentoo…

# emerge -va ccid pcsclite

and for arch linux (ccid is in the AUR, so you need to use yoaurt or eqivalant)

$ yaourt -S ccid pcsclite

Next, you need to extract and install cackey.

# cd /work/

# ./configure && make && make install

After cackey is installed, you will need to point firefox to the cac reader. Open firefox, go to Edit, Preferences, Advanced and Encryption. Click on the Security Devices button. Click Load on the right hand side. You want to name the module “CAC Module” and you want to navigate to the libcackey.so file: “/usr/local/lib/libcackey.so”. (make sure the cac reader is plugged in before you load the module.

Now for the last (and most painful) part. You will have to load all of the certificates.

Go to http://dodpki.c3pki.chamb.disa.mil/rootca.html and click on all of the links to install the first set of certificates.

Next, go to https://crl.chamb.disa.mil/ and select the “ALL CRL ZIP” on the left hand window and download. Next, you need to extract that. Go back to firefox and click Edit, Preferences, Advanced, Encryption and click the View Certificates button.  Go to the Authorities tab, and click Import.  Navigate to where the certificates are and on the bottom right, there is a drop down to change the file extension to “All Files“.  You will have to import each one manually.  After you select one, click Open, and then click Okay.  Then repeat the process. (View Certificates, Import, etc…).  Once all have been loaded, then your 144K CAC Card should work.

If there are any questions, please ask.