Migrating from Sun DSEE & Boolean values question
by Simon Fraser
Hi,
We're planning to migrate to OpenLDAP from Sun Directory Server. So far
the test setup works fine, with one potential problem. Sun's directory
server treats boolean values as case-insensitive, while the RFC (and
OpenLDAP) require upper-case TRUE and FALSE values.
Is there a way of forcing case insensitivity on boolean values with
OpenLDAP, so that any clients who are applying filters like "(foo=true)"
will continue to work? Or is the only way to maintain stats logging and
try to locate particular scripts on the machines that connect, and fix
each one in turn? I realise the former option is not RFC compliant, but
for me, it'll be very convenient to be permissive.
Thanks,
Simon.
--
The Wellcome Trust Sanger Institute is operated by Genome Research
Limited, a charity registered in England with number 1021457 and a
company registered in England with number 2742969, whose registered
office is 215 Euston Road, London, NW1 2BE.
12 years, 1 month
Advise on distributed directory service
by Germ van Ek
Hello,
I am asked to design a replicated OpenLDAP implementation for use on
1500 of our customers servers who are now use a non-replicated
configuration using the standard passwd/shadow backend combined with a
PostgreSQL database. Our customers consist of primary schools and will
use the database for authentication through Samba. The reason we want to
replicate the data is so that we can offer email and other services from
a central datacentre.
Having considered several options ( Multi-Master, MirrorMode ), after
some consulting in our team, I've decided we'll opt for the 'simple'
Master-Slave setup, with a Master at each customer site and 7
(virtualised) servers each handling an everage of 215 customer
databases.
Having 7 servers however has the disadvantage of not knowing on which
server a customer's database will be when a user is trying to
authenticate on their email for example. My first thought was that I
would configure a special 'redirection' server only containing
referrals. I 'hoped' all common clients would cache these referrals so
that load on this redirection server would be low.
I'm now doubting this choice for 2 reasons:
- The following of this referrals seams highly unstandardized. The
biggest users of the referral functionality will probably be PHP, in the
PHP manual the documentation on rebinding / referral chasing is not very
thorough. Any automation of this is also not present, and I would need
to implement any caching myself too. (
http://www.php.net/manual/en/function.ldap-set-rebind-proc.php ) This is
'annoying' for me, but I highly doubt third party applications will all
implement this in a reasonable way, and I was not planning on
customizing all of the software we use...
- In the notes on the documentation of referrals for OpenLDAP 2.4 (
http://www.openldap.org/doc/admin24/referrals.html ), the following note
is present:
Note: the use of referrals to construct a Distributed Directory Service
is extremely clumsy and not well supported by common clients. If an
existing installation has already been built using referrals, the use of
the chain overlay to hide the referrals will greatly improve the
usability of the Directory system. A better approach would be to use
explicitly defined local and proxy databases in subordinate
configurations to provide a seamless view of the Distributed Directory.
Though I am usually very stubborn, I try to avoid designing systems in a
way the documentation says is not recommended.
The use of 1 single proxy cache server seams to 'ease the pain' a bit,
but does not seam like a very scalable approach. The use of
proxy-overlays would make the server the client connects to function as
a kind of non caching proxy, and in general 'be involved' in all of the
requests, which again doesn't seam very desirable, and very
single-point-of-failure.
All servers that are configured (customer servers excluded unless they
opt/pay for it) will be configured in a failover way, I didn't mention
this above to avoid too much complication.
What do you recommend for distributing the databases and still be able
to easily use them? Do I overestimate the amount of traffic/work a
server has in the proxy overlay method?
Germ van Eck
Engineer
Station to Station B.V.
--
12 years, 1 month
complex characters in UID attribute
by Vinay Kalkoti
Hi,
I wanted to know what all complex characters can be included for an
UID attribute.
I have the following user names (uid).
Please let me know which which of the following uid's are invalid -
test_user: IT (LOC)
sup_12$
test_user:IT(LOC)
test_user-IT
test_user IT
test_user:IT
test_user(IT)
test_user.IT
test_user/IT
test_user/IT
test_user#IT
test_user*IT
test_user@IT
Thanks,
Vinay
12 years, 1 month
OpenLDAP performances on AIX?
by Marco Pizzoli
Hi all,
on the same line of previous mail about openldap performances on Solaris, I
would like to know if someone has experience about AIX.
I'm evaluating a deploy on this platform and I would like to know about any
performance comparison/experience between AIX (5.3/6.1/7.1) and Linux.
Thanks in advance
Marco
--
_________________________________________
Non è forte chi non cade, ma chi cadendo ha la forza di rialzarsi.
Jim Morrison
12 years, 1 month
Re: Poor performance on Solaris
by jekvb＠gmx.co.uk
<quote Quanah>
Some time ago, I did benchmarks of Linux 2.6 vs Slowaris-x86 on identical
hardware, and it still was noticeably slower, although not as bad as when
using the sparc architecture.
<quote Quanah />
Could you state what Solaris-x86 version that was?
Thanks, Kuba
----- Original Message -----
From: Quanah Gibson-Mount
Sent: 24/02/11 07:28 PM
To: Juergen.Sprenger(a)swisscom.com, openldap-technical(a)openldap.org
Subject: Re: Poor performance on Solaris
--On Thursday, February 24, 2011 3:53 PM +0100 Juergen.Sprenger(a)swisscom.com wrote: > Hi, > > we had some performance issues on our ldap servers running Solaris 10 > sparc. > > I did some tests using slamd http://www.slamd.com/ and got disturbing > results: > > ldap-service: OpenLDAP 2.4.23, setup identical on both boxes, threads=64, > identical content. > > box1: > hardware: Sun Microsystems sun4v SPARC Enterprise T5120 > memory:32 GB RAM > os: Solaris 10 s10s_u9wos_14a > searches (avg/second): 1521 Slowaris is always tedious with OpenLDAP. At a previous job, I was able to replace 9 slowaris boxes with 4 linux boxes, and even then, just one of the Linux boxes could handle the complete load it took the 9 slowaris boxes to run. I will note that if you are going to use slowaris, I highly advise you set a memory key rather than using on disk cache for BDB if your DB is any size over about 4 GB. Other than that, you'll generally just have to deal with the fact it will be significantly slower than Linux. Some time ago, I did benchmarks of Linux 2.6 vs Slowaris-x86 on identical hardware, and it still was noticeably slower, although not as bad as when using the sparc architecture. --Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration
12 years, 1 month
Re: Poor performance on Solaris
by Omer Faruk SEN
Hi,
I totally agree with you about Solaris + OpenLdap issues. Just use
Linux if you will use openldap if possible of course ..
Regards.
On Thu, Feb 24, 2011 at 8:28 PM, Quanah Gibson-Mount <quanah(a)zimbra.com> wrote:
> --On Thursday, February 24, 2011 3:53 PM +0100 Juergen.Sprenger(a)swisscom.com
> wrote:
>
>> Hi,
>>
>> we had some performance issues on our ldap servers running Solaris 10
>> sparc.
>>
>> I did some tests using slamd http://www.slamd.com/ and got disturbing
>> results:
>>
>> ldap-service: OpenLDAP 2.4.23, setup identical on both boxes, threads=64,
>> identical content.
>>
>> box1:
>> hardware: Sun Microsystems sun4v SPARC Enterprise T5120
>> memory:32 GB RAM
>> os: Solaris 10 s10s_u9wos_14a
>> searches (avg/second): 1521
>
> Slowaris is always tedious with OpenLDAP. At a previous job, I was able to
> replace 9 slowaris boxes with 4 linux boxes, and even then, just one of the
> Linux boxes could handle the complete load it took the 9 slowaris boxes to
> run.
>
> I will note that if you are going to use slowaris, I highly advise you set a
> memory key rather than using on disk cache for BDB if your DB is any size
> over about 4 GB. Other than that, you'll generally just have to deal with
> the fact it will be significantly slower than Linux.
>
> Some time ago, I did benchmarks of Linux 2.6 vs Slowaris-x86 on identical
> hardware, and it still was noticeably slower, although not as bad as when
> using the sparc architecture.
>
> --Quanah
>
>
> --
>
> Quanah Gibson-Mount
> Sr. Member of Technical Staff
> Zimbra, Inc
> A Division of VMware, Inc.
> --------------------
> Zimbra :: the leader in open source messaging and collaboration
>
12 years, 1 month
idle_timelimit - idletimeout - nscd
by ldap＠mm.st
We run a few ldap servers (RH5, openldap 2.3) for our Linux systems to
authenticate against. Using the netstat command we notice that a large
number of established connections are always present on our ldapservers.
We currently do not use idle_timelimit in any of the client ldap.conf
files and we also do not use idletimeout in slapd.conf on our servers.
We have seen a few remarks stating that if idletimeout is used in slapd
that it may adversely affect replications.
We are trying to decide if we should use the server based idletimeout or
the client idle_timelimit to close the idle connections. Any
recommendations? If so, what are some sane values to start with?
We currently do not use ncsd on the clients, but are considering it if
that makes a difference in the above settings.
12 years, 1 month
Multiple certificates
by Yann CUEFF
Hello,
I have an 2.4.21 openldap server with Thawte/Verisign SSL server
certificates.
I created self signed certificates and everything is OK when I replace
Thawte/Verisign SSL certificates with self signed certificates.
I concatenated my authority certificate to client certificate and clients
could negociate with openldap server.
Do you now if it is possible to use both server certificates ?
I tried to concatenate self signed certificates to Thawte/Verisign SSL
certificates, openssl restart correctly but ldap clients did not negociate
correctly with openldap server.
Regards,
Yann
Ce message et toutes les pièces jointes (ci-après le 'Message') sont établis à l'intention exclusive des destinataires et les informations qui y figurent sont strictement confidentielles. Toute utilisation de ce Message non conforme à sa destination, toute diffusion ou toute publication totale ou partielle, est interdite sauf autorisation expresse.
Si vous n'êtes pas le destinataire de ce Message, il vous est interdit de le copier, de le faire suivre, de le divulguer ou d'en utiliser tout ou partie. Si vous avez reçu ce Message par erreur, merci de le supprimer de votre système, ainsi que toutes ses copies, et de n'en garder aucune trace sur quelque support que ce soit. Nous vous remercions également d'en avertir immédiatement l'expéditeur par retour du message.
Il est impossible de garantir que les communications par messagerie électronique arrivent en temps utile, sont sécurisées ou dénuées de toute erreur ou virus.
____________________________________________________
This message and any attachments (the 'Message') are intended solely for the addressees. The information contained in this Message is confidential. Any use of information contained in this Message not in accord with its purpose, any dissemination or disclosure, either whole or partial, is prohibited except formal approval.
If you are not the addressee, you may not copy, forward, disclose or use any part of it. If you have received this message in error, please delete it and all copies from your system and notify the sender immediately by return message.
E-mail communication cannot be guaranteed to be timely secure, error or virus-free.
12 years, 1 month
pcache / proxy overlay
by Mauro Parra
Hello,
is there any document besides the Kumar's article about the openLDAP proxy
cache? Specially a howto about configuring the service.
Saludos,
M
--
Saludos,
Mauro Parra-Miranda
Consultor Senior Novell - mparra(a)novell.com
openSUSE Developer - mauro(a)openSUSE.org
BB PIN - 22600AE9
12 years, 1 month
