I am one of the system administrators for Lysator, a academic computer
society. We have about 500 members and a vast amount of different
hardware and software. Our current user database is a combination of a
MySQL member database and NIS.
The current user database have quite a few drawbacks, the fact tha the
member database and the user database is not connected being the most
irritating. I'm thinking about replacing the system with some kind of
Due to the fact that we run a whole bunch of operating systems
(SunOS 5.4-5.8, AIX, HP-UX, Linux, UNICOS, Tru64, you name it),
replacing NIS really isn't an option. Finding working LDAP support for
all the operating systems would be a nightmare, not to mention the
fact that NIS is running on really low-end hardware, which is good.
Enough background. My idea is to run a master LDAP and a few slaves,
and then on both the master and the slaves run a NIS server that gets
it's info from LDAP.
I haven't found any LDAP->NIS gateway (except one from PADL, but it's
AFAIK commercial which makes it uninteresting in this
context). Perhaps there is one I don't know of? I'd like it to do some
intelligent caching, so that each NIS question doesn't generate a LDAP
My idea for a LDAP->NIS gateway is instead to keep the NIS server, but
to change it's database behind it's back. It should be doable, I just
tested on Solaris 2.8 and changing one of the /var/yp/`domainname`/
databasefiles immediately changed the result of a ypcat command.
I'm thinking about having some kind of daemon finding out when data in
the LDAP database changes, changing the data in the NIS backend on
demand. I think it could work, and it would solve the problems we have
with distributing the data to the slaves (yppush is not the best
protocol in the world..)
Now to the real question - How can I find out when data changes in the
LDAP? I'd like to know the DN:s of the entries changed, in order to
read them from my daemon. One of my ideas here is to fool slapd it has
slaves, and then read the file slurpd is supposed to read. Could that
work? Any other ideas about how to find this information? Is there a
log written with this information for some loglevel?
Oh, by the way, all software I write to solve this problem will, of
course, be open source :-).