Archive for May 28th, 2006

KDE 3.5 Gentoo ebuilds

Is it me, or is somebody just not thinking?  It seems like Gentoo has a beef against monolithic packages like KDE and X.org.  The recent builds of these have been broken up into (as many as) hundreds of separate ebuilds — in the case of KDE, instead of the monolithic kdepim for example, each package that came with kdepim now has its own ebuild (same with kdeaddons, kdegraphics, etc).  Which is all very well, except that upstream still distributes the source monolithically…

I’ve noticed the following when emerging the new KDE 3.5…

>>> Emerging (18 of 275) kde-base/ksystraycmd-3.5.1 to /
>>> checking ebuild checksums ;-)
>>> checking auxfile checksums ;-)
>>> checking miscfile checksums ;-)
>>> checking kdebase-3.5.1.tar.bz2 ;-)
>>> Unpacking source...
>>> Extracting from tarball...
>>> Source unpacked.

One thing is that this emerge (an emerge world, btw) comprises 275 operations, most of which are KDE.  That’s okay, KDE is big.  But each and every ebuild is working on the kdebase tarball — checking the MD5, unzipping, extracting.  Presumably when it eventually gets to the other KDE components it will leave the kdebase tarball alone and move on to each of the others…

Hopefully it’s only untarring the directory for the package being compiled (you can do that with tar, right?).  It’s still a lot of digesting and unzipping though!  Surely it’s safe to assume that I’ll want more than just one package out of the tarball, so the whole thing could be unwound someplace and linked into at compile-time…

Maybe the overhead of managing that is not warranted (after all, we all have octo-core 24GHz AMD chips in our PCs now, don’t we)…

Active Directory accounts on Linux

Never thought I could get this excited about something to do with a Windows server!  But there it is — one of my SLES 9 test servers is now supporting logons from a user account stored in Active Directory, with no Samba in sight!

Before you say ANYTHING, this is not an indication that the Crossed Wires campus is switching to the evil side.  Any experienced Linux sysadmin will tell you that working with Windows systems can’t be avoided — and in some cases, welcomed (after all it’s better to have one or two Linux boxes in a sea of Windows than no Linux boxes at all).  My main customer at work is essentially a Windows shop, but their main file servers are Linux on zSeries, which means that me as a Linux guy needs to know more than I thought I would want to know about bringing Linux and Windows together.

So they are doing a migration to Microsoft Active Directory, and the Linux systems need to be integrated into the AD setup.  To our architects, Linux Windows integration equals Samba — they never bothered to look at making use of AD’s LDAP component to create a model that Linux can handle natively, instead of the (to me) less-than-optimal Winbind (don’t get me wrong, Winbind works, it just imposes some operational issues that I’d sooner do without, like SID-[UG]ID mapping, for instance).

So I proposed that the solution be updated to utilise LDAP, through the use of Microsoft’s own Services for Unix (SFU).  I was told “yeah, dunno why it wasn’t designed that way, would be the best way to do it, but no”.  Sigh.

So I decided to stick to my guns and set up something to show that it would work exactly as I said it would.  And I have!  I’ve worked around some inaccurate information on the ‘Net, some incomplete documentation from Microsoft, and some finger-checks on my part, to be able to show The Right Way to anyone who cares…  Yep, sometimes the useless thing is just worth doing.  :)

Tags: , , ,