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).