Best way for AIX patch management - Aix

This is a discussion on Best way for AIX patch management - Aix ; Hi, I know this might be a odd question because there's nothing such as "best way", it varies from person to person, but just want to take some opinions on how people world over do their patch management like upgrade ...

+ Reply to Thread
Results 1 to 10 of 10

Thread: Best way for AIX patch management

  1. Best way for AIX patch management

    Hi,

    I know this might be a odd question because there's nothing such as
    "best way", it varies from person to person, but just want to take
    some opinions on how people world over do their patch management like
    upgrade TLs etc.

    This is how I have been doing,

    - Break the mirror or rootvg (LPARs with VIO disks). If rootvg disks
    are physical disks of Managed system, assign another disk for OS
    upgrade
    - do a alt_disk_copy from NIM and give new LPP source name (of new TL)
    to be applied after copy.
    - verify from NIM installp logs if the copy & upgrade was successful
    or not.
    - If successful, schedule a reboot of server (with some spare time).
    - Change the bootlist to new disk (on which we copied rootvg + new TL)
    and reboot the server
    - Once back up, check the oslevel.
    - If everything is fine, remove the old rootvg and put disks of old
    rootvg to new rootvg.
    - Establish mirroring, and remove the temp. disk used for upgrade from
    rootvg

    looking forward to see how others are doing OS upgrades.

    cheers..

  2. Re: Best way for AIX patch management

    In
    news:992db118-354b-4090-9a36-6ababe527d6a@59g2000hsb.googlegroups.com,
    Abhi typed:

    > Hi,
    >
    > I know this might be a odd question because there's nothing such as
    > "best way", it varies from person to person, but just want to take
    > some opinions on how people world over do their patch management like
    > upgrade TLs etc.
    >
    > This is how I have been doing,
    >
    > - Break the mirror or rootvg (LPARs with VIO disks). If rootvg disks
    > are physical disks of Managed system, assign another disk for OS
    > upgrade
    > - do a alt_disk_copy from NIM and give new LPP source name (of new TL)
    > to be applied after copy.
    > - verify from NIM installp logs if the copy & upgrade was successful
    > or not.
    > - If successful, schedule a reboot of server (with some spare time).
    > - Change the bootlist to new disk (on which we copied rootvg + new TL)
    > and reboot the server
    > - Once back up, check the oslevel.
    > - If everything is fine, remove the old rootvg and put disks of old
    > rootvg to new rootvg.
    > - Establish mirroring, and remove the temp. disk used for upgrade from
    > rootvg
    >
    > looking forward to see how others are doing OS upgrades.



    I use mutlibos(3).

    --
    Regards
    Piotrek Kapczuk


  3. Re: Best way for AIX patch management

    Abhi schrieb:
    > Hi,
    >
    > I know this might be a odd question because there's nothing such as
    > "best way", it varies from person to person, but just want to take
    > some opinions on how people world over do their patch management like
    > upgrade TLs etc.
    >
    > This is how I have been doing,
    >
    > - Break the mirror or rootvg (LPARs with VIO disks). If rootvg disks
    > are physical disks of Managed system, assign another disk for OS
    > upgrade
    > - do a alt_disk_copy from NIM and give new LPP source name (of new TL)
    > to be applied after copy.
    > - verify from NIM installp logs if the copy & upgrade was successful
    > or not.
    > - If successful, schedule a reboot of server (with some spare time).
    > - Change the bootlist to new disk (on which we copied rootvg + new TL)
    > and reboot the server
    > - Once back up, check the oslevel.
    > - If everything is fine, remove the old rootvg and put disks of old
    > rootvg to new rootvg.
    > - Establish mirroring, and remove the temp. disk used for upgrade from
    > rootvg
    >
    > looking forward to see how others are doing OS upgrades.
    >
    > cheers..

    Hi

    my opinion: What you are describing is ok for migrating AIX to a new
    version or release, but sounds a little bit paranoid for TL/SP updates.
    To me it is sufficient save to
    1) commit all applied software, if not already done
    2) create a system backup (mksysb), if not already done
    3) install TL/SP with "Commit software updates?=no" and "Save replaced
    files? = yes"
    4) reboot, check
    5) wait one or two week(s)
    6) commit applied software

    If your update does not work, just "reject applied software"

    Regards,
    Uwe Auer

  4. Re: Best way for AIX patch management

    On Sep 11, 8:21 pm, Uwe Auer wrote:
    > Abhi schrieb:
    >
    > > Hi,

    >
    > > I know this might be a odd question because there's nothing such as
    > > "best way", it varies from person to person, but just want to take
    > > some opinions on how people world over do their patch management like
    > > upgrade TLs etc.

    >
    > > This is how I have been doing,

    >
    > > - Break the mirror or rootvg (LPARs with VIO disks). If rootvg disks
    > > are physical disks of Managed system, assign another disk for OS
    > > upgrade
    > > - do a alt_disk_copy from NIM and give new LPP source name (of new TL)
    > > to be applied after copy.
    > > - verify from NIM installp logs if the copy & upgrade was successful
    > > or not.
    > > - If successful, schedule a reboot of server (with some spare time).
    > > - Change the bootlist to new disk (on which we copied rootvg + new TL)
    > > and reboot the server
    > > - Once back up, check the oslevel.
    > > - If everything is fine, remove the old rootvg and put disks of old
    > > rootvg to new rootvg.
    > > - Establish mirroring, and remove the temp. disk used for upgrade from
    > > rootvg

    >
    > > looking forward to see how others are doing OS upgrades.

    >
    > > cheers..

    >
    > Hi
    >
    > my opinion: What you are describing is ok for migrating AIX to a new
    > version or release, but sounds a little bit paranoid for TL/SP updates.
    > To me it is sufficient save to
    > 1) commit all applied software, if not already done
    > 2) create a system backup (mksysb), if not already done
    > 3) install TL/SP with "Commit software updates?=no" and "Save replaced
    > files? = yes"
    > 4) reboot, check
    > 5) wait one or two week(s)
    > 6) commit applied software
    >
    > If your update does not work, just "reject applied software"
    >
    > Regards,
    > Uwe Auer


    Hi Uwe,

    2 things,

    1. Somehow I am not comfortable in working directly on rootvg (may be
    I am too conscious)
    2. What if something goes wrong during the upgrade, like a hdisk
    failure or a controller failure (in case of physical server)
    3. Do you apply these patches while applications are running on
    system ? or you shutdown apps ?


  5. Re: Best way for AIX patch management

    Abhi schrieb:
    > On Sep 11, 8:21 pm, Uwe Auer wrote:
    >> Abhi schrieb:
    >>
    >>> Hi,
    >>> I know this might be a odd question because there's nothing such as
    >>> "best way", it varies from person to person, but just want to take
    >>> some opinions on how people world over do their patch management like
    >>> upgrade TLs etc.
    >>> This is how I have been doing,
    >>> - Break the mirror or rootvg (LPARs with VIO disks). If rootvg disks
    >>> are physical disks of Managed system, assign another disk for OS
    >>> upgrade
    >>> - do a alt_disk_copy from NIM and give new LPP source name (of new TL)
    >>> to be applied after copy.
    >>> - verify from NIM installp logs if the copy & upgrade was successful
    >>> or not.
    >>> - If successful, schedule a reboot of server (with some spare time).
    >>> - Change the bootlist to new disk (on which we copied rootvg + new TL)
    >>> and reboot the server
    >>> - Once back up, check the oslevel.
    >>> - If everything is fine, remove the old rootvg and put disks of old
    >>> rootvg to new rootvg.
    >>> - Establish mirroring, and remove the temp. disk used for upgrade from
    >>> rootvg
    >>> looking forward to see how others are doing OS upgrades.
    >>> cheers..

    >> Hi
    >>
    >> my opinion: What you are describing is ok for migrating AIX to a new
    >> version or release, but sounds a little bit paranoid for TL/SP updates.
    >> To me it is sufficient save to
    >> 1) commit all applied software, if not already done
    >> 2) create a system backup (mksysb), if not already done
    >> 3) install TL/SP with "Commit software updates?=no" and "Save replaced
    >> files? = yes"
    >> 4) reboot, check
    >> 5) wait one or two week(s)
    >> 6) commit applied software
    >>
    >> If your update does not work, just "reject applied software"
    >>
    >> Regards,
    >> Uwe Auer

    >
    > Hi Uwe,
    >
    > 2 things,


    Counting leds me to "3" :-)
    >
    > 1. Somehow I am not comfortable in working directly on rootvg (may be
    > I am too conscious)


    It's completely up to you. I just expressed my opinion, and since working 15
    years with AIX, it never forced me to revise my opinion (Not claiming that I
    never had any problem). I never understood the constraints about working on
    rootvg and in fact you do it all day while administering your system.

    > 2. What if something goes wrong during the upgrade, like a hdisk
    > failure or a controller failure (in case of physical server)


    What can go wrong ? We do talk about applying Technology Levels and/or Service
    Packs and *not* about upgrading to a new AIX release. My ability to imagination
    is not great enough. The worst case scenario to me would be that the system
    (hdisk,adapter to rootvg disk) dies on executing "bosboot". If this happens
    really once during your AIX career, boot to maintenance an perform a manual
    bosboot. If your controller fails - how will you boot from your "saved" system ?

    And - you may conceive hardware failure scenarios, which make your approach a
    complete disaster, requiring to restore of an mksysb (see 2) on my original answer)

    > 3. Do you apply these patches while applications are running on
    > system ? or you shutdown apps ?
    >


    Depends on applications, risk concerns of customers, colleagues, service
    providers, availabilty requirements and experience. I tend to keep everything
    online while applying TL and SPs. But for sure there are situation where my
    approach could and will lead to problems.

    Regards,
    Uwe Auer

  6. Re: Best way for AIX patch management

    On Sep 12, 2:10*am, Uwe Auer wrote:
    > Abhi schrieb:
    >
    >
    >
    >
    >
    > > On Sep 11, 8:21 pm, Uwe Auer wrote:
    > >> Abhi schrieb:

    >
    > >>> Hi,
    > >>> I know this might be a odd question because there's nothing such as
    > >>> "best way", it varies from person to person, but just want to take
    > >>> some opinions on how people world over do their patch management like
    > >>> upgrade TLs etc.
    > >>> This is how I have been doing,
    > >>> - Break the mirror or rootvg (LPARs with VIO disks). If rootvg disks
    > >>> are physical disks of Managed system, assign another disk for OS
    > >>> upgrade
    > >>> - do a alt_disk_copy from NIM and give new LPP source name (of new TL)
    > >>> to be applied after copy.
    > >>> - verify from NIM installp logs if the copy & upgrade was successful
    > >>> or not.
    > >>> - If successful, schedule a reboot of server (with some spare time).
    > >>> - Change the bootlist to new disk (on which we copied rootvg + new TL)
    > >>> and reboot the server
    > >>> - Once back up, check the oslevel.
    > >>> - If everything is fine, remove the old rootvg and put disks of old
    > >>> rootvg to new rootvg.
    > >>> - Establish mirroring, and remove the temp. disk used for upgrade from
    > >>> rootvg
    > >>> looking forward to see how others are doing OS upgrades.
    > >>> cheers..
    > >> Hi

    >
    > >> my opinion: What you are describing is ok for migrating AIX to a new
    > >> version or release, but sounds a little bit paranoid for TL/SP updates..
    > >> To me it is sufficient save to
    > >> 1) commit all applied software, if not already done
    > >> 2) create a system backup (mksysb), if not already done
    > >> 3) install TL/SP with "Commit software updates?=no" and "Save replaced
    > >> * * files? = yes"
    > >> 4) reboot, check
    > >> 5) wait one or two week(s)
    > >> 6) commit applied software

    >
    > >> If your update does not work, just "reject applied software"

    >
    > >> Regards,
    > >> Uwe Auer

    >
    > > Hi Uwe,

    >
    > > 2 things,

    >
    > Counting leds me to "3" :-)
    >
    >
    >
    > > 1. Somehow I am not comfortable in working directly on rootvg (may be
    > > I am too conscious)

    >
    > It's completely up to you. I just expressed my opinion, and since working15
    > years with AIX, it never forced me to revise my opinion (Not claiming that I
    > never had any problem). I never understood the constraints about working on
    > rootvg and in fact you do it all day while administering your system.
    >
    > > 2. What if something goes wrong during the upgrade, like a hdisk
    > > failure or a controller failure (in case of physical server)

    >
    > What can go wrong ? We do talk about applying Technology Levels and/or Service
    > Packs and *not* about upgrading to a new AIX release. My ability to imagination
    > is not great enough. The worst case scenario to me would be that the system
    > (hdisk,adapter to rootvg disk) dies on executing "bosboot". If this happens
    > really once during your AIX career, boot to maintenance an perform a manual
    > bosboot. If your controller fails - how will you boot from your "saved" system ?
    >
    > And - you may conceive hardware failure scenarios, which make your approach a
    > complete disaster, requiring to restore of an mksysb (see 2) on my original answer)
    >
    > > 3. Do you apply these patches while applications are running on
    > > system ? or you shutdown apps ?

    >
    > Depends on applications, risk concerns of customers, colleagues, service
    > providers, availabilty requirements and experience. I tend to keep everything
    > online while applying TL and SPs. But for sure there are situation where my
    > approach could and will lead to problems.
    >
    > Regards,
    > Uwe Auer- Hide quoted text -
    >
    > - Show quoted text -


    Thanks Uwe for you input. I will try n change my approach of patch
    management :-)

  7. Re: Best way for AIX patch management

    On 12 Sep, 06:25, Abhi wrote:
    > On Sep 12, 2:10*am, Uwe Auer wrote:
    >
    >
    >
    >
    >
    > > Abhi schrieb:

    >
    > > > On Sep 11, 8:21 pm, Uwe Auer wrote:
    > > >> Abhi schrieb:

    >
    > > >>> Hi,
    > > >>> I know this might be a odd question because there's nothing such as
    > > >>> "best way", it varies from person to person, but just want to take
    > > >>> some opinions on how people world over do their patch management like
    > > >>> upgrade TLs etc.
    > > >>> This is how I have been doing,
    > > >>> - Break the mirror or rootvg (LPARs with VIO disks). If rootvg disks
    > > >>> are physical disks of Managed system, assign another disk for OS
    > > >>> upgrade
    > > >>> - do a alt_disk_copy from NIM and give new LPP source name (of new TL)
    > > >>> to be applied after copy.
    > > >>> - verify from NIM installp logs if the copy & upgrade was successful
    > > >>> or not.
    > > >>> - If successful, schedule a reboot of server (with some spare time)..
    > > >>> - Change the bootlist to new disk (on which we copied rootvg + new TL)
    > > >>> and reboot the server
    > > >>> - Once back up, check the oslevel.
    > > >>> - If everything is fine, remove the old rootvg and put disks of old
    > > >>> rootvg to new rootvg.
    > > >>> - Establish mirroring, and remove the temp. disk used for upgrade from
    > > >>> rootvg
    > > >>> looking forward to see how others are doing OS upgrades.
    > > >>> cheers..
    > > >> Hi

    >
    > > >> my opinion: What you are describing is ok for migrating AIX to a new
    > > >> version or release, but sounds a little bit paranoid for TL/SP updates.
    > > >> To me it is sufficient save to
    > > >> 1) commit all applied software, if not already done
    > > >> 2) create a system backup (mksysb), if not already done
    > > >> 3) install TL/SP with "Commit software updates?=no" and "Save replaced
    > > >> * * files? = yes"
    > > >> 4) reboot, check
    > > >> 5) wait one or two week(s)
    > > >> 6) commit applied software

    >
    > > >> If your update does not work, just "reject applied software"

    >
    > > >> Regards,
    > > >> Uwe Auer

    >
    > > > Hi Uwe,

    >
    > > > 2 things,

    >
    > > Counting leds me to "3" :-)

    >
    > > > 1. Somehow I am not comfortable in working directly on rootvg (may be
    > > > I am too conscious)

    >
    > > It's completely up to you. I just expressed my opinion, and since working 15
    > > years with AIX, it never forced me to revise my opinion (Not claiming that I
    > > never had any problem). I never understood the constraints about working on
    > > rootvg and in fact you do it all day while administering your system.

    >
    > > > 2. What if something goes wrong during the upgrade, like a hdisk
    > > > failure or a controller failure (in case of physical server)

    >
    > > What can go wrong ? We do talk about applying Technology Levels and/or Service
    > > Packs and *not* about upgrading to a new AIX release. My ability to imagination
    > > is not great enough. The worst case scenario to me would be that the system
    > > (hdisk,adapter to rootvg disk) dies on executing "bosboot". If this happens
    > > really once during your AIX career, boot to maintenance an perform a manual
    > > bosboot. If your controller fails - how will you boot from your "saved"system ?

    >
    > > And - you may conceive hardware failure scenarios, which make your approach a
    > > complete disaster, requiring to restore of an mksysb (see 2) on my original answer)

    >
    > > > 3. Do you apply these patches while applications are running on
    > > > system ? or you shutdown apps ?

    >
    > > Depends on applications, risk concerns of customers, colleagues, service
    > > providers, availabilty requirements and experience. I tend to keep everything
    > > online while applying TL and SPs. But for sure there are situation where my
    > > approach could and will lead to problems.

    >
    > > Regards,
    > > Uwe Auer- Hide quoted text -

    >
    > > - Show quoted text -

    >
    > Thanks Uwe for you input. I will try n change my approach of patch
    > management :-)- Hide quoted text -
    >
    > - Show quoted text -


    Hi Uwe,

    You say you will 'reject' applied updates if there is a problem.
    However this is not the IBM recommended way, they would tell you to do
    a mksysb restore I believe. They may not even support you doing a
    'reject' but I dont know this for sure.

    Scott

  8. Re: Best way for AIX patch management

    On Sep 12, 5:04 pm, scott wrote:
    > On 12 Sep, 06:25, Abhi wrote:
    >
    >
    >
    > > On Sep 12, 2:10 am, Uwe Auer wrote:

    >
    > > > Abhi schrieb:

    >
    > > > > On Sep 11, 8:21 pm, Uwe Auer wrote:
    > > > >> Abhi schrieb:

    >
    > > > >>> Hi,
    > > > >>> I know this might be a odd question because there's nothing such as
    > > > >>> "best way", it varies from person to person, but just want to take
    > > > >>> some opinions on how people world over do their patch management like
    > > > >>> upgrade TLs etc.
    > > > >>> This is how I have been doing,
    > > > >>> - Break the mirror or rootvg (LPARs with VIO disks). If rootvg disks
    > > > >>> are physical disks of Managed system, assign another disk for OS
    > > > >>> upgrade
    > > > >>> - do a alt_disk_copy from NIM and give new LPP source name (of new TL)
    > > > >>> to be applied after copy.
    > > > >>> - verify from NIM installp logs if the copy & upgrade was successful
    > > > >>> or not.
    > > > >>> - If successful, schedule a reboot of server (with some spare time).
    > > > >>> - Change the bootlist to new disk (on which we copied rootvg + new TL)
    > > > >>> and reboot the server
    > > > >>> - Once back up, check the oslevel.
    > > > >>> - If everything is fine, remove the old rootvg and put disks of old
    > > > >>> rootvg to new rootvg.
    > > > >>> - Establish mirroring, and remove the temp. disk used for upgrade from
    > > > >>> rootvg
    > > > >>> looking forward to see how others are doing OS upgrades.
    > > > >>> cheers..
    > > > >> Hi

    >
    > > > >> my opinion: What you are describing is ok for migrating AIX to a new
    > > > >> version or release, but sounds a little bit paranoid for TL/SP updates.
    > > > >> To me it is sufficient save to
    > > > >> 1) commit all applied software, if not already done
    > > > >> 2) create a system backup (mksysb), if not already done
    > > > >> 3) install TL/SP with "Commit software updates?=no" and "Save replaced
    > > > >> files? = yes"
    > > > >> 4) reboot, check
    > > > >> 5) wait one or two week(s)
    > > > >> 6) commit applied software

    >
    > > > >> If your update does not work, just "reject applied software"

    >
    > > > >> Regards,
    > > > >> Uwe Auer

    >
    > > > > Hi Uwe,

    >
    > > > > 2 things,

    >
    > > > Counting leds me to "3" :-)

    >
    > > > > 1. Somehow I am not comfortable in working directly on rootvg (may be
    > > > > I am too conscious)

    >
    > > > It's completely up to you. I just expressed my opinion, and since working 15
    > > > years with AIX, it never forced me to revise my opinion (Not claiming that I
    > > > never had any problem). I never understood the constraints about working on
    > > > rootvg and in fact you do it all day while administering your system.

    >
    > > > > 2. What if something goes wrong during the upgrade, like a hdisk
    > > > > failure or a controller failure (in case of physical server)

    >
    > > > What can go wrong ? We do talk about applying Technology Levels and/or Service
    > > > Packs and *not* about upgrading to a new AIX release. My ability to imagination
    > > > is not great enough. The worst case scenario to me would be that the system
    > > > (hdisk,adapter to rootvg disk) dies on executing "bosboot". If this happens
    > > > really once during your AIX career, boot to maintenance an perform a manual
    > > > bosboot. If your controller fails - how will you boot from your "saved" system ?

    >
    > > > And - you may conceive hardware failure scenarios, which make your approach a
    > > > complete disaster, requiring to restore of an mksysb (see 2) on my original answer)

    >
    > > > > 3. Do you apply these patches while applications are running on
    > > > > system ? or you shutdown apps ?

    >
    > > > Depends on applications, risk concerns of customers, colleagues, service
    > > > providers, availabilty requirements and experience. I tend to keep everything
    > > > online while applying TL and SPs. But for sure there are situation where my
    > > > approach could and will lead to problems.

    >
    > > > Regards,
    > > > Uwe Auer- Hide quoted text -

    >
    > > > - Show quoted text -

    >
    > > Thanks Uwe for you input. I will try n change my approach of patch
    > > management :-)- Hide quoted text -

    >
    > > - Show quoted text -

    >
    > Hi Uwe,
    >
    > You say you will 'reject' applied updates if there is a problem.
    > However this is not the IBM recommended way, they would tell you to do
    > a mksysb restore I believe. They may not even support you doing a
    > 'reject' but I dont know this for sure.

    It depends - as allway.
    The way Uwe discribed is the standard way of updating a system.
    BUT: Sometimes go get a new BASELEVEL fileset.
    Example:
    xlC.rte.9.0.0.0.I
    xlC.rte.9.0.0.1.I

    In case the new software has to be rejected it can not be done easily
    since you can not reject a baselevel fileset.
    In this case you had to do a forced overwrite of the base fileset and
    they reject the other updates.

    In case you switch to a new TL with many new fileset a reject to a
    former level might be not that easy at all . That the reason why i
    like to use gencopy to create my install source. Its creates the
    correct endings for the fileset like ..I for Install ( Base
    level ) , ..U for Update and you see at a glance all new base fileset.

    Please correct me if i should be wrong.

    Hajo

  9. Re: Best way for AIX patch management

    scott schrieb:
    > On 12 Sep, 06:25, Abhi wrote:
    >> On Sep 12, 2:10 am, Uwe Auer wrote:
    >>
    >>
    >>
    >>
    >>
    >>> Abhi schrieb:
    >>>> On Sep 11, 8:21 pm, Uwe Auer wrote:
    >>>>> Abhi schrieb:
    >>>>>> Hi,
    >>>>>> I know this might be a odd question because there's nothing such as
    >>>>>> "best way", it varies from person to person, but just want to take
    >>>>>> some opinions on how people world over do their patch management like
    >>>>>> upgrade TLs etc.
    >>>>>> This is how I have been doing,
    >>>>>> - Break the mirror or rootvg (LPARs with VIO disks). If rootvg disks
    >>>>>> are physical disks of Managed system, assign another disk for OS
    >>>>>> upgrade
    >>>>>> - do a alt_disk_copy from NIM and give new LPP source name (of new TL)
    >>>>>> to be applied after copy.
    >>>>>> - verify from NIM installp logs if the copy & upgrade was successful
    >>>>>> or not.
    >>>>>> - If successful, schedule a reboot of server (with some spare time).
    >>>>>> - Change the bootlist to new disk (on which we copied rootvg + new TL)
    >>>>>> and reboot the server
    >>>>>> - Once back up, check the oslevel.
    >>>>>> - If everything is fine, remove the old rootvg and put disks of old
    >>>>>> rootvg to new rootvg.
    >>>>>> - Establish mirroring, and remove the temp. disk used for upgrade from
    >>>>>> rootvg
    >>>>>> looking forward to see how others are doing OS upgrades.
    >>>>>> cheers..
    >>>>> Hi
    >>>>> my opinion: What you are describing is ok for migrating AIX to a new
    >>>>> version or release, but sounds a little bit paranoid for TL/SP updates.
    >>>>> To me it is sufficient save to
    >>>>> 1) commit all applied software, if not already done
    >>>>> 2) create a system backup (mksysb), if not already done
    >>>>> 3) install TL/SP with "Commit software updates?=no" and "Save replaced
    >>>>> files? = yes"
    >>>>> 4) reboot, check
    >>>>> 5) wait one or two week(s)
    >>>>> 6) commit applied software
    >>>>> If your update does not work, just "reject applied software"
    >>>>> Regards,
    >>>>> Uwe Auer
    >>>> Hi Uwe,
    >>>> 2 things,
    >>> Counting leds me to "3" :-)
    >>>> 1. Somehow I am not comfortable in working directly on rootvg (may be
    >>>> I am too conscious)
    >>> It's completely up to you. I just expressed my opinion, and since working 15
    >>> years with AIX, it never forced me to revise my opinion (Not claiming that I
    >>> never had any problem). I never understood the constraints about working on
    >>> rootvg and in fact you do it all day while administering your system.
    >>>> 2. What if something goes wrong during the upgrade, like a hdisk
    >>>> failure or a controller failure (in case of physical server)
    >>> What can go wrong ? We do talk about applying Technology Levels and/or Service
    >>> Packs and *not* about upgrading to a new AIX release. My ability to imagination
    >>> is not great enough. The worst case scenario to me would be that the system
    >>> (hdisk,adapter to rootvg disk) dies on executing "bosboot". If this happens
    >>> really once during your AIX career, boot to maintenance an perform a manual
    >>> bosboot. If your controller fails - how will you boot from your "saved" system ?
    >>> And - you may conceive hardware failure scenarios, which make your approach a
    >>> complete disaster, requiring to restore of an mksysb (see 2) on my original answer)
    >>>> 3. Do you apply these patches while applications are running on
    >>>> system ? or you shutdown apps ?
    >>> Depends on applications, risk concerns of customers, colleagues, service
    >>> providers, availabilty requirements and experience. I tend to keep everything
    >>> online while applying TL and SPs. But for sure there are situation where my
    >>> approach could and will lead to problems.
    >>> Regards,
    >>> Uwe Auer- Hide quoted text -
    >>> - Show quoted text -

    >> Thanks Uwe for you input. I will try n change my approach of patch
    >> management :-)- Hide quoted text -
    >>
    >> - Show quoted text -

    >
    > Hi Uwe,
    >
    > You say you will 'reject' applied updates if there is a problem.
    > However this is not the IBM recommended way, they would tell you to do
    > a mksysb restore I believe. They may not even support you doing a
    > 'reject' but I dont know this for sure.
    >
    > Scott

    Hi

    may be that IBM support would try to direct me to restore a mksysb. But i won't
    accept. What justification should that "apply" and a "reject" feature have other
    than the possibility to clean up from an update, which is not working for me. If
    IBM won't support that, then they need to remove these features from installp
    and from all SMIT menus

    I don't know, how others UNI*es do their software management nowadays, but i
    rmember times where this feature - amongst many others - was a great AIX
    differentiator to OSes of other vendors.


    BTW: Once i needed it and it worked.

    Regards,
    Uwe Auer

  10. Re: Best way for AIX patch management

    Uwe Auer wrote:



    UA>Hi
    UA>
    UA>may be that IBM support would try to direct me to restore a mksysb. But i won't
    UA>accept. What justification should that "apply" and a "reject" feature have other
    UA>than the possibility to clean up from an update, which is not working for me. If
    UA>IBM won't support that, then they need to remove these features from installp
    UA>and from all SMIT menus
    UA>
    UA>I don't know, how others UNI*es do their software management nowadays, but i
    UA>rmember times where this feature - amongst many others - was a great AIX
    UA>differentiator to OSes of other vendors.
    UA>
    UA>
    UA>BTW: Once i needed it and it worked.
    UA>
    UA>Regards,
    UA>Uwe Auer

    IBM's recommendation is to use mksysb to go back to a previous TL; reject
    applied sw is still supported between SPs. That is, say

    From 5.3.8.0 to 5.3.7.x <==== mksysb
    From 5.3.8.3 to 5.3.8.2 <==== reject

+ Reply to Thread