Having migrated to dynamic config, I'm looking for a reasonable way to restore in the event of a disaster.
The discussion last week got me curious and though I can slapcat -n 0 -l $SOME_FILE I can't slapadd this same file because it complains that I don't have a slapd.conf file, which of course is true... I haven't needed it with the dynamic configuration backend.
What's the minimum that I would need in a slapd.conf file so I can simply 'rm -fr /var/lib/ldap/* && slapadd -l $SLAPD_BACKUP' ?
Craig White wrote:
Having migrated to dynamic config, I'm looking for a reasonable way to restore in the event of a disaster.
The discussion last week got me curious and though I can slapcat -n 0 -l $SOME_FILE I can't slapadd this same file because it complains that I don't have a slapd.conf file, which of course is true... I haven't needed it with the dynamic configuration backend.
What's the minimum that I would need in a slapd.conf file so I can simply 'rm -fr /var/lib/ldap/*&& slapadd -l $SLAPD_BACKUP' ?
You don't need a slapd.conf file at all. You just need to tell it where to slapadd the configuration.
slapadd -F new/slapd.d -n0 config.ldif
On Oct 26, 2011, at 12:00 PM, Howard Chu wrote:
Craig White wrote:
Having migrated to dynamic config, I'm looking for a reasonable way to restore in the event of a disaster.
The discussion last week got me curious and though I can slapcat -n 0 -l $SOME_FILE I can't slapadd this same file because it complains that I don't have a slapd.conf file, which of course is true... I haven't needed it with the dynamic configuration backend.
What's the minimum that I would need in a slapd.conf file so I can simply 'rm -fr /var/lib/ldap/*&& slapadd -l $SLAPD_BACKUP' ?
You don't need a slapd.conf file at all. You just need to tell it where to slapadd the configuration.
slapadd -F new/slapd.d -n0 config.ldif
---- # mkdir /etc/ldap/slapd.d
# slapadd -l slapcat_config.ldif -F /etc/ldap/slapd.d Available database(s) do not allow slapadd
There aren't any databases configured because I'm thinking recovery from a disaster, starting from a clean install as it were.
Craig
Craig White wrote:
On Oct 26, 2011, at 12:00 PM, Howard Chu wrote:
Craig White wrote:
Having migrated to dynamic config, I'm looking for a reasonable way to restore in the event of a disaster.
The discussion last week got me curious and though I can slapcat -n 0 -l $SOME_FILE I can't slapadd this same file because it complains that I don't have a slapd.conf file, which of course is true... I haven't needed it with the dynamic configuration backend.
What's the minimum that I would need in a slapd.conf file so I can simply 'rm -fr /var/lib/ldap/*&& slapadd -l $SLAPD_BACKUP' ?
You don't need a slapd.conf file at all. You just need to tell it where to slapadd the configuration.
slapadd -F new/slapd.d -n0 config.ldif
# mkdir /etc/ldap/slapd.d
# slapadd -l slapcat_config.ldif -F /etc/ldap/slapd.d Available database(s) do not allow slapadd
There aren't any databases configured because I'm thinking recovery from a disaster, starting from a clean install as it were.
Pay attention. Even a monkey can copy text without omitting parts.
slapadd -F /etc/ldap/slapd.d -n 0 -l slapcat_config.ldif
On Oct 26, 2011, at 1:13 PM, Howard Chu wrote:
Craig White wrote:
On Oct 26, 2011, at 12:00 PM, Howard Chu wrote:
Craig White wrote:
Having migrated to dynamic config, I'm looking for a reasonable way to restore in the event of a disaster.
The discussion last week got me curious and though I can slapcat -n 0 -l $SOME_FILE I can't slapadd this same file because it complains that I don't have a slapd.conf file, which of course is true... I haven't needed it with the dynamic configuration backend.
What's the minimum that I would need in a slapd.conf file so I can simply 'rm -fr /var/lib/ldap/*&& slapadd -l $SLAPD_BACKUP' ?
You don't need a slapd.conf file at all. You just need to tell it where to slapadd the configuration.
slapadd -F new/slapd.d -n0 config.ldif
# mkdir /etc/ldap/slapd.d
# slapadd -l slapcat_config.ldif -F /etc/ldap/slapd.d Available database(s) do not allow slapadd
There aren't any databases configured because I'm thinking recovery from a disaster, starting from a clean install as it were.
Pay attention. Even a monkey can copy text without omitting parts.
slapadd -F /etc/ldap/slapd.d -n 0 -l slapcat_config.ldif
---- sorry - I'm stupid but and am not a monkey.
It seems to me the reason that something like Zytrax gets traction is sometimes the seemingly very simple just doesn't work and then of course, there is the public chastisement that seemingly comes with the territory. All I am trying to do is have a disaster plan though admittedly, I can do pretty much the same because I have a scripted installation which I can use to set up the configuration again and just ldapadd (possibly slapadd) the main DSA data. This was something I could do easily with a flat file configuration but dynamic configuration has made this a real chore.
blow by blow... (have done slapcat -n 0 & -n 1 from my production machine and am working on a VM test, certificate names & paths have been fixed for the VM and adjustments made for apparmor)
root@ubuntu:/etc/ldap# rm -fr slapd.d/* root@ubuntu:/etc/ldap# rm -fr /var/lib/ldap/* root@ubuntu:/etc/ldap# slapadd -F /etc/ldap/slapd.d -n 0 -l slapcat_config.ldif olcDbDirectory: value #0: invalid path: No such file or directory slapadd: could not add entry dn="olcDatabase={2}hdb,cn=config" (line=1009): _################### 99.24% eta none elapsed none spd 5.4 M/s Closing DB... root@ubuntu:/etc/ldap# slapadd -F /etc/ldap/slapd.d -n 1 -l slapcat_data.ldif accesslog: "logdb <suffix>" missing or invalid. backend_startup_one (type=hdb, suffix="dc=ttinet,dc=local"): bi_db_open failed! (1) slap_startup failed
line 1009 in my slapcat_config.ldif... dn: olcDatabase={2}hdb,cn=config
but just above that line is the section... dn: olcOverlay={1}accesslog,olcDatabase={1}hdb,cn=config objectClass: olcOverlayConfig objectClass: olcAccessLogConfig olcOverlay: {1}accesslog olcAccessLogDB: cn=accesslog olcAccessLogOps: writes olcAccessLogPurge: 07+00:00 01+00:00 olcAccessLogSuccess: TRUE structuralObjectClass: olcAccessLogConfig entryUUID: 676a8df4-6db8-1030-90ba-11b63c1d4648 creatorsName: cn=admin,cn=config createTimestamp: 20110907161553Z entryCSN: 20110907161553.355785Z#000000#000#000000 modifiersName: cn=admin,cn=config modifyTimestamp: 20110907161553Z
--On October 26, 2011 2:00:07 PM -0700 Craig White craig.white@ttiltd.com wrote:
root@ubuntu:/etc/ldap# rm -fr slapd.d/* root@ubuntu:/etc/ldap# rm -fr /var/lib/ldap/* root@ubuntu:/etc/ldap# slapadd -F /etc/ldap/slapd.d -n 0 -l slapcat_config.ldif olcDbDirectory: value #0: invalid path: No such file or directory slapadd: could not add entry dn="olcDatabase={2}hdb,cn=config" (line=1009): _################### 99.24% eta none elapsed none spd 5.4 M/s Closing DB... root@ubuntu:/etc/ldap# slapadd -F /etc/ldap/slapd.d -n 1 -l slapcat_data.ldif accesslog: "logdb <suffix>" missing or invalid. backend_startup_one (type=hdb, suffix="dc=ttinet,dc=local"): bi_db_open failed! (1) slap_startup failed
You sent the wrong entry. Clearly when you did rm -rf /var/lib/ldap you removed directories that are referenced in your exported config (specifically whatever is in olcDbDirectory. Note that the error clearly states the problem is with the olcDatabase={2}hdb entry, yet you sent an entirely unrelated and different entry. Please send the information that is relevant to the error reported.
--Quanah
On Oct 26, 2011, at 2:18 PM, Quanah Gibson-Mount wrote:
--On October 26, 2011 2:00:07 PM -0700 Craig White craig.white@ttiltd.com wrote:
root@ubuntu:/etc/ldap# rm -fr slapd.d/* root@ubuntu:/etc/ldap# rm -fr /var/lib/ldap/* root@ubuntu:/etc/ldap# slapadd -F /etc/ldap/slapd.d -n 0 -l slapcat_config.ldif olcDbDirectory: value #0: invalid path: No such file or directory slapadd: could not add entry dn="olcDatabase={2}hdb,cn=config" (line=1009): _################### 99.24% eta none elapsed none spd 5.4 M/s Closing DB... root@ubuntu:/etc/ldap# slapadd -F /etc/ldap/slapd.d -n 1 -l slapcat_data.ldif accesslog: "logdb <suffix>" missing or invalid. backend_startup_one (type=hdb, suffix="dc=ttinet,dc=local"): bi_db_open failed! (1) slap_startup failed
You sent the wrong entry. Clearly when you did rm -rf /var/lib/ldap you removed directories that are referenced in your exported config (specifically whatever is in olcDbDirectory. Note that the error clearly states the problem is with the olcDatabase={2}hdb entry, yet you sent an entirely unrelated and different entry. Please send the information that is relevant to the error reported.
---- the last 3 entries of my slapcat_config.ldif (I believe this is starting at line 993)
dn: olcOverlay={1}accesslog,olcDatabase={1}hdb,cn=config objectClass: olcOverlayConfig objectClass: olcAccessLogConfig olcOverlay: {1}accesslog olcAccessLogDB: cn=accesslog olcAccessLogOps: writes olcAccessLogPurge: 07+00:00 01+00:00 olcAccessLogSuccess: TRUE structuralObjectClass: olcAccessLogConfig entryUUID: 676a8df4-6db8-1030-90ba-11b63c1d4648 creatorsName: cn=admin,cn=config createTimestamp: 20110907161553Z entryCSN: 20110907161553.355785Z#000000#000#000000 modifiersName: cn=admin,cn=config modifyTimestamp: 20110907161553Z
dn: olcDatabase={2}hdb,cn=config objectClass: olcDatabaseConfig objectClass: olcHdbConfig olcDatabase: {2}hdb olcDbDirectory: /var/lib/ldap/accesslog olcSuffix: cn=accesslog olcRootDN: cn=admin,dc=ttinet,dc=local olcDbIndex: default eq olcDbIndex: entryCSN,objectClass,reqEnd,reqResult,reqStart structuralObjectClass: olcHdbConfig entryUUID: 673907ac-6db8-1030-90b6-11b63c1d4648 creatorsName: cn=admin,cn=config createTimestamp: 20110907161553Z entryCSN: 20110907161553.031220Z#000000#000#000000 modifiersName: cn=admin,cn=config modifyTimestamp: 20110907161553Z
dn: olcOverlay={0}syncprov,olcDatabase={2}hdb,cn=config objectClass: olcOverlayConfig objectClass: olcSyncProvConfig olcOverlay: {0}syncprov olcSpNoPresent: TRUE olcSpReloadHint: TRUE structuralObjectClass: olcSyncProvConfig entryUUID: 67684d46-6db8-1030-90b8-11b63c1d4648 creatorsName: cn=admin,cn=config createTimestamp: 20110907161553Z entryCSN: 20110907161553.341021Z#000000#000#000000 modifiersName: cn=admin,cn=config modifyTimestamp: 20110907161553Z
On Oct 26, 2011, at 2:18 PM, Quanah Gibson-Mount wrote:
--On October 26, 2011 2:00:07 PM -0700 Craig White craig.white@ttiltd.com wrote:
root@ubuntu:/etc/ldap# rm -fr slapd.d/* root@ubuntu:/etc/ldap# rm -fr /var/lib/ldap/* root@ubuntu:/etc/ldap# slapadd -F /etc/ldap/slapd.d -n 0 -l slapcat_config.ldif olcDbDirectory: value #0: invalid path: No such file or directory slapadd: could not add entry dn="olcDatabase={2}hdb,cn=config" (line=1009): _################### 99.24% eta none elapsed none spd 5.4 M/s Closing DB... root@ubuntu:/etc/ldap# slapadd -F /etc/ldap/slapd.d -n 1 -l slapcat_data.ldif accesslog: "logdb <suffix>" missing or invalid. backend_startup_one (type=hdb, suffix="dc=ttinet,dc=local"): bi_db_open failed! (1) slap_startup failed
You sent the wrong entry. Clearly when you did rm -rf /var/lib/ldap you removed directories that are referenced in your exported config (specifically whatever is in olcDbDirectory. Note that the error clearly states the problem is with the olcDatabase={2}hdb entry, yet you sent an entirely unrelated and different entry. Please send the information that is relevant to the error reported.
---- got it - thanks
I had to manually create /var/lib/ldap/accesslog directory
Craig
Craig White wrote:
On Oct 26, 2011, at 1:13 PM, Howard Chu wrote:
Pay attention. Even a monkey can copy text without omitting parts.
slapadd -F /etc/ldap/slapd.d -n 0 -l slapcat_config.ldif
sorry - I'm stupid but and am not a monkey.
It seems to me the reason that something like Zytrax gets traction is
sometimes the seemingly very simple just doesn't work and then of course, there is the public chastisement that seemingly comes with the territory.
It's called negative reinforcement, and it is intentional, to discourage careless posts like yours. You're free to carelessly waste as much of your own time as you like, but it's extremely inconsiderate of you to waste the time of everyone else subscribed to the mailing list.
All
I am trying to do is have a disaster plan though admittedly, I can do pretty much the same because I have a scripted installation which I can use to set up the configuration again and just ldapadd (possibly slapadd) the main DSA data. This was something I could do easily with a flat file configuration but dynamic configuration has made this a real chore.
It may seem a "real chore" to you but you've only made it difficult for yourself, by failing to read and pay attention, as already demonstrated before. There are countless installations out there all working fine. The majority of deployments simply fire it up and go their merry way. That would not be the case, if things were as difficult as you make them out to be.
blow by blow... (have done slapcat -n 0& -n 1 from my production machine and
am working on a VM test, certificate names& paths have been fixed for the VM and adjustments made for apparmor)
root@ubuntu:/etc/ldap# rm -fr slapd.d/* root@ubuntu:/etc/ldap# rm -fr /var/lib/ldap/* root@ubuntu:/etc/ldap# slapadd -F /etc/ldap/slapd.d -n 0 -l slapcat_config.ldif olcDbDirectory: value #0: invalid path: No such file or directory slapadd: could not add entry dn="olcDatabase={2}hdb,cn=config" (line=1009): _################### 99.24% eta none elapsed none spd 5.4 M/s Closing DB...
Your first mistake here is in continuing on even though this first slapadd command clearly failed. Again - PAY ATTENTION to what's in front of you.
Your other mistake is obviously that you deleted the directory that your config used. This mistake has nothing to do with dynamic configuration; you would have had the same error if you were using slapd.conf. It's easy to shirk responsibility for your actions and blame the software, but it's clear that you're creating your own problems by not paying attention to what you're doing.
root@ubuntu:/etc/ldap# slapadd -F /etc/ldap/slapd.d -n 1 -l slapcat_data.ldif accesslog: "logdb<suffix>" missing or invalid. backend_startup_one (type=hdb, suffix="dc=ttinet,dc=local"): bi_db_open failed! (1) slap_startup failed
line 1009 in my slapcat_config.ldif... dn: olcDatabase={2}hdb,cn=config
Once again - the software clearly told you which entry and attribute it had a problem with. If you had paid attention to it, instead of ignoring it and creating your own fantasy scenarios, you would have a working system by now.
but just above that line is the section...
Which was completely irrerlevant...
You can learn from your mistakes, and actually start paying attention, or you can continue to ignore what's in front of you. If you choose the latter, I would ask that you quit using OpenLDAP software and go use someone else's package, because there's nothing rewarding in trying to help people who don't learn.
openldap-technical@openldap.org
-
Craig White -
Howard Chu -
Quanah Gibson-Mount