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.

StumbleUponXINGBalatarinBox.netDiggGoogle GmailNetvouzPlurkSiteJotTypePad PostYahoo BookmarksVKSlashdotPocketHacker NewsDiigoBuddyMarksRedditLinkedInBibSonomyBufferEmailHatenaLiveJournalNewsVinePrintViadeoYahoo MailAIMBitty BrowserCare2 NewsEvernoteMail.RuPrintFriendlyWaneloYahoo MessengerYoolinkWebnewsStumpediaProtopage BookmarksOdnoklassnikiMendeleyInstapaperFarkCiteULikeBlinklistAOL MailTwitterGoogle+PinterestTumblrAmazon Wish ListBlogMarksDZoneDeliciousFlipboardFolkdJamespotMeneameMixiOknotiziePushaSvejoSymbaloo FeedsWhatsAppYouMobdiHITTWordPressRediff MyPageOutlook.comMySpaceDesign FloatBlogger PostApp.netDiary.RuKindle ItNUjijSegnaloTuentiWykopTwiddlaSina WeiboPinboardNetlogLineGoogle BookmarksDiasporaBookmarks.frBaiduFacebookGoogle ClassroomKakaoQzoneSMSTelegramRenrenKnownYummlyShare/​Save

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 local 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 local 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­eral 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 never) 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 brother de­cided to move to a new server 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­gether a new ISP where he either could host his server, or get a root­server for a good price (the idea was to have my do­main in a jail on a server of the com­pany of my brother, and we share the costs for it). We found Man­itu (the owner 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­ilar) 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 brother 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…”).

HOWTO

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­server 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­eral 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:

ROOTFS_SIZE=5G
ROOTFS_NAME=root0
FILENAME=rootfs

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­tainer 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 rootfs:

# 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}
newfs –U /dev/mirror/${ROOTFS_NAME}a

Mount the new rootfs 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 other 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 shorter, 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 in­stall, the im­age can be un­moun­ted:

umount /​mnt

The fi­nal steps are to lo­gin into 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 into the pipe above. This way you could even use an HTTP server 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 other 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 cover 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 “newfs” 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 manual way via “mount /​place/​where/​it/​is/​mounted” after adding it to the fstab, not the com­plete manual 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 rootfs (“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­tional road-​block in some cases and may pre­vent some ma­li­cious be­ha­vior… 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 suhosin. They also fail to list other 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 suhosin.ex­ecutor.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 outgoing-alex._domainkey.leidinger.net 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 other 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 verify the sig­na­tur is not avail­able. :(