list members,
i have a multi-provider footprint that i want to remove the AutoCA functionality from. when i loaded the overlay, i set it to disabled, per the below:
dn: olcOverlay={5}autoca objectClass: olcOverlayConfig objectClass: olcAutoCAConfig objectClass: top olcOverlay: {5}autoca structuralObjectClass: olcAutoCAConfig entryUUID: 739501f2-49ad-103e-911a-3dc9b40470bf creatorsName: uid=brendan,ou=domainusers,ou=users,dc=bpk2,dc=com createTimestamp: 20240117175614Z olcAutoCADays: 3650 olcAutoCAKeybits: 2048 olcDisabled: TRUE olcAutoCAserverKeybits: 2048 olcAutoCAuserClass: inetOrgPerson olcAutoCAserverClass: device olcAutoCAserverDays: 1826 olcAutoCAuserDays: 365 olcAutoCAuserKeybits: 2048 entryCSN: 20240117192443.210024Z#000000#001#000000 modifiersName: uid=brendan,ou=domainusers,ou=users,dc=bpk2,dc=com modifyTimestamp: 20240117192443Z
note, olcDisabled is set to true. it seems that something went awry and even though i didn't want the capability active, i wound up with some caCertificate and caPrivateKey objects created in the DIT. it looks like i may have added the overlay in an active state and disabled it after the caCertificate/PrivateKey objects were created. i want to clean up things and remove the AutoCA pieces until i can test them better. what process is needed to remove the objects and overlay, as replication may play a part in some of the effort?
i could imagine that deleting the caCertificate and caPrivateKey objects would be relatively straight forward, but the overlay may prove a bit more complicated. i found a message on this list from some time ago, https://www.openldap.com/lists/openldap-technical/201811/msg00075.html, that says i can stop the slapd instance, remove the overlay ldif files and restart the instance, to accomplish this task. the issue that i am trying to avoid is having to take down the entire fully replicated DIT, in order to delete the overlay and not have replication recreate it because one active node "didn't get the memo".
are there any insights into how i can delete overlays without having replication recreate the objects i want to remove, all while still providing at least one instance to service requests? if it clarifies things, i am running 3 slapd instances behind a load balancer and both the config DB and DIT are replicated between all nodes. if it comes to it, i could take down all instances to perform this work, but i would like to avoid it if possible.
thanks in advance,
brendan kearney
--On Thursday, September 12, 2024 12:39 PM -0400 Brendan Kearney bpk678@gmail.com wrote:
list members,
i have a multi-provider footprint that i want to remove the AutoCA functionality from. when i loaded the overlay, i set it to disabled, per the below:
1) ldapdelete the objects in the binary database that were created by autoca 2) ldapdelete the autoca overlay from the config db
I'd test that in a test environment first, but in theory it should work fine.
--Quanah
--On Thursday, September 12, 2024 2:07 PM -0700 Quanah Gibson-Mount quanah@fast-mail.org wrote:
--On Thursday, September 12, 2024 12:39 PM -0400 Brendan Kearney bpk678@gmail.com wrote:
list members,
i have a multi-provider footprint that i want to remove the AutoCA functionality from. when i loaded the overlay, i set it to disabled, per the below:
- ldapdelete the objects in the binary database that were created by
autoca 2) ldapdelete the autoca overlay from the config db
I'd test that in a test environment first, but in theory it should work fine.
* Assuming a current release of OpenLDAP.
--Quanah
On 9/12/24 4:08 PM, Quanah Gibson-Mount wrote:
--On Thursday, September 12, 2024 2:07 PM -0700 Quanah Gibson-Mount quanah@fast-mail.org wrote:
--On Thursday, September 12, 2024 12:39 PM -0400 Brendan Kearney bpk678@gmail.com wrote:
list members,
i have a multi-provider footprint that i want to remove the AutoCA functionality from. when i loaded the overlay, i set it to disabled, per the below:
- ldapdelete the objects in the binary database that were created by
autoca 2) ldapdelete the autoca overlay from the config db
I'd test that in a test environment first, but in theory it should work fine.
- Assuming a current release of OpenLDAP.
--Quanah
i am running 2.6.6, which should be pretty recent. 2.6.7 seems to be the latest available.
sadly, my command-line-fu is lacking and most of the tools i use will not work (they all crash and cannot enumerate the base of dc=bpk2,dc=com). i am trying:
ldapdelete "cACertificate;binary,dc=bpk2,dc=com" and ldapdelete "cACertificate,dc=bpk2,dc=com"
but both attempts return:
ldap_delete: Invalid DN syntax (34) additional info: invalid DN
the structure looks like this:
dc=bpk2,dc=com dc: bpk2 o: BPK2.com objectClass: dcObject objectClass: organization objectClass: top objectClass: autoCA cACertificate;binary:: MII... cAPrivateKey;binary:: MII...
what would be the proper syntax to delete the cACertificate, cAPrivateKey objects and autoCA objectClass?
thanks for tolerating my neophyte level ignorance,
brendan
--On Friday, September 13, 2024 10:59 AM -0400 Brendan Kearney bpk678@gmail.com wrote:
sadly, my command-line-fu is lacking and most of the tools i use will not work (they all crash and cannot enumerate the base of dc=bpk2,dc=com). i am trying:
ldapdelete "cACertificate;binary,dc=bpk2,dc=com" and ldapdelete "cACertificate,dc=bpk2,dc=com"
but both attempts return:
ldap_delete: Invalid DN syntax (34) additional info: invalid DN
ldapdelete is for deleting entire entries. If you want to remove attributes, you use ldapmodify.
ldapmodify ... dn: ... changetype: modify delete: cACertificate - delete: cAPrivateKey - delete: objectClass objectClass: autoCA
--Quanah
On 9/13/24 11:48 AM, Quanah Gibson-Mount wrote:
--On Friday, September 13, 2024 10:59 AM -0400 Brendan Kearney bpk678@gmail.com wrote:
sadly, my command-line-fu is lacking and most of the tools i use will not work (they all crash and cannot enumerate the base of dc=bpk2,dc=com). i am trying:
ldapdelete "cACertificate;binary,dc=bpk2,dc=com" and ldapdelete "cACertificate,dc=bpk2,dc=com"
but both attempts return:
ldap_delete: Invalid DN syntax (34) additional info: invalid DN
ldapdelete is for deleting entire entries. If you want to remove attributes, you use ldapmodify.
ldapmodify ... dn: ... changetype: modify delete: cACertificate
delete: cAPrivateKey
delete: objectClass objectClass: autoCA
--Quanah
i took several tries at this and each different try fails...
[brendan@x1titanium ~]$ ldapmodify SASL/GSSAPI authentication started SASL username: brendan@BPK2.COM SASL SSF: 256 SASL data security layer installed. dn: dc=bpk2,dc=com changetype: modify delete: cACertificate - delete: cAPrivateKey - delete: objectClass objectClass: autoCA
modifying entry "dc=bpk2,dc=com" ldap_modify: Undefined attribute type (17) additional info: cACertificate: requires ;binary transfer
ok, add the ";binary" string to the attribute to be deleted...
[brendan@x1titanium ~]$ ldapmodify SASL/GSSAPI authentication started SASL username: brendan@BPK2.COM SASL SSF: 256 SASL data security layer installed. dn: dc=bpk2,dc=com changetype: modify delete: cACertificate;binary - delete: cAPrivateKey;binary - delete: objectClass objectClass: autoCA
modifying entry "dc=bpk2,dc=com" ldap_modify: Invalid syntax (21) additional info: objectClass: value #0 invalid per syntax
ok, try deleting the attributes only, instead of the attributes and the objectClass all at once...
[brendan@x1titanium ~]$ ldapmodify SASL/GSSAPI authentication started SASL username: brendan@BPK2.COM SASL SSF: 256 SASL data security layer installed. dn: dc=bpk2,dc=com changetype: modify delete: cACertificate;binary - delete: cAPrivateKey;binary
modifying entry "dc=bpk2,dc=com" ldap_modify: Object class violation (65) additional info: unrecognized objectClass 'autoCA'
i have no idea why the attempts to delete the attributes and objectClass fail. is adding the ";binary" string to the attribute the correct action to overcome the error?
thanks,
brendan
--On Friday, September 13, 2024 1:50 PM -0400 Brendan Kearney bpk678@gmail.com wrote:
[brendan@x1titanium ~]$ ldapmodify SASL/GSSAPI authentication started SASL username: brendan@BPK2.COM SASL SSF: 256 SASL data security layer installed. dn: dc=bpk2,dc=com changetype: modify delete: cACertificate;binary
delete: cAPrivateKey;binary
delete: objectClass objectClass: autoCA
modifying entry "dc=bpk2,dc=com" ldap_modify: Invalid syntax (21) additional info: objectClass: value #0 invalid per syntax
Hm, that seems like a bug.
[brendan@x1titanium ~]$ ldapmodify SASL/GSSAPI authentication started SASL username: brendan@BPK2.COM SASL SSF: 256 SASL data security layer installed. dn: dc=bpk2,dc=com changetype: modify delete: cACertificate;binary
delete: cAPrivateKey;binary
modifying entry "dc=bpk2,dc=com" ldap_modify: Object class violation (65) additional info: unrecognized objectClass 'autoCA'
This seems to think the module is not present. I wonder if by setting it to invalid it doesn't register the objectClass which makes it impossible to clean up. Howard will have to answer how you get out of this situation.
--Quanah
On 9/13/24 1:50 PM, Quanah Gibson-Mount wrote:
--On Friday, September 13, 2024 1:50 PM -0400 Brendan Kearney bpk678@gmail.com wrote:
[brendan@x1titanium ~]$ ldapmodify SASL/GSSAPI authentication started SASL username: brendan@BPK2.COM SASL SSF: 256 SASL data security layer installed. dn: dc=bpk2,dc=com changetype: modify delete: cACertificate;binary - delete: cAPrivateKey;binary - delete: objectClass objectClass: autoCA
modifying entry "dc=bpk2,dc=com" ldap_modify: Invalid syntax (21) additional info: objectClass: value #0 invalid per syntax
Hm, that seems like a bug.
[brendan@x1titanium ~]$ ldapmodify SASL/GSSAPI authentication started SASL username: brendan@BPK2.COM SASL SSF: 256 SASL data security layer installed. dn: dc=bpk2,dc=com changetype: modify delete: cACertificate;binary - delete: cAPrivateKey;binary
modifying entry "dc=bpk2,dc=com" ldap_modify: Object class violation (65) additional info: unrecognized objectClass 'autoCA'
This seems to think the module is not present. I wonder if by setting it to invalid it doesn't register the objectClass which makes it impossible to clean up. Howard will have to answer how you get out of this situation.
--Quanah
there seems to be more at play than meets the eye. i am now running weekly backups of the config and DIT, using slapcat, and i am getting empty backup files. my nas was offline for a bit, as i blew it up and had to rebuild it. i hadnt noticed the failed backups during the rebuild of the nas. now when i run the below script, it completes with only intermittent success...
#!/bin/bash
name=`hostname` date=$(date +%b-%d-%Y)
/sbin/slapcat -n0 -l /root/$name.config.$date.ldif /sbin/slapcat -n2 -l /root/$name.bpk2.$date.ldif
mv /root/$name.*.ldif /backups/
if i run just "slapcat -n0" from the command line, i sometimes get the LDIF output, while other times i get the following error:
[root@server1 ~]# slapcat -n0 PROXIED attributeDescription "OU" inserted. PROXIED attributeDescription "DC" inserted. olcAutoCAserverClass: value #0: <olcAutoCAserverClass> handler exited with 1! config error processing olcOverlay={5}autoca,olcDatabase={2}mdb,cn=config: <olcAutoCAserverClass> handler exited with 1 slapcat: bad configuration file!
something is absurdly wrong, and i cannot delete the Auto CA attributes in the DIT, in order to properly remove the overlays. now, this is causing backups to fail. what do i have to do, to rid my environment of the Auto CA functionality and restore proper backup functionality?
thanks,
brendan
-----Original Message----- From: Brendan Kearney bpk678@gmail.com Sent: Monday, October 21, 2024 7:52 PM To: Quanah Gibson-Mount quanah@fast-mail.org; openldap- technical@openldap.org Subject: [EXT] Re: Removing AutoCA overlay, objectClass, etc
...
#!/bin/bash
name=`hostname` date=$(date +%b-%d-%Y)
/sbin/slapcat -n0 -l /root/$name.config.$date.ldif /sbin/slapcat -n2 -l /root/$name.bpk2.$date.ldif
mv /root/$name.*.ldif /backups/
if i run just "slapcat -n0" from the command line, i sometimes get the LDIF output, while other times i get the following error:
[Windl, Ulrich]
Maybe examining the exit code of the command before continuing might be a good idea. 😉 Capturing and examining the command output might be another good idea.
...
Regards, Ulrich
openldap-technical@openldap.org
-
Brendan Kearney -
Quanah Gibson-Mount -
Windl, Ulrich