freebsd.munk.me.uk - FreeBSD

Moving munk.me.uk to a new HDD - filesystem layout

nospam@example.com (munk) — Fri, 05 Jan 2007 14:25:00 +0000

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:

CODE:

G=Gigabytes

fdisk:
======

Name        Size                Partition Type
====        ====                ==============
ad1s1        59G                freebsd
ad1s2        89G                freebsd
ad1s3        49G                freebsd
ad1s4        33G                freebsd

disklabel:
==========

Partition    Mount              Size (approx.)
=========    =====              ==============
ad1s1:
------

ad1s1a        /                 0.5G

ad1s1b        swap              2G

ad1s1d        /tmp              1G

ad1s1e        /var/db/mysql     20G

ad1s1f        /var/www          10G

ad1s1g        /var/             10G

ad1s1h        /usr              20G

ad1s2:
------

ad1s2d        /home             40G

ad1s2e        /var/backups      50G

ad1s3:
------

ad1s3d        /var/media        50G

ad1s4:
------

ad2s4d        /var/win32        35G

Let root see all files with locate

nospam@example.com (munk) — Sat, 18 Nov 2006 10:38:40 +0000

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:

CODE:

39 2 * * * root env -i LOCATE_CONFIG=/root/locate/conf/locate.rc /usr/libexec/locate.updatedb > /dev/null 2>&1

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:

CODE:

FCODES="/root/locate/db/locate.database.root"

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:

CODE:

root@users /root# env -i LOCATE_CONFIG=/root/locate/conf/locate.rc /usr/libexec/locate.updatedb

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

CODE:

root@users /root# locate -d /root/locate/db/locate.database.root .cshrc.root
/root/.cshrc.root

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':

CODE:

root@users /root# grep locate $cshrc
alias locate 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:

CODE:

#!/bin/sh
# make sure db file exists:
touch /var/db/locate.database

# then change ownership to the nobody user:
chown nobody /var/db/locate.database

# make it writeable by nobody and readable by everyone else:
chmod 644 /var/db/locate.database

# then move on to update the db...
# first make sure we're in the / folder where the db update starts:
cd /

# then finally run the updatedb command as the 'nobody' user:
echo "/usr/libexec/locate.updatedb" | su - -fm nobody

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:

CODE:

root@users /# ls -al /var/db/locate.database /root/locate/db/locate.database.root
-rw-r--r-- 1 root wheel 4070484 Nov 18 02:45 /root/locate/db/locate.database.root
-rw-r--r-- 1 nobody wheel 3280409 Nov 18 11:41 /var/db/locate.database

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

CODE:

root@users /root# locate .cshrc.root
/root/bin/ktrace.out
/root/ktrace.out
/usr/local/etc/snort/ktrace.out
root@users /root# echo "locate ktrace.out" | su - -fm nobody
/usr/local/etc/snort/ktrace.out

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

FreeBSD 6.2 To Include Security Event Auditing

nospam@example.com (munk) — Tue, 14 Nov 2006 16:38:39 +0000

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

Samba Upgrade to 3.0.23c and Login Failures

nospam@example.com (munk) — Tue, 05 Sep 2006 20:10:02 +0000

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:

CODE:

20060904:
  AFFECTS: users of net/samba3
  AUTHOR: timur@gnu.org

  Reviosion of Samba 3.0.23c port had changed location of the directory,
  where Samba stores it's smbpasswd files from $PREFIX/private to a more
  common $PREFIX/etc/samba.

  You need to move *.tdb files from an old to new location and remove old
  directory if you use tdbsam backend for Samba user authentication.

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!

Solving permission problems with parsepath.pl

nospam@example.com (munk) — Mon, 04 Sep 2006 22:41:00 +0000

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':

CODE:

chmod 755 test.php

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:

CODE:

[23:58:17] root@users /usr/local/www/web/www.munk.me.uk/foo/bar# ; ls -l
total 0
-rwxr-xr-x 1 www www 0 Sep 4 23:39 test.php

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:

CODE:

[0:03:21] root@users /usr/local/www/web/www.munk.me.uk/foo/bar# parsepath.pl user=www +r test.php
! group=www +rx fails: d 0700 root:www /usr/local/www/web/www.munk.me.uk/foo
! unix-other +rx fails: d 0750 root:wheel /usr/local/www/web/www.munk.me.uk/foo/bar

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:

CODE:

# the group bit on the folder 'foo' doesn't have the +rx flag set:
! group=www +rx fails: d 0700 root:www /usr/local/www/web/www.munk.me.uk/foo

# the other bit on the folder 'bar' doesn't have the +rx flag set:
! unix-other +rx fails: d 0750 root:wheel /usr/local/www/web/www.munk.me.uk/foo/bar

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:

CODE:

[0:10:33] root@users /usr/local/www/web/www.munk.me.uk/foo/bar#
> parsepath.pl /usr/local/www/web/www.munk.me.uk/foo/bar/test.php
% /usr/local/www/web/www.munk.me.uk/foo/bar/test.php
d 0755 root:wheel /
d 0755 root:wheel /usr
d 0755 root:wheel /usr/local
d 0755 root:wheel /usr/local/www
d 0770 www:wheel /usr/local/www/web
d 0750 www:www /usr/local/www/web/www.munk.me.uk
d 0700 root:www /usr/local/www/web/www.munk.me.uk/foo
d 0750 root:wheel /usr/local/www/web/www.munk.me.uk/foo/bar
f 0755 root:www /usr/local/www/web/www.munk.me.uk/foo/bar/test.php

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.

Continue reading "Solving permission problems with parsepath.pl"

Snort upgrade to 2.6.0 fails in make build on FreeBSD 4.11

nospam@example.com (munk) — Sat, 02 Sep 2006 18:12:54 +0000

UPDATE:
Yay this is now fixed, seemed to be a fairly simple solution too. All good!

http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/102922

A few days ago I went to upgrade snort to the latest version (from 2.4.5 to 2.6.0) and it failed at the 'make build' stage. I've just had a chance to look into the problem and it appears to be to do with the build of the dynamic rule processing functionality. A temporary workaround is to build snort with the '-DWITHOUT_DYNAMIC' flag on FreeBSD:

CODE:

cd /usr/ports/security/snort
make -DWITHOUT_DYNAMIC clean install

Hopefully a full fix will be found in the next few weeks. I'm about to submit a problem report (PR) once the maintainer's had a chance to look it over, I'll cc it to the snort-users mailing list as well in the hope someone there will have a better idea what the problem is.

The PR is included in the extended article.

Continue reading "Snort upgrade to 2.6.0 fails in make build on FreeBSD 4.11"

Rolling back the ports tree to an earlier time

nospam@example.com (munk) — Sat, 02 Sep 2006 16:41:13 +0000

Upgrading a port can be a real annoyance when it turns out the upgraded port doesn't actually work too well or has bugs that make it unusable. This has happened to me on a number of times and I've resorted to 'rolling back' the port to an eariler version / date that I know will work ok.

In essence you simply roll back the ports tree to an earlier date in time using cvsup's date tagline in the cvsup ports supfile you use:

CODE:

# One day ago:
*default date=2006.09.01.00.00.00

This way when cvsup fetches the ports tree, the tree that was in place at the date specified will be grabbed instead of the current most up to date tree.

Of course this has the problem of reverting *all* ports to the earlier date, so another cvsup would be required without the 'date' tagline in the supfile to bring the ports tree back up to the current date.

Other options to avoid clobbering the whole ports tree:

Modify the 'prefix' tagline in the cvsup file to be different to /usr/ports:

CODE:
*default prefix=/tmp/usr

This will set cvsup to download the old ports tree into /tmp/usr/ports and from there you can copy over the particular port you're interested in into /usr/ports.
Use cvsweb to work out which files changed since the port last worked correctly and download the known working good files into the port's directory. Rebuilding the port from those files should do the trick to get the port rolled back. In fact it might be easier to use the excellent FreshPorts site to see more easily which files were touched since the last known working good version of the port.

This article has lots of advice on rolling back ports:

Rolling back ports to an earlier time

FreeBSD Security Advisory - Boundary checking errors in syscons

nospam@example.com (munk) — Tue, 05 Oct 2004 00:18:07 +0000

Another freebsd related sec advisory, only applicable to admins who have users who login to FreeBSD systems locally - ie on ttyv* local consoles.

CODE:

=============================================================================
FreeBSD-SA-04:15.syscons                                    Security Advisory
                                                         The FreeBSD Project

Topic:          Boundary checking errors in syscons

Category:       core
Module:         sys_dev_syscons
Announced:      2004-10-04
Credits:        Christer Oberg
Affects:        FreeBSD 5.x releases
Corrected:      2004-09-30 17:49:15 UTC (RELENG_5, 5.3-BETA6)
               2004-10-04 17:04:25 UTC (RELENG_5_2, 5.2.1-RELEASE-p11)
CVE Name:       CAN-2004-0919
FreeBSD only:   YES

For general information regarding FreeBSD Security Advisories,
including descriptions of the fields above, security branches, and the
following sections, please visit
<URL:http://www.freebsd.org/security/>.

I.   Background

syscons(4) is the default console driver for FreeBSD.  Using the
physical keyboard and screen, it provides multiple virtual terminals
which appear as if they were separate terminals.  One virtual terminal
is considered current and exclusively occupies the screen and the
keyboard; the other virtual terminals are placed in the background.

II.  Problem Description

The syscons CONS_SCRSHOT ioctl(2) does insufficient validation of
its input arguments.  In particular, negative coordinates or large
coordinates may cause unexpected behavior.

III. Impact

It may be possible to cause the CONS_SCRSHOT ioctl to return portions of
kernel memory.  Such memory might contain sensitive information, such as
portions of the file cache or terminal buffers.  This information might
be directly useful, or it might be leveraged to obtain elevated
privileges in some way.  For example, a terminal buffer might include a
user-entered password.

IV.  Workaround

There is no known workaround.  However, this bug is only exploitable
by users who have access to the physical console or can otherwise open
a /dev/ttyv* device node.

V.   Solution

Perform one of the following:

1) Upgrade your vulnerable system to the RELENG_5_2 security branch
dated after the correction date.

2) To patch your present system:

The following patches have been verified to apply to FreeBSD 5.2
systems.

a) Download the relevant patch from the location below, and verify the
detached PGP signature using your PGP utility.

# fetch ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/patches/SA-04:15/syscons.patch
# fetch ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/patches/SA-04:15/syscons.patch.asc

b) Apply the patch.

# cd /usr/src
# patch < /path/to/patch

c) Recompile your kernel as described in
<URL:http://www.freebsd.org/handbook/kernelconfig.html> and reboot the
system.

VI.  Correction details

The following list contains the revision numbers of each file that was
corrected in FreeBSD.

Branch                                                           Revision
Path
- -------------------------------------------------------------------------
RELENG_5_2
src/UPDATING                                                 1.282.2.19
src/sys/conf/newvers.sh                                       1.56.2.18
src/sys/dev/syscons/syscons.c                                 1.409.2.1
- -------------------------------------------------------------------------

VII. References

<URL:http://cvsweb.freebsd.org/src/sys/dev/syscons/syscons.c.diff?r1=1.428&r2=1.429>

FreeBSD Security Advisory - Various CVS Server Related Vulnerabilities

nospam@example.com (munk) — Mon, 20 Sep 2004 16:19:31 +0000

I. Background

The Concurrent Versions System (CVS) is a version control system. It
may be used to access a repository locally, or to access a `remote
repository' using a number of different methods. When accessing a
remote repository, the target machine runs the CVS server to fulfill
client requests.

II. Problem Description

A number of vulnerabilities were discovered in CVS by Stefan Esser,
Sebastian Krahmer, and Derek Price.

. Insufficient input validation while processing "Entry" lines.
(CAN-2004-0414)

. A double-free resulting from erroneous state handling while
processing "Argumentx" commands. (CAN-2004-0416)

. Integer overflow while processing "Max-dotdot" commands.
(CAN-2004-0417)

. Erroneous handling of empty entries handled while processing
"Notify" commands. (CAN-2004-0418)

. A format string bug while processing CVS wrappers.

. Single-byte buffer underflows while processing configuration files
from CVSROOT.

. Various other integer overflows.

Additionally, iDEFENSE reports an undocumented command-line flag used
in debugging does not perform input validation on the given path
names.

III. Impact

CVS servers ("cvs server" or :pserver: modes) are affected by these
vulnerabilities. They vary in impact but include information disclosure
(the iDEFENSE-reported bug), denial-of-service (CAN-2004-0414,
CAN-2004-0416, CAN-2004-0417 and other bugs), or possibly arbitrary code
execution (CAN-2004-0418). In very special situations where the
attacker may somehow influence the contents of CVS configuration files
in CVSROOT, additional attacks may be possible.

See the extended article for the complete advisory.

Continue reading "FreeBSD Security Advisory - Various CVS Server Related Vulnerabilities"

Advanced FreeBSD last Command

nospam@example.com (munk) — Tue, 24 Aug 2004 06:00:10 +0000

Most Unix/BSD/Linux type systems have a 'last' command that allows you to see easily who was last logged into the server. See here for an overview of FreeBSD's last command.

The last command relies on getting it's information from the wtmp file - usually stored in /var/log/wtmp. This means that when the wtmp file is rotated, issuing a last command will only display login details since the time wtmp was rotated last. This can be annoying when you need to find out all the times that a user was logged in last - over the last few years say, not just over the last few days.

As a solution to this problem I wrote a simple shell script to display last information not only based on the current wtmp file, but also from backed up wtmp files as well. The help output looks like this:

CODE:

[6:55:28] root@users /opt# last_all
last_all [-a|-l]
Display last login information.
-a Display all last login info on record
-l Display the last login dates per user

See the extended entry to view the script.
Continue reading "Advanced FreeBSD last Command"

Server has a hissy fit

nospam@example.com (munk) — Mon, 22 Mar 2004 20:00:46 +0000

Well, I'm baffled, the server just had a total hissy fit and fell down in a ball of nervous cyber tension and had to be cold rebooted - hit that reset switch baby... not had to do that for literally years on this box. Hoping it's not a sign of impending hardware failure...

Just before resorting to the magic finger reset button technique (pure BOFH stylee), saw a *lot* of messages about the HDD failing and then when I rebooted, the HDD wouldn't get detected until I unplugged the IDE cable from the controller and reinserted it... odd.

Denial of Service OpenSSL Vulnerability

nospam@example.com (munk) — Wed, 17 Mar 2004 17:18:36 +0000

Joy. I was just browsing through bugtraq when I noticed a fairly major looking security release. Hrm I thought... wonder why that hasn't hit the freebsd-security list yet? Wishful thinking... within literally a minute as I moved onto the freebsd-security list, sure enough there was a security announcement about the problem... time to makeworld :P

Curious, I seem to have caught this very early, the post to the freebsd-security list doesn't appear to have made it to the MARC archives yet... by the time anyone reads this no doubt it will have though :P

BSD Family Tree

nospam@example.com (munk) — Wed, 17 Mar 2004 16:50:57 +0000

Just spent ages doing silly stuff like 'locate map' or 'locate bsd' to try and find a map of the BSD Family Tree. I'd seen it before a long long time ago, but for the life of me couldn't remember where it was.

For the record you can view it in the local file system under FreeBSD here:

/usr/share/misc/bsd-family-tree

I've copied it into the docroot, you can view it online here:

BSD Family Tree

More FreeBSD Shell Scripts

nospam@example.com (munk) — Wed, 17 Mar 2004 13:25:55 +0000

http://www103.pair.com/parv/comp/src/ - a number of interesting shell scripts mostly specific to FreeBSD.

The guy's name who authored these scripts - Parv - I recognize from the freebsd-questions list and possibly(?) exim-users as well... small world.

Incidentally I came across the list of scripts via an entry in another weblog by Jonathan Arnold called Daemon Dancing in the Dark, a FreeBSD weblog - very similar to this one - check it out :P

Using mtree to Restore File Permissions

nospam@example.com (munk) — Wed, 03 Mar 2004 03:46:52 +0000

Messing up the filesystem by badly executed chmod commands is a pain in the butt. Luckily there's a tool called mtree on FreeBSD that can help out in restoring the file permissions to some of the base file systems.

There's a great post here by Matthew Seaman about using mtree:

Using mtree to correct file system perm problems