I just updated to a recent -cur­rent and tried the new nullfs. Sock­ets (e.g. the MySQL one) work now with nullfs. No need to have e.g. jails on the same FS and hardlink the socket to not need to use TCP in MySQL (or an IP at all for the jail).

Great work!

Last week­end I com­mit­ted some dummy-syscalls to the lin­ux­u­la­tor in FreeBSD-cur­rent. I also added some com­ments to syscalls.master which should give a hint which linux ker­nel had them for the first time (if the linux man–page I looked this up in is cor­rect). So if some­one wants to exper­i­ment with a higher compat.linux.osrelease than 2.6.16 (as it is needed for a Cen­tOS based linux_base), he should now get some ker­nel mes­sages about unim­ple­mented syscalls instead of a silent failure.

There may be some low-hanging fruits in there, but I did not really ver­ify this by check­ing what the dummy syscalls are sup­posed to do in linux and if we can eas­ily map this to exist­ing FreeBSD fea­tures. In case some­one has a look, please send an email to emu­la­tion@FreeBSD.org.

It seems my HOWTO cre­ate a new linux_base port was not too bad. There is now a PR for a Cen­tOS 6 based linux_base port. I had a quick look at it and it seems that it is nearly usable to include into the Ports Col­lec­tion (the SRPMs need to be added, but that can be done within some minutes).

When FreeBSD 8.3 is released and the Ports Col­lec­tion open for sweep­ing com­mits again, I will ask port­mgr to do a repo-copy for the new port and com­mit it. This is just the linux_base port, not the com­plete infra­struc­ture which is needed to com­pletely replace the cur­rent default lin­ux­u­la­tor user­land. This is just a start. The process of switch­ing to a more recent linux_base port is a long process, and in this case depends upon enough sup­port in the sup­ported FreeBSD releases.

Atten­tion: Any­one installing the port from the PR should be aware that using it is a highly exper­i­men­tal task. You need to change the lin­ux­u­la­tor to imper­son­ate him­self as a linux 2.6.18 ker­nel (described in the pkg-message of the port), and the code in FreeBSD is far from sup­port­ing this. Any­one who wants to try it is wel­come, but you have to run FreeBSD-current as of at least the last week­end, and watch out for ker­nel mes­sages about unsup­ported syscalls. Reports to emulation@FreeBSD.org please, not here on the webpage.

Michael W. Lucas pub­lished his new book “SSH Mas­tery” (no link to an online store, get it from your pre­ferred online or offline one in your part of the world).

Do you think you know a lot about SSH? I thought I did when Michael searched tech­ni­cal proof-readers for this book. I offered to have a look at his work in progress and he gen­tly accepted (while I do not get money for this, I am one of the per­sons he thanks for  the tech­ni­cal review in the begin­ning, so I am involved some­how and as such you should take the fol­low­ing with a grain of salt).

I already had user restric­tions in place before the review, but now I nar­rowed down some restric­tions based upon some con­di­tion­als. I already used SSH tun­nels for var­i­ous things before (where legally applic­a­ble), but I learned some addi­tional VPN tech­niques with SSH. I already used mul­ti­ple ssh-keys for var­i­ous things, but Michael pro­vides some inter­est­ing ways of han­dling a large-volume of ssh-keys over mul­ti­ple machines. … I really hope that my review was as valu­able for Michael, 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 major­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 lit­tle bit of enter­tain­ment in between).

I know a lot of peo­ple which work daily with SSH, and they know only a small part of what is pre­sented in this book. In my opin­ion this book is a must-have for every System/Database/Application/Whatever Admin­is­tra­tor 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­a­bly it will be OpenSSH or a clone of it)) will get some help­ful infor­ma­tion from this book.

I can only rec­om­mend it.

I got a lit­tle bit of time to update my 3 year old work of adding sta­tic DTrace probes to the lin­ux­u­la­tor.

The changes are not in HEAD, but in my linuxulator-dtrace branch. The revi­sion to have a look at is r230910. Included are some DTrace scripts:

• script to check inter­nal locks
• script to trace futexes
• script to gen­er­ate stats for DTracified lin­ux­u­la­tor parts
• script to check for errors:
  • emu­la­tion errors (unsup­ported stuff, unknown stuff, …)
  • ker­nel errors (resource shortage, …)
  • pro­gram­ming errors (errors which can hap­pen if some­one made a mis­take, but should not happen)

The programming-error checks give hints about user­land pro­gram­ming errors respec­tively a hint about the rea­son of error return val­ues due to resource short­age or maybe a wrong com­bi­na­tion of para­me­ters. An exam­ple error mes­sage for this case is “Appli­ca­tion %s issued a sysctl which failed the length restric­tions.nThe length passed is %d, the min length sup­ported is 1 and the max length sup­ported is %d.n”.

The stats-script (tai­lored spe­cially to the lin­ux­u­la­tor, but this can eas­ily be extended to the rest of the ker­nel) can report about:

• num­ber of calls to a ker­nel func­tion per exe­cutable binary (not per PID!): allows to see where an opti­miza­tion would be ben­e­fi­cial for a given application
• graph of CPU time spend in ker­nel func­tions per exe­cutable binary: together with the num­ber of calls to this func­tion this allows to deter­mine if a ker­nel opti­miza­tion would be ben­e­fi­cial / is pos­si­ble for a given application
• graph of longest run­ning (CPU-time!) ker­nel func­tion in total
• tim­ing sta­tis­tics for the emul_lock
• graph of longest held (CPU-time!) locks

Unfor­tu­nately this can not be com­mit­ted to HEAD as-is. The DTrace SDT provider can not han­dle probes which are added to the ker­nel after the SDT provider is already loaded. This means that you either have to com­pile the lin­ux­u­la­tor sta­t­i­cally into the ker­nel, or you have to load the SDT ker­nel mod­ule after the lin­ux­u­la­tor mod­ule is loaded. If you do not respect this, you get a ker­nel panic on first access of one of the providers in the lin­ux­u­la­tor (AFAIR this includes list­ing the probes avail­able in the kernel).