Like one of those B-24 bombers that would come back with sunlight showing through the wings where they caught flak, Old Ironsides is a resilient machine. Laying it flat so the fan would sit on top of the CPU by virtue of gravity and replacing the CMOS battery brought it back to life long enough for some thorough data recovery. But it's been drawing a lot of power, about 60-80 Watt, and maintaining the ports and whatnot had become a bit of a chore.

So this accident gave me the excuse to get me a nicer, greener setup: the Intel D510MO motherboard in an In-Win BP655 case with 2G of DDR2 RAM, a 500GB HD, and a CD-DVD drive, because paying $25 is much more pleasant than trying to install an OS off a USB stick. The lot cost about $260 at Intrex Computers down the road.

Not wanting to throw away all that Unix human capital I accumulated over the past three years, I dug around for a compromise between ease of use and FOSS, and found Amahi, via Webmonkey. By the way, do you know how old Webmonkey is? That's where I learned HTML in 1997, at least that old. Many happy returns, whenever its birthday is.

Amahi works. It runs on Fedora 12 for now, but the Fedora 14 edition is in alpha testing and anyway there's nothing wrong that I can think of with Fedora 12, once you do yum -y update on it. Amahi has everything I want, and while VNC did take me some fiddling, it was nothing compared to having to configure every little service by hand like I had to do with FreeBSD. I didn't complain at the time, it was educational, but the novelty wore off right away.

On the recommendation of my friend Bálint Érdi, I signed on with Dropbox, and I figured one good use of it would be to keep my vimrc files in sync across three virtual Linux computers I'm having to use.

So, I went looking for the originals -- the Vim configuration files on the Linux Mint 8 VM that I am using now. Except I didn't go straight to the VM. I took a detour through Chrome, and typed this in the address box: "where is .vimrc". That got me here, which is a comment thread that happened six years ago.

Of course, the answer is trivial: # locate vimrc. That's UNIX love right there. If you want to find a file, just locate it. If you're the almighty root (#), the computer will fetch it without a fuss. But the more fascinating bit is a little further below, posted by the user Wolfbone:

.foorc = runtime configuration file for programme "foo" located in user's home directory.

/etc/foorc (if it exists) = global (all users) runtime configuration file for programme "foo", overridden by .foorc, if it exists.

Suggesting to someone who cannot find an 'rc' file that '#locate vimrc' is a useful command is not very helpful.

I had no idea that vimrc was called that in order to respect this [r]untime [c]onfiguration naming convention. I also had no idea that the ~/.foorc files are there to override /etc/foorc files. Sounds like an architecture thing. I am guessing that the common use is that your IT guy will put configuration files in /etc/foorc, and if you like those, fine. If you don't, just make up your own .foorc files and stick them in the home folder. Neat, but it gets even better.

If you run this # locate vimrc command, it'll turn up /etc/vimrc.local. If you then cat vimrc you can see that it defers to vimrc.local if it exists. So, there are two available layers of configuration overrides: first is /etc/vimrc.local, then ~/.vimrc, which reigns supreme. What's the use of that? And how is this implemented in FreeBSD? My initial guess was that the FreeBSD convention is that rc is a file extension, as in mail.rc. But then in the /etc folder I also saw things like rc.firewall. And in /usr/local/etc I saw things called ddclient.conf. What's different between files that start with rc., or end with .rc, or end with .conf?

So many questions, so little time. Still, this is better than my experience with Windows, where things either just work (thank you, Windows 7) or they're so arcane that, if I ever attempt them, it's always on guts alone. I have no theory whatsoever of what might go wrong.

A couple of days ago PuTTY started to demand password authentication, which it shouldn't, because I normally log in with a public-private key pair. That was a good excuse to refresh my keys anyway, so I generated a new pair and overwrote the authorized_keys file. I hoped, again and without any basis in reason or logic, that the problem would go away as quietly as it turned up. It did not.

Fiddling with /etc/ssh/sshd_config didn't help either. What did help was fixing the home directory permissions: doing ls -l /usr/home as a super-user showed soon enough that they were drwxrwxr-x, when they should have been drwr-xr-x at a minimum. I can't remember when I changed them or why, but the problem is fixed with chmod 755 /usr/home/username. That this was indeed the fault of loose permissions was confirmed by a quick examination of /var/log/auth.log. The idea to look there came from here. Some further clarifications on ssh, including a sample config file, are available here.

The other thing I learned from /var/log/auth.log is that I am getting hit by a flood of unauthorized login attempts from the weirdest places every day. So far, so good.

Take good notes, for one. While dabbling in an unrelated topic -- I was investigating how to enable wake-on-LAN for this machine -- I found a reference to a command I never knew existed: psearch. It's a port and I didn't have it installed, but whereis psearch led me to it quickly enough, and then it was just a matter of make install clean. Now, back to the portaudit problem: psearch libtool found the buggy port immediately: devel/libtool22.

I wasn't sure that this quick note was worth a post, so I left it in the drafts folder. But today's portaudit revealed multiple vulnerabilities in php5. Fixing that is in progress. Meanwhile I thought I'd post this thing after all, so I'll have a quick way to jog my memory next time I go looking for a well-hidden port.

One annoying thing is that I'm still unclear on when to use portupgrade -r, portupgrade -R, or portupgrade -rR. My default is the latter because I find it comforting that these recursive upgrades take care of all sorts of dependencies for me, both up and down stream. But man does it take a long time. That Pentium III is showing its age. It'd be good if I could safely cut some corners. So, dear readers, please comment away. I am curious.

FreeBSD, for example, will sometimes turn up a damaged package or two in response to #portaudit. The procedure for that, according to the relevant chunk of the FreeBSD Handbook is that you only need #portsnap extract when you run #portsnap fetch for the first time. After that, you already have a ports tree on your system, and all you need is #portsnap update.

Had I remembered that, I wouldn't be sitting here writing this post while my ports tree is rebuilding itself for no good reason. On the same topic (of things to remember): according to the same FreeBSD Handbook, I should run #pkgdb -F once in a while, pretty much before every #portupgrade. An overview of what that does is here.

Suppose you don't want to do that. Suppose you just want to get the code all in the same directory structure on your local machine, and only the code, not the associated html files that make it render in a browser. In that situation, you can do this:

wget -r -np -nH -R "*.html*" http://www.sobell.com/UB2/code/

Recursive downloads with wget are discouraged because they hit the web server hard with a fast succession of requests. But I think the example above is a case of polite wget use: it only downloads what the original host of the code intended to make available for downloading. The -r part means "recursive". The -np part means "but not upwards". The -nH part means "and do not visit any hosts referenced here". Finally, the -R "*.html*" part means "and I don't want any file with .html in it".

As it turns out, wget can do a lot of things, so its man page is rather long. I googled around for a more concise reference, and I found this. Enjoy.

The UNIX equivalent to this would be rsync. Cygwin comes with it. In FreeBSD you can install it from ports:

portsnap fetch update
whereis rsync
cd /usr/ports/net/rsync
make install

Then, assuming that you have ssh access with a key pair to your server, all you need to do is this:

rsync -avzu [username]@example.com:[yourfolder] /cygdrive/g/[yourlocalmirror]

A simple ls /cygdrive in Cygwin will tell you what letter corresponds to your external hard drive. In my case it's g. I back up this web site to a WD MyBook with rsync. My wife uses SyncToy to back up her Vista notebook to her Samba share on our FreeBSD home server.

Now: if you do not have ssh access to your UNIX server yet, see my earlier notes for setting up OpenSSH on FreeBSD, or buy the book. For Linux, see here. If rsync fails on the first run with some cryptic message that includes "error in rsync protocol data stream (code 12)" just check the file permissions.  That fixed it for me.

There are several pieces to this. Let's say your UNIX machine runs FreeBSD. If so, you're in luck. You can install OpenSSH using instructions from here or here. Then you can install Subversion. Instructions for that are right here. Now you need to get TortoiseSVN to talk to it from your Windows machine. Instructions for that are here.

Now here's what didn't work, and how I fixed it: as soon as I had everything in place, I went to the first random Windows Explorer entry and right-clicked it so I'd get to the TortoiseSVN menu, then Repo-browser. I was anxious to browse this:

svn+ssh://gabi@192.168.10.2/usr/home/svn/repos

But I was out of luck. By default, TortoiseSVN uses TortoisePlink to connect to a UNIX box. This simply is a version of Plink that will not open a command line, because you don't need one. Normally, this works. For me it didn't. First, it kept inviting me over and over again to enter my user name. This is a known problem and it has a solution, but I did not like it. Then I tried to set PuTTY as the ssh client (as explained further down below), but then my connection to the server would close immediately, as if the ssh daemon had rejected my credentials.

So, first I logged into the FreeBSD with PuTTY to make sure that my key worked. Then I opened Cygwin and ran

svn list svn+ssh://gabi@192.168.10.2/usr/home/svn/repos

This was to make sure that I actually did have access to the Subversion server through the svn+ssh:// protocol. When this returned the list of directories I had added yesterday from the Ubuntu box, I knew that all was well, and the trouble was contained to TortoiseSVN.

It was actually contained to the PuTTY default settings. TortoisePlink can establish a PuTTY session if the default settings contain the path to the private key. If you just installed PuTTY and established a named SSH connection that works (as explained here), then you know that you have a working key and you know where it is, but your default settings are still pristine. Let's call this named SSH connection MyConnection and let's suppose that you also saved an "Auto-login username" to go with it (that's in Connection -> Data; refer back to the instructions if needed).

Now "Load" the Default Settings just to make sure that all the boxes are cleared. Then in the left pane navigate to SSH, then to Auth. Then, in the "Private key for authentication" text box, browse to where you stored your .ppk file. Next, "Save" your Default Settings. They're now as empty as before, with the one exception of the path to the .ppk file. This worked for me. I was able to browse my existing repository both via

svn+ssh://gabi@192.168.10.2/usr/home/svn/repos

and via

svn+ssh://MyConnection/usr/home/svn/repos

Finally, to ensure that TortoiseSVN uses its own TortoisePlink as a ssh client, find the Settings entry at the bottom of the TortoiseSVN menu in Windows Explorer. Then go to the Network tab, and check that the "ssh client" box is empty. This, by the way, is where you could set the ssh client to PuTTY instead, if you wanted to, but that did not work for me.

I installed SmartSVN on the Ubuntu box and declared a new repository with a svn+ssh:// protocol. I figured it would make sense, since I connect to the server through a ssh tunnel with authentication key files. I was right. SmartSVN connected to the server without a hitch. Then I tried svn://, http:// and https://. None of them worked. The latter two require some extra module (WebDAV?) enabled in the Apache server. I don't know much about any of it, so I figured I'd just stick with svn+ssh:// and be done with it.

Then my first commit attempt promptly failed, with a message that a certain lock file could not be opened.

That looked like a file permissions issue to me. In FreeBSD, the /etc/group file lists the group names, ID's and members. I had a group named svn present already, so I added my name to the member list and saved over. Now whatever that group's permissions needed to be, I was going to be in on them.

Then, as root, I did this:

chown -R gabi:svn /usr/home/svn/repos

OK, so now I own the files in any sub-directories of the repository, and the group permissions will apply to the svn group. I set them like so:

chmod 775 /usr/home/svn/repos/hooks
chmod 775 /usr/home/svn/repos/locks
chmod 775 /usr/home/svn/repos/db

It worked. I could commit a folder with some example text file in it. Then I changed it and updated it, and then I made a different working copy and caused a conflict, so I would have something to resolve. All of that worked as advertised. There are a few things left to do, like branching, tagging, merging, and reverse and forward integration. I'll write more as I go through the learning process, but before I close this post I have to mention this neat little post. It's a better introduction to how version control works and why it's done than even Chapter 1 in the Subversion book, which is great, so that's saying something. Better explained, indeed. I'd never heard of them. All hail Google, again.

And now my Stata code can go under proper version control. Life's good.

As in Samba's case, there are some changes to be made to the server, and some to the client. I want to share files across all the computers on my home network. The usual wild card for multiple client computers is [network gateway IP]/[mask]. I use my own network gateway IP, 192.168.10.0, as an example. Different router makers use different numbers after the 192.168 part. The mask is 255.255.255.0.

There are four main steps to setting up NFS on the server side. First you enable packet filtering, then you edit three system files: /etc/exports, /etc/hosts.allow, and /etc/rc.conf.

The first step, enabling packet filtering, has three sub-steps of its own, detailed below.

First, you write an /etc/pf.conf file. I wrote mine using Ian Robinson's instructions posted here:

# my /etc/pf.conf file
# /24 in 192.168.10.0/24 is equal to saying the netmask is 255.255.255.0
# 1. define macros for local network NIC and IP address
nic_1 = "fxp0"
lan = "192.168.10.0/24"
# 2. write pf commands to pass all traffic to and from local network
# the macros from above are used and are prefixed with a "$"
pass in on $nic_1 from $lan to any keep state
pass out on $nic_1 from $lan to any keep state

Second, you edit /etc/rc.conf with this line:

pf_enable="YES"

Third, you start the pf daemon:

/etc/rc.d/pf start

You can check that your packet filtering rules are live:

pfctl -sr

If you already had packet filtering, and instead of writing an /etc/pf.conf file from scratch you just had to edit your existing one, then you will skip the two steps above and instead activate your new rules like so:

pfctl -nf /etc/rc.conf // this is to check the edited file for problems
pfctl -f /etc/rc.conf // to activate the new rules, remove the -n flag

That's it for packet filtering. Next, write your /etc/exports file. I wanted to make my server home directory /usr/home/gabi available to the root user of any client computer on my home network. So, my /etc/exports file looks like this:

/usr/home/gabi -network 192.168.10 -mask 255.255.255.0

There is an extra option you could add at the end of the line above. You can direct the root user of the client server to adopt the server privileges of any user registered there, based on that user's ID number (known as UID in the manual's parlance). For example, typing -maproot=1001 at the end of the line will give the root user on the client computer the privileges of the user identified on the server by the UID 1001. This is useful, for example, if you want to grant the remote user specific server privileges. By default, FreeBSD is conservative: not using a -maproot instruction will map the remote user to nobody:nobody. As you might have guessed, this guy can't do much. We'll get back to this part later.

Moving on to step 3: adjust the /etc/hosts.allow settings. This amounts to letting a few daemons loose on the local network and restricting them everywhere else:


rpcbind : 192.168.10.0/255.255.255.0 : allow
rpcbind : ALL : deny
portmap : 192.168.10.0/255.255.255.0 : allow
portmap : ALL : deny
mountd : 192.168.10.0/255.255.255.0 : allow
mountd : ALL : deny
statd : 192.168.10.0/255.255.255.0 : allow
statd : ALL : deny

The fourth and final step is to edit /etc/rc.conf to enable these daemons:

rpcbind_enable="YES"
nfs_server_enable="YES"
mountd_flags="-r"
rpc_lockd_enable="YES"
rpc_statd_enable="YES"


On the client computer things are easier. Ubuntu comes with the wonderful Synaptic Package Manager (in Gnome, find it in the System/Administration menu). Search for the string "nfs" and mark the packages "nfs-common" and "portmap" for installation. Synaptic will suggest some dependencies and ask for permission to install some other packages as well. Let it.

That's all. Now in a terminal window on the client you can set up a mount point, e.g.

$ mkdir ~/from_server

And then you can mount any of the server directories listed in your /etc/exports file onto it, like so:

$ sudo mount your_server_IP:/your/remote/directory /home/you/from_server


Note that Ubuntu, by default, does not come with a root user. Instead, the user who installs the Ubuntu OS is granted some administrative privileges that make him/her a kind of quasi-root. This is to make Ubuntu systems safe for beginner UNIX-ers. The -maproot=UID directive can work with that. Leaving the /etc/exports file without a -maproot=UID instruction showed the content of my /usr/home/gabi folder on the FreeBSD server in the /home/gabi/from_server mount point on the client computer but the files were read-only. On the other hand, adding "-maproot=UID" to the last line of the /etc/exports file on the server did what I wanted: the Ubuntu user gabi received the same rights to the /home/gabi/from_server folder on the client as the FreeBSD user gabi had to the /usr/home/gabi folder on the server. In other words, I now can read/write/navigate my server home directory as if it were on my client computer.