http://www.gcu-squad.org/2010/05/19-mai-19-mai-il-a-quoi-de-special-ce-jour/

J'aime leur annonce

Il est grand temps de purifier les BDD jv.com à grands coups de postgresql ! ;p

J'ai postgres aussi sur ma station

Effectivement, excellente l'annonce. J'ai bien aimé l'allusion aux news noyau de patrick_g sur linuxfr et sa réponse en commentaire. :p
Ça me fait penser que j'ai deux machines à upgrader dont une qui sera impactée par la nouvelle syntaxe pf. :/

Bof les changements sont assez minimes Par contre ça me fait penser que j'ai eu aucune réponse à ce message http://marc.info/?l=openbsd-misc&m=127195017931433&w=2

Si quelqu'un a une idée, je suis preneur. J'ai prévu de passer la machine concernée en -current et de relancer sur la ml, dès que j'aurais le temps...

Dargor, j'ai deja reflechit a ca, et je ne sais pas bien comment faire avec les outils "classiques" que l'on a sous linux. Le plus simple est probablement d'avoir un routeur interne qui reparti la charge entre les deux routeurs externes pour eviter a avoir a configurer toutes les machines du reseaux et pour avoir une vision globale du traffic. Mais meme une fois que tu as mis un routeur pour faire borker, je ne connais pas de moyen de faire ca. Et tu as l'air d'en savoir bien plus que moi

Le plus simple est probablement d'avoir un routeur interne qui reparti la charge entre les deux routeurs externes pour eviter a avoir a configurer toutes les machines du reseaux et pour avoir une vision globale du traffic

C'est l'idée oui, cette machine est censée être une gateway. Ça marche parfaitement en round-robin mais dès qu'on rajoute le sticky-address ça déconne, sans raison apparente

mmm, je viens de comprendre que ton reseau interne utilise des IP non publique. Pourquoi en pas affecter un canal a chaque machine et migrer frequement (toutes les x minutes) les machines d'un canal a l'autre pour equilibrer la charge ?

Cela fournirait bien evidement un equilibrage moins bon, mais resoudrait le probleme des sticky address la plupart du temps. Tu peux aussi ne pas migrer une machine qui doit etre sticky a moins qu'elle fasse vraiment chier (plus de 10x minutes et load important)

C'est une idée, je peux prévoir d'allouer dans une table la connexion à allouer et effacer la table de temps en temps, mais ça ferait une duplication d'efforts vu que c'est déjà censé être implémenté dans pf

tu cherches juste a equilibrer l'upload ou tu es inquiet pour le download egalement ?

Effectivement les changements étaient assez minimes. :p
Moins d'une heure pour l'upgrade des deux machines. \o/
Sinon aucune idée pour le problème de load balancing, j'ai jamais eu à faire ça.

"Pourquoi en pas affecter un canal a chaque machine et migrer frequement (toutes les x minutes) les machines d'un canal a l'autre pour equilibrer la charge ?"

J'aurais tendance à penser que changer l'IP publique d'une machine n'est pas une bonne chose à faire (au moins lorsqu'elle a déjà des connections en cours), il y a pas mal de serveur que ça dérangerait (ou, qui par mesure de sécurité, déconnecte un client qui change d'IP). Même si c'est un problème _par application_ il doit être assez difficile au niveau du routeur de déterminer si l'IP peut changer. Ou alors, il est possible d'émettre sur une interface mais avec une IP source qui est celle de l'autre interface ?

Bonjour,

En ce moment nous parlons beaucoup de l'évocation d'un portage de Steam sous Linux. C'est fantastique, nous allons découvrir l'achat au gros plus cher que l'achat à l'unité :
http://store.steampowered.com/sub/1036/

Y a pas a dire, ils sont vraiment très fort

bonsoir,
j'ai un petit problème en dev system. Hier mon programme marchait, mais ajd j'ai rencontré un problème.
En gros, je suis connecté sur une socket udp sur mon localhost, et j'attend des paquets qui doivent arriver, paquets que je redirige ou pas vers des hotes en fonction de certaines conditions.
Mon problème est que je n'arrive plus a créer de socket vers ces hotes, car je me mange une erreur : "Address family not supported by protocol" au moment de la création de la nouvelle socket.

J'ai cherché un peu, et il se trouve que lorsque je recois un paquet udp (j’emploie donc recvfrom), l'adresse du client qui l'a envoyé n'est pas la bonne :

struct sockaddr_in remoteAddr;
if ((numbytes = recvfrom(listener, buf, MAXBUFLEN, 0, (struct sockaddr *)&remoteAddr, &addr_len)) == -1) {
perror("recvfrom");
}
else{
printf("de : %s \n",inet_ntoa(remoteAddr.sin_addr));

L'adresse affichée à l'écran de debug , est fausse, je ne sais même pas d'ou elle sort...
Je fais des tests avec un unique client qui a son adresse ip sur le réseau, et cette adresse ne correspond pas avec celle affichée...

Ma question est donc :
D'ou vient l'erreur d'ip ? (hier je n'avais pas de problème, c'est ca qui m'étonne^^)
Précisons que je travaille sur un hote ubuntu (pas taper!!! j'ai que ca sous la main là^^) et que le client est sous win xp.

http://www.google.fr/#hl=fr&source=hp&q="Address+family+not+supported+by+protocol"&btnG=Recherche+Google&aq=f&aqi=&aql=&oq=&gs_rfai=&fp=5767821d1ca09201 ?

J'ai pas d'idée pour le moment, et ce message aurait sans doute plus sa place sur le forum programmation.

dnob, c'est deja ca qu'il fait (changer l'ip publique de la machine). Je proposais juste de mettre un delai suffisaement long pour que l'utilisateur ne voit pas la difference.

ok je file faire un tour sur le forum programmation

tu cherches juste a equilibrer l'upload ou tu es inquiet pour le download egalement ?

Juste l'upload.

J'aurais tendance à penser que changer l'IP publique d'une machine n'est pas une bonne chose à faire (au moins lorsqu'elle a déjà des connections en cours), il y a pas mal de serveur que ça dérangerait (ou, qui par mesure de sécurité, déconnecte un client qui change d'IP). Même si c'est un problème _par application_ il doit être assez difficile au niveau du routeur de déterminer si l'IP peut changer. Ou alors, il est possible d'émettre sur une interface mais avec une IP source qui est celle de l'autre interface ?

pf garde une trace des connexions en cours, un socket ouvert ne changera donc pas d'IP. Après niveau application c'est en effet un souci, d'où le sticky-address qui est censé envoyer une IP vers la même box même si tous les sockets ont été fermés, de manière transparente donc.

D'ou vient l'erreur d'ip ? (hier je n'avais pas de problème, c'est ca qui m'étonne^^)

bzero(&remoteAddr, sizeof remoteAddr) avant l'appel à recvfrom ?

Je suis très loin d'être un pro de pf donc j'imagine que c'est soit très con, soit que tu as déjà essayé… mais as-tu testé de rajouter un « keep state » à ta règle de routage vers tes interfaces :
pass in log on $int_if route-to \
{ ($ext1_if $ext1_gw), ($ext2_if $ext2_gw) } sticky-address \
from $int_net keep state
?

Il semble que la « sticky connection » existe tant que l'état de la connexion existe, d'où l'hypothétique nécessité du « keep state »…
Ça peut valoir le coup de forcer l'algorithme de répartition à round robin (c'est censé être celui utilisé par défaut mais sait-on jamais…) vu que toutes les méthodes de répartition ne supportent pas le sticky-address.
pass in log on $int_if route-to \
{ ($ext1_if $ext1_gw), ($ext2_if $ext2_gw) } round-robin sticky-address \
from $int_net

s/testé/tenté/ et :
pass in log on $int_if route-to \
{ ($ext1_if $ext1_gw), ($ext2_if $ext2_gw) } round-robin sticky-address \
from $int_net keep state
pour la dernière règle plutôt…

C'est inutile en théorie, vu que ce sont les valeurs par défaut. Un pfctl -vf /etc/pf.conf le confirme, on voit bien apparaître round-robin, inet et flags S/SA keep state aux bons endroits.

En pratique je suis assez désespéré pour essayer