Free DLNA serv­er which works good with my Sony BRAVIA TV

In sev­er­al pre­vi­ous posts I wrote about my quest for the right source format to stream video to my Sony BRAVIA TV (build in 2009). The last week-​end I fi­nally found some­thing which sat­is­fies me.

What I found was ser­viio, a free UPnP-​AV (DLNA) serv­er. It is writ­ten in java and runs on Win­dows, Linux and FreeBSD (it is not lis­ted on the web­site, but we have an not-​so-​up-​to-​date ver­sion in the ports tree). If ne­ces­sary it transcodes the in­put to an ap­pro­pri­ate format for the DLNA ren­der­er (in my case the TV).

I tested it with my slow Net­book, so that I was able to see with which in­put format it will just re­mux the in­put con­tain­er to a MPEG trans­port stream, and which in­put format would be really re-​encoded to a format the TV understands.

The bot­tom line of the tests is, that I just need to use a sup­por­ted con­tain­er (like MKV or MP4 or AVI) with H.264-encoded video (e.g. en­coded by x264) and AC3 audio.

The TV is able to chose between sev­er­al au­dio streams, but I have not tested if ser­viio is able to serve files with mul­tiple au­dio streams (my wife has a dif­fer­ent moth­er lan­guage than me, so it is in­ter­est­ing for us to have mul­tiple au­dio streams for a movie), and I do not know if DLNA sup­ports some­thing like this.

Now I just have to re­place min­idlna (which only works good with my TV for MP3s and Pic­tures) with ser­viio on my FreeBSD file serv­er and we can for­get about the disk-juggling.

What you should know about SSH

Mi­chael W. Lu­cas pub­lished his new book “SSH Mas­tery” (no link to an on­line store, get it from your pre­ferred on­line or off­line one in your part of the world).

Do you think you know a lot about SSH? I thought I did when Mi­chael searched tech­nic­al proof-​readers for this book. I offered to have a look at his work in pro­gress and he gently ac­cep­ted (while I do not get money for this, I am one of the per­sons he thanks for  the tech­nic­al re­view in the be­gin­ning, so I am in­volved some­how and as such you should take the fol­low­ing with a grain of salt).

I already had user re­stric­tions in place be­fore the re­view, but now I nar­rowed down some re­stric­tions based upon some con­di­tion­als. I already used SSH tun­nels for vari­ous things be­fore (where leg­ally ap­plic­able), but I learned some ad­di­tion­al VPN tech­niques with SSH. I already used mul­tiple ssh-​keys for vari­ous things, but Mi­chael provides some in­ter­est­ing ways of hand­ling a large-​volume of ssh-​keys over mul­tiple ma­chines. … I really hope that my re­view was as valu­able for Mi­chael, as it was for me to do the review.

He ends the book with “You now know more about SSH, OpenSSH and Putty than the vast ma­jor­ity of IT pro­fes­sion­als! Con­grat­u­la­tions”, and this is true, and all that in his writ­ing style where you can come with a prob­lem, read about it, and leave with a solu­tion (nor­mally with a little bit of en­ter­tain­ment in between).

I know a lot of people which work daily with SSH, and they know only a small part of what is presen­ted in this book. In my opin­ion this book is a must-​have for every System/​Database/​Application/​Whatever Ad­min­is­trat­or in charge of some­thing on an UNIX-​like sys­tem, and even “nor­mal users” of SSH (no mat­ter if they use PuTTY, or a ssh com­mand line pro­gram on an UNIX-​like sys­tem (most prob­ably it will be OpenSSH or a clone of it)) will get some help­ful in­form­a­tion from this book.

I can only re­com­mend it.

Tun­ing guide in the wiki

In the light of the re­cent bench­mark dis­cus­sion, a vo­lun­teer im­por­ted the tun­ing man-​page in­to the wiki. Some com­ments at some places for pos­sible im­prove­ments are already made. Please go over there, have a look, and par­ti­cip­ate please (testing/​verification/​discussion/​improvements/​…).

As al­ways, feel free to re­gister with First­nameLast­name and tell a FreeBSD com­mit­ter to add you to the con­trib­ut­ors group for write ac­cess (you also get the be­ne­fit to be able to re­gister for an email no­ti­fic­a­tion for spe­cif­ic pages).

HOWTO add linux-​infrastructure ports for a new linux_​base port

In my last blog-​post I de­scribed how to cre­ate a new linux_​base port. This blog-​post is about the oth­er Linux-ports which make up the Linux-in­fra­struc­ture in the FreeBSD Ports Col­lec­tion for a giv­en Linux-release.

What are linux-​infrastructure ports?

A linux_​base port con­tains as much as pos­sible and at the same time as little as pos­sible to make up a use­ful Linux-​compatibility-​experience in FreeBSD. I know, this is not a de­script­ive ex­plan­a­tion. And it is not on pur­pose. There are no fixed rules what has to be in­side or what not. It “ma­tured” in­to the cur­rent shape. A prac­tic­al ex­ample is, that there is no GUI-stuff in the linux_​base. While you need the GUI parts like GTK or QT for soft­ware like Skype and acror­ead, you do not need them for head­less game serv­ers. While you may need vari­ous lib­rar­ies for game serv­ers, you may not need those for Skype or acror­ead. As such some stand­ard parts are in sep­ar­ate ports which are named linux-LINUX_​DIST_​SUFFIX-NAME. For GTK and the Fe­dora 10 re­lease this res­ults in linux-​f10-​gtk2. Such gen­er­ic ports which de­pend upon a spe­cif­ic Linux-​release make up the Linux-​infrastructure in the FreeBSD Ports Col­lec­tion. Those ports are ref­er­enced in port-​Makefiles via the USE_​LINUX_​APPS vari­able, e.g. USE_LINUX_APPS=gtk2.

If you cre­ated a new linux_​base port, you need most stand­ard in­fra­struc­ture ports in a ver­sion for the Linux-​release used in the linux_​base port, to have the Linux-​application ports in the FreeBSD Ports Col­lec­tion work­ing (if you are un­lucky, some ports do not play well with the Linux-​release you have chosen, but this is out of the scope of this HOWTO).

Up­dat­ing Mk/

 First we need to set the LINUX_​DIST_​SUFFIX vari­able to a value suit­able to the new Linux-​release. This is done in the con­di­tion­al which checks the OVERRIDE_​LINUX_​NONBASE_​PORTS vari­able for val­id val­ues. Add an ap­pro­pri­ate con­di­tion­al, and do not for­get to add the new val­id value to the IGNORE line in the last else branch of the conditional.

The next step is to check the _​LINUX_​APPS_​ALL and _​LINUX_​26_​APPS vari­ables. If there are some in­fra­struc­ture ports which are not avail­able for the new Linux-​release, the con­di­tion­al which checks the avail­ab­il­ity of a giv­en in­fra­struc­ture port for a giv­en Linux-​release needs to be mod­i­fied. If at a later step you no­tice that there are some ad­di­tion­al in­fra­struc­ture ports ne­ces­sary for the new Linux-​release, _​LINUX_​APPS_​ALL and the check-​logic needs to be mod­i­fied too (e.g. add a new vari­able for your Linux-​release, add the con­tent of the vari­able to _​LINUX_​APPS_​ALL, and change the check to do the right thing).

After that two te­di­ous parts need to be done.

For each in­fra­struc­ture port there is a set of vari­ables. The name_​PORT vari­able con­tains the loc­a­tion of the port in the Ports Col­lec­tion. Typ­ic­ally you do not have to change it (if you really want to change it, do not do it, fix the nam­ing of the in­fra­struc­ture port in­stead), be­cause we use a nam­ing con­ven­tion here which in­cludes the LINUX_​DIST_​SUFFIX. The name_​DETECT vari­able is an in­tern­al vari­able, do not change it (if you cre­ate a new in­fra­struc­ture port, copy it from some­where else and make sure the name in value of the vari­able matches the port name in the name of the vari­able). Then there are sev­er­al name_​suf­fix_​FILE vari­ables. Leave the ex­ist­ing ones alone, and add a new one with the cor­rect suf­fix for your new Linux-​release. The value of the vari­able needs to be an im­port­ant file which is in­stalled by the in­fra­struc­ture port in ques­tion. FYI: The con­tent of the name_​suf­fix_​FILE vari­ables are used to set the name_​DETECT vari­ables, de­pend­ing on the Linux-​relase the name_​DETECT vari­ables are used to check if the port is already in­stalled. Ideally the name_​suf­fix_​FILE vari­able points to a lib­rary in the port. The name_​DEPENDS vari­able lists de­pend­en­cies of this in­fra­struc­ture port. If the de­pend­en­cies changed in your Linux-​release, you need to add a con­di­tion­al to change the de­pend­ency if LINUX_​DIST_​SUFFIX is set to your Linux-release.

Nor­mally this is all what needs to be done in PORTSDIR/Mk/, the rest of the file is code to check de­pend­en­cies and some cor­rect­ness checks.

The second te­di­ous part is to ac­tu­ally cre­ate all those in­fra­struc­ture ports. Nor­mally you can copy an ex­ist­ing in­fra­struc­ture port, re­name it, ad­just the PORTNAME, PORTVERSION, PORTREVISION, MASTER_​SITES, PKGNAMEPREFIX, DISTFILES, CONFLICTS (also in all oth­er Linux-​release ver­sions of this in­fra­struc­ture port), LINUX_​DIST_​VER, RPMVERSION (if set/​neccesary) and SRC_​DISTFILE vari­ables, gen­er­ate the dist­file check­sums (make make­sum), and fix the plist. I sug­gest to script parts of this work (as of this writ­ing Fresh­ports counts 68 ports where the port­name starts with linux-f10-).

Adding new in­fra­struc­ture ports, or re­mov­ing in­fra­struc­ture ports for a giv­en Linux-release

If your Linux-​release does not come with a pack­age for an ex­ist­ing in­fra­struc­ture port, just do not cre­ate a cor­res­pond­ing name_​suf­fix_​FILE line. You still need to do the right thing re­gard­ing de­pend­en­cies of ports which de­pend upon this non-​existing in­fra­struc­ture port (if your Linux-​release comes with pack­ages for them).

To add a new in­fra­struc­ture port, copy an ex­ist­ing block, re­name the vari­ables, set them cor­rectly, add a new vari­able for your Linux-​release in the first _​LINUX_​APPS_​ALL sec­tion, add the con­tent of this vari­able to _​LINUX_​APPS_​ALL, and change the check-​logic as de­scribed above.

Fi­nal words

If you have some­thing which in­stalls and dein­stalls cor­rectly, feel free to provide it on freebsd-​emulation@​FreeBSD.​org for re­view/​testing. If you have ques­tions dur­ing the port­ing, feel also free to send a mail there.

HOWTO cre­ate a new linux_​base port

FreeBSD is in need of a new linux_​base port. It is on my TODO list since a long time, but I do not get the time to cre­ate one. I still do not have the time to work on a new one, but when you read this, I man­aged to get the time to cre­ate a HOWTO which de­scribes what needs to be done to cre­ate a new linux_​base port.

I will not de­scribe how to cre­ate a new linux_​base port from scratch, I will just de­scribe how you can copy the last one and up­date it to some­thing new­er based upon the ex­ist­ing in­fra­struc­ture for RPM packages.

Spe­cif­ic ques­tions which come up dur­ing port­ing a new Linux re­lease should be asked on freebsd-​emulation@​FreeBSD.​org,  there are more people which can an­swer ques­tions than here in my blog. I will add use­ful in­form­a­tion to this HOWTO if necessary.

In the easy case most of the work is search­ing the right RPMs and their de­pend­en­cies to use, and to cre­ate the plist.

Why do we need a new linux_​base port?

The cur­rent linux_​base port is based upon Fe­dora 10, which is end of life since Decem­ber 2009. Even Fe­dora 13 is already end of life. Fe­dora 16 is sup­posed to be re­leased this year. From a sup­port point of view, Fe­dora 15 or maybe even Fe­dora 16 would be a good tar­get for the next linux_​base port. Oth­er al­tern­at­ives would be to use an ex­ten­ded life­time re­lease of an­oth­er RPM based dis­tri­bu­tion, like for ex­ample Cen­tOS 6 (which seems to be based upon Fe­dora 12 with back­ports from Fe­dora 13 and 14). Us­ing a Linux re­lease which is told to be sup­por­ted for at least 10 years, sounds nice from a FreeBSD point of view (only minor changes to the linux ports in such a case, in­stead of cre­at­ing a com­plete new linux_​base each N+2 re­leases like with Fe­dora), but it also means ad­di­tion­al work if you want to cre­ate the first linux_​base port for it.

The mys­ter­ies you have to con­quer if you want to cre­ate a new linux_​base port

What we do not know is, if Fe­dora 15/​16, Cen­tOS 6, or any oth­er Linux re­lease will work in a sup­por­ted FreeBSD re­lease. There are two ways to find this out.

The first one is to take an ex­ist­ing Linux sys­tem, ch­root in­to it (either via NFS or after mak­ing a copy in­to a dir­ect­ory of a FreeBSD sys­tem), and to run a lot of pro­grams (acror­ead, skype, shells, scripts, …). The LTP test­suite is not that much use­ful here, as it will test mostly ker­nel fea­tures, but we do not know which ker­nel fea­tures are man­dat­ory for a giv­en user­land of a Linux release.

The second way of test­ing if a giv­en Linux re­lease works on FreeBSD is to ac­tu­ally cre­ate a new linux_​base port for it and test it without chrooting.

The first way is faster, if you are only in­ter­ested in test­ing if some­thing works. The second way provides an easy to setup test­bed for FreeBSD ker­nel de­velopers to fix the Linuxu­lat­or so that it works with the new linux_​base port. Both ways have their mer­its, but it is up to the per­son do­ing the work to de­cide which way to go.

The meat: HOWTO cre­ate a new linux_​base port

First off, you need a sys­tem (or a jail) without any linux_​base port in­stalled. After that you can cre­ate a new linux_​base port (= lbN), by just mak­ing a copy of the latest one (= lbO). In lbN you need to add lbO as a CONFLICT, and in all oth­er ex­ist­ing linux_​base ports, you need to add lbN as a conflict.

Change the PORTNAME, PORTVERSION, re­set the PORTREVISION in lbN, and set LINUX_​DIST_​VER  to the new Linux-​release ver­sion in the lbN Make­file (this is used in PORTSDIR/Mk/ and PORTSDIR/Mk/

If you do not stay with Fe­dora, there is some more work to do be­fore you can have a look at chos­ing RPMs for in­stall­a­tion. You need to have a look at PORTSDIR/Mk/ and add some cases for the new LINUX_​DIST you want to use. Do not for­get to set LINUX_​DIST in the lbN Make­file to the name of the dis­tri­bu­tion you use. You also need to aug­ment the LINUX_​DIST_​VER check in PORTSDIR/Mk/ with some LINUX_​DIST con­di­tion­als. If you are lucky, the dir­ect­ory struc­ture for down­loads is sim­il­ar to the Fe­dora struc­ture, and there is not a lot to do here.

When this is done, you can have a look at the BIN_​DISTFILES vari­able in the lbN Make­file. Try to find sim­il­ar RPMs for the new Linux re­lease you want to port. Some may not be avail­able, and it may also be the case that dif­fer­ent ones are needed in­stead. I sug­gest to first work with the ones which are avail­able (make make­sum, test in­stall and cre­ate plist). After that you need to find out what the re­place­ment RPMs for non-​existing ones are. You are on your own here. Search around the net, and/​or have a look at the de­pend­en­cies in the RPMs of lbO to de­term­ine if some­thing was ad­ded as a de­pend­ency of some­thing else or not (if not, for­get about it ATM). When you man­aged to find re­place­ment RPMs, you can now have a look at the de­pend­en­cies of the RPMs in lbN. Do not add blindly all de­pend­en­cies, not all are needed in FreeBSD (the linux_​base ports are not sup­posed to cre­ate an en­vir­on­ment which you can ch­root in­to, they are sup­posed to aug­ment the FreeBSD sys­tem to be able to run Linux pro­grams in ports like they where FreeBSD nat­ive pro­grams). What you need in the linux_​base ports are lib­rar­ies, con­fig and data files which do not ex­ist in FreeBSD or have a dif­fer­ent syn­tax than in FreeBSD (those con­fig or data files which are just in a dif­fer­ent place, can be sym­linked), and ba­sic shell com­mands (which com­mands are needed or not… well… good ques­tion, in the past we made de­cisions what to in­clude based upon prob­lem re­ports from users). Now for the things which are not avail­able and where not ad­ded as a de­pend­ency. Those are things which are either used dur­ing in­stall, or where use­ful to have in the past. Find out by what it was re­placed and have a look if this re­place­ment can eas­ily be used in­stead. If it can be used, add it. If not, well… bad luck, we (the FreeBSD com­munity) will see how to handle this somehow.

If you think that you have all you need in BIN_​DISTFILES, please up­date SRC_​DISTFILES ac­cord­ingly and gen­er­ate the dist­file via  make -DPACKAGE_​BUILDING make­sum to have the check­sums of the sources (for leg­al reas­ons we need them on our mirrors).

The next step is to have a look at REMOVE_​DIRS, REMOVE_​FILES and ADD_​DIRS if some­thing needs to be mod­i­fied. Most of them are there to fall back to the cor­res­pond­ing FreeBSD directories/​files, or be­cause they are not needed at all (REMOVE_​*). Do not re­move dir­ect­or­ies from ADD_​DIRS, they are cre­ated here to fix some edge con­di­tions (I do not re­mem­ber ex­actly why we had to add them, and I do not take the time ATM to search in the CVS history).

If you are lucky, this is all (make sure the plist is cor­rect). If you are not lucky and you need to make some modi­fic­a­tions to files, have a look at the do-​build tar­get in the Make­file, this is the place where some changes are done to cre­ate a nice user experience.

If you ar­rive here while cre­at­ing a new linux_​base port, lean back and feel a bit proud. You man­aged to cre­ate a new linux_​base port. It is not very well tested at this mo­ment, and it is far from everything which needs to be done to have the com­plete Linux in­fra­struc­ture for a giv­en Linux re­lease, but the most im­port­ant part is done. Please no­ti­fy freebsd-​emulation@​FreeBSD.​org and call for testers.

What is missing?

The full Linuxu­lat­or in­fra­struc­ture for the FreeBSD Ports Col­lec­tion has some more ports around a linux_​base port. Most of the in­fra­struc­ture for this is handled in Mk/

UPDATE: I got some time to write how to up­date the Linux-​infrastructure ports.

How I setup a Jail-Host

Every­one has his own way of set­ting up a ma­chine to serve as a host of mul­tiple jails. Here is my way, YMMV.

Ini­tial FreeBSD install

I use sev­er­al hard­disks in a Soft­ware-RAID setup. It does not mat­ter much if you set them up with one big par­ti­tion or with sev­er­al par­ti­tions, feel free to fol­low your pref­er­ences here. My way of par­ti­tion­ing the hard­disks is de­scribed in a pre­vi­ous post. That post only shows the com­mands to split the hard­disks in­to two par­ti­tions and use ZFS for the root­fs. The com­mands to ini­tial­ize the ZFS data par­ti­tion are not de­scribed, but you should be able to fig­ure it out your­self (and you can de­cide on your own what kind of RAID level you want to use). For this FS I set atime, ex­ec and setu­id to off in the ZFS options.

On the ZFS data par­ti­tion I cre­ate a new data­set for the sys­tem. For this data­set I set atime, ex­ec and setu­id to off in the ZFS op­tions. In­side this data­set I cre­ate data­sets for /​home, /​usr/​compat, /​usr/​local, /​usr/​obj, /​usr/​ports/​, /​usr/​src, /​usr/​sup and /​var/​ports. There are two ways of do­ing this. One way is to set the ZFS moun­t­point. The way I prefer is to set re­l­at­ive sym­links to it, e.g. “cd /​usr; ln -s ../​data/​system/​usr_​obj obj”. I do this be­cause this way I can tem­por­ary im­port the pool on an­oth­er ma­chine (e.g. my desktop, if the need arises) without fear to in­ter­fere with the sys­tem. The ZFS op­tions are set as follows:

ZFS op­tions for data/​system/​*



data/​system/​home ex­ec on
data/​system/​usr_​compat ex­ec on
data/​system/​usr_​compat setu­id on
data/​system/​usr_​local ex­ec on
data/​system/​usr_​local setu­id on
data/​system/​usr_​obj ex­ec on
data/​system/​usr_​ports ex­ec on
data/​system/​usr_​ports setu­id on
data/​system/​usr_​src ex­ec on
data/​system/​usr_​sup sec­ond­arycache none
data/​system/​var_​ports ex­ec on

The ex­ec op­tion for home is not ne­ces­sary if you keep sep­ar­ate data­sets for each user. Nor­mally I keep sep­ar­ate data­sets for home dir­ect­or­ies, but Jail-​Hosts should not have users (ex­cept the ad­mins, but they should not keep data in their homes), so I just cre­ate a single home data­set. The setu­id op­tion for the usr_​ports should not be ne­ces­sary if you re­dir­ect the build dir­ect­ory of the ports to a dif­fer­ent place (WRKDIRPREFIX in /etc/make.conf).

In­stalling ports

The ports I in­stall by de­fault are net/​rsync, ports-​mgmt/​portaudit, ports-​mgmt/​portmaster, shells/​zsh, sysutils/​bsdstats, sysutils/​ezjail, sysutils/​smartmontools and sysutils/​tmux.

Ba­sic setup

In the crontab of root I setup a job to do a portsnap up­date once a day (I pick a ran­dom num­ber between 0 and 59 for the minute, but keep a fixed hour). I also have http_​proxy spe­cified in /​etc/​profile, so that all ma­chines in this net­work do not down­load everything from far away again and again, but can get the data from the loc­al cach­ing proxy. As a little watch­dog I have a little @reboot rule in the crontab, which no­ti­fies me when a ma­chine reboots:

@reboot grep “ker­nel boot file is” /​var/​log/​messages | mail -s “„host­name„ re­booted” root >/​dev/​null 2>&1

This does not re­place a real mon­it­or­ing solu­tion, but in cases where real mon­it­or­ing is overkill it provides a nice HEADS-​UP (and shows you dir­ectly which ker­nel is loaded in case a non-​default one is used).

Some de­fault ali­ases I use every­where are:

ali­as portmlist=“portmaster -L | egrep -B1 „(ew|ort) version|Aborting|installed|dependencies|IGNORE|marked|Reason:|MOVED|deleted|exist|update“ | grep -v „^ – “”
ali­as portmclean=“portmaster -t –clean-​distfiles –clean-​packages”
ali­as portmcheck=“portmaster -y –check-​depends”

Ad­di­tion­al devfs rules for Jails

I have the need to give ac­cess to some spe­cif­ic devices in some jails. For this I need to setup a cus­tom /etc/devfs.rules file. The files con­tains some ID num­bers which need to be unique in the sys­tem. On a 9-​current sys­tem the num­bers one to four are already used (see /etc/defaults/devfs.rules). The next avail­able num­ber is ob­vi­ously five then. First I present my devfs.rules entries, then I ex­plain them:

add path „au­dio*“ un­hide
add path „dsp*“ un­hide
add path midistat un­hide
add path „mix­er*“ un­hide
add path „mu­sic*“ un­hide
add path „se­quen­cer*“ un­hide
add path snd­stat un­hide
add path speak­er un­hide

add path „lpt*“ un­hide
add path „ulpt*“ un­hide user 193 group 193
add path „un­lpt*“ un­hide user 193 group 193

add path zfs un­hide

add in­clude $devfsrules_​hide_​all
add in­clude $devfsrules_​unhide_​basic
add in­clude $devfsrules_​unhide_​login
add in­clude $devfsrules_​unhide_​printers
add in­clude $devfsrules_​unhide_​zfs

add in­clude $devfsrules_​hide_​all
add in­clude $devfsrules_​unhide_​basic
add in­clude $devfsrules_​unhide_​login
add in­clude $devfsrules_​unhide_​zfs

The devfs_​rules_​unhide_​XXX ones give ac­cess to spe­cif­ic devices, e.g. all the sound re­lated devices or to loc­al print­ers. The devfsrules_​jail_​XXX ones com­bine all the un­hide rules for spe­cif­ic jail setups. Un­for­tu­nately the in­clude dir­ect­ive is not re­curs­ive, so that we can not in­clude the de­fault devfsrules_​jail pro­file and need to rep­lic­ate its con­tents. The first three in­cludes of each devfsrules_​jail_​XXX ac­com­plish this. The unhide_​zfs rule gives ac­cess to /​dev/​zfs, which is needed if you at­tach one or more ZFS data­sets to a jail. I will ex­plain how to use those pro­files with ez­jail in a follow-​up post.

Jails setup

I use ez­jail to man­age jails, it is more com­fort­able than do­ing it by hand while at the same time al­lows me to do some­thing by hand. My jails nor­mally reside in­side ZFS data­sets, for this reas­on I have setup a spe­cial area (ZFS data­set data/​jails) which is handled by ezjail.The cor­res­pond­ing ezjail.conf set­tings are:


I also dis­abled procfs and fdescfs in jails (but they can be en­abled later for spe­cif­ic jails if necessary).

Un­for­tu­nately ez­jail (as of v3.1) sets the moun­t­point of a newly cre­ated data­set even if it is not ne­ces­sary. For this reas­on I al­ways is­sue a “zfs in­her­it moun­t­point ” after cre­at­ing a jail. This sim­pli­fies the case where you want to move/​rename a data­set and want to have the moun­t­point autom­c­at­ic­ally fol­low the change.

The ac­cess flags of  /​data/​jails dir­ect­ory are 700, this pre­vents loc­al users (there should be none, but bet­ter safe than sorry) to get ac­cess to files from users in jails with the same UID.

After the first create/​update of the ez­jail base­jail the ZFS op­tions of base­jail (data/​jails/​basejail) and new­jail (data/​jails/​newjail) need to be changed. For both ex­ec and setu­id should be changed to “on” The same needs to be done after cre­at­ing a new jail for the new jail (be­fore start­ing it).

The de­fault ez­jail flavour

In my de­fault ez­jail fla­vour I cre­ate some de­fault user(s) with a basesystem-​shell (via /data/jails/flavours/mydef/ezjail.flavour) be­fore the pack­age in­stall, and change the shell to my pre­ferred zsh af­ter­wards (this is only val­id if the jails are used only by in-​house people, if you want to of­fer light­weight vir­tu­al ma­chines to (un­known) cus­tom­ers, the de­fault user(s) and shell(s) are ob­vi­ously up to dis­cus­sion). At the end I also run a “/​usr/​local/​sbin/​portmaster -y –check-​depends” to make sure everything is in a sane state.

For the pack­ages (/​data/​jails/​flavours/​mydef/​pkg/​) I add sym­links to the un­ver­sioned pack­ages I want to in­stall. I have the pack­ages in a com­mon (think about set­ting PACKAGES in make.conf and us­ing PACKAGES/Latest/XYZ.tbz) dir­ect­ory (if they can be shared over vari­ous fla­vours), and they are un­ver­sioned so that I do not have to up­date the ver­sion num­ber each time there is an up­date. The pack­ages I in­stall by de­fault are bsdstats, portaudit, port­mas­ter, zsh, tmux and all their dependencies.

In case you use jails to vir­tu­al­ize ser­vices and con­sol­id­ate serv­ers (e.g. DNS, HTTP, MySQL each in a sep­ar­ate jail) in­stead of provid­ing light­weight vir­tu­al ma­chines to (un­known) cus­tom­ers, there is also a be­ne­fit of shar­ing the dist­files and pack­ages between jails on the same ma­chine. To do this I cre­ate /data/jails/flavours/mydef/shared/ports/{distfiles,packages} which are then moun­ted via null­fs or NFS in­to all the jails from a com­mon dir­ect­ory. This re­quires the fol­low­ing vari­ables in /data/jails/flavours/mydef/etc/make.conf (I also keep the pack­ages for dif­fer­ent CPU types and com­pilers in the same sub­tree, if you do not care, just re­move the “/${CC}/${CPUTYPE}” from the PACAKGES line):

DISTDIR=  /​shared/​ports/​distfiles
PACKAGES= /shared/ports/packages/${CC}/${CPUTYPE}

New jails

A fu­ture post will cov­er how I setup new jails in such a setup and how I cus­tom­ize the start or­der of jails or use some non-​default set­tings for the jail-startup.