Pour les emails j'utilise MailScanner qui s'interface avec plein d'antivirus....
dont mcafee viruscan (version linux) avec updates en ftp sur leur site (dans un cron ...) et qui doit pouvoir scanner tes partitions samba.
Pour un utilisateur qui ne veut pas developper son propre script je conseillerai plutot d'utiliser fwbuilder ou shorewall qui ne sont pas mal du tout.
L'interet de ta doc c'est de montrer la souplesse interne du mecanisme iptables et de susciter l'envie de se lancer dans son exploitation.
Shorewall a deja une grosse base d'utilisateurs, des fichiers de config pas si compliqués ...
De mon point de vue, ta doc doit etre parsemée d'exemples pour illustrer les possibilités de iptables et le meilleur moyen c'est d'accompagner le lecteur dans la redaction d'un script D'EXEMPLE.
Je ne pense pas du tout qu'il faille arriver a un script utilisable tel quel dans la majorité des situations et qui repose sur un /etc/netfilter.conf cachant les lignes iptables et donc ... le but initial d'exemple.
Effectivement, c'est ce que je viens de voir avec les liens que tu as envoyé. Le patch "tcp-nopickup" résout réellement ce problème ?
je suppose oui mais je ne les ai pas essayé... et dans la doc ils previennent qu ele résultat est déroutant (coupure des connections a chaque relance du script netfilter -- ce qui est logique)
D'ailleur dans le cadre d'un doc visant les débutants je te déconseilles de commencer par leur demander de patcher le noyau :-))
Pour corriger ce probleme, il suffit de ne pas utiliser --state NEW puisqu'il ne fait pas ce que l'on veut/pense. De plus je trouve criticable ta facon d'utiliser --state NEW sans le dire. Le jour ou les developeurs de netfilter ajoutent un etat de plus dans la liste des etats connus pour une connection, tu va la matcher par defaut egalement ... il vaudrait mieux explicitement choisir les etats qui t'interessent.
Honnetement je ne voit pas l'interet d'un etat --state NEW :
si tu as des règles dans cet ordre:
1/ rejet des etat non voulus (invalid)
2/ accept des etats souhaitables (connected)
3/ accept un a un des protocoles connus et voulus quel que soit l'etat
normalement le filtrage est ok et sans utiliser --state NEW. [jusqu'a preuve du contraire]. le --state NEW de netfilter est mal-nommé amha, il devrait s'appeler --state OPTIMISTICALNEW ou quelque chose du genre :-))
dans le <3> si on est un peu plus parano on peut preciser les flags souhaitables (SYN ...). Mais pour ma par, je pense que le role du firewall netfilter c'est de laisser passer ces paquets. Si mon serveur web tourne sur le port 80, je peux accepter any:any -> serveur:80. C'est a apache et son OS hote d'etre resistant (pile tcp et serveur applicatif).
Certes mais c'est un choix stratégique que tu fais la:
"j'ouvre tous les protocoles sortants".
Comme tout choix, c'est certainement le résultat d'une réflexion poussée qui doit alors apparaitre dans ton document pour permettre aux lecteurs de faire le meme raisonnement (validation) ou de le contredire (et a ce moment la il faudra leur donner les moyens d'implementer d'autres politiques de filtrage).
Avec le filtrage décrit ci dessus:
- Quid des spyware qui tournent sur tes postes clients ?
ils etablissent des connections sortantes et ont donc tout loisir d'exporter toutes les informations qu'ils souhaitent.
- Quid des serveur FTP malicieux qui peuvent negocier des ouvertures de ports ENTRANT (grace au tracking de connection destinée au départ pour le ftp-data)
Si ils sont consultés ils peuvent établir des connections entrantes sur les ports TCP qu'ils veulent (negocier avec le client FTP donc on doit faire confiance au client pour etre restrictif ? je me demande si netfilter sait prendre cela en considération ... a voir).
N'importe quel nimbda tournant chez toi peut infecter l'exterieur (connection sortante port 80)
N'importe quel trojan va pourvoir passer, se connecter (connection sortante) sur un canal IRC et y attendre des ordres ... qu'il va executer depuis l'intérieur. Un remote shell en quelques sortes.
Pour moi, hors de question, les protocoles qui sont autorisés en sortie sont sur ma liste de choses impossibles a supprimer et passent par un proxy applicatif le plus possible, par un proxy "bete" (comme un socks) sinon de facon a delocaliser les flux et a valider qu'ils sont connus/maitrisés autant que faire se peu.
C'est pour cela que certaines personnes ont besoin de la relation Appli/Port ,
evidement si tu ouvres en grand, pas besoin de connaitre le détail.
Une connection c'est IPsource+Portsource->IP dest+PortDest.
donc sur les connections deja etablies (--state ESTABLISHED) y a plus grand chose a dire sinon faire du filtrage applicatif !!
>>ton CPU sera content :-)
>Ca va, ils sont loin d'être au taquet. Surtout avec une connexion RTC :=)
bon ben ton temps de ping a UT alors :-)
non j'admet completement l'argument martelage et regles independantes meme si cela finit par faire des scripts un peu "lourds".
Pas si, comme je le dis, "l'attaque" vient du FAI lui-même
humm ok.
argument accepté mais tout de meme tordu amha :-))
les règles de firewall, surtout sur l'interface externe doivent commencer par de l'antispoofing. Et l'antispoofing tu peux l'ecrire de 2 facons: soit tu rejette tout ce qui ne t'es pas destiné (ne fontionne que pour les acces particuliers avec une seule adresse IP a-tout-faire). Soit tu rejette tous les reseaux RFC1918, y compris et surtout ceux que tu utilises en interne (et ca c'est une invariante, donc independant de l'IP de ta machine, qui fontionne meme en entreprise).
Donc je ne sais pas comment Netfilter a fait, mais il a restauré le suivi de connexion...
c'est ce que je critique avec le --state NEW. il essaye de deviner les paquets qui devraient faire partie d'une connection en cours. c'est a dire que ce n'est pas un match de SYN/SYN+ACK mais que des paquets *au milieu* d'un connection peuvent aussi servir a ajouter la connection au tracking. Pour moi c'est litigieux comme comportement et je n'utilises pas le --state NEW.
Le risque est très faible, du fait de l'ordre des règles "ipatbles -X", "-F" et "-P"
A noter que si tu te débarasse de la dépendance entre tes règles et ton IP, le script netfilter est a lancer une seule fois au demarrage de la machine et AVANT de configurer les interfaces eth et ppp... cette fois plus de doutes TOUS les paquets seront filtrés.
Il n'est pas besoin d'utiliser --state NEW pour reperer les paquets de "demande de connexion" et faire du tracking.
imagines ces règles:
1/ --state ESTABLISHED,RELATED --> ACCEPT
2/ connection au serveurs web (dst=tcp/80) --> ACCEPT.
la 2 va matcher pour les paquets non traités par la 1 (les nouvelles connexions) et la 1 va matcher pour les connexions existantes.
le probleme du --state NEW c'est qu'il est volontairement laxiste pour permettre de garder la trace de connections malgré un reboot de la machine (c'est a dire qu'il considère comme NEW des paquets qui semblent legitimes mais ne le sont pas forcement).
Pour faire du statefull, l'interessant c'est le --state ESTABLISHED.
RELATED pour certains protocoles (FTP) et on pourrait le limiter a ceux la aussi.
Tu as tout a fait raison, il y avait d'ailleur des packetages kernel-uml distribués avec les RedHat 7.x
Très simples a installer/utiliser c'est comme ca que j'avais commencé a jouer avec uml !!
je ne sais pas pourquoi ils n'existent plus en redhat 8/9 ??
Très bien faite cette doc, je viens de la parcourir ...
Quelques commentaires:
- Il faudrait que les spécialistes du coupage de cheveux ortho-grammatico-français en fassent une relecture (supprimer les 'malgré que' et autres fautes).
- la partie sur les chaines utilisateur est a mon gout trop rapide.
LE gros avantage de netfilter sur les autres firewalls c'est justement ces chaines qui permettent d'optimiser le temps de parcours de l'arbre de décision. Or dans ce document les chaines utilisateur ne sont utilisées que pour éviter de répéter l'option de LOG par exemple (chaine DropLog). Exemple: Creer des chaines utilisateur par type de routage (exterieur vers dmz, intranet vers exterieur ...) permet d'optimiser le nombre de règles lues pour prendre une décision.
Les chaines utilisateur peuvent aussi servir de compteur de paquets/octets pour faire des statistiques (et de beau graphes avec rrdtool).
- La partie sur le filtrage avec l'adresse IP externe de la machine me semble aussi moyenne (mais c'est sujet a discussion).
Pour optimiser un peu, tu pourrais commencer le script par un test sur l'IP UNE FOIS POUR TOUTE et eviter ainsi de re-tester l'adresse IP dans chaque chaine, ton CPU sera content :-) . Sinon je ne comprends pas bien la remarque: si tu recois le paquet en PPP c'est qu'il a été ROUTE vers toi. Donc l'adresse destination est la tienne ou un broadcast. Comme tu commences tes chaines par jeter tous les broadcast (hein ?) l'adresse est FORCEMENT la tienne. si pas de PPP (cable ...), tu peux valider selon l'adresse MAC de ta carte. Ces 2 techniques permettent de supprimer la dependance du script avec l'adresse ip externe (variable), donc de supprimer la commande "barbare" de lancement. Et surtout de supprimer la necessité de relancer a chaque coupure ADSL (donc re-initialisation des compteurs et surtout perte du tracking de connection, voire passage possible de paquets entre le stop/start de ton script netfilter).
- tu ne mentionnes pas les caractéristiques TROMPEUSES de l'etat NEW. Personnellement je prefere ne pas utiliser du tout le "--state NEW" que je trouve étonament laxiste (je ne suis pas le seul.... google est ton amis)
si j'ai le temps je ferai une relecture exhaustive de ton doc qui est tout de meme très complet, et proposerai des ajouts/modifications ...
Mais avant tout, cela t'interesse-t-il ?
Tu n'as pas été voir le lien que je te donne, MailScanner detache les pièces jointes pour les passer a l'antivirus. il y a donc dans MailScanner (en perl) toute la logique dont tu as beosin pour ton projet.
non.
la première c'est la SLS avec laquelle j'ai commencé linux (et qui a disparu depuis).
dailleur si tu lis le message de 93 posté avec la news, le createur de la slackware annonce que sa distribution est basee sur la SLS et que ses packages "A" (une serie de disquettes) sont en fait la compilation des packages "A"+"B"+"C" de la SLS originale.
Exactement.
Avec NFS ton filesysteme (ext3 par exemple) est monté par un serveur qui va l'exporter a plusieurs clients (en NFS).
Si tu veux fiabiliser cela et le rendre scalable (montée en charge), tu va etre tenté de multiplier les serveurs NFS en parallele.
Probleme: un filesysteme ext3 ne peut pas etre monté en parallele par plusieurs machines sinon il y a risque de corruption de données (en fait il y a corruption de données garantie :-)).
D'ou GFS qui est un filesysteme qui résoud exactement ce probleme: plusieurs machines peuvent le monté en parallele, voir meme le ré-exporter en NFS si tu veux le rendre dispo a travers ton réseau.
==> redondance, montée en charge ... ou simple partage de data de clusters.
heu .. si t'as le source ca vaudrait peut-etre le coup de debugguer la lib parce que faire un segmentation fault a cause de datas ... c'est pas clean !
ext3fs permet de journaliser les data AUSSI mais comme c'est plus lent c'est pas activé par défaut.
par defaut ext2fs est monté en data=ordered (pas journalisé)
mais tu peut specifier data=journal ...
man mount
(ceci dit, une base de donnée c'est peut-etre pas mal ...)
C'est d'autant plus nul qu'avec une solution de redondance (2 serveurs en cluster) tu peux tout reinstaller le node inactif pendant que l'autre bosse ...
a l'époque non plus ce n'étais pas très utile puisque si je me souviens bien on était obligé de se logguer sur quelques machines dédiées (dont la machine gateway/serveur web/email j'ai nommé eerie.eerie.fr) pour pouvoir sortir :-))
par défaut on avait pas d'accès exterieur autre que le mail, il fallait signer une convention de "bonne tenue" ressamblant a la nettiquette pour obtenir le login saluteur sur la bonne machine.
j'ai voté 1990 mais en recalculant ca date d'avant :-))
c'etais a l'EERIE pendant ma prépa à Nimes.
l'EERIE avait obtenu le dernier range d'IP classe A distribué en France et possédait déjà une ligne 2Mbps directement sur renater.
A l'époque seul mosaic existait et nous permettait de faire des recherches de fichiers. les news, les canaux irc ...
et des téléchargements plus rapide que pour écrire sur les disquettes , il faut dire que les sparc ne sont pas rapides pour ecrire sur disquette (cela les plantait meme parfois ...)
Pour l'utiliser on avait des stations sun (sparc) puis des hp toutes neuves. les vielles hp (appolo) on les boudait un peu pour ce genre d'utilisation.
Internet c'etais le fief des informaticiens, et de quelques autres scientifiques (maths / biologie). pas de commerce, pas de truc consommateurs de bande passante (radios/films/flash ...) pas de spam, pas de virus email ...
on avait accès a volonté aux salles info (badge magnetique pour y aller meme la nuit) et en 92 avec la révélation linux, j'ai passé quelques nuits a copier des disquettes de la distribution SLS rentrer chez moi l'installer, me rendre compte que la disquette 23 est illisible, retourner a l'ecole ...
# Re: Des Antivirus dans ma Debian ?
Posté par PLuG . En réponse au journal Des Antivirus dans ma Debian ?. Évalué à 1.
dont mcafee viruscan (version linux) avec updates en ftp sur leur site (dans un cron ...) et qui doit pouvoir scanner tes partitions samba.
[^] # Re: Documentation: Firewall [...] que du bonheur ;o)
Posté par PLuG . En réponse à la dépêche Documentation: Firewall et sécurité d'un réseau personnel sous Linux. Évalué à 1.
Pour un utilisateur qui ne veut pas developper son propre script je conseillerai plutot d'utiliser fwbuilder ou shorewall qui ne sont pas mal du tout.
L'interet de ta doc c'est de montrer la souplesse interne du mecanisme iptables et de susciter l'envie de se lancer dans son exploitation.
Shorewall a deja une grosse base d'utilisateurs, des fichiers de config pas si compliqués ...
De mon point de vue, ta doc doit etre parsemée d'exemples pour illustrer les possibilités de iptables et le meilleur moyen c'est d'accompagner le lecteur dans la redaction d'un script D'EXEMPLE.
Je ne pense pas du tout qu'il faille arriver a un script utilisable tel quel dans la majorité des situations et qui repose sur un /etc/netfilter.conf cachant les lignes iptables et donc ... le but initial d'exemple.
[^] # Re: Documentation: Firewall et sécurité d'un réseau personnel sous Linux
Posté par PLuG . En réponse à la dépêche Documentation: Firewall et sécurité d'un réseau personnel sous Linux. Évalué à 1.
ca fait des annees que mes firewalls iptables n'utilisent pas le --state NEW.
[^] # Re: Documentation: Firewall et sécurité d'un réseau personnel sous Linux
Posté par PLuG . En réponse à la dépêche Documentation: Firewall et sécurité d'un réseau personnel sous Linux. Évalué à 2.
je suppose oui mais je ne les ai pas essayé... et dans la doc ils previennent qu ele résultat est déroutant (coupure des connections a chaque relance du script netfilter -- ce qui est logique)
D'ailleur dans le cadre d'un doc visant les débutants je te déconseilles de commencer par leur demander de patcher le noyau :-))
Pour corriger ce probleme, il suffit de ne pas utiliser --state NEW puisqu'il ne fait pas ce que l'on veut/pense. De plus je trouve criticable ta facon d'utiliser --state NEW sans le dire. Le jour ou les developeurs de netfilter ajoutent un etat de plus dans la liste des etats connus pour une connection, tu va la matcher par defaut egalement ... il vaudrait mieux explicitement choisir les etats qui t'interessent.
Honnetement je ne voit pas l'interet d'un etat --state NEW :
si tu as des règles dans cet ordre:
1/ rejet des etat non voulus (invalid)
2/ accept des etats souhaitables (connected)
3/ accept un a un des protocoles connus et voulus quel que soit l'etat
normalement le filtrage est ok et sans utiliser --state NEW. [jusqu'a preuve du contraire]. le --state NEW de netfilter est mal-nommé amha, il devrait s'appeler --state OPTIMISTICALNEW ou quelque chose du genre :-))
dans le <3> si on est un peu plus parano on peut preciser les flags souhaitables (SYN ...). Mais pour ma par, je pense que le role du firewall netfilter c'est de laisser passer ces paquets. Si mon serveur web tourne sur le port 80, je peux accepter any:any -> serveur:80. C'est a apache et son OS hote d'etre resistant (pile tcp et serveur applicatif).
[^] # Re: Documentation: Firewall et sécurité d'un réseau personnel sous Linux
Posté par PLuG . En réponse à la dépêche Documentation: Firewall et sécurité d'un réseau personnel sous Linux. Évalué à 1.
"j'ouvre tous les protocoles sortants".
Comme tout choix, c'est certainement le résultat d'une réflexion poussée qui doit alors apparaitre dans ton document pour permettre aux lecteurs de faire le meme raisonnement (validation) ou de le contredire (et a ce moment la il faudra leur donner les moyens d'implementer d'autres politiques de filtrage).
Avec le filtrage décrit ci dessus:
- Quid des spyware qui tournent sur tes postes clients ?
ils etablissent des connections sortantes et ont donc tout loisir d'exporter toutes les informations qu'ils souhaitent.
- Quid des serveur FTP malicieux qui peuvent negocier des ouvertures de ports ENTRANT (grace au tracking de connection destinée au départ pour le ftp-data)
Si ils sont consultés ils peuvent établir des connections entrantes sur les ports TCP qu'ils veulent (negocier avec le client FTP donc on doit faire confiance au client pour etre restrictif ? je me demande si netfilter sait prendre cela en considération ... a voir).
N'importe quel nimbda tournant chez toi peut infecter l'exterieur (connection sortante port 80)
N'importe quel trojan va pourvoir passer, se connecter (connection sortante) sur un canal IRC et y attendre des ordres ... qu'il va executer depuis l'intérieur. Un remote shell en quelques sortes.
Pour moi, hors de question, les protocoles qui sont autorisés en sortie sont sur ma liste de choses impossibles a supprimer et passent par un proxy applicatif le plus possible, par un proxy "bete" (comme un socks) sinon de facon a delocaliser les flux et a valider qu'ils sont connus/maitrisés autant que faire se peu.
C'est pour cela que certaines personnes ont besoin de la relation Appli/Port ,
evidement si tu ouvres en grand, pas besoin de connaitre le détail.
[^] # Re: Documentation: Firewall et sécurité d'un réseau personnel sous Linux
Posté par PLuG . En réponse à la dépêche Documentation: Firewall et sécurité d'un réseau personnel sous Linux. Évalué à 2.
http://msgs.securepoint.com/cgi-bin/get/netfilter-0304/138/1/1.html(...)
ou meme ca !! tres bien expliqué:
http://iptables-tutorial.frozentux.net/chunkyhtml/newnotsyn.html(...)
[^] # Re: Documentation: Firewall et sécurité d'un réseau personnel sous Linux
Posté par PLuG . En réponse à la dépêche Documentation: Firewall et sécurité d'un réseau personnel sous Linux. Évalué à 2.
donc sur les connections deja etablies (--state ESTABLISHED) y a plus grand chose a dire sinon faire du filtrage applicatif !!
[^] # Re: Documentation: Firewall et sécurité d'un réseau personnel sous Linux
Posté par PLuG . En réponse à la dépêche Documentation: Firewall et sécurité d'un réseau personnel sous Linux. Évalué à 3.
>Ca va, ils sont loin d'être au taquet. Surtout avec une connexion RTC :=)
bon ben ton temps de ping a UT alors :-)
non j'admet completement l'argument martelage et regles independantes meme si cela finit par faire des scripts un peu "lourds".
Pas si, comme je le dis, "l'attaque" vient du FAI lui-même
humm ok.
argument accepté mais tout de meme tordu amha :-))
les règles de firewall, surtout sur l'interface externe doivent commencer par de l'antispoofing. Et l'antispoofing tu peux l'ecrire de 2 facons: soit tu rejette tout ce qui ne t'es pas destiné (ne fontionne que pour les acces particuliers avec une seule adresse IP a-tout-faire). Soit tu rejette tous les reseaux RFC1918, y compris et surtout ceux que tu utilises en interne (et ca c'est une invariante, donc independant de l'IP de ta machine, qui fontionne meme en entreprise).
Donc je ne sais pas comment Netfilter a fait, mais il a restauré le suivi de connexion...
c'est ce que je critique avec le --state NEW. il essaye de deviner les paquets qui devraient faire partie d'une connection en cours. c'est a dire que ce n'est pas un match de SYN/SYN+ACK mais que des paquets *au milieu* d'un connection peuvent aussi servir a ajouter la connection au tracking. Pour moi c'est litigieux comme comportement et je n'utilises pas le --state NEW.
Le risque est très faible, du fait de l'ordre des règles "ipatbles -X", "-F" et "-P"
A noter que si tu te débarasse de la dépendance entre tes règles et ton IP, le script netfilter est a lancer une seule fois au demarrage de la machine et AVANT de configurer les interfaces eth et ppp... cette fois plus de doutes TOUS les paquets seront filtrés.
[^] # Re: Documentation: Firewall et sécurité d'un réseau personnel sous Linux
Posté par PLuG . En réponse à la dépêche Documentation: Firewall et sécurité d'un réseau personnel sous Linux. Évalué à 3.
imagines ces règles:
1/ --state ESTABLISHED,RELATED --> ACCEPT
2/ connection au serveurs web (dst=tcp/80) --> ACCEPT.
la 2 va matcher pour les paquets non traités par la 1 (les nouvelles connexions) et la 1 va matcher pour les connexions existantes.
le probleme du --state NEW c'est qu'il est volontairement laxiste pour permettre de garder la trace de connections malgré un reboot de la machine (c'est a dire qu'il considère comme NEW des paquets qui semblent legitimes mais ne le sont pas forcement).
Pour faire du statefull, l'interessant c'est le --state ESTABLISHED.
RELATED pour certains protocoles (FTP) et on pourrait le limiter a ceux la aussi.
[^] # Re: Documentation: Firewall et sécurité d'un réseau personnel sous Linux
Posté par PLuG . En réponse à la dépêche Documentation: Firewall et sécurité d'un réseau personnel sous Linux. Évalué à 2.
Très simples a installer/utiliser c'est comme ca que j'avais commencé a jouer avec uml !!
je ne sais pas pourquoi ils n'existent plus en redhat 8/9 ??
# Re: Documentation: Firewall et sécurité d'un réseau personnel sous Linux
Posté par PLuG . En réponse à la dépêche Documentation: Firewall et sécurité d'un réseau personnel sous Linux. Évalué à 8.
Quelques commentaires:
- Il faudrait que les spécialistes du coupage de cheveux ortho-grammatico-français en fassent une relecture (supprimer les 'malgré que' et autres fautes).
- la partie sur les chaines utilisateur est a mon gout trop rapide.
LE gros avantage de netfilter sur les autres firewalls c'est justement ces chaines qui permettent d'optimiser le temps de parcours de l'arbre de décision. Or dans ce document les chaines utilisateur ne sont utilisées que pour éviter de répéter l'option de LOG par exemple (chaine DropLog). Exemple: Creer des chaines utilisateur par type de routage (exterieur vers dmz, intranet vers exterieur ...) permet d'optimiser le nombre de règles lues pour prendre une décision.
Les chaines utilisateur peuvent aussi servir de compteur de paquets/octets pour faire des statistiques (et de beau graphes avec rrdtool).
- La partie sur le filtrage avec l'adresse IP externe de la machine me semble aussi moyenne (mais c'est sujet a discussion).
Pour optimiser un peu, tu pourrais commencer le script par un test sur l'IP UNE FOIS POUR TOUTE et eviter ainsi de re-tester l'adresse IP dans chaque chaine, ton CPU sera content :-) . Sinon je ne comprends pas bien la remarque: si tu recois le paquet en PPP c'est qu'il a été ROUTE vers toi. Donc l'adresse destination est la tienne ou un broadcast. Comme tu commences tes chaines par jeter tous les broadcast (hein ?) l'adresse est FORCEMENT la tienne. si pas de PPP (cable ...), tu peux valider selon l'adresse MAC de ta carte. Ces 2 techniques permettent de supprimer la dependance du script avec l'adresse ip externe (variable), donc de supprimer la commande "barbare" de lancement. Et surtout de supprimer la necessité de relancer a chaque coupure ADSL (donc re-initialisation des compteurs et surtout perte du tracking de connection, voire passage possible de paquets entre le stop/start de ton script netfilter).
- tu ne mentionnes pas les caractéristiques TROMPEUSES de l'etat NEW. Personnellement je prefere ne pas utiliser du tout le "--state NEW" que je trouve étonament laxiste (je ne suis pas le seul.... google est ton amis)
si j'ai le temps je ferai une relecture exhaustive de ton doc qui est tout de meme très complet, et proposerai des ajouts/modifications ...
Mais avant tout, cela t'interesse-t-il ?
[^] # Re: Bijour, bijour
Posté par PLuG . En réponse au journal Bijour, bijour. Évalué à 1.
# Re: Comment enregistrer une émission en flux real rm
Posté par PLuG . En réponse au journal Comment enregistrer une émission en flux real rm. Évalué à 3.
reglez realplay pour qu'il utilise le daemon esd comme sortie son
enregistrez avec esdmon ...
c'est la meme chose sans compiler/installer rien de plus :-))
[^] # Re: Slackware a 10 ans !
Posté par PLuG . En réponse à la dépêche Slackware a 10 ans !. Évalué à 4.
non.
la première c'est la SLS avec laquelle j'ai commencé linux (et qui a disparu depuis).
dailleur si tu lis le message de 93 posté avec la news, le createur de la slackware annonce que sa distribution est basee sur la SLS et que ses packages "A" (une serie de disquettes) sont en fait la compilation des packages "A"+"B"+"C" de la SLS originale.
[^] # Re: Sistina announce Sistina GFS 5.2
Posté par PLuG . En réponse à la dépêche Sistina announce Sistina GFS 5.2. Évalué à 1.
Avec NFS ton filesysteme (ext3 par exemple) est monté par un serveur qui va l'exporter a plusieurs clients (en NFS).
Si tu veux fiabiliser cela et le rendre scalable (montée en charge), tu va etre tenté de multiplier les serveurs NFS en parallele.
Probleme: un filesysteme ext3 ne peut pas etre monté en parallele par plusieurs machines sinon il y a risque de corruption de données (en fait il y a corruption de données garantie :-)).
D'ou GFS qui est un filesysteme qui résoud exactement ce probleme: plusieurs machines peuvent le monté en parallele, voir meme le ré-exporter en NFS si tu veux le rendre dispo a travers ton réseau.
==> redondance, montée en charge ... ou simple partage de data de clusters.
# Re: Bijour, bijour
Posté par PLuG . En réponse au journal Bijour, bijour. Évalué à 1.
http://www.sng.ecs.soton.ac.uk/mailscanner/(...)
[^] # Re: Ecriture sur disque et résistance aux arrêts brutaux.
Posté par PLuG . En réponse au journal Ecriture sur disque et résistance aux arrêts brutaux.. Évalué à 1.
[^] # Re: Ecriture sur disque et résistance aux arrêts brutaux.
Posté par PLuG . En réponse au journal Ecriture sur disque et résistance aux arrêts brutaux.. Évalué à 0.
par defaut ext2fs est monté en data=ordered (pas journalisé)
mais tu peut specifier data=journal ...
man mount
(ceci dit, une base de donnée c'est peut-etre pas mal ...)
[^] # Re: Jean-Kevin est de retour !
Posté par PLuG . En réponse à la dépêche Jean-Kevin est de retour !. Évalué à 2.
[^] # Re: Question pour les vétérans
Posté par PLuG . En réponse au sondage Ma première utilisation d'internet, c'était.... Évalué à 1.
a l'époque non plus ce n'étais pas très utile puisque si je me souviens bien on était obligé de se logguer sur quelques machines dédiées (dont la machine gateway/serveur web/email j'ai nommé eerie.eerie.fr) pour pouvoir sortir :-))
par défaut on avait pas d'accès exterieur autre que le mail, il fallait signer une convention de "bonne tenue" ressamblant a la nettiquette pour obtenir le login saluteur sur la bonne machine.
[^] # Re: Question pour les vétérans
Posté par PLuG . En réponse au sondage Ma première utilisation d'internet, c'était.... Évalué à 1.
[^] # Re: Question pour les vétérans
Posté par PLuG . En réponse au sondage Ma première utilisation d'internet, c'était.... Évalué à 1.
C'est une classe B (et la dernière distribuée en France),
et c'est gopher évidement !!
[^] # Re: Question pour les vétérans
Posté par PLuG . En réponse au sondage Ma première utilisation d'internet, c'était.... Évalué à 2.
c'etais a l'EERIE pendant ma prépa à Nimes.
l'EERIE avait obtenu le dernier range d'IP classe A distribué en France et possédait déjà une ligne 2Mbps directement sur renater.
A l'époque seul mosaic existait et nous permettait de faire des recherches de fichiers. les news, les canaux irc ...
et des téléchargements plus rapide que pour écrire sur les disquettes , il faut dire que les sparc ne sont pas rapides pour ecrire sur disquette (cela les plantait meme parfois ...)
Pour l'utiliser on avait des stations sun (sparc) puis des hp toutes neuves. les vielles hp (appolo) on les boudait un peu pour ce genre d'utilisation.
Internet c'etais le fief des informaticiens, et de quelques autres scientifiques (maths / biologie). pas de commerce, pas de truc consommateurs de bande passante (radios/films/flash ...) pas de spam, pas de virus email ...
on avait accès a volonté aux salles info (badge magnetique pour y aller meme la nuit) et en 92 avec la révélation linux, j'ai passé quelques nuits a copier des disquettes de la distribution SLS rentrer chez moi l'installer, me rendre compte que la disquette 23 est illisible, retourner a l'ecole ...
le bon temps quoi :-)
[^] # Re: Commentaires disparus
Posté par PLuG . En réponse au journal Mise à jour de Templeet. Évalué à 1.
[^] # Re: Snif ...
Posté par PLuG . En réponse au journal Snif .... Évalué à 2.