La valeur du chmod telle qu’elle apparaît dans le terminal est un peu esotérique. Prenons par exemple le chmod d’un fichier standard de WordPress : -rw-r-----, cela demande une petite gymnastique intellectuelle pour réaliser quels sont les droits véritables.
Je vous propose donc une petite commande qui va vous simplifier la vie, de manière à vous donner la valeur numérique du chmod des fichiers et répertoires.
Il vous suffit d’utiliser la commande stat comme ceci, dans votre fenêtre de terminal:
stat -c '%a %U:%G %n' *
Notes:
-c permet de formater la sortie avec la template entre apostrophes
Il peut être extrêmement utile d’activer la connexion SSH chez certains hébergeurs qui la proposent, comme SiteGround. Cela permet de gagner pas mal de temps, notamment lorsque l’on utilise wp-cli.
Mais avant de pouvoir se connecter, il faut d’abord l’activer dans les options de CPanel.
Activation de la connection SSH dans CPanel
Rendez-vous dans CPanel > Security > SSH Shell Access :
Ensuite, cliquez sur le bouton Manage SSH Keys:
Nous avons ensuite le choix entre deux solutions : soit nous créons la paire de clés privées/publiques sur le serveur et nous les copions sur notre machine locale, soit nous la créons en locale et l’envoyons sur le serveur. Je suis plutôt pour la seconde solution.
Création des clés SSH
On se rend dans le répertoire SSH de notre utilisateur et on liste le répertoire:
cd ~/.ssh
ls
Si le fichier id_rsa.pub existe déjà, il suffit d’afficher son contenu:
cat id_rsa.pub
Si le fichier n’existe pas, il suffit de le créer:
ssh-keygen
Copiez le contenu du fichier, il s’agit de la clé publique que nous allons importer dans CPanel.
Import de notre clé SSH dans CPanel
Cliquez sur Import Key:
Renommez la clé pour id_rsa puis collez le contenu de votre clé SSH publique:
Il ne vous reste plus qu’à vous connecter en SSH au serveur. Suivant votre hébergeur, le numéro du port SSH peut changer pour des raisons de sécurité. Chez SiteGround, SSH tourne sur le port 18765:
J’utilise mon NAS Synology tous les jours et l’une des fonctions que j’affectionne particulièrement est de pouvoir regarder des vidéos directement sur la télévision, en passant par la Freebox Revolution.
Il existe plusieurs manières de regarder les vidéos stockées sur le NAS sur la télévision : depuis la Freebox, depuis un navigateur avec VideoStation ou depuis votre mobile avec l’application DS Video.
Lire des vidéos avec fichiers de sous-titres depuis la Freebox
Il suffit de se rendre dans le menu Freebox > Disques et de sélectionner votre NAS, qui s’appelle par défaut « DiskStation » chez Synology.
Si le fichier de sous-titre porte le même nom que le fichier vidéo auquel il se rattache, alors la Freebox le chargera automatiquement. Vous pouvez alors le désactiver en appuyant sur la touche Menu verte de la télécommande Free.
C’est la méthode que j’utilise au quotidien mais il faut avoir prévu de télécharger les bons sous-titres, s’être assuré que le nom ne diffère pas et les avoir mis dans le même répertoire que le fichier vidéo… cela demande un peu de manutention avant de pouvoir se caler dans le canapé.
Lire des vidéos avec sous-titres chargés à la volée depuis le NAS
Une seconde solution consiste à lancer le fichier depuis le webdamin du Synology : démarrez l’application VideoStation et sélectionnez le fichier à lire.
Allumez ensuite votre télévision et le Freebox Player pour qu’il soit détecté par l’application VideoStation.
Si vous cliquez sur la petite icône Réglages du lecteur vidéo, il est possible de charger des sous-titres à la volée dans la section Sous-Titres :
Il ne vous reste plus qu’à sélectionner la destination vidéo vers laquelle envoyer la vidéo en flux DLNA dans la section Source. Ici, nous choisissons Freebox Player en DLNA:
Il suffit de cliquer sur le bouton lecture et la vidéo sera directement projetée sur la télévision par le biais du Freebox Player.
Lire vidéos et sous-titres depuis l’application mobile DS Video
Je vous ai gardé le meilleur pour la fin : vous pouvez lancer les vidéos du Synology et activer les sous-titres à la volée depuis l’application mobile DS Video, à installer sur votre téléphone portable.
Si vous utilisez Local by Flywheel pour développer un site WordPress en local, il peut arriver que la machine virtuelle ne réponde plus et ne veuille plus redémarrer, ce qui rend toute utilisation de Local impossible.
Voici donc comment redémarrer la machine virtuelle de Local by Flywheel.
Si la machine virtuelle ne répons plus, il faut redémarrer la VM local-by-flywheel dans VirtualBox.
Ouvrez VirtualBox
macOS: appuyez sur Command + Espace et tapez « VirtualBox » et validez avec Entrée pour ouvrir VirtualBox
Windows: ouvrez le menu Démarrer de Windows ettapez « VirtualBox » et validez avec Entrée pour ouvrir VirtualBox
Faites un clic droit sur local-by-flywheel et cliquez sur Fermer » Redémarrage ACPI
Attendez que la machine virtuelle affiche « Powered Off… »
Si la machine virtuelle n’affiche pas « Powered Off… » après 5 minutes, répétez l’étape 2 et sélectionnez Fermer > Éteindre.
Fermez VirtualBox
Ouvrez de nouveau Local
J’espère que cela peut vous aider. La machine virtuelle a souvent tendance à planter et fermer/réouvrir Local ne suffit pas toujours. Il faut vraiment relancer le conteneur sous VirtualBox puis relancer Local.
Sur l’un des serveurs de mes clients Codeable, j’ai mis à jour MariaDB de la version 10.1 à la version 10.3 et voici ce que retournait MariaDB lors du lancement de procédures:
ERROR 1558 (HY000): Column count of mysql.proc is wrong. Expected 21, found 20.
Created with MariaDB 100212, now running 100303.
Please use mysql_upgrade to fix this error
Si cela arrive, pas de panique: MaraDB fonctionne et le site s’affiche mais la base de données mysql n’a pas été mise à jour par apt, il faut lancer la procédure d’installation manuellement, depuis le terminal.
On met donc la base mysql à jour avec mysql-upgrade:
mysql_upgrade -u root -p
et on relance MariaDB:
service mysql restart
La routine de mise à jour mysql_upgrade permet de mettre à jour la base interne de MariaDB, qui évolue au fil des mises à jour.
Au redémarrage du service, plus de problème avec les procédures SQL.
Sur le serveur chinois que j’ai monté pour un de mes clients sur Codeable, le site a commencé à afficher des erreurs étranges : erreur 502 pour nginx sur certaines pages et des nombres étranges en lieu et place des données de la base de données.
Après un redémarrage des services PHP, nginx et mysql, je constate que MariaDB veut bien s’arrêter mais ne veut plus de lancer.
Voici ce que donne:
systemctl status mariadb.service
Résultat:
● mariadb.service - MariaDB database server
Loaded: loaded (/lib/systemd/system/mariadb.service; enabled; vendor preset: enabled)
Active: failed (Result: exit-code) since Mon 2019-04-22 18:14:22 CST; 59s ago
Process: 721 ExecStartPost=/bin/sh -c systemctl unset-environment _WSREP_START_POSITION (code=exited, status=0/SUCCESS)
Process: 718 ExecStartPost=/etc/mysql/debian-start (code=exited, status=0/SUCCESS)
Process: 12274 ExecStart=/usr/sbin/mysqld $MYSQLD_OPTS $_WSREP_NEW_CLUSTER $_WSREP_START_POSITION (code=exited, status=1/FAILURE)
Process: 12179 ExecStartPre=/bin/sh -c [ ! -e /usr/bin/galera_recovery ] && VAR= || VAR=`/usr/bin/galera_recovery`; [ $? -eq 0 ] && systemctl set-environment _WSREP_START_POSITION=$VAR || exit 1 (code=exited,
Process: 12176 ExecStartPre=/bin/sh -c systemctl unset-environment _WSREP_START_POSITION (code=exited, status=0/SUCCESS)
Process: 12173 ExecStartPre=/usr/bin/install -m 755 -o mysql -g root -d /var/run/mysqld (code=exited, status=0/SUCCESS)
Main PID: 12274 (code=exited, status=1/FAILURE)
Status: "MariaDB server is down"
systemd[1]: Starting MariaDB database server…
mysqld[12274]: 2019-04-22 18:14:19 140194687476288 [Note] /usr/sbin/mysqld (mysqld 10.1.26-MariaDB-0+deb9u1) starting as process 12274 …
systemd[1]: mariadb.service: Main process exited, code=exited, status=1/FAILURE
systemd[1]: Failed to start MariaDB database server.
systemd[1]: mariadb.service: Unit entered failed state.
systemd[1]: mariadb.service: Failed with result 'exit-code'.
Bon, chou blanc. Cela ne nous donne aucune information exploitable quand à l’erreur qui empêche le démarrage du service de base de données.
On regarde ensuite ce que nous donnent les logs de MariaDB:
tail -f /var/log/mysql/error.log
Résultat:
2019-04-22 18:14:19 140194687476288 [Note] InnoDB: Completed initialization of buffer pool
2019-04-22 18:14:19 140194687476288 [Note] InnoDB: Highest supported file format is Barracuda.
2019-04-22 18:14:19 140194687476288 [Note] InnoDB: 128 rollback segment(s) are active.
2019-04-22 18:14:19 140194687476288 [Note] InnoDB: Waiting for purge to start
2019-04-22 18:14:19 140194687476288 [Note] InnoDB: Percona XtraDB (http://www.percona.com) 5.6.36-82.1 started; log sequence number 11397472969
2019-04-22 18:14:19 140194687476288 [Note] Plugin 'FEEDBACK' is disabled.
2019-04-22 18:14:19 140194687476288 [ERROR] mysqld: Can't change size of file (Errcode: 28 "No space left on device")
2019-04-22 18:14:19 140194687476288 [ERROR] Can't init tc log
2019-04-22 18:14:19 140194687476288 [ERROR] Aborting
Là, c’est beaucoup plus intéressant. Visiblement, deux erreurs majeures sont à l’origine du non-démarrage du service:
il n’y a plus d’espace disponible sur le disque dur du serveur,
le fichier /var/lib/mysql/tc.log ne peut pas être initialisé.
Après un petit df, il s’avère que le client a installé un plugin de sauvegarde qui a littéralement saturé tout l’espace disponible.
Après un petit ménage, il ne reste plus qu’à gérer la seconde erreur, Can’t init tc log.
Le fichier /var/lib/mysql/tc.log peut parfois souffrir d’un problème de permission. Dans le cas du client, on l’archive par précaution:
A noter que l’erreur 502 de nginx n’était pas due à une mauvaise configuration du server block mais bien d’un manque d’espace disque. C’est important à vérifier, avant de se lancer dans la dissection du fichier de configuration d’nginx (qui n’aurait pas réglé le problème dans ce cas précis).
Réforme de la directive sur le droit d’auteur sur Internet
Le Parlement européen a donné son aval à la directive sur le droit d’auteur, un ensemble de lois controversé destiné à mettre à jour le droit d’auteur en Europe à l’ère de l’internet.
Les députés ont voté à 348 en faveur de la loi et 274 contre. Une proposition de dernière minute visant à supprimer la clause la plus controversée de la loi – connue sous le nom d’article 13 ou «filtre de téléchargement» – a été rejetée de près par cinq voix seulement.
La directive va maintenant être transmise aux États membres de l’UE, qui disposeront de 24 mois pour la traduire en droit national. La directive sur le droit d’auteur est en préparation depuis plus de deux ans et a fait l’objet d’un lobbying acharné de la part des géants de la technologie, des détenteurs de droits et des activistes des droits numériques.
Julia Reda, eurodéputée du parti pirate allemand qui a beaucoup dirigé l’opposition à la directive, a déclaré que c’était « un jour sombre pour la liberté de l’internet ». Andrus Ansip, vice-président de la Commission européenne et grand défenseur de la loi, a déclaré qu’il était un «grand pas en avant» qui unifierait le marché numérique européen tout en protégeant la «créativité en ligne».
Les détails de la législation devront être décidés par les différents États membres de l’UE, mais la loi aura probablement un impact considérable sur le fonctionnement d’Internet en Europe et au-delà. Comme nous l’avons vu avec le GRPD, la législation de l’UE sur la protection des données, la législation européenne peut influencer la politique américaine.
Les partisans de la directive ont déclaré qu’elle équilibrerait le terrain de jeu entre les géants américains de la technologie et les créateurs de contenu européens, en donnant aux détenteurs de droits d’auteur le pouvoir sur la manière dont les plates-formes Internet distribuent leur contenu.
Les critiques disent toutefois que la loi est vague et mal conçue, et finira par restreindre la façon dont le contenu est partagé en ligne, ce qui freine l’innovation et la liberté d’expression.
La nouvelle police d’Internet: la « taxe sur les liens » et le « filtre de téléchargement »
Les clauses les plus controversées de la directive sur le droit d’auteur – l’article 11 ou la « taxe sur les liens » et l’article 13 ou le « filtre de téléchargement » – sont restées en grande partie intactes.
L’article 11 permet aux éditeurs de facturer des plateformes telles que Google Actualités lorsqu’ils affichent des extraits d’articles d’actualité, tandis que l’article 13 (renommé Article 17 dans la version la plus récente de la législation) donne à des sites tels que YouTube de nouvelles obligations pour empêcher les utilisateurs de télécharger du contenu protégé par le droit d’auteur.
Dans les deux cas, les critiques disent que ces lois bien intentionnées créeront des problèmes. L’article 13, par exemple, pourrait conduire à l’introduction de «filtres de téléchargement» qui analyseront tout le contenu de l’utilisateur avant son téléchargement sur des sites afin de supprimer les éléments protégés par le droit d’auteur. La loi n’appelle pas explicitement de tels filtres, mais les critiques disent que ce sera inévitable, car les sites cherchent à éviter les pénalités.
Les défenseurs de la directive disent que les allégations selon lesquelles l’article 13 «tue les mèmes» sont des exagérations et que la législation prévoit des protections pour la parodie. Mais les experts affirment que tous les filtres introduits seront probablement source d’erreurs et inefficaces. Ils notent également que, compte tenu du coût de déploiement de cette technologie, la loi pourrait avoir l’effet inverse de son objectif: consolider accidentellement la domination des géants américains de la technologie sur les espaces en ligne.
Les effets possibles de la taxe sur les liens sont également difficiles à prévoir. La loi est principalement axée sur des services tels que Google Search et Google News, qui diffusent des extraits d’articles de presse. Google a déclaré que si les journaux choisissaient de facturer des licences pour ce matériel, ils seraient forcés de supprimer le contenu affiché dans Google News.
Les groupes du monde de la musique, de l’édition et du cinéma ont célébré l’adoption de la loi. « C’est un vote contre le vol de contenu », a déclaré Xavier Bouckaert, président de l’European Magazine Media Association, dans un communiqué de presse. «Les éditeurs de toutes tailles et les autres créateurs auront désormais le droit de définir des termes et des conditions pour que les autres utilisateurs réutilisent leur contenu à des fins commerciales, ce qui n’est que juste et approprié.»
La plupart des gens craignent au contraire que leur expérience du Web ne soit affectée, car la législation aura également un impact considérable sur les hommes d’affaires. «Quiconque développe une plate-forme avec des utilisateurs de l’UE impliquant le partage de liens ou de contenu est confronté à une grande incertitude», a déclaré Tal Niv, vice-président du droit et de la politique du dépositaire de codes GitHub, dans un communiqué. « Les conséquences sont notamment l’impossibilité de développer les fonctionnalités attendues par les internautes et l’obligation de mettre en oeuvre un filtrage automatisé très coûteux et inexact. »
Message de George Orwell
Cela va conduire à encore plus de chiffrement des réseaux… et c’est George Orwell (ou bientôt George TORwell!) qui adresse un important message à tous les utilisateurs des Internets !
Il existe certaines situations dans lesquelles le plugin WooCommerce est mis à jour mais la mise à jour de la base de données du plugin échoue.
Cet échec de la mise à jour de la base de données est généralement causé par le délai d’attente de PHP, en particulier sur l’environnement d’hébergement partagé, puisque PHP ne dispose que de 60 secondes pour s’exécuter via une requête Web.
La non-concordance de version entre la version de la base de données WooCommerce et celle du plugin WooCommerce peut être à l’origine de problèmes.
Mise à jour de la base WooCommerce en ligne de commande
Pour résoudre ces problèmes, nous pouvons mettre à jour la base de données WooCommerce via la ligne de commande, en utilisant wp-cli.
1. Connectez-vous au serveur en SSH.
2. Naviguez jusqu’à la racine du site via SSH et exécutez la commande de mise à jour de WooCommerce:
wp wc update
Pour une grosse base de données, cela peut prendre un certain temps. Voici le résultat que vous devriez obtenir une fois le processus de mise à jour de la base de données terminé :
wp wc update
Calling update function: wc_update_350_db_version
Success: 2 updates complete. Database version is 3.5.0
3. Vérifiez dans WooCommerce > Status que la version de la base de données correspond bien à la version du plugin WooCommerce.
Vous lisez actuellement cet article depuis le nouveau serveur de SkyMinds, baptisé ORION.
De mail à ORION
Le serveur précédent a été le théâtre d’une multitude de tutoriels consacrés à la série Monter un serveur dédié de A à Z, tournait sous Debian (6, 7, 8, et 9) mais était un peu limité en termes de ressources (Intel Core2 Quad Q8300 @ 2.50GHz, 4 Go de RAM, 750 Go de disque). Tant qu’il n’y avait qu’un seul site à gérer, cela convenait mais avec près d’une dizaine de sites, on touchait les limites.
ORION est bien plus confortable : Intel Xeon W3530 @ 2.80GHz, 32 Go de RAM, 2 To de disque en RAID). De quoi pouvoir monter en charge tranquillement :)
Du changement dans notre stack
Qui dit nouveau serveur, dit refonte de la stack. Vu que nous partons d’un environnement vierge, autant partir du bon pied et utiliser toutes les dernières innovations. Le serveur précédent datait de 2012 et, même s’il tournait parfaitement, il a connu pas mal de mises à jour (parfois pas très stables).
J’ai donc décidé de changer d’OS pour ORION : même si j’adore travailler sous Debian, je me suis dit que j’allais tenter Ubuntu Server 18.04 LTS. Certains tutoriels ne sont pas exactement équivalents entre Debian et Ubuntu Server donc cela promet quelques nouveaux tutoriels !
Objectif performance
Le but du nouveau serveur est d’être un peu plus à l’aise au niveau des ressources, surtout si les sites lancés récemment prennent de l’ampleur. Cela donne également un peu plus d’oxygène au serveur de bases de données.
L’autre objectif est un objectif de performance : monter un serveur dédié de manière simple et efficace, en privilégiant la sécurité et la rapidité des sites hébergés.
Voilà, c’est tout pour la note de service. Les tutoriels sont en cours d’écriture, donc bientôt disponibles sur le site !
J’ai récemment monté un nouveau serveur qui utilise MySQL 8 et après quelques jours d’utilisation, je me suis rendu compte que l’espace disque avait considérablement augmenté.
La cause ? Une multitude de fichiers logs binaires dans le répertoire d’exécution de MySQL 8 : il y en avait pour plus de 260 Go !
Les fichiers logs binaires enregistrent toutes les requêtes qui ont été effectuées par le serveur de bases de données. Inutile de dire qu’il est assez improbable que vous cherchiez à savoir quelles requêtes ont été lancées le mois dernier!
Désactivation des logs binaires
Sous MySQL 8, voici comment désactiver les logs binaires : éditez le fichier de configuration de MySQL:
nano /etc/mysql/mysql.conf.d/mysqld.cnf
et ajoutez cette ligne sous [mysqld] :
skip-log-bin
Vous pouvez également vous connecter au serveur MySQL en ligne de commande:
mysql -u root -p
et lancer la commande suivante dans l’invite de commande MySQL:
SET sql_log_bin = 0;
PURGE BINARY LOGS BEFORE '2019-03-31';
Relancez ensuite le serveur MySQL:
service mysql restart
Il ne vous reste plus qu’à vous rendre dans le dossier d’exécution de MySQL – /etc/mysql par défaut, sauf si vous l’avez modifié – et supprimer les fichiers binlog*.
Voici un tutoriel qui vous permet de supprimer les kernels linux installés sur votre serveur/machine qui ne sont pas actuellement utilisés.
Cela est utile pour faire un peu de ménage sur la partition /boot, idéalement avant qu’elle ne soit complètement saturée. Sinon, je vous donne aussi l’astuce pour faire le ménage manuellement et retrouver APT complètement opérationnel.
Ce tutoriel a été testé sous Ubuntu Server 18.04 LTS, il est complètement transférable sous Ubuntu et Debian.
Cas de figure 1: /boot n’est pas plein à 100% et apt est opérationnel
1. On vérifie la version actuelle du kernel
uname -r
Cela nous donne la version du noyau sous laquelle tourne notre machine:
You will get the list of images something like below:
linux-image-4.15.0-45-generic
2.b. On supprime les vieux kernels (un par un)
sudo apt purge linux-image-4.15.0-45-generic
Une fois que les vieux kernels sont supprimés, on supprime également les paquets qui seront maintenant obsolètes:
sudo apt autoremove
Et on finit par la mise à jour de la liste des noyaux de GRUB:
sudo update-grub
Voilà, il ne vous reste plus qu’à rebooter votre machine ou votre serveur. Il ne reste que le dernier kernel.
Cas de figure 2 : apt est indisponible car /boot est plein à 100%
NOTE: cette partie du tutoriel n’est valable que si et seulement si vous ne pouvez utiliser APT parce que la partition /boot est pleine à 100%.
1. Listez les images de kernel
Obtenez la liste des images de kernels et faites la liste des kernels que vous pouvez supprimer car ils ne sont plus utilisés. Cette commande vous montre les kernels installés à l’exception de celui qui est en cours d’utilisation:
Vous devez préparer la commande qui va supprimer tous les kernels inutilisés en utilisant la brace expansion pour vous simplifier la vie. Je vous conseille d’écrire la commande dans un éditeur de texte et de bien la vérifier avant de la lancer dans le terminal.
N’oubliez pas d’exclure le kernel actuel ainsi que les deux kernels les plus récents pour pallier tout problème:
sudo rm -rf /boot/*-3.19.0-{59,61,65}-*
3. Nettoyez APT et ses messages d’avertissement à propos d’une installation partielle
sudo apt-get -f install
4. Autoremove
Enfin, on lance la commande autoremove pour supprimer les paquets relatifs aux vieilles images de kernel qui ont été rendues orphelines par le nettoyage manuel de /boot :
sudo apt autoremove
5. Mise à jour de GRUB
sudo update-grub
6. APT est opérationnel
Vous pouvez de nouveau utiliser APT et mettre à jour, installer et supprimer les paquets de votre distribution:
Je considère ici que l’installation de Flexget est déjà opérationnelle.
Installation de subliminal
S’il n’est déjà présent sur votre serveur/poste de travail, installez subliminal:
pip install subliminal
Configuration des sous-titres
Editez le fichier de configuration de FlexGet, config.yml et ajoutez-y cette nouvelle tâche:
tasks:
get-subtitles:
filesystem:
path:
- d:\media\incoming # on Windows
- /home/incoming # unix
regexp: '.*\.(avi|mkv|mp4)$' # only include filenames with these extensions
recursive: yes
accept_all: yes
seen: local # seen shouldn't interfer with anything outside this subtitles task
subliminal:
languages:
- eng
alternatives:
- fra
exact_match: yes
#only use the following providers
providers: [addic7ed, opensubtitles, tvsubtitles]
single: no
hearing_impaired: yes
authentication: #consider using the variables plugin
addic7ed:
username: my_user
password: my_password
opensubtitles:
username: other_user
password: other_passsword
Pensez à éditer le chemin du répertoire qui contient vos fichiers vidéo (lignes 5-6), suivant que vous êtes sous Windows ou Unix. N’oubliez pas de mettre les identifiants de compte addic7ed et opensubtitles.
Il ne vous reste plus qu’à lancer FlexGet et celui-ci se chargera de récupérer les sous-titres de tous les fichiers vidéos contenus dans le répertoire que vous avez défini dans la configuration:
