On Sun, Jun 29, 2008 at 4:00 AM, <[EMAIL PROTECTED]> wrote:
> From: ottomeister <[EMAIL PROTECTED]>
> Subject: Re: [SunRay-Users] role of slapd on linux SRSS
> servers/misconfiguration of slapd?
>
> 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.
This is my first time going through this procedure; I had the exact
same reaction when I learned the process that was already being used
to make new srss servers when we need them. I would love nothing
better than to learn how to make a fresh machine to insert into the
cluster; as soon as I'm not working with this issue I'll be spending
all spare time on learning how to do that.
> What were the error messages? Did you run a 'utconfig -u' before
> attempting to run 'utconfig'?
Yes on doing the utconfig -u, no webadmin, no kiosk mode,
For the standard utconfig, I enter the password, yes to failover
group, then I confirm the data that is to be added and get:
-=-=-=-=-
Sun Ray Core Services 4.0
Failover group: yes
Sun Ray Kiosk Mode: no
Continue ([y]/n)?
Updating Sun Ray Data Store schema ...
Updating Sun Ray Data Store ACL's ...
Creating Sun Ray Data Store ...
Restarting Sun Ray Data Store ...
Starting Sun Ray Data Store daemon .
Tue Jul 1 09:20 : utdsd starting
Loading Sun Ray Data Store ...
Executing '/usr/bin/ldapadd -h srss-bismarck-gamma -x -p 7012 -D
cn=admin,o=utdata' ...
ldap_bind: Invalid credentials (49)
--
(ditto to this 18 times)
--
Added 18 new LDAP entries.
Creating Sun Ray Core Services Configuration ...
You have chosen to configure this server for a failover group.
All servers in a failover group must share a unique signature,
which is a string of 8 or more characters where at least two
characters are letters and at least one is not.
Enter signature:
Re-enter signature:
Restarting Sun Ray Data Store ...
Stopping Sun Ray Data Store daemon
Sun Ray Data Store daemon stopped
Starting Sun Ray Data Store daemon .
Tue Jul 1 09:21 : utdsd starting
Adding user admin ...
Failed to add user(s) to the list
ERROR: Could not retrieve policy.
ERROR: Could not retrieve policy.
***********************************************************
The current policy has been modified. You must restart the
authentication manager to activate the changes.
***********************************************************
-=-=-=-
> 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.
That is a definite load off of my mind. With what I've seen of
calendar and the other commsuite packages, I kind of figured this.
But any time there are ldap issues my colleages run to me because they
know I set up the authentication.
>> 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.
Again, excellent, and thank you for enlightening me a little more
about the inner workings.
> 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.
There shouldn't be a problem in that case... I only removed a slapd
process because someone had inadvertently set it up when they made a
failed attempt to set up ldap authentication. Nothing else used it,
so that process missing never was part of the problem; our servers
pull the posix information that they need from a centralized server
and syncing backup as far as non-sun LDAP services.
> 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?
I'm not sure; I'll have to look into how DS is configured on our
servers. The person that originally set up the cluster has been gone
from here for some time. I was hired on to learn all of this and I've
only picked up the tidbits that other people knew a bit about. Is
there a config file that I can look in to find out about this?
Thanks for your informative reply, it was much appreciated.
_______________________________________________
SunRay-Users mailing list
[email protected]
http://www.filibeto.org/mailman/listinfo/sunray-users
