Journal d’installation de/de mise à niveau vers la version 12.04 de (K)Ubuntu, Precise Pangolin…

Trois journaux : Installation à blanc de Kubuntu 12.04, upgrade de Kubuntu sur un ordinateur de bureau depuis 11.10 et upgrade de Ubuntu server depuis 10.04 LTS

Installation neuve sur Asus Eee PC 1225B

Les informations concernant l’installation sur cet ordinateur portable de la version 12.04 sont consultable sur la documentation francophone de Ubuntu. L’installation avec le livecd (netinstall) se déroule sans problème : pas de problème de pilote à signaler. Comme précisé sur la documentation Ubuntu, la mise en veille ne fonctionne pas après installation. La solution proposée sur la page permet d’y remédier ; il suffit de modifier ou de créer le fichier /etc/pm/sleep.d/20_custom-ehci_hcd

sudo nano /etc/pm/sleep.d/20_custom-ehci_hcd

en remplaçant son contenu par :

#!/bin/sh
#inspired by http://art.ubuntuforums.org/showpost.php?p=9744970&postcount=19
#...and http://thecodecentral.com/2011/01/18/fix-ubuntu-10-10-suspendhibernate-not-working-bug    
# tidied by tqzzaa 🙂

VERSION=1.1
DEV_LIST=/tmp/usb-dev-list
DRIVERS_DIR=/sys/bus/pci/drivers
DRIVERS="ehci xhci" # ehci_hcd, xhci_hcd
HEX="[[:xdigit:]]"
MAX_BIND_ATTEMPTS=2
BIND_WAIT=0.1

unbindDev() {
  echo -n > $DEV_LIST 2>/dev/null
  for driver in $DRIVERS; do
    DDIR=$DRIVERS_DIR/${driver}_hcd
    for dev in `ls $DDIR 2>/dev/null | egrep "^$HEX+:$HEX+:$HEX"`; do
      echo -n "$dev" > $DDIR/unbind
      echo "$driver $dev" >> $DEV_LIST
    done
  done
}

bindDev() {
  if [ -s $DEV_LIST ]; then
    while read driver dev; do
      DDIR=$DRIVERS_DIR/${driver}_hcd
      while [ $((MAX_BIND_ATTEMPTS)) -gt 0 ]; do
          echo -n "$dev" > $DDIR/bind
          if [ ! -L "$DDIR/$dev" ]; then
            sleep $BIND_WAIT
          else
            break
          fi
          MAX_BIND_ATTEMPTS=$((MAX_BIND_ATTEMPTS-1))
      done  
    done < $DEV_LIST   fi   rm $DEV_LIST 2>/dev/null
}

case "$1" in
  hibernate|suspend) unbindDev;;
  resume|thaw)       bindDev;;
esac

Le fichier doit ensuite être rendu exécutable par

sudo chmod 755 /etc/pm/sleep.d/20_custom-ehci_hcd

Fix it! Problème non résolu : Le clavier et le pavé tactile se bloquent au démarrage ou en sortie de mise en veille de façon aléatoire. Il suffit de redémarrer…

Mise à niveau de Kubuntu 11.10 vers Kubuntu 12.04 sur HP Compaq dc5800

La mise à niveau vers Kubuntu 12.04 fut laborieuse :

  • pas de problème particulier rencontré lors de l’exécution de l’utilitaire de mise à niveau mais, au redémarrage de l’ordinateur…
  • les commandes
    sudo apt-get update
    sudo apt-get upgrade

    renvoient l’erreur suivante :

    E: Dépendances manquantes. Essayez d'utiliser l'option -f.

    L’exécution de

    sudo apt-get upgrade -f

    ou de

    sudo apt-get install -f

    renvoient l’erreur

    E: Internal Error. No file name for libgcc1

    Les commandes suivantes permettent de régler le problème de libgcc1 :

    sudo dpkg -i /var/cache/apt/archives/gcc-4.6-base*
    sudo dpkg --configure -a
    sudo apt-get install -f
    sudo apt-get upgrade -f
    sudo apt-get upgrade -f

    (en ignorant les erreurs rencontrées dans les diverses étapes). Une dernière erreur persiste :

    Les paquets suivants contiennent des dépendances non satisfaites :
    vlc : Dépend: vlc-nox (= 2.0.1-4) mais 1.1.12-2~oneiric1 est installé
    vlc-data : Casse: vlc-nox (< 2.0.1-3) mais 1.1.12-2~oneiric1 est installé vlc-nox : Dépend: libvlccore4 (>= 1.1.0) mais il n'est pas installable
    vlc-plugin-notify : Dépend: vlc-nox (= 2.0.1-4) mais 1.1.12-2~oneiric1 est installé
    vlc-plugin-pulse : Dépend: vlc-nox (= 2.0.1-4) mais 1.1.12-2~oneiric1 est installé
    E: Dépendances manquantes. Essayez d'utiliser l'option -f.

    La solution est identique à la précédente :

    sudo dpkg -i /var/cache/apt/archives/vlc*
    sudo dpkg --configure -a
    sudo apt-get install -f
    sudo apt-get upgrade -f
  • Les mises à jour de sécurité importantes, qui demandent l’installation de nouveau packages, génèrent d’autres problèmes de dépendances non satisfaites qui sont, in fine, toutes résolues par des sudo apt-get upgrade -f.
  • Les dépôts désactivés lors de la mise à niveau:
    • En éditant le fichier /etc/apt/sources.list en super-utilisateur, je dé-commente les dépôts désactivés pour la mise à jour (pour moi deb http://ubuntusatanic.org/hell et deb http://deb.torproject.org/torproject.org et lance la mise à niveau avec
      sudo apt-get update
      sudo apt-get upgrade
    • Je mets à jour les dépôts ppa désactivé pour la mise à niveau : dans le répertoire /etc/apt/sources.list.d se situent un certain nombre de dépôts ppa installé manuellement. On retrouve pour chacun de ces dépôts, le fichier initial dans lequel le dépôt mis à niveau est présent mais commenté et un fichier copie, qui se termine par .distUpgrade qui correspond à la version précédente du dépôt et qui est effective. Par exemple, pour le ppa dropbox, j’édite le fichier dropbox.list et je dé-commente la ligne présente puis j’édite le fichier dropbox.list.distUpgrade et je commente la ligne présente. Je termine par
      sudo apt-get update
      sudo apt-get upgrade

      puis je peux supprimer définitivement le fichier dropbox.list.distUpgrade si aucune erreur n’est rencontrée.</li> </ul> </li>

    • Je terminer la mise à niveau par
      sudo apt-get autoremove
      sudo apt-get clean
    • </ul>

      Mise à niveau de Ubuntu Server 10.04 vers Ubuntu Server 12.04 (serveur OVH)

      Mise en œuvre de la mise à niveau

      Plusieurs étapes pour lancer la mise à niveau :

      1. Sauvegarde des données importantes !
      2. Mise à jour de la distribution Ubuntu Server 10.04 avec
        sudo apt-get update
        sudo apt-get upgrade

        et redémarrage du serveur : sudo reboot.</li>

      3. Installation de l’utilitaire de mise à niveau :
        sudo apt-get install update-manager-core

        et édition du fichier de configuration /etc/update-manager/release-upgrades pour régler l’option Prompt=lts.</li>

      4. Lancement de la mise à niveau :
        do-release-upgrade -d

        et suivre les instructions à l’écran. Des fichiers de configuration modifiés manuellement sont mis à jour pendant l’upgrade. Pour chacun, l’utilisateur doit choisir entre le fichier modifié et sa nouvelle version. Mes choix ont été les suivants :

        • /etc/mysql/my.cnf : conserver l’ancienne version ;
        • /etc/initramfs-tools/initarmfs.conf : installer la nouvelle version ;
        • /etc/apache2/sites-available/default et /etc/apache2/sites-available/default-ssl : conserver l’ancienne version ;
        • /etc/php5/apache2 : conserver l’ancienne version ;
        • /etc/ssh/ssh_config : conserver l’ancienne version ;
        • /etc/crontab : conserver l’ancienne version ;
        • /etc/ntp.conf : conserver l’ancienne version ;
        • /etc/denyhost.conf : conserver l’ancienne version ;
        • /etc/dovecot/dovecot.conf : conserver l’ancienne version (Attention ! Ceci génère des problèmes : voir plus loin…) ;
        • /etc/fail2ban/jail.conf : conserver l’ancienne version ;
        • /etc/default/saslauthd : installer la nouvelle version ;
        • /etc/phpmyadmin/config.inc.php : installer la nouvelle version ;
        • /etc/roundcube/db.inc.php : installer la nouvelle version ;
        • /etc/roundcube/debian-db.php : conserver l’ancienne version ;
        • /etc/roundcube/main.inc.php : installer la nouvelle version (Attention ! Ceci génère des problèmes : voir plus loin…) ;
        • /etc/default/grub : installer la nouvelle version.

        Ces choix ne sont pas nécessairement les meilleurs ; certains ont conduit à des problèmes de configuration que j’ai réglés manuellement. On peut juger pour chaque fichier de la différence entre les deux fichiers par utilisation de l’option “D” avant de faire un choix définitive entre les deux versions.</li>

      5. On nettoie le système par
        sudo apt-get autoremove
        sudo apt-get clean
      6. Redémarrage du serveur…
      7. </ol>

        Correction des problèmes

        Le redémarrage et la connexion SSH s’effectuent sans problème. Après redémarrage, les problèmes suivants ont été rencontrés :

        Serveur mail

        Le serveur dovecot ne fonctionne plus… Les messages d’erreur suivants apparaissent dans le fichier /var/log/mail.log :

        SERVER postfix/pipe[10453]: 03F50656BB: to= USER@SERVER, relay=dovecot, delay=0.38,
        delays=0.26/0.01/0/0.11, dsn=4.3.0, status=deferred (temporary failure. Command output:
        doveconf: Warning: NOTE: You can get a new clean config file with: doveconf -n
        > dovecot-new.conf
        doveconf: Warning: Obsolete setting in /etc/dovecot/dovecot.conf:25 [...]

        … qui vient du fait que des configurations présentent dans le fichier /etc/dovecot/dovecot.conf dont j’avais conservé l’ancienne version sur le serveur, sont maintenant devenues obsolètes. Voici les diverses étapes pour régler le problème :

          1. Tentative de mise à jour automatiquede la configuration par
            cp dovecot.conf dovecot.old
            dovecot -n > dovecot-new.conf

            La réponse du serveur est :

            doveconf: Error: protocols: Unknown protocol: sieve
            doveconf: Fatal: Error in configuration file /etc/dovecot/dovecot.conf:
            protocols: Unknown protocol: sieve
        • Suppression du protocole sieve (que je n’utilise pas) et mise à jour automatique : j’édite le fichier /etc/dovecot/dovecot.confet je remplace
          protocols = imaps managesieve

          par

          protocols = imaps

          puis je relance dovecot -n > dovecot-new.confqui retourne la réponse :

          doveconf: Warning: NOTE: You can get a new clean config file with: doveconf -n >
          dovecot-new.conf
          doveconf: Warning: Obsolete setting in /etc/dovecot/dovecot.conf:25: 'imaps' protocol
          is no longer supported. to disable non-ssl imap, use service imap-login { inet_listener
          imap { port=0 } }
          doveconf: Warning: Obsolete setting in /etc/dovecot/dovecot.conf:43: protocol
          managesieve {} has been replaced by protocol sieve { }
          doveconf: Warning: Obsolete setting in /etc/dovecot/dovecot.conf:44: listen=..:port
          has been replaced by service { inet_listener { port } }
          doveconf: Warning: Obsolete setting in /etc/dovecot/dovecot.conf:44: protocol { listen }
          has been replaced by service { inet_listener { address } }
          doveconf: Warning: Obsolete setting in /etc/dovecot/dovecot.conf:45: login_executable
          has been replaced by service { executable }
          doveconf: Warning: Obsolete setting in /etc/dovecot/dovecot.conf:46: mail_executable
          has been replaced by service { executable }
          doveconf: Warning: Obsolete setting in /etc/dovecot/dovecot.conf:101: ssl_ca_file has
          been replaced by ssl_ca =
        • Les messages ne sont toujours pas délivrés correctement par dovecot, toujours à cause de sieve : le fichier /var/log/mail.logfait apparaître l’erreur suivante :
          lda: Fatal: Plugin 'sieve' not found from directory /usr/lib/dovecot/modules

          que je règle en éditant le fichier /etc/dovecot/dovecot.conf et en commentant les lignes suivantes :

          #plugin {
          #  sieve = /home/vmail/%d/%n/Maildir/.dovecot.sieve
          #  sieve_dir = /home/vmail/%d/%n/Maildir/sieve
          # }

          et, dans la section protocol lda

          #mail_plugins = sieve (dans protocol lda)
        • À ce stade, les messages sont délivrés correctement par dovecot mais l’utilisateur ne peut pas de connecter. Les erreurs suivantes apparaissent dans le fichier /var/log/mail.log
          Message : dovecot: auth: Fatal: Unknown database driver 'mysql'

          Ce problème est résolu en éditant le fichier /etc/dovecot/dovecot.conf et en commentant les lignes

          # userdb {
          # driver = passwd
          # }

          ainsi qu’en installant un nouveau paquet :

          sudo apt-get install dovecot-mysql
        • Le serveur mail est alors pleinement fonctionnel à nouveau mais, pour supprimer les alertes reçues à chaque connexion SSL dans le fichier /var/log/mail.log, du type
          Jul 21 14:39:45 chix dovecot: imap-login: Warning: SSL alert: where=0x4004, ret=256:
          warning close notify [37.8.180.238]
          Jul 21 14:39:45 chix dovecot: imap-login: Warning: SSL alert: where=0x4008, ret=256:
          warning close notify [37.8.180.238]
          Jul 21 14:39:45 chix dovecot: imap-login: Disconnected (no auth attempts):
          rip=37.8.180.238, lip=94.23.43.67, TLS
          Jul 21 14:39:45 chix dovecot: imap-login: Warning: SSL: where=0x10, ret=1: 
          before/accept initialization [37.8.180.238]
          Jul 21 14:39:45 chix dovecot: imap-login: Warning: SSL: where=0x2001, ret=1: 
          before/accept initialization [37.8.180.238]
          Jul 21 14:39:45 chix dovecot: imap-login: Warning: SSL: where=0x2001, ret=1: 
          SSLv3 read client hello A [37.8.180.238]
          Jul 21 14:39:45 chix dovecot: imap-login: Warning: SSL: where=0x2001, ret=1: 
          SSLv3 write server hello A [37.8.180.238]
          Jul 21 14:39:45 chix dovecot: imap-login: Warning: SSL: where=0x2001, ret=1: 
          SSLv3 write certificate A [37.8.180.238]
          Jul 21 14:39:45 chix dovecot: imap-login: Warning: SSL: where=0x2001, ret=1: 
          SSLv3 write server done A [37.8.180.238]
          Jul 21 14:39:45 chix dovecot: imap-login: Warning: SSL: where=0x2001, ret=1: 
          SSLv3 flush data [37.8.180.238]
          Jul 21 14:39:45 chix dovecot: imap-login: Warning: SSL: where=0x2002, ret=-1: 
          SSLv3 read client certificate A [37.8.180.238]
          Jul 21 14:39:45 chix dovecot: imap-login: Warning: SSL: where=0x2002, ret=-1: 
          SSLv3 read client certificate A [37.8.180.238]
          Jul 21 14:39:46 chix dovecot: imap-login: Warning: SSL: where=0x2001, ret=1: 
          SSLv3 read client key exchange A [37.8.180.238]
          Jul 21 14:39:46 chix dovecot: imap-login: Warning: SSL: where=0x2001, ret=1: 
          SSLv3 read finished A [37.8.180.238]
          Jul 21 14:39:46 chix dovecot: imap-login: Warning: SSL: where=0x2001, ret=1: 
          SSLv3 write change cipher spec A [37.8.180.238]
          Jul 21 14:39:46 chix dovecot: imap-login: Warning: SSL: where=0x2001, ret=1: 
          SSLv3 write finished A [37.8.180.238]
          Jul 21 14:39:46 chix dovecot: imap-login: Warning: SSL: where=0x2001, ret=1: 
          SSLv3 flush data [37.8.180.238]
          Jul 21 14:39:46 chix dovecot: imap-login: Warning: SSL: where=0x20, ret=1: 
          SSL negotiation finished successfully [37.8.180.238]
          Jul 21 14:39:46 chix dovecot: imap-login: Warning: SSL: where=0x2002, ret=1: 
          SSL negotiation finished successfully [37.8.180.238]

          j’édite à nouveau le fichier /etc/dovecot/dovecot.conf et je règle l’option

          verbose_ssl = no
        • Conclusion… Le fichier /etc/dovecot/dovecot.conf fonctionnel est obtenu par dovecot -n:
          dovecot.conf

          et il est rendu fonctionnel en redémarrant dovecot :

          /etc/init.d/dovecot restart

        Serveur apache

        Les logs du serveur apache renvoient une erreur :

        PHP Warning:  Module 'PDO' already loaded in Unknown on line 0
        PHP Warning:  Module 'pdo_mysql' already loaded in Unknown on line 0

        qui est envoyée par email à l’administrateur toutes les 30 minutes. Le problème est réglé par en commentant les lignes

        ;extension=pdo.so
        ;extension=pdo_mysql.so

        (avec les ; ) dans le fichier /etc/php5/apache2/php.ini. Je m’attendais à trouver des entrées dupliquées pour ces lignes mais ça n’était pas le cas…

        Roundcube

        Le webmail roundcube est fonctionnel mais demande de préciser le nom du serveur mail à la connexion. Pour que le serveur soit automatiquement configuré, éditer le fichier /etc/roundcube/main.inc.php et remplacer la ligne

        $rcmail_config['default_host'] = '';

        qui correspond à la configuration par défaut (du nouveau paquet) par

        $rcmail_config['default_host'] = 'ssl://localhost:993';

        Serveur Git

        Le serveur Git n’est plus fonctionnel après passage de gitosis (déprécié) à gitolite. La transition est effectuée par 1/ l’installation et la configuration de gitolite et 2/ la récupération des dépôts gitosis.

        1. Installation et configuration de gitolite
          Gitolite est installé par</p>
          sudo apt-get install gitolite

          qui retourne un message d’erreur à l’installation

          No adminkey given - not setting up gitolite.

          Ce problème est réglé en relançant la configuration de gitolite :

          sudo dpkg-reconfigure gitolite

          Trois renseignements doivent être fournis :

          • le nom d’utilisateur : gitolite (par exemple) ;
          • l’emplacement des dépôts : /var/lib/gitolite/ (j’ai essayé un autre emplacement /home/gitosis qui a conduit à de multiples erreurs…) ;
          • l’emplacement du fichier de la clé publique de l’administrateur (pour la connexion par ssh).

          Ensuite, sur l’ordinateur local, il faut cloner le répertoire administrateur : la clé privée chargée, faire

          git clone gitolite@server.domainname.org:gitolite-admin

          Le répertoire administrateur contient un dossier keydir contenant les clés autorisées et un dossier conf contenant le fichier de configuration de gitolite.</li>

        2. Récupérer un projet gitosis dans gitolite

          Les migrations automatiques décrites dans les diverses pages web ayant échouées chez moi, je décris une migration sans doute plus laborieuse mais qui a fonctionné. Supposons qu’on souhaite récupérer le projet git project qui est stocké dans le répertoire /srv/gitosis/repositoris/project.git (sur le serveur) et associé aux clés utilisateur du répertoire gitosis-admin/keydir/user1 et gitosis-admin/keydir/user2(sur l’ordinateur local).</p>
          • Initialiser le projet project dans gitolite : pour cela, il faut éditer le fichier local gitolite-admin/conf/gitolite.confet ajouter les lignes suivantes :
            repo    project
                       RW+     =   admin user1 user2

            Il faut également copier les clés publiques de user1 et user2 (qu’on récupère dans gitosis-admin/keydir/user1 dans le dossier gitolite-admin/keydir/user1) et les ajouter au dépôt gitolite-admin :

            git add keydir/user1 keydir/user2

            puis mettre à jour le dépôt gitolite-admin

            git commit -a
            git push

            L’opération précédente a pour effet de créer un dossier project.git dans/var/lib/gitolite/repositories.</li>

          • Copier le dossier projectde gitosis dans gitolite : sur le serveur,
            sudo rm -rf /var/lib/gitolite/repositories/project.git
            sudo cp /srv/gitosis/repositories/project.git /var/lib/gitolite/repositories/project.git

            puis spécifier correctement l’utilisateur et les droits :

            sudo chown -R gitolite:gitolite /var/lib/gitolite/repositories/project.git
            sudo chmod -R og-rx /var/lib/gitolite/repositories/project.git

            On peut alors cloner l’ancien dépôt gitosis à nouveau :

            git clone gitolite@server.domainname.org:project
          • </ul> </li> </ol>

            Coming soon…

            </div>