aix administrator secrets

8/9/2019 AIX Administrator Secrets

http://slidepdf.com/reader/full/aix-administrator-secrets 1/18



About the Author:Christian Pruett is a senior UNIX systems administrator and architect with more than 15 years ofexperience with AIX, Sun Solaris, HP/UX, and Linux.



ContentsAbout the Author

Introduction

Chapter 1: Breaking into the Business ................................................................1

Chapter 2: File Systems ......................................................................................4

Chapter 3: Tips for Patching Your AIX Server ......................................................6

Chapter 4: Networking ......................................................................................9

Chapter 5: What to Do After the First Server Reboot .......................................12



IntroductionI often get email messages from people all over the world who’ve benefitted from the articles I’vewritten about AIX systems administration. Some just say, “Thank you,” while others are looking formore details about a particular topic or asking for clarification on a point I’ve made. Some are lookingfor information on a subject I haven’t yet addressed or are actually requesting a specific topic. In all

the incoming email messages, there are a surprising number of people who ask a simple, yet com-plex, question: “How can I become an AIX systems administrator?”

As I reply back to all of these people and try to help those looking for assistance, I ponder the chal-lenges newcomers to AIX administration must face. In the past, I could sense that some people werein dire straits and knew that things were going to turn out badly. For others, I could tell they had beengiven a bad task and knew that they would have to paddle upstream all the way. Some seemed justplain lost. But then I thought to myself, “Wouldn’t it be great if someone could share all of the expe-riences that can’t be gained from a classroom or training environment so that newcomers wouldn’thave to go through the struggles and mistakes that other administrators have made?”

With these experiences in mind, I knew I had to write a series on the secrets of being an AIX systemsadministrator. In this five-part series, I cover the things I wish I had known about AIX before I becamean admin. You’ll learn the practical knowledge that can’t be acquired within training classes or booksor gleaned from the man pages on a server. And, hopefully, I’ll save you from some of the headachesand heartaches I’ve faced in my many years of taking care of servers in all sorts of environments, fromeducation and telecommunications to agriculture and outsourcing.



2 Chapter 1: Breaking into the Business

Install Linux or play with other flavors of UNIX. Since its inception in the early 1990s, Linux hasbecome hugely prolific. And with the advent of AIX 5L, there’s integration between AIX and Linux.Even if you have access to an AIX server, by building your own Linux box at home, you’ll be able toplay around and experiment with commands as the root user—blowing a few things up in a safe envi-ronment—before you lay hands on an AIX production server that’s worth millions of dollars.

Find a mentor. Try to locate a skilled AIX admin who’s generous with sharing information and has a

patient teacher’s spirit. Don’t ever think you know more than him or her; approach your admin witha kind, inquisitive attitude and learn as much as you can from seeing how he or she reacts to varioussituations over time. Take copious notes and ask questions whenever you can. And buy your mentor ameal or drink after work to show your appreciation for his or her knowledge and wisdom.

Apply and prepare for rejection. When trying to find a position, there’s a great paradox that happensto nearly everyone: You can’t get a job as an admin without experience, and you can’t get experi-ence without a job. This is why you’ll need to beef up your resume by demonstrating all the time andenergy you’ve invested into learning AIX. You might need to quantify this by passing a certificationexam, getting references from qualified people, or finding a low-level entry position and working your

way up from there. Be ready to get rejected, but don’t give up hope; stay determined and watchful.

If you follow these steps, you’ll be on the right path for a solid career in this field. And from there,you’ll understand more of the secrets of being an AIX systems administrator.

And what are the secrets, you ask? Let’s start with the all-important user ID.

User ID Utopia

One of the first things that AIX systems administrators get tasked with in order to familiarize them-selves with their environments is user ID management. The theory is that this is one of the best waysfor admins to get to know their user communities and the function and purpose of their servers. How-ever, more often than not, user ID management is seen almost as a janitorial task—a sort of necessaryevil that everyone has to take part in from time to time. That’s because it’s no fun working throughendless password resets, changing huge groups of users who weren’t set up properly initially, or man-ually managing dozens of user IDs on many servers.

There are some good rules for managing user IDs that aren’t typically found in manuals or trainingclasses. I’ve acquired these guidelines after years of seeing things go amiss, taking drastic measures to

fix problems, and being kept awake at all hours of the night. In general, if you use these secrets, yourlife as an AIX admin will go much more smoothly.

Protect the root password. The more people who know the root password, the greater the likelihoodof someone running the wrong command. Guard it as though it’s a bank account number.

Homogenize user IDs. Try to get a spreadsheet or system going to keep all of the user ID numbers forall of the user IDs across your servers in sync. This way, you won’t need to be brought in to set per-missions or ownership should someone need to transfer files from one server to another or use an NFSmount across systems. If you’re administering more than just a few servers, consider using a utilitysuch as NIS or LDAP to handle things from a single location.



Chapter 1: Breaking into the Business 3

Make important user IDs local. Make sure that any user IDs and home directories, such as those usedby applications, are defined locally to the server. I’ve seen some environments in which network out-ages have crippled mission-critical servers because all of their resources were located externally to thesystems. If your business won’t work without some specific user IDs being present, keep them local.

Establish all groups up front. One of the strangest problems an admin can encounter is getting themessage, “Cannot set process credentials,” when someone attempts to log in. This message happens

when the user’s primary group doesn’t exist on the server. To solve this problem and make manage-ment easier in the long run, give all the user IDs all of the possible groups they need up front.

Use proper home directory management. If you have user IDs that consume a good deal of space intheir home directories, make the home directories into their own file systems, and then set permis-sions and ownership as you create the user IDs. Put the home directories in places in which theymake sense; I’ve seen home directories placed in all sorts of locations such as \etc and \tmp, wherethey could potentially harm the server or cause general confusion. Keep them in \home or anotherfile system structure that stands out for the applications on the server.

Set password expiration warnings. If you’re using best computer security practices or have to conformto federal laws or regulations, your user IDs will have regularly scheduled password expiration dates.Do yourself a favor and set a reminder email to go to your users a week or so before the change sothat they can take action before they get locked out.

Install sudo. Lastly, I believe that there’s no greater application for managing user IDs than sudo. Sudoprovides a safe and secure way to give access to privileged commands while minimizing risk to theserver. The sudo configuration file can be ported across multiple servers and even onto different ver-sions of AIX, UNIX, or Linux systems. I believe in using it on any server I administer, if for no otherreason than providing another audit trail to becoming the root user.



4 Chapter 2: File Systems

Chapter 2: File Systems

On the list of the most common activities that AIX systems administrators perform, file system mainte-nance comes right after user ID maintenance and password resets. I can’t count the number of timesI’ve created, grown, shrunk, or deleted file systems in the course of my professional career. When youthink about it, this makes sense: Almost every user needs space to store his or her data.

AIX’s flexibility for managing data comes with a downside: There are many ways to make an errorin file system maintenance that will set the stage for future problems on the server. It takes only oneor two commands to make a server practically impossible to grow, so that you can’t keep up withdemands for additional places for data. Growing a file system the wrong way—for example, growingan IBM PowerHA file system on a server without using the PowerHA command set—can also createmore work in the long run. To help you avoid file system maintenance mistakes that could result ininefficiencies on your server, this article offers some pearls of file system wisdom that I’ve acquiredover the years.

Use the Root Volume Group for Rootvg Data Only

The most common mistake administrators—especially novice admins—make is to put a file systeminside the root volume group (rootvg) or to use space that’s within the rootvg for application-relatedwork. Here are the three big reasons you shouldn’t do this:

• If you’re using internal disks, you’ll be more limited as to how large you can make your filesystems.

• In the event that the file systems need to be exported to another system, you’ll wind up exportingyour entire rootvg.

• Putting a file system within rootvg can make backups performed using mksysb or other AIX backuputilities exceedingly large.

I recommend using rootvg space only for applications in limited circumstances, such as small webservers, personal AIX systems, and temporary testing environments.



Chapter 2: File Systems 5

Break Down Volume GroupsWhen you begin to plan a Power Systems server environment, think about how to use your disk spaceefficiently and purposefully. Separate the data into volume groups according to guidelines such ashow dynamically VGs will change, types of data and access levels, and types of storage. For example,AIX 6.1 and 7.1 provide a new flag, -X, for the mkvg and chvg commands, which can restrict VGsto using a certain type of storage, such as solid-state drive (SSD) disks, thereby preventing a mixed-storage environment that could cause a hit on the server’s I/O. Use these tools with foresight to design

a maintainable system.

Use JFS2 and Scalable VGsThe more modern versions of AIX include two features of the Logical Volume Manager (LVM) thatI recommend be used almost everywhere. The first is scalable volume groups. In the past, AIX hadlimitations as to how many physical volumes could be in a volume group, how large the volumegroup could get, and how large the physical partition size could be. Scalable volume groups eliminatealmost every reasonable constraint previously associated with managing volume groups.

The second feature is the enhanced journaled file system structure, better known as JFS2. Just asscalable volume groups improved management of larger disks, JFS2 took the limitations of JFS andrendered them obsolete by permitting file systems to grow larger than the 2TB limit. JFS2 also gaveus better tools, such as the ability to shrink the size of a file system. If you create your volume groupsand file systems using these two features, you’ll eliminate 90 percent of the growth and sustainabilityproblems that existed just a decade ago.

Keep Physical Volumes the Same Size Whenever PossibleAesthetically speaking, there’s nothing worse than pulling up information on the physical volumes ina volume group and seeing all sorts of random disk sizes. I’ve seen servers with disks ranging from

20GB to 500GB—all in the same volume group. This discrepancy in sizes can be caused by disksbeing mixed and matched across local and SAN storage, people responding to emergency file systemgrowth requests, and sloppy SAN administrators. However, this kind of non-uniform disk layout canhave other implications, such as limiting growth (e.g., a logical volume’s inter-disk policy is reached)and impacting I/O (e.g., a large, hot disk takes 80 percent or more of the I/O for a volume group).

I recommend working with SAN administrators and those in charge of storage to come up with a uni-form disk-size policy for volume groups. Set the physical volume size to something appropriate—forexample, 50GB—and stick to that size policy. If you set the policies for your logical volumes to bestriped across all the disks (assuming there’s some type of RAID configuration on the back end, as is

the case in most SAN environments), you’ll avoid creating any hot spots. This configuration has theadded benefit of making the root disk easily visible when you’re booting through a System Manage-ment Services (SMS) menu if you pick a unique size, such as 48GB, for its disks.

Simple Steps to Better File ManagementBy following my advice, you’ll find that once-troublesome file-system requests will become one of theeasiest tasks you to perform. The tips I provided will also help you in the long run with patching yourservers.



6 Chapter 3: Tips for Patching Your AIX Server

Chapter 3:

Tips for Patching Your AIX Server

Nowhere is the truism “the only constant thing is change” more relevant than in the IT world. We

have to deal with the constant presence of external threats such as exploits and vulnerabilities thatmust be removed to prevent servers from being compromised. Then, too, software is continuallyupdated as new tools are released and features are added to existing software and OSs. So as tech-nology constantly evolves, keeping AIX servers up to date with the latest versions of the OS is crucial.In this article, we’ll look at how to patch AIX servers and maintain software on them.

Breaking Down the OS

Before we delve into the actual topic of patching, I want to back up a bit and discuss AIX’s versioningstructure. AIX has one of the easiest structures for keeping track of and understanding the levels ofsoftware on a server. Unlike Microsoft Windows, with its non-intuitive version numbers—for example,Windows 98 was released long before Windows 7—or an OS whose patch levels aren’t easily dis-cerned when you look at the individual pieces of the OS at a glance (say, when watching a Solarispatch cluster as it runs), AIX has a simple way of iterating each version of its OS and components.

The AIX OS comprises four main levels: version, release, technology level (TL), and service pack (SP).

The version and release numbers denote the main levels of AIX and typically change as major featuresor hardware enhancements are released. The next level under Release is TL; TLs are groupings of largequantities of OS filesets that contain new functions or features. Finally, under TLs are SPs, which aremore minor revisions (i.e., fixes) within each TL. You can view the levels installed on your system byrunning the oslevel -s command.

Likewise, AIX filesets generally reflect the OS level. You can obtain the levels for a particular fileset byrunning the lslpp -l command against the fileset; the four numbers returned in the command outputgenerally reflect the version, release, TL, and SP pretty well. However, other pieces of software (i.e.,DB2) often don’t have any relationship to the level of the AIX OS.



Chapter 3: Tips for Patching Your AIX Server 7

Commit-Apply-Commit

The first step to maintaining the AIX OS on servers is to understand the difference between a com-mitted and an applied fileset. When a fileset is committed on a server, there’s no way to roll back to aprevious version of the software, short of a reinstall. The committed fileset is locked in place. When afileset is applied, however, it can be rejected and removed from the server in the event that applying

the fileset causes something to go wrong on the server.

When it’s time to apply some patches or upgrade a server, especially when dealing with TLs and SPs,I recommend starting with a mksysb backup of the server first. Then, after the backup is done, commitany applicable filesets to cement the state of the OS. Following this procedure will provide a solidfoundation and restore point for the rest of the process.

Install the software in the applied state so that in the event that something is off-kilter with the patchesor upgrade, it can be promptly rejected. If you can afford to do so (even if the software doesn’t requireit), I advise that you also reboot the server afterward to make sure that the system periodically gets

tested and any latent problems can be shaken out. After a few weeks of the server running well andgoing through a vetting period, commit the software to complete the process and set the new baselinefor the server.

Stick with the Big Groupings

Sometimes an application will require an individual OS fileset to be upgraded in order to work prop-erly. For example, the pre-check for installing Oracle will often call out several filesets to be patchedbefore the database software can be installed. However, I never advise upgrading filesets on a one-off

basis; I always stick with the practice of upgrading through TLs or SPs.

When admins deviate from this practice and place a number of incongruous updates on their servers,it makes administration more difficult in the long run. Commands like oslevel or instfix will returninconsistent numbers for the software levels that are running. Future patches may balk at having somecomponents already at higher levels than they should be. Plus, if you have to contact IBM Support forhelp, it will make explaining your server much more complicated than simply saying, “I’m runningAIX 6.1, TL 06, SP 05.”

The only cases in which I would endorse deviating from this practice are if something is seriously

broken on the server or if a high-profile vulnerability could impact the server. In such cases, it’s appro-priate to add an IBM eFix and resume the recommended patching practice after IBM integrates the fixinto a future TL or SP.

Use NIM or a Software Repository

One big headache that plagues AIX systems admins is working in an environment where servers areall across the board with their OSs. I’ve been in some shops that ran every version of AIX, from 5.1 to7.1, with multiple TLs and SPs in each version and release. The variation of OS versions made keeping



8 Chapter 3: Tips for Patching Your AIX Server

track of servers a nightmare: finding which systems needed to be patched, which ones had vulner-abilities, and picking and choosing which needed immediate patching, especially when IBM emailedwarnings about high-impact alerts.

The Network Installation Manager (NIM) utility makes it a breeze to install the same level of OS ontomultiple servers at once. Find a good level of the AIX OS that works for your servers, install NIM ontoa small LPAR, and turn that system into a bastion host that serves as a software fix repository. By doing

this, you’ll only need to be concerned with one or two iterations of the OS, and you’ll find it easier tomass-deploy a homogenous OS configuration.

Watch for RPMs Versus Filesets

With the advent of Linux affinity in the AIX OS about a decade ago, it became possible to compileand install Red Hat packages onto Power Systems. While most OS patches pertain to AIX filesets,there are a fair number of applications that work closely with the OS that use RPM packages. These

applications include utilities like sudo, wget, and gcc, which all have a role in administration.

When you go to patch your servers, be sure to also check the RPM packages installed on your systemto determine whether they should also be updated. Use both the rpm and lslpp commands to checkall those other pieces of software.

Use nimadm_migrate and alt_disk_install Strategies

One of the best features of AIX that has come out in the past few years is a combination of two tech-

nologies: nimadm_migrate, which is the AIX System Management Interface Tool (SMIT) fastpath tomigrating a client box to a new version of the OS, and alt_disk_install. These two commands allowadmins to take the currently running OS, clone it onto a blank hdisk, and then even apply patchesonto that drive. This way, the server stays completely up and there’s no risk to the currently runningroot volume group (rootvg) as the server is migrated to a new SP, TL, or even a completely new ver-sion and release of the OS. All it takes is a reboot to switch over to the fresh OS. And in the eventsomething goes wrong, the server just needs to be rebooted onto the original disk to put things backthe way they were.

Stay Current with PatchingKeeping your servers up to date with the AIX OS and patching them on a routine schedule can staveoff unnecessary downtime, give your users more features, and periodically “shake the tree” to see ifanything falls out. We’ll continue our exploration of AIX management in the next article, when welook at a few techniques to make networking more understandable and manageable.



Chapter 4: Networking 9

Chapter 4: NetworkingIn AIX, I’ve found that networking is probably one of the most complicated subjects around. Somecomponents of networking are addressed by making changes to flat files, while others are handledthrough the Object Data Manager (ODM). There are typically at least three commands or ways ofdoing something, from adding a route to turning off an interface. And what seems like a subtle orinnocuous action can wind up causing headaches on the server in due time—for example, a reboot

that brings out duplicate default routes.

I have extensive experience in both setting up and messing up networking on AIX servers worldwide.Along the way, I’ve taken copious notes on how to manage networking, so that others will hopefullyavoid the same plights I encountered. The following is a condensed version of the knowledge I’vegleaned about AIX networking through hard-won experience.

Understand Physical and Logical Relationships

Although most forms of UNIX and Linux will have only one device under the /dev directory todescribe each networking interface, AIX is different in that it will create both a device for the physicalinterface (e.g., ent0) and a device for the logical interface (e.g., en0). Each device serves a unique pur-pose; for example, media speeds are set on the physical interface, whereas IP addresses are definedon the logical interface.

Knowing this about the physical and logical devices, your one key take-away is that if you need to dosomething to the physical interface, you’ll need to shut down, disable, or remove the logical interfacebefore AIX will accept any commands to manipulate the physical interface.

Establish EtherChannel Devices First

Before you define any IPs on your servers, to create redundancy and get higher performance, I rec-ommend setting up devices that use Cisco EtherChannel technology wherever possible. Much likebonding in Linux or IP network multipathing (IPMP) in Solaris, EtherChannel lets you gather multiplephysical interfaces into one connection. The interfaces can be aggregated so that traffic goes downboth pipes simultaneously, or they can work in an active-passive mode conditional upon failover. The“smitty etherchannel” fastpath is the easiest way I’ve found to define EtherChannel devices.



10 Chapter 4: Networking

One thing worth noting is that the EtherChannel device, although logical in nature, still has a physicaland a logical component. For example, if you choose to use ent0 and ent1 to create an EtherChanneladapter, the physical device will be created as ent2 with a logical device of en2. The EtherChanneladapter behaves almost identically to any other standard network adapter as far as setting networktunable parameters or establishing IP aliases, but the physical interface will show some additionalinformation when viewed using the lsdev or lsattr command.

Use SMIT for Your Initial IPs

I’ve always subscribed to the philosophy that the proficiency of an AIX administrator can generallybe determined by how often or seldom the admin relies upon the System Management Interface Tool(SMIT) to do his or her work. But there are a few tasks where, rather than memorize long commandswith dozens of flags, I will turn to SMIT to accomplish my work. Setting up initial IP addresses is oneof those tasks.

The “smitty tcpip” fastpath is the quickest route to navigating to the menus for setting up everythingnetwork related. From the SMIT Minimum Configuration & Startup screen, define your first IP addressand default gateway through the menu. Then, as you need to add IPs to other interfaces, use the“smitty chinet” fastpath for those other devices. Using the Minimum Configuration & Startup screen todefine additional interfaces could adversely affect the routing on the server.

Use the ODM Wisely

Most networking information in AIX is stored within the ODM. Only a few flat files that pertain to net-

working can be modified manually, such as /etc/hosts or the /etc/rc.tcpip and /etc/rc.nfs files. This canmake it difficult to manage, change, or remove items like network routing from the server quickly andeasily.

Aside from the initial plumbing-up of IPs on interfaces, the one other thing I’ll do through the ODM isto assign any IP aliases onto devices. I do so using the following command:

chdev -l enX -a alias4=$IP,$NETMASK

This way, following a reboot, all IPs on that specific adapter will come up automatically. However,beyond this point, I stick with modifying other flat files.

Case in point: I’ve found the task of adding additional routes to a server by means of the ODM to be abeast. I’ve had to hunt through obscure corners of the CuAt database when trying to remove or adjusta single route. Instead of trying to jump through hoops in adding or removing routes through theODM, I typically modify the /etc/rc.net file under “Part II - Traditional Configuration” and add all myroutes to this area using the route command. This way, I can delete active routes off the server using aroute delete command and strip them from the file without having to do a reboot or worrying aboutthe ODM.



12 Chapter 5: What to Do After the First Server Reboot

Chapter 5: What to Do After

the First Server RebootIf you’ve been an AIX systems administrator for a while, you know that when you’ve finished buildinga server and installing an OS, you haven’t really finished building the server. Developers or applica-

tion owners might think that because a system is up and pingable they can go ahead and load alltheir stuff onto it, but there’s still a lot of other work that must be done to make the system usable. Inthis fifth and final article in my “Secrets of an AIX Awdministrator” series, we’ll walk through the stepsadmins should take immediately after building an AIX server from scratch for the first time—the tasksyou need to perform to complete the server-building process.

Step 1: Lock Down RootThe very first step you should take after your server reboots following the installation of AIX is tochange the root file system password. This is when the server is most vulnerable to problems, and thekey to the kingdom must be secured.

Step 2: Mirror the OSIf you’re using internal drives, I recommend that at this time you mirror the root volume group (rootvg)because there will be next to no I/O going on with the server. Although mirroring should typically falllater on the priority list, it’s worth your while to take 20 minutes now to have the system mirror therootvg, instead of later on, when you’ll be contending against users logging in and doing their initialconfiguration.

Step 3: Patch the ServerSimilar to mirroring the OS, if you patch your server with the proper technology level (TL) and servicepack (SP) at this point in the process, you’ll also avoid the hassle later on of trying to find a windowof time in which to reboot the server. Patching the server now provides the additional benefit of let-ting you establish an expectation for the OS deployment, which will prevent users from complainingabout future patching interfering with their installations and software.

Step 4: Set the Date and Time ZoneAlthough your server will likely have the correct time by this point, check the TZ variable in the /etc/ environment file. Make sure that the system’s time zone is in the correct locale, or set the time zone



Chapter 5: What to Do Afterthe First Server Reboot 13

if your project requires doing so. You want to avoid the painful future scenario of discovering thata database or web page has been logging time in GMT when the system should have been in PST,requiring records to be backlogged or skipped forward by hours to correct the discrepancy. Also, bythis point in the process, you shouldn’t have to reboot your server from now on for any further initialOS work.

Step 5: Disable Unnecessary Network Services; Install and Use SSHThe /etc/inetd.conf file is chock-full of various network services, from telnet and ftp to rsh and fingerd.Pretty much every service running either poses a security risk in today’s world or is unnecessary. Thus,you should comment out the entire file and refresh the inetd daemon and instead use more securecommunication protocols such as Secure Shell (SSH) for your communications to and from the server.

Step 6: Set Up IPsNow that your system is secure from both a login and network perspective, this is the time to set upthe IP addresses that you’ll need for communicating with the world.

Step 7: Grow and Develop rootvg File SystemsDepending on physical partition sizes, when an AIX server is built from scratch, the process will typi-cally create the file systems on the server with the minimum amount of necessary space possible. Thisspace limitation will become a hazard as soon as the server is put into use, so as a starting point, Irecommend growing the file systems to at least the sizes listed in Table 1.

I’ll also do two other things at this time. First, I’ll break out /var/tmp into its own file system, sized atabout 1GB. I’ll do this because many applications will use this space as a temporary area for files, andseparating /var/tmp in this way will offset some of the risk of a user maxing out /var by doing some-thing like using vi on a mammoth-sized file. The second thing I’ll do is grow the paging space anddump devices to sizes that will work for application owners and enable the capture the data from anycrashes that might happen.



14 Chapter 5: What to Do Afterthe First Server Reboot

Step 8: Define User IDs and GroupsUsually, I would recommend hooking users up with access (including sudo) as one of the last thingsto do on a server, because the users could prematurely hop onto the box and start doing work beforeeverything is completed. But there’s one good reason I put this action here in the list of things to do:Defining user IDs makes it easier to perform the next step.

Step 9: Establish External Volume GroupsRather than coming back around after disk space has been appropriated, logical volumes are defined,and file systems have been mounted to set ownership and permissions on all applicable directoriesand files, I typically prefer that user IDs (or at least the local application-specific user IDs) alreadyexist, to make establishing external volume groups a job that can be done in one fell swoop.

Step 10: Create a mksysb imageIf you haven’t had a chance to do so, create a mksysb image of the server and store it away. There’snothing more frustrating than having to redo all your work, and a mksysb image will save you time

and energy in case you have to go to backups for a restore. And speaking of mksysb images…

Step 11: Create a “Golden” Image Using NIMIdeally, you’ll only ever have to set up a server from scratch once. After you do this, the mksysb imagethat you created can be used as a “gold standard” from which all future AIX builds can be done, facil-itated by Network Installation Manager (NIM). This golden image can be rapidly distributed to newservers, which reduces your time investment in creating AIX builds. Plus, if there are any componentssuch as tunables, additional user IDs, or system configurations that you need to mass-distribute in thefuture, it’s much easier to do so using a single administrative source rather than having to go out toeach and every server individually.

Shorten Your AIX Learning Curve

Becoming a skilled AIX systems admin is no easy task. It will take years to develop and hone yourskills and to become familiar with your servers and customers. Most professional admins I know willagree that it typically takes at least six months to become proficient with an individual componentof new technology, such as when LPARs and Virtual I/O Servers came on the scene, and at least ninemonths of understanding your employer’s business before your learning curve takes you from being

dangerous to knowing the basics of how their business works.

In this five-article series, I’ve shared a number of tips and tricks I’ve learned along the way—some-times painfully—that have helped me whenever I go into new environments and lay hands on keysfor the first time in different industries. Integrating these ideas and concepts into your own skill set willbetter your chances of avoiding mistakes, improve your work, and help you develop as an AIX sys-tems admin.

aix administrator secrets

Documents