Catégorie : Non classé

Pas de commentaire

Extension de partition sur Debian Jessie grâce à GParted

  de

Comme évoqué dans mon précédent article, je me suis confronté à un problème d’espace disque sur ma machine virtuelle faisant fonctionner Plex Media Server. Je vais donc procéder à l’augmentation de la taille du disque virtuel pour élargir la partition /dev/sda1 qui a besoin de plus d’espace.

Première étape, l’extension de disque dans la console ESXi elle-même ; étant donné que je suis en 6.5 et que ma machine virtuelle est de version 12 – si mes souvenirs sont corrects – je suis obligé de passer par l’interface web, bien que je préfère très nettement le client lourd. Mon datastore composé de deux disques durs de 3 To en RAID 1 me le permettant très largement, je passe de 60 Go à 100 Go.

Etant donné qu’à l’installation de Debian, je n’ai pas séparé certains répertoires sur des partitions distinctes (/var, /home par exemple) – ce qui n’est pas très propre, j’en conviens, mais plus facile pour gérer l’espace libre lorsqu’on est pas aguerri sur Debian – je suis condamné à réaliser l’élargissement avec GParted en live CD.

Il faut donc démarrer sur le disque virtuel, en pressant échap dans la console VMware.

Puis on arrive sur cet écran :

On choisit la première option, vient par la suite la configuration du clavier, rien de difficile. Il faut ensuite confirmer la disposition de celui-ci.

Une fois l’initialisation terminée – ce qui peut prendre quelques minutes – on arrive sur l’écran principal de l’application GParted qui présente l’état du stockage.

Confirmation de la bonne extension du VMDK : on a 40 Go non alloués. Je ne peux étendre directement /dev/sda1, car comme cela est visible sur le graphique, mon espace non alloué est après la partition étendue et le swap. Je vais donc devoir supprimer le swap, la partition étendue, puis étendre /dev/sda1 et recréer une partition et le swap.

Une fois le disque étendu, on valide l’écriture sur le disque. Si tout s’est bien passé, /dev/sda1 a bien été étendue à environ 100 Go – car il ne faut pas oublier de laisser un peu de place pour le swap ! – puis on procède à la recréation de la partition étendue, puis du swap.

On écrit de nouveau les modifications sur le disque.

Une fois l’écriture terminée, on constate que tout semble s’être bien déroulé : /dev/sda1 a été agrandie, et le swap a bien repris sa place et son point de montage.

Un simple redémarrage plus tard – il y a un raccourci pour faire un redémarrage proprement sur le « bureau » du live CD, df nous indique bien que /dev/sda1 a grossi pour nous offrir quelques dizaines de Go supplémentaires.

Pas de commentaire

Crash de Plex Media Server et googledrive-ocaml-fuse

  de

Après quelques mois de fonctionnement sans problèmes particuliers de Plex en duo avec googledrive-ocaml-fuse dont l’installation à été expliquée dans ce billet, hier soir il m’a été impossible  d’accéder à Plex. Comme cela était déjà arrivé par le passé, le service plexmediaserver se met en carafe et il faut donc le relancer.

service plexmediaserver stop
service plexmediaserver start

Tout simplement… sauf qu’hier, le service n’a pas voulu se stopper, ni même se relancer. Le status m’indiquait que le service était en train de s’arrêter mais visiblement bloqué sur cet état d’arrêt. Je pensais alors qu’un petit ps -u plex afin de récupérer le PID du processus Plex Media Server suivi d’un kill <PID> suffirait pour tuer le service et pouvoir le relancer. Cependant, j’ai été un peu surpris lorsque j’ai exécuté le kill puis refait un ps -u plex pour m’assurer de la bonne exécution que le processus apparaissait en <defunct>.

Je me retrouvais donc avec un processus zombie qui ne voulait visiblement pas partir. Bien que je pense que le processus parent soit tout simplement init, je voulais en être sur, et un ps -ef –forest me l’a confirmé, car le parent avait pour PID 1. J’allais devoir lancer un telinit U pour relancer init et le forcer à dégager ce zombie.

Une fois cette instruction envoyée, j’ai pu relancer le service normalement et Plex semble avoir fonctionné quelques minutes, avant un nouveau crash. Cette fois-ci, avant de vouloir arrêter et relancer le processus, je demande à voir le statut. Malgré tout, il fonctionne, mais l’interface est inaccessible. Quelque chose que je n’avais pas vu au départ me saute aux yeux désormais : Plex ne peut fonctionner correctement car /dev/sda1 est plein. Surpris, je vérifie avec un df et en effet, son utilisation était à 100%.

En réalité, après trois mois d’utilisation et des centaines d’épisodes de série ou de films téléchargés sur le serveur depuis Google Drive, le cache de googledrive-ocaml-fuse était arrivé à saturer le disque dur. Surprenant, car j’avais configuré le cache pour qu’il utilise au maximum 10 Go – peut-être une mauvaise idée compte tenu de la taille du disque virtuel qui est de 40 Go. Cela signifie que le système et les applicatifs ont grossi d’eux-mêmes avec les mises à jour entre autres. J’ai donc nettoyé le cache de googledrive-ocaml-fuse.

eval `opam config env`
googledrive-ocaml-fuse -cc

Et, là :

J’ai pu relancer le service, et Plex respire et peut de nouveau streamer proprement.

Maintenant, afin d’éviter que cela se reproduise, deux solutions : soit réduire la taille du cache à 5 Go, soit augmenter la taille du disque virtuel. J’ai réalisé dans l’urgence une réduction de la taille du cache à 5 Go dans le fichier de configuration (voir cet article pour plus de détails) et je ferai ce week-end ou un peu plus tard une extension à 60 Go du disque virtuel de mon serveur Plex pour pouvoir rétablir le cache à 10 Go, ce qui devrait empêcher de futurs crashs.

Pas de commentaire

Accéder à un serveur FTP situé derrière un routeur

  de

Un ami qui partait en vacances et qui souhaitait sauvegarder les vidéos de son drone afin de pouvoir libérer la mémoire interne avait besoin d’un espace en ligne pour déposer les fichiers car sa tablette Android n’avait pas une capacité suffisante. J’ai donc ouvert sur le web mon serveur FTP personnel situé sur mon Cloud personnel. Je vais donc détailler les quelques pas nécessaires à la bonne configuration du serveur FTP afin qu’on puisse y accéder depuis le web même si il est situé derrière un routeur.

J’ai réalisé cette opération en me servant d’un routeur virtuel pfSense car mon serveur FTP est hébergé sur un serveur vSphere ESXi, ainsi que de FileZilla Server pour Windows, sur un 2012 R2. Pour des raisons de simplicité, j’ai utilisé le port 21 afin d’éviter des incompatibilités avec les clients FTP disponibles sur Android.

Etant donné qu’il est placé derrière un routeur, le serveur ne doit pas agir en mode actif, mais en mode passif. Le mode passif nécessite d’être configuré dans FileZilla, car afin de fonctionner correctement, il faut lui spécifier l’IP externe de la machine physique, c’est à dire, par exemple, 87.32.38.143, et non l’IP du serveur FTP sur le réseau local, qui pourrait être 192.168.1.2. Ensuite, un range de ports pour que le mode passif fonctionne, et le tour est joué.

A titre d’exemple, j’ai utilisé le range de ports 30000-30100 car il n’était utilisé par aucune autre application sur l’hyperviseur.

Il faut maintenant ouvrir et router correctement les ports, ce qui n’a rien de difficile. Sur pfSense, il m’a suffit de rediriger vers le serveur FTP les requêtes TCP sur le port 21 sur le range 30000 à 30100. Le test montre bien que tout communique sans problème :

Pas de commentaire

Mise à jour de Debian Jessie (8.x) vers Stretch (9.0)

  de

Il y a un peu plus d’un mois, Debian Stretch pointait le bout de son nez pour succéder à Jessie sortie en 2015. Bien que Jessie soit supportée jusqu’en 2020, j’ai décidé de mettre à jour par curiosité ma machine Debian virtuelle qui me sert de bureau internet.

Je vais donc mettre à jour ma Debian 8.8 avec un environnement graphique MATE vers 9.0. Cela n’est pas très difficile, mais je vais détailler les étapes nécessaires à la mise à jour, que cela concerne un système avec environnement graphique ou non. Je vous renvoie vers ce lien si vous souhaitez avoir plus de détails sur ce qui change avec Stretch.

Bien entendu, avant une telle mise à jour, il est de bon ton de sauvegarder ses données, ses fichiers de configuration et bien vérifier la compatibilité de certaines applications ou librairies. Dans mon cas, cette machine n’étant qu’un petit bureau avec un navigateur et quelques applis, comme un PC domestique.

Tout d’abord, mettre à jour les paquets pour être sûr de partir sur les derniers paquets disponibles pour Debian 8.

apt-get update && apt-get upgrade

Si tous les paquets sont à jour, on doit se trouver sur une version 8.8 : une vérification ne fait pas de mal :

cat /etc/debian_version

Ensuite, avec un éditeur de texte, il va falloir éditer le fichier sources.list après en avoir fait une copie.

cp /etc/apt/sources.list /etc/apt/sources.list.old
nano /etc/apt/sources.list  

Cela devrait donner quelque chose ayant cette forme, avec plus ou moins de lignes évidemment en fonction des dépôts qui ont été ajoutés dans ce fichier (ils peuvent également être dans d’autres répertoires). Chaque ligne correspondant à un dépôt qui est interrogé par le système en cas de requête de mise à jour de paquet. On va donc procéder à la modification de Jessie en Stretch afin que le système aille chercher les paquets pour Stretch et plus pour Jessie.

De Jessie…
… vers Stretch

Ensuite, on relance une mise à jour pour redescendre les paquets Stretch et mettre à niveau vers 9.0 !

apt-get update && apt-get dist-upgrade
reboot 

Et enfin, après un redémarrage, on peut de nouveau profiter du système avec quelques changements cosmétiques visibles dès l’écran de connexion.