At 06:41 PM 1/12/2007, Prakash Velayutham wrote:
>I think this should be achievable by some combination of referral and
>the OpenLDAP directory design. I just can't seem to get the right idea,
>though. Any suggestions/pointers?
Assuming the client has no mechanism to determine which
server to use,
Hello All,
I have a requirement for a new infrastructure we are building.
Our organization has a AD holding all employees' account. I maintain a
separate OpenLDAP server with other users' that are not employees. Both
the groups (employees and non-employees) need access to a group of
Linux/Windows
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On
> Behalf Of Simon Maier
> Sent: Thursday, January 11, 2007 8:32 AM
> To: openldap-software@openldap.org
> Subject: Question about multiple Backends
>
> Hi,
>
> I have a tricky Question, at least I think it ist.
--On Friday, January 12, 2007 5:09 PM -0600 "Jeremy M. Guthrie"
<[EMAIL PROTECTED]> wrote:
I've nailed this down quite a bit now. It appears that 'replica:
192.168.247.130:XXX' is not making it in regardless of ldap or ldaps. I
was able to reproduce the issue in a VMWARE set of hosts wher
I've nailed this down quite a bit now. It appears that 'replica:
192.168.247.130:XXX' is not making it in regardless of ldap or ldaps. I was
able to reproduce the issue in a VMWARE set of hosts where I could restart
from scratch. Soon as I add the line, it works like it should with ldap and
I see that slapd does not actually write the 'replica: 192.168.247.130:389'
line to the ldif entries it puts in the 'reglogfile'. So that looks like the
source for one issue.
On Friday 12 January 2007 14:46, Quanah Gibson-Mount wrote:
> --On Friday, January 12, 2007 2:34 PM -0600 "Jeremy M. G
oh... sorry... I meant to change the 389 to 636 as well.
replica uri=ldaps://192.168.247.130:636/
to
replica uri=ldap://192.168.247.130:389/
On Friday 12 January 2007 14:46, Quanah Gibson-Mount wrote:
> --On Friday, January 12, 2007 2:34 PM -0600 "Jeremy M. Guthrie"
>
> <[EMAIL PROTECTED]> wrote
--On Friday, January 12, 2007 2:34 PM -0600 "Jeremy M. Guthrie"
<[EMAIL PROTECTED]> wrote:
So more information about my problem:
if I change:
replica uri=ldaps://192.168.247.130:389/
to
replica uri=ldap://192.168.247.130:389/
THEN I get a slightly different replication log created by Slurpd.
So more information about my problem:
if I change:
replica uri=ldaps://192.168.247.130:389/
to
replica uri=ldap://192.168.247.130:389/
THEN I get a slightly different replication log created by Slurpd. However,
when I examine that file, it is missing:
replica: 192.168.247.130:389
If I kill slu
Simon Maier wrote:
>
> I have a tricky Question, at least I think it ist. At the computing
> center of our university we use a groupware (openxchange). This
> gropware needs a LDAP server with write access. For this reason it
> can't be integrated into the centralised LDAP of the university. Still
Ralf Haferkamp wrote:
Is that really possible in OpenLDAP 2.3 from the man-page I only see that you
can configure it in a way that only successful operations are
logged "logsuccess TRUE", but "logsuccess FALSE" will log everything (failed
and successful)
Am I overlooking something?
You're r
I moved replogfile down at the bottom but 'no go'. I still do not see a TCP
connection from the 192.168.247.129 host to the 192.168.247.130 host. I
don't even see an attempt to form a connection.
begin replication thread for 192.168.247.130:636
new work in /var/lib/ldap/replog/ldap.binc-groups
I'm currently using ppolicy in a replicated 2.3.30 environment. Most
things wrt ppolicy work extremely well but I'm having issues with slurpd
and ppolicy's internal attributes.
Due to firewall restrictions I'm currently forced to use both syncrepl and
slurpd for replication. Problem with slurpd is
On Thursday 11 January 2007 16:37, Pierangelo Masarati wrote:
> Andreas Taschner wrote:
> > We have a setup with a very high number of binds, so running with
> > loglevel 256 floods the log file. According to
> > http://www.openldap.org/lists/openldap-software/200205/msg00120.html John
> > Dalbec w
But what about the fact that I can't login to openldap with anything
other than anyonymous? :(
Thanks and Kind Regards,
Ian Moroney
Field Engineer
T: 020 8891 3010
M: 07791 965924
F: 020 8288 2591
www.techdivision.co.uk
TechDivision - Making IT Work
-Original Message-
From: Piera
Does this patch enhance the "sync" loglevel, or do I need to enable
something else? I currently have "loglevel config sync". Or do I need to put
a special config switch in at build time?
Yes, the statements are debug_sync, for the provider.
Am I right in thinking that with "syncprov-checkpoint
Ian Moroney wrote:
But what about the fact that I can't login to openldap with anything
other than anyonymous? :(
From what you posted earlier, you can't login because you supply
invalid credentials, in the form of a string that doesn't conform to DN
syntax where a DN is expected.
p.
In
17 matches
Mail list logo
