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 pack­ages.

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 ne­ces­sary.

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 re­lease.

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 ch­root­ing.

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 con­flict.

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 some­how.

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 mir­rors).

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 his­tory).

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 ex­per­i­ence.

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 test­ers.

What is miss­ing?

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.

Rants about JASS (Sol­ar­is Se­cur­ity Toolkit)

Re­cently I switched to a new cli­ent where the Sol­ar­is Se­cur­ity Toolkit (JASS) is ex­tens­ively used. I am now in the pro­cess of up­dat­ing some things, among them are JET and JASS. As part of this work I ree­valu­ate the loc­al JASS modi­fic­a­tions. Pre­vi­ously a cus­tom JASS pack­age was used, but in case JASS is up­dated by Or­acle at some point in time (and an up­date is really needed, see be­low), this would need some amount of work to find out the dif­fer­ences and to for­ward port them to the new ver­sion. If everything is well doc­u­mented, this should not be hard to do, but the per­son do­ing the work also needs to find the up-​to-​date docs.

To make it more easy I de­cided to change this. I now in­stall the of­fi­cial JASS pack­age via JET to­geth­er with the latest patch for it, and then let JET copy our modi­fic­a­tions over the in­stalled pack­age. In­stead of modi­fy­ing ex­ist­ing drivers, I cre­ated our own drivers with a ref­er­ence to the driver which served as a base.

While do­ing this I en­countered sev­er­al short­com­ings of JASS on Sol­ar­is 10.

There are sev­er­al FS based checks which do not make sense to do for the FS of zones in a glob­al zone (at least not the way I use JASS, so maybe a con­fig­ur­able way of chan­ging the be­ha­vi­or should serve for every­one). If zones are in­stalled in /​zones, you do not need to check for files without val­id UIDs (you surely find a lot of files, as the users are defined in­side the zones and not in the glob­al zone) or sim­il­ar things (even not for world writ­able files, as the zones are in­stalled in a root-​access-​only sub­tree and in­side the zones there may be oth­er se­cur­ity con­straints con­figured in­side JASS, read: it is the re­spons­ib­il­ity of JASS in­side the zone to do this). An easy solu­tion would be to ex­clude those FS which con­tain zones (and as we only have one sub­tree, I just hard­coded this in sev­er­al scripts).

I also miss the pos­sib­il­ity (maybe I over­looked a simple way) for the ssh check to lim­it the Al­low­Root­Lo­gin to spe­cif­ic hosts. JASS only checks yes or no, but can not lim­it it to spe­cif­ic hosts (e.g. via “Match IP/​hostname”). Of­ten you do not need to per­mit root-​logins (RBAC/​sudo/​…), but some­times it is the only way to handle a par­tic­u­lar edge-​case (or to speed up an ac­tion dra­mat­ic­ally), and in such cases you do not want to al­low root-​logins more than ne­ces­sary.

Not much free time…

I am work­ing for a new cli­ent now, where I have more things to take care about. This re­duces a bit the pos­sib­il­ity to write some in­ter­est­ing things here.

There are some things I would like to doc­u­ment here, some more ex­per­i­ences with An­droid and cus­tom cer­ti­fic­ates, some things about Sol­ar­is, and oth­er stuff. Un­for­tu­nately the day has only 24 hours.