On 3/7/2011 2:18 πμ, Howard Chu wrote:
We've been discussing this problem (ACL rule descriptions) for quite a
while. My current thinking is that somehow we can use attribute
options to help. Visually it might be better to associate the option
with the original attribute, e.g.
olcAccess:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 10/19/2011 12:50 PM, Howard Chu wrote:
Read http://highlandsun.com/hyc/drafts/draft-chu-ldap-xordered-xx.html
I would like to point out that while back-ldif handles the ordering
prefix fine, bconfig's (bconfig.c:4726) implementation of the same
Ondrej Kuznik wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 10/19/2011 12:50 PM, Howard Chu wrote:
Read http://highlandsun.com/hyc/drafts/draft-chu-ldap-xordered-xx.html
I would like to point out that while back-ldif handles the ordering
prefix fine, bconfig's (bconfig.c:4726)
Nick Milas wrote:
On 3/7/2011 2:18 πμ, Howard Chu wrote:
We've been discussing this problem for quite a while. My current
thinking is that somehow we can use attribute options to help.
Visually it might be better to associate the option with the original
attribute, e.g.
olcAccess:
On 04/07/2011 00:32, Nick Milas wrote:
olcAccess: to attrs=member,entry
by dnattr=member selfwrite
description;x-olcAccess: (0) Access rules for attrs: member,entry
description;x-olcAccess: (0) Entered by Nick on 7/12/2012
olcAccess: to dn.children=dc=example,dc=com
by * search
On 03/07/2011 14:21, Howard Chu wrote:
What you call a deficiency(sp) is sheer nonsense. Tell me how you expect
to provide read/write database access to a file included from any
arbitrary filesystem location? Think about the safety of such a
proposition as well; not everybody has AppArmor or
Howard Chu wrote:
I note that the accesslog overlay already allows you to track the history of
individual changes to attributes, so recording an Entered by name on
date comment seems both redundant and vague.
I really like slapo-accesslog and the audit trail it provides. Feature
request:
Howard Chu wrote:
Michael Ströder wrote:
There's no mechanism like include.
False. OpenLDAP's LDIF library supports include directives, and they're used
frequently in the test suite. The include statement has been documented in the
ldif(5) manpage since 2006.
How do you use this
Michael Ströder wrote:
Howard Chu wrote:
Michael Ströder wrote:
There's no mechanism like include.
False. OpenLDAP's LDIF library supports include directives, and they're used
frequently in the test suite. The include statement has been documented in the
ldif(5) manpage since 2006.
How do
Chan Wilson wrote:
On Wed, Jun 29, 2011 at 5:26 AM, Mark Cave-Ayland
mark.cave-ayl...@siriusit.co.uk mailto:mark.cave-ayl...@siriusit.co.uk
wrote:
Hi all,
Having started to look at the changes required to migrate from a
slapd.conf setup to a cn=config setup, one of things I'm
Il 02/07/2011 00:47, Christopher Wood ha scritto:
What stops you from checking the ldif of cn=config into revision control
before and after a change?
Complexity, because you have to add more steps to have less
informations. I don't think there are comments inside cn=config, and
those are very
Christopher Wood wrote:
What stops you from checking the ldif of cn=config into revision control
before and after a change?
Nothing. But it's more cumbersome. Also comments are lost. Normally I comment
everything and describe for which requirement in the concept the ACLs,
constraints, etc. are
On 2/7/2011 2:53 μμ, Simone Piccardi wrote:
...
I don't think there are comments inside cn=config, and
those are very important when you have to document and track tens of
different installations.
Indeed, it seems that the config schema does not include a description
(or similar) attribute
Nick Milas wrote:
On 2/7/2011 2:53 μμ, Simone Piccardi wrote:
I don't think there are comments inside cn=config, and
those are very important when you have to document and track tens of
different installations.
Indeed, it seems that the config schema does not include a description (or
--On Saturday, July 02, 2011 1:36 PM -0500 Chan Wilson
chanwil...@gmail.com wrote:
And recognizing that emergencies *do* happen, and having a Plan of Action
is key to responding to emergencies correctly, what *is* the proper way
to manually edit cn=config? Particularly in a replicated RTC
Chan Wilson wrote:
The ability to do manual disaster-recovery/emergency config changes is
crucial. But you also have to understand that going this route is for
*emergencies* - it is not the way to go for routine administrative tasks.
One item I've always wondered about the RTC
Michael Ströder wrote:
Nick Milas wrote:
On 2/7/2011 2:53 μμ, Simone Piccardi wrote:
I don't think there are comments inside cn=config, and
those are very important when you have to document and track tens of
different installations.
Indeed, it seems that the config schema does not include a
zeno:/tmp# ldapadd -D 'cn=admin,dc=siriusit,dc=co,dc=uk' -f
sirius-custom.ldif -xW
Enter LDAP Password:
adding new entry cn=schema,cn=config
ldap_add: Constraint violation (19)
additional info: structuralObjectClass: no user modification
allowed
Hi Mark,
How did you generate your
On Wed, Jun 29, 2011 at 5:26 AM, Mark Cave-Ayland
mark.cave-ayl...@siriusit.co.uk wrote:
Hi all,
Having started to look at the changes required to migrate from a slapd.conf
setup to a cn=config setup, one of things I'm struggling with is how to load
new LDAP schemas into cn=config.
On 29/06/11 18:05, Quanah Gibson-Mount wrote:
Although I'm not sure exactly how this is going to work since elements of
slapd.conf are still required to bootstrap the directory from LDAP
.schema files. Hmmm.
Zimbra puts cn=config in the same location as any other LDAP database we
use
On Wednesday, 29 June 2011 16:15:54 Daniel Qian wrote:
On 11-06-29 9:26 AM, Mark Cave-Ayland wrote:
On 29/06/11 12:59, Howard Chu wrote:
Thanks for the response - this makes a bit more sense now. Just to
clarify another point: when you generate schemaConvert.conf, I guess
that you need to
On 29/06/2011 18:30, Mark Cave-Ayland wrote:
On 29/06/11 16:56, Simone Piccardi wrote:
Then I think you must be flamed too...
But if you did so, then why just not to stay with slapd.conf?
It still work and is far easier to understand and manage.
Because slapd.conf is deprecated and going
On 30/06/2011 19:18, Quanah Gibson-Mount wrote:
Again, I urge people to file bug reports etc with distributions when
they find issues like these. I do this fairly often with Debian/Ubuntu.
As I said I already filed a bug for Debian, is here:
Hi all,
Having started to look at the changes required to migrate from a
slapd.conf setup to a cn=config setup, one of things I'm struggling with
is how to load new LDAP schemas into cn=config.
I've seen the guides similar to this one here:
Mark Cave-Ayland wrote:
Hi all,
Having started to look at the changes required to migrate from a
slapd.conf setup to a cn=config setup, one of things I'm struggling with
is how to load new LDAP schemas into cn=config.
I've seen the guides similar to this one here:
On 29/06/11 11:59, Howard Chu wrote:
Having started to look at the changes required to migrate from a
slapd.conf setup to a cn=config setup, one of things I'm struggling with
is how to load new LDAP schemas into cn=config.
I've seen the guides similar to this one here:
Mark Cave-Ayland wrote:
On 29/06/11 11:59, Howard Chu wrote:
Having started to look at the changes required to migrate from a
slapd.conf setup to a cn=config setup, one of things I'm struggling with
is how to load new LDAP schemas into cn=config.
I've seen the guides similar to this one here:
On 29/06/11 12:59, Howard Chu wrote:
Thanks for the response - this makes a bit more sense now. Just to
clarify another point: when you generate schemaConvert.conf, I guess
that you need to include *all* schemas in your current cn=config
matching the existing order, as well as the new one you
Mark Cave-Ayland wrote:
On 29/06/11 12:59, Howard Chu wrote:
Thanks for the response - this makes a bit more sense now. Just to
clarify another point: when you generate schemaConvert.conf, I guess
that you need to include *all* schemas in your current cn=config
matching the existing order, as
On 11-06-29 9:26 AM, Mark Cave-Ayland wrote:
On 29/06/11 12:59, Howard Chu wrote:
Thanks for the response - this makes a bit more sense now. Just to
clarify another point: when you generate schemaConvert.conf, I guess
that you need to include *all* schemas in your current cn=config
matching
On 29/06/11 14:42, Howard Chu wrote:
You only need to load those 4 schema files if your sirius-custom.schema
file actually depends on all of them. The ordering prefix only needs to
be {4} if you really need those others to be parsed first. Otherwise the
prefix can be deleted and the config
On 29/06/11 15:15, Daniel Qian wrote:
Not sure if it is the same on Debian but on Fedora I only copied the
workplace output schema file (autofs.schema in my case) to
/etc/openldap/slapd.d/cn=config/cn=schema/ without modifying anything. I
restarted slapd after that and everything worked for me.
On 11-06-29 10:49 AM, Mark Cave-Ayland wrote:
On 29/06/11 15:15, Daniel Qian wrote:
Not sure if it is the same on Debian but on Fedora I only copied the
workplace output schema file (autofs.schema in my case) to
/etc/openldap/slapd.d/cn=config/cn=schema/ without modifying anything. I
restarted
On 29/06/2011 16:46, Mark Cave-Ayland wrote:
I have been honest enough during this thread to admit that I felt I may
have missed something obvious. But I have to point out that all of the
Google searches I have done on this topic have returned posts similar to
the one I pointed you to, which
On 29/06/2011 16:15, Daniel Qian wrote:
Not sure if it is the same on Debian but on Fedora I only copied the
workplace output schema file (autofs.schema in my case) to
/etc/openldap/slapd.d/cn=config/cn=schema/ without modifying anything. I
restarted slapd after that and everything worked for
On 29/06/11 16:50, Simone Piccardi wrote:
I think that putting the cn=config backend in some other directory
instead of /etc/ldap/slapd.d (that's for Debian, don't know for other
distributions) could help a lot.
Most sysadmin expect to find text configuration files under /etc, not a
kind of
On 11-06-29 11:56 AM, Simone Piccardi wrote:
On 29/06/2011 16:15, Daniel Qian wrote:
Not sure if it is the same on Debian but on Fedora I only copied the
workplace output schema file (autofs.schema in my case) to
/etc/openldap/slapd.d/cn=config/cn=schema/ without modifying anything. I
On 29/06/11 16:56, Simone Piccardi wrote:
Then I think you must be flamed too...
But if you did so, then why just not to stay with slapd.conf?
It still work and is far easier to understand and manage.
Because slapd.conf is deprecated and going away in openldap 2.5. So I'd
like to get
On 11-06-29 12:28 PM, Mark Cave-Ayland wrote:
On 29/06/11 16:50, Simone Piccardi wrote:
I think that putting the cn=config backend in some other directory
instead of /etc/ldap/slapd.d (that's for Debian, don't know for other
distributions) could help a lot.
Most sysadmin expect to find text
--On Wednesday, June 29, 2011 5:30 PM +0100 Mark Cave-Ayland
mark.cave-ayl...@siriusit.co.uk wrote:
On 29/06/11 16:56, Simone Piccardi wrote:
Then I think you must be flamed too...
But if you did so, then why just not to stay with slapd.conf?
It still work and is far easier to understand
--On Wednesday, June 29, 2011 12:51 PM -0400 Daniel Qian
dan...@up247solution.com wrote:
Question is why the /etc/openldap/slapd.d file structure is there for
users to edit in the first place? Wouldn't it be even more misleading if
the running one is modified on the fly while the one in
41 matches
Mail list logo
