masar...@aero.polimi.it wrote:
Ok, fair warning - this is a little long-winded, but I'd rather give too
much detail than not enough. Also, all
examples are in slapd.conf format, since there is no documentation for
cn=config, and I'm using slapd with -f and -F to
make the conversion.
masar...@aero.polimi.it wrote:
masar...@aero.polimi.it wrote:
In this case, dscl (Mac OS X's directory services client) expects a UID,
not a DN, as is the POSIX standard for group
members, and doesn't know how to parse usernames in groups that use DN's
to identify their members. Instead,
masar...@aero.polimi.it wrote:
masar...@aero.polimi.it wrote:
masar...@aero.polimi.it wrote:
No, I know the difference. What I'm saying is that the OS X clients
aren't translating DN-valued LDAP group membership
attributes to UID-valued POSIX group memberships. On Linux, this is done
, or would like some help.
Thanks for any and all advice, musings, criticisms, and opinions!
-Ryan
--
Ryan Steele
Systems Administrator
AWeber Communications
Quanah Gibson-Mount wrote:
--On Tuesday, April 20, 2010 5:34 PM -0400 Ryan Steele
ry...@aweber.com wrote:
The FAQ indicates that the 'retry' option should be a comma-separated
list: http://www.openldap.org/faq/data/cache/1118.html
However, all of the examples from the section
The FAQ indicates that the 'retry' option should be a comma-separated list:
http://www.openldap.org/faq/data/cache/1118.html
However, all of the examples from the section on replication in the Admin Guide
seem to show them as being
space-delimited values:
Hey folks,
As it stands, I've got an environment with six slapd servers (2.4.18) in an
N-Way Multi-Master configuration. At any
given moment, only one of these six nodes is receiving client requests (reads,
writes, etc.). We use Pacemaker to
provide some basic high-availability services, such
at any given time are
performed on only one of them to ensure
consistency? That is, short of doing what I'm doing now (sending ALL traffic
to only one master), which doesn't scale
very well.
Ryan Steele wrote:
Hey folks,
As it stands, I've got an environment with six slapd servers (2.4.18
Howard Chu wrote:
Ryan Steele wrote:
Hey folks,
In order to provide stability to my OpenLDAP clients in the event of a
network outage, I would like to implement some client-side caching.
I've done some research, and have concluded that nscd is evil and
should be avoided at all costs
Hey folks,
In order to provide stability to my OpenLDAP clients in the event of a network
outage, I would like to implement some
client-side caching. I've done some research, and have concluded that nscd is
evil and should be avoided at all costs,
and thus eventually settled on using back-ldap
I actually have two separate questions, both aimed at performance tuning my
database.
The first is about running slapindex on individual cluster members to preserve
high availability. Namely, if each
cluster member is brought offline individually for reindexing (as opposed to
putting them all
Ryan Steele wrote:
I'm not quite sure how to interpret that though, given the results I'm seeing
in my master-master pair. Should the
contextCSN's in the backend database for both SID 001 and SID 002 match?
E.g.:
contextCSN: 20100126210305.876171Z#00#001#00
contextCSN
Rein Tollevik wrote:
Ryan Steele wrote:
I'm replicating both the config and backend databases between two
boxes. Everything seems fine, but for some reason
when I query them both for the contextCSN, the config database returns
only one while the backend database returns two,
as seen below
HRZ Konten wrote:
Hallo all,
we have 2 OpenLDAP 2.4.17 with N-Way Replication on Debian Lenny.
Config
dn: olcDatabase={0}config
objectClass: olcDatabaseConfig
olcDatabase: {0}config
olcRootPW:: x
structuralObjectClass: olcDatabaseConfig
entryUUID:
I'm replicating both the config and backend databases between two boxes.
Everything seems fine, but for some reason
when I query them both for the contextCSN, the config database returns only one
while the backend database returns two,
as seen below:
## ldap1 replication config
Gavin Henry wrote:
- Howard Chu h...@symas.com wrote:
The key element of MirrorMode is that there is an external frontend
that
ensures that all writes are directed to a single server. Otherwise,
there is
no difference.
Should I change the docs for MM? We do writes to a single server
Gavin Henry wrote:
- Ryan Steele ry...@aweber.com wrote:
Hi folks,
I'm in the process of setting up about six nodes, and tossing around
the idea of having either 2 masters in MirrorMode
(traffic to the active master is managed externally) with 4 slaves
(each of whom will refer
Gavin Henry wrote:
- Ryan Steele ry...@aweber.com wrote:
I want to use MirrorMode, but between six nodes instead of two (the
example in the Admin Guide uses three, so I figured
using more than just two nodes was fine). As such, I need an active
master to ensure that two masters don't
Hi folks,
I'm in the process of setting up about six nodes, and tossing around the idea
of having either 2 masters in MirrorMode
(traffic to the active master is managed externally) with 4 slaves (each of
whom will refer their writes to the active
master). I'm automating some of the setup, and
Hi Quanah,
Quanah Gibson-Mount wrote:
This is how filters work in LDAP. It sounds to me like things are
working correctly. I.e., if I search for objectClass=joe objectClass,
it will return every entry that has an objectClass value of joe, and all
the values for objectClass.
If I search
Hi Akihiro,
Akihiro Moriguchi wrote:
cn={3}inetorgperson,cn=schema,cn=config: olcAttributeTypes: Duplicate
attributeType: 2.16.840.1.113730.3.1.1
Sounds to me like you have two schema files which each define the same
attribute (in this case, carLicense). Try
identifying them with something
Brandon Hume wrote:
On Fri, 2009-09-18 at 07:33 -0400, Francis Swasey wrote:
This is getting ridiculous from my perspective. We've had a rash of people
reporting problems
against older releases and being effectively told to go to hell (which is
what we hear when the
development team or
Hey Andreas,
Andreas Hasenack wrote:
On Wed, Sep 16, 2009 at 17:42, Ryan Steele ry...@aweber.com wrote:
query returns nothing:
ldapsearch -x -w SECRET -D cn=admin,dc=example,dc=com -b
cn=testgroup,ou=Groups,dc=example,dc=com -LLL '(uid=user1)'
This filter doesn't look right. Try
Howard Chu wrote:
autogroup isn't supposed to perform any expansion during searches.
That's not what it does.
So, you're saying that dynlist should perform the expansion, and autogroup just
allows you to filter it? The autogroup
man page makes no mention of needing the dynlist module (only
Howard Chu wrote:
Ryan Steele wrote:
Howard Chu wrote:
autogroup isn't supposed to perform any expansion during searches.
That's not what it does.
So, you're saying that dynlist should perform the expansion, and
autogroup
just allows you to filter it?
I'm quite certain I never said any
Hey folks,
I'm trying to debug the cause of faulty module behavior (autogroup) which has
eluded both strace and 'slapd -d 16383'
(and, just as a point of reference, it's slapd 2.4.18 and autogroup 1.8 on
Ubuntu 8.04). So, I'd like to use gdb to
figure out what's going on, but I'm not quite sure
Is the autogroup overlay considered stable for use with versions of OpenLDAP
earlier than 2.4.18? I know it's being
used on earlier versions (as 2.4.18 is not considered stable yet), but I've
also seen some reports of basic search
functionality getting clobbered after doing so. According to
The Hwyman wrote:
I'm running Red Hat Enterprise 5 (x86_64) and Openldap version 2.3.27
from official rpms. I have installed openldap, openldap-devel,
openldap-clients, and openldap-servers.
The following command:
ldapsearch -x -b dc=example,dc=com '(uid=jsmith)'
produces the following
Pierangelo Masarati wrote:
Ryan Steele wrote:
Hey folks,
While researching another problem, I noticed that even on successful
searches (e.g., entries returned that match the filters I set), I see
the following in the logs:
Apr 23 12:45:11 ldapmaster slapd[30294]: send_ldap_result: err=0
Hey folks,
While researching another problem, I noticed that even on successful
searches (e.g., entries returned that match the filters I set), I see
the following in the logs:
Apr 23 12:45:11 ldapmaster slapd[30294]: send_ldap_result: err=0
matched= text=
It almost looks to me like it's saying
Howard Chu wrote:
Chris G. Sellers wrote:
pwdMinAge is part of the password policy, not part of the user's record.
The scheme defines pwdMinAge as being part of the objectClass
pwdPolicy, so unless you have that in your users record, it will not
be there.
I believe you assume correct that
Tony Earnshaw wrote:
My site uses ppolicy with great success.
Ryan Steele skrev, on 08-04-2008 23:35:
I wanted to test the scenario where a user had forgotten his password,
and needed to have it reset. I wanted to give this user the ability
change this temporary password if they wanted
Adam, Howard, and list,
Upon Howard's suggestion, I went and re-read the docs on ACL's for
slapd.conf. What I came up with is the following (I'll change the
first asterisk to the specific attributes once I've actually got it
working...):
# ACL's
access to *
by
configuration
options - pastings inline below:
Howard Chu wrote:
Ryan Steele wrote:
I realize that 'only' is what I want and that's what I'm using, however
I think smbk5pwd is working. The two snippets below are show the
differences after a Windows user changes his password (from the
ctrl+alt+delete
comments below
Howard Chu wrote:
Ryan Steele wrote:
Hey Howard, Adam, and List:
I'm not even sure this is the path I ought to be going down. If
smbk5pwd has no knowledge of ppolicy, and password changes from Windows
clients won't adhere to those restrictions with any combination
Adam Tauno Williams wrote:
I say this because clients joined to the domain (run by a Samba PDC with
an OpenLDAP backend) can change their passwords and it updates the NT/LM
passwords in LDAP, thus verifying the functionality of smk5pwd, but it
does not appear to enforce ppolicy restrictions.
Hello,
I've got the smbk5pwd and ppolicy modules working, but I'm not entirely
sure I've got them working together.
I say this because clients joined to the domain (run by a Samba PDC with
an OpenLDAP backend) can change their passwords and it updates the NT/LM
passwords in LDAP, thus verifying
to say.
replies are inline.
On Tue, 2008-04-01 at 15:46 -0400, Ryan Steele wrote:
Hello,
I've got the smbk5pwd and ppolicy modules working, but I'm not entirely
sure I've got them working together.
I say this because clients joined to the domain (run by a Samba PDC with
an OpenLDAP
Hey folks,
If this is the wrong list, please let me know and I'd be happy to send
it to the right one.
As I've mentioned in a previous post (which hasn't been posted yet, so I
apologize if you've seen any of this information already) I've got a FC6
box, with OpenLDAP 2.3.30. I'm attempting to
Hello,
First let me thank the gracious folks on this list who have lent their
advice to me on my path towards implementing ppolicy. I'm making
progress; I can reject new passwords based on password history, and
reject weak passwords. However, I'm having a bit of a time trying to
get the
40 matches
Mail list logo
