Com­pil­ing Sam­ba 3.5.8 with AD sup­port on Solaris 10 u8

If some­one needs a sam­ba which is able to com­mu­ni­cate with an AD 2008 serv­er on a Solaris 10 sys­tem… here is how I did it.

Pre­req­ui­sites

  • /opt/SUNWspro con­tains the Stu­dio 12 compiler
  • tar­balls of openldap-stable-20100719 (2.4.23), heimdal‑1.4, samba‑3.5.8
  • export PATH=/opt/SUNWspro/bin:/usr/xpg6/bin:/usr/xpg4/bin:/usr/perl5/bin:/usr/bin:/usr/openwin/bin:/bin:/usr/sfw/bin:/usr/sfw/sbin:/sbin:/usr/sbin:/usr/sadm/admin/bin:/usr/sadm/bin:/usr/java/jre/bin:/usr/ccs/bin:/usr/ucb CC=cc CXX=CC
  • DEST=/path/to/final/location

Com­pil­ing everything

openldap-stable-20100719 (2.4.23)

export CPPFLAGS=”-I/usr/sfw/include” LDFLAGS=”-L/usr/sfw/lib ‑R/usr/sfw/lib”
./configure –prefix=$DEST/openldap‑2.4.23 –disable-slapd
make depend
make install

heimdal‑1.4

./configure –prefix=$DEST/heimdal‑1.4 –with-openldap=$DEST/openldap‑2.4.23 –with-hdbdir=$DEST/heimdal-instance/var/heimdal –sysconfdir=$DEST/heimdal-instance/etc
cd lib/hcrypto/libtommath

Unfor­tu­nate­ly heimdal‑1.4 does not con­tain all the files you need. As of this writ­ing (if you try to do this a lot lat­er, you may get more recent ver­sions which may or may not work with heim­dal 1.4) I was able to down­load them from

cd ../../..
make
make install
mkdir ‑p $DEST/heimdal-instance/var/heimdal $DEST/heimdal-instance/etc

samba‑3.5.8

export CPPFLAGS=”-I$DEST/openldap‑2.4.23/include” LDFLAGS=”-L$DEST/openldap‑2.4.23/lib ‑R$DEST/openldap‑2.4.23/lib ‑R$DEST/samba‑3.5.8/lib ‑R$DEST/heimdal‑1.4/lib”
./configure –prefix=$DEST/samba‑3.5.8 –sysconfdir=$DEST/samba-instance/etc –localstatedir=$DEST/samba-instance/var –with-privatedir=$DEST/samba-instance/private –with-lockdir=$DEST/samba-instance/var/locks –with-statedir=$DEST/samba-instance/var/locks –with-cachedir=$DEST/samba-instance/var/locks –with-piddir=$DEST/samba-instance/var/locks –with-ncalrpcdir=$DEST/samba-instance/var/ncalrpc –with-configdir=$DEST/samba-instance/config –with-ldap –with-krb5=$DEST/heimdal‑1.4 –with-ads –with-quotas –with-aio-support –with-shared-modules=vfs_zfsacl
gmake
gmake install

After that you have a sam­ba in $DEST/samba‑3.5.8, the con­fig for it should be put into $DEST/samba-instance/config and if you need to have a cus­tom krb4.conf you can put it int $DEST/heimdal-instance/etc/.

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.

Sta­bil­i­ty prob­lems solved (hard­ware problem)

After putting the disks of the 7‑stable sys­tem which exhib­it­ed sta­bil­i­ty prob­lems into a com­plete­ly dif­fer­ent sys­tem (it is a rent­ed root-server, not our own hard­ware), the sys­tem now sur­vived more than a day (and still no trace of prob­lems) with the UFS set­up. Pre­vi­ous­ly it would crash after some minutes.

The ZFS set­up with the changed hard­ware had a prob­lem dur­ing the night before (like always after all my ZFS relat­ed changes on this machine), but on this machine I changed all locks in ZFS from shared locks to exclu­sive locks (this extend­ed the uptime from 4 – 6 hours to “until I reboot­ed the morn­ing after because of hang­ing process­es”), so this may be because of this. I do not know yet if we will test the ZFS set­up with the pure 7‑stable source we use now or not (the goal was to get back a sta­ble sys­tem, instead of play­ing around with unre­lat­ed stuff).

It looks like some kind of hard­ware prob­lem was uncov­ered by updat­ing from 7.1 to 7.2 (and 7‑stable sub­se­quent­ly). This new machine has a com­plete­ly dif­fer­ent chipset, a new CPU and RAM and PSU and … so I do not real­ly know what caused this (but the fact that the pre­vi­ous sys­tem did not rec­og­nize the CPU after replac­ing it with a big­ger one and the obser­va­tion that only shared locks with a spe­cif­ic usage pat­tern where affect­ed lets me point towards miss­ing microc­ode updates…).

I merged a lot of ZFS patch­es to 7‑stable

Dur­ing the last weeks I iden­ti­fied 64 patch­es for ZFS which are in 8‑stable but not in 7‑stable. For 56 of them I had a deep­er look and most of them are com­mit­ed now to 7‑stable. The ones of those 56 which I did not com­mit are not applic­a­ble to 7‑stable (infra­struc­ture dif­fer­ences between 8 and 7).

Unfor­tu­nate­ly this did not solve the sta­bil­i­ty prob­lems I have on a 7‑stable system.

I also com­mit­ted a diff reduc­tion (between 8‑stable and 7‑stable) patch which also fixed some not so harm­less mis­merges (mem-leak and ini­tial­iz­ing the same mutex twice at dif­fer­ent places). No idea yet if it helps in my case.

I also want to merge the new arc reclaim log­ic from head to 8‑stable and 7‑stable. Maybe I can do this tomorrow.

Cur­rent­ly I run a test with a ker­nel where the shared locks for ZFS are switched to exclu­sive locks.