Corporate Linux: Coexisting with the Big Boys

Integrating Linux into a large-scale production network running SPARCs and Windows.

Linux has come a long way in these past few years, no longer a geek toy and well on its way to being a mainstream operating system. Linus Torvalds, with tongue firmly planted in cheek, is striving for world domination; however, one of the more intriguing strengths of Linux is its friendly and fruitful coexistence with other systems, UNIX or not. In fact, its standards-based approach is one of my favorite ways of distinguishing between it and certain commercial products.

This being said, I would like to present some experiences with integrating Linux machines into a production computer network of over 1000 nodes, divided into about two-thirds SPARCs running Sun Solaris and one-third PCs running one of the variety of software packages emanating from Redmond, WA.

Any large UNIX site usually employs the operating system's easy yet effective mechanisms for maintaining a large number of users working on an equally large number of machines. For Linux to participate in such a network, it needs to be able to participate in or even provide any of these services. At our site, these are:

  • NIS: Sun's Network Information Services, formerly called Yellow Pages. This is a well-proven mechanism to distribute any kind of information that can be represented as lists, such as user accounts, passwords and printer definitions.

  • NFS: the Network File System. This allows mounting of remote file systems, typically with a mix of static and automatic mounts. The former are configured on a per-machine basis and the latter are distributed via NIS maps.

  • Unified login scripts: a carefully set up and maintained web of shell scripts, providing users with the required settings to work with their respective applications. This eliminates the need for each user to hack together her own environment with all the support implications.

Additionally, it is almost self-evident that a Linux box should be able to access networked or server-based printers via the LPR protocol as well as utilize all other communication protocols like HTTP, NNTP, SMTP or FTP. Linux has a well-deserved reputation for being an excellent performer in this respect.

The Information Source: Enabling NIS

A three-step approach lets a Linux machine participate in an NIS domain, beginning with the installation of the necessary software. In the case of the Red Hat 5.x distributions, these come in two RPM packages—ypbind and yptools. The former provides the ypbind executable, which must run on any NIS client as a daemon, and provides communication with the NIS server. The latter contains various NIS-related tools for querying NIS tables (ypcat, ypmatch, yppoll) and maintaining the client configuration (ypwhich, ypset).

Next, the server-side configuration is modified to let the new NIS client participate in the domain. NIS has only basic security mechanisms, with a common one being the “securenets” list enumerating the networks considered secure to participate in a domain. If your Linux box lives in a different subnet than your other UNIX boxes, make sure that network is present in your server's securenets list (commonly located in /var/yp/securenets on a Sun server).

The final hurdle is the client-side configuration. First of all, the ypbind daemon needs to know the NIS domain name (another security precaution, although a rather fragile one). This is set in the file /etc/yp.conf, together with either an NIS server name or the instruction to broadcast for a server. The file needs to contain only a single line in this format:

domain

The server bigboy.my.net must have an entry in the hosts database, /etc/hosts.

Now the NIS domain name needs to be set. This can be accomplished via the domainname my.NIS.domain command. To make this setting persist even after a reboot, the domain name should also be entered into the system's network configuration, in the case of Red Hat: /etc/sysconfig/network:

DOMAINNAME=

After creating a directory /var/yp/binding for ypbind to store binding information in, ypbind can be started via its script: /etc/rc.d/init.d/ypbind start.

Next, we have to let the system know to actually use NIS to resolve things like hostnames, user IDs and passwords. To do this, edit the file /etc/nsswitch.conf and change the corresponding lines for each service with which you would like to use NIS, e.g.:

passwd:     files nis
shadow:     files nis
group:      files nis
hosts:      nis files dns
automount:  files nis

In the above examples, the login program trying to authenticate a user will consult /etc/nsswitch.conf, see the sequence files nis and look for the information in the respective files. Upon failure, it will query the NIS service for the user's password and shadow entries. If this also fails, the login is denied. The reason to have the entry listed as files nis is that the root user is normally not defined in NIS (this is considered a security hole). In the case of a network problem, looking in the local passwd/shadow files first lets root log in without further problems.

This is basically it. Once the file is edited and ypbind is running correctly (verify this by looking for suspicious messages in /var/log/messages and in the corresponding file on the NIS server), your machine is part of the NIS domain. Of course, you can reboot if that makes you feel better; it also allows you to test that the system will come up with the correct configuration.

You can verify ypbind's connection to the server (a “binding” in NIS parlance) using the ypwhich command. You can also manually look up information: the command ypmatch joe passwd will show Joe's entry from the NIS password map.

______________________

Comments

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

mount

Konjet's picture

How can I mount a Filesystem and make it persistent across reboot?

White Paper
Linux Management with Red Hat Satellite: Measuring Business Impact and ROI

Linux has become a key foundation for supporting today's rapidly growing IT environments. Linux is being used to deploy business applications and databases, trading on its reputation as a low-cost operating environment. For many IT organizations, Linux is a mainstay for deploying Web servers and has evolved from handling basic file, print, and utility workloads to running mission-critical applications and databases, physically, virtually, and in the cloud. As Linux grows in importance in terms of value to the business, managing Linux environments to high standards of service quality — availability, security, and performance — becomes an essential requirement for business success.

Learn More

Sponsored by Red Hat

White Paper
Private PaaS for the Agile Enterprise

If you already use virtualized infrastructure, you are well on your way to leveraging the power of the cloud. Virtualization offers the promise of limitless resources, but how do you manage that scalability when your DevOps team doesn’t scale? In today’s hypercompetitive markets, fast results can make a difference between leading the pack vs. obsolescence. Organizations need more benefits from cloud computing than just raw resources. They need agility, flexibility, convenience, ROI, and control.

Stackato private Platform-as-a-Service technology from ActiveState extends your private cloud infrastructure by creating a private PaaS to provide on-demand availability, flexibility, control, and ultimately, faster time-to-market for your enterprise.

Learn More

Sponsored by ActiveState