|Home||Switchboard||Unix Administration||Red Hat||TCP/IP Networks||Neoliberalism||Toxic Managers|
May the source be with you, but remember the KISS principle ;-)
Skepticism and critical thinking is not panacea, but can help to understand the world better
|Minitutorial||Recommended Books||Recommended Links||Linux Minitutorial||Solaris Minitutorial||NIS Troubleshooting||Network trouble-shooting|
|Linux NIS Maps||Linux NIS daemons||Server installation||Client installation||Slave installation||Netgroups||NIS security|
|Solaris NIS Maps||Solaris NIS daemons||Server installation||Client installation||Slave installation||Netgroups||NIS security|
|NIS security||Microsoft Services For Unix||SFU as NIS Active Directory bridge||AIX
|IBM Redbooks||Linux Implementation|
|Event correlation||Horror Stories||Random Findings||Humor||Etc|
Due to its size mini-tutorial was moved to a separate page
There is also older Solaris NIS Minitutorial
Dec 6, 2001.( Prentice Hall) Reading this chapter is not an absolute requirement for deployment of LDAP, but if you become familiar with some of the architectural nuances, you can better understand broader deployment strategies. Each naming service has its own unique characteristics which may dictate how you deploy them. Although the focus of this BluePrint is LDAP, it is helpful to understand the feature set of legacy Solaris naming services to see how this new technology compares.
This is a sample chapter from Solaris and LDAP Naming Services: Deploying LDAP in the Enterprise.
- Evolution of Solaris Naming Services
- NIS and Files Coexistence
- NIS and DNS Coexistence
- Solaris Naming Service Switch
- Solaris Naming Service Switch Architecture
- NIS Architecture Overview
- NIS Client Server Architecture
- How NIS Clients Bind to the NIS Server
- NIS Maps
- NIS High Availability Architecture Features
Prior to the launch event I got some suggestions from Solaris sysadmins who had specific problems with previous versions of Solaris and had switched to other operating systems where they could. I took the issues mentioned in this SysAdmin to SysAdmin column and the comment attached to it, plus some other notes, and compiled the following list of issues, which several Solaris engineers addressed point by point:
- Solaris is too complex. This was described by the Solaris hackers as being an engineering problem that has been solved by introducing better technology -- namely, DTrace to replace other less specific command-line tools, X.org to replace the aging Xsun server, a more streamlined installation procedure, and better documentation. "Documentation is never an afterthought for us," Cantrill told me.
- If a user belongs to more than 15 groups, the system dies. Cantrill told me that this has long been a tunable parameter in Solaris. "Such that it exists at all, the limitation is due to a protocol restriction in NFS. By default, Solaris is configured to cooperate with other vendors' NFS implementations -- which means setting the number of supplementary groups to 15."
- NIS netgroups have a size limitation; this forces messy netgroups. This is due to an underlying DBM database issue; the database has a size limit of 1,024 bytes. The best solution is to use LDAP instead.
- If one machine is in two netgroups and both groups have mount privileges, the NFS server crashes. The Solaris engineers tested this and didn't find the problem; furthermore they had no record of this ever being a bug or problem with any previous editions of Solaris.
- GNOME is poorly implemented. GNOME support has been greatly improved in Solaris 10. The version that ships with the initial release is 2.6.1, and it now uses the Java Desktop System theme by default.
- The version of Netscape included with Solaris is old. Sun has abandoned Netscape in favor of Mozilla.
- Solaris has a poor LDAP implementation. A great deal of work has gone into improving LDAP in Solaris 10. The new implementation is of a much higher quality and has expanded features over previous Solaris implementations.
- If you set up the system to authenticate to NIS, then start LDAP, the system crashes. This bug has been fixed in Solaris 10.
- Solaris is slow. Solaris 10 includes an optimized TCP/IP stack, which now scales much better on multi-CPU systems. Additionally, Solaris 10 has specific performance enhancements for UltraSPARC IIIi and IV systems that can increase performance by as much as 20%.
- To: "Sunmanagers (E-mail)" <Sunmanagers@sunmanagers.org>
- Subject: SUMMARY: using Active Directory with Solaris
- From: "Corbett Waddingham" <firstname.lastname@example.org>
- Date: Tue, 6 Apr 2004 15:44:12 -0700
Hello all, Sometime ago, I posed a question about how to get Solaris to work with Active Directory. After several false starts, I finally found the answer: Microsoft's Services for UNIX (SFU). SFU is a software suite which extends the Active Directory schema, allowing various services to run out of AD for UNIX servers, including (wait for it....) NIS. So far, it's working fairly well, with some limitations. Here's a list of the gotchas I've encountered so far: 1) If you have an existing AD tree, you have to modify each individual user to use SFU by opening their properties, choosing the "UNIX Attributes" tag, and adding their UNIX account information (UID, GID, home, shell, and NIS domain). Needless to say, this is tedious in large organizations. I'm lucky, I only have about 100 users, I can't imagine someone with 10,000 going through this willingly. 2) Once the UNIX attributes have been set, you have to reset the password of the user before you can sync their account up in NIS. Presumably because AD stores passwords in a one way encryption, which is neither crypt nor MD5. 3) If you have/want multiple NIS domains, you'll have to have multiple NT domains. Each NT domain gets mapped to a single NIS domain, which must be the same name, which requires one PDC for each domain. You can, however, control multiple domains through one AD forest, so the administration isn't too bad, as long as you have extra machines for this purpose. 4) Not all of the common features of NIS are easily supported, but they are all there. The passwd map is controlled through the user management GUI, however all other maps (netgroup, hosts, ethers, etc.) must be edited on the command line. Potentially a problem for organizations which want to standardize on one management tool. It should be possible to extend the AD schema to include these other maps, however I have not yet gotten to that. 5) The master NIS server *must* be the AD server. There is a tool for migrating an existing master db into the AD server, but so far as I can tell, this is only useful if you have an existing NIS network, with no existing AD servers. 6) I encountered some problems getting the master to talk to the slaves properly. I found you have to make sure, when you list the slave servers in the SFU console, to supply their FQDN. Just using the hostname by itself lead to inconsistent communication. It was surprisingly easy to install and configure SFU, and since it was using NIS it was trivial to set up on the Solaris servers. Unfortunately, SFU doesn't support NIS+, so for those organizations requiring that, this isn't the answer. But for a smallish shop like mine with a need to standardize usernames and passwords on both the NT and UNIX sides of the house, it was the answer. r/ Corbett Waddingham Senior Systems Administrator National Clearing Corp. 310-385-2257 phone 310-385-2225 fax email@example.com
IBM Redbooks AIX - Migrating NIS Maps into LDAP
Google matched content
Freebsd handbook and freebsd beginners tutorial/NIS FreeBSD Handbook. Chapter 19 Advanced Networking. Written by Bill Swingle. Enhanced by Eric Ogren and Udo Erdelhoff.
SunService Tip Sheet for Sun NIS also at SunService Tip Sheet for Sun NIS
Cisco - Installing DNS on a Sun Running NIS
HP-UX-Sun Interoperability Cookbook - NIS
also at HP-UX-Sun Interoperability Cookbook - NIS
Protocols.com/SUN Protocols Family - MOUNT PMAP YP (NIS)
Using NIS in conjunction with DNS
Linux NIS(YP) Server and Tools The Network Information Service (NIS) provides a simple network lookup service consisting of databases and processes. It was formerly known as Sun Yellow Pages (YP).
8.16 nis -- Interface to Sun's NIS (Yellow Pages) Python interface
IBM UNIX servers - Security for pSeries AIX 5L security enhancements
Network Information Services (NIS) infrastructure has been enhanced to support netgroups in LDAP and client support for shadow passwords (encrypted passwords in the /etc/security/passwd file).
1999 SUMMARY NIS and Netgroups behaviourFrom: Neal S. Pressman (firstname.lastname@example.org)
Ronald Loftin <email@example.com>
"David W. Blaine" <firstname.lastname@example.org>
"Salehi, Michael E" <Mike.Salehi@usa.xerox.com>
also thanks to:
who didnt respond to my e-mail but has posted a summary of this problem
to the archives:
<--- snip --->
Turns out that netgroup works only with NIS running, and that using
it in .rhosts files is no problem. I'll also make the tentative
observation that the wisdom that follows applies certainly to netgroup
usage in .rhosts files, but not necessarily in other places (e.g.,
hosts.equiv, exports) because some of the rules I have to follow
(e.g., don't use capital letters) are rules I've seen violated in
other places without problems. That having been said:
</--- snip --->
my problem was simply that our Netgroup was in UCASE this is not a
problem for 2.6 or 2.7 only earlier versions.
<--- original question --->
-> I have an NIS question,
-> we have a mixed solaris environment mostly 2.5.1 and 2.6 with a couple of
-> solaris 7 boxes. we are trying to implement the use of netgroups for
-> /.rhosts and /etc/hosts.equiv . the man pages for all vers. of the OS
-> state this can be done with + and - @NETGROUP entries. we have been able
-> to get this to work on both 2.6 and solaris 7 but 2.5.1 doesnt seem to
-> here are what my files have in them:
-> MELALL is a netgroup containing all of our trusted systems.
-> has anyone been able to get this to work on 2.5.1????
</--- original question --->
-- \\|// (0~0) ----------------------------oooO-(_)-Oooo---------------------------- Neal S. Pressman Raytheon Systems Company System Administrator (MCAE) 528 Boston Post Road phone: (978) 440-1273 Sudbury, MA 01776 fax: (978) 440-2684 ms 4-1-283 E-mail: email@example.com / Neal_S_Pressman@res.raytheon.com ____________________________________Oooo.____________________________ .oooO (___)
The Last but not Least Technology is dominated by two types of people: those who understand what they do not manage and those who manage what they do not understand ~Archibald Putt. Ph.D
Copyright © 1996-2018 by Dr. Nikolai Bezroukov. www.softpanorama.org was initially created as a service to the (now defunct) UN Sustainable Development Networking Programme (SDNP) in the author free time and without any remuneration. This document is an industrial compilation designed and created exclusively for educational use and is distributed under the Softpanorama Content License. Original materials copyright belong to respective owners. Quotes are made for educational purposes only in compliance with the fair use doctrine.
FAIR USE NOTICE This site contains copyrighted material the use of which has not always been specifically authorized by the copyright owner. We are making such material available to advance understanding of computer science, IT technology, economic, scientific, and social issues. We believe this constitutes a 'fair use' of any such copyrighted material as provided by section 107 of the US Copyright Law according to which such material can be distributed without profit exclusively for research and educational purposes.
This is a Spartan WHYFF (We Help You For Free) site written by people for whom English is not a native language. Grammar and spelling errors should be expected. The site contain some broken links as it develops like a living tree...
|You can use PayPal to make a contribution, supporting development of this site and speed up access. In case softpanorama.org is down you can use the at softpanorama.info|
The statements, views and opinions presented on this web page are those of the author (or referenced source) and are not endorsed by, nor do they necessarily reflect, the opinions of the author present and former employers, SDNP or any other organization the author may be associated with. We do not warrant the correctness of the information provided or its fitness for any purpose.
Last modified: March 12, 2019