NIM clients and multibos - Aix

This is a discussion on NIM clients and multibos - Aix ; Hi I want to upgrade my NIM clients to new TL-SP. I'd like to use multibos for that. I don't know where to start. To do NIM client upgrade using alt_disk_install there is "fast path" nimadm but there is none ...

+ Reply to Thread
Results 1 to 9 of 9

Thread: NIM clients and multibos

  1. NIM clients and multibos

    Hi

    I want to upgrade my NIM clients to new TL-SP. I'd like to use multibos
    for that. I don't know where to start. To do NIM client upgrade using
    alt_disk_install there is "fast path" nimadm but there is none for
    multibos.

    How to use multibos with NIM ? I can't find _anything_ on the web. Can
    you please point me in the right direction ?


    --
    Regards
    Piotrek Kapczuk


  2. Re: NIM clients and multibos

    piotr::kapczuk wrote:
    > Hi
    >
    > I want to upgrade my NIM clients to new TL-SP. I'd like to use multibos
    > for that. I don't know where to start. To do NIM client upgrade using
    > alt_disk_install there is "fast path" nimadm but there is none for
    > multibos.
    >
    > How to use multibos with NIM ? I can't find _anything_ on the web. Can
    > you please point me in the right direction ?
    >
    >


    Ummmm...why go through the effort of creating the lppsource? Just down
    load the files to your master, export the directory and then (from the
    client), mount the directory, and run smit(ty) update_all (use the
    directory that was mounted on the client when prompted/required)...then
    "follow the bouncing ball"...

    HTH
    p.s. You SHOULDN'T need to use "multibios" for a "TL-SP" updates!!

  3. Re: NIM clients and multibos

    Sub Genius wrote:
    > p.s. You SHOULDN'T need to use "multibios" for a "TL-SP" updates!!


    pray tell, why?

    i shouldn't have needed an alt_disk_install backup of my 5.2 OS
    following my upgrade to 5.3.. until I uncovered a rather nasty
    performance regression involving ftp, password hashing and having a
    massive number of accounts on a system (which ibm still has not fixed
    yet.. but we're working on it with them).

    in the few brief times i played with multibos, it proved interesting as
    another method to back out a significant os change (patch application).
    it also had some.. 'odd' interactions with existing volume groups (i.e.
    some of the vg info didn't appear to fully copy to the alternate bos
    image/filesystem/ODM.. or something). it looks to be increasing in
    stability but is still rather fresh.

    -r

  4. Re: NIM clients and multibos

    no body wrote:
    > i shouldn't have needed an alt_disk_install backup of my 5.2 OS
    > following my upgrade to 5.3.. until I uncovered a rather nasty
    > performance regression involving ftp, password hashing and having a
    > massive number of accounts on a system (which ibm still has not fixed
    > yet.. but we're working on it with them).


    I'd be interested in hearing more about this bug. What is the performance
    hit, and how many accounts does it take to make the problem visible?

    --
    Mark Perew
    To the world you may be just one person,
    but to one person you may be the world. (Source Unknown)

    --
    Posted via a free Usenet account from http://www.teranews.com


  5. Re: NIM clients and multibos

    In news:yCG1j.9907$B21.5787@trndny07,
    Sub Genius typed:

    > piotr::kapczuk wrote:
    >> Hi
    >>
    >> I want to upgrade my NIM clients to new TL-SP. I'd like to use
    >> multibos for that. I don't know where to start. To do NIM client
    >> upgrade using alt_disk_install there is "fast path" nimadm but there
    >> is none for multibos.
    >>
    >> How to use multibos with NIM ? I can't find _anything_ on the web.
    >> Can you please point me in the right direction ?
    >>
    >>

    >
    > Ummmm...why go through the effort of creating the lppsource? Just
    > down load the files to your master, export the directory and then
    > (from the client), mount the directory, and run smit(ty) update_all
    > (use the directory that was mounted on the client when
    > prompted/required)...then "follow the bouncing ball"...


    Thanks. I did it using NFS. I was hooping there is some automation to
    upgrade machine groups


    > HTH
    > p.s. You SHOULDN'T need to use "multibios" for a "TL-SP" updates!!


    Why ?


    --
    Pozdrawiam
    Piotrek Kapczuk


  6. Re: NIM clients and multibos

    Mark Perew wrote:
    > I'd be interested in hearing more about this bug. What is the performance
    > hit, and how many accounts does it take to make the problem visible?


    in a nutshell.. ftp server, ~21.5k accounts, uses hashing for
    authentication files (see mkpasswd), sees per-minute peaks of ~350-400
    connects/min during heavy-traffic periods in the mornings. under 5.2,
    all ftp sessions could be connected and closed inside of 10 seconds
    (average worst case, typical was closer to 6-8 secs). this is simply
    completing authentication and doing a 'ls' (scripted using curl as a ftp
    client). under 5.3, this process goes up to 1m45s at best. culprit
    appeared to be severe IO to the hashfile for lastlog. delete lastlog,
    rebuild hashes.. 8s turnaround times return, but then some commands
    break. ibm apparently has totally revamped routines servicing
    authentication.. but some processes now apparently load entire file
    contents per change instead of accessing keyed records in a hashfile. so
    far, we're into the first efix which supposely fixed some problem in a
    low-level subroutine (putuserattr? processing time per login was
    supposedly cut from 500ms to 100ms) but now the ftpds simply sit there
    doing nothing for a minute until finally closing the connection.

    this was uncovered after a 5.2 -> 5.3 nimadm upgrade, when the server
    started its morning traffic ramp-up and promptly buried itself in
    stalled ftp connections until it exhausted page.

    -r

  7. Re: NIM clients and multibos

    no body schrieb:
    > Mark Perew wrote:
    >> I'd be interested in hearing more about this bug. What is the performance
    >> hit, and how many accounts does it take to make the problem visible?

    >
    > in a nutshell..


    Reference numbers, like APAR, PMR (service request) could
    be useful for others.

  8. Re: NIM clients and multibos

    On 26 Nov., 23:34, no body wrote:
    > Mark Perew wrote:
    > > I'd be interested in hearing more about this bug. What is the performance
    > > hit, and how many accounts does it take to make the problem visible?

    >
    > in a nutshell.. ftp server, ~21.5k accounts, uses hashing for
    > authentication files (see mkpasswd), sees per-minute peaks of ~350-400
    > connects/min during heavy-traffic periods in the mornings. under 5.2,

    .....

    I think we had a similar thread a few month ago. On our AIX 5.3 box we
    had that problem that the wtmp file was getting to large thus ftp and
    normal logins started to take seconds. Might worth to take a look at
    the wtmp and rotate it in case it is getting to large.

    hth
    Hajo

  9. Re: NIM clients and multibos

    Hajo Ehlers schrieb:
    > On 26 Nov., 23:34, no body wrote:
    >> Mark Perew wrote:
    >>> I'd be interested in hearing more about this bug. What is the performance
    >>> hit, and how many accounts does it take to make the problem visible?

    >> in a nutshell.. ftp server, ~21.5k accounts, uses hashing for
    >> authentication files (see mkpasswd), sees per-minute peaks of ~350-400
    >> connects/min during heavy-traffic periods in the mornings. under 5.2,

    > ....
    >
    > I think we had a similar thread a few month ago. On our AIX 5.3 box we
    > had that problem that the wtmp file was getting to large thus ftp and
    > normal logins started to take seconds. Might worth to take a look at
    > the wtmp and rotate it in case it is getting to large.
    >
    > hth
    > Hajo


    Ok, but I'm looking for a real ref, like
    IY88127
    Commands like ls -l, ps, istat open indexed files like
    /etc/passwd.id.idx, /etc/passwd.nm.idx in O_RDWR mode
    when they should not be.

    And they not open them in read-write, if the user has
    write permission to the file (like root), they rebuild
    the file ... large perf hit.
    I'm not sure IY88127 does fix this too.

    But some more searching got me to IY88180
    Commands like ls -l, istat write to the colon indexed id
    files /etc/passwd.id.idx, /etc/group.id.idx files.

    And IY97858
    The index files for the security files /etc/passwd and
    /etc/group (e.g. /etc/passwd.id.idx and
    /etc/passwd.nm.idx)
    are being unnecessarily updated.
    which is fixed with
    U811513 bos.rte.security 5.3.7.1
    U813779 bos.rte.libc 5.3.7.1
    U813781 bos.adt.prof 5.3.7.1

    Then there are IY88941, IY89582, IY89585 and IZ02764

    None APAR points to wtmp (as far as I see). But for
    those with large passwd/group files and perf problems
    using indexed files, the APARs above may help.
    However, it seems that the initial poster currently
    has a call open with IBM - could be a new bug and I
    want to know the PMR or APAR number. Would be easier
    than searching for me :-)

+ Reply to Thread