LDAP Admin unable to login during boot after OES2 SP3

Hi,

I have upgraded all our local servers and a couple of regional servers to OES2 SP3, using the online updates through yast2 and selecting the "upgrade to OES2 SP3" box. After the initial script install, and then the rerun of the update to do the actual update all looks good. Then I reboot the server and it asks me for the Admin password to upgrade eDir.

This worked fine for some servers, but others are having issues saying the password is wrong (which it is not). If I just continue I can see the eDir versions have been updated and all seems fine, it just becomes an irritation now that every time the server boots it asks me for the Admin password and will not go further. I have tried placing the obfuscated password in the answer file as well without success.

Is there a way to run this process after I have logged in or even better to tell the server that it is done and not to ask me everytime?
  • That shouldn't be, although the only thing I can think of is that it's perhaps trying to reference an LDAP server that isn't up/running yet? Like perhaps the local LDAP server vs. a "remote" one?

    I'm not sure where the upgrade gets its information from. I mean I know that /etc/nam.conf has a list of LDAP servers, but I'm not sure if this is the only list that's maintained.
  • kjhurni;2117393 wrote:
    That shouldn't be, although the only thing I can think of is that it's perhaps trying to reference an LDAP server that isn't up/running yet? Like perhaps the local LDAP server vs. a "remote" one?

    I'm not sure where the upgrade gets its information from. I mean I know that /etc/nam.conf has a list of LDAP servers, but I'm not sure if this is the only list that's maintained.


    Yeah that was my thinking as they all point to their own local LDAP server and then use the HQ as an alternate. BUT I then tried to force it to only use the HQ "Remote" server and this also did not work. I am sure we are on the right track though. That is why I asked if there was a way to run this process once the server was up as then we could test LDAP connectivity before running this process.
  • That's a good question. I don't believe there is, but let me check for you (I've had a need to run it as well, while the server is up, not just on bootup)
  • I have tried this again using the silent (answer file) method. One pointing to the local LDAP and the other to the Main Org LDAP server and both failed again. Did you get an answer from Novell on this?
  • No official answer just yet. We think it would use the "localhost", but not sure.
    If you tried a non-local LDAP server, you should be able to enable LDAP tracing on the DSTRACE menu (I use DSMONITOR thingy):

    https://serverip:8030
    choose DSTRACE
    I "unselect all" and then whatever it "needs" it leaves checked. I then check the LDAP box and enable tracing. You should at least be able to see the login attemp (at least that would indicate it IS talking to the other server and perhaps it will indicate an error with why it doesn't like to login?)
  • kjhurni;2118117 wrote:
    No official answer just yet. We think it would use the "localhost", but not sure.
    If you tried a non-local LDAP server, you should be able to enable LDAP tracing on the DSTRACE menu (I use DSMONITOR thingy):

    https://serverip:8030
    choose DSTRACE
    I "unselect all" and then whatever it "needs" it leaves checked. I then check the LDAP box and enable tracing. You should at least be able to see the login attemp (at least that would indicate it IS talking to the other server and perhaps it will indicate an error with why it doesn't like to login?)


    I have tested the LDAP browser from these servers and although quite slow they do login and work. Maybe it is a timeout issue.
  • rob collins wrote:

    >
    > kjhurni;2118117 Wrote:
    >> No official answer just yet. We think it would use the "localhost", but
    >> not sure.
    >> If you tried a non-local LDAP server, you should be able to enable LDAP
    >> tracing on the DSTRACE menu (I use DSMONITOR thingy):
    >>
    >> https://serverip:8030
    >> choose DSTRACE
    >> I "unselect all" and then whatever it "needs" it leaves checked. I then
    >> check the LDAP box and enable tracing. You should at least be able to
    >> see the login attemp (at least that would indicate it IS talking to the
    >> other server and perhaps it will indicate an error with why it doesn't
    >> like to login?)

    >
    > I have tested the LDAP browser from these servers and although quite
    > slow they do login and work. Maybe it is a timeout issue.
    >
    >


    You say it is slow. When you say slow is it like 10 to 12 seconds? If it is
    you may have been bit by the same thing I did when I went to sp3. If you did
    I can dig up what we did to try and fix it. If it is the same issue and you
    want to open an sr I can get you the bug number for it as well.
  • Yeah probably longer. That would be great if you could.
  • rob collins wrote:

    >
    > Yeah probably longer. That would be great if you could.
    >
    >


    Please, lets do a troubleshooting step here. If you are running the latest
    version of NMAS Plugins for iManager, go to: Directory Administration|Browse
    to your Login Policy Object|Settings Tab.

    Then, change it to 0 (zero), bounce ndsd on those servers and let's try it
    again and see how it goes.

    This is what I had to do. Still waiting on more info.
  • hmm, wonder if that's why we haven't noticed it.
    We created a specific UP policy and put our Admin user (amongst others) in there, so that the password never expires, whereas our regular "login policy" is assigned to the login doohickey in eDir and our "regular" users have to change their passwords every X days.