Maethor's blog

Backupninja, des sauvegardes incrémentales simples et efficaces

Par maethor lundi 28 janvier 2013 dans Adminsys

Les sauvegardes, c'est bien, on est tous d'accord là dessus. Ça devient nettement moins sympa quand il faut les mettre en place. En général, deux solutions se présentent, utiliser une bonne grosse usine à gaz type BackupPC, ou coder tout à la main à base de rsync + hardlinks ou autres tar incrémentaux pour pouvoir faire ce qu'on veut, et surtout pour savoir ce qu'on fait.

La solution dont je vais vous parler se place précisément entre les deux. Vous êtes adminsys, vous n'avez pas besoin d'une interface web pour gérer vos backups. Par contre, vous n'avez pas envie pour autant d'aller systématiquement tout coder en shellscript. Gérer les crontab, les erreurs, les différents dumps avant les copies distantes, etc… Backupninja permet de configurer tout ça sans se prendre la tête, et plus encore.

Puller… Pusher…

Bien qu'il soit tout à fait possible de faire des sauvegardes en local (sur un disque dur externe, par exemple), nous allons nous intéresser ici au cas où elles sont effectuées en réseau d'une machine à une autre. Pour les backups distantes, vous n'avez pas 150 stratégies. En gros vous en avez deux, puller ou pusher.

Puller, ça consiste à mettre le script de backup sur la machine qui va rappatrier les sauvegardes depuis la machine sauvegardée. Vu qu'on automatise les sauvegardes, ça veut dire que la machine qui stocke les sauvegardes a un accès root sans mot de passe sur la machine à sauvegarder.
Pusher, c'est l'inverse. On met le script de backup sur la machine sauvegardée, qui va donc envoyer elle-même ses sauvegardes vers la machine qui les stocke. Vu qu'on automatise, ça veut dire que la machine sauvegardée a un accès sans mot de passe (pas forcément root) sur la machine qui stocke les sauvegardes.

Il n'y a pas une stratégie qui soit meilleure que l'autre. Tout dépend des situations et des outils utilisés pour les sauvegardes. Rsyncd, par exemple, permet de donner un accès à des répertoires prédéfinis depuis une IP prédéfinie, en lecture seule si besoin, avec un simple mot de passe qui sera passée en argument à rsync. Donc pas besoin d'accès root, ça permet de sécuriser nettement le choix du "pull". Si vous cherchez à sauvegarder une machine, les deux cas se valent.

Dans mon cas, j'avais besoin d'automatiser la sauvegarde d'une 15ene de machines. Les différences en terme de sécurité entre les deux solutions commencent à apparaître.

Pull : Une machine a accès root (au moins en lecture) sans mot de passe à toutes les machines du réseau.
Push : Toutes les machines du réseau ont accès en écriture sans mot de passe à la machine qui stocke les sauvegardes, et donc potentiellement aux données des autres machines du réseau, puisqu'elles sont toutes sauvegardées au même endroit.

Je suis parti sur l'option Push. J'ai tendance à penser qu'elle est plus sécurisée (il suffit d'utiliser un utilisateur différent par machine, et elles ne pourront pas accéder aux backups des autres machines), et elle s'adapte mieux à l'outil que je vais utiliser pour les synchronisations, rdiff-backup, qui ne permet pas de limiter l'accès en lecture, contrairement à rsyncd. En plus, j'ai de toutes façon besoin d'effectuer quelques sauvegardes en local, notamment des dumps MySQL, PostgresSQL et LDAP qui seront rapatriés avec les fichiers.

Quoiqu'il en soit, l'outil que je vais présenter gère parfaitement les deux politiques, donc vous pouvez toujours choisir celle qui vous convient le mieux.

J'ajoute aussi que backupninja permet d'effectuer des sauvegardes incrémentales, c'est à dire qu'il ne stockera que les modifications faites depuis la dernière sauvegarde, et ceci sur un roulement de X jours (7, par exemple, ou 60 si vous avez de la place). Ça veut dire qu'en cas de problème, vous pouvez récupérer n'importe laquelle des X dernières sauvegardes effectuées. On ne fait pas des sauvegardes que pour parer aux problèmes matériels, mais aussi pour les erreurs humaines. Si vous supprimez un fichier par accident, vous pourriez mettre plusieurs jours à vous en rendre compte, et ce serait dommage de ne pas pouvoir le retrouver dans vos sauvegardes.

Mise en place

Maintenant qu'on a vu comment procéder, voyons la mise en place.

Tout d'abord, l'installation. Sur Debian c'est tout simple, sudo aptitude install backupninja. Si vous voulez recevoir des rapports par mail, profitez-en pour configurer le serveur mail à coup de sudo dpkg-configure exim4-config, ça ne fera pas de mal.

Backupninja s'administre par des fichiers de configurations très lisibles et très bien commentés.

/etc/backupninja.conf contient la configuration générale de backupninja. Ici, vous ne configurez pas les politiques de sauvegardes mais l'heure des sauvegardes (1h du matin, par défaut), l'adresse mail à prévenir en cas de problème (root), etc…
/etc/backup.d/ contient les sauvegardes à effectuer. Vous trouverez des exemples de fichiers de configuration dans /usr/share/backupninja. Vous pouvez y mettre autant de fichiers que vous le voulez, en respectant les bonnes conventions de nommage. Ces fichiers seront exécutés par ordre alphabétique. Typiquement, visez bien pour faire un dump SQL avant d'expédier vos répertoires (y compris le dump) sur le serveur distant. Mais j'ai dit que ce serait simple et efficace, donc ne commencez pas à ajouter des fichiers de configuration maintenant, il y a mieux !

Ninjahelper

Backupninja est livré avec un outil vraiment très pratique, ninjahelper. Vous ne le savez pas encore, mais c'est exactement ce qu'il vous manquait pour mettre en place vos sauvegardes sans vous prendre la tête.

Lancez simplement sudo ninjahelper.

Vous n'avez plus qu'à choisir ce que vous voulez sauvegarder. Commencez par exemple par MySQL pour faire un dump de vos bases là où vous le voulez (typiquement dans /var/backup). Vous êtes déjà root, pas besoin du moindre mot de passe.

Ensuite, passez à l'étape intéressante, les backups incrémentales des répertoires. Ninjahelper gère par défaut plusieurs outils, rdiff-backup notamment. Cet outil dispose d'un avantage conséquent, il simule son propre filesystem sur la machine destinataire, ce qui permet une bien meilleure sécurité des données sauvegardées. En effet, les droits sur les fichiers (propriétaires + droits) sont sauvegardés par rdiff-backup, et non par le système de fichier de la machine destinataire. Du coup, si vous voulez sauvegarder un fichier appartenant à root, vous n'avez pas besoin d'être root sur la machine destinataire pour conserver les droits (on ne peut pas créer un fichier appartenant à root sans être root). Un autre énorme avantage de rdiff-backup, c'est que vous avez constamment accès à la dernière version des données, car il enregistre les modifications vers le passé. À l'inverse, avec rsync+hardlink, vous stockez la plus ancienne version (snapshot), puis les modifications vers le présent.

Ninjahelper va gérer absolument toute la procédure de mise en place des backups en mode push. Après avoir spécifié les fichiers à sauvegarder et l'endroit où les envoyer, il va essayer de se connecter au serveur distant en ssh, vous demander le mot de passe de l'utilisateur, générer une clé sans mot de passe, créer les répertoires qui accueilleront les backups (ce qui permet de vérifier si votre utilisateur a les droits d'écrire dessus), etc. Il va même installer rdiff-backup si ce n'est pas déjà fait. Toute cette automatisation est vraiment extrêmement pratique.

Vous pouvez tester vos sauvegardes via ninjahelper, en sélectionnant le script puis "run". Et voilà, c'est en place ! Il ne vous reste plus qu'à aller siroter une bonne bière l'esprit tranquille, vous avez des backups !

aucun commentaire aucun rétrolien

Deux configurations cgit sur un même serveur

Par maethor mercredi 18 janvier 2012 dans Adminsys

J'avais prévu de faire un article pour raconter un peu comment installer et configurer cgit, mais aujourd'hui, je met définitivement le char avant les sangliers. Si vous ne savez pas ce qu'est cgit, mea culpa, je m'engage à essayer d'y remédier dans un futur article

Aujourd'hui donc, j'ai commencé à partager mon serveur pour accueillir un ami qui avait les mêmes besoins que moi, à savoir mail, web et git. Problème, comment faire en sorte de lui proposer un cgit, à l'image de mon dépôt public, avec sa propre configuration, donc son propre /etc/cgitrc.

Comme toujours quand je ne connais pas, j'ai commencé par essayer l'approche dégueulasse, patcher cgit pour modifier le path, « forcément » codé en dur quelque part, et recompiler le tout avec un nouveau fichier de configuration, disons /etc/meow.cgitrc. Un petit coup de grep sur les sources, et on remarque une option dans le Makefile, génial ! Je modifie l'option, je recompile, ça ne marche pas… snif !

Après quelques recherches, je suis tombé sur l'astuce tant recherchée. En fait, cette option est une variable d'environnement Apache. Il suffit donc de redéfinir la variable CGIT_CONFIG dans le virtual host Apache pour que cgit aille chercher un autre fichier de configuration. Dans mon exemple, j'ai donc le morceau suivant.

<VirtualHost *:80>
    ServerName git.meowstars.org
    DocumentRoot /srv/git/repositories

    Alias /cgit.css /srv/git/cgit.css
    Alias /cgit.png /srv/git/cgit.png
    Alias /favicon.ico /srv/git/favicon.ico
    ScriptAlias /cgit.cgi /srv/git/cgit.cgi

    <Location />
        DirectoryIndex cgit.cgi
        SetEnv CGIT_CONFIG "/etc/meow.cgitrc"
    </Location>

    # …suite de la conf…
</VirtualHost>

Ainsi, chacun sa page, chacun affiche les projets qu'il veut afficher, sans avoir à recompiler quoique ce soit. Moralité, il y a toujours au moins une façon crade et une façon propre de faire quelque chose !

aucun commentaire aucun rétrolien

Envoyer les commits Git par mail automatiquement

Par maethor lundi 16 janvier 2012 dans Adminsys

Je me souviens que lors de mon dernier stage en entreprise, c'était à LDD à la fin de mon IUT, j'ai découvert une méthode d'organisation qui m'avait beaucoup plu. Ils reçoivent tout les commits de leur dépôt SVN par mail sur une liste de diffusion à laquelle sont inscrits tous les développeurs de l'entreprise. Ça permet à chacun de suivre en temps réel, par mail, l'évolution du projet. En ce qui me concerne, mon organisation fait que je reçois par mail absolument tout ce que je dois recevoir, à l'exception des flux RSS. Je préfère éviter d'aller chercher les infos par-ci par-là (logs des serveurs, évolutions des projets...). Du coup, je trouve cette organisation extrêmement pratique lorsque le projet ne possède pas de gestionnaire de ticket susceptible d'envoyer les avancées par mail, comme ChiliProject que j'utilise dans le cadre de Aquilenet.

Il se trouve justement que nous venons de commencer les projets de programmation de Master 1, par équipe de cinq. Nous sommes rapidement tombés d'accord pour utiliser Git, dont le dépôt est hébergé sur mon serveur. J'ai aussi installé un Sympa pour gérer des listes de diffusion. Les conditions étaient parfaites, il fallait impérativement réunir les deux pour faire envoyer les commits Git sur une liste de diffusion !

L'opération s'est révélée beaucoup plus simple que prévu, l'occasion pour moi d'explorer une facette de Git que j'avais ignorée juste là, les hooks.

Basiquement, en informatique, un hook (littéralement « crochet » ou « hameçon ») permet à l'utilisateur d'un logiciel de personnaliser le fonctionnement de ce dernier, en lui faisant réaliser des actions supplémentaires à des moments déterminés (Wikipedia, toussa...). Dans le cas de Git, le système permet d'exécuter des scripts à des moments importants de l'utilisation… par exemple lorsque le serveur reçoit des commits ! Vous voyez où je veux en venir ?

Les hooks Git

Il y a en fait deux types de hook Git, les hooks "client", et les hook "serveur". Comme vous l'avez sûrement compris, les premiers sont exécutés par les clients, c'est à dire les dépôts locaux, les machines des développeurs. Ils sont habituellement présents dans le répertoire .git/hooks/ de votre dépôt cloné. Si vous regardez, vous trouverez d'ailleurs quelques exemples dans ce répertoire. Les hook "serveur", quant à eux, sont exécutés sur le serveur. C'est donc un de ces derniers qui nous intéresse. En effet, ce sera bien le serveur Git qui, à chaque réception de commit suite à un git push, enverra ce (ou ces) commit par mail à une adresse donnée. Ces hooks sont présents dans le répertoire du dépôt coté serveur. Attention, j'insiste bien, coté serveur. Dans mon cas, le répertoire des hooks serveur du dépôt pdp (Projet de Programmation) se trouve donc dans /srv/git/repositories/pdp.git/hooks/

Par chance, le hook qui nous intéresse est déjà présent dans la documentation Git de Debian, en temps qu'exemple. Il se trouve dans /usr/share/doc/git/contrib/hooks/post-receive-email. Copiez ce fichier dans le répertoire hooks du dépôt concerné, renommez le post-receive (hook exécuté à la réception d'un push), et rendez le exécutable.

cd /srv/git/repositories/toto/hooks/
cp /usr/share/doc/git/contrib/hooks/post-receive-email post-receive
chmod +x post-receive

Il ne vous reste plus qu'à configurer le dépôt, toujours coté serveur, pour ajouter les bonnes variables de configuration des hooks. Pour ce faire, ajouter les lignes suivantes dans le fichier config du dépôt concerné :

[hooks]
    mailinglist = "adresse1@toto.fr adresse2@toto.fr..."
    envelopesender = "git@toto.fr"
    emailprefix = "[GIT] "

Ces variables sont largement documentées au début du script post-receive-email. En gros, mailinglist contient la liste des adresses auxquelles envoyer l'email, envelopesender contient l'adresse de l'expéditeur et emailprefix contient le tag du mail. Seule la première variable est obligatoire (sinon il saura pas à qui envoyer…). Vous pouvez aussi configurer le sujet de l'email, qui correspond à la première ligne du fichier description du dépôt Git, toujours coté serveur.

Voilà ! Ce sera tout pour aujourd'hui. Il ne vous reste plus qu'à tester, et si vous avez des questions, n'hésitez pas à utiliser les commentaires ;-)… Si vous n'avez pas de question, n'hésitez pas non plus à commenter, ça fait toujours plaisir !

aucun commentaire aucun rétrolien

Divers outils auto-hébergés

Par maethor vendredi 13 janvier 2012 dans Web

Faire son propre "cloud" #4 - Fin de la série

Je ne m'étendrai pas beaucoup plus longtemps sur les autres services que j'ai choisi d'héberger sur mon propre serveur, mais voici une petite liste non-exhaustive.

Mail

Le mail est certainement le service le plus important hébergé sur mon serveur. Il faudrait cependant bien plus d'un article pour expliquer tout les détails de mon architecture. Je lâche donc quelques mots clés, si vous êtes intéressés par un article plus long, laissez un commentaire ou contactez-moi

J'utilise Postfix pour recevoir et envoyer des emails. Ce dernier se base sur des utilisateurs virtuels gérés par une base de données PostgreSQL. Cette solution me permet notamment de gérer proprement plusieurs domaines et alias, mais aussi de ne pas dépendre d'utilisateurs UNIX pour les boites mail. Pour lire ces mails, j'utilise le serveur IMAP (et POP) Dovecot. Les mails sont filtrés automatiquement à l'aide de filtres Sieve. Je peux ainsi ranger mes mails dans diverses mailboxes en fonction de leur contenu, du destinataire, de l'expéditeur, de la liste de diffusion… tout est possible. Enfin, le trio Amavis, ClamAV et SpamAssassin s'occupe des filtrages antivirus et antispam. Associer ces trois outils à une bonne configuration de Postfix, c'est la garantie d'éliminer 90% des spams. Pour les 10% restants, j'utilise un plugin Dovecot et un script à base de learning SpamAssassin pour que, lorsque je déplace un mail dans la boite Spam, SpamAssassin apprenne à détecter ce spam à l'avenir.

Si vous êtes un grand fan de l'interface web de Gmail, alors vous trouverez probablement votre bonheur avec le Webmail Roundcube. En ce qui me concerne, je n'utilise pas de Webmail, préférant le client mail en console Mutt. Néanmoins, j'ai eu l'occasion d'installer et d'utiliser Roundcube pour le serveur mail de l'association Aquilenet, et je dois dire que son ergonomie et sa simplicité sont vraiment très agréables. Il est aussi très simple à installer et s'adapte à tout type de base de données. Plus rien ne vous retient chez Gmail désormais !

Git

J'ai aussi installé sur mon serveur le fameux gestionnaire de gestion Git, qui me permet de centraliser et de partager tout mes projets de développement, ainsi que mes fichiers de configuration. Pour gérer finement les droits d'accès par utilisateur et pour ne pas dépendre des utilisateurs UNIX, j'utilise actuellement Gitosis, largement documenté sur le web. Néanmoins, ce dernier n'est plus maintenu, et je prévois donc de migrer assez rapidement^[1] sur le petit nouveau, Gitolite, utilisé notamment par le projet Fedora. Qui sait, cette migration fera peut-être l'objet d'un futur article ? D'ici là, n'hésitez pas à jeter un œil à mes projets publics.

Upload de fichiers

Lorsque vous possédez votre propre serveur web, il arrive bien souvent que vous ayez envie de mettre rapidement un fichier en ligne, pour le partager avec un ami, par exemple. C'est encore Sebsauvage qui nous fourni la solution la plus simple ! Vous trouverez plus d'informations sur la page dédiée du wiki de Sebsauvage, qui renferme bien d'autres trésors.

Conclusion

Voilà, la série se termine ici pour le moment. J'espère qu'elle vous aura fait découvrir des outils intéressants et utiles pour votre organisation. Si vous connaissez d'autres outils que vous voulez suggérer, ou si vous avez la moindre question, n'hésitez pas à laisser un commentaire ;-). Bien entendu, je vous ferai part des évolutions de mon panel d'outils, dès qu'elles se présenteront.

Notes :

[1] En fait, je n'ai pas eu le temps de finir cet article avant la migration Gitosis -> Gitolite. Donc je suis désormais sous Gitolite.

3 commentaires aucun rétrolien

Shaarli, l'agrégateur de lien (alternative à Delicious)

Par maethor dimanche 4 décembre 2011 dans Web

Faire son propre "cloud" #3

Je n'avais jamais vraiment saisi l'utilité des agrégateurs de liens tels que Delicious. En gros, dès que vous êtes sur une page qui vous intéresse, vous cliquez sur un bouton et le lien est immédiatement posté sur un site… Comme un J'aime de Facebook, mais qui ne fait que ça, et le fait bien, en théorie. Un marque-page centralisé et public, pour résumer.

Encore une fois, comme le soulève Sebsauvage sur son blog, de nombreux problèmes techniques et libertaires se posent. Ces sites gardent souvent l'historique de toutes les pages que vous avez visitées, même celles que vous n'avez pas marquées, gênant. Il y a quelques semaines, il a donc décidé de développer et de publier un simple script PHP qui permet de gérer ça en 150 lignes et sans base de données, afin que chacun puisse héberger le logiciel sur son propre serveur, même minimaliste. Ce programme se nomme Shaarli (Shaare Links).

Au départ, j'avoue que je voulais juste le tester histoire de reporter quelques bugs afin d'aider l'auteur de cette très bonne initiative. Et puis je me suis pris au jeu, en me rendant compte que ce système pourrait véritablement me permettre de fermer mes 40 onglets ouverts dans Chromium, en attente de lecture ou de traitement. Mission réussie après quelques jours d'adaptation, le résultat sur http://links.subiron.org/ (et si je rajoutais un lien permanent en haut du blog, au fait ? Je le note dans MyTinyTODO :D). L'interface est simple, ça fait juste ce qu'on lui demande, et ça le fait vraiment bien. Grâce aux commentaires de la communauté et au dynamisme de l'auteur, les versions se multiplient et les améliorations sont de plus en plus intéressantes : aperçu des photos et des vidéos présentes dans les liens, nuage de tags et mur de photos… sans pour autant que le code grossisse démesurément.

Par contre au niveau de l'organisation, contrairement aux deux outils précédents, je ne m'impose aucune règle particulière. Je ne marque pas forcément toutes les pages intéressantes que je trouve, je ne marque pas forcément que des pages intéressantes non plus. En somme c'est un peu n'importe quoi, pour le moment. J'essaye juste de trouver les bons tags pour chaque entrée, afin qu'il y ait un minimum de classement, et que ça puisse servir plus tard.

À l'époque de l'installation, le look de Shaarli était vraiment horrible. J'ai donc modifié la feuille CSS pour obtenir mon propre thème. Sebsauvage s'en est d'ailleurs un peu inspiré, avant de le changer pour intégrer entièrement un nouveau thème développé par un utilisateur. N'étant pas particulièrement fan des couleurs de ce nouveau thème, j'ai conservé le mien. Si vous aimez ce design, n'hésitez pas à télécharger cette feuille de style (actuellement pour la version 0.30) et remplacer le fichier style.css présent dans le répertoire de Shaarli. Pour le moment c'est probablement assez peu portable (tant pis pour IE), mais c'est aussi en TodoList. Autre problème, de part sa légèreté, Shaarli n'inclut aucun système de template pour le moment (mais c'est programmé pour la prochaine version 0.32). Je suis donc limité à la modification de la CSS. Heureusement, CSS permet vraiment de faire beaucoup de choses, et le HTML de Shaarli est assez propre jusqu'à la version 0.30.

Que ce soit pour bloguer, pour conserver ou pour partager vos liens, je vous recommande vivement cet outil, simple et efficace ! Dès que la version 0.32 sortira, j'essaierai de porter mon thème le plus rapidement possible sur le nouveau template. Stay in touch

aucun commentaire aucun rétrolien

L'art de transformer ses clients en produits

Par maethor lundi 28 novembre 2011 dans Internet

Voici un article originellement écrit pour le site de Aquilenet, FAI associatif dont je suis secrétaire. Du coup y'a plein de "on" à la place de "je".
Lien original de l'article : https://www.aquilenet.fr/article/281111/lart-de-transformer-ses-clients-en-produits

Si vous n'êtes pas encore abonné chez Aquilenet, chez FDN, ou chez un vrai FAI, vous avez forcément dû remarquer sur votre connexion que certains sites ont tendance à être plus lents que d'autres. Curieusement, chez Orange par exemple, on constate que Youtube est plus lent que Dailymotion. Je dis curieusement, parce qu'il ne nous viendrait pas à l'idée que ceci puisse avoir un rapport avec le fait que Orange est actionnaire de Dailymotion.

Mais voilà que ces derniers jours, la presse semble s'émouvoir une énième fois le problème. Free, suspecté de brider Youtube, voudrait faire payer Google (propriétaire du Youtube en question). Alors plutôt que de tourner encore une fois autour du pot en se remémorant les épisodes précédents, essayons de comprendre comment un opérateur peut imposer ce genre de négociation au titan incontestable du web.

Lire la suite →

aucun commentaire aucun rétrolien

MyTinyTODO et GTD, n'oubliez jamais ce que vous avez à faire

Par maethor mardi 22 novembre 2011 dans Web

Faire son propre "cloud" #2

Déjà trop longtemps que traîne le brouillon de cet article. Voici enfin la suite de notre série.

Le deuxième outil absolument indispensable pour moi au quotidien est le gestionnaire de TodoList. Quoi de plus frustrant que d'avoir une idée, et le choix entre la mettre en œuvre tout de suite ou la laisser filer ? La solution est pourtant simple, la noter, tout noter. C'est la méthode d'organisation que j'ai choisi d'adopter il y a quelques mois, avec succès.

Il existe de nombreux outils permettant de gérer ces TodoList, allant des plus fermés et complexes (Remember The Milk, Evernote) aux plus simples et ouverts. MyTinyTodo fait partie de la seconde catégorie. Du coup, comme par hasard, c'est lui que j'ai choisi d'utiliser.

Avec MyTinyTodo, vous ne faites que l'essentiel, et c'est bien ce qui importe. Ajouter des tâches (nom, description), les ranger dans diverses listes, les taguer, leur donner une date d'échéance et une priorité. À part le nom de la tâche, tout est optionnel. Quand elle est terminée, vous cochez la case et elle disparaît comme par magie. Cette application web embarquée, basée sur AJAX et une base de données SQLite, propose aussi une CSS adaptée aux smartphones... que demander de mieux ? Une API, peut-être... Screenshot MyTinyTodo

Mais comme je l'ai dit, un outil doit s'accompagner d'une méthode pour l'utiliser.

Lire la suite →

aucun commentaire aucun rétrolien

NON à ACTA

Par maethor mercredi 2 novembre 2011 dans Internet

aucun commentaire aucun rétrolien

Faire son propre "cloud" pour se libérer de Google et compagnies

Par maethor vendredi 14 octobre 2011 dans Web

Depuis quelques mois, de pus en plus de blogueurs célèbres ont publié des articles de ce genre. Il faut croire que les évènements donnent de plus en plus raison aux idées de décentralisation et d'auto-hébergement. Google supprime des comptes sans prévenir et Microsoft ne fait pas mieux en retrouvant tout ses services internationaux indisponibles pendant des heures à cause d'un DNS corrompu. Des heures, ça peut vous sembler peu, mais pour certaines entreprises dépendant de ces services, c'est du temps à ne rien pouvoir faire. Autant donner une après midi de chomage technique à ses employés.

Mais pour certains (dont moi), le problème de la centralisation chez Google and co va au delà des aspects purement fonctionnel. Il s'agit de données personnelles, de ce qu'il y a de plus confidentiel (mail, centres d'intérets, calendrier et todolists). Pourquoi fournir ces données à un entreprise étrangère soumise au Patriot Act, alors qu'il est possible de les héberger chez soit ?

Voici une petite série d'articles qui ne répondra pas à cette question, bien au contraire.

N'étant pas moi même utilisateur de toute la collection de services proposés par Google, je ne pourrai pas donner une alternative à chacun d'eux. Dans cette série d'articles, je présenterai donc les outils que j'utilise pour mon organisation personnelle, en espérant que cela puisse servir à d'autres. J'ai commencé à utiliser ces outils il y a quelques mois, et je vous garanti qu'ils peuvent vraiment révolutionner l'organisation personnelle, à condition de les accompagner d'un peu de méthode. Et ça commence au premier épisode : TT-RSS, l'alternative à Google Reader

aucun commentaire aucun rétrolien

TT-RSS, l'alternative à Google Reader

Par maethor vendredi 14 octobre 2011 dans Web

Faire son propre "cloud" #1

Pour être honnête, je n'ai jamais utilisé Google Reader, je ne me risquerai donc pas à une quelconque tentative de comparaison. TT-RSS (pour TinyTinyRSS) est un aggregateur de flux RSS (et Atom) en version Web. En d'autres termes, vous l'installez sur un serveur, et vous pouvez accéder à vos RSS via votre navigateur web préféré, depuis n'importe quel ordinateur connecté à Internet. Il existe même une application mobile officielle très bien conçue (testée sur Androïd).

J'ai pu lire par-ci par-là que cette application était très consommatrice en espace disque, de par son format de stockage des articles, et qu'il valait donc mieux le configurer pour supprimer automatiquement les vieux articles. Je ne l'ai pas fait, aucun soucis à signaler pour le moment, mais mon serveur (Dedibox) est dimensionné relativement large, donc bon..

Malheureusement, TT-RSS comporte à mon goût énormément de bugs et de choix d'interface relativement étranges. Par exemple, ctrl+clic-droit sur un article ne l'ouvre pas dans un nouvel onglet du navigateur, mais dans un nouvel onglet de TT-RSS... sauf que c'est parfaitement inutile pour les flux RSS contenant les trois premières lignes des articles... Autre manque gênant, je n'ai toujours pas trouvé comment voir d'où provient l'article que je suis entrain de lire. Dans la plupart des cas, je peux le deviner au style ou au contenu, mais parfois non. Je trouve ça assez frustrant. Signe de gros problèmes dans la conception.

Beaucoup commencent donc à parler d'un nouveau gestionnaire de flux RSS web, RSSLounge, qui apparait comme étant plus léger et surtout plus convivial que TTRSS. Rien qu'à voir la différence entre le design des deux sites, c'est convainquant ! Malheureusement, cet aggregateur ne supporte que le système de gestion de base de données MySQL. Fervant utilisateur de PostGreSQL, je dois donc me résoudre à attendre un portage, peut-être dans une future version. D'ici là, si vous n'êtes pas aussi bornés que moi, rien ne vous empèche de le tester

Utiliser un agrégateur de flux RSS (et Atom)

Force est de constater que beaucoup n'utilisent pas correctement leur aggregateur de flux RSS, et par conséquent finissent par ne plus pouvoir l'utiliser du tout. J'ai moi même été confronté il y a quelques années au problème de surcharge de l'aggregateur. On part une semaine en vacances sans lire ses flux, on revient et 200 news nous attendent. On repousse au lendemain le dépilage... et les news continuent à s'agglutiner comme des badeaux à la sortie du nouvel iPhone. Alors on fini par ne plus utiliser l'outil, préférant faire le tour des blogs qui nous intéressent quand on en a envie.

C'est lors de la lecture d'un excellent article sur le blog de Nicolargo que j'ai réalisé mon erreur, et l'importance crutiale de cet outil dans l'organisation (et de l'organisation dans l'utilisation de cet outil). Quelques règles sont donc à suivre, absolument

Ne pas utiliser l'aggregateur pour des sites à forte publication (plus d'un ou deux articles par jour). Si vous le faites, les "petits" sites seront noyés dans la masse, et c'est dommage car il s'agit probablement des plus intéressant. Je prend mon cas pour exemple, si un article du blog de fdn se perdait au milieu des articles de Numérama, ce serait vraiment dommage. Il vaut donc mieux utiliser l'aggregateur pour les petites sources, afin de vous éviter à les vérifier tout les jours. À contrario vous savez très bien que Korben publie 5 articles par jour, autant aller les lire directement sur son site, donc. Les favoris du navigateur vous assisteront à merveille dans cette visite quotidienne.
Lisez vos RSS dès que celà vous vient à l'idée et que vous avez 2 minutes de libre. Plus vous les lisez souvent, moins ils s'accumulent.
Si exceptionnellemnt les news se sont accumulées (vacances...), n'hésitez pas à faire le grand ménage. Lisez les articles qui vous intéressent dès le titre, marquez tout les autres comme lus. Sauf si vous voulez vraiment tout lire tout de suite, évidemment. La grosse erreur consiste à repousser la lecture à plus tard, et à laisser des articles dans l'état "non lu". Il faut mieux parcourir la liste en vitesse et marquer des articles comme "important", pour les relire en détail plus tard. On récupère ainsi un aggregateur sans article "non lu", afin de repartir sur une nouvelle base.

Si vous appliquez scrupuleusement ces conseils, alors vous verrez que l'utilisation d'un aggregateur est un véritable plaisir, et permet de gagner énormement de temps lors de votre veille quotidienne. Bien sûr, je n'affirme pas que cette méthode est la seule et la meilleure, mais elle a le mérite d'exister, et de fonctionner.

un commentaire aucun rétrolien

« billets précédents - page 1 de 2