On 1/25/06, Paul Lussier <[EMAIL PROTECTED]> wrote:
Especially in a lab where engineers control the wires and have access to /etc/dhcpd.conf
LDAP or something else :-)
:-)
I think I might be doing this too. Seems a shame to have a Sun box as a NIS slave (among other things) and a Linux client on a gigabit network all by themselves.
Probably. I haven't done NIS on *BSD but I bet it's like that.
Well, it kinda makes sense. If you have a small net, NIS works well enough. For something bigger or with security in mind you do something else. So the hobbists use NIS and the IT shops use LDAP, Hesiod/Kerberos or whatnot. NIS+ solves some of the issues at the expense of fragility and portabilty. Even Sun has moved away from NIS+ and Linux NIS+ development stopped too.
In the meantime :-).....
Tom Buskey <[EMAIL PROTECTED]> writes:
> Yes. Broadcasts on the 54 subnet won't reach the 48 subnet. For example I
> have a dhcp server on the 54 net because it won't reach the rest of the
> network.
That's a different statement than "the 54 subnet won't transmit broadcasts".
(sorry, I'm being pedantic :) But your configuration makes perfect sense.
Especially in a lab where engineers control the wires and have access to /etc/dhcpd.conf
>> Yeah, I vaguely remember this problem. It's a few years since I've
>> played with NIS, but I would have expected the linux implementation to
>> have matured by now...
>
> You would, but it's good enough, mostly and most people needing more then
> linux NIS offers have moved to LDAP, etc. Such as yourself :-)
LDAP or something else :-)
Hah! moved along to LDAP :) That's funny! We're using Hesiod and
Kerberos. Ain't no stinking LDAP here! (Have I mentioned I hate LDAP
? What a truly ugly, unmanageable hack of a design!)
:-)
> domain gps server nismaster
> Should bind explicity to nismaster from the docs.....
Agreed. I remember having this problem explicitly. As a matter of
fact, I remember Derek and I swearing at the NIS slave because it
wouldn't bind to the nismaster. This was probably 5-6 years ago
though, when we were at Bay Networks (Holy Cat5, has it been *that*
long?)
> Things have changed in the Sun world too. Pre solaris 8 wouldn't
> work in this scenario but 8 (9) and 10 do.
I remember in the pre-Solaris 8 days we would always have a nis slave
on each subnet for clients to bind to which got the maps pushed to
them by from the master. This might be the work around we used.
Build a slave that binds to itself and gets updates from the master
pushed to it using cron and ypxfer.
I think I might be doing this too. Seems a shame to have a Sun box as a NIS slave (among other things) and a Linux client on a gigabit network all by themselves.
> I kind of like yp.conf. Instead of /etc/defaultdomain and ypinit -c (with
> /var/yp/ypservers). and others scattered about /etc.
I always liked the defaultdomain stuff. Maybe because it was what I
first learned and it was simple.
Probably. I haven't done NIS on *BSD but I bet it's like that.
> Linux NIS feels partly finished. Like the docs say it should work this way,
> but it doesn't. Hence this question :-(
Sadly it seems it's been that way for a loooooong time.
Well, it kinda makes sense. If you have a small net, NIS works well enough. For something bigger or with security in mind you do something else. So the hobbists use NIS and the IT shops use LDAP, Hesiod/Kerberos or whatnot. NIS+ solves some of the issues at the expense of fragility and portabilty. Even Sun has moved away from NIS+ and Linux NIS+ development stopped too.
In the meantime :-).....
--
A strong conviction that something must be done is the parent of many bad measures.
- Daniel Webster
