petit_bibi a écrit 115 commentaires

La possibilité d'empiler des couches n'est pas exclusive à java, il est tout à fait possible de faire de même avec d'autres langages.
Pour s'en convaincre, il suffit de jeter un oeil du coté de l'audio sous linux par exemple...
http://www.trilug.org/~crimsun/linuxaudio.png
Donc à partir d'une certaine profondeur, je dirais que le problème se situe au niveau de la conception.

mais un FakeEmacs me ferait bien plaisir.

Rassures-toi, avec le multitouch ça ne devrait plus trop tarder...

Mm, il ne devait pas y avoir de lumière dans ce tunnel ou alors il ne l'a pas vu..

Il faudrait dans un premier temps rajouter des logs pour savoir ce qui se passe:
(Les règles de log doivent être prioritaires)

for c in 'INPUT' 'OUTPUT' 'FORWARD' ; do
iptables -I ${c} 1 -m limit --limit 2/s --limit-burst 10 -j LOG --log-prefix ${c}:
done
for c in 'PREROUTING' 'POSTROUTING' ; do
iptables -t nat -I ${c} 1 -m limit --limit 2/s --limit-burst 10 -j LOG --log-prefix ${c}:
done


Résultat dans /var/log/.. si syslog est réglé correctement:

INPUT:IN=eth0 OUT= MAC=ff:ff:ff:ff:ff:ff:00:13:72:8b:3a:3f:08:00 SRC=192.168.0.100 DST=192.168.0.255 LEN=94 TOS=0x00 PREC=0x00 TTL=64 ID=34563 DF PROTO=UDP SPT=631 DPT=631 LEN=74
...


Ensuite, tenter d'établir une connection depuis le client et extraire de ces logs les chaines traversées ainsi que les source/destination devices/ip des paquets..
Sachant qu'il y a un process openvpn derrière, peut-être bien que INPUT OUTPUT sont de la partie, Je n'ai jamais utilisé openvpn..


Il faut regarder attentivement les sources IP, dest IP ainsi que IN/OUT devices, et nous les fournir éventuellement ? :-)
Sait-on jamais il y a peut-être aussi du loopback dans le tas, je ne sais pas comment ça se passe avec un process et du PPP...

Enfin, ces règles risquent de générer beaucoup de logs si tu as d'autres truc qui tournent sur cette machine. Mais c'est toujours préférable d'avoir toutes les logs pendant ce genre de recherches pour ne pas rater quelque chose ..

Aussi, si je me souviens seul les paquets de state 'NEW' passent par la chaine PREROUTING. (La signification de NEW dépend du protocole.) Donc c'est normal si il n'y a pas beaucoup de logs au sujet de PREROUTING.

Mandriva (mauvaises expériences par le passé dues à son instabilité

C'est sûr que les bugs/problèmes sont éternels, n'est-ce pas ? Tout le monde sais que Kubuntu ne saura jamais 'packager' un KDE ?

Perso Mandriva 2009.1 avec kde 4.3.1 ça roulaize chez moi et au boulot.
( http://www.kde.org/download/ pour les RPMs)
Pas de bug à signaler, c'est réactif même sur un vieux céléron merdique.
( Je n'ai que du nvidia proprio, je sais mais http://nvidia.ca.marche.meme.si.saimal.fr/ )
Ah si, il y a kopete qui de temps à autre se déconnecte sans raison précise.. bon je n'ai pas encore creusé, car c'est seulement 2-3 fois par semaines.

KDE 4.2 sur opensuse marchait bien quand je le testé, mais Yast , bah j'accroche pas même si il marche bien.
Je l'ai trouvé lent et surtout je n'ai pas trouvé d'équivalent installé par défaut pour faire des choses tel que urpmf urpmq & co..

Effectivement, il est important de modifier la source des paquets forwardé, sinon la machine qui va les recevoir répondra directement à ton client. Ton client recevra (si le réseau et les routes le permettent) des paquets tel que les premiers ACK mais il les ignorera car ils ne viennent pas d'une connection qu'il a initié (response source IP != request destination IP).


Si tu as deux cartes réseaux sur ton 'routeur':

#!/bin/bash
IN_DEVICE=eth0
LOCAL_IP=192.168.0.250
LOCAL_PORT=22

OUT_DEVICE=eth1
OUT_DEVICE_IP=192.168.2.250
NEW_IP=192.168.2.105
NEW_PORT=22
echo 1 > /proc/sys/net/ipv4/ip_forward

iptables -t nat -A PREROUTING -i ${IN_DEVICE} -p tcp -d ${LOCAL_IP} --dport ${LOCAL_PORT} -j DNAT --to-destination ${NEW_IP}:${NEW_PORT}
iptables -t nat -A POSTROUTING -o ${OUT_DEVICE} -p tcp -d ${NEW_IP} --dport ${NEW_PORT} -j SNAT --to-source ${OUT_DEVICE_IP}


Mais ça marche aussi si tu n'as qu'une seule carte et une seule adresse tel que:

OUT_DEVICE=IN_DEVICE
OUT_DEVICE_IP=LOCAL_IP

INPUT et OUTPUT ne sont traversé que pour ce qui va a destination des processus locaux, seul FORWARD est traversé dans ton cas.

ouch, it's openarena mumuse time, @+

ce qui veut dire qu'il track les connexions, et dans NAT il y a _translation_, ce qui veut dire que B va bien faire croire à A que c'est lui qui a inité la connexion.

Dans DNAT il y a Destination, donc seule la destination est modifiée c'est bien pour ça qu'il faut également modifier la source pour faire croire à A que c'est B qui a initié la connection.

quelles sont les autres règles du par-feu ? À priori c'est effectivement un problème de "retour" des paquets, mais il faudrait par exemple bien voir si B qui forwarde autorise bien les paquets retour (avec une règle genre --cstate ESTABLISHED,RELATED), etc.

Les chaines sont en ACCEPT, donc à priori le pare-feu est ouvert (sauf si certaines règles de DROP se trouvent dans la chaine FORWARD..).

A ma connaissance, NEW, ESTABLISHED.. servent à affiner le filtrage du paquet par rapport a l'état de sa connection (si le protocole est stateful). Si ce n'est pas spécifié, pas de filtrage sur ce point.
RELATED c'est utile avec certains protocoles qui ouvrent des ports dynamiquements et qui peuvent être autorisés grace à un 'connection tracker' tel que: irc_conntrack, ftp_conntrack...

Iptables est un firewall _statefull_,

Iptables stateful? j'ai des doutes, car ça dépend du protocole.
Je pense que l'ont peut configurer un firewall stateful avec iptables, mais que ce n'est pas une obligation.
Exemple, UDP est stateless par nature, il me semble qu'iptables simule du stateful en se servant d'un module externe (xt_state, xt_tcpudp probablement) qui utilise des temporisateurs configurables comme ici: /proc/sys/net/ipv4/netfilter/ip_conntrack_udp_timeout.
Ainsi, il est possible d'utiliser des choses tel que -m state --state NEW sur une connection UDP. Mais ça reste optionel (-m).
D'ailleur il me semble que c'est à cause de ce 'UDP-timeout' que quand l'on décide d'interdire un flux UDP, il faut attendre un certain temps avant que cette règle ne soit fonctionnelle sur le traffique déjà existant.. à confirmer..

Rajoute ça sur B:

iptables -t nat -A POSTROUTING -p tcp -d 192.168.0.1 --dport 8080 -j SNAT --to-source 192.168.0.10


Sans cette règle:
-Une machine C envoie un paquet B
-B transmettra bien ce paquet à A. (tcpdump doit pouvoir le confirmer)
-Mais A reçoit un paquet ayant pour source C
-A répond à C alors que C attends logiquement une réponse de B.
-Si C est dans le même réseau que A, C recevra le paquet de 'retour'
mais l'ignorera car il ne vient pas de B.
-Si C n'est pas dans le même réseau, le paquet de 'retour' sera routé via la
gateway par défaut de A qui n'est probablement pas B dans ton cas..

Donc soit le paquet de 'retour' n'arrivera pas, soit il aura une mauvaise source et sera rejetté par C.

Par contre, si B est la gateway par défaut de A et que celle-ci (A) NAT ce qui sort, cette règle de POSTROUTING n'est pas nécessaire quand C est en dehors du réseau A,B.

Avant la fin de cette année un superordinateur dépassera la barre mythique du pétaflops

On va enfin pouvoir faire tourner Vista dans emacs en gardant sa machine en vi !

Trop gros, m'a échappé ->[]

>>4. Installer une vingtaine de programmes par une simple commande.
>4. Voir 3 (Geek)
Je suis effrayé de voir qu'aujourd'hui, utiliser un peu du clavier suffit pour être geek.
Je peux en déduire que tous ceux qui ont connu DOS sont des geek.
Si si, il fallait savoir taper des commandes , je devrais même dire 'des codes' afin d'être compris par nos nouvelles générations.

Et que dire de mon pauvre Amstrad, avec son curseur clignotant et orphelin dans ça boite de 80x25.
A 9 ans, j'étais déjà geek car je tapais des commandes pour installer des trucs, que du bonheur.
D'ailleur, le minitel c'était pour les geek, Il y avait aussi des codes à taper...

à l'endroit même ou on devrait expédier tous les serveur IIS de la planète

Ah non, il y a déjà trop de déchets par la-bas.
http://www.futura-sciences.com/fr/sinformer/actualites/news/(...)

Et pourquoi pas à Naples tant nous y sommes !

10x plus gros ? Tu trouves que 1500 (forme condensee sans RIEN de supprime) c'est 10x plus gros que 767 ? Visiblement on n'a pas suivi les memes cours de math.
Personnellement, j'ai pas mal utilisé cette forme condensée pendant mes cours de math pour TRICHER. Si si, c'est bien le sujet !

Et puis d'abord, le 380 est plus gros que 767 ... alors bon, les maths, toussa ...
Ok, ça vole pas haut --> []

Pour le boulot, j'avais acheté un portable dell XPS M1530, malheureusement il n'était pas dispo avec Linux (et la license de vista m'a été imposée, vente liée toussa...).

Je savais que linux fonctionnerait dessus, car très proche du M1330 livrable avec ubuntu...
Vista, je l'ai amorcé une fois par curiosité pour ensuite le virer et le remplacer comme prévu par une mandriva.
Existe-t-il un endroit chez Dell qui me permette de noter ma réelle utilisation ?

(
Je ne cherche pas un remboursement de license, j'aimerai juste contribuer à rendre les compteurs plus réalistes..
)

Le miens depuis un mois sur mandriva 2008.
Pas de gros soucis et pour l'instant très satisfait.

J'ai du tous de même rajouter ça dans mon modprobe pour le son:
options snd-hda-intel model=3stack

Pour la carte réseau, j'ai du également télécharger les sources de sk98lin chez le fabriquant et compiler le module.
(Le modèle c'est:
.09:00.0 Ethernet controller: Marvell Technology Group Ltd. 88E8040 PCI-E Fast Ethernet Controller (rev 12)
)
A priori sk98lin est 'périmé' mais pour il marche contrairement à celui équivalent de mon kernel.

Pour que le wifi marche, j'ai du ajouter un 'nolapic' dans les options de grub car sinon je me prenais une erreur lors du chargement du module.
Ça semble être un bug récent sur le BIOS, je n'ai pas fais de recherches plus profondes pour l'instant.

Pour la webcam, si je me souviens bien, j'avais un driver à compiler et lors de mon premier test, l'image était bonne.

La majorité de ces problèmes sont probablement liés au kernel de la mandriva 2008 qui se fait vieux.. La future Spring sera probablement meilleure.

Pour le reste,
Graveur dvd, telecommande IR, touches Play,pauses,vol+.. du clavier, lecteur de SD, scrollbars sur le touchpad, lecteur biométrique.., ça marche sans problèmes.

Pour la vidéo, pas de soucis avec la nVidia GeForce 8600M GT, mais je suis 'tainté'.

Pas testé HDMI et firewire.

Voilà

Une section dédiée aux dépèches à caractère idéologique, politique, lobbyiste etc..
En gardant la possibilitée de publier certaines en une.
Ça ne ferait pas de mal, si ?

As-tu essayé Pound ?
C'est un reverse-proxy leger, simple et efficace:
http://www.apsis.ch/pound

Dans le cas de pound, l'adresse ip réélle est transmise via le header
X-Forwarded-For.
Pour les logs d'apache il faut utiliser une réference tel que
%{X-Forwarded-For}i
(je ne me souviens plus précisement...)

Il est possible de rendre plus "lisible" un document xml en utilisant un peu plus les attributs. Pour les hachages, j'utilise souvent cette forme:

<parameters
   charset=""
   file=""
   titi=""
   toto=""
   tata.name=""
/>

Ceci dit, il y a un problème si l'on souhaite commenter les attributs. Et probablement d'autres quand on écrit la DTD.

<servlet
  name="nom_servlet"
  class="servlet_class"
  description="..."
/>
<servlet-mappings>
  <mapping url-pattern="/a/*" servlet-name="nom_servlet"/>
  <mapping url-pattern="/b/*" servlet-name="nom_servlet"/>
</servlet-mappings>

Est-ce que le montage a l'option 'sync' dans un des deux cas ?

C'est peut-être une explication...

Je ne cherchais pas à dire que c'est mieux que awk ou autre,
mais simplement de montrer que l'on peut se passer des pipes en bash et le gain en performances en est conséquent.
Sur de gros fichiers, il est évident que de faire des | grep , | awk ça rox.
Mais sur de petits fichiers et une machine lente, le pipe c'est lent (car fork si je ne me trompe pas).
Et si le processing fait appelle à d'autres outils du script bash pour inserer des trucs dynamiquement , définir des variables pour bash en fonction de certaines lignes, remplir un tableau (si si ça existe en bash) etc ..
Une pile de grep/awk n'est pas forcement plus efficace.

Et puis, le plus pénible avec ces tubes étant la difficulté à obtenir le code de retour de la première commande ce qui rend encors plus complexe la détection d'erreurs dans le script qui sont trop souvent négligées sous pretexte que ça n'arrive jamais.

>imagine que dans ton traitement tu fais appel a des grep, cut ou sed, sur un fichier de plusieurs milliers de lignes c'est l'horreur.

Si je montre comment éviter les grep, cut & autre, ce n'est pas pour en mettre dans le 'processing' de chaques lignes. Suis pas gros débile non plus, hein :-)
Utiliser un script shell pour traiter plusieurs milliers de lignes, c'est pas une super bonne idée non-plus.

Pour grep, il est souvent possible de s'en passer quand il sagit seulement
de savoir si (une ligne, un mot, un process) est présent:

a=`<fichier.txt`
[ "${a//michu/}" != "${a}" ] && echo "MATCH" || echo "MATCH PAS"

C'est nettement plus rapide que:

cat fichier.txt | grep michu
[ "$?" == "0" ] && echo "MATCH" || echo "MATCH PAS"

Mais c'est dangereux si le fichier est gros.

Pour traiter un fichier ligne par ligne:

exec 3<fichier.txt
while read -u 3 line ; do
echo "${line}"
# Traitement
done
exec 3>&-

C'est plus rapide que:

function processLines() {
local line
while read line ; do
echo "${line}"
done
}
cat fichier.txt | processLines

Il y a pas mal de bidouilles pour gagner en perfs, par exemple avec
les trucs décrits dans la section 'Parameter Expansion' on peut couvrir
pas mal de cas en ce qui concerne le traitement de chaines de caractères.

Moi j'aime bien celle ci:
curl checkip.dyndns.org
(souvent utilisée par les clients dyndns)

Euh, de quel serveur parles-tu ?

Pour la connection unique, il y a netcat:
nc -l -p 8080

Bah j'ai eu le même problème, mais maintenant une version CD de la 2007.1 existe, en revanche il faut savoir jongler avec les CD's pendant l'installation:

CD1 -> CD2 -> CD1 -> CD2 ->CD1 ->CD2 ->CD3 -> CD2 >CD3 -> CD2 -> CD3 -> CD6 ->CD4
Et c'est sans exagèrer !

Tout ça parce que je n'ai choisi que ça pendant l'installation d'un serveur:

Network Computer
Configuration
Console Tools
Development
Firewall/Router
Network Computer Server

Ceci dit, l'essentiel c'est de pouvoir enfin l'installer .

Il serait aussi pas mal de rajouter une règle de logging à la fin de chaque chaines avant le DROP par défaut afin de pouvoir regarder ce qu'il se passe pendant
que tu essais de te connecter.

Un truc de ce style:

FW=/sbin/iptables
LOGLIMIT="2/s"
LOGLIMITBURST="10"

$FW -N log_drop
$FW -A log_drop -m limit --limit $LOGLIMIT --limit-burst $LOGLIMITBURST \
-j LOG --log-prefix 'FW-DROP: '
$FW -A log_drop -j DROP

$FW -A INPUT -j log_drop
$FW -A OUTPUT -j log_drop
$FW -A FORWARD -j log_drop

C'est beau maintenant! Merci :-)