Why use utilities to change AIX configuration files?
You can avoid many problems that result from editing mistakes by using some of the supported AIX utilities for changing system files. AIX offers some user-friendly commands for updating many critical system files. When you get familiar with these commands, you realize how much safer (and often easier) they are than directly editing the files. Furthermore, direct editing of some files, such as /etc/inittab, is not supported, so it's worth learning how to use the tailor-made commands or make changes via SMIT.
You may be used to editing system files, but sometimes things can go wrong—editing sessions are interrupted, critical files are mistakenly overwritten, and so on. You may think you're safe because you always make a backup prior to editing any system file. Even so, you may not realize you need to revert to a backup version until it's too late. It's only when you realize there's a problem that you think of reinstating an earlier version.
One challenge with editing system files is ensuring you use the right format. The syntax can vary from one file to another. For example, the fields in the /etc/passwd and /etc/inittab files use a colon character (:) as a delimiter, but the fields in the /etc/services and /etc/hosts files use white space. In the /etc/inittab file, the colon character also serves as a comment character, rather than the pound character (#) that you might expect. But in the /etc/filesystems file, the comment character is the asterisk (*). If a utility checks your syntax before it updates a file, you've got more protection than if you make a copy of the file yourself. Prevention is better than cure.
Now you may have many years of experience on UNIX® systems, and the syntax of the system files is second nature to you. You might also be a whiz with the editor. That's good, but consider how difficult it might be for you to train someone less experienced in the mysteries of the editor and configuration file standards. A tiny oversight while editing the /etc/passwd file—even a missing character—can render your production system unusable. For other files, you may not realize there is a mistake for a long time. For example, if there's something wrong in /etc/inittab or /etc/filesystems, it may not be discovered until the next reboot, and that may be months after you make the change. It can be frustrating and time consuming to determine which configuration file might be causing a problem. Then you have to pinpoint which typographic or syntactic error is causing the damage. Wouldn't it be easier for you, and anyone who might work on your system, if there was a simple command you could run for at least some of these essential files?
The tips provided in this article won't make your system bullet proof, but they will
help you implement some checks and balances when you're making changes to critical operating system files. So, before you discover the hard way that a simple command such as
vi /etc/passwd isn't always a positive career move, take a look at some safer options.
Using standard AIX utilities
There are many commands available for making changes to the most common AIX system configuration files. These commands provide sanity checks, and they're generally more likely to stop you—or at least give a warning—if the syntax isn't correct. Even if you don't use these commands every time you need to change a configuration file, it's helpful to know they're there, especially for changes to those system files that you are less familiar with.
You can change many critical AIX system files using SMIT. One advantage of using SMIT is that it keeps a log of changes (smit.log in the user's home directory) and a script of all the commands that have been run (smit.script). When you press Enter in SMIT to run a command, you can view the command syntax by pressing F6 or Esc-6. That's a great way to look under the covers. It often displays a short script that may assist you with writing your own scripts.
For more information about using SMIT, see Resources.
Other AIX utilities
Apart from SMIT, there are other AIX utilities you can use to change system files. There are advantages in running a customized command instead of using the editor. Using a customized command to change a file can:
- Save time because you can script the command and run it with minimal user intervention.
- Improve consistency because you can run exactly the same change on equivalent virtual servers.
- Check the syntax as part of the file change.
- Enable you to keep a log of successes and failures.
- Maintain correct permissions on system files.
- Simplify documentation of file changes.
If you want to make changes to the same file on several AIX virtual servers, you can run a command to update the file on all the different servers using Distributed Shell (DSH) (see Resources).
Changing common AIX configuration files
AIX has many system configuration files that play a central role in a well-functioning system. Here are just a few that system administrators often edit themselves:
- Users (/etc/passwd)
- User groups (/etc/group)
- File systems (/etc/filesystems)
- NFS mounts (also in /etc/filesystems)
- NFS exports (/etc/exports)
- Host names and aliases (/etc/hosts)
- Domain name services (/etc/resolv.conf)
- TCP/IP services (/etc/services)
- inetd daemon configuration file (/etc/inetd.conf)
- Initialization table (/etc/inittab)
There are alternatives to editing these files yourself, and in some cases the commands involve less effort than opening the file and searching for the section you want to change. There is documentation available for all the commands listed here (see Resources).
The passwd file contains a list of users and a selection of valuable information about them. It's central to the login process, managing permissions, and specifying home directories. Because the /etc/passwd file is common to all UNIX systems, it used to be a favorite to edit and use for printing tests. But it's a critical file, and if it's damaged or overwritten you may find yourself recovering from a backup, or at least booting into maintenance mode to repair the damage.
I once saw a system wiped out because someone tried to print /etc/passwd and accidentally redirected the print command to that file. I've even seen sites where /etc/passwd is available via a Samba share, where it can be viewed and possibly even overwritten by ordinary users.
System administrators often edit the /etc/passwd file just to view information or to change some detail about a user. That can be risky. Instead, you can view information using the
lsuser command. You can change user details, such as the GECOS field (the user's full name), using the
chuser command. If you like, you can use the
smit user fast path to view user information or make changes.
User groups (/etc/group)
The list of groups with their users is particularly problematic to edit. A single line can span hundreds of characters because each group contains the user names of all its members. Use the commands described in Table 1 below to manage the /etc/group file.
Table 1. Commands for managing the /etc/group file
|Change the group attributes, such as users.|
|Change the members of a group.|
|Change the group membership for a single user.|
|List the group.|
|Create a new group.|
|Create a new user.|
|Remove a group. Be sure to remove each user from the group first.|
smit group fast path takes you to menus to list details or make changes to UNIX groups.
File systems (/etc/filesystems)
This file is essential for mounting file systems. If there's an error in /etc/filesystems, it may not be picked up until the next reboot. That could be months after the file was edited, and you may be left with one or more file systems that don't mount. That can result in databases and applications not starting correctly.
If you want to change the mount point of a file system, you can use the
chfs -m command. You can also use the
chfs command to change mount options, such as Concurrent I/O (CIO). To change file systems in SMIT, use the
smit chfs fast path.
NFS mounts (/etc/filesystems)
For Network File System (NFS) mounts, use the
fast path, or the commands described below in
Table 2. Commands for managing NFS mounts in the /etc/filesystems file
|Create a mount.|
|Change the mount options.|
|Remove a mount.|
NFS exports (/etc/exports)
The /etc/exports file contains a list of directories that can be exported to NFS clients. Rather than editing the exports file directly and then
exportfs command, you can use the
smit nfs fast path, or run the commands described below in Table 3.
Table 3. Commands for managing the /etc/exports file
|Export directories so that other virtual servers can mount them.|
Host names and aliases (/etc/hosts)
Most people update the local hosts file using an editor, but you can use the
hostent command instead. The advantage is that it checks to
see if you are adding a duplicate host name or IP address. Listing 1 below shows how to add a host.
Listing 1. Add a host with
hostent -a 10.1.1.10 -h lpar10
You can then display the host using
hostent -s, as shown
below in Listing 2.
Listing 2. Display host entry
hostent -s lpar10 10.1.1.10 lpar10
As mentioned earlier, the
hostent command prevents you from adding an entry with a duplicate IP address or
host name, as shown in Listing 3.
Listing 3. The
hostent command checks for duplicate entries
hostent -a 10.1.1.10 -h lpar11 hostent: 0822-041 The IP address 10.1.1.10 already exists.
If you need to make changes to the hosts database for several virtual servers, the
hostent command is simpler and safer than directly editing the /etc/hosts file.
To make changes to the hosts in SMIT, use the
smit namerslv fast path.
Domain name services (/etc/resolv.conf)
namerslv command lets you manage the list of Domain Name System (DNS) servers. Using this command, you can add a domain, add or delete name servers, and change the search list. You can also use the
smit namerslv fast path.
TCP/IP services (/etc/services)
You can change the services file using the
chservices command. This command lets you add, change, or deactivate entries in the /etc/services file.
inetd daemon configuration file (/etc/inetd.conf)
You can change the /etc/inetd.conf file with the
chsubserver command. This lets you add, delete, or change entries. This can also
send a signal to refresh the inetd daemon. The SMIT fast path for changing the /etc/inetd.conf file is
Initialization table (/etc/inittab)
Use the commands described below in Table 4 to manage the /etc/inittab file.
Table 4. Commands for managing the /etc/inittab file
|List entries in /etc/inittab. To list all entries except the ones that are commented out, use |
|Make a change to an existing entry. However, you can't comment out an entry with this command.|
|Create a new entry.|
|Remove an entry.|
Bypassing the editor
However confident you may be with editing critical system files, accidents can happen. The variations in syntax from one file to another can make it difficult to undo or even detect precisely what is causing a mysterious loss of functionality.
When you are looking at changing any system configuration file, check to see if there is a tailor-made command or a menu option in SMIT. The built-in commands give your system more protection from human errors, and if you do run into difficulties with a change, it's easier to trace through your command history and reverse the change.
- "Introducing SMIT" (developerWorks, September 2006) provides an introduction to SMIT.
- Read "DSH Simplifies the Task of Managing Multiple Systems" (IBM System Magazine, October 2008) to learn about using DSH to execute commands across multiple AIX systems.
- Learn more about System Files in AIX Version 7.1
- Check out the AIX 7.1 Commands documentation.
- Check out my blog, AIX Down Under, on IBM developerWorks. It has lots of tips and practical examples for AIX administrators. There are tips for beginners as well as a look at some more advanced topics.
- Follow me on Twitter and keep up with my blog updates.
- Stay current with developerWorks technical events and webcasts focused on a variety of IBM products and IT industry topics.
- Attend a free developerWorks Live! briefing to get up-to-speed quickly on IBM products and tools as well as IT industry trends.
- Follow developerWorks on Twitter.
- Watch developerWorks on-demand demos ranging from product installation and setup demos for beginners, to advanced functionality for experienced developers.
Get products and technologies
- Evaluate IBM products in the way that suits you best: Download a product trial, try a product online, use a product in a cloud environment, or spend a few hours in the SOA Sandbox learning how to implement Service Oriented Architecture efficiently.
- Try out IBM software for free. Download a trial version, log into an online trial, work with a product in a sandbox environment, or access it through the cloud. Choose from over 100 IBM product trials.
- Get involved in the developerWorks community. Connect with other developerWorks users while exploring the developer-driven blogs, forums, groups, and wikis.
- Follow developerWorks on Twitter.
- Participate in developerWorks blogs and get involved in the developerWorks community.
- Get involved in the My developerWorks community.
- Participate in the AIX and UNIX® forums: