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.).

Les détails et conditions sont ici. Et quelques exemples de mon travail se trouvent dans ma galerie photo.

Si vous êtes intéressé(e)s, j'insiste : ne me contactez pas à partir d'une adresse hotmail, ma réponse aurait de grandes chances de ne jamais vous parvenir.

Il y a quelques mois, j'ai diffusé cette annonce sur le site étudiant de Lyon 2 pour recruter des modèles amateurs. À cette occasion, j'ai rencontré plein de jeunes filles très sympathiques (je ne désespère pas de trouver quelques garçons), et j'ai fait plus de 23 Go de photos.

Valve : vous vous êtes bien foutu de notre gueule.

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 !

Sur la machine qui reçoit les logs

Il faut remplir deux conditions : votre machine doit accepter les connexions à destination de syslogd, et ce dernier doit savoir quoi faire des données qu'il reçoit.
Pour dire à syslogd d'accepter les connexions venant du réseau, il suffit de modifier les paramètres de lancement dans le fichier /etc/rc.conf. Éditez ce fichier pour que la ligne syslogd_flags ressemble à ceci :

syslogd_flags="-c4C -a machine_distante"

Je vous renvoie au man syslogd pour la signification des options. Par exemple, si votre réseau est en IPv6, remplacer le 4 par un 6. "machine_distante" est le nom ou l'IP de la machine dont vous souhaitez centraliser les logs. Vous pouvez préciser plusieurs fois le paramètre -a, pour ajouter des machines, des netmasks...

Par défaut, syslogd n'accepte que les données qui proviennent d'une machine listée dans le -a, et dont le port distant est 514. Si vous souhaitez agréger des logs de machines sous Mac OS X Server par exemple, il vous faudra préciser le port "*", car ce système utilise un port non privilégié pour envoyer ses données :

syslogd_flags="-c4C -a machine_distante -a macosx_server:*"

Ensuite, il faut régler le contenu du fichier /etc/syslog.conf pour assigner une destination à chaque flux de log. Et c'est ici que la difficulté se trouve. Si on n'y prend garde, des données sont écrites dans de mauvais fichiers, d'autres ne sont pas écrites du tout.
Si les machines sont assez peu nombreuses, je recommande la simplicité : un bloc de définition = une machine. C'est plus verbeux, mais c'est aussi plus simple à corriger/modifier.
Un bloc consiste en une série d'instructions débutant par une définition de machine ou de programme (ou des deux). L'ordre doit toujours être :

1. définition facultative de machine
2. définition facultative de programe
3. sélecteur et action
4. ...

Pour éviter toute interférence entre deux blocs consécutifs, je recommande de placer à la fin de chaque bloc un "reset" pour la définition de machine. Voici un exemple :

   1: +machine_distante
   2: mail.info                                       /var/log/maillog
   3: +*
   4:
   5: +macosx_server
   6: mail.*                                       /var/log/maillog
   7: local5.*					/var/log/maillog
   8: +*
   9:
  10: +@
  11: *.err;kern.warning;auth.notice;mail.crit		/dev/console

Je suis ici tout au début de mon fichier /etc/syslog.conf. Ma première ligne indique que le bloc qui débute concerne les logs en provenance de la machine "machine_distante". Tout ce qui vient de cette machine, et qui appartient au sélecteur mail.info sera enregistré dans le fichier /var/log/maillog.
La troisième ligne fait un "reset" de la machine.
Ligne 5, j'ouvre un bloc qui concerne la machine "macosx_server". Lignes 6 et 7 je défini mes couples sélecteur/action, puis ligne 8 je ferme mon bloc avec un "reset".
Ligne 10, j'utilise le nom de machine @ qui représente la machine locale. Les lignes suivantes sont les couples sélecteur/action pour localhost.

Une fois tout ceci réglé, il vous suffit de relancer syslogd (en root) :

# /etc/rc.d/syslogd restart

Sur les machines qui envoient les logs

Pour finir, il reste à configurer le syslogd des machines distantes pour qu'ils envoient les données voulues vers votre serveur FreeBSD. À nouveau, je vous renvoie vers le man syslogd, qui à ce niveau est assez clair. Voici par exemple ce qu'il faut ajouter au fichier /etc/rc.conf d'un FreeBSD :

syslogd_flags="-cs"

Cela permet à syslogd de parler sur le réseau, sans l'autoriser pour autant à recevoir des connexions venant de l'extérieur.
Puis dans le fichier /etc/syslog.conf, on indique simplement les sélecteurs que l'on souhaite envoyer vers le serveur. Par exemple, ces deux lignes indiquent que je veux écrire les logs de mail.info en local et sur la machine distante "serveur_syslogd" :

mail.info					/var/log/maillog
mail.info					@serveur_syslogd

Relancez le syslogd de la machine dont vous modifier la configuration, assurez vous bien sûr que les firewall laissent passer le trafic qui vous intéresse, et tout devrait fonctionner.

Si ça coince

Si ça ne fonctionne pas, vous avez deux outils pour trouver le point de blocage. Le premier outil est tcpdump. Il vous aidera rapidement à voir ce qui sort d'une machine et ce qui arrive à l'autre. Par exemple, sur le serveur de log :

# tcpdump -A src or dst host machine_distante and port syslog

Cette commande vous permet de vérifier que les paquets venant de machine_distante vous parviennent bien sur le port 514. La commande suivante permet de vérifier, sur "machine_distante" que les paquets à destination de serveur_syslogd tentent bien de sortir :

# tcpdump -A src or dst host serveur_syslogd and port syslog

Si les deux commandes donnent satisfaction, alors la connexion entre les deux machines est bonne, et le problème ne vient pas d'un éventuel firewall.

Le second outil qui dépanne, c'est l'option -d de syslogd : le mode debug. Ajoutez ce paramètre à syslogd_flags dans votre rc.conf (sur la machine qui centralise les logs), et relancez syslogd. Après quelques lignes indigestes, les informations intéressantes arrivent. Voici un exemple :

   1: cvthname(192.168.0.20)
   2: validate: dgram from IP 192.168.0.20, port 514, name machine_distante;
   3: accepted in rule 0.
   4: logmsg: pri 26, flags 0, from machine_distante, msg ../..
   5: Logging to FILE /var/log/maillog
   6: cvthname(192.168.0.20)
   7: validate: dgram from IP 192.168.0.20, port 514, name machine_distante;
   8: accepted in rule 0.
   9: logmsg: pri 26, flags 0, from machine_distante, msg  ../..
  10: Logging to FILE /var/log/maillog
  11: cvthname(192.168.0.250)
  12: validate: dgram from IP 192.168.0.250, port 50194, name macosx_server;
  13: rejected in rule 0 due to port mismatch.
  14: rejected in rule 1 due to port mismatch.

Lignes 1 à 10, on a deux exemples de trames correctement acceptées par notre agrégateur de log, et venant du port 514 de "machine_distante".
Lignes 11 à 14, on a un rejet de trame, venant du port 50194 de la machine "macosx_server". Sans doute avons-nous oublié d'indiquer :* comme port autorisé pour la machine "macosx_server" dans les options syslogd_flags.
Ici, le mode debug nous dit clairement où est notre erreur : rejected in rule 0 due to port mismatch.
Si vous avez un gros débit de log, coupez rapidement le mode debug (ctrl-c), supprimez le -d de votre syslogd_flags, et relancer syslogd. Vous aurez tous le temps d'analyser la trace ensuite.

Pris isolément, chaque stage vaut bien l'initiation au studio que j'ai suivie avec l'association Imag'in. C'est plus cher, mais c'est plus long. Et selon le thème on y trouve plus ou moins d'informations techniques. Le gros défaut, c'est le manque de suivi : il est bien évident que sur un stage d'une journée, il est totalement impossible de revenir sur les photos du jour avec le maître de stage, et d'envisager une quelconque progression.
Le stage d'une semaine aux RP offre quant à lui une vraie opportunité de travailler, de progresser, le tout dans une ambiance plus sereine et débarrassée de tous les aspects négatifs énumérés plus hauts.
Si vous cherchez une vraie expérience profitable, choisissez plutôt les stages des Rencontres Photographiques que les stages du FEPN.

note : première photographie © Edouard De' Pazzi

1 : Torche Elinchrom Style et boîte à lumière ~80x80 pour le modèle, Ranger Quadra et boîte 40x40 pour le fond
2 et 3 : Ranger Quadra et boîte à lumière 40x40