Bug 41782 - unknown attr "@univentionVirtualMachine"
unknown attr "@univentionVirtualMachine"
Status: NEW
Product: UCS
Classification: Unclassified
Component: LDAP
UCS 4.1
Other Linux
: P5 normal with 2 votes (vote)
: ---
Assigned To: UCS maintainers
UCS maintainers
:
Depends on:
Blocks: 47598
  Show dependency treegraph
 
Reported: 2016-07-12 16:14 CEST by Stefan Gohmann
Modified: 2018-08-20 06:23 CEST (History)
10 users (show)

See Also:
What kind of report is it?: Bug Report
What type of bug is this?: 1: Cosmetic issue or missing function but workaround exists
Who will be affected by this bug?: 2: Will only affect a few installed domains
How will those affected feel about the bug?: 2: A Pain – users won’t like this once they notice it
User Pain: 0.023
Enterprise Customer affected?: Yes
School Customer affected?:
ISV affected?:
Waiting Support:
Ticket number: 2017040621000198, 2018080921000496
Bug group (optional): Troubleshooting
Max CVSS v3 score:
best: Patch_Available+


Attachments
patch (1.99 KB, patch)
2016-07-21 14:08 CEST, Florian Best
Details | Diff
join.log (2.82 KB, text/plain)
2018-08-15 18:16 CEST, Philipp Hahn
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Stefan Gohmann univentionstaff 2016-07-12 16:14:50 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.
Comment 1 Florian Best univentionstaff 2016-07-20 19:31:59 CEST
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 ***
Comment 2 Florian Best univentionstaff 2016-07-21 14:08:33 CEST
Created attachment 7821 [details]
patch

Well, the duplicate fixes it for UCS@school but not for UCS. Here is a patch.
Comment 3 Florian Best univentionstaff 2016-07-21 16:11:49 CEST
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
Comment 4 Florian Best univentionstaff 2016-07-26 12:22:26 CEST
This didn't work, in 01univention-ldap-server-init.inst is a function fake_initial_schema() which writes a different schema.
Comment 5 Florian Best univentionstaff 2016-07-26 13:04:19 CEST
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“
Comment 6 Dirk Wiesenthal univentionstaff 2016-07-26 13:07:51 CEST
(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
Comment 7 Stefan Gohmann univentionstaff 2016-08-02 07:13:25 CEST
Moving to 4.1-3-errata.
Comment 8 Florian Best univentionstaff 2016-09-21 16:32:00 CEST
No time for it currently.
Comment 9 Stefan Gohmann univentionstaff 2016-09-21 16:36:20 CEST
The message irritates while debugging other problems.
Comment 10 Florian Best univentionstaff 2016-09-21 16:48:03 CEST
(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?!
Comment 11 Florian Best univentionstaff 2016-09-26 15:56:06 CEST
The traceback occurred also in the logfile of Bug #42505.
Comment 12 Christina Scheinig univentionstaff 2017-04-06 10:13:29 CEST
Happened in Ticket# 2017040621000198
Comment 13 Philipp Hahn univentionstaff 2017-08-18 10:36:49 CEST
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
Comment 14 Philipp Hahn univentionstaff 2017-08-18 10:56:15 CEST
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.
Comment 15 Stefan Gohmann univentionstaff 2017-08-18 11:04:07 CEST
Can you add the logfiles? At least join.log and listener.log?
Comment 16 Philipp Hahn univentionstaff 2017-08-18 11:29:15 CEST
(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...
Comment 17 Christina Scheinig univentionstaff 2018-08-15 15:39:18 CEST
Happened again in a customer school environment
Master version is 4.2-4 errata429
A new installed school slave cannot join.
Ticket 2018080921000496
Comment 18 Philipp Hahn univentionstaff 2018-08-15 15:57:05 CEST
(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...
Comment 19 Philipp Hahn univentionstaff 2018-08-15 18:16:39 CEST
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
Comment 20 Sönke Schwardt-Krummrich univentionstaff 2018-08-16 10:22:33 CEST
(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.
Comment 21 Sönke Schwardt-Krummrich univentionstaff 2018-08-16 10:25:40 CEST
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.
Comment 22 Philipp Hahn univentionstaff 2018-08-16 10:36:59 CEST
(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.
Comment 23 Philipp Hahn univentionstaff 2018-08-16 14:05:51 CEST
(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!
Comment 24 Stefan Gohmann univentionstaff 2018-08-20 06:23:58 CEST
I reset the bug flags since the failed join is not this issue. It is Bug #47598.