I've installed OES-Linux before, so I didn't expect the kinds of problems I had with this latest round. I was attempting to install OES-Linux SP1 into a VM-Ware session, and things went a little pear-shaped when it came time for the eDir install. For reasons beyond my understanding, the eDir install failed.
I've spent the last three days poking at this one. I'm surprised that the GUI didn't work. But the bright side to this is that troubleshooting the problem has caused me to learn a lot more about how all those fun YaST installers work under the hood.
The problem that nailed me was that eDir wouldn't install. It got to the point where it attempted to contact the newly-configured eDir, and gave me an unable to bind to LDAP error. Much poking later, and I discovered that eDir was infact up, but secure LDAP wasn't running. Since eDir was up I was able to point ConsoleOne at it and discovered that the LDAP Server object didn't have a certificate associated with it. Weird. I hand-associated it, and then Secure-LDAP started working.
But 'nldap -s' did not report that it was up, even though I could do secure-LDAP sessions with binds and everything. Odd. More poking, and I suspected that this was due to the eDir install process probably exporting keys or something and nldap not having the right trusted-root to play with. Or something.
The main reason I was trying to install OES-Linux in the first place was that I wanted to get NSS-on-linux running. Once I got an eDir responding to hails, I attempted to get NSS up and running. And it just plain would not install the user-object it needs to manage NSS-on-linux. No matter what I did. It spat an '6f' error, which did not yield to googling.
That wasn't the only feature. There were other oddities in the process that just made it a pain to work with.
So this afternoon I tried an edir-from-scratch again by way of 'ndsconfig new -t treename -a admin.me -n o=me' command. And miracle of miracles, this time it ran to completion without barking about not being able to associate a SSL certificate with LDAP. W-e-i-r-d. The ONLY difference that I know of between this attempt and earleir attempts is that I gave up and told it to install the server in the O rather than in an OU. Why that would make a difference, I just don't know. But it did. EDir installed just fine, and the oddities went away. NSS was able to get its user installed.
Unfortunately, by now I had uninstalled and reinstalled iManager, NSS, SMS, and LUM so many times that things were messy in the file-system. So I don't have a working iManager right now since my web-server on that box has gone away somehow. I don't understand that right now.
Friday, when I'm next at work, I plan on blowing the whole thing away and installing fresh. Only this time with the server in the O from the get-go, so I can see what a 'normal' OES install is supposed to look like. Perhaps then I'll get the NSS-on-linux thing up and running.
Now if only I had a test-box that wasn't also 4 years old, I could get some performance tests out of it. Hmmmmm.
I've spent the last three days poking at this one. I'm surprised that the GUI didn't work. But the bright side to this is that troubleshooting the problem has caused me to learn a lot more about how all those fun YaST installers work under the hood.
The problem that nailed me was that eDir wouldn't install. It got to the point where it attempted to contact the newly-configured eDir, and gave me an unable to bind to LDAP error. Much poking later, and I discovered that eDir was infact up, but secure LDAP wasn't running. Since eDir was up I was able to point ConsoleOne at it and discovered that the LDAP Server object didn't have a certificate associated with it. Weird. I hand-associated it, and then Secure-LDAP started working.
But 'nldap -s' did not report that it was up, even though I could do secure-LDAP sessions with binds and everything. Odd. More poking, and I suspected that this was due to the eDir install process probably exporting keys or something and nldap not having the right trusted-root to play with. Or something.
The main reason I was trying to install OES-Linux in the first place was that I wanted to get NSS-on-linux running. Once I got an eDir responding to hails, I attempted to get NSS up and running. And it just plain would not install the user-object it needs to manage NSS-on-linux. No matter what I did. It spat an '6f' error, which did not yield to googling.
That wasn't the only feature. There were other oddities in the process that just made it a pain to work with.
So this afternoon I tried an edir-from-scratch again by way of 'ndsconfig new -t treename -a admin.me -n o=me' command. And miracle of miracles, this time it ran to completion without barking about not being able to associate a SSL certificate with LDAP. W-e-i-r-d. The ONLY difference that I know of between this attempt and earleir attempts is that I gave up and told it to install the server in the O rather than in an OU. Why that would make a difference, I just don't know. But it did. EDir installed just fine, and the oddities went away. NSS was able to get its user installed.
Unfortunately, by now I had uninstalled and reinstalled iManager, NSS, SMS, and LUM so many times that things were messy in the file-system. So I don't have a working iManager right now since my web-server on that box has gone away somehow. I don't understand that right now.
Friday, when I'm next at work, I plan on blowing the whole thing away and installing fresh. Only this time with the server in the O from the get-go, so I can see what a 'normal' OES install is supposed to look like. Perhaps then I'll get the NSS-on-linux thing up and running.
Now if only I had a test-box that wasn't also 4 years old, I could get some performance tests out of it. Hmmmmm.
I've had better success skipping the initial OES configuration, and waiting for the box to do it's final reboot. Then, after it is back up, go into YaST and run the eDir config tool, then NSS, etc.--Alex