General

Never know quite how to describe this 'migration' - it's the same old bits in the machine but I've built a new installation of FreeBSD onto a new HDD and am now putting this new 'server' (hdd!) into the old machine! Sounds pretty weak/easy maybe but it's taken me almost a month to get this done what with migrating various bits and bobs and tidying up crap along the way - together with a heavy dose of procrastination along with it all. Just managed to whittle the MySQL dbs down to about 25% of what they used to be, so many dbs and users that haven't used anything since 2003 or so!

Mind, not that it's active that much now, we're talking maybe a dozen users or so...

Anyway, still got a lot to do, the server is just about running now with the new HDD, managed to get named up and running along with apache, exim and mysql with all the data more or less migrated over now. There *will* be lots of problems with web services but that can wait for now, nothing that can't wait til tomorrow.

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:

bsdstats.org is a website aimed at gathering statistics on what type and version of BSD people around the world are using. The script can be installed from /usr/ports/sysutils/bsdstats, and is run via FreeBSD's periodic utility - so it gets run on a monthly basis.

One thought that springs to mind though is how fair this is on other BSD systems that don't have an inbuilt periodic utility - whilst it's easy enough to set this kind of thing up via a cronjob, it could skew the statistics somewhat if the method of installation isn't the same from one BSD to another. Still I guess it can only ever be a rough guide anyway... will install it anyway I think.

Ok, just installed it, the output from the install looks like this:

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.

Nothing Unix related is simple and straightforward - hey that's what we love about it right? I went about finding out why the formatting in my mutt manual.txt was so screwy and it appears the mutt build process on FreeBSD creates the text manual incorrectly. Ok fair enough, so I look into fixing it up and hey, great, I have to tussle with SGML once again... -sigh-

So I'm looking for a tool called 'sgml2html' which is apparently required to build the manual.txt file from the master manual.sgml file and by all accounts the utility has been outdated by the SGML Tools suite. Ok fair enough. So I go to install sgmltools from the ports and there's a bunch of dependencies as long as your arm - and that's just for the sgmltools-lite package!!!

Ho hum... as I type this the darn thing is -still- building, 5-10 minute later...

If anyone knows of any decent resources for learning SGML - especially docbook - it'd be great to hear about it. :P