Blekko : un moteur de recherche original …


A l'heure où Google adapte son algorithme pour lutter contre le spam il est temps de faire un tour d'horizon des solutions alternatives en matière de recherche Web. De nombreuses initiatives ont, de part le passé, vu le jour (Cuil, Wolfram Alpha ...) mais ces dernières n'ont pas vraiment réussie à prendre des parts de marché significatives.

C'est dans ce contexte qu'un nouvel outil est apparu il y a quelques mois : Blekko. La particularité de ce moteur est de permettre de limiter la recherche à une liste de site web prédéterminée (par le simple ajout d'un "slashtag" à la suite de la requête).

Par exemple la requête "paracetamol /health" ne retournera que des résultats issus de sites de confiance,  référencés dans le domaine de la santé. On obtiendra ainsi moins de résultats mais de meilleure qualité.

Il existe une multitude de "slashtag" prédéfinis par les équipes de Blekko : "/recipes" pour les recettes de cuisine, "/biotech", "/rugby" ...) Vous pouvez consulter la liste complète  ICI.

Il est également possible de consulter la liste des sites web composant chaque "slashtag" en utilisant une requête de la forme "/view /blekko/le_nom_du_slashtag".

Mais la force de Blekko réside dans son aspect communautaire. En effet, chaque utilisateur peut définir ses propres slashtags qui pourront ensuite être utilisés par les autres membres. Il est ainsi possible de créer vos propres listes de sites en fonction de vos besoins. Les slashtags prennent alors la forme suivante "/nom_utilisateur/nom_du_slashtag".

A signaler également que pour chaque URL ajoutée,  Blekko fournie une analyse SEO plutôt bien détaillée.

Même si le pari de ce nouveau moteur est encore loin d'être gagné, cette initiative à toutefois le mérite d’apporter une solution originale visant à améliorer la qualité des recherches sur le net.

www.blekko.com

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é".

 

 

Dopez facilement Firefox avec le cache en RAM

Bien que Firefox soit, par défaut, un navigateur particulièrement rapide, une solution permet d'améliorer encore sensiblement sa réactivité : il s'agit de légèrement modifier la configuration d'origine afin qu'il n'utilise pas le disque dur pour stocker les informations du cache mais plutôt la mémoire vive de votre PC (ou de votre MAC ...). Résultats : des temps d'accès aux éléments présents dans le cache très sensiblement améliorés.

Si vous avez envie de tester c'est très simple ...

  • Commencez par un petit "about:config" dans la barre d'adresse de Firefox
  • Saisissez ensuite "browser.cache" au sein du champs de recherche
  • Supprimer le cache sur disque en double cliquant sur la variable "browser.cache.disk.enable" (la valeur devrait passer à "false")
  • Double cliquez sur "browser.cache.memory.enable" afin de commuter la valeur en "true"
  • Créer la nouvelle variable "browser.cache.memory.capacity" (clic droit sur la fenêtre principale -> nouvelle  -> valeur numérique) et assignez lui une valeur en kilo - octets (par exemple 100 000 pour 100Mo). Bien entendu vous pouvez modifier cette valeur en fonction de vos besoins (par exemple si vous disposez d'une machine avec une RAM importante)

Vous devriez, à ce stade, avoir un truc qui ressemble à ça :

Fermez ensuite  toutes les fenêtres et redémarrez Firefox.

Si vous souhaitez revenir en arrière il suffit bien entendu de réactiver le cache sur disque ("browser.cache.disk.enable" à "true") et de supprimer le cache en mémoire ("browser.cache.memory.enable" à "false").

Vous avez essayé, je suis preneur de vos observations ...

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!

Deux astuces pour la mise à jour (Froyo) du Samsung Galaxy S avec Kies

Comme vous le savez certainement Samsung a respecté ses engagements : la mise à jour  d'Androïd (Froyo - 2.2) est désormais officiellement disponible pour le Galaxy S. Je possède depuis quelques mois ce téléphone et j'ai donc décidé de tenter la mise à jour (il faut dire que cette dernière est quand même assez importante depuis qu'une faille critique sur le navigateur embarqué dans la 2.1 a été découverte ...).

Et bien les amis, autant vous prévenir tout de suite c'est quand même une belle galère !  Le principal problème vient du fait qu'il est nécessaire d'utiliser (du moins si l'on souhaite respecter un mode de mise à jour officiel) le logiciel "Samsung Kies". Ce dernier intègre tout un tas de fonctions qui, à mon avis, ne servent absolument à rien, mais si vous voulez mettre à jour c'est un passage obligé ...

J'ai passé quasiment une demi journée (et oui quand même ...) à comprendre pourquoi mon mobile n'était pas reconnu par Kies ! Je voulais donc vous fournir deux petites astuces qui devraient vous épargner pas mal de temps si vous souhaitez tenter l'aventure (bien que je ne pense pas que ce bug soit  généralisé) !

Premier problème rencontré : lors de la connexion USB entre le Galaxy S et le PC j'obtenais, sur le téléphone, un écran "MTP Application" (avec un dessin d'une prise USB en plein écran) qui s'affichait et disparaissait (en boucle) ... Le téléphone n'était bien entendu pas reconnu par le logiciel. Si vous rencontrez ce problème la solution consiste à formater la carte SD Interne, puis si cela ne suffit pas de faire de même avec la SD externe. Bien entendu n'oubliez pas de sauvegarder vos données avant cette opération !!! Pour formater : Paramètres -> Carte SD et mémoire -> Carte SD externe -> démonter la carte SD -> Carte SD externe(/interne) -> Formater la carte SD - Si cette option est grisée il est nécessaire de préalablement démonter la carte.

Deuxième problème, après avoir solutionné le premier point : l'écran "MTP Application" ne tourne plus en boucle (il affiche même un beau message "connecté") mais le téléphone n'est toujours pas reconnu par Kies (le soft affiche un message du type "connexion en cours" ou un truc du genre - mais rien ne se passe ...). Dans ce cas  déconnectez le téléphone, démontez la carte SD externe (Paramètres -> Carte SD et mémoire -> Carte SD externe -> démonter la carte SD)  puis reconnectez le phone.

Une fois le téléphone reconnu par Kies, la mise à jour vous sera automatiquement proposée. Pour moi tout s'est ensuite bien passé. Mes premières impressions sur la version 2.2 "officielle" :  je constate dans la plupart des cas une vitesse/réactivité améliorée par rapport à la version 2.1. Mais bizarrement  je rencontre, de temps en temps ,des lags quand même un peu gênants. A voir avec une future mise à jour de la 2.2 ...

  • Télécharger Kies : ICI

[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