1. Connectez-vous à la machine en SSH, via un compte admin (ben oui, il y a quand même quelques pré-requis)
2. Tapez les commandes suivantes : sudo -s puis echo "enabled">/etc/ScreenSharing.launchd

C'est fini. Le partage d'écran est activé sur ce Mac.

La sauvegarde est une des briques de la sécurité informatique. En tant que telle, elle en hérite deux caractéristiques élémentaires : c'est un compromis, et c'est indispensable.

Les seules variables réelles pour l'utilisateur se trouvent donc au niveau de ce compromis. Sauvegarder des données, cela prend du temps, de la place, éventuellement de la bande passante, c'est contraignant, cela requière de l'attention. Il faut donc faire un compromis entre ce que l'on veut sauvegarder et les moyens qu'on est prêt à mettre en œuvre.

Par exemple, il est très facile de faire une sauvegarde de toutes ses données, mise à jour toutes les heures, avec possibilité de remonter dans le temps sur un an d'historique ou plus. Vous branchez un disque dur sur votre machine, et vous configurez Time Machine (si vous êtes sur Mac, pour les autres plateformes charge à vous de trouver le logiciel équivalent). Les sauvegardes sont alors totalement automatiques.
L'accès aux données est rapide, et très simple. Mais si votre logement est cambriolé, incendié, innondé, ou que votre machine est victime d'un pirate ou d'un gros virus, vous avez toutes les chances de perdre à la fois les données de votre machine et leurs sauvegardes.
Il faut donc éloigner la sauvegarde de l'ordinateur pour assurer la sécurité de vos données. Cela se complique. On peut mettre le disque externe en lieu sûr, mais alors cela oblige à des manipulations entre chaque sauvegarde : sortir le disque de sa cachette, le brancher, sauvegarder, le débrancher, le remettre en lieu sûr... Pénible !
La solution simple est alors de passer par internet, mais c'est lent. Allez donc sauvegarder 200 Go de données via votre ligne ADSL. Et puis d'abord, où allez vous trouver autant de place ? Il faut payer un hébergement spécialisé. On en trouve des pas trop chers, mais contrairement à un disque dur, la dépense est mensuelle.
Tel que je vois les choses, il faut utiliser la sauvegarde locale cumulée à la sauvegarde distante. Plus la sauvegarde est éloignée (et donc pénible d'accès), moins je sauvegarde de données. C'est aussi simple que ça.
La seule réflexion que doit mener l'utilisateur dans ce cas de figure, est la hiérarchisation de ses données. Il doit décider parmi ses données les quelles il est inutile de sauvegarder, les quelles il est utile de sauvegarder, les quelles il est important de sauvegarder, etc.
Pour la sauvegarde locale, on est sur du disque dur. L'accès est performant, c'est de la sauvegarde de confort. On peut y placer toutes les données, même les données peu importantes.
Pour une sauvegarde intermédiaire (sur une autre machine du réseau par exemple), on est en accès relativement rapide, mais moins que le disque local, et on a aussi sans doute un peu moins de place. On va donc omettre les données peu importantes (les gros logiciels installés dont on a le CDROM dans l'étagère, les fichiers volumineux qu'on peut retrouver facilement ailleurs...).
Pour la sauvegarde hors-site (sur un serveur accessible via internet), on sait que l'accès est lent, que l'espace est compté et facturé, on doit donc se limiter à l'essentiel (emails, documents personnels, photos de famille irremplaçables, factures électroniques...).

C'est un fonctionnement en entonoir. Plus la sauvegarde est contraignante (distance, temps d'accès, coût), plus vous la limitez en volume.

À titre d'illustration, voici comment mes sauvegardes "ceinture et bretelles" fonctionnent :

- Dans mon Mac, j'ai un second disque dur qui sert pour Time Machine, j'ai donc une sauvegarde incrémentale sur plus de 2 ans de toutes mes données. Toutes les heures, Time Machine fait une sauvegarde sur ce disque. L'accès est rapide, mais le disque de sauvegarde est dans la même machine que le disque sauvegardé. Le risque de perdre les deux en même temps est maximal.

- Sur mon réseau local, j'ai une seconde machine, avec un disque dur dédié aux sauvegardes. J'ai sur le Mac un script qui se lance tous les deux jours, et qui envoie sur cette seconde machine une partie de ma dernière sauvegarde Time Machine. Cette machine a peu à craindre d'un cambrioleur ou d'un pirate, rien à craindre des virus, mais un sinistre pourrait lui être fatal. L'accès est plus lent qu'un disque local, mais plus rapide que via internet.

- Ensuite, le même script envoie sur un serveur distant, au travers de ma liaison ADSL, un sous-ensemble encore plus petit de ces données. Et ce serveur distant garde l'historique des données une fois par semaine pendant 20 semaines. Je peux donc revenir en arrière de 5 mois sur les données sauvegardées.
Ce serveur est à 400 km, dans un datacenter sécurisé. La probabilité pour que mes deux sauvegardes "maison" et cette sauvegarde distante disparaissent en même temps est nulle.

L'intégralité des trois étapes est bien sûr entièrement automatisée, et tout fonctionne sans intervention humaine. C'est primordial. Si vous utilisez un système de sauvegarde manuelle, vous pouvez être sûr qu'un jour vous oublierez, ou vous vous lasserez.

Pour résumer tout ceci en une ligne : ayez toujours une sauvegarde locale pour votre confort, et une sauvegarde distante pour les données vraiment importantes. Si vous réfléchissez à cela sérieusement, cela vous forcera aussi à considérer l'ensemble de vos habitudes de stockage : qu'est ce que je stocke sur ma machine ? Est-ce vraiment utile de garder tout ça ? Qu'est ce que je peux supprimer ou perdre sans états d'âme ? etc.

Ne faites pas comme Nick Denton, le fondateur de Gawker Media : n'utilisez pas le même mot de passe ridicule (24862486) partout. Ne partagez jamais un mot de passe par email, chat, ou autre, mais partez du principe que les autres le font. Pour finir, ne faites pas confiance aux dépositaires de vos mots de passe.

Joyeux Noël ;)

This weekend we discovered that Gawker Media's servers were compromised,
resulting in a security breach at Lifehacker, Gizmodo, Gawker, Jezebel,
io9, Jalopnik, Kotaku, Deadspin, and Fleshbot. As a result, the user name
and password associated with your comment account were released on the
internet. If you're a commenter on any of our sites, you probably have
several questions.

Outch.

Dans un premier temps il faut activer, si ce n'est déjà fait, la compatibilité Linux dans le noyau de FreeBSD :

# chargement manuel du module
kldload /boot/kernel/linux.ko
# activation du chargement automatique au démarrage
echo 'linux_enable="YES"' >> /etc/rc.conf 

Ensuite (et pas avant), on peut installer les librairies Linux. Pour FreeBSD 8, il faut installer la version f10 :

portinstall -PP linux_base-f10

Attention, si vous êtes en FreeBSD 64 bits (amd64), le package refusera de s'installer, il faudra alors utiliser :

portinstall linux_base-f10

On termine de préparer l'environnement de compatibilité Linux en montant le système de fichier procfs. Il faut ajouter la ligne suivante au fichier /etc/fstab

linproc         /compat/linux/proc      linprocfs       rw 0 0

puis faire un

mount -a

Enfin, on peut installer le client steam :

portinstall linux-steam

En réalité, c'est seulement un logiciel de mise à jour du client steam qui est installé, il faut lancer la mise à jour pour que la vraie commande steam soit installée. Je fais cette étape deux fois :

cd /usr/local/steam/
./steam
# on attend la fin de l'exécution
# puis on recommence
./steam

Le binaire steam est maintenant installé, à jour, et totalement fonctionnel. Via ce client, il est possible d'installer n'importe quel jeu compatible. Voilà comment procéder pour installer Left 4 Dead 2 :

./steam -command update -game left4dead2 -dir /chemin/du/jeu

On remplacera /chemin/du/jeu par le chemin du répertoire dans le quel on souhaite stocker les fichiers du jeu. Attention, pour Left 4 Dead 2 il y a environ 8 Go à télécharger. Si vous êtes sur de l'UFS, c'est donc 8 Go de stockage qui seront consommés. Si vous êtes sur un volume ZFS avec compression GZip, il faut compter environ 4,2 Go d'espace disque consommé. Le téléchargement est assez long, faites une pause, voire même, lancez la commande avant d'aller vous coucher.

Après cela, le répertoire /chemin/du/jeu contiendra un répertoire left4dead2. Dans ce dernier se trouve un script de lancement qui permet de démarrer le serveur dédié Source : srcds_run.
Voici un exemple de lancement :

cd /chemin/du/jeu/left4dead2
./srcds_run -ip 192.168.1.1 +sv_lan 1

L'option -ip permet d'imposer l'IP sur la quelle le serveur écoute. C'est très utile car le script est d'une bêtise monumentale. En effet, pour une raison que j'ignore, le serveur dédié se lance par défaut en utilisant la toute première IP configurée dans le fichier /etc/rc.conf même si la ligne est commentée !
C'est à dire que si votre rc.conf contient les lignes suivantes :

#ifconfig_em0="inet 192.168.128.201  netmask 255.255.255.0"
ifconfig_em0="inet 193.30.227.216  netmask 255.255.255.192"

et bien cet abruti de serveur tente de se lancer sur l'IP 192.168.128.201, alors que, bien sûr, l'IP n'est pas active. Épargnez votre santé mentale, imposez dès le départ une IP à srcds.
L'option +sv_lan 1 quant à elle impose un fonctionnement sur le LAN uniquement, ce qui permet aisément de tester le fonctionnement du serveur sans l'ouvrir sur le monde.

Vous devrez veiller à quelques points de détail :

• le firewall doit autoriser les connexions TCP et UDP sur les ports 26901 et 27015.
• le jeu peut (doit) être lancé avec un utilisateur non privilégié. Créez un compte pour l'occasion, avec un shell /bin/nologin, et toute autre mesure de protection que vous jugerez nécessaire.
  Attention, faire tourner le jeu avec un utilisateur non privilégié n'est pas forcément très simple, surtout si vous l'avez installé en root. J'ai découvert que lancer le jeu une première fois en root peut régler certains problèmes.
• l'utilisateur en question devra notamment pouvoir écrire dans les répertoires /chemin/du/jeu/left4dead2/update, /chemin/du/jeu/left4dead2/left4dead2 et /chemin/du/jeu/left4dead2/left4dead2/{downloads,logs} et dans les fichiers /chemin/du/jeu/left4dead2/left4dead2/*.cache
• il devra aussi pouvoir exécuter les fichiers /chemin/du/jeu/left4dead2/srcds_run /chemin/du/jeu/left4dead2/srcds_linux

Pour un utilisateur non privilégié, en "nologin", le moyen fiable de lancer le serveur est d'utiliser sudo, dans un screen pour être tranquille :

cd /chemin/du/jeu/left4dead2/
screen nice -n -5 sudo -u utilisateur_steam ./srcds_run -ip 192.168.1.1

Avec tout ceci, votre serveur doit être fonctionnel, et permet déjà de jouer. Le plus dur reste à faire, puisque de toute l'histoire de l'informatique, ce sont les serveurs de jeu qui détiennent la triste palme des logiciels les moins bien documentés au monde. Créez un fichier /chemin/du/jeu/left4dead2/left4dead2/cfg/server.cfg et testez des combinaisons jusqu'à obtenir le résultat souhaité.

• Vous devez installer Wireshark sur votre machine (A)
• Vous devez aussi pouvoir vous connecter en root via SSH sur la machine que vous voulez utiliser pour la capture (B)

Dans un premier temps, il s'agit de créer un socket UNIX via mkfifo. C'est ce socket que votre Wireshark va lire en local sur la machine A.

mkfifo capture.fifo

Dans un deuxième temps, il faut ouvrir une connexion SSH de A vers B, lancer tcpdump dans cette connexion, et rediriger la sortie standard dans votre tout nouveau socket.

ssh root@machineB tcpdump -s 0 -U -n -w - -i ath0 >  capture.fifo

Remplacez ath0 par le nom de l'interface réseau qui vous intéresse, et éventuellement, ajoutez aux options de tcpdump les filtres adéquats pour affiner votre analyse.
Attention, pour une connexion avec mot de passe, ssh ne vous demandera le fameux sésame qu'au moment où Wireshark ouvrira le socket. C'est à dire à l'étape suivante.

Dans un troisième et dernier temps, vous pouvez lancer Wireshark sur la machine A si ce n'est déjà fait, et le configurer pour lire votre socket capture.fifo. Pour cela, ouvrez les options de capture, et saisissez le chemin de votre socket dans le champ "interface" :

Enfin, cliquez sur "Start" pour lancer la capture, et si nécessaire, tapez votre mot de passe pour la machine B dans la fenêtre de terminal où votre connexion SSH est établie.

Quelques utilisateurs sont tout de même parvenus à pervertir ce système de vote. Ce n'était pas bien compliqué, c'est certain, mais était-ce bien nécessaire ? Ils ont localisé dans le code HTML une adresse qui permet de voter pour une photo donnée sans l'étape laborieuse du visionnage. Ils ont alors sans aucun doute transmis l'URL adéquate à leurs "amis" de facebook, et c'est ainsi que la plupart des photos en tête de classement sont à la fois totalement hors sujet et complètement inintéressantes. On en voit même certaines gagner plus de 200 votes en quelques minutes. Le pire, c'est qu'il est même techniquement possible de faire voter les gens pour une photo précise à leur insu.

Je ne suis pas surpris que des types pas drôles et sans grande morale se livrent à ce genre de sport. Je suis juste un peu écœuré pour les participants honnêtes, dont les photos sont parfois très jolies et pertinentes, car ils ne seront pas récompensés.
Comment peut on encore participer de bonne foi à ce genre de concours, si on sait que de toute manière seuls les plus roublards, les plus tricheurs, les moins finauds gagneront ?

crédit photo : Thomas Gasparetto

edit : le règlement du concours a été mis à jour, le choix des gagnants sera fait par un jury. Voilà qui est une bonne nouvelle (et qui ne me laisse aucune chance ;) )

Et puis, pour justifier le pluriel de mon titre : j'ai aussi cédé aux sirènes des réseaux sociaux, puisque je suis désormais inscrit sur LinkedIn et Viadeo (Shame. On. Me.).

Je pense que c'est un très bon complément à Flickr (même si je n'utilise pas ce dernier).
Sylights devrait s'étoffer rapidement, avec des fonctions d'annotation, et la possibilité de poster des photos illustrant le montage de lumière décrit (ça semble primordial !).

Un petit exemple tout simple pour la route : mon premier essai.

L'avenir nous dira si c'est une idée lumineuse ou pas. Mais quand les plans seront ré-éditables, qu'on pourra y faire des annotations, et qu'on pourra les "hot-linker" depuis un blog, ça deviendra certainement un outil de référence !

Coder votre proxy personnalisé.

C'est théoriquement l'étape du travail la plus intéressante, puisque c'est ici que l'on peut exprimer toute sa créativité, et surtout apporter la réponse à un de ses problèmes. Comme le programme sera lancé à la demande par launchd, et que c'est ce dernier qui va gérer le socket de communication avec le client, la tâche est simplifiée. En contrepartie, le programme ne peut pas être trop lourd, car des lancements à répétition seraient alors pénalisants pour le reste du système.
Mac OS X est livré avec de nombreux langages de script et de programmation (C, Java, PHP, Python, Ruby, Perl, Shell…). Contrairement à mon habitude, j'ai choisi de coder mon proxy en PHP. De la sorte, je pouvais réutiliser mon code dans un autre contexte au cas où le fonctionnement en proxy ne donnait pas satisfaction.
Voici le squelette de mon script PHP, à titre d'exemple :

#!/usr/bin/php
<?php
// get request from http client
$request = explode(" ", trim(fgets(STDIN)));
$MyGET = $request[1];
// curl request
$ch = curl_init();
curl_setopt($ch, CURLOPT_URL, $MyGET);
curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1);
$output = curl_exec($ch);
// cleanup
curl_close($ch);   

// callback
function fetch_author($matches) {
    ../..
    return $matches[1].$matches[2].$author[1]." ".$matches[3];
}

// html parsing
$apresreplace = preg_replace_callback('/.../',"fetch_author",$output);

// output
echo $apresreplace;
?>

J'ai volontairement simplifié et tronqué mon code. La seule chose qui compte est le squelette du programme. Première remarque, le script fonctionne en mode "ligne de commande". C'est du PHP, mais il ne sera pas interprété par Apache, donc les variables intéressantes de $_SERVER, de $_GET, ... n'existent pas. Je récupère la requête du client HTTP en lisant tout simplement la première ligne de STDIN.
Ensuite, j'utilise les fonctions de la librairie CURL pour aspirer le contenu distant qui correspond à l'URL transmise par le client. Puis je fais sur ce contenu un rechercher-remplacer via la fonction preg_replace_callback et via la fonction attachée que j'ai créée (dite fonction de callback).
Les détails ne sont pas importants, à ce stade ce qu'il faut bien comprendre, c'est que mon script de proxy a reçu l'URL demandée par le client. Il a téléchargé le contenu correspondant à cette URL, et il l'a enrichi selon mes besoins. La dernière ligne du script renvoie dans la sortie standard le contenu enrichi. Le client (mon lecteur de flux RSS) reçoit alors la réponse à sa requête.

Lancer le proxy à la demande

Launchd est l'outil idéal pour lancer le proxy dès qu'une connexion est initiée dans sa direction. Le fonctionnement est alors similaire à inetd (ou xinetd). La problématique est la même que dans le cas de la création d'un tunnel ssh à la demande, donc je passe sur les détails.
Voici le fichier plist de configuration qu'il faut charger dans launchd pour activer le proxy :

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN"
"http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
        <key>Debug</key>
        <false/>
        <key>Label</key>
        <string>tld.monsuper.proxy</string>
        <key>ProgramArguments</key>
        <array>
                <string>/chemin/du/programme/de/proxy</string>
        </array>
        <key>Sockets</key>
        <dict>
                <key>Listeners</key>
                <dict>
                        <key>SockNodeName</key>
                        <string>127.0.0.1</string>
                        <key>SockServiceName</key>
                        <string>8080</string>
                        <key>SockType</key>
                        <string>stream</string>
                </dict>
        </dict>
        <key>StandardErrorPath</key>
        <string>/tmp/proxy.err</string>
        <key>inetdCompatibility</key>
        <dict>
                <key>Wait</key>
                <false/>
        </dict>
</dict>
</plist>

Après avoir adapté le Label, le chemin du programme, le port de connexion, et éventuellement le fichier de stderr, il faut enregistrer ce fichier plist dans ~/Library/LaunchDaemons/ (pour vous seul) ou dans /Library/LaunchDaemon/ (pour tous les utilisateurs de la machine). Ensuite il faut le charger via launchctl load /chemin/du/fichier.plist.

C'est terminé. Toutes les briques du proxy personnalisé sont en place. Le client (si il honore bien les préférences systèmes) utilisera le proxy désigné dans le fichier .PAC. Launchd recevra la requête et la transmettra au programme du proxy. Ce dernier fera les traitements sur les données téléchargées, et renverra le résultat au client.

edit : style et coquilles
edit : ajout de l'IP 127.0.0.1 pour le bind, ça évite que le proxy puisse êtes utilisé par n'importe qui sur le réseau… :)