On Fri, Jun 27, 2008 at 1:06 PM, Damon Getsman <[EMAIL PROTECTED]> wrote: > Recently one of our failover SRSS4 servers (running on OpenSuSE 10.3) ended > up having a catastrophic hardware failure necessitating rerolling a new > one. In the past we have used a method for doing this that hasn't given us > any problems. [...]
That whole procedure makes the hairs on the back of my neck stand up. I think you've been amazingly lucky that it's worked at all, let alone on several occasions. > As I said, previously this worked without any issues. Unfortunately this > time we've run into some problems. The entire configuration of the sunray > services seemed to occur without any mishap, until it attempted to add 18 > ldap entries to an ldap directory. > > At this point the error message dealt with not being able to insert them > into the directory. What were the error messages? Did you run a 'utconfig -u' before attempting to run 'utconfig'? > Here is where I think the problem lies. Early on in my > time on these clusters, I was set to making the machines authenticate over > LDAP. During this time I knew next to nothing about SRSS and had no idea > that it used LDAP. SRSS uses the LDAP protocol, but only to talk to a private instance of an LDAP server running on its own TCP port, completely unrelated to any other LDAP service that might be active on the system. SRSS does not interact with 'slapd', except incidentally through standard system API's that might eventually result in some LDAP activity. The LDAP commands executed by 'utconfig' are aimed at the private SRSS LDAP service. > While I was configuring the servers I noticed slapd > running on the machines (can't remember if it was some or all) and I > disabled the service. I believe there are still backups of the original > slapd.conf file, and /var/lib/ldap still shows a large database, but I > cannot get slapd to run on any of the machines in order to determine if this > is the problem or not. SRSS doesn't know about any of this. If turning off this slapd instance interferes with any of the usual system features (password record retrieval for user accounts, user authentication, hostname lookups, ...) then SRSS could suffer along with any other application that tries to use those features, but it doesn't have a direct dependency on a slapd instance and it has no knowledge of the configuration of any slapd instance. > So what I'm really asking is a multipart question: First off, what is the > role of LDAP in SRSS, and is this why the process is failing? LDAP is the protocol that SRSS uses to interact with its private data store. It has nothing to do with why some slapd process is unhappy. > Second, is > there any sort of special configuration of slapd that I need to be aware of > when trying to get this service running again on the localhost? Not that SRSS knows or cares about. > Third, do I > need to wipe my ldap.conf files on these machines so that they can properly > speak to their own slapd? Finally, is there anywhere that I could find an > existing configuration of this sort in order to rebuild any configuration > files that I may have destroyed? Obviously you need to bring this slapd's configuration into line with whatever it is that your site uses it for, but that's completely separate from SRSS. Perhaps you don't need slapd to be running at all -- you say it's been disabled for some time with no ill effect. If your site doesn't use LDAP for anything then there'd be no reason for slapd to be running anywhere. I'd concentrate on the 'utconfig' issue. I the rest of the system is happy without slapd running then SRSS probably doesn't care either. The 'utconfig' failure might be the only thing that's preventing SRSS from running. Is the machine you're trying to rebuild a Sun Ray DS secondary, and did you pull the tarball from some other DS secondary? OttoM. __ ottomeister Disclaimer: These are my opinions. I do not speak for my employer. _______________________________________________ SunRay-Users mailing list [email protected] http://www.filibeto.org/mailman/listinfo/sunray-users
