Tag - linux

Entries feed

Tuesday, March 10 2015

Se maintenir au top de la sécurité SSL/TLS en faisant le ménage sur sa suite de chiffrements (cipher suite)

Le monde de la sécurité informatique est en perpétuelle évolution et les chiffrements jugés solides à un instant T ne le sont plus forcément à T+1 ! En novembre dernier, je proposais un paramétrage qui permettait alors d'obtenir la note maximale sur Qualys SSLLabs https://www.ssllabs.com (ce qui n'est bien sûr pas une fin en soi mais qui est un indicateur facile du niveau de sécurité atteint... si l'on fait confiance aux gens de Qualys).

Cependant, les attaques sur l'algorithme de chiffrement RC4 se sont multipliées et celui-ci a été récemment déclaré comme faible et déconseillé donc pour l'établissement de connexions sécurisées. Diable, il faut donc mettre à jour la suite de chiffrements utilisés pour écarter ce chiffrement !

Heureusement, les gens de Mozilla (encore eux !) nous rendent la tâche aisée en publiant une série de 3 suites de chiffrement selon le niveau de sécurité et le niveau de rétro-compatibilité souhaités (avec de vieux navigateurs / de vieux OS) : https://wiki.mozilla.org/Security/Server_Side_TLS

En date du 10 mars, la suite de chiffrement conseillée pour le plus haut niveau de sécurité est la suivante :

Ciphersuite: ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!3DES:!MD5:!PSK

Voilà qui devrait aider les administrateurs à optimiser la sécurité des connexions SSL/TLS proposées par leurs serveurs !

Thursday, January 8 2015

Activer un réseau Wifi invité sur un routeur avec le micrologiciel TomatoUSB

Nous allons détailler ici les étapes nécessaires pour activer un Wifi "invité" sur un routeur muni du micrologiciel Tomato (TomatoUSB). Par Wifi invité, j'entends un Wifi indépendant du Wifi principal : idéal par exemple pour partager sa connexion avec un voisin ou un ami que l'on ne souhaite pas voir fureter sur son réseau interne. Bien aussi pour les petites entreprises qui veulent présenter à leurs visiteurs un Wifi avec accès à internet mais déconnecté du reste du réseau de l'entreprise.

Voici donc comment procéder.

Etape 1 : créer une interface LAN spécifique avec son propre intervalle d'IP, son propre DHCP...

Dans TomatoUSB, dans l'onglet LAN, vous devriez vraisemblablement voir le bridge par défaut br0 correspondant à votre interface principale d'accès au Web. Nous allons ajouter une nouvelle interface br1 avec son propre DHCP et son propre intervalle d'IP.

guest-wifi-img1.png

Etape 2 : créer une interface sans fil virtuelle

Dans les fonctions avancées du micrologiciel TomatoUSB, nous allons cette fois ajouter une interface sans fil virtuelle.

guest-wifi-img2.png

Evidemment, il conviendra de choisir un code de sécurité différent de celui de l'interface principale !

Etape 3 : on place chaque réseau dans des VLANs distincts

On crée un nouveau VLAN distinct du VLAN principal utilisé pour br0. On branche donc br1 sur ce VLAN et voilà un bon cloisonnement !

guest-wifi-img3.png

Etape 4 : on rajoute une couche d'iptables

Dans Administration->Scripts, on ajoute les règles suivantes au pare-feu (iptables) pour n'autoriser aucun échange entre les 2 bridges.

iptables -P FORWARD DROP
iptables -A FORWARD -i eth0 -o br0 -j ACCEPT
iptables -A FORWARD -i br0 -o eth0 -j ACCEPT
iptables -A FORWARD -i eth0 -o br1 -j ACCEPT
iptables -A FORWARD -i br1 -o eth0 -j ACCEPT

et hop le tour est joué !

Imprimante SL-M2020 sur Linux : tout fonctionne !

L'imprimante SL-M2020 est une petite imprimante laser économique commercialisée par Samsung. Elle fonctionne parfaitement sous Linux. Des drivers officiels pour Linux sont disponibles sur le site de Samsung : ils comprennent un script d'installation (compatible x86, amd64 et également arm !), des binaires et un PPD spécifique.

L'imprimante est bien reconnue, sort les pages rapidement, aucun souci avec Linux !

Que demander de plus !

Sunday, January 4 2015

Surveiller un changement de page web avec urlwatch

urlwatch est un super outil pour surveiller les changements d'une page web. Il est facile à utiliser pour détecter un changement mais également en afficher la teneur à l'aide d'un diff.

Utilisation de base

  • on spécifie une liste d'URLs à surveiller dans un fichier /home/bob/liste-des-urls avec une URL par ligne
  • on exécute urlwatch avec cette commande :
urlwatch --urls=/home/toto/liste-des-urls
  • urlwatch conserve alors automatiquement une version de la page (par défaut dans ~/.urlwatch)
  • quand on l'exécute une nouvelle fois, une comparaison est faite et toute modification est mise en avant

Des filtres plus complexes

Il est possible de coder en Python des filtres spécifiques (applicables par exemple à certaines URLs seulement) : par exemple suppression des zones de publicité, suppression de parties de page non pertinentes, ... Quelques exemples sont donnés ici.

Et hop, dans cron, pour un suivi régulier !

On peut bien sûr placer la commande dans cron pour une surveillance régulière automatique. La commande ci-dessous exécute urlwatch et envoie les résultats (s'ils sont non vides) à une adresse électronique :

urlwatch --urls=/home/toto/liste-des-urls | ifne mail -s "URL Watcher - un changement !" bob@courriel.fr

Friday, January 2 2015

Sauvetage boot EFI sur portable Asus

Patatra, un Kernel Panic sur son Asus X301A et le voilà qui refuse de booter sans donner d'explications : à chaque démarrage, seul le BIOS du système s'affiche... Ennuyeux.

Pour essayer de comprendre, on boote sur une clé USB contenant SystemRescueCD et rapidement on découvre que la partition /dev/sda1 (utilisée pour stocker les éléments nécessaires pour le boot EFI), 1 Mo formatée en FAT32, est corrompue ("dirty bit", sûrement à cause de l'extinction subite lors du Kernel Panic.

On essaye déjà de réparer le système de fichiers par :

fsck.vfat -a /dev/sda1

Puis on re-démarre mais rien ne change.

Il semble que le BIOS ne parvienne pas à détecter tout seul la présence de l'amorceur Grub sur la partition EFI - et qu'il ne soit possible de modifier la séquençage d'amorçage EFI que depuis un système lui-même lancé par EFI.

Qu'à cela ne tienne : on reboote sur le disque de sauvetage SystemRescueCD et on effectue alors les opérations suivantes :

  • on monte la partition EFI dans /boot/efi
mkdir /boot/efi
mount /dev/sda1 /boot/efi
  • on trouve le fichier grubx64.efi dans EFI/debian/ et on le copie dans EFI/boot/ en le renommant bootx64.efi
mkdir /boot/efi/EFI/boot
cp /boot/efi/EFI/debian/grubx64.efi /boot/efi/EFI/boot/bootx64.efi

Et hop, on reboote. Normalement, le bios EFI cherche par défaut le fichier bootx64.efi donc Grub devrait apparaître à l'écran. On peut alors booter normalement dans le système d'exploitation, puis, pour ramener la situation à la normale, réinstaller Grub proprement. En effet, quand il s'installe, Grub paramètre intelligement les paramètres EFI donc il va pouvoir ré-apprendre au BIOS à aller chercher EFI/debian/grubx64.efi.

grub-install /dev/sda1

Entretenir et sécuriser Nextcloud/ownCloud avec logrotate et fail2ban

On ne présente plus ownCloud/Nextcloud, plateforme de stockage et partage de fichiers fort aboutie. Pour ceux qui hébergent leur propre instance d'ownCloud/Nextcloud, voici deux petites astuces pour bien entretenir et sécuriser l'installation.

La rotation des logs

La rotation des logs évite que le fichier owncloud.log n'occupe une place trop importante sur votre serveur. On pourra utiliser logrorate pour effectuer la rotation automatique et régulière.

Dans /etc/logrotate.d/owncloud, on placera le paramétrage (assez explicite) suivant :

/var/www/owncloud/data/owncloud.log {
        weekly
        missingok
        rotate 8
        compress
        notifempty
        create 640 www-data www-data
}

et le tour est joué. On prendra bien sûr le soin d'adapter le chemin vers le fichier et le nom de l'utilisateur créateur du fichier (ici www-data car c'est l'utilisateur propriétaire du serveur web sous Debian) ! Si l'on utilise Nextcloud plutôt qu'ownCloud, on remplacera owncloud.log par nextcloud.log sans surprise !

Surveillance avec fail2ban

Fail2ban est capable de détecter des connexions non autorisées et de bannir (via iptables) l'adresse IP offensante. Un éventuel attaquant n'aura ainsi pas tout le loisir de tester les combinaisons nom d'utilisateur / mot de passe à son aise. Concrètement, on paramètre fail2ban pour vérifier régulièrement un fichier de log et pour détecter dans ce fichier les tentatives d'accès frauduleuses (i.e. qui se répètent). Puis, quand une tentative frauduleuse est repérée, on bannit l'adresse IP correspondante.

Nous allons créer un nouveau filtre pour fail2ban dans /etc/fail2ban/filter.d/owncloud.conf :

[Definition] 
#Pour owncloud <8
failregex = {"app":"core","message":"Login failed:(.*)IP: '<HOST>'
#Pour owncloud 8
failregex = {"reqId":".*","remoteAddr":".*","app":"core","message":"Login failed: '.*' \(Remote IP: '<HOST>', X-Forwarded-For: '.*'\)","level":2,"time":".*"}

Si l'accès est contrôlé par un proxy, on pourra modifier la règle pour repérer l'adresse IP associée au champ X-Forwarded-for :

[Definition]
#Pour owncloud <8
failregex = {"app":"core","message":"Login failed:(.*)X-Forwarded-For: '<HOST>'
#Pour owncloud 8
failregex = {"reqId":".*","remoteAddr":".*","app":"core","message":"Login failed: '.*' \(Remote IP: '.*', X-Forwarded-For: '<HOST>'\)","level":2,"time":".*"}

On peut alors créer une nouvelle règle dans /etc/fail2ban/jail.local :

[owncloud]
enabled  = true
port     = http,https
filter   = owncloud
logpath  = /var/www/owncloud/data/owncloud.log
maxretry = 6

et désormais, toute tentative d'accès répétée conduira à l'exclusion de l'IP douteuse !

'PS Merci à Arnaud Collarde pour la mise à jour de l'expression régulière pour ownCloud 8 et à Guillaume pour mise à jour de la regexp pour Nextcloud 15 qui m'indique que celle-ci pourrai ressembler à

failregex ={"reqId":".*","level":2,"time":".*","remoteAddr":".*","user":".*","app":"core","method":".*","url":".*","message":"Login failed: '.*' \(Remote IP: ''\)","userAgent":".*","version":".*"}

Sunday, December 28 2014

Errors were encountered while processing: sane-utils

Petit problème rencontré avec Debian lors d'une mise à jour :

The following partially installed packages will be configured:
  sane-utils 
No packages will be installed, upgraded, or removed.
0 packages upgraded, 0 newly installed, 0 to remove and 1 not upgraded.
Need to get 0 B of archives. After unpacking 0 B will be used.
Setting up sane-utils (1.0.24-7) ...
saned:x:109:115::/home/saned:/bin/false
Moveing homedir from /home/saned to /var/lib/saned
usermod: user saned is currently used by process 1799
dpkg: error processing package sane-utils (--configure):
 subprocess installed post-installation script returned error exit status 8
Errors were encountered while processing:
 sane-utils
E: Sub-process /usr/bin/dpkg returned an error code (1)
Failed to perform requested operation on package.  Trying to recover:
Setting up sane-utils (1.0.24-7) ...
saned:x:109:115::/home/saned:/bin/false
Moveing homedir from /home/saned to /var/lib/saned
usermod: user saned is currently used by process 1799
dpkg: error processing package sane-utils (--configure):
 subprocess installed post-installation script returned error exit status 8
Errors were encountered while processing:
 sane-utils

Cela semble pouvoir se régler en tuant le processus 1799 puis en effectuant la modification de dossier 'home' manuellement pour l'utilisateur saned :

kill 1799
usermod -d /var/lib/saned saned

Et hop le tour est joué !

Bonne journée.

Wednesday, December 10 2014

Activer la recherche des commandes historiques dans ZSH

J'ai réalisé que par défaut, il n'était pas possible de rechercher dans l'historique des commandes avec mon shell ZSH (avec la commande Ctrl+R que j'avais déjà utilisée avec d'autres shells). Quà cela ne tienne ! Paramétrons correctement le ~/.zshrc pour réactiver cette fonctionnalité.

Il suffit d'ajouter ces quelques lignes à son .zshrc (celui de son /home ou bien celui général /etc/zsh/zshrc si l'on veut que cela s'applique à tous les utilisateurs) :

bindkey -v
bindkey '^R' history-incremental-search-backward
HISTSIZE=1000
SAVEHIST=1000
HISTFILE=~/.history

pour que désormais Ctrl+R permette d'activer la recherche de commandes historiques, avec par défaut les 1000 dernières commandes saisies enregistrées.

Attention, n'oubliez pas de faire attention alors à tout mot de passe saisi à un moment ou un autre en clair en ligne de commande (par exemple pour se connecter à un FTP, un partage Samba, un webdav...) car alors le mot de passe en clair sera conservé visible dans l'historique jusqu'à sa péremption !

Modifier le registre de Windows depuis Linux

Vous connaissiez peut-être chntpw pour modifier le mot de passe d'un utilisateur Windows depuis un LiveCD linux ?

Et bien, bonne nouvelle, chntpw est encore plus puissant que cela : il permet de modifier aussi le registre de Windows depuis un LiveCD (par exemple System Rescue CD qui inclut cet utilitaire par défaut) :

  • on commence bien sûr par monter le disque sur lequel se trouve Windows
  • puis on commence à lire dans la Regedit : chntpw -l /path/to/windows/Windows/system32/config/software
  • pour se rendre dans HKey_Local_Machine/SYSTEM/MountedDevices, on va taper cd HKLMSYSTEMMountedDevices
  • la commande ls va permettre de lister les clés présentes
  • ed key va permettre de modifier ensuite une clé

Bien sûr, prudence dans toute action, il ne faut pas se tromper ! Sauvegardes nécessaires avant d'effectuer des opérations de la sorte. Dans mon cas, cela m'a permis de détruire une association de disque hasardeuse avec le contenu du disque C: automatiquement attribué à la lettre E: ce qui empêchait tout démarrage de Windows (qui n'aime pas démarrer sur E: s'il a été installé sur C: ... il doit y avoir des liens absolus laissés par l'installation !)

Monday, November 10 2014

Obtenir une bonne note chez SSLLabs avec Pound

J'utilise Pound dans mon infrastructure, notamment pour sa capacité d'assurer tout le chiffrement en SSL/TLS entre mes serveurs et les clients.

Cependant, la version stable de Pound dans Debian Wheezy n'est pas patchée pour écarter les récentes "attaques" sur SSL/TLS à commencer par la corruption de SSLv3 (faille baptisée Poodle).

Si la version 2.7, la prochaine stable, disposera de tous les derniers raffinements, seule une branche non officielle pourra satisfaire le plus scrupuleux adminsys. Cette branche non officielle est maintenue par Joe Gooch (qu'il soit permis ici de le remercier !) et est disponible ici : https://github.com/goochjj/pound/tree/pcidss/v2.6.

Voici comment Joe décrit cette branche :

The other is called pcidss/v2.6, which is Pound 2.6, plus cipher and protocol patches necessary (initially) to pass PCI compliance, and as part of that is the directive to disable SSL3.

Compiler Pound 2.6-pcidss

  • Télécharger la dernière version ici : https://github.com/goochjj/pound/archive/pcidss/v2.6.zip
  • Dé-zipper l'archive et se rendre dans le dossier
  • Réaliser ensuite la compilation (le système devra bien sûr comporter tout le nécessaire à cela : gcc, build-essentials, libssl-dev...) :
./configure
make
make install
  • dans Debian, il semble que pound 2.6-pcidss s'installe dans /usr/local/sbin/pound alors que le paquet original l'installe dans /usr/sbin/pound. On peut donc remplacer l'ancienne version par la nouvelle et vérifier que l'utilitaire par défaut correspond bien à la nouvelle version :
pound -V

qui doit retourner 2.6-pcidss.

  • on peut alors modifier la configuration de Pound avec ces paramètres :
	DisableSSLv2
	DisableSSLv3

	Ciphers "EECDH+ECDSA+AESGCM:EECDH+aRSA+AESGCM:EECDH+ECDSA+SHA384:EECDH+ECDSA+SHA256:EECDH+aRSA+SHA384:EECDH+aRSA+SHA256:EECDH:EDH+aRSA:-RC4:EECDH+aRSA+RC4:EECDH+RC4:EDH+aRSA+RC4:!aNULL:!eNULL:!LOW:!3DES:!MD5:!EXP:!PSK:!SRP:!DSS:RC4+SHA"
    	SSLHonorCipherOrder 1
	SSLAllowClientRenegotiation     0
  • et redémarrer Pound

Normalement, vous devriez désormais disposer d'un chiffrement SSL de qualité susceptible de vous faire obtenir un A (yes!) sur https://www.ssllabs.com/ssltest/ (si votre certificat est de bonne qualité - SSLLabs disqualifie tout de suite tout certificat auto-signé !).

StartSSL pour des certificats SSL "wildcard" à petit prix

Disposant de plusieurs domaines pour mes activités personnelles et professionnelles, j'utilisais jusqu'ici des certificats auto-signés pour sécuriser mes connexions avec SSL/TLS. Cependant, habituer l'utilisateur à "ajouter une exception de sécurité" sans réfléchir me déplaisait au plus haut point. J'ai donc finalement, poussé aussi par mon beau-frère, mis en place de jolis certificats validés par StartCom Ltd. (StartSSL).

Les tarifs pratiqués par StartCom Ltd./StartSSL sont beaucoup plus doux que ceux pratiqués par d'autres acteurs du domaine. Chez eux, on paye en effet le processus de validation d'identité mais ensuite l'émission des certificats est gratuite. Voilà qui est tout à fait intéressant et économique pour couvrir plusieurs domaines !

Ouvrir un compte chez StartSSL

La première étape consiste à se connecter sur http://startssl.com et à choisir "Sign-up" pour ouvrir un nouveau compte. On saisit ses informations personnelles (il faut qu'elles soient exactes si l'on prévoit de faire valider son identité !) puis le site installe automatiquement dans le navigateur un certificat/clé qui autorise ce seul navigateur à se connecter au site. Une bonne pratique consistera à sauvegarder de manière sûre ce certificat pour conserver l'accès au site StartSSL !

Profiter des certificats de niveau 1

Sans rien payer, il est alors possible de faire valider un domaine via le 'Validations Wizard' (la validation d'un domaine consiste à recevoir un courriel envoyé par exemple à postmaster@le-domaine-en-question.fr et à saisir le code de validation reçu) puis de créer des certificats de niveau 1.

Les certificats de niveau 1 sont une bonne base pour débuter mais il n'est notamment pas possible avec ce niveau de disposer de certificats "wildcard" (i.e. pour tous les sous-domaines d'un domaine). Pour bénéficier de cette fonctionnalité, il faut disposer d'un niveau 2.

Obtenir le niveau 2

Pour passer niveau 2, il faut d'une part :

  • soumettre des documents pour prouver son identité (photocopies de 2 pièces d'identité, éventuellement justificatif de domicile, éventuellement recevoir un appel de StartSSL sur son numéro de téléphone)
  • s'acquitter de la somme de 59,90$ (environ 48 euros)

Tout le processus s'effectue en ligne via le 'Validations Wizard', catégorie 'Personal identity validation'. Les gens de StartCom StartSSL sont extrêmement réactifs.

Dans mon cas, après quelques heures et quelques échanges par courriel et téléphone, mon identité a été vérifiée et mon niveau 2 validé.

Créer un certificat 'wildcard'

Une fois niveau 2, voici la marche à suivre :

  • sur le serveur que l'on souhaite protéger, nous allons générer une clé privée et un Certificate Sining Request (CSR) par la commande
openssl req -nodes -newkey rsa:4096 -sha256 -keyout cle-privee.key -out serveur.csr

Il est à noter que ce processus génère une clé privée sans mot de passe. Il est tout à fait possible de générer une clé avec mot de passe mais il faudra alors préciser le mot de passe correspondant aux logiciels serveurs qui utiliseront la clé pour crypter les échanges.

Au cours du processus, OpenSSL va demander quelques informations d'identité. Il est important de préciser dans le champ 'Common Name' le nom d'hôte à protéger : en l'occurrence *.le-domaine-en-question.fr si l'on souhaite bénéficier d'un certificat 'wildcard' pour le-domaine-en-question.fr.

Country Name (2 letter code) [AU]: FR
State or Province Name (full name) [Some-State]: Ile-de-France
Locality Name (eg, city) []: Mary-sur-Marne
Organization Name (eg, company) [Internet Widgits Pty Ltd]: MaSociété
Organizational Unit Name (eg, section) []: 
Common Name (eg, YOUR name) []: *.le-domaine-en-question.fr
Email Address []: postmaster@le-domaine-en-question.fr
A challenge password []: 
An optional company name []:
  • on peut alors afficher le contenu du CSR par
cat serveur.csr

et le conserver précieusement

  • de retour sur le site de StartSSL, se rendre dans le 'Certificates wizard'
  • choisir 'Webserver SSL/TLS certificate'
  • passer (bouton SKIP) l'étape de génération d'une clé privée puisque nous avons créé nous-même notre clé privée sur le serveur
  • copier alors le contenu du CSR dans le champ texte
  • sélectionner le domaine à protéger : seuls les domaines déjà validés peuvent être utilisés. On pourra par exemple saisir *.le-domaine-en-question.fr.
  • et voilà le certificat qui apparaît à l'écran. Il convient de copier ce certificat précieusement, par exemple dans un fichier wildcard.le-domaine-en-question.fr.crt.

Utiliser son tout nouveau certificat

Cette étape dépend ensuite du serveur utilisé (Apache, Pound, Nginx, ...). La plupart du temps, on regroupera le certificat obtenu de la part de l'autorité de certification et la clé privée dans un même fichier .pem. On pourra également inclure les certificats intermédiaires de l'autorité : https://www.startssl.com/certs/ca.pem et https://www.startssl.com/certs/sub.class2.server.ca.pem.

cat wildcard.le-domaine-en-question.fr.crt cle-privee.key ca.pem sub.class2.server.ca.pem > wildcard.le-domaine-en-question.pem

On pourra alors utiliser ce .pem sur son serveur, en s'assurant toutefois de bien le garder secret, car il contient notre clé privée !

Bon courage pour votre génération de certificats !

Friday, September 26 2014

Contrôleur RAID Dell PERC H310 (PowerEdge R220) et Linux, tout fonctionne !

La nouvelle gamme de serveur Dell PowerEdge R220 est équipée du contrôleur PERC H310.

Outre être compatible sans problème avec Debian Wheezy, ce contrôleur a le bon goût de pouvoir être suivi ("monitoré" si vous me pardonnez l'anglicisme) depuis Linux. En effet, comme tout le monde le sait, il est indispensable de suivre l'état d'un RAID tout au long de sa vie pour intervenir au plus vite en cas de panne de l'un des disques pour effectuer son remplacement.

Vérifier que vous avez bien un PERC H310

Le rendu de la commande

lspci

doit contenir cette ligne :

01:00.0 RAID bus controller [0104]: LSI Logic / Symbios Logic MegaRAID SAS 2008 [Falcon] ![1000:0073] (rev 03)

Charger le module du kernel Linux adéquat

Cette carte est gérée par le module

megaraid_sas

que l'on peut charger, si nécessaire, avec la commande

modprobe megaraid_sas

Installer les utilitaires adaptés

Les paquets adaptés sont disponibles sur hwraid.le-vert.net. On peut les installer en ajoutant cette ligne dans /etc/apt/sources.list :

deb http://hwraid.le-vert.net/debian wheezy main

puis

aptitude update
aptitude install megactl megaraid-status

Il est désormais possible de surveiller l'état du RAID avec la commande :

megasasctl

ou

megasasctl -B

(si, comme le PERC H310, votre carte ne comporte pas de batterie donc vous ne voulez pas avoir d'alerte pour batterie manquante)

Aussi, en installant megaraid-status, un démon de surveillance du RAID a été installé. Il enverra un courriel à root lors tout défaut sur le RAID. Je vous invite à tester cette fonctionnalité en détériorant manuellement (en débranchant un disque de la grappe par exemple - en environnement de test hein !) le RAID. Voici le style de message reçu :

This is a RAID status update from megaraidsas-statusd.  The megaraidsas-status
program reports that one of the RAIDs changed state:

-- Arrays informations --
-- ID | Type | Size | Status
a0d0 | RAID 1 | 465GiB | DEGRADED

-- Disks informations
-- ID | Model | Status | Warnings
a0e*s0 | ATA TOSHIBA DT01ACA0 465GiB | rebuild
a0e*s1 | ATA TOSHIBA DT01ACA0 465GiB | online

There is at least one disk/array in a NOT OPTIMAL state.

Report from /etc/init.d/megaraidsas-statusd on cefepime

Recevoir les courriels système envoyés à root

Si vous ne voulez pas d'un serveur courriel compliqué sur votre serveur, vous pouvez déployer le rapide et simple nullmailer. Il se chargera de renvoyer vers l'adresse spécifiée dans /etc/nullmailer/adminaddr tout message envoyé à root.

Bonne surveillance de RAID sur PERC H310 !

Thursday, August 28 2014

wget pour télécharger intelligement le contenu d'un espace webdav

Qu'on l'aime ou qu'on ne l'aime pas, la technologie webdav est assez répandue et largement utilisée par certains hébergeurs pour partager des données. On trouve sous Linux toute un panel de logiciels capables de travailler avec webdav, et vous connaissez sans doute davfs2 qui permet de monter un partage webdav comme une partition locale.

Cependant, davfs2 fonctionne à l'aide d'un cache (sensé rendre l'usage plus fluide et confortable). Ainsi, à chaque ouverture de fichier, celui est d'abord copié en zone cache (par défaut /var/cache/davfs2/) avant d'être rendu disponible. Si ce comportement est très intéressant pour des usages classiques, il devient problématique lorsque le partage est distant et les fichiers atteignent des tailles massives (plusieurs Go) avec une grosse lenteur causée par la mise en cache !

J'ai notamment trouvé ce comportement problématique avec rsync : tentant de synchroniser avec l'excellent rsync le contenu d'un partage webdav comprenant plusieurs fichiers >10 Go (partage monté avec davfs2), je me retrouvais avec rsync bloqué, apparemment sans activité et l'impossibilité de tuer les processus. Et pour cause, davfs2 faisait tout son possible pour basculer le fichier en cache avant de laisser rsync (gelé en attente) travailler dessus... Pas idéal !

Je décidais alors de remplacer rsync par wget pour mon travail de synchronisation à sens unique :

wget -c -r -nH --cut-dirs=1 -N --user="user" --password="password" http://server.tld/webdav/
  • -c pour reprendre le téléchargement s'il a été interrompu en cours de travail
  • -r pour télécharger le répertoire de manière récursive (en suivant donc les liens au sein du partage webdav)
  • -nH et --cut-dirs=1 pour ne pas copier le nom d'hôte et le premier nom de dossier dans l'arborescence locale
  • -N pour ne télécharger depuis la source que les fichiers qui n'existent pas ou n'ont pas la même taille en local

Au passage, on "gagne" la barre de progression propre à wget dont rsync ne dispose pas par défaut.

Bien évidemment, wget n'est pas rsync et wget n'a certainement pas toutes les fonctionnalités de synchronisation avancées (et diablement intelligentes) de rsync. Cependant, il se défend admirablement pour télécharger le contenu d'un espace webdav de manière intelligente et sans bloquer sur le mécanisme de cache de davfs2 !

Mais wget, le vénérable, m'a encore bien dépanné !

Une résolution DNS propre à chaque sous-réseau avec Dnsmasq !

Dnsmasq est un léger (mais performant) client DNS et DHCP. J'ai découvert dernièrement une très intéressante fonction que je m'empresse de partager avec vous : localise-queries.

Imaginez la situation suivante : votre machine est accessible depuis plusieurs interfaces réseau (par exemple plusieurs instances d'OpenVPN) et vous souhaitez offrir une résolution DNS aux clients qui se connectent sur chaque interface. Or, chaque interface dispose de sa propre adresse et de son sous-réseau propre. Comment offrir une résolution de nom qui prenne en compte le sous-réseau d'origine et adapte ses réponses en conséquence ?

Dnsmasq dispose de la fonction localise-queries pour ce faire !

On ajoute donc la ligne

localise-queries

dans le fichier de configuration /etc/dnsmasq.conf.

Puis, dans /etc/hosts (pour mémoire dnsmasq s'inspire de /etc/hosts pour établir la liste des correspondances IP/nom), nous allons définir plusieurs résolutions correspondant chacune à un sous-réseau :

10.8.300.1   nomA
10.8.301.1   nomA
10.8.302.1   nomA
10.8.300.1   nomB
10.8.301.1   nomB
10.8.302.1   nomB

On redémarre alors dnsmasq (service dnsmasq restart) et le tour est joué !

Quand on sera connecté via la sous-réseau 10.8.301.x, alors nomA sera résolu en 10.8.301.1. En revanche, lors d'une connexion via le sous-réseau 10.8.302.x, alors nomA sera résolu en 10.8.302.1 !

"Fortiche" dnsmasq !

Sunday, August 17 2014

Nouvelle version d'atom (0.124) compilée pour Debian Jessie

Je viens de compiler la dernière version d'atom, l'éditeur de texte évolué créé par les équipes de GitHub. La version 0.124 est donc disponible sous la forme d'un paquet Debian : atom-0.124.0-amd64.deb.

Ce paquet devrait fonctionner sur Debian Jessie 64 bits.

Il a été généré en suivant les instructions de compuilation officielles et certains pré-requis doivent peut-être être remplis sur des machines qui n'ont jamais été confrontées à atom.

Bon téléchargement !

Sunday, June 22 2014

Modifier les locales pour PHP dans elementaryOS

Pour ajouter la locale fr_FR à PHP dans elementaryOS : il faut ajouter la ligne

fr_FR.ISO8859-1

dans le fichier /var/lib/locales/supported.d/fr

Puis lancer les commandes

sudo dpkg-reconfigure locales
sudo locale-gen

Et voilà, le tour est joué !

Sunday, May 11 2014

Supprimer tous les fichiers temporaires de Gedit dans mon dossier de travail

Gedit stocke les sauvegardes automatiques des fichiers dans des fichiers temporaires au nom "name~".

Pour nettoyer un espace de travail de tous ces fichiers temporaires, la commande suivante peut faire l'affaire :

find . -name "*~" -exec rm -f {} \;

Apache, protéger par mot de passe tout un hôte virtuel sauf certaines adresses : utilisation de LocationMatch

Il est assez classique d'utiliser les fonctions d'authentification d'Apache, par exemple auth_digest, pour sécuriser l'accès à un répertoire ou une application web propulsée par Apache.

Toutefois, il est parfois souhaitable de laisser en accès sans mot de passe une adresse spécifique, correspondant par exemple à une page publique ou à une fonctionnalité de l'application qu'un utilisateur lambda doit pouvoir déclencher.

Apache permet cela grâce à la direction "LocationMatch" et à des expressions régulières.

Par exemple, avec l'exemple ci-dessous placé dans un hôte virtuel correspondant à mon-app.domaine.tld :

<LocationMatch "^(?!/zone-publique)">
        AuthType Digest
        AuthName "mon-app"
        AuthDigestProvider file
        AuthUserFile /path/to/digest-password-file
        Require valid-user
</LocationMatch>

tout accès à l'hôte virtuel sera protégé par mot de passe sauf l'adresse http://mon-app.domaine.tld/zone-publique qui sera accessible à tous sans mot de passe.

Bons paramétrages !

Thursday, May 8 2014

"/usr/bin/env: node: No such file or directory"

Se résout assez facilement par :

ln -s /usr/bin/nodejs /usr/bin/node

Sunday, March 23 2014

L'importance du paramètre TimeOut dans Pound

Pound est un reverse-proxy et un load-balancer libre fort perfomant. Il faut toutefois savoir que par défaut Pound n'attend pas plus de 15 secondes la réponse du serveur sous-jacent avant de retourner une erreur : "An internal server error occurred. Please try again later". Un 'timeout' de 15 secondes est suffisant pour de nombreux cas - cependant certaines requêtes sont parfois plus longues par exemple quand il s'agit de déclencher des requêtes importantes sur des bases de données, de lancer le téléchargement d'une grosse archive dans ownCloud ou de toute autre opération susceptible de prendre plus de 15 secondes à un serveur (notamment quand celui-ci est fortement sollicité par ailleurs).

Il est dès lors possible d'augmenter la durée du 'TimeOut' en ajoutant cette ligne :

  • soit dans la configuration globale de pound
  • soit dans la définitiond d'un 'backend' spécifique
TimeOut 150

Si 150 secondes n'est pas adapté, on modifie bien sûr la valeur.

Voilà qui devrait faire disparaître la plupart des erreurs "An internal server error occurred. Please try again later" !

- page 4 of 8 -