OpenLDAP 2.3.32
How do I move an entry to a new superior without changing the RDN as well? I cannot find any examples of this (at least, none that works).
dn: uid=dhtest,dc=coreng,dc=com,dc=au changeType: modDN newRDN: dhtest deleteOldRDN: 1 newSuperior: ou=systems,dc=coreng,dc=com,dc=au -
Fails with:
ldapmodify: invalid format (line 6) entry: "uid=dhtest,dc=coreng,dc=com,dc=au" Failed to update entry.
as does:
dn: uid=dhtest,dc=coreng,dc=com,dc=au changeType: modDN newRDN: uid=dhtest deleteOldRDN: 1 newSuperior: ou=systems,dc=coreng,dc=com,dc=au -
I already discovered that I need "newRDN" i.e. just "newSuperior" won't cut it.
Or must I use "ldapmodrdn", and risk a race condition if making several changes to the same entry?
Dave Horsfall wrote:
OpenLDAP 2.3.32
How do I move an entry to a new superior without changing the RDN as well? I cannot find any examples of this (at least, none that works).
test006, test007, test017, test018, test019, test032, test040, test043, test045, test046, test048...
Wherever you were looking, you should always start by looking in the source distro itself.
dn: uid=dhtest,dc=coreng,dc=com,dc=au changeType: modDN newRDN: dhtest deleteOldRDN: 1 newSuperior: ou=systems,dc=coreng,dc=com,dc=au -Fails with:
ldapmodify: invalid format (line 6) entry: "uid=dhtest,dc=coreng,dc=com,dc=au" Failed to update entry.
"-" is invalid in a modDN request. And yes, newRDN must be an actual RDN, not just a naked value.
I already discovered that I need "newRDN" i.e. just "newSuperior" won't cut it.
Or must I use "ldapmodrdn", and risk a race condition if making several changes to the same entry?
ldapmodify doesn't do anything different from ldapmodrdn here.
On Mon, 12 Mar 2007, Howard Chu wrote:
How do I move an entry to a new superior without changing the RDN as well? I cannot find any examples of this (at least, none that works).
test006, test007, test017, test018, test019, test032, test040, test043, test045, test046, test048...
Wherever you were looking, you should always start by looking in the source distro itself.
And I completely failed to see the lack of "-", as you pointed out later... And yes, line 6 == "-" should have been a hint.
"-" is invalid in a modDN request. And yes, newRDN must be an actual RDN, not just a naked value.
I'm starting to see too many mistakes in "http://www.zytrax.com/books/ldap/" to trust it now. Or, for that matter, Howes/Smith/Good (1st Ed).
It's working now; thanks.
I was testing a simple "ldapdiff" utility which given "before" and "after" generates the required LDIF operations; I cannot use "ldifdiff.pl" because it requires Net::LDAP which is not a core module.
I hope to get permission to release it; a couple of people have expressed interest in it...
Dave Horsfall wrote:
On Mon, 12 Mar 2007, Howard Chu wrote:
How do I move an entry to a new superior without changing the RDN as well? I cannot find any examples of this (at least, none that works).
test006, test007, test017, test018, test019, test032, test040, test043, test045, test046, test048...
Wherever you were looking, you should always start by looking in the source distro itself.
And I completely failed to see the lack of "-", as you pointed out later... And yes, line 6 == "-" should have been a hint.
"-" is invalid in a modDN request. And yes, newRDN must be an actual RDN, not just a naked value.
I'm starting to see too many mistakes in "http://www.zytrax.com/books/ldap/" to trust it now. Or, for that matter, Howes/Smith/Good (1st Ed).
Only starting? Tim Howes' book was authoritative, a lifetime ago. Living technologies evolve.
The Zytrax stuff looked like a nice effort at first, but as usual, I question the motives. People who genuinely want to help others spend time doing exactly that, in public forums. People who genuinely want to improve the state of the OpenLDAP documentation do exactly that, by contributing docs and patches to the Project. People who sit off in their corner of the world proclaiming their authoritative knowledge about a piece of technology that they otherwise have made no visible contribution to strike me as just being leeches. Even worse when their docs are full of errors.
On a slightly related topic - the first several chapters of my OpenLDAP Administration book will be published on the web in a few months. Even after it comes out on paper, we'll be revising the electronic copy over time. It's somewhat unavoidable that documenting OpenLDAP is a moving target - only dead things stop moving.
It's working now; thanks.
I was testing a simple "ldapdiff" utility which given "before" and "after" generates the required LDIF operations; I cannot use "ldifdiff.pl" because it requires Net::LDAP which is not a core module.
I hope to get permission to release it; a couple of people have expressed interest in it...
On Tue, 13 Mar 2007, Howard Chu wrote:
I'm starting to see too many mistakes in "http://www.zytrax.com/books/ldap/" to trust it now. Or, for that matter, Howes/Smith/Good (1st Ed).
Only starting? Tim Howes' book was authoritative, a lifetime ago. Living technologies evolve.
Some here regard Howes' book as a bible; indeed, it gets recommended from time to time. Is the 2nd edition any better?
The Zytrax stuff looked like a nice effort at first, but as usual, I question the motives. People who genuinely want to help others spend time doing exactly that, in public forums. People who genuinely want to improve the state of the OpenLDAP documentation do exactly that, by contributing docs and patches to the Project. People who sit off in their corner of the world proclaiming their authoritative knowledge about a piece of technology that they otherwise have made no visible contribution to strike me as just being leeches. Even worse when their docs are full of errors.
Which in turn illustrates the dichotomy of the problem: those in the best position to document something i.e. the developers themselves are the very ones who cannot (because they're too busy) or should not (because they are too close to it, and take things for granted). This got drilled into me around 25 years ago, at a DEC device driver course.
On the other hand, Open Source has no official Documentation Department.
On the gripping hand, end-users will document that which they do not understand...
On a slightly related topic - the first several chapters of my OpenLDAP Administration book will be published on the web in a few months. Even after it comes out on paper, we'll be revising the electronic copy over time. It's somewhat unavoidable that documenting OpenLDAP is a moving target - only dead things stop moving.
I'll certainly purchase it.
Dave Horsfall wrote:
Which in turn illustrates the dichotomy of the problem: those in the best position to document something i.e. the developers themselves are the very ones who cannot (because they're too busy) or should not (because they are too close to it, and take things for granted). This got drilled into me around 25 years ago, at a DEC device driver course.
I think that's a false dichotomy. Software has bugs, we file bug reports, and the bugs get fixed. If docs are missing something because a point has been taken for granted, it's no different - someone files a bug report against the doc, and the doc bug gets fixed. The process is always the same, and it's driven by the same thing - user feedback. No bug reports, no fixes.
The point about developers being too busy is only peripherally relevant - everything in the Project was contributed at some point or another. Yes, developers are busy; no, you should not expect "someone else" to contribute everything. If you want something addressed, it's up to you to make it happen.
On the other hand, Open Source has no official Documentation Department.
On the gripping hand, end-users will document that which they do not understand...
Which is why I always harp on these points: 1) don't blindly follow advice that is given without an explanation of the rationale behind the advice. 2) don't give advice without an explanation. 3) don't create documentation in a vacuum - submit it to the Project so that it can be reviewed, corrected, and incorporated.
Easy answers tend to be the least useful in the long run. "RTFM" answers are given for a reason - to make you think, and to make you learn. The problem with most HOWTOs (the ones that aren't completely wrong, anyway) is they tend to just list a sequence of steps, without any explanation of why those steps work, why their particular sequence was chosen, etc.
As a quick example, if you were faced with a black box that takes one number as input and spits out another number as output, and you were given a sample set of inputs and outputs: 1, 2, 3, 4, 5, 6, 7, 8, 9 1, 0, 9, 0, 25, 0, 49, 0, 81 it may not be immediately obvious to you why those outputs are as they are. If someone then asks you "what will be the output for an input of 15" you might be hard-pressed to come up with the answer.
On the other hand, if someone were to tell you "the rule for this black box is that for any even number, the output is zero, and for any odd number, the output is the square of the input" then you can easily apply that rule to any arbitrary input.
HOWTOs without detailed explanations are like the black box with just a short list of data points. They don't teach you anything, they only give you a fixed set of answers to a fixed set of questions. When you're faced with a new question that's not on their list, you're lost.
It's always important to understand the reasons behind the answers.
Howard Chu wrote:
Dave Horsfall wrote:
Which in turn illustrates the dichotomy of the problem: those in the best position to document something i.e. the developers themselves are the very ones who cannot (because they're too busy) or should not (because they are too close to it, and take things for granted). This got drilled into me around 25 years ago, at a DEC device driver course.
I think that's a false dichotomy. Software has bugs, we file bug reports, and the bugs get fixed. If docs are missing something because a point has been taken for granted, it's no different - someone files a bug report against the doc, and the doc bug gets fixed. The process is always the same, and it's driven by the same thing - user feedback. No bug reports, no fixes.
The point about developers being too busy is only peripherally relevant - everything in the Project was contributed at some point or another. Yes, developers are busy; no, you should not expect "someone else" to contribute everything. If you want something addressed, it's up to you to make it happen.
On the other hand, Open Source has no official Documentation Department.
On the gripping hand, end-users will document that which they do not understand...
Which is why I always harp on these points:
- don't blindly follow advice that is given without an explanation
of the rationale behind the advice. 2) don't give advice without an explanation. 3) don't create documentation in a vacuum - submit it to the Project so that it can be reviewed, corrected, and incorporated.
Easy answers tend to be the least useful in the long run. "RTFM" answers are given for a reason - to make you think, and to make you learn. The problem with most HOWTOs (the ones that aren't completely wrong, anyway) is they tend to just list a sequence of steps, without any explanation of why those steps work, why their particular sequence was chosen, etc.
As a quick example, if you were faced with a black box that takes one number as input and spits out another number as output, and you were given a sample set of inputs and outputs: 1, 2, 3, 4, 5, 6, 7, 8, 9 1, 0, 9, 0, 25, 0, 49, 0, 81 it may not be immediately obvious to you why those outputs are as they are. If someone then asks you "what will be the output for an input of 15" you might be hard-pressed to come up with the answer.
On the other hand, if someone were to tell you "the rule for this black box is that for any even number, the output is zero, and for any odd number, the output is the square of the input" then you can easily apply that rule to any arbitrary input.
HOWTOs without detailed explanations are like the black box with just a short list of data points. They don't teach you anything, they only give you a fixed set of answers to a fixed set of questions. When you're faced with a new question that's not on their list, you're lost.
It's always important to understand the reasons behind the answers.
On the other hand, having a howTo get you started on the road to investigation can be a good thing. For me, the path to LDAP knowledge was not best started with a walk through slapd.conf. A running server with basic config can allow you to investigate LDAP at an appropriate level. You may be "lost" when you get to your first tough question, but you are lost in the middle of a highway with a bunch of signs telling you where to head for answers. No HowTo is created in a vacuum. More knowledge can be found at the end of the google path when you are ready.
Also, when you are trying to learn to fish, you are probably not ready to understand the workings of the reel, how to make lead weights and to tie a perfect knot.
My point is that there is more than one way to learn. Options are good.
\Greg
--On Tuesday, March 13, 2007 11:30 PM -0400 Greg Martin gmartin@gmartin.org wrote:
On the other hand, having a howTo get you started on the road to investigation can be a good thing. For me, the path to LDAP knowledge was not best started with a walk through slapd.conf. A running server with basic config can allow you to investigate LDAP at an appropriate level. You may be "lost" when you get to your first tough question, but you are lost in the middle of a highway with a bunch of signs telling you where to head for answers. No HowTo is created in a vacuum. More knowledge can be found at the end of the google path when you are ready.
Also, when you are trying to learn to fish, you are probably not ready to understand the workings of the reel, how to make lead weights and to tie a perfect knot.
My point is that there is more than one way to learn. Options are good.
But the majority of "How-To" documents I've found via google are just flat-out *wrong*. The only thing they teach people is incorrect ways to set things up, which leads to mass confusion, and complaints to the list about "poor documentation". And getting people to take down and/or fix their erroneous how-to's is nearly impossible.
--Quanah
-- Quanah Gibson-Mount Principal Software Developer ITS/Shared Application Services Stanford University GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html
On Wed Mar 14 2007 at 06:04:19 CET, Quanah Gibson-Mount wrote:
But the majority of "How-To" documents I've found via google are just flat-out *wrong*.
"How-To" documents are like copying from a class mate; you copy the mistakes as well. The majority of How-Tos I've come across might have been right at some point in time, but that expires very quickly. Unfortunately, the documents don't expire over time (i.e. they are still available) which, IMHO, makes beginner's lives even more difficult, as they use new software with old (and meanwhile incorrect) documentation.
I'd think How-Tos are here to stay, as many aren't interested in learning about the software but are only interested in getting it up and limping quickly.
-JP
<quote who="Quanah Gibson-Mount">
--On Tuesday, March 13, 2007 11:30 PM -0400 Greg Martin gmartin@gmartin.org wrote:
On the other hand, having a howTo get you started on the road to investigation can be a good thing. For me, the path to LDAP knowledge was not best started with a walk through slapd.conf. A running server with basic config can allow you to investigate LDAP at an appropriate level. You may be "lost" when you get to your first tough question, but you are lost in the middle of a highway with a bunch of signs telling you where to head for answers. No HowTo is created in a vacuum. More knowledge can be found at the end of the google path when you are ready.
Also, when you are trying to learn to fish, you are probably not ready to understand the workings of the reel, how to make lead weights and to tie a perfect knot.
My point is that there is more than one way to learn. Options are good.
But the majority of "How-To" documents I've found via google are just flat-out *wrong*. The only thing they teach people is incorrect ways to set things up, which leads to mass confusion, and complaints to the list about "poor documentation". And getting people to take down and/or fix their erroneous how-to's is nearly impossible.
I agree, but sometimes people don't care and get a thought in their head, "I want to setup OpenLDAP!", follow a howto and they've done it. Now they're OpenLDAP experts ;-)
As long as we work our docs to be the best they can be (I'm sure that's been in a movie before ;-) ), then what else can we do?
Gavin.
--Quanah
-- Quanah Gibson-Mount Principal Software Developer ITS/Shared Application Services Stanford University GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html
I'm going to have to disagree with that statement. "Most" is ambiguous and unfair at best. The effectivity of every document, is relative to the readers background(that's a fair and unbiased statement)! When I saw the 'little math sequence', the pattern was nothing but obvious, that's also because my math background lends perfectly to that, obviously to someone who hasn't seen or studied math at all, that would be less than obvious(again relative to the 'readers' background, expectation was partial). I'm brand spanking new to OpenLDAP and within one week, after searching google and sifting through documentation out there - piece wise - I was able to get OpenLDAP(2.3 after recompiling the sources to add sql backend functionality) running on a FC4 server(running on port 81 non-default), using PostgreSQL(8.0.1) on a Solaris(on port 1025 again non-default) and both of these are plugged into another well known application, running on port 80(ewww, did anyone guess http? *bell* wrong... while yes port 80 is the 'standard' port for http protocol to be served on, I'm running an entirely different service there).
Relativity, ambiguity, conciseness, background experiences, any permutation of these(maybe one can add additional parameters to this equation) determines how effective the document is. Actually if we rotate the glass sphere, one could have the perspective that, a document that is wrong is also a GOOD lesson learned in what not to do, and will lend insight into the system operation, by raising the fast-track questions.
That's my $.02 USD.
:)
Quanah Gibson-Mount wrote:
--On Tuesday, March 13, 2007 11:30 PM -0400 Greg Martin gmartin@gmartin.org wrote:
On the other hand, having a howTo get you started on the road to investigation can be a good thing. For me, the path to LDAP knowledge was not best started with a walk through slapd.conf. A running server with basic config can allow you to investigate LDAP at an appropriate level. You may be "lost" when you get to your first tough question, but you are lost in the middle of a highway with a bunch of signs telling you where to head for answers. No HowTo is created in a vacuum. More knowledge can be found at the end of the google path when you are ready.
Also, when you are trying to learn to fish, you are probably not ready to understand the workings of the reel, how to make lead weights and to tie a perfect knot.
My point is that there is more than one way to learn. Options are good.
But the majority of "How-To" documents I've found via google are just flat-out *wrong*. The only thing they teach people is incorrect ways to set things up, which leads to mass confusion, and complaints to the list about "poor documentation". And getting people to take down and/or fix their erroneous how-to's is nearly impossible.
--Quanah
-- Quanah Gibson-Mount Principal Software Developer ITS/Shared Application Services Stanford University GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html
--On Wednesday, March 14, 2007 9:05 AM -0400 louis gonzales gonzales@linuxlouis.net wrote:
I'm going to have to disagree with that statement.
You are obviously welcome to disagree. I will note, however, that I periodically browse the how-to's returned by google, and contact (or attempt to at least) the authors to get them to take them down or update them. So I have a rather good idea of what is out there. And the majority of it is not correct, or at least not correct in relation to the current release series (2.3). And I've seen them cause endless confusion, both on the list and the #ldap channel on freenode. I'm glad you had a good experience, but you are the exception, rather than the rule (unfortunately).
--Quanah
-- Quanah Gibson-Mount Principal Software Developer ITS/Shared Application Services Stanford University GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html
Quanah Gibson-Mount wrote:
--On Wednesday, March 14, 2007 9:05 AM -0400 louis gonzales gonzales@linuxlouis.net wrote:
I'm going to have to disagree with that statement.
You are obviously welcome to disagree. I will note, however, that I periodically browse the how-to's returned by google, and contact (or attempt to at least) the authors to get them to take them down or update them. So I have a rather good idea of what is out there. And the majority of it is not correct(*Incorrect relative to what? If the doc captured a successful deploy for the variables involved with the person deploying, than it is obviously _correct_ to them, or?*), or at least not correct in relation to the current release series (2.3)(*If someone chooses to use a document outlining a deploy of 1.x.y.z for a 2.3 software bundle, then that's their problem and they'll discover that soon enough)*. And I've seen them cause endless confusion(*re-enforces my point, about relativity, for whom does it cause this? To the person deploye 1.xxy on 2.3, sure, sounds like they're already confused :) *), both on the list and the #ldap channel on freenode. I'm glad you had a good experience, but you are the exception, rather than the rule (unfortunately)(*Not an exception by any means, just not confused :D )*.
I think the take away from this should be: - Do the due proper pre-deployment research - Understand at least what versions one is attempting to deploy - based on features necessary to meet deployment objective - Docs on the internet (good/bad/accurate/inaccurate) need to be thought through and aligned with 1st bullet - Docs on the internet provide good referential/supplemental material (good practice is to ensure versions outlined in docs, apply to your scenario) - Statement about "bad and incorrect" documents is certainly true to the extent that they exist ( my point IS that both lend insight into the correct path, namely getting successful deployment ) -- No two deployments will _ever_ be identical 100% - there will always be variables when dealing with software (while humankind has created many marvels, we still have the problem of proving 100% perfection in logic)
:)
--Quanah
-- Quanah Gibson-Mount Principal Software Developer ITS/Shared Application Services Stanford University GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html
On Wed, 14 Mar 2007, Quanah Gibson-Mount wrote:
gonzales@linuxlouis.net wrote:
I'm going to have to disagree with that statement.
You are obviously welcome to disagree. I will note, however, that I periodically browse the how-to's returned by google, and contact (or attempt to at least) the authors to get them to take them down or update them. So I have a rather good idea of what is out there. And the majority of it is not correct, or at least not correct in relation to the current release series (2.3). And I've seen them cause endless confusion, both on the list and the #ldap channel on freenode. I'm glad you had a good experience, but you are the exception, rather than the rule (unfortunately).
If I can add something to the conversation:
A well written HOWTO is useful, but it is very version dependant.
What is true for version 2.0 is not for version 2.3, obviously, so a new HOWTO needs to be written when the time comes. That can be done from someone else or from the author of the original version, but the new version does not make the original version invalid.
I find it useful when I'm running through the initial setup to document the ins and outs. That can be made into a howto and published under a license that allows others to copy, modify and redistribute giving credit to the original authors.
I think that without things like howto's kicking around, (for example the LDAPv3 howto) the actual implementation becomes far far more difficult.
Just my two cents, and I hope that someone finds it useful input.
James
--Quanah
openldap-software@openldap.org
-
Dave Horsfall -
Gavin Henry -
Greg Martin -
Howard Chu -
James Bourne -
Jan-Piet Mens -
louis gonzales -
Quanah Gibson-Mount