On Friday 30 January 2004 20:03 pm, Steven T. Hatton wrote: [snip] It doesn't. but works well with it. It may be a dependency, but automount (actually autofs) is independent of NIS. All I know is that when I had NIS installed and configured, I could cd /net//directory/path, but that stopped working when I blew away

If you are thinking of using it then I'd reccomend getting the latest autofs4 from www.kernel.org. There was a time I always built my own kernel, but it started requiring

On Friday 30 January 2004 15:44, Dylan wrote: the NIS configuration. thought, and that was more than I could handle. I hope that is bundled in the eagerly awaited 2.6.x kernel rpms from SuSE. My last try resulted in no network connection, so I rolled back. [snip]

NIS+ is only available as a client - SFAIK there is no Linux server for it, only a Solaris one. Can't say any more about it that that...

I /believe/ yp is actually NIS+.

NIS works well, but you may need to hack the makefile to get it to distribute non-standard autofs maps. I simply added the necessary sections for my setup and it worked fine. There is no encryption on the passwords, so it shouldn't be used on an open or untrusted network.

I recall looking at something in the SuSE distribution, late one night, over a year ago that purported to be a means of using PKI (Primary Key Infrastructure) and/or encryption with NIS/YP and/or NFS. All I recall clearly is the package had the fingerprints of one of the SuSE old-timers all over it, and it consisted of little more than C header files.

Autofs3 doesn't (IME, YMMV) work well, especially with NIS. autofs4 (and I really do suggest getting the latest build) functions as described - I share all the autofs configs with NIS over 8 boxes without problems -

I don't believe I have had Autofs4 working, but as I say, it's been over a year since I dug into this.

NFS has some peculiarities - it doesn't co-exist well with reiserfs, no matter what people say about the problems being fixed. Security is basic to say the least, but if you configure it sensibly you should be safe on a closed network. It's not easy to get it running through NAT, to the extent that I wouldn't bother trying (again, YMMV.) Also, it's picky about whitespace in the /etc/exports file, and the file locking is not what it should be!

I do recall reading so sun documentation on NIS+/NFS and encryption, but that was back in the 20th century.

HTH

It forces me to think... Oh wait, I said I didn't want to do that. ;-) Actually, I'm taking a breather from learning to use SOAP and AXIS*, and looking at the SuSE 9.0 book's networking sections. * http://ws.apache.org/axis/ BTW, if any of the Novell folks out there in Happy Valley are listening, there are three requirements for any kind of network solution that involves first level administrators or users directly. User interface, user interface and user interface.

Dylan

STH

"Steven T. Hatton" writes:

I /believe/ yp is actually NIS+.

YP stands for Yellow Pages, the name which Sun originally used for its naming service. British Telecom protested (I think it was its trademark) and therefore Sun renamed it to NIS. In NIS+, Sun added security and hierarchical domains but, technically, NIS+ is very different from NIS. A similar name is used for marketing purposes only. Other Unix vendors refused to support NIS+ and therefore it is a dead technology now though some companies may still use it. Anyway, both NIS and NIS+ are strongly OBSOLETE at present. There are several good reasons why NIS is still used but the future is somewhere else, probably in LDAP. Unfortunately, administration tools for configuring and managing LDAP on Linux are still not user friendly. I expect it will change in 2004.

I do recall reading so sun documentation on NIS+/NFS and encryption, but that was back in the 20th century.

NFS is terribly insecure and therefore Sun came with Secure NFS (long time ago). Some Unixes implement it but the widespread is low. I'm not aware of any supported implementation of Secure NFS in Linux. IMHO there is no conceptually similar alternative to NFS which is secure, fully supported, and easy to install and configure now. Solutions like Coda, Samba, AFS, GPFS from IBM, ... exist and work but they are based on different concepts. NFS is still actively supported by Sun so I hope some security will finally be added, perhaps via IPv6. Personally, my level of satisfaction with naming services and network file system in Linux is very low. (But it doesn't mean it's better in other operating systems.) -- A.M.

On Saturday 31 January 2004 17:45 pm, steve-ss wrote:

...

Anyway, both NIS and NIS+ are strongly OBSOLETE at present.

Oh no. I don't want to run an obsolete network.

I wouldn't worry about it too much in your situation.

Should I change to ldap? Now? SuSE-9.1. . . ? How easy is it to swap over from nis? Can I keep my old nis maps?

Have a look at the docs on www.openldap.org Dylan

Steve.

-- "They that can give up essential liberty to obtain a little temporary safety, deserve neither liberty nor safety."                                   -Benjamin Franklin

On Saturday 31 January 2004 14:40, Damian O'Hara wrote:

steve-ss wrote:

...

...

Anyway, both NIS and NIS+ are strongly OBSOLETE at present.

Oh no. I don't want to run an obsolete network. Should I change to ldap? Now? SuSE-9.1. . . ? How easy is it to swap over from nis? Can I keep my old nis maps? Steve.

Take it easy Steve,

NIS is about as obsolete as UNIX was proclaimed to be when Win2K came out. I know of at least two multi-billion dollar high tech companies who use it extensively and who have no plans to go to LDAP for account services. LDAP can be a PITA to administer unless you have a good understanding the right tools/access. When it grows up a bit more I'll revisit it (I note that SuSE use it in their enterprise products).

I can also guarantee that NIS servers run better under Linux than under Solaris or HP-UX under a mixed environment. Pure agony behind that particular experience!

Damian

It's been a couple years since I worked directly in this area, but I've tried to keep my ear to the ground. Bear in mind that LDAP, strictly speaking, is a _P_rotocal, not a database specification. LDAP and NIS can work together. This really is a 'directory services' discussion. As such, the LDAP implementations I'm familiar with have certain limitations which I found restrictive. I would have to really focus on the topic to explain what the details are, but I believe a more generalized object oriented database approach would be more effective in achieving maximum flexibility in this area. The wall I hit time and time again is the lack of good UI. Some people are very gifted at working with purely textual interfaces. I can survive in such an environment, but certainly benefit from having intuitive GUI tools at my disposal. The building block are all over the place. I was just watching the Mozilla CVS source update scroll by and saw the directory SDK listed. That does have pretty good SSL support, and is the creation of the originators and first implementors of LDAP. Curses and more curses for the Mozilla project neglecting Java integration! It would be very nice to be able to exploit Gecko while working with purely java code. I can write C++, and I've done a fair bit of JavaScript hacking, but I am by far most productive with Java. I'm currently playing with http://www.schatten.info/software/xindice_browser/xindice_browser.html which looks like a good starting point to get into Xindice programming. I believe there may be real potential in XMLDB with respect to the foregoing discussion on directory services. I have to get a bit deeper into the subject before I form more solid opinions, however. STH

On Friday 30 January 2004 8:01 pm, Art Fore wrote:

For awhile, we were getting worms from the Taiwan and India VPN on the network, and if you shared a directory, you would get a worm within about two minutes.

Just curious: who were you sharing directories with that you picked up those worms? Was directory sharing really that open? I'm not familiar with VPN but I'm interested in knowing about the hazards. Paul Abrahams