Gérez “AWS Glacier” en ligne de commande

AWS_LOGO_RGB_300px

Pour ceux qui seraient passés à côté, Amazon Glacier est un système de stockage sur le cloud d’Amazon (un peu comme S3) dédié à la conservation “longue durée” de vos données (un système d’archivage en quelque sorte).

Par rapport à S3 le principal avantage de cette solution est le prix. En effet avec un coût de $0,01 par Go et par mois il s’agit certainement là de la solution de stockage la plus économique du marché (10€ / 1To / mois difficile de faire mieux) – A titre de comparaison 1To stocké sur S3 coûte 95$ / mois !

Bon à ce tarif là vous devez vous douter qu’il y a quelques inconvénients. Le plus significatif est certainement le délai de récupération des données. En effet si l’upload d’informations est immédiat, toute opération de récupération de données va nécessiter une attente préalable d’au moins 4 h ! Et ce délai concerne toutes les opérations : même une demande d’inventaire (un “ls” en quelque sorte) du contenu d’un dépôt va demander le même délai (4h) avant d’obtenir le résultat de votre requête …

Il est donc clair qu’avec une telle contrainte il faut réserver l’usage de Glacier à des seules fins d’archivage …

A l’inverse de S3 il n’existe pas (pour le moment) d’interface web (fournie par Amazon) permettant de gérer le contenu de ses archives. Plusieurs logiciels dédiés existent toutefois sur le marché. J’ai par exemple testé “FastGlacier” sur une des mes machines Windows (ce soft est gratuit pour un usage non commercial). Toutefois, dans certains cas, il est plus pratique d’utiliser directement une interface en ligne de commande (pour archiver le contenu d’un serveur Linux par exemple). Il existe, pour ce faire, un ensemble de scripts Python totalement fonctionnels et qui permettent d’agir sur vos archives. Il s’agit de “glacier-cmd“.

L’installation (et l’utilisation) de “glacier-cmd” ne pose pas vraiment de problème, mais j’ai quand même décidé de faciliter la tâche à ceux (celles) d’entres vous qui ont quelques petites difficultés avec la langue anglaise et/ou démarrer rapidement à partir d’un document de synthèse.

C’est parti …

Ce how-to est basé sur l’utilisation d’une distribution Debian 6 “out of the box” sans particularité. Bien entendu aucune interface graphique n’est nécessaire (c’est d’ailleurs un peu l’objectif de ce how-to …)

La première chose à faire est de s’assurer que Python est bien installé sur votre système.

Un petit “python -V” devrait vous retourner la version de Python installée

Dans le doute vous pouvez toujours lancer un “apt-get install python” ça ne peut pas faire de mal !

Il faut ensuite passer à l’installation de “Git” (qui vous permettra de faciliter l’installation de “glacier-cmd“)

apt-get install git

On récupére ensuite l’intégralité de glacier-cmd avec une seule ligne de commande :

git clone https://github.com/uskudnik/amazon-glacier-cmd-interface.git

On entre dans le répertoire où ont été récupérées les sources

cd amazon-glacier-cmd-interface/

On installe un module supplémentaire pour Python nécessaire au lancement du script d’installation

apt-get install python-setuptools

Et on lance finalement le script d’installation

python setup.py install

On va ensuite créer un fichier de configuration pour glacier-cmd.

vi /etc/glacier-cmd.conf

Le fichier va ressembler à ça :


[aws]
 access_key=Identifiant de clé d’accès
 secret_key=Clé d’accès secrète

[glacier]
 region=us-east-1
 logfile=~/.glacier-cmd.log
 loglevel=INFO
 output=print

Pour récupérer (ou créer les clés AWS) il faut se connecter ICI

Ce fichier de conf va également vous permettre de sélectionner la zone géographique où seront hébergés vos données (les tarifs varient légèrement en fonction de ce paramètre : toutes les infos sont ICI ).

Les valeurs possibles pour “region” sont donc les suivantes :


us-east-1 pour : US - Virginia
us-west-1 pour : US - N. California
us-west-2 pour : US - Oregon
eu-west-1 pour : EU - Ireland
ap-northeast-1 pour : Asia-Pacific - Tokyo

On peut ensuite passer à l’utilisation de glacier-cmd. Les principales commandes sont les suivantes :

  • Pour créer un dépôt (“vault”) de stockage (afin d’y déposer ensuite des archives)
    glacier-cmd mkvault <le_nom_de_votre_dépôt>
    
  • Pour lister les dépôts disponibles :
    glacier-cmd lsvault
  • Pour obtenir le contenu (liste des archives/fichiers) d’un dépôt (attention le résultat de cette commande ne sera disponible qu’après 4h d’attente …)
    glacier-cmd inventory <le_nom_de_votre_dépôt>
  • Pour uploader une archive (fichier) au sein d’un dépôt :
    glacier-cmd upload <nom_de_votre_dépôt> <nom_du_fichier_a_uploader> --description "la_description_du_fichier"
  • Pour télécharger les archives (fichiers) contenues au sein d’un dépôt  :

    L’opération se déroule en deux temps:

    1) On lance une demande de récupération de l’archive avec la commande suivante :

    glacier-cmd getarchive <nom_de_votre_dépôt> <id_de_l'archive_à_récupérer>

    NB : On récupère l’id de l’archive avec la commande “inventory” (voir ci-dessus)

    2) Après environ 4h d’attente vous pouvez demander le téléchargement de l’archive avec cette commande :

    glacier-cmd download <nom_de_votre_dépôt> <id_de_l'archive_à_récupérer> --outfile <nom_du_fichier>

    Donc pour résumer une récupération “type” s’effectue en 8h : 4h pour obtenir le contenu du dépôt (avec les identifiants d’archives) puis 4h pour obtenir une archive prête à être téléchargée et enfin le temps nécessaire au téléchargement du fichier ! Mieux vaut ne pas être pressé …

  • Pour obtenir la liste de jobs en cours (inventaire, récupération …) :
glacier-cmd listjobs nom_de_votre_dépôt

Ce how-to n’a bien entendu pas vocation à être exhaustif. Si vous souhaitez découvrir l’intégralité des fonctionnalités proposées par glacier-cmd, je vous invite à consulter la documentation disponible ICI .

Dans un prochain billet, je vous présenterai une solution permettant d’automatiser le backup d’un serveur Linux vers Glacier …

Utilisez Google Authenticator sans smartphone

Je vous parle, depuis quelques semaines, de Google Authenticator afin de sécuriser vos connexions à différents services : compte Google bien entendu mais également Dropbox, WordPress, LastPass (la liste devrait s’allonger assez rapidement …). C’est certainement l’un des systèmes les plus performants pour sécuriser l’accès à vos comptes. Mais comment faire si vous ne disposez pas d’un smartphone (c’est encore possible ça ;-) ) ou bien si votre téléphone se trouve dans une autre pièce et que vous n’avez pas envie de vous déplacer …

Un module pour Google Chrome est désormais disponible. Ce dernier après une configuration rapide (mais toutefois sans utilisation de code barres – il va falloir saisir votre clé secrète à 16 caractères) vous communiquera vos codes à usage unique à l’instar de l’application mobile. Attention toutefois à n’installer ce module que sur un PC de confiance !

Le module “GAuth Authenticator” est disponible ICI

L’authentification à facteurs multiples pour votre blog WordPress

Vous cherchez un moyen de renforcer la sécurité de votre blog WordPress (auto-hébergé) ? Vous devriez aller jeter un coup d’œil du côté du plugin “Google Authenticator”. Comme son nom l’indique, ce dernier va vous permettre d’intégrer le système d’authentification “en deux étapes” de Google à votre propre blog.

L’intégration et la configuration semble être assez simple :

  • installation et activation du plugin
  • paramétrage du module au sein de l’interface d’administration de WordPress
  • scan du code-barres d’auto-configuration avec l’appli pour smartphone

  • et c’est terminé ! Vous devriez normalement voir apparaître un champ supplémentaire au sein de la fenêtre d’authentification.

Vous perdez votre smartphone ? Pas d’inquiétude, vous pourrez accéder de nouveau à votre blog en supprimant (avec un accès ftp, ssh …) le plugin de votre arborescence WordPress (d’où l’intérêt d’opter pour un mot de passe ftp/ssh assez fort). Le plugin vous permet également de maintenir un accès par mot de passe (afin que certaines applications puissent accéder à votre blog par exemple). Mais dans ce cas vous diminuez bien sûr l’efficacité du dispositif !

Il est bon de noter, au passage, que Google Authenticator commence à être utilisable avec de nombreuses autres solutions que les produits de Google : WordPress mais également LastPass, Dropbox, vos propres serveurs SSH … A mon avis ce système va rapidement s’imposer comme un standard pour l’accès à pas mal de sites web et dispositifs sur le net.

Pour ceux qui ne qui ne savent pas ce qu’est une authentification à facteurs multiples, je vous conseille la lecture de  mon billet de la semaine dernière (“Les 3 news de la semaine” / titre “Dropbox permet désormais l’authentification à facteurs multiples“).

  • Le plugin WordPress se trouve ICI
  • Google Authenticator pour Android est disponible sur le Play Store : ICI (pour les autres : iOS, Blackberry … vous n’avez qu’à chercher par vous même ;-) )

Twitter propose une connexion HTTPS permanente …

Si vous utilisez régulièrement l’interface web de Twitter à partir d’un hot spot public vous devriez activer cette nouvelle option !

En effet, et à l’instar de ce que Googe proposait il y a quelques mois pour Gmail, il est désormais possible de forcer la connexion en mode HTTPS (voir l’annonce officielle ICI).

C’est plutôt une bonne nouvelle quand on connait la simplicité d’utilisation d’une application comme FireSheep !

Attention : pour le moment la version mobile de Twitter (accessible au travers de l’URL : http://mobile.twitter.com ) n’est pas encore concernée par cette option. Vous devez donc vous assurer de bien vous connecter avec https://mobile.twitter.com ).

La réaction de Google après la découverte des applications malveillantes

On apprenait, dans la semaine, la découverte de 21 applications malveillantes au sein de l’Android Market (ICI). Google vient de publier un article sur son blog dédié aux mobiles ( ICI) en réaction à cette annonce .

Visiblement le problème est  pris au sérieux et des mesures spécifiques ont été mises en œuvre : désinstallation à distance des programmes malveillants et application automatique d’un patch de sécurité sur les mobiles affectés. Enfin les utilisateurs concernés seront prévenus par mail.

Google annonce également la mise  en place de nouvelles mesures spécifiques visant à améliorer la sécurité du Market.

L’Android Market est un système ouvert et c’est une très bonne chose. Toutefois, il faut constater que cette ouverture ne permet pas de garantir un niveau de sécurité optimal. Il serait peut être intéressant que Google s’inspire de ce que fait Mozilla pour son système d’extensions Firefox (ou Thunderbird) avec le concept d’approbation. A vous de décider, ainsi, si vous prenez (ou pas), le risque d’installer un module “non approuvé”.

 

 

Firesheep : quand utiliser un hot spot wifi devient une activité risquée …

Vous ne le savez peut être pas encore, mais depuis quelques semaines une nouvelle extension pour Firefox a vu le jour. Son nom : Firesheep. Cette dernière a pour vocation d’intercepter tous les paquets réseau qui transitent (en clair) sur un hot spot WiFi, de repérer les cookies afin de permettre à tout un chacun et sans aucune connaissance particulière, de se connecter à votre insu, sur votre compte Twitter, Facebook  …

Je pense qu’une petite vidéo vous permettra d’y voir un peu plus clair …

Inquiétant non ?

Pas de panique ! Si vous souhaitez vous protéger plusieurs solutions sont envisageables :

  • crypter tout le trafic en utilisant systématiquement un tunnel VPN dès que vous êtes connecté à un hot-spot publique (vous sortez ainsi sur le net par le biais de la connexion de votre boulot par exemple ou bien au travers de la connexion de votre domicile). Il existe également une multitude d’offre sur le net en la matière. L’avantage de cette solution est de vous protéger également de toute interception de mots de passe habituellement véhiculés en clair : POP/IMAP par exemple. Si vous souhaitez en savoir plus vous pouvez consulter le WiKi de @korben en cliquant ICI
  • n’utiliser que le protocole HTTPS pour naviguer sur le net. Pas toujours très simple, heureusement une extension est là pour vous aider. Il s’agit de “HTTPS Everywhere” téléchargeable ICI
  • utiliser une nouvelle extension Firefox permettant de détecter la présence d’un Firesheep au sein d’un hot-spot. Il s’agit de “BlackSheep” (ouais ok ça devient un peu tordu mon truc:-) ). L’extension est téléchargeable ICI . Attention quand même :  Mozilla n’a pas, pour le moment, testé cette extension, moi non plus d’ailleurs et visiblement certains utilisateurs semblent avoir rencontrés quelques problèmes …

Pour conclure : soyez prudents!

[HOWTO] Automatisez la sauvegarde de vos serveurs avec “Rdiff-Backup”

Si vous administrez des serveurs Linux vous vous êtes déjà probablement interrogé sur la meilleure façon de sauvegarder vos systèmes et données. La télé-sauvegarde est une option particulièrement intéressante. Bien que Rsync paraîsse naturellement le dispositif le mieux adapté à cette tâche une autre solution existe : Rdiff-backup.

Moins connu, ce dernier présente de nombreux avantages : une gestion optimisée des incréments, la création d’un miroir de fichiers ou de répertoires, la gestion automatisée de l’effacement des anciens incréments, la compression des données transférées … Rdiff-Backup est utilisable en “local” mais également dans le cadre d’un système de télé-sauvegarde. Dans ce cas les échanges sont cryptés en utilisant (de manière transparente) le protocole SSH.

L’objectif de ce how-to est de présenter une méthode permettant de réaliser une sauvegarde à distance, sécurisée, automatisée, sans aucune intervention de la part de l’administrateur (les procédures d’authentification reposant sur un système de clés asymétriques).

La distribution utilisée pour la création de ce how-to est une “Ubuntu 10.04 LTS server“, mais il ne devrait pas y avoir beaucoup de différences si vous utilisez un autre Linux. Un serveur SSH doit également être présent sur les 2 machines.

Dernière précision : afin de simplifier cette procédure j’utilise volontairement l’utilisateur “root” pour réaliser la sauvegarde. Pour optimiser la sécurité, les “puristes” pourront bien entendu adapter cette  méthode  avec un autre compte utilisateur …

Dans le cadre de ce tutoriel nous allons utiliser deux serveurs :

  • srv-prod “: qui correspond au serveur “à sauvegarder” (IP dans ce how-to : 192.168.0.157)
  • srv-backup” : qui correspond au serveur destiné à héberger la sauvegarde de srv-prod

On procède tout d’abord à l’installation de “Rdiff-Backup” en lançant (sur les 2 serveurs) la commande

apt-get install rdiff-backup

On va ensuite générer les clés SSH nécessaires à l’authentification de “srv-backup” auprès de “srv-prod”. Créez (si ce n’est pas déjà fait) sur “srv-backup” un répertoire nommé “/root/.ssh/“. On lance ensuite (sur ce même serveur)  la commande suivante :

ssh-keygen -t rsa -b 4096

Répondez de la manière suivante aux questions posées par l’application :

Enter file in which to save the key (/root/.ssh/id_rsa): /root/.ssh/rdiff_id_rsa

Ne rien mentionner en réponse à la question “Enter passphrase (empty for no passphrase):”. Idem pour “Enter same passphrase again:

Suite à cette opération, vous trouverez 2 fichiers au sein du répertoire “/root/.ssh” :

  • rdiff_id_rsa : qui correspond à votre clé privée
  • rdiff_id_rsa.pub : votre clé publique (qui devra, par la suite, être positionnée sur le serveur de production …

Pour ce faire il est nécessaire d’éditer le fichier “rdiff_id_rsa.pub” (avec un petit “cat /root/.ssh/rdiff_id_rsa.pub” par exemple). Vous devriez obtenir une chaîne de la forme :

Bien entendu le contenu de votre fichier sera différent car il s’agit de clés générées aléatoirement (heureusement … ;-) )

Copiez ensuite cette chaîne de caractères afin de pouvoir la coller dans le fichier “/root/.ssh/authorized_keys2” du serveur de production (“srv-prod”). Dans l’hypothèse où ce répertoire (“.ssh”) et ce fichier (“authorized_keys2″) n’existent pas il sera nécessaire de les créer manuellement. Attention aux droits à appliquer sur le fichier “authorized_keys2” qui doivent être positionnés à 644 (“chmod 644 /root/.ssh/authorized_keys2“). Il faut également s’assurer de copier la chaîne de caractères tel-quel sans y ajouter aucun caractère n’y retour chariot.

Une fois la clé copiée, il est nécessaire d’y ajouter (sur “srv-prod“) certaines options comme illustré dans l’exemple ci-dessous :

Les directives à placer devant la clé sont les suivantes (il ne vous reste plus qu’à copier / coller …) : “command=”rdiff-backup –server –restrict-read-only /”,no-port-forwarding,no-X11-forwarding,no-pty “. Il s’agit de mesures de sécurités complémentaires. En effet le serveur de backup s’authentifiant de manière automatisée, il est intéressant de limiter les opérations réalisables avec ce compte (pas de terminal, opération en lecture seule uniquement, pas de forward de ports …).

Sur le serveur “srv-backup” créez le fichier “/root/.ssh/config“. Ce dernier va intégrer les éléments nécessaires à la connexion automatique au serveur de production. Le contenu de ce fichier est le suivant :

host 192.168.0.157
hostname 192.168.0.157
user root
identityfile /root/.ssh/rdiff_id_rsa
compression yes
protocol 2

Bien entendu vous devez remplacer l’IP (192.168.0.157) par l’adresse de votre serveur de prod (ou bien par son nom pleinement qualifié). Vous pouvez également modifier le paramètre “compression” en le passant à “no” si vous ne souhaitez pas compresser les données échangées entre les deux serveurs.

Créez ensuite, sur “srv-backup” un répertoire au sein duquel seront stockées les données sauvegardées. Par exemple “mkdir /backup

Il ne reste plus qu’à essayer de générer une sauvegarde d’un des répertoires du serveur de production (“/etc” par exemple) en utilisant une commande du style :

rdiff-backup -v 5 root@192.168.0.157::/etc /backup/etc

Vous allez voir apparaître un message du type :

The authenticity of host ’192.168.0.157 (192.168.0.157)’ can’t be established.
RSA key fingerprint is 60:6b:12:0a:6f:bf:98:da:83:5c:43:16:f2:72:3c:29.
Are you sure you want to continue connecting (yes/no)?

répondez “yes” (cette question ne sera plus posée par la suite). Vous devriez voir la sauvegarde se réaliser. Un petit contrôle du répertoire “/backup/etc” confirme la présence des fichiers.

Vous pouvez automatiser (via le crontab) cette tâche de sauvegarde en vous inspirant, après adaptation, de ce script (merci à  @ledeuns pour sa contribution ) :

#!/bin/bash</p>
RETCODE=""

### Sauvegarde ###

/usr/bin/rdiff-backup  root@192.168.0.157::/var /backup/var
if [ $? -ne 0 ]; then RETCODE="VAR;"; fi
/usr/bin/rdiff-backup  root@192.168.0.157::/etc /backup/etc
if [ $? -ne 0 ]; then RETCODE="ETC;$RETCODE"; fi
/usr/bin/rdiff-backup root@192.168.0.157::/home /backup/home
if [ $? -ne 0 ]; then RETCODE="HOME;$RETCODE"; fi
/usr/bin/rdiff-backup root@192.168.0.157::/root /backup/root
if [ $? -ne 0 ]; then RETCODE="ROOT;$RETCODE"; fi
/usr/bin/rdiff-backup root@192.168.0.157::/usr /backup/usr
if [ $? -ne 0 ]; then RETCODE="USR;$RETCODE"; fi

### Effacement des increments datant de plus de 2 semaines (2W) ###

/usr/bin/rdiff-backup --force --remove-older-than 2W /backup/var/
if [ $? -ne 0 ]; then RETCODE="DELVAR;$RETCODE"; fi
/usr/bin/rdiff-backup --force --remove-older-than 2W /backup/etc/
if [ $? -ne 0 ]; then RETCODE="DELETC;$RETCODE"; fi
/usr/bin/rdiff-backup --force --remove-older-than 2W /backup/home/
if [ $? -ne 0 ]; then RETCODE="DELHOME;$RETCODE"; fi
/usr/bin/rdiff-backup --force --remove-older-than 2W /backup/root/
if [ $? -ne 0 ]; then RETCODE="DELROOT;$RETCODE"; fi
/usr/bin/rdiff-backup --force --remove-older-than 2W /backup/usr/
if [ $? -ne 0 ]; then RETCODE="DELUSR;$RETCODE"; fi

### Envoi du rapport par mail ###

if [ -z $RETCODE ]; then
echo "" | mail -s "Sauvegarde effectuee" votre@adresse.fr
else
echo "$RETCODE" | mail -s "Sauvegarde en erreur" votre@adresse.fr
fi

Ce how-to n’ayant pas vocation à décrire d’une manière exhaustive le fonctionnement de Rdiff-Backup, je vous invite à consulter le manuel détaillé disponible à cette adresse (vous pourrez y découvrir l’ensemble des commandes et options disponibles) !

  • Le site officiel est disponible ICI