Bug #5387: Failing upgrade 2.10 > 2.11 due to rudder-webapp being upgraded before rudder-inventory-ldap - Rudder - Issue Tracker

Actions

Copy link

Bug #5387

closed

Failing upgrade 2.10 > 2.11 due to rudder-webapp being upgraded before rudder-inventory-ldap

Added by Dennis Cabooter over 10 years ago. Updated about 10 years ago.

Status:

Released

Priority:

1 (highest)

Assignee:

Nicolas CHARLES

Category:

System integration

Target version:

2.11.3

Pull Request:

https://github.com/Normation/rudder/p...

Severity:

UX impact:

User visibility:

Effort required:

Priority:

Name check:

Fix check:

Regression:

Description

The errors during the upgrade:

NFO: Adding 'rudder-web' server Role to root server...dpkg: error processing rudder-webapp (--configure):
 subprocess installed post-installation script returned error exit status 17

dpkg: dependency problems prevent configuration of rudder-server-root:
 rudder-server-root depends on rudder-webapp (= 2.11.2-precise0); however:
  Package rudder-webapp is not configured yet.
dpkg: error processing rudder-server-root (--configure):
 dependency problems - leaving unconfigured
No apport report written because the error message indicates its a followup error from a previous failure.
                          Errors were encountered while processing:
 rudder-webapp
 rudder-server-root

The status of the rudder packages after the upgrade:

iU  rudder-server-root                   2.11.2-precise0                   Configuration management and audit tool - root server base package
iF  rudder-webapp                        2.11.2-precise0                   Configuration management and audit tool - webapp

After re-running "apt-get install rudder-server-root" things seem to be fixed.

Subtasks 1 (0 open — 1 closed)

Related issues 1 (0 open — 1 closed)

Actions

Copy link

Updated by Jonathan CLARKE over 10 years ago

Category set to System integration
Status changed from New to 8
Priority changed from N/A to 1 (highest)

This error (17) comes from the ldapadd command run in rudder-upgrade. The full output is:

root@rudder-snapshot:~# ${LDAPADD} -f ldapMigration-2.10-2.11-add-root-server-role.ldif 
modifying entry "nodeId=root,ou=Nodes,ou=Accepted Inventories,ou=Inventories,cn=rudder-configuration" 
ldap_modify: Undefined attribute type (17)
    additional info: rudderServerRole: attribute type undefined

This likely means that the migration is being run too early, before the schema got updated and/or slapd got restarted.

Actions

Copy link

Updated by Jonathan CLARKE over 10 years ago

My suspicion here is that this happens because the rudder-webapp package no longer depends directly on rudder-inventory-ldap, so we have no guarantee that that package is upgraded before rudder-webapp. This would explain that this failed originally, then worked again after all upgrades had been processed.

However, I don't see an immediate solution...

Actions

Copy link

Updated by Jonathan CLARKE over 10 years ago

Subject changed from Failing upgrade rudder-server-root 2.10 > 2.11 on Ubuntu Precise to Failing upgrade 2.10 > 2.11 due to rudder-webapp being upgraded before rudder-inventory-ldap
Assignee set to François ARMAND
Target version set to 2.11.3

This has happened several other times, including on CentOS. We need to workaround this bug.

After careful discussion, we have been able to get back to the root cause: this problem arises because of a fix for bug #5273 (no reports are saved since no roles are defined on root server), which was due to the fact that the Rudder webapp didn't know it's own node was a server component, so didn't give it the "server-roles" technique.

This seems illogical, and we should only have to care about server roles when using a distributed multi-server Rudder setup (see http://www.rudder-project.org/rudder-doc-latest/rudder-doc.html#multiserver-rudder). Therefore, a simple fix seems to modify the condition in the webapp that says "add the server-roles technique if this node has a server-role" to add an "or if this node has UUID=root". François will implement this, and also remove the migration that fails from rudder-upgrade.

Actions

Copy link

Updated by François ARMAND over 10 years ago

To be more precise about the problem: the dependency ordering problem is clearly here, and we don't have a clear workaround for that. Nonetheless, we are working at enhancing the output of the upgrade script so that it is VERY clear that something goes wrong, what goes wrong, and if running the script a second time can correct the problem (see: #5464).

Actions

Copy link

Updated by François ARMAND over 10 years ago

Status changed from 8 to In progress

So, the workaround for that is to remove schema-dependent feature from the upgrade script.
In place, we will consider that the root server ALWAYS belong to the special group "all_servers_with_role".

Note that of course, that won't prevent Rudder to completly fails in unexpected ways if something goes wrong in the update script (but it's not specific the problem at hand and is partially handled by #4564).

Actions

Copy link