Doxy­gen stuff updat­ed in 9‑current

I com­mit­ted my patch for tools/kerneldoc/subsys. Except for not gen­er­at­ing the PDF part, this is now the same con­fig which I use to gen­er­ate the online ver­sion. While writ­ing the com­mit log I noticed that I did more changes than I thought…

So any­one who wants to gen­er­ate the Doxy­gen docs of some FreeB­SD ker­nel sub­sys­tems on his own, can do it now. Adding more sub­sys­tems is easy, just make a copy of one the the exist­ing Doxyfile-* files – keep the same nam­ing scheme – and change the con­tents. Every­thing else is han­dled automatically.

I also added a link to the FreeB­SD wiki. It is not at a promi­nent place (near the end of the main page), but at least some­one can find the link to the my FreeBSD-doxygen page there.

HOWTO: “Blind” remote install of FreeB­SD via tiny disk image

In this post I write how to install FreeB­SD on a remote lin­ux sys­tem by cre­at­ing a root image pre­pared for mir­ror­ing on a local sys­tem. There is no (free) access to the remote con­sole, only access via ssh.

In this post I write how to install FreeB­SD on a remote lin­ux sys­tem by cre­at­ing a root image pre­pared for mir­ror­ing on a local sys­tem. There is no (free) access to the remote con­sole, only access via ssh.

Back­ground story

While I was at the uni­ver­si­ty, I worked remote­ly for an ISP (admin­is­tra­tion of sev­er­al FreeB­SD sys­tems). Dur­ing this time I start­ed to use my own domain, and I was allowed to host it direct­ly at the ISP for free. I tried to not use too much space on the hard­disk (at the end about 400 MB) and to not pro­vide some­thing which attract­ed too much peo­ple to keep the band­with on a sane lev­el. After the uni­ver­si­ty I was still avail­able to answer ques­tions, and I was still allowed to host my web­site there for free. As the num­ber of ques­tions can be count­ed with IIRC one hand since then, I decid­ed at some point (recent­ly, to be exact – bet­ter late than nev­er) to move my web­site to a dif­fer­ent place (I am still avail­able if they have some ques­tions – for free – but I do not expect to get much ques­tions from them).

At the same time my broth­er decid­ed to move to a new serv­er hoster, as his old one decid­ed to increase the amount of mon­ey cus­tomers have to pay for the ser­vice. So we searched togeth­er a new ISP where he either could host his serv­er, or get a root­serv­er for a good price (the idea was to have my domain in a jail on a serv­er of the com­pa­ny of my broth­er, and we share the costs for it). We found Man­i­tu (the own­er has even a blog about his busi­ness), which is even not far away from my place.

Unfor­tu­nate­ly they do not pro­vide FreeB­SD pre­in­stalled on their root­servers, but they offer a remote res­cue sys­tem (read: boot­ing a lin­ux image… I assume via PXE or sim­i­lar) and we knew some­one who has some servers there, so I was able to get a rough idea what kind of hard­ware is used there (the hard facts like PCI IDs and such). The idea was to build a very small disk image, put it on the hard­disk over the net­work via the remote res­cue sys­tem, and then to con­fig­ure the remain­der of the harddisk(s) to use it. And here is how I did it (my broth­er thought “who is bet­ter suit­ed to install a FreeB­SD sys­tem remote­ly with­out access to the con­sole of the machine (the ISP offers to hook up a KVM switch, but only dur­ing busi­ness hours and you have to pay for it) than one of the devel­op­ers of FreeBSD…”).

HOWTO

In the title of this post I wrote “via a tiny disk image”. This is true for a suit­able def­i­n­i­tion of tiny.

What we have in the root­serv­er are two 160 GB hard­disks. They shall be used in a soft­ware mir­ror (via gmir­ror). The root-FS shall have about 5 GB. This is more than need­ed, but as this is only 3% of one hard­disk, I pre­fer to keep it a lit­tle bit big­ger than too small after an remote update or two. The machine has 2 GB of RAM. We do not expect much ker­nel pan­ics (= crash dumps) there, so we do not real­ly need >2 GB of swap (for­get the rule of hav­ing twice as much swap than RAM, with the cur­rent amount of RAM in a machine you are in “trou­ble” when you need even the same amount of swap than RAM). I decid­ed to go with 1 GB of swap (mir­rored too, to pre­vent a hard­disk fail­ure to take down the machine), this is more than enough. The rest of the hard­disk will be used for jails, the distfiles/packages for/of the ports, and as WRKDIRPREFIX when build­ing ports.

Now, pushing/pulling a 160 GB image over the net­work to install a sys­tem is not real­ly some­thing I want to do. I would pre­fer to trans­fer less than 500 MB (that is 0.3% of the entire disk) to get this job done, and this is fea­si­ble. Due to an error or two I had to trans­fer the image sev­er­al times until every­thing was work­ing, so it was more in the area of maybe 2 GB (~1% of the entire disk).

First let us define some vari­ables in the shell, this way you just need to change the val­ues in one place and the rest is copy&paste:

ROOTFS_SIZE=5G
ROOTFS_NAME=root0
FILENAME=rootfs

Then change your cur­rent direc­to­ry to a place where you have enough space for the image. There we will cre­ate a con­tain­er for the image, and make it ready for partitioning:

truncate -s ${ROOTFS_SIZE} ${FILENAME}
mdconfig -a -t vnode -f ${FILENAME}

Cre­ate the rootfs:

# create one active FreeBSD slice with $ROOTFS_SIZE GB
fdisk -e /dev/mdX
gmirror label ${ROOTFS_NAME} /dev/mdXsY
bsdlabel -w /dev/mirror/${ROOTFS_NAME}
# create an "a"-partition for everything
bsdlabel -e /dev/mirror/${ROOTFS_NAME}
newfs -U /dev/mirror/${ROOTFS_NAME}a

Mount the new rootfs to /mnt and install FreeBSD:

mount /dev/mirror/${ROOTFS_NAME}a /mnt
cd /usr/src
make buildworld >&! buildworld.log
make buildkernel >&! build_generic.log
make installworld DESTDIR=/mnt
make distribution DESTDIR=/mnt
make installkernel DESTDIR=/mnt

Now you need to cre­ate /mnt/etc/rc.conf (set the default­router, the IP address via ifconfig_IF (and do not for­get to use the right IF for it), the host­name, set sshd_enable to yes, add an user (I used “vipw ‑d /mnt/etc”) which is in the wheel group so you can login remote­ly, and maybe oth­er things you are inter­est­ed in), /mnt/etc/resolv.conf, /mnt/etc/hosts. Final­ly, do not for­get to load the gmir­ror mod­ule, it will safe a lot of head-scratching (yes, an echo would be short­er, but WP con­verts the single-quotes to double-quotes), and add the rootfs to the fstab:

cat > /mnt/boot/loader.conf <<EOT
geom_mirror_load="YES"
EOT
echo "/dev/mirror/root0a / ufs rw,noatime 1 1" >/mnt/etc/fstab

Now we are ready to install, the image can be unmounted:

umount /mnt

The final steps are to login into the res­cue con­sole (the­o­ret­i­cal­ly you should be able to over­write even a run­ning sys­tem, but then you need to make sure there is a way to power-cycle the sys­tem remote­ly to force a reboot) of the new sys­tem and to install via a com­pressed ssh con­nec­tion (my remote res­cue sys­tem is a lin­ux sys­tem, so linux-syntax has to be used). The login to the res­cue con­sole is not shown here, but the install from the remote sys­tem is sim­ple (this assumes the image resides on a sys­tem which is acces­si­ble from the new system):

ssh -C -o CompressionLevel=9 user@myhost cat /path/to/${FILENAME} | dd of=/dev/hda bs=1m

Alter­na­tive­ly you can com­press it with bzip2 on your sys­tem and add an bunzip2 into the pipe above. This way you could even use an HTTP serv­er to fetch the file from, but then the com­mand to fetch the file needs to have a way to out­put the file it down­loads on std­out. Both ways of trans­fer­ring the image depend upon the sta­bil­i­ty of the trans­fer. If the con­nec­tion is cut, the sys­tem can not boot any­more. So if you do not have a res­cue con­sole which is inde­pen­dent from the con­tent of the hard­disk, you bet­ter have a plan B.

If I did not make an error here (I did this some months ago, I hope I did not for­get to write down some impor­tant step and also cor­rect­ed all steps which where not writ­ten down cor­rect­ly), you did every­thing cor­rect­ly too, and the remote sys­tem does not need oth­er ker­nel mod­ules loaded, you can now reboot the new sys­tem, cross your fin­gers for some moments, and then login to the new system.

Post install TODO

Now you should have a basic sys­tem up and run­ning, and you can start to con­fig­ure it.

I added two more FreeB­SD par­ti­tions, 1 GB for swap, and the rest of the hard­disk (I took care to not have the last par­ti­tion cov­er also the last sec­tor of the hard­disk, else gmir­ror will think it has to mir­ror the entire hard­disk and not only the last par­ti­tion) as one big par­ti­tion. For the sec­ond hard­disk I made the same par­ti­tion­ing as for the first harddisk.

Then I cre­at­ed two more gmir­rors, one mir­ror for the swap, and one for the rest of the space. The mir­ror for the swap I cre­at­ed with the option “-F”, to not syn­chro­nize the par­ti­tion after a pow­er fail­ure (not nec­es­sary for swap). All two I also cre­at­ed with the “-n” option, to not sync the con­tents (there is noth­ing yet, so it does not mat­ter what is writ­ten there).

Now just a quick “bsd­la­bel” on the two mir­rors to cre­ate a “b”-partition for the swap and a “d”-partition for the large par­ti­tion. To add the swap it is just an “echo /dev/mirror/swap0b none swap sw 0 0 >/etc/fstab”. Do not for­get to add the big par­ti­tion to the fstab (after doing a “newfs” off course).

To be sure it will sur­vive a reboot, do a quick test of man­u­al­ly mount­ing the big par­ti­tion (use the easy man­u­al way via “mount /place/where/it/is/mounted” after adding it to the fstab, not the com­plete man­u­al way, this is meant to test the fstab entry too), and a “swapon ‑a” to test the swap. I also made a reboot test, just to be sure every­thing is ok.

The final step was to add the par­ti­tion on the sec­ond hard­disk to the rootfs (“gmir­ror insert ${ROOTFS_NAME} /dev/…”).

WP plu­g­ins and PHP safe_mode

Obvi­ous­ly a lot of WP plu­g­in authors do not check if their plu­g­in is PHP safe_mode/open_basedir com­pat­i­ble. Yes, I know, it is dep­re­cat­ed and does not offer 100% safe­ty, but it is at least an addi­tion­al road-block in some cas­es and may pre­vent some mali­cious behav­ior… If I can choice between 100% break-in pos­si­bil­i­ty and <100% break-in pos­si­bil­i­ty, I chose the later.

I also think most of them also do not check with suhosin. They also fail to list oth­er PHP exten­sion require­ments most of the time, they just assume you have a full install.

  • quick­stats wants the PHP ctype exten­sion, does not seem to play well with sql.safe_mode while the rest of WP does not seem to have an obvi­ous prob­lem with it
  • wp-stats-dashboard wants the PHP curl and json exten­sion (curl does not play well with safe_mode or open_basedir => needs to be dis­abled), needs suhosin.executor.include.max_traversal set to 6; still does not work 100% cor­rect, I delet­ed the cache direc­to­ry con­tents to let it recre­ate the stats, but it still does not dis­play as much vis­its as I can see in the stats on the post­ings page
  • bot-tracker wants the PHP ses­sion extension
  • broken-link-checker tries to write to /var/tmp/ (safe_mode/open_basedir incompatible)
  • one-time-password does not play well with safe_mode/open_basedir
  • smartlink­er tells me that the vari­able cook­ieString is not defined

DNS prob­lem (DomainKey TXT entry)

The TXT entry outgoing-alex._domainkey.leidinger.net which worked for a long time sud­den­ly stopped being deliv­ered by named (thanks to Hen­ri Hen­nebert for the HEADS-UP). Every oth­er query I try works so far, it is real­ly just this one entry (resolve time­out). I noti­fied the respon­si­ble per­son, inves­ti­ga­tion is ongoing.

This means that any ver­i­fi­ca­tion of my out­go­ing mail will not work, as the data nec­es­sary to ver­i­fy the sig­natur is not available. 🙁