Month: March 2011

New DTrace probes for the linuxulator

I for­ward port­ed my DTrace probes for the FreeB­SD lin­ux­u­la­tor from a 2008-current to a recent ‑cur­rent. I have not the com­plete FreeB­SD lin­ux­u­la­tor cov­ered, but a big part is already done. I can check the major locks in the lin­ux­u­la­tor, trace futex­es, and I have a D‑script which yells at a lot of errors which could hap­pen but should not.

Some of my D‑scripts need some changes, as real-world test­ing showed that they are not real­ly work­ing as expect­ed. They can get over­whelmed by the amount of spec­u­la­tion and dynam­ic vari­ables (error mes­sage: dynam­ic vari­able drops with non-empty dirty list). For the dynam­ic vari­ables prob­lem I found a dis­cus­sion on the net with some sug­ges­tions. For the spec­u­la­tion part I expect sim­i­lar tuning-possibilities.

Unfor­tu­nate­ly the D‑script which checks the inter­nal locks fails to com­pile. Seems there is a lit­tle mis­un­der­stand­ing on my side how the D‑language is sup­posed to work.

I try to get some time lat­er to have a look at those problems.

Dur­ing my devel­op­ment I stum­bled over some gener­ic DTrace prob­lems with the SDT provider I use for my probes:

  • If you load the Lin­ux mod­ule after the SDT mod­ule, your sys­tem will pan­ic as soon as you want to access some probes, e.g. “dtrace ‑l” will pan­ic the sys­tem. Load­ing the Lin­ux mod­ule before the SDT mod­ule pre­vents the panic.
  • Unload­ing the SDT mod­ule while the Lin­ux mod­ule with the SDT probes is still loaded pan­ics the sys­tem too. Do not unload the Lin­ux mod­ule if you run with my patch.

Accord­ing to avg@ those are known prob­lems, but I think nobody is work­ing on this. This is bad, because this means I can not com­mit my cur­rent patchset.

If some­one wants to try the new DTrace probes for the lin­ux­u­la­tor, feel free to go to http://www.Leidinger.net/FreeBSD/current-patches/ and down­load linuxulator-dtrace.diff. I do not offer a work­ing hyper­link here on pur­pose, the SDT bugs can hurt if you are not care­ful, and I want to make the use of this patch a strong opt-in because of this. If the patch hurts you, it is your fault, you have been warned.

Share/Save

VDR ports docs

After a quick dis­cus­sion with nox@ I made a copy&paste of his “VDR is com­mit­ted now”-mail into the FreeB­SD wiki. I also re-styled some small parts of it to fit bet­ter into the wiki. It is not per­fect, but already usable. Now inter­est­ed peo­ple can go and improve the docs there.

Thanks to Juer­gen for all his work in this area!

Share/Save

Con­vert­ing from Couri­er IMAP to dove­cot is easy

I have used Couri­er IMAP at home since a long time. As I want to update a dove­cot 1.2 set­up to dove­cot 2.x, I decid­ed to first have a look at dove­cot 2.x at home.

Switch­ing from Couri­er IMAP to dove­cot is real­ly easy. I just con­fig­ured the cor­rect path to the maildir, set­up a passdb/userdb, and it was working.

The impor­tant part was the cor­rect trans­fer of the pass­words. I used already an userdb in Couri­er IMAP with MD5 pass­words. For each user it has imappw=XXX with XXX sim­i­lar to $1$abc.

This can be con­vert­ed into a dove­cot passdb/userdb line very easily:

username:{MD5-CRYPT}$1$abc::UID:GID::HOMEDIR::userdb_mail=maildir:~/path/to/maildir

The cor­re­spond­ing passdb/userdb set­tings for dove­cot are:

passdb {
   args = scheme=MD5-CRYPT username_format=%u /usr/local/etc/dovecot/dovecot.pws
   driver = passwd-file
}
userdb {
   args = username_format=%u /usr/local/etc/dovecot/dovecot.pws
   driver = passwd-file
}

Com­pared to when I had a look the last time, dove­cot is also able to use OTP as an authen­ti­ca­tion mech­a­nism now. Unfor­tu­nate­ly I did not find any doc­u­men­ta­tion how to configure/use it.

Share/Save

Non-default lin­ux base ports deprecated

Yes­ter­day I dep­re­cat­ed the non-default Fedo­ra based Lin­ux base ports. This means fc6, f7, f8 and f9 will van­ish soon (I decid­ed for one month of expiry time). This is because all of them are End of Life upstream since a long time (= no secu­ri­ty updates).

The fc4 and f10 ones are still avail­able – even if they are End of Life too – because FreeB­SD 7.x can not use some­thing new­er than the fc4 one, and we have not test­ed yet a more recent Lin­ux distribution.

Prob­a­bly the most easy way to update the Lin­ux base ports to some­thing new­er is to stay with Fedo­ra (we have a lot of ports-infrastructure for it already). Unfor­tu­nate­ly it is not known if some­thing new­er works with­out prob­lems (miss­ing epoll/inotify sup­port could be a road­block here in case it is exten­sive­ly used in a more recent version).

I want to get some time to have a look if a more recent Fedo­ra ver­sion is suit­able for the use as a Lin­ux base in FreeB­SD 8.x+, but I do not have an esti­mate when I can start and how long it may take. In case some­one already test­ed a more recent Fedo­ra ver­sion feel free to share your experience.

Share/Save
Exit mobile version
%%footer%%