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 com­pil­er
  • tar­balls of openldap-sta­ble-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 every­thing

openldap-stable-20100719 (2.4.23)

export CPPFLAGS=”-I/usr/sfw/include” LDFLAGS=”-L/usr/sfw/lib ‑R/usr/sfw/lib”
./configure –pre­fix=$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/con­fig –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/.

Send to Kin­dle

On the way to solve the CUPS prob­lem

I opened a bug report for the prob­lem (have a look at the relat­ed posts below) and got the response that it is a prob­lem in pstoraster. This means it is a prob­lem in ghost­script, not in CUPS.

So I had a look at pstoraster and seen that CUPS_FONTPATH is added to GS_LIB. The­o­ret­i­cal­ly it should solve my issue when I set CUPS_FONTPATH, but this assumes I can do it with­out CUPS dis­card­ing my set­tings.

Unfor­tu­nate­ly this assump­tion is not true. I tried it and I still see the same behav­ior as before.

Send to Kin­dle

More prob­lems with CUPS (pass­ing env vari­ables)

Sat­ur­day I had to print a post­script file. The file was gen­er­at­ed out of a tem­plate which I wrote myself by hand sev­er­al years ago. There I use a non-standard PS font which can not be changed. The font is not embed­ded, and I can print it via ghost­script by telling it the loca­tion where the font files are locat­ed (export GS_LIB=/path/to/dir1/path/to/dir2). Now that I switched to use CUPS as my printserv­er soft­ware, I had to teach it to set this for the call to gs (via foomat­ic). Unfor­tu­nate­ly I failed to get it work­ing via the CUPS con­fig.

I added “SetEnv GS_LIB /path/to/dir1:/path/to/dir2” to cups.conf and restart­ed CUPS. This did not work. I added “PassEnv GS_LIB” to cups.conf, added an appro­pri­ate export of GS_LIB to /etc/rc.conf (just to make sure… I still had the SetEnv in cups.conf) and restart­ed CUPS. This did not work either.

As I just want­ed to print out some­thing and did not want to spend my time debug­ging this, I put a workaround into place: I moved gsc to gsc.bin and cre­at­ed a lit­tle shell script as gsc which sets the vari­able and starts gsc.bin.

At the next update of ghost­script this will break my print­ing (if I for­get that I have this workaround in place), so I should try to get some time to fix this. Maybe I can fix this by adding “env GS_LIB=…” to the call of gs in the ppd, but this seems more like anoth­er workaround to me, than a real fix.

Send to Kin­dle