FreeBSD

Well after having been on FreeBSD 4.x for as long as I can remember (4years now I guess), it's finally time to move to FreeBSD 6.x! For ages I've been saying as soon as I get a larger HDD I'd upgrade the system and santa kindly delivered a shiny new 250Gb Maxtor DiamondMax 10, so it's time to sort it out and make the move.

Funny now I think about it, for me upgrading to a larger capacity HDD has always been a fairly rare occasion. Back in 2000 or so I remember moving from a measily 1.6Gb to a whopping 20Gb HDD and thinking that was way too much. In a way it's a good thing to not have a lot of space - it makes you more tidy and less likely to spam crap all over the filesystem. Of course on the other hand not having a lot of space also sucks if you want to store a lot of stuff (duh). This is kind of how it's been with my FreeBSD server for the last 4yrs or so - I've only had a 40Gb drive and in that time I've hosted over 100 users at the same time, dozens of domains, ran a load of services, and never really had a lot to complain about re lack of space. The main reason for the change I guess is the increased use of broadband/bittorrent which I really need more space to save files to disk for.

I'm gonna document the filesystem layout of the new HDD here, no doubt it'll only be me that ever reads this again (and you if you're reading this heh :o).


File System Layout
I spent quite a while thinking about how best to partition/slice up the new 250Gb disk, mainly because my server is running 24/7 and various applications really do kane the filesystem when accessing data (ie apache and mysql for two). I want to try and partition the disk so that it's more efficient for apache and mysql to read/write from/to the disks.

The other deliberation I went through whilst thinking about the file system layout was where to mount partitions for backups, music, videos and windows application installers. Of course this could be anywhere really - /backups /music /videos /windows for example - but I don't really like spamming the root level filesystem with lots of folders that only add clutter.

I had a quick look at the Filesystem Hierarchy Standard which is a standard aimed at encouraging clean and consistent filesystem layouts on Unix type OSs and eventually ended up with the following layout:

The locate utility on linux was one of the first tools I hit when I made the move to FreeBSD a few years back - knowing where files are is half the battle when you're trying to configure things and find documentation on how to do it. The trouble with locate though as jdarnold mentions in his article 'Locate This!' is that if you build the locate database as 'root', you end up exposing everything to any user that runs the locate command. The other problem he mentions is the locate db is only updated weekly on FreeBSD by default via the periodic system which isn't really enough if you use your system regularly.

I remember thinking along the same lines a while back and after reading through the man pages the solution I found was to create two separate databases - one for root and one for regular users. The 'regular' db is updated on a weekly basis as per the default on FreeBSD via periodic, whereas the other 'root' locate db is built daily in a crontab so I can get the latest up to date details on which files are where.

To get the root db built first you need to create a crontab entry - i put this in /etc/crontab:



This tells the locate.updatedb script to use a separate configuration file - /root/locate/conf/locate.rc - for building root's locate db. The content of /root/locate/conf/locate.rc look like this:



which indicates that this db should be built in /root/locate/db/locate.database.root instead of the default locate in /var/db/locate.database. You can safely run the command as root on the commandline to initialize your new db:



Once the database is built you can move on to test the new db works ok:



This file is only readable by root, so it seems to work ok.


To make things easier, add a shell alias in root's .cshrc file aliasing 'locate' to the command 'locate -d /root/locate/db/locate.database.root':



With the "-d /root/locate/db/locate.database.root" switch, locate will use the db at /root/locate/db/locate.database.root instead of the default /var/db/locate.database and root will be able to use locate to find any files in the filesystem, not just those that are world readable.


Finally, one way to update the regular locate db as root but without making it list every world readable file is to perform the following:



This is basically what the 310.locate periodic script does and results in a locate db that contains only files that are readable by the 'nobody' user - essentially all 'world readable' files.

Comparing the sizes of the root db against the nobody db:



You can see the size difference there, not as many entries in nobody's db as root's. Just to double check:



So from that you can see that 'nobody' can see the ktrace.out files located in /root - apart from root of course :) Sorted.

Just read an interesting article about the addition of 'Security Event Auditing' in FreeBSD 6.2. Until now FreeBSD hasn't had any really useful security auditing other than using 'accounting' to log all syscalls which at best was confusing when it came to working out who did what when and how.

At one time I installed a kernel module lrexec to log all system exec calls, but this was also quite a handful to configure scripts so they reported only on certain users. Hopefully this new security auditing daemon will make security auditing a lot easier on FreeBSD.

Read the article for more info on what's new:
Security Event Auditing in FreeBSD 6.2

Also of interest is the new addition to the FreeBSD handbook on security auditing:
FreeBSD Handbook: Security Event Auditing

I just went to upgrade Samba to the latest FreeBSD port release - 3.0.23c. The portupgrade went smoothly but when I went to restart the samba daemon, I found I was locked out of the network shares on the FreeBSD machine when trying to login/access them from Windows.

Reading in /usr/ports/UPDATING revealed the problem:



The location of the samba password dbs changed! Small sigh of relief, moved the db files over and everything worked as normal.

Pays to read /usr/ports/UPDATING!

parsepath.pl is a brilliant perl script for fixing permissions problems on Unix based platforms by Jeremy Mates. Probably the most common type of permission problem from a sysadmin/webmaster's viewpoint is uploading a file to a directory in a website's document root folder and then trying to access the file or script in a web browser only to get the dreaded 403 error message:

Forbidden
You don't have permission to access /foo/bar/test.php on this server.

Most time the solution is very simple, just change the permissions on 'test.php' to make sure the user the webserver runs as can read the file correctly - the simplest and most common method being to change the mode of the file to '755':



Unfortunately sometimes it's not that easy and many times you see users asking 'I'm getting 'access denied' errors even though I've changed the perms to 755'. The problem is that one of the subdirectories that the 'test.php' file lives in has permissions set so that the webserver can't read the file properly. Now that's where the headache comes in :)

However, parsepath.pl can take the headache out of fixing permissions problems.

Say you have a website document root directory tree /usr/local/www/web/www.munk.me.uk/foo/bar and you upload a web script 'test.php' into that directory. You try and access the file in a webbrowser but get the 403 permission denied error above. First off you check the permissions on the file itself:



That looks ok, with permissions 755 and the owner/group set to 'www' the webserver user 'www' should be able to read the file ok. So in this case the problem must be with the permissions on one of the parent subdirectories. The old method of working out the perms would be either to trawl one by one through each directory checking the perms on each subdirectory or to change the permissions recursively on the document root folder so all subfolders have the read bit set for the webserver user/group.

With parsepath.pl things are a lot simpler though - just run the following command:



With this command parsepath.pl recurses through each subdirectory below the file/path you feed it on the commandline and tells you the permissions problems - if any - for the user 'www' (the user=www argument) to read (the +r argument) the file 'test.php'.

In the output, we're told that permissions to read the test.php by the user www fails on two counts:



With this information it's easy enough to go in and make the changes necessary to fix the problem using 'chmod g+rx foo foo/bar'.

There are other ways of invoking parsepath.pl though. Running it just with a file/path as an argument it'll tell you the permissions on each subdirectory under it:



which can is better to see a whole tree in one go.

No permissions were harmed in the making of this article!


I'll include the parsepath.pl script in the extended article just in case the original ever gets lost - big credit of course goes to the author of the script, Jeremy Mates. His site is actually very interesting from a sysadmin's point of view containing lots of interesting admin scripts and thoughts on system administration in general - spent quite a while grazing through his stuff there - cheers Jeremy.