[108] in Hesiod
How do you implement Hesiod services?
daemon@ATHENA.MIT.EDU (Mark Rosenstein)
Fri Oct 30 09:46:32 1992
Date: Fri, 30 Oct 92 09:08:48 -0500
From: Mark Rosenstein <mar@MIT.EDU>
To: SAM@CSI.compuserve.com
Cc: hesiod@Athena.MIT.EDU
In-Reply-To: <SAM@CSI.compuserve.com>'s message of 29 Oct 92 21:02:03 EST <CSI_5930-29242@CompuServe.COM>
Date: 29 Oct 92 21:02:03 EST
From: <SAM@CSI.compuserve.com>
I've been looking into Hesiod to help centralize the administration of
a dozen or so Unix boxes that I've got running. I plan on using it
initially to replace /etc/passwd and /etc/group, and in the future, I
might add some of the other commonly used tables like /etc/services,
/etc/fstab, and others. (I'm also looking into Moira at some moment in
the near future.)
fstab would seem to be a bad choice as you need to reference this file
before the network layer is up to be able to use hesiod, and it's very
much dependant on the local machine configuration anyway. Another
likely candidate is /etc/printcap.
* I have replaced getpwnam(3), getpwuid(3), getgrnam(3), and
getgrgid(3) in libc. Is this going to cause many problems? Is this
the preferred way of handling this, or do people normally place the
Hesiod calls directly in the source?
We decided not to replace the regular routines with the same name, but
to add routines called hes_* which are hesiod equivalents. This way a
program has to be explicitly changed to use hesiod so that we know
which ones are and aren't using hesiod.
* I plan on relinking all of my utilities with the new libc. I do not
forsee any major problems, however, I'm curious if this is the
approach taken by others. What kind of problems am I in for? Are
there any utilities that should not be Hesiodized? (ie, login, su?)
Any programs used early during reboot or for low-level debugging may
not want to be hesiodized. Login is one we certainly do have
hesiodized, but in a very special way, not just replacing local
lookups with hesiod. There's a complicated set of rules for how local
and hesiod info interact in login, and whatever login eventually comes
up with for the user, it appends into /etc/passwd and /etc/group. We
do this so that any third party software running can find this info
locally if it looks for it.
* How do you handle getpwent(3) and getgrent(3) which want to
sequentially scan through the passwd and group database?
We don't. DECathena does it by creating aliases for each hesiod entry
like passwd-1, passwd-2, etc., and then steps through them
numerically. We think that's a gross solution, but don't have a
better one. We also don't allow our users access to the list of
20,000 valid user accounts here anyway.
* How do you perform /etc/{passwd,group} lookups? Do you hit the disk
file first and if that fails try Hesiod, or Hesiod then disk?
We generally allow the local files to override hesiod, and then make
it a policy to keep the local files empty unless absolutely necessary.
* Finally, does anyone have any examples/source that they're able to
share? Why reinvent the wheel...
I'll have to look through our source tree and see if any of the
interesting parts are not license-encumbered.
-Mark
