Bienvenue sur Think-Underground.com

Logiciels libres, photographie, musique, énigmes, humour et coups de cœur

dimanche 16 janvier 2011

Sauvegarder un FTP avec lftp

Mon problème : trouver un moyen pratique de sauvegarder un serveur FTP, donc typiquement une ligne de commande que je pourrai faire tourner régulièrement en cron ou manuellement
Ma solution : lftp

lftp est un client FTP libre (licence GPL) qui propose des fonctionnalités très avancées dont l'une de mirroring qui va nous intéresser ici. Sous Debian un petit apt-get install lftp est suffisant pour installer la bête.

Imaginons que je désire :

  • me connecter au serveur ftp.monsite.fr ;
  • avec mon compte djib ;
  • et sauvegarder tout le répertoire /www distant (sous-répertoires inclus) vers /backups/monsite en local.

La commande à lancer est

lftp -u djib -e "mirror -en --verbose /www /backups/monsite/; exit" ftp.monsite.fr

  • -u précise le nom de l'utilisateur
  • -e indique la commande distante à exécuter

En option à mirror j'ai ajouté :

  • -e qui supprime les fichiers locaux qui n'existent plus sur le serveur distant ;
  • -n qui ne transfère que les fichiers plus récents sur le serveur qu'en local (en gros une sauvegarde différentielle) ;
  • --verbose qui affiche les fichiers en cours de transfert.

Si vous voulez que le mot de passe se renseigne automatiquement, vous pouvez le mettre juste après le nom d'utilisateur (lftp -u djib,password …) ou dans un fichier externe.

Voilà, n'hésitez pas à vous plonger dans le manuel de lftp qui sera bien plus complet que ce petit guide pratique.

mercredi 8 avril 2009

Problème fsockopen et SSL avec Roundcube

Il y a quelques semaines de ça, j'ai mis à jour un de mes serveurs Debian vers Lenny, la nouvelle version stable. Malheureusement ça m'a cassé mon Roundcube qui se mettait à me crier dessus à l'écran de connexion :

Warning: fsockopen() [function.fsockopen]: SSL: Connection reset by peer in /usr/share/roundcube/program/lib/imap.inc on line 464
Warning: fsockopen() [function.fsockopen]: Failed to enable crypto in /usr/share/roundcube/program/lib/imap.inc on line 464
Warning: fsockopen() [function.fsockopen]: unable to connect to ssl://localhost:993 (Unknown error) in /usr/share/roundcube/program/lib/imap.inc on line 464
IMAP Error: Could not connect to ssl://localhost at port 993:
Warning: Cannot modify header information - headers already sent in /usr/share/roundcube/program/include/main.inc on line 339
Warning: Cannot modify header information - headers already sent in /usr/share/roundcube/program/include/rcube_html.inc on line 163

J'ai mis un petit bout de temps à comprendre d'où ça venait : en fait c'est que courier-imap-ssl ne communique plus (par défaut) avec la version 2 de TLS. Roundcube lui essaye une poignée de mains en SSL2 avec mon serveur Courier qui refuse tout simplement la connexion.

Pour corriger ce petit problème de configuration, il suffit de modifier une ligne dans /etc/imapd-ssl :

TLS_PROTOCOL=SSL3

devient

TLS_PROTOCOL=SSL23

On redémarre le service Courier et pof, on arrive de nouveau à se connecter à Roundcube.

invoke-rc.d courier-imap-ssl reload

Elle est pas belle la vie ?

samedi 10 janvier 2009

Dokuwiki, gestionnaire de configuration : Le fichier des paramètres ne peut être modifié

Je suis tombé sur cette erreur étrange l'autre jour sur mon Dokuwiki (un wiki très simple à utiliser) fraichement installé sous Debian :

Le fichier des paramètres ne peut être modifié,
si ceci n'est pas intentionnel,
vérifiez que le nom et les droits du fichier sont corrects.

J'ai eu du mal à comprendre d'où venait ce message dans la mesure ou mon fichier local.php et local.php.bak dans le répertoire /etc/dokuwiki étaient bien accessibles en écriture pour le groupe www-data. Rien de plus n'est précisé dans la documentation. Du coup je me suis plongé dans le code et j'ai trouvé l'origine du problème : le répertoire /etc/dokuwiki doit aussi être accessible en écriture.

Voilà, ça casse pas trois pattes à un canard, mais n'ayant pas trouvé d'articles sur ce problème, j'en écris un petit. J'espère que ça en débloquera certains.

samedi 27 décembre 2008

Ajaxterm : un terminal SSH dans son navigateur !

Si comme moi vous avez besoin d'accéder à une machine en SSH depuis un peu n'importe où, sans avoir besoin de télécharger un logiciel, de brancher une clef USB "portable" (comme la Framakey), ou sans avoir à faire de tunnels compliqués parce que certains ports sont bloqués, je vous conseille de vous tourner vers l'excellent Ajaxterm.

Ajaxterm vous permettra d'obtenir un terminal directement dans votre navigateur. Il n'est pas d'une réactivité à toute épreuve, mais il se défend très très bien, et c'est somme toutes agréable d'avoir une solution simple à sa disposition. Ajaxterm m'a déjà dépanné plus d'une fois.

L'installation sous Debian est simplissime grâce au paquet... ajaxterm. Il faudra quand même se farcir quelques lignes de configuration Apache2 que je vous laisserai récupérer dans le fichier /usr/share/doc/ajaxterm/README.Debian ou directement le site de l'auteur.

Vous pouvez voir une démo d'Ajaxterm, qui bien sûr vous laissera "prisonnier" dans Nano, mais vous permettra de voir à quoi ressemble Ajaxterm une fois installé.

À tester et à installer de toute urgence, c'est toujours intéressant d'avoir un Plan B sous la main.

lundi 24 novembre 2008

Dotclear 2 : passage de QUERY_STRING en PATH_INFO sans douleur

Si vous voulez changer la méthode de lecture de l'URL dans Dotclear 2 mais que vous ne voulez pas casser vos liens existants, votre référencement et vos flux RSS (gloups :S[1]), rien de plus simple. Dans votre fichier .htaccess (éventuellement à créer) à la racine de Dotclear, mettez les lignes suivantes :

RewriteEngine On
RewriteBase /

# Rewrite old QUERY_STRING urls
RewriteCond %{QUERY_STRING} !^$
RewriteRule ^index.php$ %{QUERY_STRING}? [R=301,L]

# Get nice URLs with DotClear 2
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule (.*) index.php/$1
RewriteRule ^index.php$  index.php/ [L]

Les dernière lignes viennent directement de l'aide sur le site de Dotclear et les deux du milieu sont là pour rediriger les pages en QUERY_STRING vers du PATH_INFO (en gros la même chose sans le index.php? donc un peu plus joli... et surtout mieux référencé par la majorité des moteurs !). J'ai précisé un code HTTP de retour à 301 qui veut dire Moved permanently (déplacé pour toujours) pour que les moteurs de recherche mettent à jour leur liens.

N'hésitez plus à faire le passage si votre hébergeur vous autorise le Rewrite.

Notes

[1] Je suis confus d'avoir pourri le Planet-Libre avec deux articles n'ayant rien à voir... à cause de cette perte de liens.

mercredi 9 juillet 2008

Denyhost : finies les attaques bruteforce sur mon serveur

Dans mon article Mes premiers pas vers un système sécurisé j'avais rapidement présenté Logwatch qui permet de recevoir à intervalles prédéfinis un résumé des fichiers de logs d'un serveur.

Ce qui m'étonne le plus dans mes logs, c'est le nombre de tentatives de connexion SSH à mon serveur. Adapter à la main le fichier /etc/hosts.deny est un peu lourd !

Heureusement, j'ai trouvé (ou plutôt Alban m'a parlé de) un petit outil sympathique, Denyhosts, qui permet automatiquement de bloquer les IPs qui tentent un peu trop de connexion vers votre serveur. Le script s'installe sous Debian avec apt-get install denyhosts et est directement fonctionnel.

Les options de configuration sont très nombreuses et se trouvent dans le fichier /etc/denyhosts.conf qui est bien documenté. Vous pouvez :

  • choisir le nombre de tentatives au bout desquelles bloquer une IP,
  • choisir de bloquer plus rapidement les tentatives en root ou sur des comptes inexistants,
  • bloquer les IPs que pour le SSH ou bien pour tous les services du serveur,
  • retirer automatiquement les IPs du fichier /etc/hosts.deny après une durée déterminée,
  • ...

Bref, le tout est assez puissant, simple à mettre en place, et vraiment pratique. Attendez-vous par contre à une petite avalanche de courriels sur votre serveur car par défaut Denyhosts vous envoie un courriel à chaque ajout dans les hosts.deny...

Attention, n'oubliez pas de vous ajouter dans les /etc/hosts.allow ou à utiliser une clef privée si vous ne voulez pas vous faire bannir de votre propre serveur :)

- page 1 de 4