FreeBSD NIS Service

The original Japanese version is available here.

After working for a company for more than 10 years, or nearly 20 years, it sometimes happens that the company’s performance breaks through, whether it is some kind of coincidence, the sales people get momentum at the same time, or other company’s declines are too severe、I don’t know. But when that happens, everyone seems to think the same thing: company-wide company trip! This is a signpost on Okiei street, a bit away from Kokusai street in Okinawa.

We have been testing our DNS service on pokemon.home.jf3vqb.net and package.home.jf3vqb.net servers, but since they were running on vmware on M$ Windows OS, Windows OS rebooted itself to complete windows update, and as a result pokemon.home.jf3vqb.net and package.home.jf3vqb.net servers got crashed 🙁 That’s why we have new dhcp.home.jf3vqb.net server now. I plan to install i386 FreeBSD to make the crash-free server environment. First, I moved the home version of DNS from pokemon.home.jf3vqb.net and package.home.jf3vqb.net, and made pokemon.home.jf3vqb.net secondary. We don’t use pokemon.home.jf3vqb.net DNS server much, but it will take over the DNS server function when dhcp.home.jf3vqb.net server needs to be offline for maintenance.

I was going to write about NFS next, but before I discuss NFS, I would like to talk about NIS. The NIS was originally called YP, but due to trademark registration issue or some other reason, YP (Yellow Page) can no longer be used, and it is now called NIS (Network Information Service). However, the commands that can be used are still ypxxxx. The reason why NFS and NIS are closely related is that a file has a set of owner and group, and access management is done using the file mode. Therefore, the security of the UNIX File System cannot be achieved unless the user information used among NFS servers and NFS clients is the same. Therefore, YP and later NIS were developed to manage not only user information but also various other information commonly over the network. In my company’s environment, general users are managed by Windows AD, and service users are managed by NIS. This allows both NIS and AD users to log on to UN*X and use SAMBA file sharing in the same way. We also use 801.2x on the switch to authenticate/authorize PCs via freeradius3 using M$ AD computer accounts, and integrate access to the switch with M$ AD using tacacs plus 4. We will talk about switch access management with tac_plus4, freeradius3, and M$ AD, or the use of Kerberos with NFSv4 for another time.

Originally, user management on UN*X machines was done by modifying /etc/passwd and /etc/group for each machine. This is the same on the NIS master server as well. This information is transfered to the NIS slave server, and the NIS client gets the user information from the nearby NIS server over the network. Let’s build the NIS master server, dhcp.home.jf3vqb.net for the NIS domain JF3VQB. After that, we will set up package.home.jf3vqb.net as a NIS slave server. First, create users and groups as usual, referring to other pokemon.home.jf3vqb.net and packages.home.jf3vqb.net. Users and groups that are needed before NIS starts should be left on the local system, since daemon may not start. NIS-related files are stored in the /var/yp directory. If nothing is set up, there is only a Makefile. Let’s take a look at the contents.

The first thing to read carefully is this. If this is the NIS master and the only server in the network, leave it as is. If there are slave serverd, then NOPUSH must not be True. The policy for this design is that the package.home.jf3vqb.net is going to be the slave server, so we will need to reset this variable.

The next thing to note is this: the FreeBSD passwd file does not contain encrypted passwords in it. This password is stored in the master.passwd file, which is not visible to the general public. The main reason for this is that if the password can be seen, there is a possibility that the encrypted password can be deciphered by brute force. However, this mechanism can be problematic when providing NIS functionality to other operating systems. In such cases, UNSECURE can be set to True so that the encrypted passwords can be seen as part of the passwd file. Since we will be using only FreeBSD, we will leave this setting unchanged.

First, let’s initialize the dhcp.home.jf3vqb.net, We use JF3VQB as the NIS domain. The domain name is not related to the DNS domain name, so this can be any string you like.

Go with defaults except for the slave server name.

Various errors occur because NIS-related processes are not running yet.

It says that the master.passwd file doesn’t exist in /var/yp directory. That’s correct. I haven’t created it yet.

Since I don’t want to copy this file to /var/yp every time user information is changed, specify the original /etc/master.passwd file as this file name. Of course, it is troublesome to type this file name every time, so let’s put it in /etc/make.conf.

Initialize again.

The data currently in /var/yp/JF3VQB is OK to recreate.

If the information entered is correct, type ‘y’ to proceed.

This time, no errors related to the master.passwd file were displayed.

Play with the /etc/rc.conf file so that the services required by NIS server dhcp.home.jf3vqb.net will start automatically.

The package.home.jf3vqb.net is also tweaked in the same way. The only difference is the order of the NIS servers.

The NIS client is OK as long as ypbind is running. The NIS server to be used after startup is the last server listed in nis_client_flags. If this server is not available, the server immediately before it will be used. If NIS is used only in a simple single network, as in this case, it could be configured as a broadcast client, but I tried to use it by specifying the NIS servers. This can be applied to any larger networks. In case you want to use broadcast, just set the domain name and run ypbind with no arguments and NIS client setup is basically OK.

First, let’s restart dhcp.home.jf3vqb.net to check if it works as expected.

If we see ypserv and ypbind, then it is OK.

Then, initialize package.home.jf3vqb.net next.

When it finishes without error, reboot to confirm if it works as expected. After rebooting, we should see the same processes as dhcp.home.jf3vqb.net.

Restart pokemon.home.jf3vqb.net and if we see ypbind, then it is OK.

Make sure that the same user is visible on the master server, slave server, and client, respectively.

When it is confirmed, delete the local user.

Try to establish SSH connection to pokemon.home.jf3vqb.net. But the SSH public key of the pokemon user doesn’t seem to be visible.

I tried entering a password, but it was rejected for authentication. It seems that the NIS user is not recognized.

Now we need to edit /etc/nsswitch.conf.

Then text string “compat” at group and passwd need to be chabged to “files nis”.

Now, OS should check local files first, if information isn’t available, then try NIS next. Now I was able to log in with my SSH public key.

Now, we do the same on other two systems and confirm that you can login as the pokemon user. The user and group names look the same, but that’s because I just happened to create the user using the same UID/GID pair on all three FreeBSDs. It is just a coincidence. We will need to use M$ AD and/or NFSv4 to make this coincidence a necessity.

To see if the update can be performed, create a new user on the NIS master server and run make in /var/yp to push new information to other slave servers.

When make finishes, check to see if the new user is visible on the other two systems.

Check to see if master.passwd is also shared. Try logging on using the password.

The password also seems to have been copied. However, there is no home directory, so I can log in with error message.

This is where NFS comes in. We talk about NFS in other articles later on.

Finally, we want to be sure that synchronization between master/slave is reliable and that the same information is always visible, but it is not true all the time. Because the slave ypserv happens to be offline when we push on the master server, or that the network is interrupted. Also, the JF3VQB domain created here is a very small home domain, so updates are not frequent. So, if a transfer fails, data inconsistency will persist for a long period of time. To avoid such a situation, it is desirable for the slave server to check the data periodically and request a transfer if it looks newer than the data it has, to ensure that it has the latest data. You should set up an administrative script to check this. I have decided to put an admin script under /etc/admin, so that is what I will do here as well.

The name of the management script is nischecker, a short script of less than 15 lines.

When this is done, each file in the domain name directory under /var/yp is checked, and if there is nothing new on NIS master server, no transfer happens.

However, when there is something new, they transfer the latest version.

Therefore, it would be a good idea to run this script automatically on all NIS slave servers about once an hour using cron.

This is the boarding gate at Kansai International Airport. The destination is Okinawa Naha Airport. The aircraft appears to be a B767. The name of the trip is not a company trip? The name of the trip is not a company trip, but a kick-off meeting in Okinawa. There will be time for a meeting at the hotel, of course. The flight should arrive at Naha around the same time and another party should also be waiting for departure at Haneda airport.

After the first day’s meeting, the group split up into those who wanted to drink, those who wanted to eat, those who wanted to go sightseeing, etc., and went to bars, restaurants, and tourist attractions. The next day, we took a bus to the parking lot where the Okinawa Ocean Expo was located, and wandered around the botanical gardens and aquarium.