Safer than editing

Utilities for changing AIX configuration files

Editing a critical system file such as /etc/passwd can be tempting, but if something goes wrong, your system can become unusable. The IBM® AIX® operating system provides several commands and System Management Interface Tool (SMIT) menus to help you manage system files without having to edit them directly. Built-in AIX commands can also check syntax before updating critical files, offering you extra protection for files you can't afford to lose.


Anthony English (, Senior AIX specialist, Levitar Pty Ltd

AnthonyAnthony English is an independent contractor from Sydney, Australia. He has worked on AIX systems since 1991 and writes the IBM developerWorks blog, AIX Down Under. He is also recognized as an IBM Champion for Power Systems. You can reach Anthony at

01 November 2011

Also available in Chinese

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).

Users (/etc/passwd)

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
chgroupChange the group attributes, such as users.
chgrpmemChange the members of a group.
chuserChange the group membership for a single user.
lsgroupList the group.
mkgroupCreate a new group.
mkuserCreate a new user.
rmgroupRemove a group. Be sure to remove each user from the group first.

The 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 smit nfs fast path, or the commands described below in Table 2.

Table 2. Commands for managing NFS mounts in the /etc/filesystems file
mknfsmntCreate a mount.
chnfsmntChange the mount options.
rmnfsmntRemove 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 running the 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
mknfsexpExport directories so that other virtual servers can mount them.
exportfsChange exports.
rmnfsexpUnexport directories.

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
hostent -a -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       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 -h lpar11
hostent: 0822-041 The IP address 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)

The 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 smit inetdconf.

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
lsitabList entries in /etc/inittab. To list all entries except the ones that are commented out, use lsitab -a. You can also specify an individual entry by its unique identifier.
chitabMake a change to an existing entry. However, you can't comment out an entry with this command.
mkitabCreate a new entry.
rmitabRemove 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.



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.



developerWorks: Sign in

Required fields are indicated with an asterisk (*).

Need an IBM ID?
Forgot your IBM ID?

Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name

The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.


All information submitted is secure.

Dig deeper into AIX and Unix on developerWorks

Zone=AIX and UNIX
ArticleTitle=Safer than editing