Exploring how to fix our code

[ulvida]

Problems when dealing with dependencies and config files personalisation have led us, in our current 0.1 release to force debian packages installation which is not an acceptable solution. We have to fix that.

On another hand, adapting the role to use PostgreSQL has led us to configure one parameter with debconf and no longer using only config file templates. When skipping sympa.conf installation with a template, sympa package installs without error.

To fix our role, let's try first to use debconf for as much parameters as possible, and see what we can obtain. We could then compare the sympa.conf file obtained by such installation with the version of our role and the version of the upstream role and try to come to a globally compatible solution.

[ulvida]

debconf parameters are obtained, with the package sympa installed with debconf-show:

# debconf-show sympa
  sympa/app-password-confirm: (password omitted)
  sympa/mysql/admin-pass: (password omitted)
  sympa/pgsql/admin-pass: (password omitted)
  sympa/pgsql/app-pass: (password omitted)
  sympa/mysql/app-pass: (password omitted)
  sympa/password-confirm: (password omitted)
  sympa/internal/skip-preseed: false
  sympa/internal/reconfiguring: false
* sympa/listmaster: [email protected]
* sympa/pgsql/authmethod-admin: ident
  sympa/remove-error: abort
* sympa/pgsql/method: TCP/IP
* sympa/language: en
* wwsympa/wwsympa_url: http://cazuela.interior.edu.uy/wws
* sympa/remote/port:
  sympa/purge: false
  sympa/dbconfig-reinstall: false
  sympa/remove_spool: false
* sympa/use_soap: false
* sympa/db/app-user: sympa@localhost
  sympa/passwords-do-not-match:
  sympa/install-error: abort
  sympa/pgsql/manualconf:
* sympa/remote/host: localhost
* sympa/hostname: cazuela.interior.edu.uy
* wwsympa/remove_spool: false
  sympa/mysql/admin-user:
  sympa/upgrade-backup: true
  sympa/upgrade-error: abort
  sympa/mysql/method: Unix socket
* sympa/pgsql/admin-user: postgres
  sympa/db/basepath:
  sympa/pgsql/changeconf: false
  sympa/remote/newhost: localhost
  sympa/missing-db-package-error: abort
* sympa/db/dbname: sympa
* wwsympa/fastcgi: true
  sympa/dbconfig-upgrade: true
* wwsympa/webserver_type: Apache 2
* sympa/dbconfig-remove: true
* sympa/dbconfig-install: true
* sympa/database-type: pgsql
  sympa/pgsql/no-empty-passwords:
* sympa/pgsql/authmethod-user: password

[ulvida]

We set with ansible several of these parameters but, when installing sympa, apt overwites most of them.

Exploring, most of sympa debconf paramenter have low or medium priority, so, even ran on the command line, apt doesn't ask for them. It asks only for high and critical priority parameters, and deduce the others from the linux hostname or default values.

Even with sympa installed, re-definind debconf parameters as we wish, and running:

dpkg-reconfigure -plow sympa

dpkg asks for more paramenters, but re-defines the proposed values some of some of them (particularly sympa/listmaster and wwsympa/wwsympa_url)

I also tried with:

DEBIAN_PRIORITY=low apt-get install sympa

and the same happends...

Well... difficult to go further in this way without going into sympa debian installer code...

[ulvida]

So I come back to the initial way, defining sympa.conf with a template.

When I set de debconf parameter sympa/dbconfig-install to true, sympa installation fails giving the messages:

Sympa configuration already located at /etc/sympa/sympa/sympa.conf
Upgrading Sympa internals (health check)", "Use of uninitialized value $field in string eq at /usr/share/sympa/lib/Sympa/DatabaseDriver/PostgreSQL.pm line 160.
Upgrading Sympa internals (upgrade)
Failed to change process user ID and group ID. Note that on some OS Perl scripts can't change their real UID. In such circumstances Sympa should be run via sudo.

When I set it to false, the installation fails with:

Sympa configuration already located at /etc/sympa/sympa/sympa.conf
Upgrading Sympa internals (health check)
Database sympa defined in sympa.conf has not the right structure or is unreachable. verify db_xxx parameters in sympa.conf

My interpretation: finding a sympa.conf file, apt considers sympa is already installed, and tries an upgrade. When sympa/dbconfig-install it seems that a (pearl?) process is launched with an unprivilegied user id, and then can no longer switch to the appropriate id to create the database. When it is false, trying to upgrade the database, as it has never been configured, it finds it structure is not appropriate.

Possible solution: as it works fine, install first sympa with apt, with minimal needed debconf parameters. Once sympa correctly installed, modify sympa.conf as needed, and trigger a service reload.

[ulvida]

I'm exploring the integration of the proposed solution in upstream code, See branch issue2-upstream, first step commit bf26fe6.

[tricovictor]

It would be good to consider this update that addresses security issues

[ulvida]

It would be good to consider this update that addresses security issues

Right... butin this case we should completely change the role architecture because the patched sympa versions are not yet in debian distribution...

Let's eventually analyse the security issue.

[ulvida]

Finally, it resulted harder to fix our code (v-0.1-arrayan) than to integrate the new functionnalities in the upstream code.

To reflect our more recent and stable version in the Ansible Galaxy, I change master branch name to old-master and create a new master default branch at our present development path.