Entries : Category [ FreeBSD ]
[OpenBSD]  [BSD]  [FreeBSD]  [Linux]  [Security]  [Python]  [Zope]  [Daily]  [e-shell]  [Hacks]  [PostgreSQL]  [OSX]  [Nintendo DS]  [enlightenment]  [Apache]  [Nintendo Wii]  [Django]  [Music]  [Plone]  [Varnish]  [Lugo]  [Sendmail]  [europython]  [Cherokee]  [self]  [Nature]  [Hiking]  [uwsgi]  [nginx]  [cycling]  [Networking]  [DNS] 

30 diciembre

mergemaster -U

and it was there all the time, in the man page!

From mergemaster(8):

-U     Attempt to auto upgrade files that have not
       been user modified.

Which is a very useful option to use if you are upgrading a FreeBSD server from a -RELEASE version to a -STABLE version, for example from 8.0-RELEASE to 8-STABLE.

In such case there are a lot of files that will be modified during the installation (like those in /etc/defaults or /etc/periodic) but whose only modification is a timestamp in the cvs information at the beginning of the file.

Passing the -U argument to mergemaster will avoid you having to check each file separately.

(Lucky me I did found this!)

Posted by wu at 12:52 | Comments (0) | Trackbacks (0)
24 enero

New FreeBSD port: openerp-web

YES! my first port after sooo much time.

Today my first FreeBSD port went into the ports tree:


I've ported the OpenERP web client so, if you update your ports tree now (using portsnap or csup) you can search for openerp:

cd /usr/ports && make search name=openerp

You will get two results, the openerp-server port and my openerp-web port:

Port:   py26-openerp-web-5.0.6
Path:   /usr/ports/finance/openerp-web
Info:   OpenERP Web Client
B-deps: gettext-0.17_1 libiconv-1.13.1 py26-Babel-0.9.4 py26-beaker-1.5.1 py26-cheetah-2.4.1_1 py26-cherrypy-3.1.2 py26-formencode-1.2.2 py26-mako-0.2.5 py26-markdown-2.0.3 py26-parsing-1.5.2_1 py26-pytz-2009u py26-setuptools-0.6c11 py26-simplejson-2.0.9 py26-xlwt-0.7.2 python26-2.6.4
R-deps: gettext-0.17_1 libiconv-1.13.1 py26-Babel-0.9.4 py26-beaker-1.5.1 py26-cheetah-2.4.1_1 py26-cherrypy-3.1.2 py26-formencode-1.2.2 py26-mako-0.2.5 py26-markdown-2.0.3 py26-parsing-1.5.2_1 py26-pytz-2009u py26-setuptools-0.6c11 py26-simplejson-2.0.9 py26-xlwt-0.7.2 python26-2.6.4
WWW:    https://launchpad.net/openobject-client-web

I needed that, as I've been working a lot on setting up OpenERP solutions under FreeBSD so having the ports to take care of the dependencies is very useful.

Lately I've been working on a howto style doc too. In that doc I cover how to install and configure both the openerp server and the web client. I'll post about it once it is finished.

Posted by wu at 12:07 | Comments (0) | Trackbacks (0)
16 febrero

NFS server behind a PF firewall

redirecting NFS traffic could be a little bit tricky

Second post entitled something behind some-other-thing, I've wasted all my imagination when I was a child... ;)

Yesterday I found a small problem with NFS while working on this setup:

NFS behind a PF firewall

In the setup, there are 2 Linux-based NAS devices that export a 1Tb share over NFS. Both NAS are in sync so, if one fails, we can mount the other one and users would be able to keep working while the first NAS is replaced.

Both NAS devices are in a Gigabit LAN, connected with one of the network interfaces on a FreeBSD server (subnet

On the other side of the server, there was another LAN, where workstations are connected to the server (subnet

The plan was to mount the /nfs/shares share in the FreeBSD server and then export it again from the server, allowing the workstations to mount it. It didn't work. After some reading I found out that NFS does not like to re-export NFS shares, that is, if you mount an NFS share from server A on server B and then you try to export that share from the mount point in server B to server C (for example) you will get all kinds of nasty errors.

It was time for a change in the plan. I didn't want to give full-access to the NAS devices and I didn't want the workstations to mount the share directly from the NAS devices either, because if one fails, I would have to modify the mounts in every workstation so they use the backup NAS device.

Perhaps I could use PF in the FreeBSD server to redirect NFS traffic from the workstations directly to the NAS devices...

Well, it took me some time to think about how to do it (and some help from viq at #pf in freenode). The best approach could be some kind of binat that could map the NFS requests for a given ip address to the ip address of the selected NAS device. Anyway, you can't map a whole network (or any to use a wildcard), so binat would not work. I had to think about a different way to do it.

Let's begin modifying the setup a little bit:

NFS behind a PF firewall (final setup)

As you can see in the picture, my idea was to add an alias to the nic connected to the subnet, then I would be able to use PF to redirect all incoming traffic for that alias ( to a given NAS device. As I've a local DNS server in the network I could add an A entry for nfs.mydomain.com that points to, this way I would be able to use that internal subdomain instead the ip address to access the NFS shares. Nice, the new plan was finished, let's start it! (I'll omit the DNS Zone modification, as it is out of the scope of this post)

First, I added the alias definition to /etc/rc.conf:

ifconfig_bge0_alias0="inet netmask"

This will create the alias properly after a reboot. Then I created the alias manually:

ifconfig bge0 alias

Once I've created the alias, I added PF support in /etc/rc.conf:


This will load the needed stuff on boot (kernel modules, sysctl knobs, etc). This will work if you've the GENERIC kernel, if not, you will have to check if your custom kernel has pf support enabled within the kernel or as a KLD.

Then I created the /etc/pf.conf file. This is a stripped version of it (It shows only the needed stuff for the NFS redirection to work):

lan_if="bge0" # NIC connected to the Intranet LAN
nas_if="bge1" # NIC connected to the NAS-storage LAN

nfsalias="" # Local alias to manage requests for NFS storage
mainnas="" # Main storage NAS
backupnas="" # Backup storage NAS

rdr on $lan_if proto { tcp, udp } from $lan_if:network to $nfsalias port 111:65535 -> $mainnas

pass in log quick on $lan_if proto { tcp, udp } from $lan_if:network to $mainnas keep state

pass in all
pass out all

What I do with this pf.conf configuration file is set a redirection so all tcp and udp traffic from the workstations LAN to the alias ip on any port between 111 and 65535 will get redirected to the main NAS device.

The reason for such redirect is that NFS uses random ports for connections (in a similar way to what FTP does) so it is easier to open a full-range of ports. The first port is 111 as it is the first port needed by NFS (sunrpc/rpcbind) and, this way, I block requests for the NAS device web interface (port 80) and SSH (port 22) and users from the workstations LAN will not be able to access the management interfaces of the NAS device.

You should have noticed that the following line is not needed at all:

pass in log quick on $lan_if proto { tcp, udp } from $lan_if:network to $mainnas keep state

It is not (because I do a pass all later) but it allows me to log only NFS traffic (useful for debugging).

Ok, once I had everything in place, I started PF:

/etc/rc.d/pf start

(This will load the kernel module if needed, set the proper sysctl options and will enable pf too)

If my plan was right (and it was ;D) I should be able to access the NFS shares of the main NAS device from any workstation, so I did some checks using showmount:

$ showmount -d nfs.mydomain.com
Directories on nfs.mydomain.com:

It worked!. that soho_storage path you see there is the full path of the shares share within the NAS device filesystem. The Iomega NAS stores all the data within a directory called samba/shares and then it creates symlinks of the data within the /nfs directory.

Ok, as showmount worked, it was time for the final test, to mount the share. In FreeBSD workstations I modified /etc/fstab, adding:

nfs.mydomain.com:/nfs/shares /mnt/nfsstuff  nfs     rw,tcp            0       0

In the Linux workstations I added a line like:

nfs.mydomain.com:/nfs/shares /mnt/nfsstuff nfs rw,tcp,rsize=32768,wsize=32768,hard,intr,timeo=14,bg       0       0

Of course /mnt/nfsstuff must exist. With the proper fstab lines in place, I just tried to mount the share:

# mount /mnt/nfsstuff

Which worked as expected:

$ df -h
Filesystem               Size    Used   Avail Capacity  Mounted on

[ stripped ]

nfs.mydomain.com:/nfs/shares    929G    269G    660G    29%    /mnt/nfsstuff


It was really disgusting to find out that NFS does not support re-export of shares. This is the first time in many years I find something I don't like about NFS. Anyway, I found a great solution, perhaps even better than re-exporting it. With this setup, if the main NAS device fails, I only have to change one PF rule and all the requests for nfs.mydomain.com will go to the backup NAS. If needed, I could even split NFS traffic, sending some workstations to the main NAS and some other to the backup NAS or I could block NFS traffic from certain ip addresses, adding some security to the whole thing. IMHO this is a great solution.

Posted by wu at 13:01 | Comments (6) | Trackbacks (0)
19 abril

Duplicate option COMPAT_FREEBSD32

building a GENERIC RELENG_8 kernel today

Picking up the next task in my TODO list since my back from Porto, I was trying to build a new kernel for a new server (RELENG_8 updated just this morning), and I found this error:

# make buildkernel KERNCONF=GENERIC

>>> Kernel build for GENERIC started on Mon Apr 19 11:08:07 UTC 2010
mkdir -p /usr/obj/usr/src/sys

>>> stage 1: configuring the kernel
cd /usr/src/sys/amd64/conf;  PATH=/usr/obj/usr/src/tmp/legacy/usr/sbin:/usr/obj/usr/src/tmp/legacy/usr/bin:/usr/obj/usr/src/tmp/legacy/usr/games:/usr/obj/usr/src/tmp/usr/sbin:/usr/obj/usr/src/tmp/usr/bin:/usr/obj/usr/src/tmp/usr/games:/sbin:/bin:/usr/sbin:/usr/bin  config  -d /usr/obj/usr/src/sys/GENERIC  /usr/src/sys/amd64/conf/GENERIC
../../conf/options.amd64: Duplicate option COMPAT_FREEBSD32.
*** Error code 1

Stop in /usr/src.
*** Error code 1

Stop in /usr/src.

mmm, quite strange. I never found such a problem before, so I took a look at /usr/src/UPDATING and I found that:

        The kernel option COMPAT_IA32 has been replaced with COMPAT_FREEBSD32
        to allow 32-bit compatibility on non-x86 platforms. All kernel
        configurations on amd64 and ia64 platforms using these options must
        be modified accordingly.

mmm, even more strange, it shouldn't affect this kernel at all, as it is the GENERIC configuration file fetched with the rest of the sources (this is a new server, it is not that I was trying to reuse my old GENERIC config file).

After digging a little bit I found that line in /usr/src/sys/conf/options.amd64:

COMPAT_IA32             = COMPAT_FREEBSD32

Which seems to be needed for GENERIC configs that still has the COMPAT_IA32 option in them.

I commented that line:

# COMPAT_IA32             = COMPAT_FREEBSD32

And then buildkernel worked ok again. Anyone having this issue with old GENERIC kernels?

Posted by wu at 11:30 | Comments (0) | Trackbacks (0)
03 septiembre

Disabling FreeBSD background fsck

You could need it on really *huge* partitions...

If you are familiar with unix systems, you probably know already fsck, if not feel free to take a look at the wikipedia article about it to learn more.

FreeBSD has a nice feature in its UFS2 filesystem called background fsck, which allow dirty filesystems (filesystems that hadn't been unmounted properly/cleanly) to be mounted even if they need fsck to check them. Once mounted, a fsck process is started in the background, checking that partition.

This is really nice because your server will not took ages to reboot after a crash, because of fsck running before finishing the boot process (before mounting the partitions exactly). You can learn more about background fsck in this article from Kirk McKusick.

But, background fsck could be a problem in certain situations. For example, it happened to one of my servers this week that, after some crashes the server just reboot fine, then started the backgrounds fsck. It went ok for a while, but when fsck is called to run on the biggest partition (600Gb, mounted in /home, with probably 45% of the space used) the machine crashed again (kernel panic).

That server is a high-load mail server with a lot of disk writes, so I thought that perhaps disabling the background fsck feature could help. It would be even better if I could get the machine to perform an offline fsck by itself and then boot cleanly (yes, that was background fsck is supposedly to avoid).

To do it I added these two lines to /etc/rc.conf:


The first one sets yes as the default answer for all the questions fsck could make during a check, while the second one disables the background fsck feature.

Then I rebooted the server, and it took quite a while to finish the reboot, but the filesystems were clean and the machine didn't freeze anymore.

(Hope it helps any of you).

Posted by wu at 23:47 | Comments (0) | Trackbacks (0)
27 septiembre

Bad : modifier in $ (:).

tcsh proper variable handling in a "echo" call

Nowadays most of the people use bash as the default shell, even if there are some other options like ksh (or Korn Shell) and tcsh (the Tenex C Shell).

Bash is the default shell in almost all Linux distributions and it is quite popular but, if you are using some other Unix flavours (like BSD ones) you can find yourself using ksh (default shell in OpenBSD) or tcsh (one of the default shells in FreeBSD).

Today I found one of those ugly errors when doing some things with tcsh. The task was about to create a bunch of user accounts in a somehow automated way. As adduser in FreeBSD allows us to create users automatically, I just tried to do it in a foreach loop, which in tcsh was something like:

# foreach i ( usera userb userc userd )
foreach? echo "$i::1005::::$i SFTP account:/home/sftp/$i:/bin/tcsh:" | adduser -w random -f "-"
foreach? end
Bad : modifier in $ (:).

I was executing that code directly in the shell (instead of writing a small script) and it should create the users ( usera userb userc userd ) with a random password associated with each one.

You probably noticed the error:

Bad : modifier in $ (:).

This happens because tcsh didn't handle the :$i thing properly. The correct way to do this in tcsh is:

echo $i"::1005::::"$i" SFTP account:/home/sftp/"$i":/bin/tcsh:" | adduser -w random -f "-"

Just leaving the $i variables outside of the "" strings.

Then it worked just fine:

# foreach i ( usera userb userc userd )
foreach? echo $i"::1005::::"$i" SFTP account:/home/sftp/"$i":/bin/tcsh:" | adduser -w random -f "-"
foreach? end
adduser: INFO: Successfully added (usera) to the user database.
adduser: INFO: Password for (usera) is: XXXXXXXXXXX
adduser: INFO: Successfully added (userb) to the user database.
adduser: INFO: Password for (userb) is: XXXXXXXXXXX
adduser: INFO: Successfully added (userc) to the user database.
adduser: INFO: Password for (userc) is: XXXXXXXXXXX
adduser: INFO: Successfully added (userd) to the user database.
adduser: INFO: Password for (userd) is: XXXXXXXXXXX

You can find similar errors like:

But the problem is probably the same as here, you are messing up with some variables in your shell code.

Posted by wu at 10:05 | Comments (0) | Trackbacks (0)
30 septiembre

Repair a GEOM mirror using a rescue-live system

I'm getting some real experience doing repairs of damaged filesystems!

Some days ago, I wrote some lines about how to disable the FreeBSD background fsck. This post is somehow related to it, as this one is based on a experience I had today. One of the FreeBSD 8 servers I manage was improperly restarted (improperly as restarted without unmounting the filesystems) 3 times in a row (jay!, thnx a lot OVH!!!). So, after the third restart, the server needed some serious fsck work. As this server wasn't modified as described in my post, it tried to run fsck in the background for some partitions (/, /tmp, /var, /usr and /home) but, being one of them (/home) quite big (~600Mb) and being that server a high-load server, the server was performing extremely bad.

Perhaps one of the reasons for this performance penalty could be that the server has two 750Gb SATA drives in a GEOM Mirror setup, so each write must be replicated from one disk to the other. I wrote some lines in this post about this kind of setup, if you are interested in more information about GEOM.

A quick look with systat (systat -iostat 2) showed me that disk access was the bottleneck so I thought it could be better if the fsck check was done offline.

To do that I just needed some kind of rescue or livecd system to boot instead of the local system, then use fsck on the live system to clean up the filesystems.

One of the good things of having a server in OVH is that you can boot your server in Rescue Mode, which is perfect for those kinds of tasks.

Once the live system finished booting (and I got the user/password info from OVH) I connected to it using SSH and I needed to get access to the GEOM Volume. This was quite easy, you only need to load the needed kernel module (thnx for the help with this, jpaetzel from the ##freebsd channel in freenode):

kldload geom_mirror

The mirror was found and loaded properly (as I could see with dmesg):

GEOM_MIRROR: Device mirror/gm0 launched (1/2).
GEOM_MIRROR: Device gm0: rebuilding provider ad6.

As you can notice, the mirror was rebuilding one of the disks. I could check the status using the gmirror utility:

rescue-bsd# gmirror status
      Name    Status  Components
mirror/gm0  DEGRADED  ad8
                    ad6 (15%)

mmm, only 15% of the disk was repaired, something wrong must had happened to the mirror :(

It is a good idea to wait for the mirror to be complete before proceeding with fsck (you've been warned) I've done some tests running fsck without the mirror was rebuilt completely, and it worked, but you should wait, seriously.

Next thing was to use fsck to check the filesystems:

rescue-bsd# ls -l /dev/mirror/
total 0
crw-r-----  1 root  operator    0, 123 Sep 30 16:13 gm0
crw-r-----  1 root  operator    0, 124 Sep 30 16:13 gm0s1
crw-r-----  1 root  operator    0, 125 Sep 30 16:13 gm0s1a
crw-r-----  1 root  operator    0, 126 Sep 30 16:13 gm0s1b
crw-r-----  1 root  operator    0, 127 Sep 30 16:13 gm0s1d
crw-r-----  1 root  operator    0, 128 Sep 30 16:13 gm0s1e
crw-r-----  1 root  operator    0, 129 Sep 30 16:13 gm0s1f
crw-r-----  1 root  operator    0, 130 Sep 30 16:13 gm0s1g

I just ran fsck for each partition except gm0s1b, which is the swap partition (yes, I know, putting the swap partition in the mirror is quite a dumb thing O:)) running fsck this way for each partition:

fsck_ufs -y /dev/mirror/gm0s1a

Once the filesystems were clean, I just rebooted the server to get it back online again.

Posted by wu at 17:22 | Comments (0) | Trackbacks (0)
19 enero

Clean up a dirty FreeBSD ports tree

Use this if you don't need to perform a full-tree cleanup

This is a quick hack for those of you who (as me) usually forget to perform a make clean after make install when installing software using the FreeBSD ports collection.

This is the shell script:

# Search for ports that contain a "work" subdirectory,
# then go into that port directory and perform a
# make clean

for i in `find /usr/ports -name work -type d`
  cd `echo "$i" | sed 's/\/[^\/]*$/\//'`
  make clean

It simply searchs for directories called work within the ports tree (because this is the name of subdirectories created by the ports tree when building software before installing it), then it removes the last part of the path (the work directory itself) and then it goes into the port directory and performs a make clean to clean up this port (and all the dependencies of the port).

This could be helpful if you only need to clean a given number of ports (10, 20, whatever) and you don't want to perform a full clean:

cd /usr/ports && make clean

This will clean up the whole ports tree, but it will take a loooong time to finish.

Oh!, obviously you need root privileges to execute the script (use sudo to call the script or edit the script and replace make clean with sudo make clean for example).

Posted by wu at 12:33 | Comments (3) | Trackbacks (0)
18 agosto

How to install a patched uwsgi package in FreeBSD

and how to do it cleanly, so you can keep track of later updates

What I'm going to explain in this post is not uwsgi-specific, you can follow this intructions to install patched versions of any package available in the FreeBSD ports collection.

In my case, I needed a patched version of the uwsgi package because I found a bug on my current version (0.9.8) that was already fixed in the -current/trunk version of uwsgi, but it hasn't been backported to any stable release yet (hopefully it will be in

So, to fix the bug I needed the latest -current/trunk code or the latest stable release ( + the needed patch.

Installing -current/trunk means compiling the sources and installing the binaries by myself, which will lead to some problems next time I had to upgrade the packages and ports in that server, so it seemed like a much better option to install the latest stable version using the ports tree. Anyway, I still would need to apply the patch to the sources before installing... this is what I've done to add the patch cleanly.

I ran all the commands as root, if needed use sudo or some other tool to gain root privileges in order to use the ports tree.

First I got the sources of uwsgi using the ports tree:

# cd /usr/ports/www/uwsgi
# make fetch

That saved the source tarball into /usr/ports/distfiles:

-rw-r--r--  1 root  wheel  351168 Jul 23 06:28 /usr/ports/distfiles/uwsgi-

Then I extracted the sources:

# make extract

That extracted the sources into /usr/ports/www/uwsgi/work/:

drwxr-xr-x  18 root  wheel  3072 Aug 18 15:47 work/uwsgi-

At this point we have two options, we could download an already existing patch or we can generate the patch ourselves. In my case, I generated the patch manually because the already existing patch didn't work.

To generate the patch I renamed the file that was going to be patched:

# cd work/uwsgi-
# mv plugins/python/wsgi_headers.c plugins/python/wsgi_headers.c.orig

Then I downloaded a copy of the patched version of the file:

# fetch -o plugins/python/wsgi_headers.c "http://projects.unbit.it/uwsgi/export/ddccfbda7423c8a61f178ba5b1526872d38cc285/plugins/python/wsgi_headers.c"

And finally I generated the patch:

# diff -ruN plugins/python/wsgi_headers.c.orig plugins/python/wsgi_headers.c > ../../files/patch-wsgi_headers.c

As explained in the patching section of the FreeBSD porters handbook:

"Each patch you wish to apply should be saved into a file named patch-* where * indicates the pathname of the file that is patched, such as patch-Imakefile or patch-src-config.h. These files should be stored in PATCHDIR (usually files/, from where they will be automatically applied. All patches must be relative to WRKSRC (generally the directory your port's tarball unpacks itself into, that being where the build is done)."

Once the patch was created, I cleaned up the work directory:

# make clean

And finally I install the new uwsgi package:

# make install clean

The bug was fixed and everything is running smoothly now.

Just some final considerations:

Posted by wu at 16:31 | Comments (0) | Trackbacks (0)
19 febrero

Setup chroot for bind 9 in FreeBSD 10

simple instructions if you are upgrading from freebsd 8.x or 9.x

FreeBSD 10 has been released some days ago and this new version comes with lots of new stuff (just take a look at the release notes to learn more about it).

One of those changes is the removal of BIND from the base system, being it replaced by Unbound. More information about this move from the FreeBSD project can be found here:

Maybe you would find interesting this thread from the freebsd-stable mailing list too:


(also available here: http://marc.info/?t=138606115200005&r=2&w=2)

There some people complain about the differences between the scripts and setup we had in the base system vs what is available in the bind9 port. Setting up a chrooted dns server was quite easy when BIND was in the base system, as the configuration files and rc.d scripts were already prepared for such a setup, but it seems that what is installed by the port does not handle that so well.

Or so it seems...

These are the steps I followed to keep my BIND servers chrooted after upgrading to FreeBSD 10:

Warning: The following assumes you have a default BIND setup, chrooted under /var/named and with all the config files in /etc/namedb, which should be a symbolic link to /var/named/etc/namedb.

  1. Install BIND 9.x from ports:

    cd /usr/ports/dns/bind99 && sudo make install clean

    or, if you prefer to use pre-built packages:

    sudo pkg install bind99
  2. The port/package will install the configuration files under /usr/local/etc/namedb, move them aside:

    sudo mv /usr/local/etc/namedb /usr/local/etc/namedb.default
  3. Link the existing configuration from our previously chrooted setup to the place where the port will look for them:

    sudo ln -s /var/named/etc/namedb /usr/local/etc/namedb
  4. Now, as the configuration files have been moved from /etc/namedb to /usr/local/etc/namedb, we have to recreate such a route inside the chroot environment, ensuring the management scripts will find the configuration files:

    sudo mkdir -p /var/named/usr/local
    cd /var/named/usr/local && sudo ln -s ../../etc .
  5. Remove the old link under /etc:

    sudo rm /etc/namedb
  6. Create a custom devfs ruleset to be used with our chroot environment, adding the following to /etc/devfs.rules:

    # Custom rules for the named chroot dev
    add hide
    add path run unhide
    add path random unhide
  7. Mount the devfs filesystem from the chroot environment. First add the following to /etc/fstab:

    devfs             /var/named/dev  devfs   rw,ruleset=4      0     0

    Then mount it:

    sudo mount /var/named/dev
  8. Enable chroot when starting BIND, adding the following line to /etc/rc.conf:

    named_flags="-t /var/named"

    You don't have to set the -u flag, because it is already passed by the rc.d script (user bind).

  9. Fix the /usr/local/etc/rc.d/named script, so it will be able to find the proper pidfile when stopping the daemon. Add the following line inside the named_stop() function, just below find_pidfile:

    test "${named_flags#*-t}" != "$named_flags" && pidfile="/var/named${pidfile}"

    This will check for the presence of the -t flag in the provided flags and, if exists, will add the path of our chroot directory to the already existing pid file path.

  10. Start BIND:

    sudo /usr/local/etc/rc.d/named start

et voilà, BIND should be running now, chrooted under /var/named as user bind, just like in your previous setup.

UPDATE 2014-02-25: Added the mount of the devfs filesystem as mentioned by APz in the comments.

Posted by wu at 12:08 | Comments (12) | Trackbacks (0)
Prev  1   [2]