Univention Bugzilla – Bug 41782
unknown attr "@univentionVirtualMachine"
Last modified: 2020-07-08 15:26:45 CEST
The following message was written to the join.log on a newly joined backup / slave: 57849f5f /etc/ldap/slapd.conf: line 166: unknown attr "@univentionVirtualMachine" in to clause 57849f5f <access clause> ::= access to <what> [ by <who> [ <access> ] [ <control> ] ]+ <what> ::= bin boot dev etc home initrd.img initrd.img.install initrd.img.old lib lib64 lost+found media mnt opt proc root run sbin selinux srv sys tmp usr var vmlinuz vmlinuz.install vmlinuz.old | dn[.<dnstyle>=<DN>] [filter=<filter>] [attrs=<attrspec>] <attrspec> ::= <attrname> [val[/<matchingRule>][.<attrstyle>]=<value>] | <attrlist> <attrlist> ::= <attr> [ , <attrlist> ] <attr> ::= <attrname> | @<objectClass> | !<objectClass> | entry | children <who> ::= [ bin boot dev etc home initrd.img initrd.img.install initrd.img.old lib lib64 lost+found media mnt opt proc root run sbin selinux srv sys tmp usr var vmlinuz vmlinuz.install vmlinuz.old | anonymous | users | self | dn[.<dnstyle>]=<DN> ] [ realanonymous | realusers | realself | realdn[.<dnstyle>]=<DN> ] [dnattr=<attrname>] [realdnattr=<attrname>] [group[/<objectclass>[/<attrname>]][.<style>]=<group>] [peername[.<peernamestyle>]=<peer>] [sockname[.<style>]=<name>] [domain[.<domainstyle>]=<domain>] [sockurl[.<style>]=<url>] [dynacl/<name>[/<options>][.<dynstyle>][=<pattern>]] [ssf=<n>] [transport_ssf=<n>] [tls_ssf=<n>] [sasl_ssf=<n>] <style> ::= exact | regex | base(Object) <dnstyle> ::= base(Object) | one(level) | sub(tree) | children | exact | regex <attrstyle> ::= exact | regex | base(Object) | one(level) | sub(tree) | children <peernamestyle> ::= exact | regex | ip | ipv6 | path <domainstyle> ::= exact | regex | base(Object) | sub(tree) <access> ::= [[real]self]{<level>|<priv>} <level> ::= none|disclose|auth|compare|search|read|{write|add|delete}|manage <priv> ::= {=|+|-}{0|d|x|c|s|r|{w|a|z}|m}+ <control> ::= [ stop | continue | break ] dynacl: <name>=ACI <pattern>=<attrname> slapschema: bad configuration file!. See Bug #41723. The join was successful, but the message is confusing.
The UCS@school LDAP-ACL's are now checking if the schema is installed. Otherwise joining fails. Let's see tomorrow what ucs-test says. *** This bug has been marked as a duplicate of bug 41725 ***
Created attachment 7821 [details] patch Well, the duplicate fixes it for UCS@school but not for UCS. Here is a patch.
Patch applied. Accidently increased wrong version number in univention-virtual-machine-manager-schema but I think this should be okay. univention-appcenter (5.0.21-26): r71158 | Bug #41782: check if schema exists before writing ACL's univention-virtual-machine-manager-schema.yaml: r71161 | YAML Bug #41782 univention-appcenter.yaml: r71161 | YAML Bug #41782 univention-virtual-machine-manager-schema (6.0.2-1): r71159 | Bug #41782: check if schema exists before writing ACL's
This didn't work, in 01univention-ldap-server-init.inst is a function fake_initial_schema() which writes a different schema.
Reverted the changes because I'm in holiday tomorrow and I don't see any simple solution without touching one more package. univention-virtual-machine-manager-schema (6.0.1-3): r71243 | Revert "Bug #41782: check if schema exists before writing ACL's" univention-appcenter (5.0.21-31): r71242 | Revert "Bug #41782: check if schema exists before writing ACL's" $rm sr From which source package do you want to remove a revision? >univention-virtual-machine-manager-schema Which source revision should be removed> 6.0.2-1 Available: 4.1-0-errata4.1-2 Selected: Select reltag to toggle. 'done' when done> 4.1-0-errata4.1-2 Available: Selected: 4.1-0-errata4.1-2 Select reltag to toggle. 'done' when done> done Removing binary versions Removing: /var/univention/buildsystem2/apt/ucs_4.1-0-errata4.1-2/*/univention-virtual-machine-manager-schema_6.0.2-1.77.201607211607.tar.gz Removing: /var/univention/buildsystem2/apt/ucs_4.1-0-errata4.1-2/*/univention-virtual-machine-manager-schema_6.0.2-1.77.201607211607_all.deb Removing: /var/univention/buildsystem2/apt/ucs_4.1-0-errata4.1-2/source/univention-virtual-machine-manager-schema_6.0.2-1.77.201607211607.dsc Removing: /var/univention/buildsystem2/apt/ucs_4.1-0-errata4.1-2/*/python-univention-directory-manager-uvmm_6.0.2-1.77.201607211607_all.deb Removing: /var/univention/buildsystem2/apt/ucs_4.1-0-errata4.1-2/source/univention-virtual-machine-manager-schema_6.0.2-1.77.201607211607_i386.changes Removing: /var/univention/buildsystem2/apt/ucs_4.1-0-errata4.1-2/*/univention-virtual-machine-manager-schema_6.0.2-1.77.201607211607.dsc Updating Packages/Sources files for ucs_4.1-0-errata4.1-2/all Cleaning up Removing python-univention-directory-manager-uvmm_6.0.2-1.77.201607211607_all.deb.packages Removing univention-virtual-machine-manager-schema_6.0.2-1.77.201607211607_all.deb.packages The Folder ucs_4.1-0-errata4.1-2/extern does not exists Updating Packages/Sources files for ucs_4.1-0-errata4.1-2/i386 Cleaning up Updating Packages/Sources files for ucs_4.1-0-errata4.1-2/amd64 Cleaning up Updating Packages/Sources files for ucs_4.1-0-errata4.1-2/source Cleaning up Removing univention-virtual-machine-manager-schema_6.0.2-1.77.201607211607.dsc.sources Pruning Source Revision from existing release tags and scopes... Removing Source Revision from the Database... Moving the sources for this revision into the morgue... „/var/univention/buildsystem2/src/univention-virtual-machine-manager-schema/6.0.2-1“ -> „/var/univention/buildsystem2/morgue/univention-virtual-machine-manager-schema/6.0.2-1“
(In reply to Florian Best from comment #5) > Reverted the changes because I'm in holiday tomorrow and I don't see any > simple solution without touching one more package. OK
Moving to 4.1-3-errata.
No time for it currently.
The message irritates while debugging other problems.
(In reply to Stefan Gohmann from comment #9) > The message irritates while debugging other problems. Okay, maybe UCS 4.2 interim-3 is better as it involves touching at least 2 packages?!
The traceback occurred also in the logfile of Bug #42505.
Happened in Ticket# 2017040621000198
Again: <http://jenkins.knut.univention.de:8080/job/UCSschool%204.1/job/UCSschool%204.1%20(R2)%20Multiserver/SambaVersion=s4-all-components/565/> # ucr search --brief ^version/ version/erratalevel: 471 version/patchlevel: 4 version/releasename: Vahr version/version: 4.1 Cost: - 3 EC2 VMs running 10h - /me ¼h debugging
slapd was NOT restarted, system was not fully joined, univention-ldapsearch failed, all subsequent LDAP changes were not replicated, all ucs-test (using LDAP) failed.
Can you add the logfiles? At least join.log and listener.log?
(In reply to Stefan Gohmann from comment #15) > Can you add the logfiles? At least join.log and listener.log? No, they were EC2 VMs which are gone after shutdown. Maybe next time...
Happened again in a customer school environment Master version is 4.2-4 errata429 A new installed school slave cannot join. Ticket 2018080921000496
(In reply to Stefan Gohmann from comment #0) Please note that following hunk, which looks like some shell expanded a '*' into the list of file names in the current working directory: > 57849f5f /etc/ldap/slapd.conf: line 166: unknown attr > "@univentionVirtualMachine" in to clause 57849f5f <access clause> ::= access > to <what> [ by <who> [ <access> ] [ <control> ] ]+ <what> ::= > bin boot dev > etc home initrd.img initrd.img.install initrd.img.old lib lib64 lost+found > media mnt opt proc root run sbin selinux srv sys tmp usr var vmlinuz > vmlinuz.install vmlinuz.old > | dn[.<dnstyle>=<DN>] [filter=<filter>]... This might be a security issue...
Created attachment 9627 [details] join.log (In reply to Christina Scheinig from comment #17) > Happened again in a customer school environment > Master version is 4.2-4 errata429 > A new installed school slave cannot join. > Ticket 2018080921000496 The join.log shows /usr/lib/univention-install/01univention-ldap-server-init.inst being executed, which creates a fake LDAP schema: (Bug #38051) >printf '# univention_dummy.conf\n\nldap/server/type: master' >"$tmp" >UNIVENTION_BASECONF="$tmp" univention-config-registry filter \ > </etc/univention/templates/files/etc/ldap/slapd.conf.d/10univention-ldap-server_schema \ > >/var/lib/univention-ldap/schema.conf That single UCR template file does *NOT* include the UVMM.schema, but the generated ACLs in "/etc/ldap/slapd.conf" still reference the attributes and objectClass definitions from it. The join script does not detect that error condition and continues until the end. Next "03univention-directory-listener.inst" gets executed and tries to start slapd, which fails as the LMDB database never was created. I don't know why that can happen (maybe it depends on the order the Debian packages are configured and if the UCR configuration for slapd is in place before slapd.postinst had a chance to run at least once, it may be missing). Anyway: the initialization of a replicating slapd seems to be broken, as 1. slapd is started before the schema is replicated at least once 2. UCR variables regarding the local LDAP server are set before it is started 3. BIND is switched to the local LDAP server before replication is complete 4. if the system is re-joined, it still uses itself for LDAP and DNS, which might be corrupt data. We should rewrite the initial join process to: 1. reset DNS and LDAP temporarily to the master (we're joining to) 2. wipe the old LDAP database and schema 3. Replicate the LDAP schema 4. Setup and start local slapd 5. Setup and start UDL 6. Wait for replication to complete 7. Set LDAP to local server 8. Setup and start BIND 9. Set DNS to local server
(In reply to Philipp Hahn from comment #19) > We should rewrite the initial join process to: > 1. reset DNS and LDAP temporarily to the master (we're joining to) VETO! (at least for now) In UCS@school environments it's important that the correct DNS/LDAP server is used due to selective replication and altered DNS entries for school-specific AD domains.
Additionally: > 6. Wait for replication to complete UCS@school listener modules use the local LDAP server and rely on the selective replication. If the master is used as LDAP server during replication, the UCS@school system is messed up.
(In reply to Sönke Schwardt-Krummrich from comment #20) > (In reply to Philipp Hahn from comment #19) > > We should rewrite the initial join process to: > > 1. reset DNS and LDAP temporarily to the master (we're joining to) > > VETO! (at least for now) > In UCS@school environments it's important that the correct DNS/LDAP server > is used due to selective replication and altered DNS entries for > school-specific AD domains. master = "the server the local system should be replicating from". Then how does that work during the initial join: The local LDAP is not yet populated and you're already using that? IMHO for a re-join we should reset the local configuration to a state similar to an un-joined system as we cannot trust the local system any longer. I had the case were a re-join failed because the local system still used its local BIND using its broken local LDAP to get the IP for the master. (In reply to Sönke Schwardt-Krummrich from comment #21) > > 6. Wait for replication to complete > > UCS@school listener modules use the local LDAP server and rely on the > selective replication. If the master is used as LDAP server during > replication, the UCS@school system is messed up. I did not propose to change anything here, but the current code switches the DNS configuration to use the local LDAP server *BEFORE* it is fully populated; any DNS query might return no or a broken answer! So again: UDL connects to the upstream server and replicates from there; that may be the master or another backup or a chained slave, but my proposal does not touch selective replication. I only propose to reorder the steps to make the dependency chain sane again.
(In reply to Philipp Hahn from comment #18) > (In reply to Stefan Gohmann from comment #0) > > Please note that following hunk, which looks like some shell expanded a '*' > into the list of file names in the current working directory: ... > > bin boot dev > > etc home initrd.img initrd.img.install initrd.img.old lib lib64 lost+found > > media mnt opt proc root run sbin selinux srv sys tmp usr var vmlinuz > > vmlinuz.install vmlinuz.old ... > # grep -nH --color slapschema /etc/init.d/slapd > /etc/init.d/slapd:219: [ -e /usr/sbin/slapschema ] && log_action_msg $(/usr/sbin/slapschema 2>&1) Misssing quotes around "$(slapschema)"; without them the shell does IFS splitting and wildcard substitution!
I reset the bug flags since the failed join is not this issue. It is Bug #47598.
This issue has been filled against UCS 4.1. The maintenance with bug and security fixes for UCS 4.1 has ended on 5st of April 2018. Customers still on UCS 4.1 are encouraged to update to UCS 4.3. Please contact your partner or Univention for any questions. If this issue still occurs in newer UCS versions, please use "Clone this bug" or simply reopen the issue. In this case please provide detailed information on how this issue is affecting you.
See also git:04d6642cdff3534e854df90266d52eb8e96007e7 which is a revert of trying to convert the schema and ACL to ucs_registerLDAPExtension. We should do this and add a condition in the ACL file, which checks if the schema is active (part of the current slapd.conf).
Again with 4.4-4 with a fresh Backup while doing QA for a Pull-Cord
Have a look at bug 46736. I did this for the OX integration.
(In reply to Philipp Hahn from comment #27) > Again with 4.4-4 with a fresh Backup while doing QA for a Pull-Cord later on: > ==> /var/log/univention/listener.log <== > 16.04.20 13:43:14.471 LISTENER ( PROCESS ) : updating 'cn=CloudType,cn=Virtual Machine Manager,dc=phahn,dc=dev' command a ... > ==> /var/log/univention/join.log <== > Object created: cn=CloudType,cn=Virtual Machine Manager,dc=phahn,dc=dev > LDAP Error: Invalid syntax: objectClass: value #2 invalid per syntax > > __JOINERR__:FAILED: /usr/lib/univention-install/40univention-virtual-machine-manager-schema.inst My Master does not have "univention-virtual-machine-manager-schema" installed, while the new Backup has it installed by default. apt purge python-univention-directory-manager-uvmm univention-virtual-machine-manager-schema solved it for now. (In reply to Philipp Hahn from comment #19) > We should rewrite the initial join process to: This is → Bug #48627
For me and a customer Philipps solution ended in not working LDAP.
(In reply to Philipp Hahn from comment #19) > Created attachment 9627 [details] > join.log > > (In reply to Christina Scheinig from comment #17) > > Happened again in a customer school environment > > Master version is 4.2-4 errata429 > > A new installed school slave cannot join. > > Ticket 2018080921000496 > > The join.log shows > /usr/lib/univention-install/01univention-ldap-server-init.inst being > executed, which creates a fake LDAP schema: (Bug #38051) > > >printf '# univention_dummy.conf\n\nldap/server/type: master' >"$tmp" > >UNIVENTION_BASECONF="$tmp" univention-config-registry filter \ > > </etc/univention/templates/files/etc/ldap/slapd.conf.d/10univention-ldap-server_schema \ > > >/var/lib/univention-ldap/schema.conf > > That single UCR template file does *NOT* include the UVMM.schema, but the > generated ACLs in "/etc/ldap/slapd.conf" still reference the attributes and > objectClass definitions from it. > > The join script does not detect that error condition and continues until the > end. > Next "03univention-directory-listener.inst" gets executed and tries to start > slapd, which fails as the LMDB database never was created. > > I don't know why that can happen (maybe it depends on the order the Debian > packages are configured and if the UCR configuration for slapd is in place > before slapd.postinst had a chance to run at least once, it may be missing). What I just found out in a new support case: UVMM comes with a UCR template for the LDAP scheme and a UCR template for the ACLs. The ACLs are always included and the LDAP schema only on the master. The LDAP server will be initialized with a fake schema/base schema set if /var/lib/univention-ldap/schema.conf *does not* exist yet. This means that the first join operation on a system with UVMM installed always fails because slapd does not start due to a missing schema. However, the join script 01univention-ldap-server-init.inst does not terminate with an error. In 03univention-directory-listener.inst the slapd is stopped and then obtained from the master of the LDAP schema blob and stored in /var/lib/univention-ldap/schema.conf. If the join process is aborted and started again, the complete LDAP schema of the master already exists in schema.conf and the start of the slapd is successful, if UVMM or the UVMM schema is already installed on the master. If this is not the case, an error message is displayed in the logfile. I.e. the only current solution seems to be to uninstall the UVMM packages mentioned by Philipp before the join process.
forget my last comment. It worked on slave for me