AIX patching

• Maintenance Level : A Maintenance Level (ML) is a concept replaced by Techology levels
• Technology Level : A Technology Level (TL) is the new term for the twice yearly AIX 5L releases, which contain new hardware and software features and service updates. The first TL will be restricted to hardware features and enablement, as well as software service. The second TL will include hardware features and enablement, software service, and new software features.

  Installing a TL is an "all or nothing" operation, meaning that requisites will be added so that the whole TL is installed, and not allow a TL to be partially installed. You should back up your system prior to installing a TL.

  • For example as of Oct. 2009 the latest technology level for AIX is level 11 IBM Support Fix Central
     
• Service Pack : A Service Pack (SP) consists of service-only updates (also known as PTF's) that are released for each Technology Levels and are grouped together for easier identification. Service packs numbering is different for each Technology level.  For example for TL 8 the latest service pack is 7 but for TL 11 the lastest service pack is 1. Service packs can include any of the following:
  • Customer-reported problems that can't wait until the next TL.
  • Critical problems reported by development teams.
  • Limited changes to support new hardware, such as device drivers' kernels changes to reflect a new processor. These are changes that do not add new functionality. New functionality will only be added for TLs or new releases. SP release schedules are approximately every four to six weeks.

  So, what happens between service packs? Interim fixes, sometimes referred to as fix packs or temporary fixes, or stand-alone PTFs, are made available for relief until the time that the fix becomes available in a service pack. It's what IBM calls "temporary relief." They are tracked on the system with either the lslpp -L  command or emgr -l  command.

  Security updates, published through advisories, are made available by IBM through subscription services.

  Another important concept to understand is the Concluding Service Pack (CSP). The CSP is the final service pack for a TL. It usually contains fixes for critical problems or security issues. The new strategy also includes a longer period of support for each OS TL. Each TL will now be supported for up to a two-year period. This means that you can continue to call IBM support for up to a two-year period (from the introduction to the update) without having to move up to the latest TL. The new server update strategy also promises improved serviceability throughout the life of TL. This is done by allowing you to maintain your operating system by installing service packs and PTFs throughout the entire lifecycle of the TL.

Patch level and/or patches

instfix -ivq
oslevel -rn

Use the lslpp -L command to verify that the patch has been applied.

Automating TLs and service pack deployments with SUMA

The IBM Service Update Management Assistance (SUMA) allows you to automate the retrieval of TL and service pack deployments. In this section, you're going to use SUMA to retrieve TLs. SUMA was first released with AIX V5.3. More than anything, SUMA helps the system administrator automate the retrieval of AIX updates, allowing the administrator to get away from the mundane tasks of manually retrieving updates from the Web. Furthermore, it allows you to configure policies to automatically download either entire TL upgrades, service packs, or even interim fixes. The primary objective of the utility is to allow systems administrators to spend more time on proactive systems administration and less time on redundant or tedious work such as downloading updates.

So, how do SUMAs work? Essentially, they use a scheduling module that allows policies to be run at predefined intervals, which conform to your maintenance window. The policies can be configured easily without any extensive configuration. You even have the option to manually run SUMA (either from smit or the command line) to bring in whatever updates you require. To configure SUMA, you need to know the fix type. There are eight different kinds of fix types. They include APAR, PTF, Critical, Security, I/O Server, Latest (all fixes), Filesets (specific types), and Maintenance Levels. In addition, there are three types of actions you can perform on a policy. These include preview, download, and download and clean. Preview mode does not really do anything; it just generates a preview of what would be downloaded. The "download only" action downloads the actual data, while the "download and clean" action removes filesets no longer necessary after a new fix level has been brought down. This limits the size of the data that you'll need to keep.

You can run the suma command from either smit or the command line. In the first example, use smit to download an entire TL: # smit suma.

When the smit screen comes up, choose Download Updates Now (easy) and click Enter.

From this screen, scroll down to Download Maintenance Level or Technology Level and click Enter (see Figure 2).

At the window in Figure 3, click F4 and choose the appropriate TL level.

In this case, it is 6100-01, as shown in Figure 4.

This provides you with the following summary:

• 59 downloaded
• 0 failed
• 36 skipped

Now try it from the command line. In this case, you're going to download TL Two for AIX V6.1. Do this by running the suma -x  command

After about 30 minutes, it completes successfully

The files get installed in /usr/sys/inst.images, which is where you would also manually put them if you were to retrieve them using different processes.

Why is SUMA important? Perhaps most importantly, it helps to ensure that your systems have the latest patches that it needs. Current fixes are important. Secondly, it downloads the patches without intervention, which allows the systems administrator to focus on more important tasks.

Fix Central

This section reviews Fix Central and discusses how to use it to download TL and service pack deployments. Fix Central is the central repository for all TLs and service packs for AIX. Among other things, you'll see how to log into Fix Central and retrieve service packs. Completely revamped in October of 2007, it provides fixes and updates for all your software, hardware, and operating systems. This includes the Hardware Management Console (HMC). Using Fix Central, you can download using the following options: by APAR, Fix ID, or Test. In addition, there are three download options, IBM Download Director, HTTP, and FTP.

Download a service pack from the exact TL that you downloaded previously during the work with suma from the command line -- 6100-02. First go to Fix Central for System p�, as shown in Figure 8 (see Resources for a link to Fix Central).

From here, in the drop-down menu, choose your version. Another drop-down menu pops up, which is where you can select from one of the following: fix packs, fix recommendations, fix search, managing updates, and security advisories. Choose fix pack. Click Continue (see Figure 9).

From here, select the TL: 6100-02. At this time, you can either download the latest service pack or the entire TL. Choose the entire TL (see Figure 10).

The options for download include Download Director, bulk FTP, or CD. In this case, use Download Director. I recommend this method because it has a friendly interface and there is also flexibility to pause downloads.

The length of time is dependent on your Internet connection. For me, on broadband, this took roughly an hour.

As a systems administrator, the Fix Central URL should definitely be one of your browser favorites. Fix Central helps you keep your systems up to date and is the best method of manually retrieving data for your upgrades. You really can't be an effective AIX systems administrator without knowing how to use this tool.

Upgrading a TL

Now review the procedures to upgrade your system to the next TL.

First log in as root: # su - root. Make sure you back up your system. If you prefer, you can also use alt_disk_install or multibios; the bottom line is that you need to have a plan B if you must go back to your prior level. You should also commit them, because they can't be rejected and they also make it easier to track and reject PTFs.

Do a backup using the following command: # mksysb. When the backup is completed, you're set!

Installation

Create a .toc file. This is done by running the inutoc command (see Figure 12). You run this in the directory where your filesets reside. If you don't have the .toc file, your update will not work.

When this is completed, you are ready to start the upgrade. Move to the directory where your .toc file resides. If you do this, you will not have to specify a path name during your upgrade: # smit update_all.

On the screen in Figure 13, you will be making several changes.

For Input device/directory for software, put in the dot (.). If you remembered to cd to the directory that has the .toc file, you don't need to specify the full path name. In this case, you did not commit the software, though as a practical matter because you can't back out of a TL upgrade, you really should say yes to limit the amount of filesets stored on your system -- a real disk hog. In this case, you first previewed the data to ensure that there would not be any problems. This is the third option on this smit menu (shown in Figure 13). The preview option does nothing except validate whether something might be missing as a prerequisite of the upgrade. This is good to do to avoid surprises. You don't want to find out something is missing during your two-hour maintenance window of the month. You can run a preview at any time without any impact to the system.

In our case, as you can see in Figure 14, the preview is successful and there are no failures. So you are ready to move on.

When you are ready to run the upgrade, change the preview to no. You will also have to change the default field that relates to << Accept new license agreement >>. For some reason, AIX defaults to no. Change it to yes.

After you click Enter, it will prompt you to make sure you want to do this. Click Enter to continue to start the process (see Figure 15).

This can run for up to an hour, depending on the speed of your system and the type of upgrade you are performing. When the process is complete, you can scroll down to the summary section to see if you've been successful, which in this case is yes. (see Figure 16).

Your final step is to reboot the box. Make sure you perform this step before bringing your applications back and going live. After I rebooted the box, I ran the oslevel command to confirm the new system level (see Listing 1).

 
lpar46ml16fd_pub > # oslevel -s
6100-02-01-0847

What does this information signify? It tells that you are running AIX V6 TL2, service pack 1, released in 2008 in the 47th week. The forth field, 0847, indicates the year and week. Finally, it is highly recommended that you apply the latest service pack when moving to the new TL. In our case we did not have to, because the latest pack was already a part of the TL upgrade.

Back to top

TL upgrade deployment schedule

When should you actually perform a TL upgrade? There are generally three scenarios where you will make this choice:

• When your TL is going out of the available support period.
• You want to test a new distribution level that will be going into production and need to get the longest period of fix support.
• You want to use the new features and functionality of the TL.

The short answer is that there really is no right or wrong time to perform an upgrade. Some clients need an environment that requires maximum uptime and stability. These clients typically wait until new TLs are out for at least six months to a year before applying them. Other folks will wait for several TL's to be put into place prior to upgrading to ensure maximum reliability. For clients that like to take advantage of new features and ensure that they have the latest security patches, they typically install new service packs shortly after they come out. From a vendor-support perspective, IBM would prefer if you upgraded your TLs (and service packs, for that matter) as soon as they come out. The reason is that it's just easier to support systems that are always at current levels. I like to upgrade at least once a year to a new TL. In doing so, I will also usually wait until at least service pack number two has been released. If you really want to err on the side of caution, wait until service pack number three. That way, you will know that your release is really rock solid.

IBM - How to check or upgrade AIX firmware level

• You can refer to the following topic in the IBM Systems Hardware Information Center:
  Viewing existing firmware levels

  To find out the current firmware level, use one of the following two options. Any user can issue these commands. Upgrading the firmware is a task normally done by the AIX administrator.
   

• Use the lscfg command

  lscfg -vp | grep -p "ROM"

• Use the lsmcode command. Note that not all AIX versions support this command.

  # lsmcode -A

  sys0!system:SF240_284 (t) SF240_202 (p) SF240_284 (t)
  fcs0!df1000fa.190313
  sisscsia0!44415255.050A008a
  ent0!14106902.GOL021
  ent1!14108902.DV0210
  ent2!14108902.DV0210
  fcs1!df1000fa.190313
  cd0!IBM-RMBO00205L.1.18
  rmt0!B008
  hdisk3!ST37320.4A523030.43373043
  hdisk4!ST37320.4A523030.43373043
  		

  DISPLAY MICROCODE LEVEL                                                   802811
  IBM,9133-55A
  
  The current permanent system firmware image is SF240_202
  The current temporary system firmware image is SF240_284
  The system is currently booted from the temporary firmware image.
  
  Use Enter to continue.
  		

NEWS CONTENTS

• 200102 : IBM - Service and support strategy best practices for Power systems ( IBM - Service and support strategy best practices for Power systems, )
• 200102 : patches AIX vs Solaris installation method - Unix Linux Forum - Fixunix.com ( patches AIX vs Solaris installation method - Unix Linux Forum - Fixunix.com, )
• 200102 : IBM Support Fix Central ( IBM Support Fix Central, )
• 200102 : July, 2009 ( )
• 200102 : AIX Maintenance Strategies ( AIX Maintenance Strategies, )
• 200102 : http://www-912.ibm.com/eserver/support/fixes/techTips.html ( http://www-912.ibm.com/eserver/support/fixes/techTips.html, )
• 200102 : IBM Support Fix Central ( IBM Support Fix Central, )
• 200102 : Service life of AIX 5.3 Technology Levels ( )

Old News ;-)

IBM - Service and support strategy best practices for Power systems

• June 2009 IBM AIX Operating System Service Strategy Details and Best Practices (139KB)
• November 2007 Fix Central changes supporting AIX Service Strategy (509KB)
• May 2007 IBM AIX 5L Operating System: Release and Service Strategy Changes for 2007 (88KB)

patches AIX vs Solaris installation method - Unix Linux Forum - Fixunix.com

MJB wrote:

> Hi all,

> I'm looking for some help/advice on patching AIX. We are in the
> process of moving from Sun/Solaris to IBM/AIX. We have a few p5
> servers running 5.3 and I want to make sure the OS stays up to date.
> On Solaris you could just download the latest recommended patch cluster
> from Sunsolve, unzip it and install it.

> How does it work with AIX? I've been to:

> http://www-912.ibm.com/eserver/support/fixes/fcgui.jsp

Hi,

You might want to start at

http://www14.software.ibm.com/webapp.../aixfixes.html .

Maintenance Levels (MLs) were renamed to Technology Levels (TLs). Service Packs (SPs) are fixes on a specific TL. You can download these from the website, order them on CD or use the SUMA tool in AIX.

IBM has a best practices guide for software maintenance

IBM - Service and support strategy best practices for Power systems

Look into SUMA. I don't know how many machines you have to maintain or how you do your provisioning or what not. But we use SUMA on our 520s and it's great. Every night it downloads the latest patches. We have
a set schedule. We install new patches in the applied state, test them, and just run them as applied until testing is complete and it is time to apply a new round of patches. Then we commit all and apply the
new ones. That's an important step.

So give smitty suma a look and see if it helps you out. You will have to do a little work to configure it, but nothing terribly sophisticated. The only information you should need with respect to maintenance levels etc. is your output from oslevel -r.

You may need to use the -c option to suma to add a HTTP_PROXY if you use one. man suma gives good details on this.

IBM Support Fix Central 5300-06 Service Pack 12 for AIX 5.3 operating system

July, 2009

ServiceReport This file is used by the AIX command compare_report to create reports listing filesets on the system that are at a lower level than the latest levels, and those that are at a lower level than the last technology level.

New Security APARs Security updates are initially released as interim fixes to expedite availability. The updates are later repackaged in the same format as generally available AIX updates.

IZ48496	Potential security issue.
IZ50500	Potential security issue.
IZ50503	Potential security issue.

New High Impact for Highly Pervasive APARs

IBM classifies some APARS as HIPER. Installation of packages containing these APARs is highly recommended.

New APARs resolving PEs APARs in the list below are included in this package and resolve problems marked as PE in previous service packs. IZ52944 "GETGRENT_R" ROUTINE CAUSES HEAP CORRUPTION .

All Other New APARs

IZ39466	UNABLE TO ADD FILTER RULES WITH PROTOCOL TCP/RESET OR TCP/URGENT
IZ43820	MEMORY LEAK IN SECURITY KERBEROS LOADMODULE
IZ50493	RANLIB DOES NOT HANDLE INPUT FILENAMES WITH SPACES
IZ50494	UNABLE TO USE MAPS TO RESTORE MKSYSB TO SAS DISKS
IZ50495	SEDMGR -D COMMAND FAILS FOR LARGE FILES.
IZ50497	SIOCGIFNETMASK RETURNS INCORRECT SUBNET MASK FOR ALIAS IP
IZ50498	DMPUNCOMPRESS FAILED TO UNPACK A LARGE DUMP
IZ50499	PASSWDEXPIRED ROUTINE FOR LDAP USER RETURNS ERROR
IZ50502	SYSTEM CRASH IN DESTROY_EXPIRED_LOCKS() WHEN USING NFSV4
IZ50509	LINK DOES NOT COME UP BETWEEN 10 GB ETHERNET DRIVER AND SWITCH
IZ50510	chdev -a pv=clear causes RDAC disks to become Defined
IZ50511	Cannot read SAS address of SAS DC using AIX command
IZ50512	uelpent CORE dump - Initialization stages
IZ50513	SYSTEM HANG DUE TO QLOGIC ADAPTER DRIVER DEADLOCK
IZ50594	STOPPING NFS SERVICES FAILS TO REMOVE NFSV4 REGISTRATION
IZ50601	Loss of path if target controller goes offline
IZ50604	Hang in mkuser command
IZ51076	Fixdata for new service pack

AIX Maintenance Strategies

Between regular technology levels, IBM will release service packs, PTFs that are grouped together for easier identification. These fixes will be for highly pervasive, critical, or security related issues and will be released ever 4-6 weeks between technology levels.

Applying the latest level of available updates will move the system to the latest service pack. To see which service pack is currently installed, we have a new command switch: "oslevel -s" . The output for a server/LPAR with AIX 5.3, technology level 4, service pack 2 installed would be:

# oslevel -s
5300-04-02

Like maintenance levels, service packs are cumulative, so if service pack 4 is installed, all of the previous critical fixes from service packs 1 through 3 will also be installed.

As you might have guessed, this also means the end of "critical fix packs".

Something completely new is the concluding service pack, which will identify the last service pack on a technology level The CSP will contain fixes for highly pervasive, critical, or security related issues, just like an SP, but it may also contain fixes from the newly released technology level that are highly pervasive, critical, or security related.

The CSP will be available shortly after a new technology level is released. As an example, if technology level 5300-04 is released, the CSP for 5300-03, will be available 4-6 weeks later.

It will have a specific level identifier of "CSP", so the "oslevel -s" command output would be:

# oslevel -s
5300-03-CSP

http://www-912.ibm.com/eserver/support/fixes/techTips.html -- patch report in version 5.3I

IBM Support Fix Central Fix packs for AIX 5.3 operating system

AIX updates are provided as Technology Level packages or Service Packs. These generally available updates have been tested to operate best when all updates in a fix pack are installed. IBM recommends installing the complete fix pack. A fix pack is a combination of many single fixes for product components that are dependent on or related on each other. It can include new features, functions, or enhancements.

Service life of AIX 5.3 Technology Levels

Beginning with AIX 5300-06, Technology Levels are supported for approximately two years. End Of Service dates are estimates only. A two year life for a TL is an objective only. All statements regarding

Recommended Links

• Visit IBM's Fix Central, central repository for all technology levels and service packs for AIX.
• Read the IBM AIX 6.1 Differences Guide to learn about the differences introduced in IBM AIX Version 6.1 when compared to AIX 5L Version 5.3.
• The AIX V6 Advanced Security Features Redbook highlights and explains the security features at the conceptual level, as well as provide practical examples of how they may be implemented.
• See the Command Reference for aixpert.
• Read the IBM Systems Information Center entry on AIX Security Expert.
• New to AIX and UNIX?: Visit the "New to AIX and UNIX" page to learn more about AIX and UNIX.
• AIX Wiki: A collaborative environment for technical information related to AIX.
• Optimizing AIX 5L performance: Tuning network performance, Part 1 (Ken Milberg, developerWorks, November 2007): Read Part 1 of a three-part series on AIX networking, which focuses on the challenges of optimizing network performance.
• For a three-part series on memory tuning on AIX, see Optimizing AIX 5L performance: Tuning your memory settings, Part 1 (Ken Milberg, developerWorks, June 2007).
• Read the IBM whitepaper Improving Database Performance with AIX concurrent I/O.
• Learn about AIX memory affinity support from the IBM System p and AIX InfoCenter.
• The Redbook, Database Performance Tuning on AIX, is designed to help system designers, system administrators, and database administrators design, size, implement, maintain, monitor, and tune a Relational Database Management System (RDMBS) for optimal performance on AIX.
• Learn about IBM's Power Architecture: High-Performance Architecture with a History.
• Read Power to the People; A history of chip making at IBM (developerWorks, December 2005) for coverage of IBM's power architecture.
• CPU Monitoring and Tuning (Wayne Huang et al. developerWorks, March, 2002): Read this article to learn how standard AIX tools can help you determine CPU bottlenecks.
• For a comprehensive guide about the performance monitoring and tuning tools that are provided with AIX 5L Version 5.3, see the IBM Redbook AIX 5L Practical Performance Tools and Tuning Guide.
• Learn what features you can benefit from in AIX 5L Version 5.3, in AIX 5L Version 5.3: What's in it for you? (developerWorks, June 2005).
• Operating System and Device Management from IBM provides users and system administrators with complete information that can affect your selection of options when performing such tasks as backing up and restoring the system, managing physical and logical storage, and sizing appropriate paging space.
• The AIX 5L Differences Guide Version 5.3 Edition (developerWorks, December 2004) redbook focuses on the differences introduced in AIX 5L Version 5.3 when compared to AIX 5L Version 5.2.
• The AIX and UNIX developerWorks zone provides a wealth of information relating to all aspects of AIX systems administration.
• Open source: Visit the developerWorks Open source zone for extensive how-to information, tools, and project updates to help you develop with open source technologies, and use them with IBM products.
• developerWorks technical events and webcasts: Stay current with developerWorks technical events and webcasts.
• Podcasts: Tune in and catch up with IBM technical experts.

Reference

U.S. DOE-CIAC Bulletins IBM Corp.� -- list of DOE patches

patch level and/or patches

instfix -ivq
oslevel -r

Use the lslpp -L command to verify that this patch has been applied.

emgr Command

Purpose

Starts the interim fix (interim fix) manager, which installs, removes, lists, and checks system interim fixes.

Syntax

To list interim fix; data:

emgr -l [ -L Label | -n interim fixNumber | -u VUID ] [-v{1|2|3} ] [ -X ]

To install an interim fix package:

emgr -e interim fixPackage | -f ListFile [-w Directory ] [ -b ] [ -k ] [ -p ] [ -I ] [ -q ] [ -m ] [ -X ]

To remove an installed interim fix:

emgr -r -L Label | -n interim fixNumber | -u VUID | -f ListFile [-w Directory ] [-b ] [ -k ] [ -p ] [ -I ] [ -q ] [ -X ]

To check an installed interim fix:

emgr -c [ -L Label | -n interim fixNumber | -u VUID | -f ListFile ] [ -w Directory ] [-v{1|2|3} ] [ -X ]

To mount or unmount an installed interim fix:

emgr -M | -U [ -L Label | -n interim fixNumber | -u VUID | -f ListFile ] [ -w Directory ] [ -X ]

To force removal of an installed interim fix:

emgr -R interim fixLabel [ -w Directory ] [ -X ]

To view packages locked by interim fix manager:

emgr -P [ Package ] [ -X ]

Description

The emgr (interim fix manager) command can be used to install and manage system interim fixes. The interim fix manager installs packages created with the epkg command and maintains a database containing interim fix information. The emgr command performs the following operations:

• interim fix package installation
• interim fix removal
• interim fix listing
• interim fix checking
• interim fix mounting
• interim fix unmounting
• Display package locks
• Force removal of an installed interim fix

Referencing an Efix

The ways to reference an interim fix are as follows:

Reference by Label

Each interim fix that is installed on a given system will have a unique interim fix label. This is the unique key that binds all of the different database objects. To reference an interim fix by label, pass the label as a parameter to the -L flag. For example, to run a check operation on an interim fix with label ABC123, type:

emgr -cL ABC123

Reference by Efix ID

Each interim fix that is installed on a given system has an interim fix ID. The interim fix ID is simply the order number in which the interim fix is listed in the interim fix database. Using this option may be convenient if you are performing operations on interim fixes based on interim fix listings. The emgr command will convert the interim fix ID into an interim fix label before performing the given operation. To reference an interim fix by ID, pass the ID as an parameter to the -n flag.

Note:

Efix IDs can change as interim fixes are removed and added. Always verify the current interim fix ID number by using the -l flag to list the specific interim fix or all interim fixes.

For example, to run a check operation on the first interim fix with ID equal to 1, type:

emgr -cn1

Reference by VUID

Because interim fix packages are not formally tracked by any entity, it is possible that the same interim fix label could be used for more than one interim fix package. However, the emgr command does not accept the installation of more than one interim fix with the same interim fix label at the same time. The VUID (Virtually Unique ID) can be used to differentiate packages with the same interim fix label. The emgr command converts the VUID into an interim fix label before performing the given operation. For example, to list an installed interim fix with VUID equal to 000775364C00020316020703, type:

emgr -l -u 000775364C00020316020703

Note:

The VUID is displayed in the preview phase of interim fix installation and removal. The VUID is also displayed when listing with verbosity level set to 2 or higher with the -v flag.

Efix Logging

The following operations are logged to the emgr command log file, /var/adm/ras/emgr.log:

• Installation
• Removal
• Checking
• Mounting
• Unmounting
• Forced Removal

Flags

-b	Causes the emgr command to skip the usual AIX bosboot process for interim fixes that require rebooting.
-c	Specifies the check operation. Instructs the emgr command to run a check operation on the specified interim fix or interim fixes.
-e interim fixPackage	Specifies the path of the interim fix package file. The interim fix package file must be created with the epkg command and must end with the 16-bit compression extension, .Z.
-f ListFile	Specifies a file that contains one of the following: A list of package locations for the installation operation (one per line) A list of interim fix labels for the remove, mount, unmount, and check operations (one per line) The emgr command ignores any blank lines or lines where the first non-white-space character is the # character.
-I	Runs the low-level debugger for AIX bosboot by using the bosboot command's -I flag.
-k	Loads the low-level debugger during AIX bosboot using the bosboot command's -D flag.
-l	Instructs the emgr command to run the list operation on the specified interim fix or interim fixes.
-L Label	Selects the interim fix for this operation by interim fix label.
-m	Instructs the emgr command to perform a mount installation. When and interim fix is mount-installed, the interim fix files are mounted over the target files.
-M	Instructs the emgr command to mount an interim fix or interim fixes that have been mount-installed by using the -m flag. The -M flag can be used to mount an interim fix that was installed using the -m flag and has been unmounted by the -U flag or by some other means, such as rebooting the system.
-n interim fixID	Selects the interim fix for this operation by specifying the interim fix ID.
-p	Instructs the emgr command to perform a preview for either installation or removal. The preview runs all of the check operations, but does not make any changes.
-P [ Package ]	Specifies the package-view operation, which displays all packages that are locked by the interim fix manager, their installer, and the locking label or labels.
-q	Suppresses all output other than errors and strong warnings.
-r	Instructs the emgr command to run a remove operation on the specified interim fix or interim fixes.
-R Label	Instructs the emgr command to run a force-remove operation. This option removes interim fix data and package locks associated with the interim fix label without actually removing interim fix files, running any remove scripts, or boot processing. This option can be used for only one interim fix at a time. The interim fix label is required to identify the target interim fix. Attention: This method of interim fix removal should be considered an emergency procedure. Because this method can create inconsistencies on the target system, the force remove method should be used only if all other methods of removing the interim fix are unsuccessful.
-u VUID	Selects the interim fix for this operation by specifying the VUID.
-U	Instructs the emgr command to unmount an interim fix or interim fixes that have been mount-installed by using the -m flag.
-v{1|2|3}	Specifies the verbosity level for the listing operation or the verification level for the check operation. Valid levels are 1, 2, and 3.
-w Directory	Instructs the emgr command to use the specified working directory instead of the default /tmp directory.
-X	Attempts to expand any file systems where there is insufficient space to perform the requested emgr operation. This option expands file systems based on available space and size estimates that are provided by the interim fix package and the emgr command. Notes: It is possible to exhaust available disk space during an installation even if the -X flag is used. This is more likely if other files are being created or expanded in the same file systems during an installation. Remote file systems cannot be expanded by the emgr command.

Exit Status

0

All of the emgr command operations completed successfully.

>0

An error occurred.

Security

Only the root user can run the emgr command. Efix data, saved files, and temporary files are accessible only by the root user.

The emgr command looks for a supported MD5 generating command on the system. If one is located, the emgr command displays the MD5 checksum to the user. The user can then cross check this MD5 sum with a secured source. If an MD5 generating command is not located, the emgr command takes no further action.

The user can force set the path to an MD5 command by exporting the EMGR_MD5_CMD shell variable. This variable should contain the absolute path to the MD5 generating command.

Note:

This feature is not supported in the original release of interim fix management. It is recommended that the user updates to the latest level of interim fix management by updating bos.rte.install to the latest level.

Examples

1. To preview the installation of an interim fix package called games.020303.epkg.Z, type:

   emgr -p -e games.020303.epkg.Z

2. To install the interim fix package called games.020303.epkg.Z and automatically expand file systems if additional space is needed, type:

   emgr -X -e games.020303.epkg.Z

3. To list all interim fixes on the system, type:

   emgr -l

4. To do a level 3 listing of interim fix label games, type:

   emgr -lv3 -L games

5. To remove the interim fix with label games, type:

   emgr -r -L games

6. To preview the removal of the interim fix labels in file /tmp/myfixes, type:

   emgr -rp -f /tmp/myfixes

7. To check all interim fixes with verification level 2, type:

   emgr -cv2

8. To check interim fix ID number 3 with verification level 1 (the default verification level), type:

   emgr -c -n3

9. To check interim fix with VUID of 000775364C00020316020703 and verification level 3, type:

   emgr -u 000775364C00020316020703 -c -v3

10. To list all locked packages and their interim fix labels, type:

    emgr -P

11. To list all interim fix labels that have locked the installp package bos.rte.lvm, type:

    emgr -P bos.rte.lvm

12. To mount-install the interim fix package called games.020303.epkg.Z and suppress AIX bosboot, type:

    emgr -e games.020303.epkg.Z -mb

13. To mount all interim fix files that have been mount-installed on the system by using the -m option, type:

    emgr -M

14. To unmount all interim fix files associated with interim fix label games, type:

    emgr -U -L games

Files

/usr/sbin/emgr	Contains the emgr command
/usr/emgrdata/DBS/efix.db	Contains the interim fix header database
/usr/emgrdata/DBS/files.db	Contains the interim fix files database
/usr/emgrdata/DBS/pkglck.db	Contains the package locks database
/usr/emgrdata/DBS/prereq.db	Contains the prerequisite database

Related Information

The bosboot command, epkg command.

Interim fix Management in AIX 5L Version 5.3 Installation Guide and Reference.

WSG Resources Unix Security Superglue

Although patching is a crucial step in maintaining system security, it can be slow and tedious work, particularly if you maintain several machines. Superglue was designed to take the burden of patching off of the system administrator, making it more likely that patches will be applied regularly. To use Superglue, all you need to do is mount the Superglue directory on your machine and run the program. Superglue takes care of the rest.

As root:

1. /sbin/mount -o (mount point) /mnt
2. /mnt/superglue --this step can take a while depending on number of patches, machine speed, and network speed
3. /sbin/umount /mnt

Please note that the scheduled maintenance period for the Solaris Superglue server is Tuesdays from 1730-1900 (5:30pm - 7:00pm). We strongly recommend that you plan your system patching activities accordingly.

Superglue is provided on an as-is basis and is not officially supported by CITES. Comments on the service may be sent to [email protected].

Random Findings

Re: Keeping any up-to-date?

Ciaran Deignan ([email protected])
Fri, 15 Jan 1999 10:24:03 +0100

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
• Next message: Casper Dik: "Re: ff.core exploit on Solaris (2.)7"
• Previous message: Darren J Moffat - Enterprise Services OS Product Support Group: "Re: Tracing by uid u after root does setuid(u)"
• Maybe in reply to: D. J. Bernstein: "Tracing by uid u after root does setuid(u)"
• Next in thread: Peter May: "Re: Keeping any up-to-date?"

On Thu, 14 Jan 1999, Randolf-Heiko Skerka wrote:

> On Mon, Jan 11, 1999 at 09:46:02AM +0000, John RIddoch wrote:
> > To carry on the thread of keeping Solaris patched, I wrote a script to
> > automatically update a systems patches overnight via cron.
>
> Great work. But are things like that available for other OSes (I�m thinking
> of AIX, HP-UX, CISCO IOS[?] and so on)?

For AIX, Bull has a check tool that verifies that PTFs corresponding to security problems have been installed. The tool is called "bull_check", and is available from www-frec.bull.com (click on "download").

By default it checks for Year2000 PTFs, give it the option "security" to check for security things.

I have a script to automatically download the missing PTFs from the Bull PTF server, if anybody's interested.

Bye Ciaran

+-------------------------------------------------------------------------+
Ciaran Deignan Tel: (France) 04 76 29 79 92
BULL XS-BU (http://www-frec.bull.com) Internet Support Project Leader

Office: C1/012 Bullcom: 229 79 92
Mail to: C1/023 or [email protected] Fax: 229 76 89
+-------------------------------------------------------------------------+

• Next message: Casper Dik: "Re: ff.core exploit on Solaris (2.)7"
• Previous message: Darren J Moffat - Enterprise Services OS Product Support Group: "Re: Tracing by uid u after root does setuid(u)"
• Maybe in reply to: D. J. Bernstein: "Tracing by uid u after root does setuid(u)"
• Next in thread: Peter May: "Re: Keeping any up-to-date?"

This archive was generated by hypermail 2.0b3 on Fri Jan 15 1999 - 09:48:18 PST

Etc

Society

Groupthink : Two Party System as Polyarchy : Corruption of Regulators : Bureaucracies : Understanding Micromanagers and Control Freaks : Toxic Managers :   Harvard Mafia : Diplomatic Communication : Surviving a Bad Performance Review : Insufficient Retirement Funds as Immanent Problem of Neoliberal Regime : PseudoScience : Who Rules America : Neoliberalism  : The Iron Law of Oligarchy : Libertarian Philosophy

Quotes

War and Peace : Skeptical Finance : John Kenneth Galbraith :Talleyrand : Oscar Wilde : Otto Von Bismarck : Keynes : George Carlin : Skeptics : Propaganda  : SE quotes : Language Design and Programming Quotes : Random IT-related quotes :  Somerset Maugham : Marcus Aurelius : Kurt Vonnegut : Eric Hoffer : Winston Churchill : Napoleon Bonaparte : Ambrose Bierce :  Bernard Shaw : Mark Twain Quotes

Bulletin:

Vol 25, No.12 (December, 2013) Rational Fools vs. Efficient Crooks The efficient markets hypothesis : Political Skeptic Bulletin, 2013 : Unemployment Bulletin, 2010 :  Vol 23, No.10 (October, 2011) An observation about corporate security departments : Slightly Skeptical Euromaydan Chronicles, June 2014 : Greenspan legacy bulletin, 2008 : Vol 25, No.10 (October, 2013) Cryptolocker Trojan (Win32/Crilock.A) : Vol 25, No.08 (August, 2013) Cloud providers as intelligence collection hubs : Financial Humor Bulletin, 2010 : Inequality Bulletin, 2009 : Financial Humor Bulletin, 2008 : Copyleft Problems Bulletin, 2004 : Financial Humor Bulletin, 2011 : Energy Bulletin, 2010 : Malware Protection Bulletin, 2010 : Vol 26, No.1 (January, 2013) Object-Oriented Cult : Political Skeptic Bulletin, 2011 : Vol 23, No.11 (November, 2011) Softpanorama classification of sysadmin horror stories : Vol 25, No.05 (May, 2013) Corporate bullshit as a communication method  : Vol 25, No.06 (June, 2013) A Note on the Relationship of Brooks Law and Conway Law

History:

Fifty glorious years (1950-2000): the triumph of the US computer engineering : Donald Knuth : TAoCP and its Influence of Computer Science : Richard Stallman : Linus Torvalds  : Larry Wall  : John K. Ousterhout : CTSS : Multix OS Unix History : Unix shell history : VI editor : History of pipes concept : Solaris : MS DOS :  Programming Languages History : PL/1 : Simula 67 : C : History of GCC development :  Scripting Languages : Perl history   : OS History : Mail : DNS : SSH : CPU Instruction Sets : SPARC systems 1987-2006 : Norton Commander : Norton Utilities : Norton Ghost : Frontpage history : Malware Defense History : GNU Screen : OSS early history

Classic books:

The Peter Principle : Parkinson Law : 1984 : The Mythical Man-Month :  How to Solve It by George Polya : The Art of Computer Programming : The Elements of Programming Style : The Unix Hater�s Handbook : The Jargon file : The True Believer : Programming Pearls : The Good Soldier Svejk : The Power Elite

Most popular humor pages:

Manifest of the Softpanorama IT Slacker Society : Ten Commandments of the IT Slackers Society : Computer Humor Collection : BSD Logo Story : The Cuckoo's Egg : IT Slang : C++ Humor : ARE YOU A BBS ADDICT? : The Perl Purity Test : Object oriented programmers of all nations : Financial Humor : Financial Humor Bulletin, 2008 : Financial Humor Bulletin, 2010 : The Most Comprehensive Collection of Editor-related Humor : Programming Language Humor : Goldman Sachs related humor : Greenspan humor : C Humor : Scripting Humor : Real Programmers Humor : Web Humor : GPL-related Humor : OFM Humor : Politically Incorrect Humor : IDS Humor : "Linux Sucks" Humor : Russian Musical Humor : Best Russian Programmer Humor : Microsoft plans to buy Catholic Church : Richard Stallman Related Humor : Admin Humor : Perl-related Humor : Linus Torvalds Related humor : PseudoScience Related Humor : Networking Humor : Shell Humor : Financial Humor Bulletin, 2011 : Financial Humor Bulletin, 2012 : Financial Humor Bulletin, 2013 : Java Humor : Software Engineering Humor : Sun Solaris Related Humor : Education Humor : IBM Humor : Assembler-related Humor : VIM Humor : Computer Viruses Humor : Bright tomorrow is rescheduled to a day after tomorrow : Classic Computer Humor

The Last but not Least Technology is dominated by two types of people: those who understand what they do not manage and those who manage what they do not understand ~Archibald Putt. Ph.D

The statements, views and opinions presented on this web page are those of the author (or referenced source) and are not endorsed by, nor do they necessarily reflect, the opinions of the Softpanorama society. We do not warrant the correctness of the information provided or its fitness for any purpose. The site uses AdSense so you need to be aware of Google privacy policy. You you do not want to be tracked by Google please disable Javascript for this site. This site is perfectly usable without Javascript.

Last modified: March 12, 2019