Alexander Leidinger

Just another weblog

Mar
28

New DTrace probes for the linuxulator

I for­ward ported my DTrace probes for the FreeBSD lin­ux­u­la­tor from a 2008-current to a recent –cur­rent. I have not the com­plete FreeBSD 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 futexes, 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 really work­ing as expected. They can get over­whelmed by the amount of spec­u­la­tion and dynamic vari­ables (error mes­sage: dynamic vari­able drops with non-empty dirty list). For the dynamic 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­nately 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 later to have a look at those problems.

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

  • If you load the Linux mod­ule after the SDT mod­ule, your sys­tem will panic as soon as you want to access some probes, e.g. “dtrace –l” will panic the sys­tem. Load­ing the Linux mod­ule before the SDT mod­ule pre­vents the panic.
  • Unload­ing the SDT mod­ule while the Linux mod­ule with the SDT probes is still loaded pan­ics the sys­tem too. Do not unload the Linux 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.

GD Star Rat­ing
load­ing…
GD Star Rat­ing
load­ing…
Share/Save

Tags: , , , , , , , , ,
Mar
28

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 FreeBSD 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­ested peo­ple can go and improve the docs there.

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

GD Star Rat­ing
load­ing…
GD Star Rat­ing
load­ing…

Tags: , , , ,
Mar
23

Con­vert­ing from Courier IMAP to dove­cot is easy

I have used Courier IMAP at home since a long time. As I want to update a dove­cot 1.2 setup to dove­cot 2.x, I decided to first have a look at dove­cot 2.x at home.

Switch­ing from Courier IMAP to dove­cot is really easy. I just con­fig­ured the cor­rect path to the maildir, setup 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 Courier IMAP with MD5 pass­words. For each user it has imappw=XXX with XXX sim­i­lar to $1$abc.

This can be con­verted 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­nately I did not find any doc­u­men­ta­tion how to configure/use it.

GD Star Rat­ing
load­ing…
GD Star Rat­ing
load­ing…

Tags: , , , , , , , , ,
Mar
01

Non-default linux base ports deprecated

Yes­ter­day I dep­re­cated the non-default Fedora based Linux base ports. This means fc6, f7, f8 and f9 will van­ish soon (I decided for one month of expiry time). This is because all of them are End of Life upstream since a long time (= no secu­rity updates).

The fc4 and f10 ones are still avail­able — even if they are End of Life too — because FreeBSD 7.x can not use some­thing newer than the fc4 one, and we have not tested yet a more recent Linux dis­tri­b­u­tion.

Prob­a­bly the most easy way to update the Linux base ports to some­thing newer is to stay with Fedora (we have a lot of ports–infra­struc­ture for it already). Unfor­tu­nately it is not known if some­thing newer works with­out prob­lems (miss­ing epoll/inotify sup­port could be a road­block here in case it is exten­sively used in a more recent version).

I want to get some time to have a look if a more recent Fedora ver­sion is suit­able for the use as a Linux base in FreeBSD 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 tested a more recent Fedora ver­sion feel free to share your experience.

GD Star Rat­ing
load­ing…
GD Star Rat­ing
load­ing…

Tags: , , , , , , , , ,