| | h2. AIX V5.3 system administration best practices |
| | |
| | A Service Level Agreement provides very important guidance in determining how a server should be configured and managed and, consequently, the best practices to be implemented to configure and manage it. A Service Level Agreement (SLA) is the contract between an IT provider and business users, often established within an [ITIL|http://en.wikipedia.org/wiki/ITIL] framework or the like. (Within ITIL, Incident, Problem, and Change Management processes are particularly important. IBM offers services to help optimize IT investments, improve performance, achieve availability objectives, and avoid costly problems. See the [Integrated Technology Services|http://www.ibm.com/services/us/index.wss/gen_it] [Infrastructure and systems management|http://www.ibm.com/services/us/index.wss/itservice/its/a1000415] web page.) An SLA clearly states the level of IT services which users require. The SLA for a departmental file server is likely to be quite different than that for an enterprise data base server. This page attempts to document best practices which are appropriate across a broad spectrum of servers. Every best practice documented here will not be applicable to every AIX server. |
| | |
| | h2. This web page is meant to supplement, *not replace*, other related best practices which have been published |
| | * [??Service and support best practices for UNIX servers??|http://www.ibm.com/servers/eserver/support/unixservers/bestpractices.html] |
| | * [??Paging Space Policies and Practice??|http://www.ibm.com/servers/aix/products/aixos/whitepapers/pagingspace.html] white paper |
| | * Best practices for implementing Oracle on AIX: |
| | *# [??Oracle 9i & 10g on IBM AIX 5L: Tips & Considerations??|http://www.ibm.com/support/techdocs/atsmastr.nsf/WebIndex/WP100556] |
| | *# [??Oracle DB & RAC 11g on IBM AIX: Tips and Considerations??|http://www.ibm.com/support/techdocs/atsmastr.nsf/WebIndex/WP101176] |
| | *# [??Oracle DB & RAC 10gR2 on IBM AIX 5L: Tips and Considerations??|http://www.ibm.com/support/techdocs/atsmastr.nsf/WebIndex/WP101089] |
| | *# [??Implementing Oracle 10g RAC with ASM on AIX??|http://www.ibm.com/support/techdocs/atsmastr.nsf/WebIndex/WP100708] white paper |
| | *# [??Oracle Architecture and Tuning on AIX??|http://www.ibm.com/support/techdocs/atsmastr.nsf/WebIndex/WP100883] white paper |
| | *# [??Tuning IBM AIX 5L for an Oracle Database??|http://www.dba-oracle.com/t_ibm_aix_tuning.htm] white paper |
| | * [??IBM System p Advanced POWER Virtualization Best Practices??|http://www.redbooks.ibm.com/abstracts/redp4194.html] Redpaper |
| | * [IBM eServer Security Planner|http://publib.boulder.ibm.com/infocenter/iseries/v1r1/en_US/info/secplanr/securwiz.htm] and the [??Strengthening AIX Security: A System-Hardening Approach??|http://www.ibm.com/systems/p/library/wp_aix_lit.html] white paper |
| | * [Learn 10 good UNIX usage habits|http://www.ibm.com/developerworks/aix/library/au-badunixhabits.html] web page |
| | |
| | h2. This web page is intended to build upon (*not replace*) basic UNIX system administration 101 |
| | * When installing AIX for the first time (or upgrading to a new release level), be sure to install available fixes. See the [AIX V5.3 installation best practices|Installation#UpdSfw] web page for more information. When installing AIX on a LUN on a Storage Area Network (SAN), be aware of considerations unique to that environment. See [AIX V5.3 boot from SAN|AIXV53SANBoot] for more information. |
| | * Capture bootable backups periodically (monthly/quarterly?). See [AIX V5.3 backup and restore|AIXV53Backup] for more information regarding AIX backups. |
| | * Store some bootable backups off site for recovery if the data center is destroyed. |
| | * Test the restore process periodically (yearly?) by restoring the most recent bootable backup. Wouldn't want to discover that a backup can not be successfully restored while in the middle of disaster recovery, would we? Doh\! It is best for the restore to be tested by someone other than the person who captured the backup, to confirm that restore procedure documentation is adequate. |
| | * Capture application data backups (volume groups other than rootvg and filesystems not mounted when mksysb is captured). |
| | * Test application data restore process periodically (yearly?) by restoring the most recent backup. It is best for the restore to be tested by someone other than the person who captured the backup, to confirm that restore procedure documentation is adequate. |
| | * Monitor the system for errors. Attempt to discover the root cause of every error and to address the cause to minimize the number of errors which occur, while acknowledging that getting a failed system back in operation must sometimes take precedence over collecting the diagnostic information required to determine failure root cause. The primary AIX error log can be displayed using the [{{errpt}}|http://publib.boulder.ibm.com/infocenter/pseries/v5r3/topic/com.ibm.aix.cmds/doc/aixcmds2/errpt.htm] command. Please note that an [AIX Error Notification exit|https://www.ibm.com/developerworks/wikis/display/WikiPtype/AIXV53hdwerr] can be used to take action (eg, send an email) if a particular error occurs. The primary HMC error log can be displayed from the HMC GUI using Service Applications \-> Service Focal Point \-> Manage Serviceable Events. Please note that Service Applications \-> Service Agent \-> Customer Notification can be used to configure an HMC to send an email when a new serviceable event is logged. Please note that {{alog \-t console \-o}} will display messages which have appeared on the AIX system console and {{alog \-t boot \-o}} will display messages which were generated as AIX booted up. |
| | * Conduct a post mortem after each application outage. Attempt to answer the following questions and then act upon the answers: (1) Was there any warning of this outage? If so, why was the warning not acted upon in time to prevent the outage? (2) What changes can be made to prevent the outage in the future? (3) Are other servers exposed to similar outages? |
| | * Test operating system, middleware, and application changes on a test server before implementing them in production. The test server's configuration should be as close as possible to the production server's. This is especially important when service level agreements impose availability and/or performance requirements on the production server. |
| | * Implement procedures to protect servers from intrusion (eg, implement and enforce password standards, force passwords to be changed periodically, enable AIX system auditing and implement procedures to review audit logs regularly, etc). See the [AIX Security Expert|http://publib.boulder.ibm.com/infocenter/pseries/v5r3/topic/com.ibm.aix.security/doc/security/aix_sec_expert.htm], the AIX [Security checklist|http://publib.boulder.ibm.com/infocenter/pseries/v5r3/topic/com.ibm.aix.security/doc/security/security_checklist.htm], and the [_Install OpenSSH_|#OpenSSH] best practice below. |
| | * Run commands, applications, cron jobs, etc as root only when absolutely necessary. (Please note that AIX allows sysadmins to define administrative roles which grant non-root users access to functions which normally require root access. For more information, please see the [??Administrative roles?? article|http://publib.boulder.ibm.com/infocenter/pseries/v5r3/topic/com.ibm.aix.security/doc/security/administrative_roles.htm] in the ??AIX V5.3 Security?? manual. And please note that [{{sudo}}|http://en.wikipedia.org/wiki/Sudo] for AIX is available for download from the [AIX Toolbox for Linux Applications|http://www.ibm.com/systems/p/os/aix/linux/index.html] web site.) |
| | * Install middleware and application software in filesystem(s) dedicated to that purpose. (That is, *don't* install middleware and applications in {{/home}}, {{/}}, {{/usr}}, {{/tmp}}, or {{/var}}. Any new filesystem must, of course, have a mount point (eg, {{/appl}}) in some existing filesystem.) Even when a vendor [packages software in AIX {{installp}} format|http://publib.boulder.ibm.com/infocenter/pseries/v5r3/topic/com.ibm.aix.genprogc/doc/genprogc/pkging_sw4_install.htm], it is possible to allocate a dedicated filesystem for the software before installing it, if desired. For example, the IBM C compiler for AIX (XL C Enterprise Edition for AIX) is packaged to install in {{/usr/vac}}. If a {{/usr/vac}} filesystem is allocated and mounted before the C compiler is installed, when installing the compiler the AIX {{installp}} command will check the {{/usr/vac}} filesystem (rather than the {{/usr}} filesystem) for required free space, will allocate more space to the {{/usr/vac}} filesystem if free space is insufficient, and will install the compiler's filesets in the directory tree below {{/usr/vac}}. |
| | * Implement procedures to collect and archive server performance information for capacity planning purposes. |
| | * Implement procedures to regularly prune [files which may grow without limit|http://www.ibm.com/support/docview.wss?rs=111&uid=isg3T1011082] (eg, {{/smit.log}}, {{/var/adm/wtmp}}, and {{/etc/security/failedlogin}}) and remove stale files from {{/tmp}}. ((i) Note: AIX does not remove files from {{/tmp}} at boot time - consider implementing [{{skulker}}|http://publib.boulder.ibm.com/infocenter/pseries/v5r3/topic/com.ibm.aix.cmds/doc/aixcmds5/skulker.htm] by uncommenting the line in root's crontab which invokes it, after first reviewing the {{skulker}} shell script to understand what it does.) |
| | * Maintain a change control log which documents changes and the date & time they were made. Use this change control log when a new problem crops up to identify changes which may have led to the problem. (Please note that the {{smit}} and {{smitty}} commands log every action in the {{/smit.log}}, which can therefore provide useful supplementary detail to a change management log.) |
| | * If appropriate, implement an accounting and charge back system which is fair to all users. To this end, please see the [??Accounting and Auditing on AIX 5L?? Redbook|http://www.redbooks.ibm.com/abstracts/sg246396.html] and please note that the [IBM Tivoli Usage and Accounting Manager|http://www.ibm.com/software/tivoli/products/usage-accounting/platforms.html] supports AIX [Advanced Accounting|http://publib.boulder.ibm.com/infocenter/pseries/v5r3/topic/com.ibm.aix.accounting/doc/accounting/intro.htm]. |
| | |
| | {note:title=Note}The contents of this web page solely reflect the personal views of the authors and do not necessarily represent the views, positions, strategies or opinions of IBM or IBM management. Please use the !http://www.ibm.com/developerworks/wikis/images/icons/add_comment_16.gif! +Add Comment+ link at the bottom of the page to provide feedback. *Note:* Until you log in (using the link in the upper right corner of this web page), you will not see the !http://www.ibm.com/developerworks/wikis/images/icons/add_comment_16.gif! +Add Comment+ link and you can not add a comment. If you do not already have an IBM ID, use the +Register Now+ link on the sign in page to obtain one. Registration is quick and easy.{note} |
| | |
| | h2. Here is an index to the best practices below |
| | |
| | # [Don't store local files in / and /usr, minimize custom changes to executable AIX files in / and /usr (eg, {{/sbin/rc.boot}}), and if changes must be made in / and /usr, make sure those changes are documented for the benefit of others who might assume responsibility for administration of the AIX image at some future time.|#Leaverootvg] |
| | # [Configure {{/etc/rc.d/rc2.d/Src.local}} and {{/etc/rc.d/rc2.d/Krc.local}} shell scripts which AIX will run at boot and shutdown, respectively.|#Userc.d] |
| | # [Make sure adequate system dump space is allocated.|#DumpSpace] |
| | # [Prepare the system so you can initiate a stand-alone dump if AIX hangs (won't allow logins - might or might not respond to a ping).|#AllowDump] |
| | # [Never edit {{/etc/filesystems}} to define or modify a filesystem definition.|#Noeditfilesystems] |
| | # [Before manually editing any file in the / and /usr filesystems for the first time, save a copy of the file.|#Savecopy] |
| | # [Configure the root user so you always know which system you are on and which directory you are in.|#rootprofile] |
| | # [After installing base AIX, install optional components by installing bundles rather than filesets.|#Bundles] |
| | # [Install a few individual filesets in addition to bundles.|#Morefilesets] |
| | # [After installing any new optional AIX filesets, always reinstall the current AIX Technology Level and Service Pack.|#ReinstallTL] |
| | # [Before creating any userids for which {{/bin/ksh}} is the default shell, update the {{/usr/lib/security/mkuser.sys}} file shipped with AIX to install a profile other than the system default when a new userid is created.|#mkuser.sys] |
| | # [Install OpenSSH.|#OpenSSH] |
| | # [Update $MANPATH for all users so that the {{man}} command can find man pages installed by applications (such as _AIX Toolbox for Linux Applications_ software).|#MANPATH] |
| | # [Configure TCP/IP to search local {{/etc/hosts}} to resolve a host name before trying DNS.|#netsvc.conf] |
| | # [Configure AIX Workload Manager (WLM) to reserve CPU time for the root userid.|#WLM] |
| | # [When configuring an ASCII console/terminal, configure AIX to set the TERM= shell environment variable correctly during login from that terminal.|#TTYTERM] |
| | # [Add useful shell scripts to {{/usr/local/bin}} and make them available to all users.|#ptree] |
| | # [Install {{lsof}} (LiSt Open Files) utility.|#lsof] |
| | # [Install a web browser.|#browser] |
| | # [Install the Adobe Acrobat reader.|#Acrobat] |
| | # [Use {{smitty crcdrfs}} to create a CD-ROM filesystem with a mount point of {{/cdrom}}.|#crcdrfs] |
| | |
| | {anchor:Leaverootvg} |
| | | Best Practice: | Don't store local files in / and /usr. (Mount points are okay, though.) And minimize custom changes to executable AIX files in / and /usr (eg, {{/sbin/rc.boot}}). And if changes must be made in / and /usr, make sure those changes are documented for the benefit of others who might assume responsibility for administration of the AIX image at some future time. | |
| | | Why: | # AIX system maintenance updates files in / and /usr. Local customization to executable AIX files in / and /usr may be wiped out when maintenance is applied. |
| | # During an version upgrade, it is sometimes desirable to use a [Preservation reinstall|http://publib.boulder.ibm.com/infocenter/pseries/v5r3/topic/com.ibm.aix.install/doc/insgdrf/bos_install_intro.htm], which discards the /, /usr, /var, and /tmp filesystems and rebuilds them from scratch. Local files stored in / and /usr will be lost during such a reinstall. (However, please note that in many cases a [Migration reinstall|http://publib.boulder.ibm.com/infocenter/pseries/v5r3/topic/com.ibm.aix.install/doc/insgdrf/bos_install_intro.htm] can be used which, unlike a Preservation reinstall, preserves most file systems, including the root volume group, logical volumes, and system configuration files. But even during a Migration reinstall, local files stored in / and /usr may be lost.) |
| | # It is best to minimize the amount of space used in / and /usr because the only way to recover unused disk space that has been allocated to / and /usr is to create a bootable backup of rootvg and restore the backup. To understand why, one must understand where AIX stores information about filesystems: \\ |
| | \\ |
| | The / and /usr filesystems contain objrepos files, which are containers for the AIX [Object Data Manager (ODM)|http://publib.boulder.ibm.com/infocenter/pseries/v5r3/topic/com.ibm.aix.genprogc/doc/genprogc/odm.htm]. Among many other things, the ODM contains information about filesystems. It is, therefore, impossible to allocate a temporary new file system, copy the contents of /usr to the new filesystem, unmount the old /usr, rename the old /usr, rename the temporary filesystem to /usr, and mount it as the new /usr. That's because the ODM containers (including the objrepos file in /usr) must be updated when /usr is renamed and the rename operations must occur while both the old and new copies of /usr are not mounted, meaning that the objrepos file in /usr is not accessible. \\ |
| | \\ |
| | And the / filesystem can not be unmounted because it contains the mount point for /usr. \\ |
| | \\ |
| | The only way to make / and /usr smaller is to create a bootable backup of the entire system and restore the backup, requesting that a smaller /usr be allocated during restore. \\ |
| | \\ (i) It is no longer the case that the only way to recover unused disk space in / and /usr is {{mksysb}} backup/restore. New in AIX V5.3, JFS2 file systems can be reduced in size. Reduction is initiated with the chfs command in much the same way that a file system is increased in size. For details, see the information about the {{\-a size}} attribute in the [{{chfs}} command article|http://publib.boulder.ibm.com/infocenter/pseries/v5r3/topic/com.ibm.aix.cmds/doc/aixcmds1/chfs.htm] in the AIX V5.3 documentation. And on 64-bit hardware, the AIX V5.3 installation process will, by default, allocate rootvg filesystems ({{/}}, {{/usr}}, {{/home}}, etc) as JFS2 (rather than JFS). And according to the [??BOS installation options??|http://publib.boulder.ibm.com/infocenter/pseries/v5r3/topic/com.ibm.aix.install/doc/insgdrf/bos_install_more_options.htm] article in the [??AIX V5.3 Installation guide and reference??|http://publib.boulder.ibm.com/infocenter/pseries/v5r3/topic/com.ibm.aix.doc/doc/base/aixpdfs.htm], JFS filesystems in rootvg can be converted to JFS2 during a [Preservation reinstall|http://publib.boulder.ibm.com/infocenter/pseries/v5r3/topic/com.ibm.aix.install/doc/insgdrf/bos_install_intro.htm] on 64-bit hardware. And the [IBM Tivoli Storage Manager for System Backup and Recovery|http://publib.boulder.ibm.com/infocenter/tivihelp/v1r1/topic/com.ibm.itsmsbr.doc/bmrug56503.htm] product can be used to convert rootvg JFS filesystems to JFS2 while [restoring a Sysback backup|http://publib.boulder.ibm.com/infocenter/tivihelp/v1r1/topic/com.ibm.itsmsbr.doc/bmrug565114.htm]. | |
| | | How: | Before putting installation images in /usr/sys/inst.images, create a /usr/sys/inst.images filesystem and mount it. | |
| | | How: | Create a filesystem with a name such as {{/usr/local}} in rootvg. Put all local files (eg, {{/usr/local/bin/ptree}}) in subdirectories under {{/usr/local}} (eg, {{/usr/local/bin}}). Add directories containing local executables (eg, {{/usr/local/bin}}) to [PATH= in {{/etc/environment}}|#PATH] so all users have access to local executables. | |
| | | How: | If you want to move everything from an existing directory to a filesystem with that directory as its mount point, use the following procedure: |
| | * Use the {{smitty crjfsbf}} fast path to create a large-file enabled filesystem in rootvg that mounts automatically at boot time with a mount point of /mnt. |
| | * Mount the new filesystem. {color:red}*(Don't forget this step. Ugly things happen if you do\!)*{color} |
| | * Use the commands {{cd <(dirname)> ; find . \-print \| cpio \-lpdm /mnt}} to copy all existing files from the {{<(dirname)>}} directory tree to the new filesystem. Optionally, remove all files from {{<(dirname)>}} after verifying that all files have been successfully copied to /mnt. |
| | * Unmount /mnt. |
| | * Use the {{smitty chfs}} fast path to change the mount point of the new filesystem to {{<(dirname)>}}. |
| | * Use {{ls \-ald <(dirname)>}} to display ownership and permissions of the existing directory. |
| | * Mount the new {{<(dirname)>}} filesystem, which mounts over the old directory. (Best to {{cd}} out of {{<(dirname)>}} first.) |
| | * Use {{ls \-ald <(dirname)>}} again to confirm that ownership and permissions of the filesystem mount point are the same as the directory had and, if not, change ownership & permissions to make it so. | |
| | | How: | If/when changes are made in / and /usr, *document those changes* in a file (eg, [{{/usr/local/README}}|AIXV53AdminBPFiles#sysreadme]) and update [{{/etc/motd}}|AIXV53AdminBPFiles#motd] to make all system administrators aware of {{/usr/local/README}} (follow links to see examples of {{/usr/local/README}} and new {{/etc/motd}} content). (*You will remember to save* {{*/etc/motd{*}}} *as* {{*/etc/motd.orig{*}}} *first, right?* \- See the _Before manually editing any file in the / and /usr filesystems for the first time, save a copy of the file_ best practice.) | |
| | |
| | {anchor:Userc.d} |
| | | Best Practice: | Configure {{/etc/rc.d/rc2.d/Src.local}} and {{/etc/rc.d/rc2.d/Krc.local}} shell scripts which AIX will run at boot and shutdown, respectively. | |
| | | Why: | For reasons described above, it is best not to update any files in / or /usr (such as /sbin/rc.boot) which are shipped in AIX. But sysadmins will certainly want to configure the system to run commands at boot time. Such commands can be placed in {{/etc/rc.d/rc2.d/Src.local}}. | |
| | | How: | Create {{/etc/rc.d/rc2.d/Src.local}} and {{/etc/rc.d/rc2.d/Krc.local shell}} scripts owned by root.system with 550 permissions. {{Src.local}} will be invoked by AIX just after AIX boots up and {{Krc.local}} will be invoked by AIX just before AIX shuts down. Write the scripts carefully and test them thoroughly to make sure they will not hang under any circumstances. \\ |
| | \\ |
| | See the [??Run level script execution??|http://publib.boulder.ibm.com/infocenter/pseries/v5r3/topic/com.ibm.aix.baseadmn/doc/baseadmndita/runlvlscript.htm] article in the ??AIX V5.3 Operating system and device management?? manual for more information regarding run level scripts. \\ |
| | \\ |
| | *Note:* This is one of the few exceptions to the [_Don't store local files in / and /usr_|#Leaverootvg] best practice, which should be documented in {{/usr/local/README}} or equivalent, as suggested in the best practice. \\ |
| | \\ |
| | Note: Execution of run level scripts is driven by the {{l2:2:wait:/etc/rc.d/rc 2}} line in [{{/etc/inittab}}|http://publib.boulder.ibm.com/infocenter/pseries/v5r3/topic/com.ibm.aix.files/doc/aixfiles/inittab.htm]. If run level scripts do not get invoked at AIX boot time, confirm that the line is still there. And please note that if a run level script hangs, the AIX boot process will hang at that line in [{{/etc/inittab}}|http://publib.boulder.ibm.com/infocenter/pseries/v5r3/topic/com.ibm.aix.files/doc/aixfiles/inittab.htm] waiting for the run level script to finish. | |
| | |
| | {anchor:DumpSpace} |
| | | Best Practice: | Make sure adequate system dump space is allocated. | |
| | | Why: | So that if AIX crashes, diagnostic information is captured to determine the cause of the crash, which usually allows remedial action to be taken to prevent a reoccurrence. | |
| | | How: | When AIX V5.3 is first installed, run the {{/usr/lib/ras/dumpcheck}} command to make sure adequate dump space has been allocated. If there are issues with dump space, {{dumpcheck}} adds an entry to the AIX error log, so use {{errpt}} to check for a new error log entry after running {{dumpcheck}}. Since the dump space requirement tends to grow as the system gets busier, configure dumpcheck to run regularly at a time when the system is likely to be fairly heavily loaded. \\ |
| | \\ |
| | Use {{crontab \-l}} to confirm that root's crontab is configured to run dumpcheck regularly at an appropriate time and, if not, use {{crontab \-e}} to update root's crontab. | |
| | |
| | {anchor:AllowDump} |
| | | Best Practice: | Prepare the system so you can initiate a stand-alone dump if AIX hangs (won't allow logins - might or might not respond to a ping). | |
| | | Why: | *It is too late for preparation when AIX is hung.* If AIX hangs and you have no way of initiating a standalone dump, you have no way of collecting diagnostic information to determine why AIX hung. | |
| | | How: | If the system is in a secure area (where unauthorized personnel can not gain physical access to it), invoke the AIX command {{sysdumpdev \-K}}. A standalone dump can then be initiated at any time (even if AIX is hung) using any of the methods described in the [??System Dump Facility??|http://publib.boulder.ibm.com/infocenter/pseries/v5r3/topic/com.ibm.aix.kernelext/doc/kernextc/sysdumpfac.htm] article in the ??AIX V5.3 Kernel Extensions and Device Support Programming Concepts?? manual. Be sure to follow links from the main article to other articles (eg, +Start a System Dump+). \\ |
| | \\ |
| | And there are other ways to initiate a system dump not mentioned in the ??System Dump Facility?? article. \\ |
| | \\ |
| | On POWER5 LPARs managed by a Hardware Management Console, the Dump option of the Restart Partition function can be used to initiate an AIX stand-alone dump, as documented in the [??Using the Hardware Management Console to restart AIX logical partitions??|http://publib.boulder.ibm.com/infocenter/eserver/v1r3s/topic/iphbk/iphbkrestartaix.htm] article in the ??POWER5 Partitioning for AIX with an HMC?? manual. \\ |
| | \\ |
| | A system dump can be initiated remotely via a modem or terminal server after enabling the remote reboot facility using the {{smitty rrbtty}} fast path. But according to PMR 24881,L6Q, the AIX remote reboot facility does not work for a system (integrated serial) port on a POWER5 system. One should instead enable serial port snoop (see the [??Enabling serial port snoop??|http://publib.boulder.ibm.com/infocenter/eserver/v1r3s/topic/iphbp/serialportsnoop.htm] article). \\ |
| | \\ |
| | While an LPAR is dumping, dump progress indicators (0c0, 0c2, 0c9, etc) will appear on the HMC and/or in the LCD display. The various possible indicator values are documented the "Dump progress indicators (dump status codes)" section of the [??AIX IPL progress codes??|http://publib.boulder.ibm.com/infocenter/eserver/v1r3s/topic/ipha6/diag1.htm] article in the ??System p Reference codes?? manual. | |
| | |
| | {anchor:Noeditfilesystems} |
| | | Best Practice: | Never edit {{/etc/filesystems}} to define or modify a filesystem definition. | |
| | | Why: | AIX keeps information regarding each JFS and JFS2 filesystem not only in {{/etc/filesystems}} but also in the LVCB of the logical volume on which the filesystem is defined. (The LVCB (logical volume control block) is in the first 512 bytes of a logical volume. Search the [??AIX V5.3 Information Center??|http://publib.boulder.ibm.com/infocenter/pseries/v5r3/topic/com.ibm.aix.doc/doc/base/aixinformation.htm] for more information about the LVCB.) \\ |
| | \\ |
| | When a volume group is imported, AIX reads the LVCB of every logical volume in the volume group and adds filesystem definitions to {{/etc/filesystems}}. And when a volume group is exported, AIX deletes from {{/etc/filesystems}} the definition of filesystems in the volume group. \\ |
| | \\ |
| | So if {{/etc/filesystems}} is edited to change a filesystem definition, the definition will revert to its original state if/when the volume group in which the filesystem resides is exported and re-imported. *Not a good thing.* | |
| | | How: | Use {{smitty manfs}} or the AIX {{chfs}} command to change a filesystem definition. \\ |
| | \\ |
| | | Filesystems are mounted at AIX boot time in the order they appear in /etc/filesystems. Filesystems are added to /etc/filesystems in the order they are defined. See the [Using Mount Groups in AIX|http://www.ibm.com/support/docview.wss?uid=isg3T1010981] Technote to understand how to change the order in which filesystems are mounted at AIX boot time. If {{/etc/rc}} is changed (as suggested in the Technote), document that change in a file (eg, [/usr/local/README|AIXV53AdminBPFiles#sysreadme]), as suggested in the [_Don't store local files in / and /usr_|#Leaverootvg] best practice. \\ |
| | | Filesystems are mounted at AIX boot time in the order they appear in /etc/filesystems. Filesystems are added to /etc/filesystems in the order they are defined. See the [??How to change the order in which AIX V5.3 mounts filesystems?? web page|AIXV53mount] to understand how to change the order in which filesystems are mounted at AIX boot time without editing {{/etc/filesystems}}. \\ |
| | \\ |
| | Use {{smitty manfs}} to remove a filesystem. (There is a documented AIX [{{rmfs}} command|http://publib.boulder.ibm.com/infocenter/pseries/v5r3/topic/com.ibm.aix.cmds/doc/aixcmds4/rmfs.htm], but be very careful with it. Like the UNIX {{rm}} command, {{rmfs}} does not prompt for confirmation. It immediately destroys the specified filesystem\!) | |
| | |
| | {anchor:Savecopy} |
| | | Best Practice: | Before manually editing any file in the / and /usr filesystems for the first time, save a copy of the file. | |
| | | Why: | A prime directive of system administration is, "Always be able to get back where you were before." If you save a copy before changing a file for the first time, it is easy to determine what changes have been made to the file since the system was first installed. And if you save a copy of a file each time you edit it, you can always restore the saved copy to get back where you were. | |
| | | How: | Use the command {{cp \-ip <filename> <filename>.orig}} to save a copy of the file in the same directory where the original file resides (eg, {{cd /etc ; cp \-ip hosts hosts.orig}}). (The {{cp \-i}} flag warns you if you are about to overwrite an {{<filename>.orig}} which was saved earlier. Very important to avoid overwriting a previously saved copy of the file\! The {{cp \-p}} flag preserves the date & time last modified - that is, the copy has the same date & time as the original.) \\ |
| | \\ |
| | *Note:* Saving individual files in this way does *not* obviate the requirement for regularly scheduled system backups. \\ |
| | \\ |
| | Note: You might consider saving a copy of {{/etc/rc}}, {{/etc/rc.nfs}}, {{/etc/rc.net}}, {{/etc/rc.tcpip}}, {{/etc/profile}}, \\ {{/etc/inittab}}, {{/etc/environment}}, {{/etc/passwd}}, {{/etc/group}}, {{/etc/security/limits}}, {{/etc/security/login.cfg}}, \\ {{/etc/security/passwd}}, {{/etc/security/user}}, {{/etc/security/group}}, {{/etc/services}}, {{/etc/inetd.conf}}, \\ {{/etc/netsvc.conf}}, {{/etc/syslog.conf}}, {{/etc/motd}}, and {{/etc/filesystems}} before tailoring the base AIX installation. Most of these files can be updated in the process of tailoring AIX through the smit interface. A copy of these files will be saved by the [{{installbp}} shell script|AIXV53AdminBPFiles#installbp] if/when it is run to install files in the [tarball which can be downloaded|AIXV53AdminBPFiles#tarball].| |
| | |
| | {anchor:rootprofile} |
| | | Best Practice: | Configure the root user so you always know which system you are on and which directory you are in. | |
| | | Why: | If you are managing systems over a network, it is very important to know what system you are on. It is, therefore, important that root's shell prompt always remind you where you are. (The odd print command in {{/.profile}} will set the text in the title bar of an {{xterm}} or {{aixterm}} window to hostname:username when you log in through an {{xterm}} or {{aixterm}} window on another system.) | |
| | | How: | Assuming you configure the root user to run ksh at login, add files [{{/.profile}}|AIXV53AdminBPFiles#profile.root] and [{{/.kshrc}}|AIXV53AdminBPFiles#kshrc.root] (follow links to see file contents). Set ownership & permissions to root.system & rw-r-----. \\ |
| | \\ |
| | Note: After logging in to the root userid through CDE (GUI Desktop) on a graphics console for the first time, edit {{/.dtprofile}} to uncomment the last line ({{\# DTSOURCEPROFILE=true}}) so that {{/.profile}} will get executed every time root logs in. (*You did remember to save* {{*/.dtprofile{*}}} *as* {{*/.dtprofile.orig{*}}} *first, right?* \- See the _Before manually editing any file in the / and /usr filesystems for the first time, save a copy of the file_ best practice.) | |
| | |
| | {anchor:Bundles} |
| | | Best Practice: | After installing base AIX, install optional components by installing bundles rather than filesets. | |
| | | Why: | Easier to select one or a few bundles rather than selecting hundreds of filesets. | |
| | | How: | Use the smit _Install Software Bundle_ menu (accessed via the {{smitty install_bundle}} fast path) to install bundles from the AIX installation media. | |
| | |
| | {anchor:Morefilesets} |
| | | Best Practice: | Install a few individual filesets in addition to bundles. | |
| | | Why: | The filesets are not part of every bundle and provide the following valuable functions: |
| | * {{bos.dosutil}} (support for AIX dosdir, dosread, and doswrite commands to read and write DOS-format diskettes - only useful if System p server hardware includes a 3.5-inch diskette drive) |
| | * {{bos.adt.samples}} (the vmtune command and other performance tools, but please note that most vmtune command functions have been replaced by the vmo, ioo, and noo commands in AIX V5.3) |
| | * {{X11.apps.config}} (needed for SSH X11 forwarding to work) |
| | * {{bos.adt.base}} (required by Oracle according to the [??Oracle 10g Release 2 (10.2) Installation Guide for AIX 5L Based Systems (64-Bit)??|http://download.oracle.com/docs/cd/B19306_01/install.102/b19075/toc.htm]) |
| | * {{bos.adt.lib}} (required by Oracle according to the [??Oracle 10g Release 2 (10.2) Installation Guide for AIX 5L Based Systems (64-Bit)??|http://download.oracle.com/docs/cd/B19306_01/install.102/b19075/toc.htm]) |
| | * {{bos.adt.libm}} (required by Oracle according to the [??Oracle 10g Release 2 (10.2) Installation Guide for AIX 5L Based Systems (64-Bit)??|http://download.oracle.com/docs/cd/B19306_01/install.102/b19075/toc.htm]) |
| | * {{bos.perf.perfstat}} (required by Oracle according to the [??Oracle 10g Release 2 (10.2) Installation Guide for AIX 5L Based Systems (64-Bit)??|http://download.oracle.com/docs/cd/B19306_01/install.102/b19075/toc.htm]) |
| | * {{bos.perf.libperfstat}} (required by Oracle according to the [??Oracle 10g Release 2 (10.2) Installation Guide for AIX 5L Based Systems (64-Bit)??|http://download.oracle.com/docs/cd/B19306_01/install.102/b19075/toc.htm]) |
| | * {{bos.perf.proctools}} (required by Oracle according to the [??Oracle 10g Release 2 (10.2) Installation Guide for AIX 5L Based Systems (64-Bit)??|http://download.oracle.com/docs/cd/B19306_01/install.102/b19075/toc.htm]) |
| | * {{Java14.sdk}} (required by [AIX Security Expert|http://publib.boulder.ibm.com/infocenter/pseries/v5r3/topic/com.ibm.aix.security/doc/security/aix_sec_expert.htm] and other software) |
| | * {{sysmgt.websm.rte}} (required by [AIX Security Expert|http://publib.boulder.ibm.com/infocenter/pseries/v5r3/topic/com.ibm.aix.security/doc/security/aix_sec_expert.htm]) |
| | * {{sysmgt.websm.apps}} (required by [AIX Security Expert|http://publib.boulder.ibm.com/infocenter/pseries/v5r3/topic/com.ibm.aix.security/doc/security/aix_sec_expert.htm]) |
| | * {{sysmgt.websm.icons}} (required by [AIX Security Expert|http://publib.boulder.ibm.com/infocenter/pseries/v5r3/topic/com.ibm.aix.security/doc/security/aix_sec_expert.htm]) |
| | * {{sysmgt.websm.framework}} (required by [AIX Security Expert|http://publib.boulder.ibm.com/infocenter/pseries/v5r3/topic/com.ibm.aix.security/doc/security/aix_sec_expert.htm]) |
| | * {{sysmgtlib.framework.core}} (required by [AIX Security Expert|http://publib.boulder.ibm.com/infocenter/pseries/v5r3/topic/com.ibm.aix.security/doc/security/aix_sec_expert.htm]) |
| | * {{sysmgt.sguide.rte}} (required by [AIX Security Expert|http://publib.boulder.ibm.com/infocenter/pseries/v5r3/topic/com.ibm.aix.security/doc/security/aix_sec_expert.htm]) |
| | * {{X11.samples.apps.clients}} (delivers the {{twm}} command which is invoked by [VNC|http://www.realvnc.com/vnc/index.html]'s {{xstartup}}) |
| | * {{bos.games}} (the UNIX fortune command) | |
| | | How: | Use the smit _Install and Update from ALL Available Software_ menu (accessed via the {{smitty install_all}} fast path) to install additional filesets from the AIX installation media. | |
| | |
| | {anchor:ReinstallTL} |
| | | Best Practice: | After installing any new optional AIX filesets, always reinstall the current AIX Technology Level and Service Pack. | |
| | | Why: | It is important to keep all system components at a consistent fix level. When an AIX Technology Level or Service Pack is installed, updates are applied only to filesets installed on the system when Technology Level or Service Pack installation occurs. When new optional AIX filesets are installed, they are installed at the fix level available on the base AIX installation media, which is likely below the AIX Technology Level and Service Pack at which the system is currently running. | |
| | | How: | Use the smit _Update Installed Software to Latest Level (Update All)_ menu (accessed via the {{smitty update_all}} fast path) to reinstall AIX Technology Level media. \\ |
| | \\ |
| | *Caution:* Use {{smitty update_all}} only against AIX Technology Level media, not against other media received from the [IBM Support Center|http://techsupport.services.ibm.com/guides/pseries/before.shtml] which contains miscellaneous fixes, unless instructed to do so by the [Support Center|http://techsupport.services.ibm.com/guides/pseries/before.shtml]. | |
| | |
| | {anchor:mkuser.sys} |
| | | Best Practice: | Before creating any userids for which {{/bin/ksh}} is the default shell, update the {{/usr/lib/security/mkuser.sys}} file shipped with AIX to install a profile other than the system default when a new userid is created. | |
| | | Why: | The system default user profile ({{/etc/security/.profile}}) assigns an absolute $PATH, which defeats any attempt to introduce a new directory into all users' $PATHs by updating the PATH= statement in {{/etc/environment}}. | |
| | | How: | Replace [{{/usr/lib/security/mkuser.sys}}|AIXV53AdminBPFiles#mkuser.sys] (follow link to see new {{mkuser.sys}} content). (*You did remember to save* {{*/usr/lib/security/mkuser.sys{*}}} *as* {{*/usr/lib/security/mkuser.sys.orig{*}}} *first, right?* \- See the _Before manually editing any file in the / and /usr filesystems for the first time, save a copy of the file_ best practice.) Verify that [{{mkuser.sys.orig}}|AIXV53AdminBPFiles#mkuser.sys.orig] is as expected (follow link to see old {{mkuser.sys}} content). \\ |
| | \\ |
| | Add files [{{/etc/security/.profile.ksh}}|AIXV53AdminBPFiles#profile.ksh] and [{{/etc/security/.kshrc}}|AIXV53AdminBPFiles#kshrc] (follow links to see file contents). Make sure {{.profile.ksh}} & {{.kshrc}} have the same ownership & permissions as {{/etc/security/.profile}} (root.security & rw-rw----). \\ |
| | \\ |
| | If you wish to create a user with a default shell other than {{/bin/ksh}}, you should make appropriate changes to {{/usr/lib/security/mkuser.sys}} for other default shell(s) and add the other default profile(s) to {{/etc/security}}. \\ |
| | \\ |
| | *Note:* This is one of the few exceptions to the [_Don't store local files in / and /usr_|#Leaverootvg] best practice, which should be documented in {{/usr/local/README}} or equivalent, as suggested in the best practice. | |
| | |
| | {anchor:OpenSSH} |
| | | Best Practice: | Install OpenSSH. | |
| | | Why: | To avoid use of unsecure protocols such as FTP and telnet, which send unencrypted passwords (including root's password) over TCP/IP networks. See the [OpenSSH|http://www.openssh.org/] web page for details. | |
| | | How: | See [How to install, configure, and use SSH on AIX V5.3|AIXV53SSH]. | |
| | |
| | {anchor:MANPATH} |
| | | Best Practice: | Update $MANPATH for all users so that the [{{man}}|http://publib.boulder.ibm.com/infocenter/pseries/v5r3/topic/com.ibm.aix.cmds/doc/aixcmds3/man.htm] command can find man pages installed by applications (such as [_AIX Toolbox for Linux Applications_|http://www.ibm.com/systems/p/os/aix/linux/index.html] software). | |
| | | Why: | Useability. | |
| | | How: | Add the line {{MANPATH=/opt/freeware/man}} to {{/etc/environment}}. (*You did remember to save* {{*/etc/environment{*}}} *as* {{*/etc/environment.orig{*}}} *first, right?* \- See the _Before manually editing any file in the / and /usr filesystems for the first time, save a copy of the file_ best practice.) \\ |
| | \\ |
| | *Note:* It may be appropriate to add more directories to MANPATH. For example, if you install the _IBM XL C/C+\+ Compiler Man Pages--U.S. English_, you should add {{:/usr/vacpp/man/en_US}} to MANPATH. If you download and install Apache from the [AIX Toolbox for Linux Applications|http://www.ibm.com/servers/aix/products/aixos/linux/index.html] web site, you should add {{:/opt/freeware/apache/man}} to MANPATH. \\ |
| | \\ |
| | There is no need to add the {{/usr/share/man}} directory to {{MANPATH}}, since the [{{man}}|http://publib.boulder.ibm.com/infocenter/pseries/v5r3/topic/com.ibm.aix.cmds/doc/aixcmds3/man.htm] command searches {{/usr/share/man}} before searching the directories listed in {{$MANPATH}}. And directories such as {{/opt/csm/man}} are not needed in {{MANPATH}} since csm filesets (eg, {{csm.dsh}}) add soft links to the {{/usr/share/man}} directory tree pointing to the man pages in the {{/opt/csm/man}} directory tree. \\ |
| | \\ |
| | *Note:* [Bull freeware installation instructions|http://www.bullfreeware.com/install_down.html] suggest that an {{export MANPATH}} command must be added to {{/etc/profile}}, but this is not necessary because ksh exports MANPATH by default if it is set. To confirm that MANPATH is exported by default after adding MANPATH to {{/etc/environment}}, login, issue the command {{export}}, and observe that MANPATH is displayed (among many other environment variables). | |
| | |
| | {anchor:netsvc.conf} |
| | | Best Practice: | Configure TCP/IP to search local {{/etc/hosts}} to resolve a host name before trying DNS. | |
| | | Why: | If your network folks hose up DNS, you want to be able to circumvent the problem locally and minimize impact on your servers while they are fixing the problem. | |
| | | How: | There are two options for [name resolution tuning|http://publib.boulder.ibm.com/infocenter/pseries/v5r3/topic/com.ibm.aix.prftungd/doc/prftungd/name_resol_tuning.htm]: |
| | # Add a line containing {{hosts=local,bind}} to {{/etc/netsvc.conf}}. (*You did remember to save* {{*/etc/netsvc.conf{*}}} *as* {{*/etc/netsvc.conf.orig{*}}} *first, right?* \- See the _Before manually editing any file in the / and /usr filesystems for the first time, save a copy of the file_ best practice.) This update takes effect as soon as the change is made. |
| | # Add a line containing {{NSORDER=local,bind}} to {{/etc/environment}}. (*You did remember to save* {{*/etc/environment{*}}} *as* {{*/etc/environment.orig{*}}} *first, right?* \- See the _Before manually editing any file in the / and /usr filesystems for the first time, save a copy of the file_ best practice.) This update takes effect only as each daemon is stopped & restarted and as users logoff & log back in. The easiest way to restart all daemons is to reboot AIX. \\ |
| | \\ |
| | It is *not* necessary to add an {{export NSORDER}} command to /etc/profile for ksh users, since ksh exports NSORDER by default if it is set. | |
| | | | Note: Leave the loopback/localhost entry in {{/etc/hosts}} and add only an entry for your local hostname unless, of course, it becomes necessary to add entries to circumvent a DNS problem. \\ |
| | \\ |
| | Note: Before and after making this change, issue the command {{host <ipaddr>}} for every {{<ipaddr>}} defined in {{/etc/hosts}}. Update entries in {{/etc/hosts}} so that the {{host <ipaddr>}} command generates the same output with and without the new line in {{/etc/netsvc.conf}}. That is, make sure your /etc/hosts is consistent with DNS. | |
| | \\ |
| | {anchor:WLM} |
| | | Best Practice: | Configure AIX Workload Manager (WLM) to reserve CPU time for the root userid. | |
| | | Why: | So that if/when many application processes are consuming all available CPU, it will still be possible to log in to the server as root and take action quickly. And so that if/when many application processes are consuming most of the available CPU, DLPAR operations will complete promptly.| |
| | | How: | See [How to configure the AIX V5.3 Workload Manager to reserve CPU time for the root userid|AIXV53WLM]. Configuring AIX [system hang detection|http://publib.boulder.ibm.com/infocenter/pseries/v5r3/topic/com.ibm.aix.baseadmn/doc/baseadmndita/syshang.htm] is another option to permit quick intervention when all available CPU is consumed. | |
| | \\ |
| | {anchor:TTYTERM} |
| | | Best Practice: | When configuring an ASCII console/terminal, configure AIX to set the TERM= shell environment variable correctly during login from that terminal. | |
| | | Why: | Ease of use. | |
| | | How: | When defining an ASCII console/terminal, always set the tty's {{TERMINAL type}} field (on the _Change / Show Characteristics of a TTY_ menu accessed via the {{smitty chgtty}} fast path) to the appropriate terminal type. For example, if the terminal is a VT100, set the {{TERMINAL type}} field to {{vt100}. When defining a serial port for a modem, leave the {{TERMINAL type}} field set to {{dumb}}. Discourage users from setting {{TERM=}} in their {{.profile}} except as a conditional statement (eg, {{if \[ "$TERM" = "dumb" \] ; then TERM=vt100 ; fi}}) | |
| | |
| | {anchor:ptree} |
| | | Best Practice: | Add useful shell scripts to {{/usr/local/bin}} and make them available to all users. | |
| | | Why: | Ease of use. | |
| | | How: | As described in the [_Don't store local files in / and /usr_|#Leaverootvg] best practice above, create a {{/usr/local}} filesystem. Create a {{/usr/local/bin}} directory in the filesystem. Add files [{{/usr/local/bin/ptree}}|AIXV53AdminBPFiles#ptree] and [{{/usr/local/bin/stopcmd}}|AIXV53AdminBPFiles#stopcmd] (follow links to see file contents) with ownership & permissions of bin.bin & r-xr-xr-x. \\ |
| | \\ |
| | Add {{/usr/local/bin}} near the end of PATH= in {{/etc/environment}}. (*You did remember to save* {{*/etc/environment{*}}} *as* {{*/etc/environment.orig{*}}} *first, right?* \- See the [_Before manually editing any file in the / and /usr filesystems for the first time, save a copy of the file_|#Savecopy] best practice.) If you implemented the [_Update the /usr/lib/security/mkuser.sys file shipped with AIX to install a profile other than the system default when a new userid is created_|#mkuser.sys] best practice, the $PATH set in {{/etc/environment}} will be inherited by all users. \\ |
| | {anchor:PATH} |
| | *Note:* Updating PATH= in {{/etc/environment}} is completely effective only if [the {{/usr/lib/security/mkuser.sys}} file was updated before any userids were created with {{/bin/ksh}} as the default shell|#mkuser.sys] and if [root's profile has been changed|#rootprofile] so that it does not set an absolute $PATH. \\ |
| | \\ |
| | *Note:* Because these files are added to the {{/usr/local}} filesystem in rootvg, this is *not* an exception to the [_Don't store local files in / and /usr_|#Leaverootvg] best practice. | |
| | |
| | {anchor:lsof} |
| | | Best Practice: | Install [{{lsof}}|http://en.wikipedia.org/wiki/Lsof] (LiSt Open Files) utility. | |
| | | Why: | Useful in diagnosing a variety of functional and performance problems. For example, when a filesystem can not be unmounted because files in it are open, lsof can be used to identify the files which are open and the processes which are holding them open. | |
| | | How: | See [How to install the lsof (LiSt Open Files) utility on AIX V5.3|AIXV53lsof]. | |
| | |
| | {anchor:browser} |
| | | Best Practice: | Install a web browser. | |
| | | Why: | A web browser is an important end-user and sysadmin tool. | |
| | | How: | Install the Mozilla browser from the _Mozilla V1.7.3 Web Browser and Application Suite for AIX CD_ (or download the latest Mozilla or Firefox browser from the [_Web browsers for AIX_ download site|http://www.ibm.com/servers/aix/browsers/]). \\ |
| | \\ |
| | See the [??Installing Mozilla on AIX??|http://www.ibm.com/support/docview.wss?uid=isg3T1000683] Technote for Mozilla installation instructions. \\ |
| | \\ |
| | Please note that root's mozilla cache is placed in {{/.mozilla}} by default. To preserve space in / and to avoid filling it up, after installing Mozilla consider creating a {{/home/root/.mozilla}} directory, creating a symbolic link to it from {{/.mozilla}}, and confirming that root's mozilla will run okay with the soft-linked directory. \\ |
| | \\ |
| | Use the {{smitty change_documentation_services}} to specify Mozilla as the system default browser once Mozilla is installed. \\ |
| | \\ |
| | If no X-desktop is available (that is, no UNIX or Linux workstations with graphics displays are available and Hummingbird Exceed or the equivalent is not available), then consider [installing VNC|AIXV53VNC] to provide the X-desktop which Mozilla requires.| |
| | |
| | {anchor:Acrobat} |
| | | Best Practice: | Install the Adobe Acrobat reader. | |
| | | Why: | A .PDF reader is an important end-user and sysadmin tool. | |
| | | How: | Download the _Adobe Acrobat Reader V7.0.8 for IBM AIX_ from the [_Adobe Reader_ download site|http://www.adobe.com/products/acrobat/readstep2_allversions.html]. \\ |
| | \\ |
| | To install Acrobat, run INSTALL in the AdobeReader directory after unpacking the downloaded archive. \\ |
| | \\ |
| | See the [_Don't store local files in / and /usr_|#Leaverootvg] best practice above, which suggests creating a {{/usr/local}} filesystem and installing software such as Adobe Acrobat in that filesystem (in, for example, directory {{/usr/local/Acrobat7}}). Add a symbolic link from {{/usr/local/bin/acroread}} to the Adobe {{acroread}} executable. (If you implemented the _Add useful shell scripts to /usr/local/bin and make them available to all users_ best practice, the {{/usr/local/bin}} directory will already exist and all users will have {{/usr/local/bin}} in their $PATHs.) \\ |
| | \\ |
| | If no X-desktop is available (that is, no UNIX or Linux workstations with graphics displays are available and Hummingbird Exceed or the equivalent is not available), then consider [installing VNC|AIXV53VNC] to provide the X-desktop which Acrobat requires. | |
| | |
| | {anchor:crcdrfs} |
| | | Best Practice: | Use {{smitty crcdrfs}} to create a CD-ROM filesystem with a mount point of {{/cdrom}}. | |
| | | Why: | Sooner or later, you will want to mount a CD. Once you have created the {{/cdrom}} filesystem, a CD can be mounted by root user with {{mount /cdrom}}. Why wait until you need to mount a CD to figure out how to create the filesystem? \\ |
| | \\ |
| | But please note that the {{installp}} command (and the smit install menus which use it) assume that a CD is not mounted. Mounting a CD before attempting to install something from it can result in cryptic (that is, difficult to diagnose) behavior from the {{installp}} command at some AIX patch levels. | |
| | | How: | Use the {{smitty crcdrfs}} fast path. | |
