Doxy­gen stuff up­dated in 9-​current

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

So any­one who wants to gen­er­ate the Doxy­gen docs of some FreeBSD 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 ex­ist­ing Doxyfile-* files – keep the same nam­ing scheme – and change the con­tents. Everything else is handled auto­mat­ic­ally.

I also ad­ded a link to the FreeBSD wiki. It is not at a prom­in­ent place (near the end of the main page), but at least someone can find the link to the my FreeBSD-doxy­gen page there.

HOWTO: “Blind” re­mote in­stall of FreeBSD via tiny disk im­age

In this post I write how to in­stall FreeBSD on a re­mote linux sys­tem by cre­at­ing a root im­age pre­pared for mir­ror­ing on a loc­al sys­tem. There is no (free) ac­cess to the re­mote con­sole, only ac­cess via ssh.

In this post I write how to in­stall FreeBSD on a re­mote linux sys­tem by cre­at­ing a root im­age pre­pared for mir­ror­ing on a loc­al sys­tem. There is no (free) ac­cess to the re­mote con­sole, only ac­cess via ssh.

Back­ground story

While I was at the uni­ver­sity, I worked re­motely for an ISP (ad­min­is­tra­tion of sev­er­al FreeBSD sys­tems). Dur­ing this time I star­ted to use my own do­main, and I was al­lowed to host it dir­ectly 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 provide some­thing which at­trac­ted too much people to keep the band­with on a sane level. After the uni­ver­sity I was still avail­able to an­swer ques­tions, and I was still al­lowed to host my web­site there for free. As the num­ber of ques­tions can be coun­ted with IIRC one hand since then, I de­cided at some point (re­cently, to be ex­act – 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 ex­pect to get much ques­tions from them).

At the same time my broth­er de­cided to move to a new serv­er hoster, as his old one de­cided to in­crease the amount of money cus­tom­ers have to pay for the ser­vice. So we searched to­geth­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 do­main in a jail on a serv­er of the com­pany of my broth­er, and we share the costs for it). We found Man­itu (the own­er has even a blog about his busi­ness), which is even not far away from my place.

Un­for­tu­nately they do not provide FreeBSD pre­in­stalled on their root­serv­ers, but they of­fer a re­mote res­cue sys­tem (read: boot­ing a linux im­age… I as­sume via PXE or sim­il­ar) and we knew someone who has some serv­ers 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 im­age, put it on the hard­disk over the net­work via the re­mote res­cue sys­tem, and then to con­fig­ure the re­mainder of the harddisk(s) to use it. And here is how I did it (my broth­er thought “who is bet­ter suited to in­stall a FreeBSD sys­tem re­motely without ac­cess to the con­sole of the ma­chine (the ISP of­fers to hook up a KVM switch, but only dur­ing busi­ness hours and you have to pay for it) than one of the de­velopers of FreeBSD…”).


In the title of this post I wrote “via a tiny disk im­age”. This is true for a suit­able defin­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 needed, but as this is only 3% of one hard­disk, I prefer to keep it a little bit big­ger than too small after an re­mote up­date or two. The ma­chine has 2 GB of RAM. We do not ex­pect much ker­nel pan­ics (= crash dumps) there, so we do not really 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 ma­chine you are in “trouble” when you need even the same amount of swap than RAM). I de­cided to go with 1 GB of swap (mirrored too, to pre­vent a hard­disk fail­ure to take down the ma­chine), 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 im­age over the net­work to in­stall a sys­tem is not really some­thing I want to do. I would prefer to trans­fer less than 500 MB (that is 0.3% of the en­tire disk) to get this job done, and this is feas­ible. Due to an er­ror or two I had to trans­fer the im­age sev­er­al times un­til everything was work­ing, so it was more in the area of maybe 2 GB (~1% of the en­tire 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:


Then change your cur­rent dir­ect­ory to a place where you have enough space for the im­age. There we will cre­ate a con­tain­er for the im­age, and make it ready for par­ti­tion­ing:

trun­cate -s ${ROOTFS_​SIZE} ${FILENAME}
md­con­fig -a -t vnode -f ${FILENAME}

Cre­ate the root­fs:

# cre­ate one act­ive FreeBSD slice with $ROOTFS_​SIZE GB
fdisk -e /​dev/​mdX
gmir­ror la­bel ${ROOTFS_​NAME} /​dev/​mdXsY
bsdla­bel -w /​dev/​mirror/​${ROOTFS_​NAME}
# cre­ate an “a”-partition for everything
bsdla­bel -e /​dev/​mirror/​${ROOTFS_​NAME}
new­fs -U /dev/mirror/${ROOTFS_NAME}a

Mount the new root­fs to /​mnt and in­stall FreeBSD:

mount /dev/mirror/${ROOTFS_NAME}a /​mnt
cd /​usr/​src
make build­world >&! buildworld.log
make buildker­nel >&! build_generic.log
make in­stall­world DESTDIR=/mnt
make dis­tri­bu­tion DESTDIR=/mnt
make in­stallker­nel DESTDIR=/mnt

Now you need to cre­ate /mnt/etc/rc.conf (set the de­faultrouter, the IP ad­dress 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 lo­gin re­motely, and maybe oth­er things you are in­ter­ested in), /mnt/etc/resolv.conf, /​mnt/​etc/​hosts. Fi­nally, 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 root­fs to the fstab:

cat > /mnt/boot/loader.conf «EOT
echo “/​dev/​mirror/​root0a /​ ufs rw,noatime 1 1” >/​mnt/​etc/​fstab

Now we are ready to in­stall, the im­age can be un­moun­ted:

umount /​mnt

The fi­nal steps are to lo­gin in­to the res­cue con­sole (the­or­et­ic­ally 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 re­motely to force a re­boot) of the new sys­tem and to in­stall via a com­pressed ssh con­nec­tion (my re­mote res­cue sys­tem is a linux sys­tem, so linux-​syntax has to be used). The lo­gin to the res­cue con­sole is not shown here, but the in­stall from the re­mote sys­tem is simple (this as­sumes the im­age resides on a sys­tem which is ac­cess­ible from the new sys­tem):

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

Al­tern­at­ively you can com­press it with bzip2 on your sys­tem and add an bunzip2 in­to 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 stdout. Both ways of trans­fer­ring the im­age de­pend upon the sta­bil­ity 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 in­de­pend­ent from the con­tent of the hard­disk, you bet­ter have a plan B.

If I did not make an er­ror here (I did this some months ago, I hope I did not for­get to write down some im­port­ant step and also cor­rec­ted all steps which where not writ­ten down cor­rectly), you did everything cor­rectly too, and the re­mote sys­tem does not need oth­er ker­nel mod­ules loaded, you can now re­boot the new sys­tem, cross your fin­gers for some mo­ments, and then lo­gin to the new sys­tem.

Post in­stall TODO

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

I ad­ded two more FreeBSD 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 en­tire hard­disk and not only the last par­ti­tion) as one big par­ti­tion. For the second hard­disk I made the same par­ti­tion­ing as for the first hard­disk.

Then I cre­ated 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­ated with the op­tion “-F”, to not syn­chron­ize the par­ti­tion after a power fail­ure (not ne­ces­sary for swap). All two I also cre­ated with the “-n” op­tion, 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 “bsdla­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 do­ing a “new­fs” off course).

To be sure it will sur­vive a re­boot, do a quick test of manu­ally mount­ing the big par­ti­tion (use the easy manu­al way via “mount /​place/​where/​it/​is/​mounted” after adding it to the fstab, not the com­plete manu­al way, this is meant to test the fstab entry too), and a “swa­pon -a” to test the swap. I also made a re­boot test, just to be sure everything is ok.

The fi­nal step was to add the par­ti­tion on the second hard­disk to the root­fs (“gmir­ror in­sert ${ROOTFS_​NAME} /​dev/​…”).

WP plu­gins and PHP safe_​mode

Ob­vi­ously a lot of WP plu­gin au­thors do not check if their plu­gin is PHP safe_​mode/​open_​basedir com­pat­ible. Yes, I know, it is de­prec­ated and does not of­fer 100% safety, but it is at least an ad­di­tion­al road-​block in some cases and may pre­vent some ma­li­cious be­ha­vi­or… If I can choice between 100% break-​in pos­sib­il­ity and <100% break-​in pos­sib­il­ity, I chose the later.

I also think most of them also do not check with suhos­in. They also fail to list oth­er PHP ex­ten­sion re­quire­ments most of the time, they just as­sume you have a full in­stall.

  • quick­stats wants the PHP ctype ex­ten­sion, does not seem to play well with sql.safe_mode while the rest of WP does not seem to have an ob­vi­ous prob­lem with it
  • wp-​stats–dash­board wants the PHP curl and json ex­ten­sion (curl does not play well with safe_​mode or open_​basedir => needs to be dis­abled), needs suhos­in.ex­ecut­or.include.max_traversal set to 6; still does not work 100% cor­rect, I de­leted the cache dir­ect­ory con­tents to let it re­cre­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 ex­ten­sion
  • broken-​link-​checker tries to write to /​var/​tmp/​ (safe_​mode/​open_​basedir in­com­pat­ible)
  • one-​time-​password does not play well with safe_​mode/​open_​basedir
  • smart­linker tells me that the vari­able cook­i­eString is not defined

DNS prob­lem (Do­main­Key TXT entry)

The TXT entry which worked for a long time sud­denly stopped be­ing de­livered by named (thanks to Henri Hen­nebert for the HEADS-​UP). Every oth­er query I try works so far, it is really just this one entry (re­solve timeout). I no­ti­fied the re­spons­ible per­son, in­vest­ig­a­tion is on­go­ing.

This means that any veri­fic­a­tion of my out­go­ing mail will not work, as the data ne­ces­sary to veri­fy the sig­na­tur is not avail­able. 🙁

EMC^2/Legato Net­work­er status

The up­date to went fine. No ma­jor prob­lems en­countered. So far we did not see any re­gres­sions. The com­plete sys­tem feels a little bit more stable (no re­starts ne­ces­sary so far, be­fore some where ne­ces­sary from time to time). We still have to test all our prob­lem cases:

  • re­start NW-​server dir­ectly after de­let­ing a cli­ent with in­dex entries (manu­al copy of /​nsr needed be­fore, in case the me­diadb cor­rup­tion bug is not fixed as prom­ised)
  • shut­down a stor­age node to test if the NW-​server still crashes in this case
  • start with an empty me­diadb but pop­u­lated cli­ents (empty /​nsr/​mm, but un­touched /​nsr/​res) and scan some tapes to check if “shad­ow cli­ents” (my term for cli­ents which have the same cli­ent ID but get newly cre­ated dur­ing the scan­ning with a new cli­ent ID and a name of “~<original-name>-<number>”) still get cre­ated in­stead of pop­u­lat­ing the in­dex of the cor­rect cli­ent

The first two ones are sup­posed to be fixed, the last one is maybe not fixed.

Not fixed (ac­cord­ing to the sup­port) is the prob­lem of need­ing a re­start of the NW-​server when mov­ing a tape lib­rary from one stor­age node to an­oth­er stor­age node. It also seems that our prob­lem with the manu­al clon­ing of save sets is not solved. There are still some clone pro­cesses which do not get out of the “serv­er busy” loop, no mat­ter how idle the NW-​server is. In this case it can be seen that ns­r­clone is wait­ing in nanosleep (use pstack or dtrace to see it). The strange thing is, that a safe set which is “fail­ing” with such be­ha­vi­or will al­ways cause this be­ha­vi­or. We need to have a deep­er look to see if we find sim­il­ar­it­ies between such safe sets and dif­fer­ences to safe sets which can be cloned without prob­lems.

Daily doxy­gen gen­er­ated docs of the FreeBSD ker­nel (head)

I man­aged to get some time to setup an auto­mated gen­er­a­tion of the doxy­gen docs for ker­nel sub­sys­tems of FreeBSD on my web­serv­er.

Every night/​morning (Ger­man timezone) the sources will be up­dated, and the docs get re­gen­er­ated (this takes some time). Cur­rently this de­pends upon some patches to the make­file and doxy­gen con­fig files in tools/​kerneldoc/​subsys. Everything is gen­er­ated dir­ectly in the place where the web­serv­er will look for to de­liv­er the pages, so if you browse this in the middle of the gen­er­a­tion, the con­tent may not be con­sist­ent (yet).

Please be nice to the web­serv­er and do not mir­ror this. You can gen­er­ate this your­self very easy. As­sum­ing you have the FreeBSD source on a loc­al hard disk, you just need to down­load the patch from http://​www​.Leidinger​.net/​F​r​e​e​B​S​D​/​c​u​r​r​e​n​t​-​p​a​t​c​h​es/ (if you do not find dox.diff, up­date your FreeBSD sources and everything will be OK), ap­ply the patch, cd in­to tools/​kerneldoc/​subsys and run “make all” (or “make vm” or whatever you are in­ter­ested in). You need doxy­gen in­stalled, off course.

If you want to setup some­thing like this your­self, just down­load the script which is do­ing all the work, change some vari­ables in the be­gin­ning, and cre­ate your own loc­al ver­sion of the com­plete docs.

In case this is us­ing sig­ni­fic­ant traffic, I will ask core/​ad­mins if there is the pos­sib­il­ity to host it on re­sources.