Sounds nice. I need to deal with RH Linux (and this may end up extending itself to = the desktop) and Solaris. I wanted to implement NIS a year ago, but was = ushered in the direction of NIS+. Ran into problems with NIS+ where the = Linux client, on changing the password, would somehow corrupt the = credentials. Not to mention that trying to administer MIS+ is a PITA. = Not to mention that Sun themselves don't use it. Not to mention that = Sun themselves are (or were, a year ago) working on implementing the Sun = One environment within their own offices, which means LDAP. But we've been able to put a few other items referenced on = infrastructures.org in place. There's definitely still room for = improvement. jc > -----Original Message----- > From: Robert G. Brown [mailto:rgb@xxxxxxxxxxxx] > Sent: Thursday, April 24, 2003 9:03 AM > To: R P Herrold > Cc: seth vidal; Carroll, Jim P [Contractor];=20 > kickstart-list@xxxxxxxxxx; > Yum RPM updater list > Subject: RE: [Yum] deploying and maintaining linux networks howto >=20 >=20 > On Wed, 23 Apr 2003, R P Herrold wrote: >=20 > > On 23 Apr 2003, seth vidal wrote: > >=20 > > > On Wed, 2003-04-23 at 18:27, Carroll, Jim P [Contractor] wrote: > >=20 > > > > BTW, is there anyplace one can find a cfengine RPM? > > >=20 > > > is cfengine still being maintained? > > >=20 > > > -sv > >=20 > > copy and SRPM at: =20 > > ftp://ftp.owlriver.com/pub/mirror/ORC/cfengine/ -- but the > > prime site I was aware of has gone dark. >=20 > www.cfengine.org is still live, and there is even a 2003 IEEE paper > linked on the site, and the site is still mirrored on > infrastructure.org. So I think it still exists and has humans working > on it. >=20 > I just think that it is of much less use on a homogeneous, rpm-derived > LAN than it was on the heterogeneous, tarball derived LANS on which it > was originally developed. This is very likely why rpm's are nearly > nonexistent -- rpm's themselves largely preclude any need for=20 > cfengine. > We used cfengine here back when we had Suns, SGI's, Linux boxes > (slackware based!), and a few oddballs, and it was wonderful=20 > because you > could sort-of automate doing things on servers, clients and so on by > architecture. >=20 > Well, now we're just one "architecture", and kickstart, yum, and NIS > pretty much totally eliminate what cfengine used to do for=20 > you and make > it "yet another scripting language" (yasl) to learn. Even=20 > though to be > fair it isn't really a scripting language, rather a configuration > language. I do think it would be "useful" to have in the toolbox even > now, but obviously it isn't essential to achieving highly scalable > LAN designs. It >>might<< be useful as one way to distribute e.g. > passwd and other core db's in a cluster design that couldn't/shouldn't > use NIS, but even then... >=20 > As it is with perl and many other tools, "there's more than one way to > do it". >=20 > rgb >=20 > --=20 > Robert G. Brown =20 http://www.phy.duke.edu/~rgb/ Duke University Dept. of Physics, Box 90305 Durham, N.C. 27708-0305 Phone: 1-919-660-2567 Fax: 919-660-2525 email:rgb@xxxxxxxxxxxx
