console linux

Ebauche : Mise à jour multiple WordPress sans plugin sur un mutualisé OVH

Si vous souhaitez faire les mises à jour de nombreux sites web, ce n’est pas évident à faire manuellement… Il faut bien en faire un de test manuellement pour voir que les mises à jour ne « cassent » rien. Mais pour les dizaines de sites à mettre à jour après, cela risque d’être long et pénible….

Vous pouvez passer par des plugins qui permettent de centraliser la gestions de vos sites WordPress, mais cela vous fait un plugin de plus et surtout un accès depuis l’extérieur vers vos sites… Niveau sécurité il y a mieux….

Mais il y a une solution à cela : La mise à jour en Bash depuis une connexion SSH. Que ce soit sur un VPS ou sur un hébergeur, il est tout à fait possible de le faire. Dans le cadre d’un VPS ou d’un dédié, vous avez tous les droits et cela ne posera aucun souci. Dans un hébergement mutualisé comme OVH, vous n’avez pas accès au réseau de base en ssh… Il faut donc ruser…

console linux

Bacula – nettoyage de printemps des volumes inutilisés

Si vous avez un manque d’espace pour Bacula, ceci peut peut-être bien vous aider, mais pas vous sauver… Il faut toujours bien penser à son dimensionnement d’espace disque nécessaire dès le départ.

Mais parfois il arrive que vous faites des changements importants, comme changer les pools utilisés par certains jobs. A ce moment là, vous risquez d’avoir beaucoup de volumes qui n’ont plus de jobs associés une fois la période de rétention passée.

Cas concret :

Vous révisez votre façon de sauvegarder avec Bacula et vous décidez de dissocier les backups systèmes et backups data. Ceci afin d’avoir une rétention de 3 mois sur les systèmes et 12 mois sur les data. Cela vaut aussi pour séparer des données critiques avec rétention de 10 ans et des données temporaires de projets de < 6 mois. Les volumes des deux pools sont sur le même disque physique (une grosse baie RAID par exemple).

Si vous modifiez les jobs « data » du pool de 3 mois vers celui de 12 mois, il faut savoir que les volumes de ce pool de 3 mois seront toujours là. Ce qui est normal vu que la rétention de 3 mois est toujours active. Après les 3 mois passé, les jobs sont retirés du catalogue, et les volumes sont toujours présents afin d’être recyclés si besoin. Mais au vue de nos changements, ce nombre de volumes prêts à être recyclés est trop important et prend de l’espace physique sur le disque inutilement.

C’est comme si vous 2 pools étaient 2 containers de cargo. Celui de 3 mois était plein, mais après changement il est à moitié vide. Pourtant il garde la même taille sur le cargo. On va donc réduire la taille de ce containers pour pouvoir en mettre un autre sur l’espace gagné.

Afin de gagner de l’espace sur le disque physique et d’avoir quelque chose de plus réaliste entre le volume de données Bacula et le volume réel des données, nous allons grappiller sur cet espace « perdu ».

console linux

mdadm augmentation du RAID howto

En temps que particulier, on a rarement tous les disques de la même taille. Dans mon cas, j’ai des disques de 1To, 1,5To et 2To. Et je compte remplacer le 1To. Le but est d’avoir un RAID sur une base de 1,5To et plus 1To. Voici la configuration en RAID5 :

  • 1To
  • 1,5To
  • 2To
  • 2To

Ce qui me donnait donc en RAID5 : (4-1 disques)*1To = 3To

Le dernier disque de 1To est à remplacer et je me présente donc avec des disques de 1,5To et 2To. On peut donc envisager d’utiliser toute l’espace disponible c’est à dire (4-1 disques)*1,5To=4,5To.

Pourquoi se priver de ces 1,5To supplémentaires sans trop de souci ?

console linux

mdadm problème de RAID durant un grow et optimisation RAID

Problème lors d’un grow mdadm

Durant un grow, l’opération sur le RAID à du être arrêtée par une coupure de courant… Si vous n’êtes pas équipé d’un UPS.

Voici l’état du RAID après redémarrage de la machine :

Pour reprendre le RAID à son état d’augmentation (reshape), il faut utiliser cette commande :

Voilà vous êtes sauvé, mais pensez à 3 choses à l’avenir : l’utilisation d’un fichier de sauvegarde de l’état du grow mdadm et aussi un UPS! Mais surtout pensez à sauvegarder vos données essentielles ailleurs! Un RAID n’est en rien une garantie de protection des données!

Source : unix.stackexchange.com

console linux

Owncloud 8 reset admin password

Si vous êtes très tête en l’air ou bien que l’owncloud de votre entreprise a un souci et le collègue qui l’a mis en place n’est vraiment pas disponible… Voici ce qui peut vous sauver ! Vous pouvez réinitialiser le mot de passe administrateur par un script prévu à cet effet.

Partez de la source de votre répertoire owncloud et suivez le guide! A voir si vous l’avez installé manuellement dans /var/www/owncloud ou via les paquets.

Les informations pour réinitialiser le mot de passe se situent dans le fichier suivant :

La manipulation se résume en 3 opérations :

Le nouveau mot de passe vous ai demandé et problème résolut!

 

console linux

Whatismyip – Obtenir son IP public et générer des alertes

Nous connaissons tous les sites whatismyip, ifconfig.me, etc ; qui permettent d’obtenir son adresse IP publique.

Il est intéressant d’avoir cette information également dans un script.

Cela peut se faire via la commande curl sur un des sites suivants :

  • http://ifconfig.me/ip
  • http://icanhazip.com

J’ai mis à disposition une page de test type Whatismyip qui vous renvoi votre adresse IP : http://myip.monlinux.net

Dans la suite de mon article, je vais l’utiliser pour un script python Centreon/Nagios avec la gestion d’erreur et la possibilité de tester différents sites si l’un d’eux est indisponible. Cela permet de tester sa connexion en plus du simple « ping ».

Concrètement cela peut servir dans ce type de cas :

  • Vous disposez de plusieurs IP de sortie : on peut vérifier que l’on sort avec la bonne IP, très utilise en cas l’erreur de natting dans le firewall.
  • Vous disposez de 2 lignes internet avec chacune une adresse IP différente pour avoir un failover et vous voulez détecter un basculement

Attention que ces tests ont des dépendances avec un service DNS à monitorer également dans Centreon ou Nagios 😉

logo openvpn notify

Openvpn notify – notification email de connexion utilisateur

Lorsque l’on souhaite mettre à disposition des employés un VPN, il est important de savoir qui l’utilise. Il existe évidement le log habituel, mais pas très pratique dans la majorité des cas.

Pour savoir qui est connecté en temps réel, on peut déjà utiliser cette option dans la configuration serveur l’OpenVPN :

Mais c’est encore mieux d’être averti par mail en live que quelqu’un se connecte à notre VPN OpenVPN !

Il faut ajouter ces 2 lignes dans le fichier de configuration serveur OpenVPN :

Cela permet à OpenVPN de faire appel à ces scripts lors d’une connexion ou déconnexion d’un client. Dans mon cas, c’est le même script, car des variables d’environnement permettent d’obtenir l’action (connect ou disconnect) et de gérer l’action désirée dans le script.

Les variables d’environnement servent à passer les paramètres d’OpenVPN dont on a besoin dans notre script. Il existe une liste liste impressionnante, voir le man d’openvpn à la section Environmental Variables.

Celles que j’ai utilisées :

  • $script_type : permet de récupérer l’action client-connect ou client-disconnect
  • $config : permet de récupérer le chemin absolut de la configuration vpn (pratique si on dispose de plusieurs VPN afin de les distinguer)
  • $common_name : le nom du client openvpn afin de savoir qui s’y connecte
  • $trusted_ip : l’IP publique par laquelle le client se connecte au VPN
  • $ifconfig_remote : l’IP interne du VPN obtenue par le client

Je vous livre mon script « tout fait qui va bien » dans la suite de cet article, il est personnalisable et sous licence GPLv3.