Debian 8 ("Jessie") est sortie le 25 avril 2015! 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.

Sommaire des changements

Les changements importants de jessie 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 WheezyUpgrade servira de base à celle de Jessie 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. Durant un test récent, cependant, la procédure s'est déroulé sans problème et sans redémarrer l'interface graphique, en roulant les commands dans un gnome-terminal dans Gnome. Documented dans bug #818506 si vous voyez des problèmes! -- TheAnarcat 2016-03-17 08:33:31

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

Il y a un projet dans Isuma pour automatiser ce processus, voir avec Cleve. Voir aussi la procédure d'upgrade des sysadmins de Debian, qui est presque complètement automatisée, ainsi que les systèmes de mise à jour majeures de Ubuntu, qui sont également automatisé.

Plus de documentation sur ça a également été écrite dans: https://wiki.debian.org/AutomatedUpgrade

Ubuntu a une commande do-release-upgrade qui fait plusieurs choses. Ça fait partie d'une proposition pour rendre les mises à jour majeures plus intuitives. do-release-upgrade fait partie du package update-release-upgrader qui depend de update-manager, écrit en Python.

Il faudrait soit reprendre le code de Ubuntu et le porter a Debian, ou écrire notre propre truc. Procédure de base:

  • screen / ttyrec / etc
  • backups
  • hooks pre-upgrade (puppet, extra configs, e.g. samhain for DSA), deployed par puppet!
  • finish pending upgrades, check consistency
  • fix sources.list(s)
  • download all packages
  • upgrade
  • abort and notify about failures
  • dist-upgrade
  • abort and notify about failures
  • save preseed for future upgrades on other machines
  • autoremove/purge orphan packages
  • hooks post-upgrade (e.g. puppet, package removal lists)
  • fix_conflicts and remember for future upgrades on other machines
  • reboot
  • cleanup old kernels

do-release-upgrade ne fait pas tout ca, du moins pas l'enregistrement des preseeds et tout... -- TheAnarcat 2016-03-17 08:11:50

Pre-upgrade

  1. Verify that the target system is really in wheezy!
    • cat /etc/debian_version
  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. Take a look at this page's Problèmes rencontrés section to spot which applications will possibly have issues with the upgrade.

  5. inform users
  6. check to make sure the backup job will not start while the upgrade takes place!
  7. check backups on backup server
  8. If the server is updated fresh wheezy install run  apt-get 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-jessie.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:
    • RELEASE=jessie
      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
      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 Nagios.

Prepare and check system

  1. disable puppet, pinning and check for packages on hold or broken
    • puppet agent --disable upgrading system to jessie # 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. Remove emacs, since the new package depends on X

    apt-get remove emacs
  3. Run any pending upgrade:
    • apt-get update && apt-get -y upgrade
  4. hold puppet and facter packages in order to upgrade all packages but them:
    • apt-mark hold puppet puppet-common facter

Preparing sources.list

  1. This mostly means changing wheezy to jessie.

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

      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
  2. Until we upgrade to puppet 3.x, we'll still need to keep wheezy around. So 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
  3. 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-shadow libaugeas-ruby1.8 ruby-selinux ruby-json
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

Upgrading the packages

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

  2. Update the package list and check disk space (now that jessie was archived, we need to avoid checking expiration of release files):
  3. Download packages:
    • apt-get -y -d upgrade && apt-get -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. Warn users of downtime
  7. Minimal upgrade run:
    • env DEBIAN_FRONTEND=noninteractive APT_LISTCHANGES_FRONTEND=mail apt-get upgrade -y -o Dpkg::Options::='--force-confdef' -o Dpkg::Options::='--force-confold'
  8. On physical servers (dom0):

    • Jessie does NOT have xen packages for i386 platform. If you are upgrading a 32bit system, ignore the purge command below and pin the xen packages to keep the ones from wheezy.

    • Using XEN/ganeti see their sections below for details JessieUpgrade#Xen JessieUpgrade#Ganeti

    • 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".

      Aussi, il est possible que vous ne voyez pas l'invite de mot de passe de la crypto, solution:

      apt-get install plymouth
      reboot
      sudo ttyrec -e screen /var/log/upgrade-jessie-phase2.ttyrec

      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.

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

Re-enable and run puppet!

  1. 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
  2. verify that puppet doesn't break anything:
    • puppet agent --enable; puppet agent -t --noop --no-report; puppet agent --disable
  3. Re-enable puppet if everything seems ok:
    • puppet agent --enable && puppet agent -t

Things to do after the upgrade

  1. If a new ssh host key was created (most likely since ED25519-type keys are added by puppet for jessie), then get the host key's fingerprint:
    • dpkg-reconfigure openssh-server
      # the above command might actually print the fingerprint for you!
      # in that case you don't need the following command
      ssh-keygen -l -f /etc/ssh/ssh_host_ed25519_key
      You should communicate this fingerprint to anyone concerned (e.g. infra team, travail only if it's a server where ppl can login via ssh -- this includes any git ssh of sftp connection, clients). You should also note that fingerprint down in the wiki page for the server.
  2. Cleanup package configuration
    1. Install the package koumbit-scripts if it's not already there:

      apt install --no-install-recommends koumbit-scripts-vps
    2. 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
    3. Run puppet: puppet agent -t

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

    • dpkg-reconfigure grub-pc
      update-grub
  4. Reboot one last time to boot on the jessie's kernel and monitor for problems in the boot sequence (lags, or errors, fsck)
    • reboot
  5. Vérfier qu'il y a assez d'espace restant pour que les backups aient lieux.
  6. Vérifier les stats du serveur sur http://stats.koumbit.net

  7. Bien sûr, vérifier que les services offerts par la machine fonctionnent toujours. Tester les vrais services, et aussi vérifier l'état dans nagios.

  8. Enlever le downtime dans nagios.
  9. Vérifier dans la file roots@rt.k.n si la file est spammé par des erreurs suite à votre mise à jour!

  10. Remove obsolete packages

    • apt-get autoremove -y --purge
  11. 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))'
  12. Cleanup dummy packages:
    • deborphan --guess-dummy
  13. Empty apt cache
    • apt-get clean
  14. (if applicable) Replace certbot:

    ### with puppet, add certbot class: ###
    include roles::service::certbot
    
    ## running puppet with the above class added should remove files from certbot-auto
    puppet agent -t
    
    # Do a dry-run to test the renewal process.
    certbot renew --dry-run
    
    # replace the existing certificate and exisiting renewal conf by generating a new cert.
    # Select option 2 at prompt (renew and replace existing cert...)
    certbot certonly --webroot -w /var/www/letsencrypt/ -d <example.koumbit.net>
    
    # Remove certbot-auto cronjob
    rm /etc/cron.d/certbot-auto
  15. (optional) If you need emacs installed (since it was removed before hand):

       apt install emacs-nox
  16. 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 Jessie

dans un domU : la swap est disparu

Après le reboot lors de la mise à jour à jessie, la swap n'est pas activé. On retrouve cette erreur lors du démarrage.

[  OK  ] Found device /dev/xvda1.
         Activating swap /dev/xvda1...
[FAILED] Failed to activate swap /dev/xvda1.
See 'systemctl status dev-xvda1.swap' for details.
[DEPEND] Dependency failed for Swap.

Ok, on roule la commande systemctl status dev-xvda1.swap

root@medias:~# systemctl status dev-xvda1.swap
● dev-xvda1.swap - /dev/xvda1
   Loaded: loaded (/etc/fstab)
   Active: failed (Result: exit-code) since dim 2016-05-15 19:12:53 EDT; 1min 25s ago
     What: /dev/xvda1
     Docs: man:fstab(5)
           man:systemd-fstab-generator(8)
  Process: 193 ExecActivate=/sbin/swapon /dev/xvda1 (code=exited, status=255)

mai 15 19:12:53 medias systemd[1]: Activating swap /dev/xvda1...
mai 15 19:12:53 medias swapon[193]: swapon: /dev/xvda1 : échec de lecture d'en-tê…hange
mai 15 19:12:53 medias systemd[1]: dev-xvda1.swap swap process exited, code=exite...255
mai 15 19:12:53 medias systemd[1]: Failed to activate swap /dev/xvda1.
mai 15 19:12:53 medias systemd[1]: Unit dev-xvda1.swap entered failed state.
Hint: Some lines were ellipsized, use -l to show in full.

En reformatant la partition de swap, celle-ci revient lors du prochain redémarrage.

# mkswap /dev/xvda1 
Configure l'espace d'échange (swap) en version 1, taille = 1048572 Kio
pas d'étiquette, UUID=5893690f-6e4b-415f-812e-9927b55d43d6

sshd

while upgrading

If you try to ssh to the machine while it's still upgrading, you'll get this error. Just wait for the upgrade to terminate!

OpenSSL version mismatch. Built against 1000105f, you have 10001080

inside a guest vserver!

After the upgrade of sshd from wheezy to jessie, it's not possible to login into the server! We get disconnected.

May 26 17:16:50 letemps sshd[18081]: Accepted publickey for root from <ip address> port 43396 ssh2: RSA xxxxxxx
May 26 17:16:50 letemps sshd[18081]: pam_loginuid(sshd:session): set_loginuid failed
May 26 17:16:50 letemps sshd[18081]: pam_unix(sshd:session): session opened for user root by (uid=0)
May 26 17:16:50 letemps sshd[18081]: pam_limits(sshd:session): Could not set limit for 'sigpending' to soft=48621, hard=0: Operation not permitted; uid=48621,euid=0
May 26 17:16:50 letemps sshd[18081]: error: PAM: pam_open_session(): Cannot make/remove an entry for the specified session
May 26 17:16:51 letemps sshd[18081]: Received disconnect from <ip address>: 11: disconnected by user

After reading the man page of The pam_loginuid tell us that it denies logins when audit daemon is not running. I tried to install in the guest vserver and run the audit daemon without success. In order to run the daemon, there are some permission to change on the host for this guest as documented here. https://www.pld-linux.org/docs/vserver#running_auditd_inside_guest

To enable access to the server by ssh, I commented in /etc/pam.d/sshd the line:

session    required     pam_loginuid.so

Then, I was able to login again.

Weird keymap problems during upgrade

During the upgrade, my X session would have weird key mapping issue. the p, o, m and other keys would be uppercased by default. When console-data and console-common would finish configuring, the problem went away. -- TheAnarcat 2015-02-17 18:14:02

First workstation test

Tout ceci a été rapporté dans #778695. -- TheAnarcat 2015-02-18 11:51:13

Apache 2.4

Voir la procédure des sysadmins de Debian.org pour un exemple de gestion des nouvelles configs.

Aegir

Aegir s'active dans apache, avec le fichier suivant: /etc/apache2/conf.d/aegir.conf -> /var/aegir/config/apache.conf dans wheezy, mais dans Jessie le répertoire conf.d n'est plus chargé par apache2. On doit utiliser les répertoires /etc/apache2/conf-available et /etc/apache2/conf-enabled, c'est là qu'on doit aller mettre le lien vers la configuration d'Aegir.

Varnish

LOTS of configuration changes are necessary. Refer to VarnishMaintenance#Upgrades for details.

Another detail that breaks some setups is that since jessie now uses systemd, it no longer reads the /etc/default/varnish file, and it might mean that varnish will not bind to the expected IP (or none at all!). See VarnishConfiguration#Systemd for details.

Cups failure

Cups ne voyait plus les imprimantes sur le réseau, j'ai dû installer cups-browsed:

apt-get install cups-browsed

J'ai aussi mis la ligne suivante dans la config /etc/cups/cups-browsed.conf:

BrowsePoll markov:631/version=1.1

et ceci dans /etc/cups/cups.client.conf:

ServerName markov.office.koumbit.net/version=1.1

... sinon il cherchait markov.local. Voir 17232 pour le suivi sur ce bug.

Asterisk

Le contexte "default" contient maintenant des choses par défaut qui peuvent être interprétées avant votre propre configuration. Si asterisk répond avec un message du genre "bravo, vous avez bien installé asterisk [blah blah blah]", vous devriez renommer votre contexte "default" à qqch d'autre qui est plus précis et approprié.

Attention, assurez-vous de remplacer tous les appels à Goto() qui vont vers ce contexte là, ainsi que tous les endroits dans sip.conf et iax.conf où les peers référencent le contexte.

Consoles série

Xen

There is a bug that makes Xen un-rebootable at this stage. See bug#763102. To remediate the situation, we need to purge xen 4.1 packages:

apt-get purge xen-utils-4.1 xen-hypervisor-4.1-amd64 libxen-4.1

/!\ Haha, did you do that before shutting down the VMs ? That was a terrible idea ! /!\

Grub rescue suite au reboot

La procédure a été suivi jusqu'ici, grub semble ne plus être installé correctement... est-ce que c'est le fait du purge de xen? Malheureusement, j'ai pas pu faire le débug plus loin que ça. Le test a été réalisé sur veles.koumbit.net avant une réinstallation pour un client. 643940 -- SeBas 2016-07-07 08:06:52

Donc, faire une double vérification des kernels installés et de l'état de grub avant le reboot.

interface pour le bridge

DomU qui ne boot pas

  • Normalement réglé dans puppet dans la classe : virtual/manifests/xen/domain/xen0.pp

Après avoir été pogné avec ce message d'erreur au boot des domU...

xenconsole: Could not open tty `': No such file or directory
libxl: error: libxl_exec.c:118:libxl_report_child_exitstatus: /etc/xen/scripts/vif-bridge online [-1] exited with error status 1
libxl: error: libxl_device.c:1116:device_hotplug_child_death_cb: script: Could not find bridge device xenbr0
libxl: error: libxl_create.c:1228:domcreate_attach_vtpms: unable to add nic devices
libxl: error: libxl_exec.c:118:libxl_report_child_exitstatus: /etc/xen/scripts/vif-bridge offline [-1] exited with error status 1
libxl: error: libxl_device.c:1116:device_hotplug_child_death_cb: script: Could not find bridge device xenbr0
libxl: error: libxl_exec.c:118:libxl_report_child_exitstatus: console child [0] exited with error status 2

Je suis allé planté le bon bridge dans xl.conf (bizarre de devoir faire ça, ça le pogne pas automatiquement....)

index 374b6bb..9489dbb 100644
--- a/xen/xl.conf
+++ b/xen/xl.conf
@@ -30,7 +30,7 @@
 #vif.default.script="vif-bridge"
 
 # default bridge device to use with vif-bridge hotplug scripts
-#vif.default.bridge="xenbr0"
+vif.default.bridge="br0"

Ganeti

A tester: la commande d'upgrade à la fin du processus roule une ronde de tests sur les nodes et plante à cause de xm qui a changé pour xl.

Il faudrait tester si c'est possible de rouler la commande modify en premier pour éviter que l'upgrade de cluster plante sur les tests.

Avant de lancer ces commandes, assurez-vous que la crypto soit débarrée sur toutes les nodes.

# gnt-cluster modify --force -H xen-pvm:xen_cmd=xl,bootloader_path=/usr/lib/xen-4.4/bin/pygrub
# gnt-cluster upgrade --to=2.12

crypto

Dans jessie, systemd a étendu ses tentacules à cryptsetup aussi; il va lire /etc/crypttab au démarrage pour débarrer la crypto, p-e timeout après un bout de temps si le mdp est pas donné (pas certain de ça).

Si jamais la crypto est débarrée manuellement et avec un nom de device différent que ce qu'il y a dans /etc/crypttab, systemd-cryptsetup ne comprend rien à rien et insiste pour débarrer la crypto même si c'est déjà fait.

Ça a comme conséquence de briser les upgrades automatiques de packages, et d'empêcher certains services de partir.

Donc il faut absolument débarrer la crypto avec les noms dans le fichier de config, voir p-e donner les mdp pendant le boot sur la console série.

Samba

Une fois rendu dans jessie, le service qui s'appelle "samba" ne semble pas bien fonctionner:

root@filer:~# service samba status
● samba.service
   Loaded: masked (/dev/null)
   Active: inactive (dead)

on voit que ça dit "masked (/dev/null)". en effet le fichier /lib/systemd/system/samba.service est un symlink vers /dev/null.

Pas de panique! le service "samba" est en fait remplacé par deux services individuels "smbd" et "nmbd":

root@filer:~# service smbd status
● smbd.service - LSB: start Samba SMB/CIFS daemon (smbd)
   Loaded: loaded (/etc/init.d/smbd)
   Active: active (running) since Wed 2016-05-04 21:55:14 EDT; 27min ago
  Process: 570 ExecStart=/etc/init.d/smbd start (code=exited, status=0/SUCCESS)
   CGroup: /system.slice/smbd.service
           ├─579 /usr/sbin/smbd -D
           └─583 /usr/sbin/smbd -D

May 04 21:55:14 filer smbd[570]: Starting SMB/CIFS daemon: smbd.
root@filer:~# service nmbd status
● nmbd.service - LSB: start Samba NetBIOS nameserver (nmbd)
   Loaded: loaded (/etc/init.d/nmbd)
   Active: active (running) since Wed 2016-05-04 21:55:14 EDT; 27min ago
  Process: 433 ExecStart=/etc/init.d/nmbd start (code=exited, status=0/SUCCESS)
   CGroup: /system.slice/nmbd.service
           └─569 /usr/sbin/nmbd -D

May 04 21:55:14 filer nmbd[433]: Starting NetBIOS name server: nmbd.

Il faut controler les deux daemons directement au lieu de passer par le raccourci "samba" comme dans les releases précédentes.

référence: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=769714

roundcube

fichiers non-apparentant au package

C'est peut-être seulement relié à une install avec alternc-roundcube... mais l'upgrade de roundcube reste jammée dans ses propres fils. Quand on dist-upgrade, on passe de la version 0.7.x de wheezy vers 1.5.1 de jessie-backports.

L'upgrade plante parce qu'il y a des fichiers qui n'appartiennent pas aux bons packages dans certains répertoires.

Un workaround qui permet de continuer l'upgrade:

# YOLO
rm /usr/share/doc/roundcube/*
rm /var/lib/roundcube/config/debian-db.php

ensuite on peut continuer avec apt-get -f install.

erreur mysql sur upgrade

Rouler apt-get install -f et suivre les prompts

carnet d'adresse disparu?

On va relancer l'installeur de roundcube pour voir si on peut retrouver les trucs.

C'est probablement pas lié à la mise à jour de roundcube mais plus au fait que vous avez peut-être changer le "host_mail" pour connecter au serveur imap. On va couvrir le cas ici RoundCubeMaintenance

trucs qui trainent apres l'upgrade

deux packages restaient marqués comme à mettre à jour après un upgrade sur un laptop ici... db5.1-util et unoconv. un dist-upgrade a résolu ce dernier, et j'ai simplement désinstallé le premier. -- TheAnarcat 2016-03-17 12:06:48

Trucs à réparer dans Puppet

apc-stats

Dans PHP 5.6, APC est enfin désuet et remplacé par OpCache (qui est beaucoup plus stable et mieux supporté). OpCache est par défaut activé sous Debian Jessie.

La configuration d'opcache est maintenant gérée par puppet dans la classe site_apache::php. Un plugin munin est également déployé automatiquement. Il faut s'assurer de retirer la classe "apc" de la node puppet.

considérer changer MySQL pour MariaDB

/tmp en RAM

dans wheezy, le fichier /etc/default/tmpfs était utilisé pour configurer /tmp comme un tmpfs (e.g. répertoire contenu en ram).

Jessie ne tient plus compte de ce fichier de configuration si on utilise systemd. Donc pour configurer /tmp pour qu'il soit dans un tmpfs, on doit demander à systemd:

systemctl enable tmp.mount

attention: cependant, l'unité par défaut qui est distribuée pour tmp.mount ne configure pas les arguments nosuid,nodev,noexec comme c'était le cas avant. Il est donc bon de considérer pousser un drop-in dans /etc/systemd/system/tmp.mount.d/qqch.conf pour ajouter ces options sur la ligne qui commence par Options=. Ce fichier devrait être mis en place via puppet (e.g. à faire).

dépendances manquates de wheezy à jessie sur les postes

Les paquets suivants contiennent des dépendances non satisfaites :
 aptdaemon : Dépend: python-aptdaemon (= 0.45-2+deb7u1) mais 1.1.1-4+deb8u1 est installé
 cheese : Dépend: libgnome-desktop-3-2 (>= 3.2.0) mais il n'est pas installé
 cups : Dépend: libcups2 (= 1.7.5-11+deb8u1) mais 1.5.3-5+deb7u6 est installé
        Dépend: cups-core-drivers (>= 1.7.5-11+deb8u1) mais il n'est pas installé
        Dépend: cups-server-common (>= 1.7.5-11+deb8u1) mais il n'est pas installé
        Dépend: cups-client (>= 1.7.5-11+deb8u1) mais 1.5.3-5+deb7u6 est installé
        Dépend: cups-filters (>= 1.0.24-3~) mais 1.0.18-2.1+deb7u2 est installé
        Recommande: cups-filters (>= 1.0.42) mais 1.0.18-2.1+deb7u2 est installé ou
                    foomatic-filters (>= 4.0)
        Recommande: cups-filters (>= 1.0.36) mais 1.0.18-2.1+deb7u2 est installé ou
                    ghostscript-cups (>= 9.02~)
 cups-bsd : Dépend: libcups2 (= 1.7.5-11+deb8u1) mais 1.5.3-5+deb7u6 est installé
            Dépend: cups-client (= 1.7.5-11+deb8u1) mais 1.5.3-5+deb7u6 est installé
 cups-daemon : Dépend: libcups2 (= 1.7.5-11+deb8u1) mais 1.5.3-5+deb7u6 est installé
               Recommande: cups-browsed mais il n'est pas installé
               Recommande: avahi-daemon (>= 0.6.31-3~) mais 0.6.31-2 est installé
 dpkg : Casse: fontconfig (< 2.11.0-6.2~) mais 2.9.0-7.1+deb7u1 est installé
        Casse: install-info (< 5.1.dfsg.1-3~) mais 4.13a.dfsg.1-10 est installé
        Casse: man-db (< 2.6.3-6~) mais 2.6.2-1 est installé
 emacs24 : Dépend: libmagickcore-6.q16-2 (>= 8:6.8.8.2) mais il n'est pas installé
 eog : Dépend: libgnome-desktop-3-2 (>= 3.2.0) mais il n'est pas installé
 evolution : Dépend: libgnome-desktop-3-2 (>= 3.2.0) mais il n'est pas installé
 evolution-plugins : Dépend: libgnome-desktop-3-2 (>= 3.2.0) mais il n'est pas installé
 foomatic-db-engine : Dépend: cups-filters (>= 1.0.42) mais 1.0.18-2.1+deb7u2 est installé ou
                               foomatic-filters (>= 4.0)
 gdm3 : Dépend: libaudit0 (>= 1.7.13) mais il n'est pas installé
 gir1.2-freedesktop : Dépend: gir1.2-glib-2.0 (= 1.32.1-1) mais 1.42.0-2.2 est installé
 gnome-color-manager : Dépend: libgnome-desktop-3-2 (>= 3.2.0) mais il n'est pas installé
 gnome-contacts : Dépend: libgnome-desktop-3-2 (>= 3.2.0) mais il n'est pas installé
 gnome-control-center : Dépend: libgnome-desktop-3-2 (>= 3.2.0) mais il n'est pas installé
 gnome-documents : Dépend: libgnome-desktop-3-2 (>= 3.2.0) mais il n'est pas installé
 gnome-panel : Dépend: libgnome-desktop-3-2 (>= 3.2.0) mais il n'est pas installé
 gnome-screensaver : Dépend: libgnome-desktop-3-2 (>= 3.2.0) mais il n'est pas installé
 gnome-settings-daemon : Dépend: libgnome-desktop-3-2 (>= 3.4.0) mais il n'est pas installé
 libcupscgi1 : Dépend: libcups2 (= 1.7.5-11+deb8u1) mais 1.5.3-5+deb7u6 est installé
 libcupsfilters1 : Dépend: libcups2 (>= 1.7.0) mais 1.5.3-5+deb7u6 est installé
 libcupsimage2 : Dépend: libcups2 (= 1.7.5-11+deb8u1) mais 1.5.3-5+deb7u6 est installé
 libcupsmime1 : Dépend: libcups2 (= 1.7.5-11+deb8u1) mais 1.5.3-5+deb7u6 est installé
 libcupsppdc1 : Dépend: libcups2 (= 1.7.5-11+deb8u1) mais 1.5.3-5+deb7u6 est installé
 libevolution : Dépend: libgnome-desktop-3-2 (>= 3.2.0) mais il n'est pas installé
 libglib2.0-bin : Dépend: libglib2.0-0 (= 2.33.12+really2.32.4-5) mais 2.42.1-1+b1 est installé
 libgtk-3-0 : Dépend: libcups2 (>= 1.6.0) mais 1.5.3-5+deb7u6 est installé
 libgtk2.0-0 : Dépend: libcups2 (>= 1.6.0) mais 1.5.3-5+deb7u6 est installé
 libmagickwand-6.q16-2 : Dépend: libmagickcore-6.q16-2 (>= 8:6.8.9.9) mais il n'est pas installé
 nautilus : Dépend: libgnome-desktop-3-2 (>= 3.2.0) mais il n'est pas installé
 printer-driver-foo2zjs : Dépend: foomatic-filters
 printer-driver-gutenprint : Dépend: ghostscript-cups
 printer-driver-hpcups : Dépend: ghostscript-cups
 printer-driver-m2300w : Dépend: cups-filters (>= 1.0.42) mais 1.0.18-2.1+deb7u2 est installé ou
                                  foomatic-filters (>= 4.0.0~bzr156)
 printer-driver-pxljr : Dépend: cups-filters (>= 1.0.42) mais 1.0.18-2.1+deb7u2 est installé ou
                                 foomatic-filters (>= 4.0.0~bzr156)
 printer-driver-splix : Dépend: ghostscript-cups
 python-aptdaemon.gtk3widgets : Dépend: python-aptdaemon (= 0.45-2+deb7u1) mais 1.1.1-4+deb8u1 est installé
 python-gi-cairo : Dépend: python-gi (= 3.2.2-2) mais 3.14.0-1 est installé

warnings de textlive-base:amd64

      texlive-base:amd64 conflicts with texlive-binaries:amd64

References


CategoryDebian

JessieUpgrade (last edited 2019-07-23 19:32:27 by gabriel)