Greetings, list!
I have a custom schema, which defines an objectclass to which all of my "users" belong. I'd like to add a required ("MUST") attribute to that objectclass, but I'm frightened of destroying my users :-)
Is the following procedure safe?
1. Add the desired attribute as optional ("MAY") to the objectclass in my schema. Restart slapd.
2. Apply an LDIF change to every node with that particular objectclass, setting that new attribute to some acceptable value.
3. Ensure that my "create a new user" tools will set that attribute.
4. Change my schema to require ("MUST") that attribute within that objectclass. Restart slapd.
If not, what is the safe procedure?
Is there a better way of adding a required attribute to an in-production objectclass?
Thanks!
--On Wednesday, May 27, 2009 4:47 PM -0400 Christopher DeMarco demarco@maya.com wrote:
Greetings, list!
Is there a better way of adding a required attribute to an in-production objectclass?
Stop your server, export your database, use Perl's Net::LDAP::LDIF to add the attribute to every entry it applies to, put your updated schema on the server, and reload it with the updated LDIF file.
--Quanah
--
Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration
Quanah Gibson-Mount writes:
demarco@maya.com wrote:
Is there a better way of adding a required attribute to an in-production objectclass?
Stop your server, export your database, use Perl's Net::LDAP::LDIF to add the attribute to every entry it applies to, put your updated schema on the server, and reload it with the updated LDIF file.
Or if that gives too long downtime, you can run slapd in read-only mode with the old database while rebuilding the new database:
Make a copy of slapd.conf, in which you add "readonly on" above the database directive and change "directory /foo/bar" to something like "directory /foo/bar.old". Then after stopping slapd and exporting your database: Rename your database directory to the ".old" location and restart slapd with -f <new conf>. Then take it down again when you're ready to restart with the new database and the original conf. Also, you might run slaptest on the new slapd before taking down the readonly slapd.
And when running slap tools, remember to suid to the user/group slapd will run as. The slapd -u/-g options don't work with slap tools.
Your original procedure lacked a step: Check that no users added an entry with some other tool than yours, one which doesn't add the attribute. If so, goto step 1.
But come to think of it, slapd will start fine if existing entires lack a "MUST" attribute. It doesn't read the entire database to check, after all. Maybe something will misbehave when trying to access such entries, I don't know. But maybe it'll work fine to restart the server with the MUST and add the actual attribute afterwards.
But come to think of it, slapd will start fine if existing entires lack a "MUST" attribute. It doesn't read the entire database to check, after all. Maybe something will misbehave when trying to access such entries, I don't know. But maybe it'll work fine to restart the server with the MUST and add the actual attribute afterwards.
Any attempt to modify non-schema compliant entries that are already in the database will fail unless the modification makes them schema compliant (namely, the modification adds the missing required attribute). Comes to mind that something like a schema compliance checking tool, either off- or on-line could be useful. Sort of a "slapschema" that checks the schema compliance of each entry (matching a filter or within a subtree specification) in a given database.
p.
masarati@aero.polimi.it wrote:
Comes to mind that something like a schema compliance checking tool, either off- or on-line could be useful. Sort of a "slapschema" that checks the schema compliance of each entry (matching a filter or within a subtree specification) in a given database.
good idea => ITS#6150
Ciao, Michael.
Hallvard B Furuseth wrote:
Quanah Gibson-Mount writes:
demarco@maya.com wrote:
Is there a better way of adding a required attribute to an in-production objectclass?
Stop your server, export your database, use Perl's Net::LDAP::LDIF to add the attribute to every entry it applies to, put your updated schema on the server, and reload it with the updated LDIF file.
Or if that gives too long downtime, you can run slapd in read-only mode with the old database while rebuilding the new database:
According to the unsatisfying discussions we had on one of the mailing lists about read-only mode and data consistency I find it really problematic to recommend a procedure which relies on read-only mode.
I'd recommend to update the schema, restart the server and do the modifications via LDAP.
Ciao, Michael.
Michael Ströder wrote:
Hallvard B Furuseth wrote:
Quanah Gibson-Mount writes:
demarco@maya.com wrote:
Is there a better way of adding a required attribute to an in-production objectclass?
Stop your server, export your database, use Perl's Net::LDAP::LDIF to add the attribute to every entry it applies to, put your updated schema on the server, and reload it with the updated LDIF file.
Or if that gives too long downtime, you can run slapd in read-only mode with the old database while rebuilding the new database:
According to the unsatisfying discussions we had on one of the mailing lists about read-only mode and data consistency I find it really problematic to recommend a procedure which relies on read-only mode.
I'd recommend to update the schema, restart the server and do the modifications via LDAP.
Restarting the server is not necessary.
Howard Chu wrote:
Michael Ströder wrote:
Hallvard B Furuseth wrote:
Quanah Gibson-Mount writes:
demarco@maya.com wrote:
Is there a better way of adding a required attribute to an in-production objectclass?
Stop your server, export your database, use Perl's Net::LDAP::LDIF to add the attribute to every entry it applies to, put your updated schema on the server, and reload it with the updated LDIF file.
Or if that gives too long downtime, you can run slapd in read-only mode with the old database while rebuilding the new database:
According to the unsatisfying discussions we had on one of the mailing lists about read-only mode and data consistency I find it really problematic to recommend a procedure which relies on read-only mode.
I'd recommend to update the schema, restart the server and do the modifications via LDAP.
Restarting the server is not necessary.
...provided back-config is used. The original poster did not tell us whether he's using slapd.conf or back-config.
Ciao, Michael.
Christopher DeMarco wrote:
I have a custom schema, which defines an objectclass to which all of my "users" belong. I'd like to add a required ("MUST") attribute to that objectclass, but I'm frightened of destroying my users :-)
Is the following procedure safe?
1. Add the desired attribute as optional ("MAY") to the objectclass in my schema. Restart slapd. 2. Apply an LDIF change to every node with that particular objectclass, setting that new attribute to some acceptable value. 3. Ensure that my "create a new user" tools will set that attribute. 4. Change my schema to require ("MUST") that attribute within that objectclass. Restart slapd.
Note that modifications are guaranteed to be atomic. A modify request complies to the schema and optional additional constraints or the modify request is completely discarded. If the LDIF you use in step 2. solely adds a single additional attribute it really makes no difference to do step 4. as step 1. in the above procedure.
And if you implement schema changes and custom scripts while having high availability requirements you should have a test system at hand for playing anyway...
Ciao, Michael.
openldap-technical@openldap.org
-
Christopher DeMarco -
Hallvard B Furuseth -
Howard Chu -
masarati＠aero.polimi.it -
Michael Ströder -
Quanah Gibson-Mount