dITStructureRules/nameForms in subschema subentry for informational purpose
by Michael Ströder
HI!
Discussed this very briefly with Howard at LDAPcon 2007 based on an idea
of Steve:
Support for dITStructureRules and nameForms is still in OpenLDAP's TODO.
In the meanwhile slapd could accept definitions for both in slapd.conf
and simply pass them on to a schema-aware LDAP client for informational
purpose without enforcing them. Same function like rootDSE <file> in
slapd.conf.
Opinions?
Ciao, Michael.
--
Michael Ströder
E-Mail: michael(a)stroeder.com
http://www.stroeder.com
14 years, 2 months
managing OpenLDAP / back-config
by Ralf Haferkamp
With the great features that back-config provides to configure OpenLDAP
servers at runtime it seems logical to start thinking about providing tools
that could help to leverage those features.
Currently to manage an OpenLDAP server through back-config you have the option
to use either a generic LDAP Browser (JXplorer, Apache LDAP Studio,
web2ldap), the OpenLDAP command line tools (ldapsearch, ldapmodify, ...) or
homegrown software using one of the available LDAP APIs. I think it would be
helpful to have some more sophisticated management tools (Commandline and/or
GUI).
In order to get there I think it could be helpful to create an API dedicated
to provide an easy way to access the OpenLDAP configuration (databases,
overlays, schema, access control, ...). This API could then be used to create
different flavors of management tools.
I have not yet spend too much time thinking about the design of such an API.
Neither about the programming language that I'd use to implement something
like this (Python, C, C++, ?). I first like to get a feeling how others think
about this and if anybody is interested in collaborating on such an API. So
please feel free to reply with your comments and suggestions :)
--
regards,
Ralf
14 years, 11 months
OpenLDAP Developer's Day - Dublin 2008 (early call for participation)
by Howard Chu
The OpenLDAP Project is tentatively planning on hosting
a developers' day conference in Dublin, Ireland in late July / early August
(most likely weekend of August 2-3, and August 4).
Those interested in speaking at the conference are
encouraged to contact <project(a)openldap.org> with a
specific proposal (title, abstract, duration). Discounts
will be available to speakers.
A formal (and more widely distributed) call for participation
will be made once conference details are firmed up a bit
(like we fix the date...).
Organizations interested in sponsoring this event are
encouraged to contact project(a)openldap.org. Currently we've
got an agreement with HEAnet to host the event, and Symas will
be sponsoring some of the activity.
At the moment it's been suggested that we conduct two
events - an ODD conference with presentations as we've done
in the past, and also a code-sprint where we all grind thru
a bunch of code together.
Feel free to email me with suggestions.
--
-- Howard Chu
Chief Architect, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
15 years, 1 month
Re: commit: ldap/servers/slapd/overlays auditlog.c
by Pierangelo Masarati
Rein Tollevik wrote:
>> On a slightly related note, but I only noticed because it's near the
>> patched lines - if sizeof(time_t) != sizeof(long) then the fprintf
>> argument is going to break. I think you should simply keep stamp
>> declared as long and let the compiler promote the return value from
>> slap_get_time() if it needs to.
>
> Yes, that is a potential problem that should be fixed. Although I would
> prefer it as an explicit cast, as that imho must better tells the random
> reader that the programmer har thought about it. I.e, to keep stamp as
> a long variable and cast the slap_get_time() return value, or as I would
> prefer it to cast the stamp argument in the fprintf statements.
I've fixed it the other way. I prefer to use types as they should, and
only cast them for printing reasons, to make clear where the "hack" is.
In this case, the sole purpose was printing it, so it would have been
fine the other way 'round as well, though.
p.
Ing. Pierangelo Masarati
OpenLDAP Core Team
SysNet s.r.l.
via Dossi, 8 - 27100 Pavia - ITALIA
http://www.sys-net.it
---------------------------------------
Office: +39 02 23998309
Mobile: +39 333 4963172
Email: pierangelo.masarati(a)sys-net.it
---------------------------------------
15 years, 2 months
Re: commit: ldap/servers/slapd/overlays auditlog.c
by Howard Chu
ando(a)OpenLDAP.org wrote:
> Update of /repo/OpenLDAP/pkg/ldap/servers/slapd/overlays
>
> Modified Files:
> auditlog.c 1.17 -> 1.18
>
> Log Message:
> avoid system call when not needed (ITS#5441)
On a slightly related note, but I only noticed because it's near the patched
lines - if sizeof(time_t) != sizeof(long) then the fprintf argument is going
to break. I think you should simply keep stamp declared as long and let the
compiler promote the return value from slap_get_time() if it needs to.
--
-- Howard Chu
Chief Architect, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
15 years, 2 months
commit sizes, coding conventions, and back-ldif
by Hallvard B Furuseth
My patch to back-ldif/ldif.c for ITS#5408 is larger than the ldif.c file
itself, which has left me wondering what to do with monster pathces:
Should they be split up in stepwise commits so it's easier to see the
logic of each change? When reading patches, I vastly prefer them split
up that way, but I don't know how much that is worth in the CVS tree.
E.g. first a commit which preserves the program logic including bugs and
just moves code around, then one with a bugfix which now can be small
and easy to read, then one for the next bug, and so on.
Besides being more work, one problem with that approach is that one
can make an error in an poorly tested intermediate version - since that
version was never intended to be used anyway. Also I don't know what
impact it has on CVS merging.
Also, what's the thereshold for when it makes sense to reformat and
rearrange code just for the sake of readability? back-ldif ihas no
consistent coding style. Normally it's "don't reformat, it makes CVS
merges harder". In this case it was easy with some of it - I touch more
than half of the lines anyway, so I could just as well reformat those
and a few more to something closer to the OpenLDAP conventions (to the
degree I understand them). But maybe in this case I should just as well
reformat it all, and maybe also it's a good time time to split back-ldif
up in 9 files of ~100-300 lines instead of one of ~1500 lines.
(Regarding CVS merges, the HEAD and RE24 versions are equal, but RE23
differs.)
Another extreme example was a recent change to a big chunk of code,
where the only change was to wrap the code in a new if-test and indent
it. It would have been nice with a a comment in the commit, or a 1-line
commit + a cosmetic commit.
Regarding formatting, when I do it I'd prefer to do it right - but I've
never quite figured out what the preferred conventions are. We've had a
style threads before but I don't remember if any of them got very far.
So I thought I'd list some rules and confusions of my own that I've
noticed.
* Generous whitespace:
- Around parens in control statements - "if ( x )" etc.
- Inside non-empty parens in function calls, sometimes sizeof,
sometimes inside [].
- Usually around binary operators.
However often but not always whitespace between two parens are omitted -
e.g. "foo( bar( baz ))". Is there some preferred guideline about that?
How about whitespace around parens that are for grouping?
E.g. "if ( (ch = getc(f)) != EOF )".
* Similarly generous use of {} for if statements etc, usually used even
when enclosing just a single statement.
* Indent 1 tab for continuation lines with the same paren level, e.g.
x = foo(
bar, baz );
y = one
? two
: three;
BTW, emacs will format this the OpenLDAP way:
wups(
foo, bar );
but if there is anything after the '(' it aligns bar with it:
wups( foo,
bar );
OpenLDAP code often does put arguments after the '(' but to my eyes it
looks easier to read without that, in addition to making emacs happy.
Complex multi-line statements require more creativity, but I can't
tell what, if any, ideas lie behind their indentation (beyond trying
to avoid such statements). Don't know if e.g. this is OpenLDAPpy:
if ( (one( two,
three ) &&
(four ||
(five &&
six))) )
* Tab-width = 4 columns. Makes a difference for when to break lines
(keeping line length < 80), how to align comments after code on a
line, and to align declarations and multi-line statements.
It doesn't hurt to try to keep code nice-looking with tab width 8 too.
(E.g. comments above statements instead of aligned to the right, and
often do not align variables in declarations.)
* Indent with tabs, not spaces.
* Usually align comments/decls to the right of code with tabs too, but
not always. (If we used space to align after code, it would stay
aligned regardless of tab-width.)
* Function names at first column in function definitions.
--
Hallvard
15 years, 2 months
printing Sleepycat version always
by Aaron Richton
[purposefully on -devel for discussion]
Any opinions on:
--- init.c~ 2008-03-12 10:02:44.000000000 -0400
+++ init.c 2008-03-12 10:03:16.000000000 -0400
@@ -712,7 +712,7 @@
return -1;
}
- Debug( LDAP_DEBUG_TRACE, LDAP_XSTRING(bdb_back_initialize)
+ Debug( LDAP_DEBUG_ANY, LDAP_XSTRING(bdb_back_initialize)
": %s\n", version, 0, 0 );
}
I'm definitely one for 'quiet' software, but knowing the version of libdb
is a really nice detail when assisting users of OpenLDAP. This would make
it that much easier to have them find it. I'd argue there's a bit of
precedent:
main.c: Debug( LDAP_DEBUG_ANY, "%s", Versionstr, 0, 0 );
The negative, of course, is the noise. But what's ~60 bytes in this day
and age?
15 years, 2 months
glue overlay man page needed?
by Gavin Henry
Hi all,
There is no configuration for the glue overlay other than "overlay glue"
in the right place.
So would there be a point having a man page? The only mention of the glue
overlay is in the slapd.conf man page.
Thanks,
Gavin.
15 years, 2 months
Re: slapd new backend
by Malcolm Cowen
"My first question is why a new backend? Why are you doing it if you've
never seen OpenLDAP code before?"
They want it to link to a product of theirs, on a particular product and
platform where we do have significant experience.
(I can't give details because of commercial confidenciality - although
Client does understand the open source nature of OpenLDAP)
"[Read] the source" - Of course
Malcolm Cowen, Software Developer, Cowen Software Ltd:
21-23 Bristol Ave, Levenshulme, Manchester, GB- M19 3NU, UK
+44 (0) 161 225 4674 (office) +44 (0) 7973 950 597 (mobile)
Registered in England No: 1828889, VAT Reg 403 4867 60
www.cowensw.co.uk, www.cowensw.com, email: mct(a)cowensw.co.uk
15 years, 2 months
