Table des matières
De Wheezy à Jessie (Debian 7 à 8)
Cet article ne présente pas une procédure de mise à jour et concerne simplement les opérations qui ont été nécessaires pour transférer les données et retrouver les fonctionnalités de l'ancien système à l'occasion d'une réinstallation complète ou encore des notes sur ce qui a changé.
Oui mais ça c'était avant !
Les bonnes vieilles commandes halt, shutdown et reboot ne fonctionnent plus… 
Il faut maintenant utiliser :
# systemctl poweroff # systemctl reboot
C'est le progrès mon pote ! 
Les bons côtés
Voici comment lister les services qui n'ont pas correctement démarré au boot : <cli>root@muffin:~# systemctl –failed –all
UNIT LOAD ACTIVE SUB DESCRIPTION
● mysql.service loaded failed failed LSB: Start and stop the mysql database server daemon
LOAD = Reflects whether the unit definition was properly loaded. ACTIVE = The high-level unit activation state, i.e. generalization of SUB. SUB = The low-level unit activation state, values depend on unit type.
1 loaded units listed. To show all installed unit files use 'systemctl list-unit-files'. </cli>
Apache
Une fois Apache installé (avec MySQL et PHP pour les besoins de mes sites), voici comment j'ai procéder pour remettre en fonction mes anciens sites :
- restauration du contenu des sites web en eux-même dans le dossier
/var/www - restauration des fichiers de configuration de chaque site dans
/etc/apache2/sites-available - activation d'un premier site dont le fichier de configuration récupéré de l'ancien système est du type
nom_du_site:
<cli>root@muffin:~# cd /etc/apache2/sites-available/
root@muffin:/etc/apache2/sites-available# a2ensite §nom_du_site§
ERROR: Site [nom_du_site] does not exist!
</cli>
Et paf le site !
J'ai recherché dans les logs, essayé de résoudre des problèmes inexistants de droits d'accès…
La solution est en fait toute simple et le message pourrait être un peu plus clair (bon d'accord il le deviens dès qu'on connait l'explication). Jessie refuse tout simplement d'activer un site dont le nom du fichier de configuration ne se termine pas par .conf.
Une fois le suffixe ajouté, tout roule : <cli>root@muffin:/etc/apache2/sites-available# mv §nom_du_site§ §nom_du_site§.conf root@muffin:/etc/apache2/sites-available# a2ensite §nom_du_site§ Enabling site nom_du_site. To activate the new configuration, you need to run:
service apache2 reload
</cli>
Je suppose (faute d'avoir le courage d'aller vérifier) que ce fameux suffixe .conf était déjà théoriquement nécessaire avant et que seule une tolérance permettait de s'en passer.
Petite digression… Je n'aime pas du tout cette commande service … qui ne renvoie aucune info :
<cli>root@muffin:/etc/apache2/sites-available# service apache2 reload
root@muffin:/etc/apache2/sites-available# </cli>
Je préfère nettement la bonne vieille méthode /etc/init.d/… :
<cli>root@muffin:/etc/apache2/sites-available# /etc/init.d/apache2 reload
[ ok ] Reloading apache2 configuration (via systemctl): apache2.service.</cli>
Samba
Pour pouvoir continuer à suivre les liens symboliques, il a fallu ajouter :
[global] follow symlinks = yes wide links = yes unix extensions = no