Cela fait quelque temps que je vois mes scripts cgi sous lighttpd hériter de l'environnement root (vous savez, les export et autres setenv dans votre ~/.$SHELLrc). Et si vous êtes un peu parano comme moi ou que vous avez des données sensibles dans votre environnement il peut s'avérer utile de les cacher du script cgi.

Pour cela j'ai modifié mon /usr/local/etc/rc.d/lighttpd, du coup j'en ai même fait un bug report chez FreeBSD histoire que tout le monde en profite. Il permet même de spécifier certaines des variables d'environnement que l'on veut conserver (comme PATH qui est souvent utilisé dans les script cgi).

Avec un peu de chance (et beaucoup de temps :>) il le prendrons et vous l'aurez bientôt dans vos ports. Sinon faite le vous même à partir du patch :

cd /root
fetch http://www.philpep.org/pub/lighttpd_rc.patch
cd /usr/local/etc/rc.d/
patch -p0 < /root/lighttpd_rc.patch

L'inconvénient c'est qu'il faut le refaire à chaque mise à jours de lighttpd.

Si vous avez un serveur git sous FreeBSD, vous aurez très rapidement des problèmes avec /usr/local/etc/rc.d/git_daemon, genre il démarre mal, et refuse de redémarrer.

En fait il suffit d'utiliser l'option --reuseaddr qui passe SO_REUSEADDR à setsockopt pendant la création du socket serveur. Du coup il peut redémarrer même si il y avait une connexion active sur le port.

En lisant le script rc, on peut même éviter de le modifier et devoir le refaire à chaque mise à jours de git, dans /etc/rc.conf

git_daemon_enable="YES"
git_daemon_directory="--reuseaddr --base-path=/usr/home/git/repositories"

EDIT : ce n'est plus nécessaire maintenant PR ports/143275

J'ai toujours eu du mal à me positionner par rapport à google et les faits récents viennent renforcer l'opinion de Benjamin Bayard de chez fdn qui dit (en très gros) que Google n'a pas à nous inquiéter pour l'instant parce que ce sont encore les fondateurs qui sont aux manettes et l'esprit originel est encore là.

Pourtant les raisons d'avoir peur et de commencer le boycot sont bien là puisqu'il s'agit sans doute de la plus grande centralisation de données de l'Internet. Moteur de recherche, service mail, serveurs DNS récursifs ouverts, vidéo (youtube), service de blog (blogspot), creation de documents (Google Docs) et pour aller avec tout ça une énorme régie publicitaire (AdSense). Ils savent manipuler les données dans tous les sens, mais comme ils disent : "c'est pour mieux satisfaire le client". Moi qui n'utilise que le moteur de recherche (et un compte gmail qui sert de poubelle), j'ai déjà super peur à l'idée de croiser mon dossier chez Google qui je le rappelle est autorisé à vous tracer (en france) pendant 9 mois. Mais imaginez celui de ceux qui utilisent tous les services de google (et j'en connais). Ajoutez à cela deux faits marquants

• Google.cn en chine censure son moteur de recherche parce qu'ils y sont forcés par la loi. (ce n'est plus le cas aujourd'hui cf plus bas)
• Gros, gros dérapage d'Eric Schmidt président de google, sur la vie privée

Je pense qu'il faut faire preuve de jugeotte. S'il y a quelque chose que vous faites et que personne ne doit savoir, peut-être qu'il faudrait commencer par ne pas le faire. Si vous avez besoin qu'on respecte à ce point votre vie privée, le fait est que les moteurs de recherche – y compris Google – enregistrent et conservent des informations pendant un certain temps. Il faut bien réaliser que nous, aux USA, sommes soumis au Patriot Act et donc qu'il est possible que toutes ces informations soient mises à la disposition des autorités à leur demande.

Et pourtant, si vous suivez un peu les actualités récentes, Google suite à une vaste opération de piratage de comptes gmails de dissidents chinois (supposée venant des autorités chinoises), vient d'enlever la censure sur google.cn et menace de quitter le pays. On peut lire beaucoup d'informations à ce sujet allez voir sur Numérama si vous êtes vraiment à la ramasse.

Personnellement je n'ai pas compris comment une entreprise aussi menaçante se met soudain à faire pression sur un gouvernement quitte à perdre un max de pognon, juste pour protéger son image de marque et pour être du coté des gentils. En fait ça rappelle une vielle histoire où Yahoo! avait collaboré avec les autorités chinoises pour espionner les boites mails de dissidents. Google essaye de ne pas reproduire cette erreur qui a beaucoup coûté à l'image de Yahoo!. Et cette décision viendrait directement d'un des deux co-fondateurs de google. Ce portrait très flatteur de l'homme (Sergey Brin) qui vient d'un journal à peu près fiable (Libération) renforce donc l'idée d'une éthique chez Google malgré les enjeux financier, ce qui n'a pas l'air d'inspirer Microsoft (Bing) qui reste en chine et collabore du moment qu'on les arrose de pognon. Le patron de Mozilla s'était donc un peu emporté quand il invitait les utilisateurs de firefox à passer à Bing..

Difficile, vraiment difficile de se faire un avis, la solution est peut être de commencer à se passer totalement de moteur de recherche, ou encore mieux de faire votre propre moteur de recherche (hein rhaamo :>)

Il y a peu je vous parlais de spamd, il vient de m'arriver une mésaventure assez horrible avec. Nous somme le 14 janvier 2009, un de mes utilisateur se plaint de ne pas recevoir un mail en particulier.

# zgrep spamd /var/log/daemon.0.gz | tail -n 3
Jan  5 20:21:26 solo spamd[28383]: 93.17.128.3: disconnected after 386 seconds. lists: spamd-greytrap
Jan  5 21:30:19 solo spamd[28383]: 93.17.128.3: connected (1/1), lists: spamd-greytrap
Jan  5 21:35:49 solo spamd[30146]: greyreader failed (Error 0)

Il y a donc 9 jours que mon spamd est mort (pour des raisons que j'ignore jusque là). Le coté vicieux de la chose c'est que ma table spamd-white était bien fournie et pf les redirigeait comme il faut vers mon vrai MTA (postfix). Du coup il recevait des mails mais pas tous. Je n'ai donc rien remarqué pendant ces 9 jours de panne.

Je me passe de spamd à partir d'aujourd'hui lui préférant dspam et qui est beaucoup plus facile à mettre en place avec un MX secondaire (pas besoin de synchronisation de parre feux etc).

RHAAAA !!

Je parlais il y a un mois d'une probable release de pblog. Et en cette belle nuit du 8 janvier 2010 c'est chose faite.

Les plus observateurs (ou ceux qui ont vraiment du temps à perdre) d'entre vous auront remarqué que le git et taggé 1.0 depuis fort longtemps. Mais on voulait faire durer un peu histoire de fixer quelques trucs, et surtout de documenter.

Quoi de neuf depuis la dernière fois, pas grand chose et beaucoup à la fois, des finitions des tests etc. Maintenant pblog a été testé avec succès (et non sans mal) sur trois serveurs web libres que sont Apache2 (pas testé avec le 1.3 à vous de jouer), Lighttpd et Nginx. Des exemples de configurations sont disponibles dans le code.

Comme toujours lisez bien le README, il y a un script d'installation rapide mais personnellement (et parce que c'est moi qui ai codé ce script d'install qui bug dans de nombreux cas) je vous recommande une installation manuelle (c'est expliqué dans le README).

La config est assez souple et permet de faire beaucoup de choses, lisez donc config.py.example et vous verrez c'est simple.

Quand je vous parlais de documentation c'est du lourd, pblog a maintenant un site dédié vous y trouverez le pourquoi du comment, et aussi une section sur notre wiki.

Bon voilà il ne me reste plus qu'à vous inviter à télécharger cette release et surtout n'hésitez pas à nous contacter (voir comment dans le README) pour des retours, ce qui vous plaît, ce que vous détestez etc.

Vers pblog 2.0 ?

L'équipe est bien motivée (mais ça peut changer très vite ...) et pense déjà à pblog 2.0 , le développement prend une allure de totale réécriture, nous avons découvert les vertues de SQLAlchemy et du coup webpy ne servira plus des masses, on pense aller vers CherryPy qui ne fait que de la gestion URL et qui est plus robuste.