Debian 9 ("Stretch") a été publié le 17 juin 2017! Donc on veut faire des tests de mise à jour pendant quelque temps pour trouver tous les problèmes potentiels pour ensuite pouvoir upgrader en masse. Voici des notes et références pour la mise à jour.

Voir https://redmine.koumbit.net/projects/kt-sa-debian-upgrades pour la liste complète des mises à jour et des outils de suivi de la progression.

Contents

  1. Sommaire des changements
  2. Upgrade process
    1. Pre-upgrade
    2. Prepare and check system
    3. Preparing sources.list
    4. Upgrading the packages
    5. Re-enable and run puppet!
    6. Things to do after the upgrade
  3. Problèmes rencontrés
    1. AlternC
    2. dpkg: erreur de traitement de l'archive /var/cache/apt/archives/ruby-hiera_1.0.0~rc3-1_all.deb
    3. 50unattended-upgrades.ucf-dist
    4. mysql -> mariadb
      1. migration (réglé!)
    5. php est pas mis à jour automatiquement
      1. Apache
      2. Nginx (fpm)
    6. Dovecot
    7. spamassassin
      1. sa-compile failed
      2. connection refused
      3. sa-update?
    8. Dovecot / sieve / spamassssin
    9. fail2ban
    10. opendkim
    11. nagios check : NRPE: Unable to read output
    12. rsyslog
    13. phpmyadmin
    14. Varnish
    15. Puppet
    16. desktops
      1. kdepimlibs-kio-plugins
  4. Références

Sommaire des changements

Les changements importants de stretch sont bien documentés ici, mais on peut noter rapidement:

Le manuel de mise à jour inclus également les enjeux majeurs de mise à jour.

Upgrade process

Depuis les mises à jour à Lenny, des procédures détaillées sont maintenus par Koumbit, en parallèle avec la documentation officielle. La procédure de JessieUpgrade servira de base à celle de Stretch ici.

Notez aussi que notre documentation vise principalement les serveurs. Par exemple, nous suivons la procédure de temps mort minimal. La procédure devrait tout de même pouvoir être utilisée pour les desktops.

Attention: cette procédure peut échouer si elle est roulée à partir de l'interface graphique, qui est redémarrée durant la procédure, selon cette note de Debian. TODO: Vérifier si c'est toujours un problème dans stretch.

Normalement, dans les premiers cycles de mise à jour, on documente surtout les problèmes avec les différents packages ensuite, on revoit la procédure de mise à jour pour de l'optimisation.

Pre-upgrade

  1. Take a look at this page's Problèmes rencontrés section to spot which applications will possibly have issues with the upgrade.

  2. Take a look at the munin graph if available for the system, lets spots any potential problems. Maybe there is 4000 mails in the mail queue or other insane stuff!
  3. Take a look at the mailq of the system and clean it.
  4. inform users
  5. check to make sure the backup job will not start while the upgrade takes place!
  6. check backups on backup server

  7. (optional) If mysql is running

    1. make sure there is good backup of the all databases with mysqldump without error. Run ninjahelper to get to mysqldump of all db. (This can take a while)

    2. Make sure there are no broken tables in your databases. This will cause mysql_upgrade later to fail and it can take a while to fix!! 

      mysqlrepair --all-databases | grep -v OK
      1.Go grab a coffee and come back later!

  8. If the server is a fresh jessie install, run  apt install ttyrec screen  and avoid the puppet and sudo's below

  9. Run in screen and record the session 
    • sudo ttyrec -e screen /var/log/upgrade-stretch.ttyrec

      • OR you can also run the upgrade in tmux: 

      sudo ttyrec -e tmux /var/log/upgrade-stretch.ttyrec
  10. Run puppet once to see if there's any outstanding issues. If so, try to fix them. 
    • puppet agent -t
  11. backup configuration: 
    • NEXT_RELEASE=stretch
cd /etc; git tag pre-${NEXT_RELEASE}
git gc --prune # make /etc smaller for backup
tar cfz /var/backups/pre-${NEXT_RELEASE}-backup.tgz /etc /var/lib/dpkg /var/lib/apt/extended_states /var/lib/aptitude/pkgstates # Note: it may be /var/lib/apt/extended_states in jessie, depending on installed software and history (?)
dpkg --get-selections "*" > /var/backups/dpkg-selections-pre-${NEXT_RELEASE}.txt
chmod 0600 /var/backups/pre-${NEXT_RELEASE}-backup.tgz /var/backups/dpkg-selections-pre-${NEXT_RELEASE}.txt

  12. Put servers in maintenance in Icinga (or Nagios). S'il y en a vraiment beaucoup on peut disabler toutes les notifications (attention, dans ce cas garder un oeil!). Voir IcingaMaintenance#Arr.2BAOo-ter_tout_les_notifications

Prepare and check system

  1. disable puppet, pinning and check for packages on hold or broken 
    • puppet agent --disable "upgrading system to stretch" # Disable puppet so it won't overwrite apt's config while we upgrade:
rm /etc/apt/preferences /etc/apt/preferences.d/* #  Check for pinned (on hold) packages, and possibly disable
rm /etc/apt/sources.list.d/testing.list # or other similar backports or sources from later releases
apt-mark showhold
dpkg --audit

  2. (only if host has not already been migrated to puppet 4.x) hold puppet and facter packages in order to upgrade all packages but them: 

    • apt-mark hold puppet puppet-common facter hiera

  3. (only if host has not already been migrated to puppet 4.x) Re-add a wheezy source in sources.list.d: 

    • mkdir -p /etc/apt/sources.list.d
cat > /etc/apt/sources.list.d/wheezy.list << EOF
deb http://archive.debian.org/debian wheezy main
deb http://archive.debian.org/debian-security wheezy/updates main contrib non-free
deb http://archive.debian.org/debian wheezy-backports main
EOF

  4. (only if host has not already been migrated to puppet 4.x) (TODO this step is about keeping wheezy. we need to change it) While at it, we pin puppet and stuff: 

    • cat > /etc/apt/preferences.d/puppet_from_wheezy.pref << EOG
Package: puppet puppet-common ruby1.8 libxmlrpc-ruby libopenssl-ruby libshadow-ruby1.8 ruby ruby-* libruby*
Pin: release n=wheezy
Pin-Priority: 1500

Package: facter hiera ruby-augeas
Pin: release n=wheezy-backports
Pin-Priority: 1500
EOG

apt-get remove ruby-safe-yaml
  5. Run any pending upgrade: 
    • apt update && apt -y upgrade

  6. (only if the server is currently running mysql (eg: NOT mariadb... mariadb is available on jessie...)) prepare it for transitioning over to mariadb: 

    • apt install -t jessie-backports default-mysql-server
  7. Remove any stray apt config files from jessie: 
    • rm -f /etc/apt/apt.conf.d/{50jessie,99no_check_until}
apt-get update

  8. if this is an alternc server: run alternc.install and check if the script says there are configuration differences.

    • If any, compare them to templates in /etc/alternc/templates/... and copy any necessary change in the templates. When you're confident that templates are up to date, run alternc.install -f so that the alternc installation is in a consistent state, ready for upgrade.

Preparing sources.list

  1. This mostly means changing jessie to stretch.

    1. with puppet 2.7: 

      sed -i.orig 's/jessie/stretch/g' /etc/apt/sources.list
rm /etc/apt/sources.list.d/jessie-backports.list

    2. with puppet 4.x: 

      rm /etc/apt/sources.list.d/jessie-backports.list
rm /etc/apt/sources.list.d/koumbit_jessie_backports_sloppy.list
sed -i.orig 's/jessie/stretch/g' /etc/apt/sources.list.d/*

      Note that in some cases, additional sources are defined in /etc/apt/sources.list.d and that you should review these sources to ensure they are still relevant: 

      ls /etc/apt/sources.list.d

      we want to keep the following APT repository sources: 

      /etc/apt/sources.list.d/aegir-stable.list
/etc/apt/sources.list.d/koumbit.list
/etc/apt/sources.list.d/wheezy.list
  2. We've been deploying a dangerous configuration on jessie and we want to get rid of it. Unfortunately, it took on many file names, so to make sure we clean it out everywhere we should check it now: 
    • ls /etc/apt/apt.conf.d/*until*
# If there is a file that is named similarly to 99no_check_valid_until -- we want to remove it:
rm -f /etc/apt/apt.conf.d/*until*

Upgrading the packages

  1. on physical servers: make sure the serial console works

  2. Update the package list and check disk space:
  3. Download packages: 
    • apt -y -d upgrade && apt -y -d dist-upgrade
  4. Warn users of potential downtime, if relevant

    • look at the list of packages downloaded above to see if any key service may be disrupted

  5. preseed some answers: 
    • debconf-set-selections <<EOF
console-data    console-data/keymap/policy      select  Don't touch keymap
localepurge     localepurge/use-dpkg-feature    boolean true
libpam-runtime  libpam-runtime/override boolean false
libnss-ldap     libnss-ldap/override    boolean false
libpam-ldap     libpam-ldap/override    boolean false
libc6   libraries/restart-without-asking        boolean true
EOF
  6. Minimal upgrade run:

    • Préparez-vous à possiblement rencontrer des problèmes pour les logiciels à cette étape-ci. Référez-vous à la section des problèmes connus pour les régler. 

      env DEBIAN_FRONTEND=noninteractive APT_LISTCHANGES_FRONTEND=mail apt upgrade -y -o Dpkg::Options::='--force-confdef' -o Dpkg::Options::='--force-confold'

      • Pendant l'upgrade ici on sait que deux upgrades de logiciels sont connues pour planter, et on a des solutions. Voir #fail2ban et #opendkim.

  7. On physical servers (dom0):

    • xen packages for i386 platform do NOT exist since Jessie. If you are upgrading a 32bit system, ignore the purge command below and pin the xen packages to keep the ones from wheezy. (TODO we might want to change this recommendation to switch to KVM because keeping wheezy around in stretch is really sketcy)

    • important: Using ganeti see GanetiConfiguration#Mise_.2BAOA_jour

    • Now you can safely reboot:

      Pendant le reboot, utiliser la console série pour aller dans le BIOS et vérifier que la redirection série est configurée à "VT-UTF8" et non "VT-100". 

      reboot
sudo ttyrec -e screen /var/log/upgrade-stretch-phase2.ttyrec

      (TODO p-e que cette étape de reboot est inutile. il faudrait considérer la retirer) Les sysadmins de Debian font un seul reboot durant leur procédure, réviser la notre, particulièrement en révisant la procédure de temps mort minimal également.

  8. Upgrade the rest of the system: 
    • env DEBIAN_FRONTEND=noninteractive APT_LISTCHANGES_FRONTEND=mail apt dist-upgrade -y -o Dpkg::Options::='--force-confdef' -o Dpkg::Options::='--force-confold'

      If upgrade fails for a webapp package (e.g. phpmyadmin) with a weird mysql/mariadb error, see the next point!

  9. (if running mysql) Rouler mysql_upgrade 

     mysql_upgrade --verbose | grep -v OK

  10. (only if using puppet 2.7) Recreate the /usr/bin/ruby symlink. This link might get lost because of the upgrade process. To recreate it we ask ruby to reinstall itself: 

    apt install --reinstall -y ruby1.9.1

    • Vérifier ensuite que /usr/bin/ruby pointe vers /etc/alternatives/ruby

Re-enable and run puppet!

  1. (only if using puppet 2.7) Remove hold on puppet and facter packages, the puppet run we'll be doing next should be adding a file in preferences.d to pin puppet to the wheezy version (2.7) which'll let us get security upgrades as opposed to held packages: 

    • apt-mark unhold puppet puppet-common facter hiera
  2. verify that puppet doesn't break anything: 
    • puppet agent --enable; puppet agent -t --noop --no-report; puppet agent --disable "verifications post-upgrade to stretch"
  3. Re-enable puppet if everything seems ok: 
    • puppet agent --enable && puppet agent -t

Things to do after the upgrade

  1. (if applicable) Fix php installation so that php7.0 is used if needed. Voir section php de problèmes rencontrés

  2. Install the package koumbit-scripts if it's not already there: 

    • apt-get install koumbit-scripts-vps

    If sources are missing, add it (see debian.koumbit.net)

  3. check the updates on configuration files, by looking for .dpkg-* or .ucf-* files in /etc, or by using the clean_conflicts script in koumbit-scripts 1.2: 

    • /opt/bin/clean_conflicts
  4. Re-run puppet to give it chance to reconfigure things you might not know about 
    • puppet agent -t

  5. On all but xen domU, rerun grub and make sure the right drives are configured for a reboot 

    • dpkg-reconfigure grub-pc

  6. Remove obsolete packages 

    • apt autoremove -y --purge
  7. Reboot one last time and monitor for problems in the boot sequence (lags, or errors, fsck, maybe console output failure) 
    • reboot

  8. Une fois la machine revenu online, vérifier que les services offerts par la machine fonctionnent toujours.

  9. Cleanup packages that are not in any current apt sources.
    • First have a look at the list of packages to be removed. 
    • # list all packages not in any installed sources.
aptitude search '?narrow(?not(?archive("^[^n][^o].*$")),?version(CURRENT))'

      • First look at the list to see if anything needs to be kept around. If so, remove other packages manually from that list.

      If (only if) everything can be removed, you can do so with one command: 

      • # uninstall anything that shouldn't be kept around.
aptitude purge '?narrow(?not(?archive("^[^n][^o].*$")),?version(CURRENT))'
  10. Empty apt cache 
    • apt-get clean

  11. optionnel: pour être certain que tout fonctionne après le ménage des vieux packages, on peut faire un autre reboot pour voir si tout revient en ligne correctement.

  12. Vérfier qu'il y a assez d'espace restant pour que les backups aient lieux.

  13. Bien sûr, vérifier que les services offerts par la machine fonctionnent toujours. Tester les vrais services (e.g. accéder à une page web, faire un appel -- accéder à ce que chaque service est supposé offrir), et aussi vérifier l'état dans nagios.

  14. Vérifier les stats du serveur sur http://stats0.koumbit.net/

  15. Vérifier que tous les services nagios ou Icinga pour le serveur sont vert. Enlever le downtime dans nagios ou Icinga.

  16. Vérifier dans la file roots@rt.k.n si la file est spammé par des erreurs suite à votre mise à jour!

  17. update the wiki documentation to reflect the new release; you're now done!

Problèmes rencontrés

Voir la section de problèmes connus des release notes de Stretch

AlternC

La liste va peut-etre être longue... hehe

Suite à la maj, apache ne roule pas. 

# apache2ctl -S
AH00526: Syntax error on line 34 of /etc/apache2/conf-enabled/alternc.conf:
Invalid command 'php_admin_flag', perhaps misspelled or defined by a module not included in the server configuration
Action '-S' failed.
The Apache error log may have more information.

C'est juste qui manque l'activation du module php7.0 d'apache! voir plus loin dans la page à propos de php7.0 

# a2enmod php7.0
# systemctl restart apache2

dpkg: erreur de traitement de l'archive /var/cache/apt/archives/ruby-hiera_1.0.0~rc3-1_all.deb

Lecture des listes de paquets... Fait
Construction de l'arbre des dépendances
Lecture des informations d'état... Fait
Calcul de la mise à jour... Fait
Les paquets suivants seront mis à une VERSION INFÉRIEURE :
  ruby-hiera
0 mis à jour, 0 nouvellement installés, 1 remis à une version inférieure, 0 à enlever et 0 non mis à jour.
47 partiellement installés ou enlevés.
Il est nécessaire de prendre 0 o/16.3 ko dans les archives.
Après cette opération, 104 ko d'espace disque supplémentaires seront utilisés.
Souhaitez-vous continuer ? [O/n] y
dpkg: avertissement: dégradation (« downgrade ») de ruby-hiera depuis 1.3.4-1 vers 1.0.0~rc3-1
(Lecture de la base de données... 56269 fichiers et répertoires déjà installés.)
Préparation du dépaquetage de .../ruby-hiera_1.0.0~rc3-1_all.deb ...
Dépaquetage de ruby-hiera (1.0.0~rc3-1) sur (1.3.4-1) ...
dpkg: erreur de traitement de l'archive /var/cache/apt/archives/ruby-hiera_1.0.0~rc3-1_all.deb (--unpack) 
:
 tentative de remplacement de « /usr/lib/ruby/vendor_ruby/hiera.rb », qui appartient aussi au paquet hiera
 3.2.0-2
Des erreurs ont été rencontrées pendant l'exécution :
 /var/cache/apt/archives/ruby-hiera_1.0.0~rc3-1_all.deb
needrestart is being skipped since dpkg has failed
E: Sub-process /usr/bin/dpkg returned an error code (1)

Pour résoudre: 

apt install hiera=1.3.4-1~bpo70+1 ruby-hiera=1.3.4-1~bpo70+1
apt-mark hold hiera

50unattended-upgrades.ucf-dist

ça plante avec l'erreur suivante... peut-être faire le ménage avant de lancer la mise à jour... à tester lors de la prochaine mise à jour. 

N: Ignoring file '50unattended-upgrades.ucf-dist' in directory '/etc/apt/apt.conf.d/' as it has an invalid filename extension
E: Sub-process /usr/bin/dpkg returned an error code (1)

Pour résoudre ce problème là, on peut simplement effacer le fichier /etc/apt/apt.conf.d/50unattended-upgrades.ucf-dist

mysql -> mariadb

The upgrade from mysql to mariadb doesn't run mysql_upgrade automatically so you need to run it manually. It might lead to strange errors during package upgrades like the following during upgrade of phpmyadmin: 

mysqldump: Couldn't execute 'SHOW FUNCTION STATUS WHERE Db = 'phpmyadmin'': Cannot load from mysql.proc. The table is probably corrupted (1728)

Run mysql_upgrade to fix the error above.

Voir MysqlConfiguration#Upgrade

migration (réglé!)

Stretch now installs mariadb by default instead of mysql:

https://www.debian.org/releases/stretch/amd64/release-notes/ch-whats-new.en.html#mariadb-replaces-mysql

One needs to install default-mysql-server in order for the transition to happen. However that package is only available in jessie-backports.

There was an upgrade bug with mysql that was reported to debian: 847992. A follow-up bug report about the lack of an upgrade path was opened: 857444

The upgrade issue was fixed and now mysql gets removed and replaced by mariadb during the dist-upgrade, even if the default-mysql-server package was not installed.

php est pas mis à jour automatiquement

Bug report debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=860337

php5 continue à rouler et a être disponible (apache ou nginx w/ php5-fpm) et la mise à jour n'est pas bloqué.

Note: Il va falloir checker les modules php5 téléchargés et essayer de construire une liste complète à partir de là. Par example, php5-sqlite3 -> php7.0-sqlite3. Le mieux serait d'automatiser le changement par puppet.

Le dossier de configuration est maintenant situé à /etc/php/X.Y/[cli|fpm|apache2] où X.Y est la version de php (eg. 7.0)

À partir de php7.1 mcrypt ne sera plus disponible. Ceci est probablement un changement important à tenir en tête

Apache

apt install php7.0
dpkg --list | grep -oe 'php5-[a-z0-9]\+' | sed -e 's/php5/php/' -e 's/php-sqlite/php-sqlite3/' | xargs apt install -t  stretch -y
dpkg --list | grep -oe 'php5-[a-z0-9]\+' | xargs apt remove --purge -y
a2dismod php5
a2enmod php7.0
apache2ctl graceful

Nginx (fpm)

Le package php7.0 dépend de libapache-modphp qui à son tour installe apache. Il ne faut donc pas l'installer quand on utilise nginx. 

apt install php7.0-fpm
dpkg --list | grep -oe 'php5-[a-z0-9]\+' | sed -e 's/php5/php/' -e 's/php-sqlite/php-sqlite3/' | xargs apt install -t stretch -y
dpkg --list | grep -oe 'php5-[a-z0-9]\+' | xargs apt remove

Le socket par défaut de fpm devient /run/php/php7.0-fpm.sock

Il faut mettre à jour vos configurations nginx pour assurer que le socket est bel et bien celui utilisé par php7.

Utiliser une commande dans le genre: /etc/apache2/sites-enabled# sed -i 's/var\/run\/php5/run\/php\/php7/g' *

Après avoir installé php7.0-fpm: 

service php5-fpm stop && service php7.0-fpm start
service nginx restart

Dovecot

Après l'upgrade à stretch, c'est possible de voir ça dans le log mail.err: 

Jun 21 10:21:16 hostname dovecot: imap-login: Fatal: Invalid ssl_protocols setting: Unknown protocol 'SSLv2'
Jun 21 10:21:16 hostname dovecot: master: Error: service(imap-login): command startup failed, throttling for 60 secs

La raison pour ça c'est que le support pour SSLv2 a été complètement enlevé d'OpenSSL version 1.1. Donc on veut changer la config pour qqch comme ça et repartir dovecot: 

ssl_protocols = !SSLv3

spamassassin

revoir la doc ici : SpamAssassinConfiguration

sa-compile failed

sa-compile: not compiling; 'spamassassin --lint' check failed!

Des erreurs ont été rencontrées pendant l'exécution :
 sa-compile
needrestart is being skipped since dpkg has failed

Les erreurs étaient du à des lignes dans le fichier /etc/spamassassin/sql.cf que j'ai mis en commentaire et j'ai pu relance la commande de la mise à jour des packages et ça passe sans problème ensuite.

connection refused

L'erreur est la suivante: ça fonctionnait bien avant la mise à jour! 

Jan 30 12:52:09 q spamc[7507]: connect to spamd on 127.0.0.1 failed, retrying (#1 of 3): Connection refused
Jan 30 12:52:10 q spamc[7507]: connect to spamd on 127.0.0.1 failed, retrying (#2 of 3): Connection refused
Jan 30 12:52:11 q spamc[7507]: connect to spamd on 127.0.0.1 failed, retrying (#3 of 3): Connection refused

Voici la bonne configuration ici : SpamAssassinConfiguration#Configuration_de_base

C'est qu'il manque probablement OPTIONS=" ... --listen localhost ... ici: /etc/default/spamassassin

sa-update?

dans journalctl -xe 

jan 30 13:04:28 ques0 spamd[12649]: config: no rules were found! Do you need to run 'sa-update'?

Donc, on veut rouler /etc/cron.daily/spamassassin

là, j'ai justement pogné un bug, https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7540 je vais réessayer dans quelques jours. Le raport du bug https://www.mail-archive.com/users@spamassassin.apache.org/msg101043.html

Dovecot / sieve / spamassssin

Dans notre procédure de mise en place de spamassassin, on déplace les courriels identifiés comme spam dans le répertoire .Junk avec sieve. Comme indiqué ici: SpamAssassinConfiguration#D.2BAOk-placer_les_spams_dans_le_r.2BAOk-pertoire_Junk_.28avec_Dovecot_et_sieve.29

Y semble que le format du fichier a changé... ou autre truc.

On doit recompiler le filtre 

sievec /etc/dovecot/sieve/default.sieve

On ajuste les permissions: 

chown -R vmail:vmail /etc/dovecot/sieve/

voici l'erreur que j'avais. 

Error: sieve: The LDA Sieve plugin does not have permission to save global Sieve script binaries; global Sieve scripts like `/etc/dovecot/sieve/default.sieve'need to be pre-compiled using the sievec tool

fail2ban

During the upgrade, the package for fail2ban might fail to start the fail2ban service back up again, leading the postinst script to fail.

The package in stretch creates a file /etc/fail2ban/jail.d/defaults-debian.conf that creates a jail for sshd but defines no filter and no port for the default action (the one set up by the puppet module that we use ... maybe we need to revise this?). Removing this file or moving it out of the way helps the fail2ban start up again: 

rm /etc/fail2ban/jail.d/defaults-debian.conf
apt -f install

opendkim

Ça plante lors de la mise à jour, en fait, le service ne redémarre pas... voici l'erreur: 

Paramétrage de opendkim (2.11.0~alpha-10+deb9u1) ...
Job for opendkim.service failed because the control process exited with error code.
See "systemctl status opendkim.service" and "journalctl -xe" for details.
invoke-rc.d: initscript opendkim, action "start" failed.
● opendkim.service - OpenDKIM DomainKeys Identified Mail (DKIM) Milter
   Loaded: loaded (/lib/systemd/system/opendkim.service; enabled; vendor preset: enabled)
   Active: activating (auto-restart) (Result: exit-code) since Mon 2018-01-15 21:07:42 EST; 12ms ago
     Docs: man:opendkim(8)
           man:opendkim.conf(5)
           man:opendkim-genkey(8)
           man:opendkim-genzone(8)
           man:opendkim-testadsp(8)
           man:opendkim-testkey
           http://www.opendkim.org/docs.html
  Process: 27704 ExecStart=/usr/sbin/opendkim -x /etc/opendkim.conf (code=exited, status=78)

jan 15 21:07:42 alternc0.koumbit.net systemd[1]: Failed to start OpenDKIM DomainKeys…er.
jan 15 21:07:42 alternc0.koumbit.net systemd[1]: opendkim.service: Unit entered fail…te.
jan 15 21:07:42 alternc0.koumbit.net systemd[1]: opendkim.service: Failed with resul…e'.
Hint: Some lines were ellipsized, use -l to show in full.
dpkg: erreur de traitement du paquet opendkim (--configure) :
 le sous-processus script post-installation installé a retourné une erreur de sortie d'état 1
Des erreurs ont été rencontrées pendant l'exécution :
 opendkim
needrestart is being skipped since dpkg has failed
E: Sub-process /usr/bin/dpkg returned an error code (1)

La solution inspirée d'ici: https://serverfault.com/questions/847435/cant-change-opendkim-socket-in-debian-stretch-in-etc-default-opendkim 

/lib/opendkim/opendkim.service.generate
systemctl daemon-reload
service opendkim restart

après ça, on peut relancer la mise à jour...

Peut-etre aller vous avoir d'autres problèmes avec opendkim... voir OpenDkimMaintenance#key_data_is_not_secure

nagios check : NRPE: Unable to read output

  1. Checker pour voir si ruby est dispo commande: 

    which ruby && ruby --version

  2. Si ruby n'est pas présent (assez normal, pcq seul rubyX.Y sont dispo en stretch), on a besoin de faire un symlink: 

     ln -s /usr/bin/ruby1.8 /usr/bin/ruby

rsyslog

fauiled to set invocation id on control group /system.slice/rsyslog.service

phpmyadmin

Paramétrage de phpmyadmin (4:4.6.6-4) ...
Determining localhost credentials from /etc/mysql/debian.cnf: succeeded.
dbconfig-common: writing config to /etc/dbconfig-common/phpmyadmin.conf
creating database backup in /var/cache/dbconfig-common/backups/phpmyadmin_4:4.2.12-2+deb8u2.2018-04-19-20.08.59.
applying upgrade script for 4:4.2.12-2+deb8u2 -> 4:4.5.0.1-1.
applying upgrade sql for 4:4.2.12-2+deb8u2 -> 4:4.5.0.2-1.
error encountered processing /usr/share/dbconfig-common/data/phpmyadmin/upgrade/mysql/4:4.5.0.2-1:
mysql said: ERROR 1146 (42S02) at line 6: Table 'phpmyadmin.pma__column_info' doesn't exist
dbconfig-common: phpmyadmin configure: aborted.
dbconfig-common: flushing administrative password

Solution: 

sed -i 's/pma__column_info/pma_column_info/g' /usr/share/dbconfig-common/data/phpmyadmin/upgrade/mysql/4:4.5.0.2-1

Varnish

Varnish n'a pas besoin de changements de configuration quand on upgrade de 4.0 à 5.0.

Par contre, il y a un changement de paramètres pour le daemon qui fera planter l'upgrade du package. Donc avant d'upgrader le système (après avoir désactivé puppet en fait), vous pouvez modifier le fichier /etc/systemd/system/varnish.service.d/daemon_options.conf et mettre toutes les lignes "ExecStart=..." en commentaire.

Après ça l'upgrade devrait bien se passer -- par contre ça fera revenir varnish sur le port par défaut, donc 6081, pendant l'upgrade. Quand vous allez réactiver puppet, ça devrait remettre le contenu du "drop-in" systemd à qqch de plus fonctionnel pour ce serveur là.

Puppet

En cas d'erreur d'encodage: 

Error: invalid byte sequence in UTF-8
Error: /Stage[main]/Profile::Utilities/File[/root/.toprc]/content: change from {md5}3711125a48d0bad83b15ab961ab10da4 to {md5}6671b33e19368d6a78147f57b4220884 failed: invalid byte sequence in UTF-8

On peut simlement supprimer le fichier concerné. Il sera re-généré par Puppet:  rm /root/.toprc 

desktops

kdepimlibs-kio-plugins

Les paquets suivants contiennent des dépendances non satisfaites :
 kdepimlibs-kio-plugins : Casse: kdepimlibs-data mais 4:16.04.2-2 devra être installé
                          Casse: kdepimlibs-data:i386
 libakonadi-kde4 : Casse: kdepimlibs-data mais 4:16.04.2-2 devra être installé
                   Casse: kdepimlibs-data:i386
 libakonadi-kmime4 : Casse: kdepimlibs-data mais 4:16.04.2-2 devra être installé
                     Casse: kdepimlibs-data:i386
 libkabc4 : Casse: kdepimlibs-data mais 4:16.04.2-2 devra être installé
            Casse: kdepimlibs-data:i386
 libkcal4 : Casse: kdepimlibs-data mais 4:16.04.2-2 devra être installé
            Casse: kdepimlibs-data:i386
 libkholidays4 : Casse: kdepimlibs-data mais 4:16.04.2-2 devra être installé
                 Casse: kdepimlibs-data:i386
 libkresources4 : Casse: kdepimlibs-data mais 4:16.04.2-2 devra être installé
                  Casse: kdepimlibs-data:i386
 libmailtransport4 : Casse: kdepimlibs-data mais 4:16.04.2-2 devra être installé
                     Casse: kdepimlibs-data:i386
E: Paquets défectueux

Pour résoudre: Use apt dist-upgrade instead

Références

CategoryDebian

StretchUpgrade (last edited 2023-06-11 03:16:36 by nina)