Trojan dans Linux
P4nd1-P4nd4
--
P4nd1-P4nd4 vous salue, et annonce que le petit ourson possï¿œde
dï¿œsormais son blog
p4nd1-p4nd4.over-blog.com
Dellara
04:35 PM:
> Qui disais que cela n'existe pas ...
>
> http://www.zdnet.com.au/blogs/null-pointer/soa/Carelessness-busts-
Linux-
security/0,2001102868,339299939,00.htm?omnRef=http://www.linuxtoday.com/infrastructure/2009120901935SCGN
>
Un utilisateur assez crï¿œtin pour installer un ï¿œconomiseur d'ï¿œcran en
root mï¿œrite ce qui lui arrive. En plus, pour exï¿œcuter rm -rf *.* il faut
ï¿œtre root. Alors ï¿œa ne peut arriver qu'aux imbï¿œciles qui tournent en
root tout le temps. Il ne mï¿œritent pas mieux. Un script du genre ne peut
s'exï¿œcuter en mode utilisateur. Alors comme d'habitude tu n'as rien
compris et l'auteur de l'article non plus je pense...
Michel Doucet
son clavier pour nous dire dans le message suivant:
> Qui disais que cela n'existe pas ...
>
> http://www.zdnet.com.au/blogs/null-pointer/soa/Carelessness-busts-Linux-
security/0,2001102868,339299939,00.htm?omnRef=http://www.linuxtoday.com/
infrastructure/2009120901935SCGN
Vous ne comprenez pas l'anglais, vous l'avez dￜjￜ dit !
"Thankfully, the delete command above will be mostly ineffectual in Linux systems."
--
Utiliser le butineur, le courriï¿œleur, le lecteur de nouvelles
et le SE avec lesquels vous vous sentez le plus sￜcurisￜ ... ;)
Posted via www.individual.net
http://mdoucet.wordpress.com/
Stephane TOUGARD
> Un utilisateur assez crétin pour installer un économiseur d'écran en
> root mérite ce qui lui arrive. En plus, pour exécuter rm -rf *.* il faut
> être root. Alors ça ne peut arriver qu'aux imbéciles qui tournent en
> root tout le temps. Il ne méritent pas mieux. Un script du genre ne peut
> s'exécuter en mode utilisateur. Alors comme d'habitude tu n'as rien
Mouais, enfin
rm -rf ~
C'est pas mieux.
Stephan Peccini
> rm -rf ~
>
> C'est pas mieux.
Cela ne me dérangerait pas trop. Même en faisant ça, je récupère tout en
quelques instants, même les dernières modifications faites. Et en 5
commandes : su, lscp, chcp, mount, cp et hop tout est remis.
--
Stéphan Peccini
Les photos : <URL:http://photonature.fr>
Les Pyrénées : <URL:http://photonature.fr/pyrenees>
Le blog : <URL:http://pyrenees.peccini.fr>
Amandine Parmesan
<ste...@photonature.fr> wrote:
>Le 10/12/2009 01:16, Stephane TOUGARD a �crit :
>
>> rm -rf ~
>>
>> C'est pas mieux.
>
>Cela ne me d�rangerait pas trop. M�me en faisant �a, je r�cup�re tout en
>quelques instants, m�me les derni�res modifications faites. Et en 5
>commandes : su, lscp, chcp, mount, cp et hop tout est remis.
Ca m'interesse. Tu peux developper un peu s'il te plait concernant
lscp et chcp.
Merci
--
France-Irlande
J'ai pas honte d'�tre francaise, mais j'aimerai �tre fier en laissant notre place � l'Irlande.
C'est une question d'honneur
Mais je ne me fais aucune illusion. J'esp�re que l'equipe qui a vol� le match soit humili� et rentre la t�te baiss�.
http://www.youtube.com/watch?v=ekxsmPnHWSA
debug this fifo
> Qui disais que cela n'existe pas ...
comme quoi bubuntu, a force de vouloir singer windows, a reussi a
devenir michu-compliant...
Amandine Parmesan
Peut �tre que toi t'aime pas bubuntu, et alors ? L'utilise pas c'est
tout.
Ce genre de distribution � au moins l'avantage d'�tre pr�-install�.
C'est grace a cela que j'ai pu mettre le pied hors de windows.
Ce genre de distribution a au moins le merite d'exister pour le
novice. C'est pas plus compliqu� � utiliser que windows et c'est
fonctionnel.
A partir de l�, rien n'interdit d'installer sur un autre PC ou machine
virtuelle une slack ou debian pour mettre les mains dans le moteur.
C'est ce que je fais avec une lenny. J'apprend a l'utiliser.
Desol�, mais je suis moins intellignete que vous, moi je dois
apprendre. J'ai pas la chance d'avoir la science infuse.
NiKo
>
> Desol�, mais je suis moins intellignete que vous, moi je dois
> apprendre. J'ai pas la chance d'avoir la science infuse.
>
Te rabaisses pas ! Tu es bien plus intelligente que certains, qui n'ont
m�me pas test� Linux et qui ne cessent de le critiquer !
Stéphane CARPENTIER
> Qui disais que cela n'existe pas ...
Le lien que tu montre lￜ :
Bon, je t'explique ton lien.
D'abord, il y a ï¿œcrit ï¿œa :
ￜ Although the malicious content is now removed. ￜ
En gros, ￜa veut dire que le contenu vￜrolￜ a ￜtￜ supprimￜ. ￜa veut donc
dire que le trojan n'existe plus. Donc, oui, ton lien montre que ï¿œa
n'existe pas.
Ensuite, il y a ï¿œcrit ï¿œa :
ￜ Thankfully, the delete command above will be mostly ineffectual in
Linux systems. ￜ
En gros ï¿œa veut dire que la commande va ï¿œtre majoritairement inefficace
sur les systï¿œmes Linux.
Plus loin, il confirme en ï¿œcrivant ï¿œa :
ￜ but despite the simplicity and ineffectiveness of this trojan
Ce qui veut dire en gros, malgrￜ la simplicitￜ et l'inefficacitￜ de ce
trojan.
Donc, non seulement l'annonce de ton trojan est pï¿œrimï¿œe, mais en plus,
ton trojan n'ï¿œtait pas dangereux.
Stephan Peccini
> Ca m'interesse. Tu peux developper un peu s'il te plait concernant
> lscp et chcp.
Un peu en retard (� cause de 6 implants plac�s ce matin :-) ), je te
donne juste un lien :
http://www.nilfs.org/en/index.html
Bonne d�couverte et si tu as des questions, je peux essayer d'y r�pondre.
--
St�phan Peccini
Les photos : <URL:http://photonature.fr>
Les Pyr�n�es : <URL:http://photonature.fr/pyrenees>
leeed
> Amandine Parmesan a écrit :
>>
>> Desolé, mais je suis moins intellignete que vous, moi je dois
>> apprendre. J'ai pas la chance d'avoir la science infuse.
>>
>
> Te rabaisses pas ! Tu es bien plus intelligente que certains, qui n'ont
Et puis vaut mieux une tête bien faite qu'une tête bien pleine ;)
Amandine Parmesan
<ste...@photonature.fr> wrote:
>Le 10/12/2009 08:47, Amandine Parmesan a �crit :
>
>> Ca m'interesse. Tu peux developper un peu s'il te plait concernant
>> lscp et chcp.
>
>Un peu en retard (� cause de 6 implants plac�s ce matin :-) ), je te
>donne juste un lien :
>http://www.nilfs.org/en/index.html
>
>Bonne d�couverte et si tu as des questions, je peux essayer d'y r�pondre.
Contrairement � Panda, je peux dire sans honte que je ne sais pas bien
lire l'anglais. (d�j� que le francais est pas au point)
Donc j'ai 2 ou 3 questions :
- Est ce que cela fonctionne avec tous les filesystem ? (de etx4 �
ntfs) ? Ou bien est ce un FS � lui tout seul ?
- O� sont stock� les info de recup�ration ? Sur la m�me partition ou
sur une autre ?
- Est ce bas� sur un daemon qui surveille les acces disques et
enregistre chaque moodif, ou bien est ce bas� sur un cron toutes les X
minutes ?
- Quelles sont les limites d'un tel systeme de recuperation?
Amandine Parmesan
>Le 10-12-2009, NiKo <Ni...@nomail.svp> a �crit�:
>> Amandine Parmesan a �crit :
>>>
>>> Desol�, mais je suis moins intellignete que vous, moi je dois
>>> apprendre. J'ai pas la chance d'avoir la science infuse.
>>>
>>
>> Te rabaisses pas ! Tu es bien plus intelligente que certains, qui n'ont
>> m�me pas test� Linux et qui ne cessent de le critiquer !
>
>Et puis vaut mieux une t�te bien faite qu'une t�te bien pleine ;)
:o((
Stephan Peccini
> - Est ce que cela fonctionne avec tous les filesystem ? (de etx4 �
> ntfs) ? Ou bien est ce un FS � lui tout seul ?
nilfs est un syst�me de fichiers � part enti�re qui est entr� il y a peu
dans le noyau.
> - O� sont stock� les info de recup�ration ? Sur la m�me partition ou
> sur une autre ?
Sur la m�me partition.
En fait tu peux monter la partition nilfs telle qu'elle �tait dans le
pass�, sachant que toute modification faite sur les fichiers est
enregistr�e automatiquement sous la forme d'un checkpoint :
[stephan@kulta ~]$ lscp|tail
135732 2009-12-10 20:37:37 cp - 5408 68599
135733 2009-12-10 20:37:38 cp - 48 68599
135734 2009-12-10 20:37:42 cp - 7442 68599
135735 2009-12-10 20:37:47 cp - 5485 68599
135736 2009-12-10 20:37:52 cp - 7534 68599
135737 2009-12-10 20:37:52 cp - 157 68600
135738 2009-12-10 20:37:57 cp - 7288 68599
135739 2009-12-10 20:38:02 cp i 7211 68599
135740 2009-12-10 20:38:07 cp - 4526 68599
135741 2009-12-10 20:38:12 cp - 8778 68600
[stephan@kulta ~]$
Si j'ai d�truit un fichier � 20 heures 38, il me suffit de monter le
checkpoint du syst�me de fichiers pr�c�dent la destruction pour le
r�cup�rer :
mount -t nilfs2 -r -o cp=135738 /dev/sdxxx /home/stephan_nilfs2
> - Est ce bas� sur un daemon qui surveille les acces disques et
> enregistre chaque moodif, ou bien est ce bas� sur un cron toutes les X
> minutes ?
C'est le driver lui-m�me qui fait le travail. Par contre il y a un d�mon
qui se charge de lib�rer les donn�es apr�s un certains temps � partir du
moment o� elles n'ont pas �t� demand�es � �tre conserv�es explicitement
par l'utilisateur (snapshot).
> - Quelles sont les limites d'un tel systeme de recuperation?
La taille du syst�me de fichiers uniquement. L� o� on peut avoir des
probl�mes, c'est quand on utilise de gros fichiers temporaires (ou
beaucoup de petits dans des d�lais courts). En effet, par principe m�me,
tant que le d�lai de conservation n'est pas pass� (pour faire rapide
dans mon explication), le syst�me de fichiers conserve la trace des
fichiers temporaires ; et si le syst�me �tait presque plein, on ne
pourra le reremplir qu'apr�s le d�lai.
Doug713705
passante pour nous ï¿œcrire :
>>comme quoi bubuntu, a force de vouloir singer windows, a reussi a
>>devenir michu-compliant...
>
> Peut ï¿œtre que toi t'aime pas bubuntu, et alors ? L'utilise pas c'est
> tout.
Les qualitï¿œs "pï¿œdagogiques" d'Ubuntu sont indï¿œniables et cette
distribution permet ￜ beaucoup d'utilisateurs de passer sous Linux.
Cependant, il est ￜgalement vrai qu'ￜ vouloir appￜter le Windowsien, elle
fini par prendre les dï¿œfauts de Windows.
Tant que la sￜcuritￜ du systￜme n'est pas mise en cause, on peut
considï¿œrer que "ï¿œa va encore".
Par contre dans le cas contraire, on est en droit de tirer ￜ boulets
rouges. Les adorateurs de Windows ne se gï¿œnent pas pour le faire et c'est
de bonne guerre.
Il en a ￜtￜ de mￜme quand une faille bￜante avait ￜtￜ trouvￜe dans le
paquet openSSL chez Debian.
C'est trï¿œs sain et c'est ce qui fait que chacun des developpeurs fait
particuliￜrement attention ￜ ce qu'il fait car sa crￜdibilitￜ et par
extension celle de la distribution est en jeu.
Chez MS, c'est diffￜrent. Tout le monde tire ￜ boulets rouges mais on se
contente de ne pas regarder les trous de sￜcuritￜ et on continue ￜ faire
du marketing au lieu de faire de l'informatique.
--
@+
Doug - Linux user #307925 - Slackware64 roulaize ;-)
[ Plus ou moins avec une chance de peut-ï¿œtre ]
Professeur Méphisto
> je ne sais pas bien
> lire l'anglais. (déjà que le francais est pas au point)
ça ne se voit pas !
Amandine Parmesan
<professeu...@wanadooooo.fr> wrote:
>Le Thu, 10 Dec 2009 20:21:51 +0100, Amandine Parmesan a �crit�:
>
>> je ne sais pas bien
>> lire l'anglais. (d�j� que le francais est pas au point)
>
>�a ne se voit pas !
Ben t'as pas vu mes autres post.
Alban Taraire
> Un peu en retard (ￜ cause de 6 implants placￜs ce matin :-) ), je tePas mal, je connaissais pas. Niveau perfs, ￜa donne quoi ?
--
Alban
Stephan Peccini
Les implants ? Je te dirai quand j'aurai la version dï¿œfinitive des dents
parce que lￜ je suis en beta en haut et en pre-alpha en bas :-)
Ah ... tu voulais parler de nilfs.
Alors ici :
http://www.linux-mag.com/id/7345/2/
et ici pour l'origine des graphiques :
http://www.usenix.org/event/lsf08/tech/shin_SSD.pdf
--
Stï¿œphan Peccini
Les photos : <URL:http://photonature.fr>
Les Pyrï¿œnï¿œes : <URL:http://photonature.fr/pyrenees>
Yliur
Stephan Peccini <ste...@photonature.fr> a écrit :
> Le 11/12/2009 04:39, Alban Taraire a écrit :
> > Stephan Peccini wrote:
> >
> >> Un peu en retard (à cause de 6 implants placés ce matin :-) ), je
> >> te donne juste un lien :
> >> http://www.nilfs.org/en/index.html
> >
> > Pas mal, je connaissais pas. Niveau perfs, ça donne quoi ?
>
> Les implants ? Je te dirai quand j'aurai la version définitive des
> dents parce que là je suis en beta en haut et en pre-alpha en bas :-)
>
> Ah ... tu voulais parler de nilfs.
>
> Alors ici :
>
> http://www.linux-mag.com/id/7345/2/
>
> et ici pour l'origine des graphiques :
>
> http://www.usenix.org/event/lsf08/tech/shin_SSD.pdf
>
Dans l'article ils semblent dire qu'en fait la fragmentation c'est pas
grave ? Et que donc tout ce qui a été fait pour produire des
systèmes de fichiers peu fragmentés ne sert à rien ? Ou c'est une
évolution récente, comme semble le suggérer une des phrases ("In
addition, it was presumed that most IO would become write dominated
(this observation is supported by a study that was summarized in a
recent article)") ?
J'imagine que ça dépend aussi de si on veut plutôt faire des lectures
ou des écritures et du taux d'efficacité du cache système. Et si je
ne dis pas de bêtises, les temps d'accès aux données en lecture ou
écriture des mémoires flash des disques SSD ne dépendent pas de la
position des données (sauf le gain apporté par les caches bien
sûr, comme en RAM) ?
Stephan Peccini
> Dans l'article ils semblent dire qu'en fait la fragmentation c'est pas
> grave ? Et que donc tout ce qui a �t� fait pour produire des
> syst�mes de fichiers peu fragment�s ne sert � rien ?
Cela fait partie de la ToDo list :
http://www.nilfs.org/en/current_status.html
> J'imagine que �a d�pend aussi de si on veut plut�t faire des lectures
> ou des �critures et du taux d'efficacit� du cache syst�me.
Je viens de faire la comparaison avec ext4 et xfs et autant pour mon
usage, nilfs est plus rapide que ext4 autant xfs peut �tre plus rapide
en �criture et un peu plus lent en lecture. Mais cela n'a rien de
scientifique et je pense que les r�sultats sont faux dans d'autres
contextes. Tout cela sur un SSD.
--
St�phan Peccini
Les photos : <URL:http://photonature.fr>
Les Pyr�n�es : <URL:http://photonature.fr/pyrenees>
Amandine Parmesan
<ste...@photonature.fr> wrote:
>Le 11/12/2009 07:10, Yliur a �crit :
>
>> Dans l'article ils semblent dire qu'en fait la fragmentation c'est pas
>> grave ? Et que donc tout ce qui a �t� fait pour produire des
>> syst�mes de fichiers peu fragment�s ne sert � rien ?
>
>Cela fait partie de la ToDo list :
>http://www.nilfs.org/en/current_status.html
>
>> J'imagine que �a d�pend aussi de si on veut plut�t faire des lectures
>> ou des �critures et du taux d'efficacit� du cache syst�me.
>
>Je viens de faire la comparaison avec ext4 et xfs et autant pour mon
>usage, nilfs est plus rapide que ext4 autant xfs peut �tre plus rapide
>en �criture et un peu plus lent en lecture. Mais cela n'a rien de
>scientifique et je pense que les r�sultats sont faux dans d'autres
>contextes. Tout cela sur un SSD.
Question, est il stable ce nilfs pour de la prod ?
Acteuelement je suis sur : Linux DC2200 2.6.28-16-generic #55-Ubuntu
SMP Tue Oct 20 19:48:32 UTC 2009 x86_64 GNU/Linux
Donc m�me pas en 2.6.30 mais il est dispo dans les depots.
JKB
Re: Trojan dans Linux,
Amandine Parmesan ?crivait dans fr.comp.os.linux.debats :
>>
>>> Dans l'article ils semblent dire qu'en fait la fragmentation c'est pas
>>> ou des écritures et du taux d'efficacité du cache système.
>>
>>en écriture et un peu plus lent en lecture. Mais cela n'a rien de
>>scientifique et je pense que les résultats sont faux dans d'autres
>
> Question, est il stable ce nilfs pour de la prod ?
>
> Acteuelement je suis sur : Linux DC2200 2.6.28-16-generic #55-Ubuntu
> SMP Tue Oct 20 19:48:32 UTC 2009 x86_64 GNU/Linux
>
En prod, je suis resté au 2.6.27.x car j'ai des tas de problèmes avec
les versions plus récentes (problèmes de montées en charge avec des
soft lockups à la chaîne voire des plantages secs). Seules deux machines
tournent chez moi en production avec des 2.6.30.9, mais patchés jusqu'à
la moëlle pour faire tourner correctement le iSCSI en 'target' et
'initiator' (et à cause d'une combre histoire de libpcap dont l'API
a subtilement changée). Les noyaux de la série 2.6.28 et 2.6.29 sont
à mon avis inutilisables en prod sur des serveurs critiques.
Cordialement,
JKB
--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.
Stephan Peccini
> Question, est il stable ce nilfs pour de la prod ?
Sachant qu'il y a des d�veloppements en cours, le projet ne s'engage pas
� ne rien changer dans les sp�cifications du syst�me de fichiers dans
l'avenir. Donc pour de la production, j'aurai tendance � dire non ; mais
apr�s il existe zfs qui lui est utilisable en prod mais que je trouve
moins int�ressant pour un usage personnel (nilfs fait tout, tout seul et
permet de remonter rapidement sur une b�tise). Donc c'est � �tudier au
cas par cas sachant que si on parle de prod, on parle d'�quipe
d'administration et donc de potentiel � passer outre le probl�me que je
vois personnellement entre zfs et nilfs.
NiKo
Pour avoir installￜ mon /home dessus, je peux te dire ce que j'en pense.
Malgrￜ que le principe soit ￜnormￜment intￜressant (Dans mon cas, le
/home est un raid 1, donc NILFS2 ajoute la sￜcuritￜ en cas "d'erreur
humaine").
J'avais 90 Go de donnￜes ￜ recopier. Le raid pointe son nez ￜ prￜs de 80
Mo/s. Il m'a fallu plus de 4 heures pour rapatrier mes donnï¿œes par rsync
(Entre disques SATA). Les perfs paraissent bonnes, au dï¿œpart (Cela doit
surement provenir de la mise en cache, j'ai 8 Go de ram) mais
s'effondrent par la suite.
Plus de 4 heures pour 90 Go, ï¿œa fait tomber les perfs en dessous de 8
Mo/s ... Une cata quoi !
De plus, ce FS maintient une charge permanente sur la machine, avec un
load average avoisinant les 0,40 en permanence sur un Amd x2 6000.
Impossibilitￜ de faire un montage automatique de ce fs au boot.
Pas trï¿œs important pour un poste 'perso' : [ESC]mount /home[CTRL][D]
Pour l'instant, ce FS n'est pas dￜclarￜ stable. Il le dit lors dur
montage, de ne pas y stocker de donnï¿œes critiques.
Bref, la thï¿œorie de ce FS est gï¿œniale, mais la pratique est toute autre.
JKB
Re: Trojan dans Linux,
> Alban Taraire a écrit :
>> Stephan Peccini wrote:
>>
>>> Un peu en retard (à cause de 6 implants placés ce matin :-) ), je te>> Pas mal, je connaissais pas. Niveau perfs, ça donne quoi ?
>>
>
> Pour avoir installé mon /home dessus, je peux te dire ce que j'en pense.
>
> Malgré que le principe soit énormément intéressant (Dans mon cas, le
> /home est un raid 1, donc NILFS2 ajoute la sécurité en cas "d'erreur
> humaine").
>
> J'avais 90 Go de données à recopier. Le raid pointe son nez à près de 80
> Mo/s. Il m'a fallu plus de 4 heures pour rapatrier mes données par rsync
> (Entre disques SATA). Les perfs paraissent bonnes, au départ (Cela doit
> surement provenir de la mise en cache, j'ai 8 Go de ram) mais
> s'effondrent par la suite.
>
> Mo/s ... Une cata quoi !
>
> De plus, ce FS maintient une charge permanente sur la machine, avec un
> load average avoisinant les 0,40 en permanence sur un Amd x2 6000.
>
> Pas très important pour un poste 'perso' : [ESC]mount /home[CTRL][D]
>
> Pour l'instant, ce FS n'est pas déclaré stable. Il le dit lors dur
> montage, de ne pas y stocker de données critiques.
>
> Bref, la théorie de ce FS est géniale, mais la pratique est toute autre.
Il y a quelque part un pilote ODS-2 pour Linux, un truc qui ajoute
un numéro de version à tous les fichiers créés. /me devrait aller
voir s'il est possible de rajouter une option de montage du type
/keep=n.
Stephan Peccini
> Plus de 4 heures pour 90 Go, ï¿œa fait tomber les perfs en dessous de 8
> Mo/s ... Une cata quoi !
[stephan@kulta ~]$ tar cf I.tgz Images/
[stephan@kulta ~]$ rm -fr Images/
[stephan@kulta ~]$ tar xf I.tgz
[stephan@kulta ~]$ time (tar cf I.tgz Images/ ; sync ; sync)
real 2m51.214s
user 0m0.487s
sys 0m24.527s
On a donc un temps global de 172 secondes pour 7400 Mo de donnï¿œes (43 Mo
en lecture et ï¿œcriture sur le mï¿œme systï¿œme de fichiers y compris le
vidage du cache) sur un SSD avec des pointes ￜ 170 Mo et rￜgulier entre
70 et 80 Mo (ï¿œcriture et lecture).
> De plus, ce FS maintient une charge permanente sur la machine, avec un
> load average avoisinant les 0,40 en permanence sur un Amd x2 6000.
C'est le garbage collector. Je suis ￜ 0,14 sur un Q6600 ￜ 1,6 GHz avec X
qui prend de la charge systￜmatique ￜ cause de mes affichages continus
de suivi du systï¿œme. Le garbage collector doit reprï¿œsenter environ 1/10
de ma charge ￜ idle ￜ (c'est ￜ dire quand je ne fais rien).
> Impossibilitￜ de faire un montage automatique de ce fs au boot.
> Pas trï¿œs important pour un poste 'perso' : [ESC]mount /home[CTRL][D]
[stephan@kulta Pyrï¿œnï¿œes]$ grep nilfs2 /etc/fstab
/dev/sdc1 /home/stephan nilfs2 rw 1 2
> Pour l'instant, ce FS n'est pas dￜclarￜ stable. Il le dit lors dur
> montage, de ne pas y stocker de donnï¿œes critiques.
C'est ce qui est dit, exact.
> Bref, la thï¿œorie de ce FS est gï¿œniale, mais la pratique est toute autre.
Je n'ai rien ￜ lui reprocher actuellement.
--
Stï¿œphan Peccini
Les photos : <URL:http://photonature.fr>
Les Pyrï¿œnï¿œes : <URL:http://photonature.fr/pyrenees>
Emmanuel Florac
> Pas mal, je connaissais pas. Niveau perfs, ça donne quoi ?
J'ai trouvé très bon. Un peu en dessous de XFS, mais meilleur qu'ext3. Je
parle d'accès séquentiel avec un système qui marche, genre 300 ou
400 Mo/s.
--
The question of whether computers can think is just like the question of
whether submarines can swim.
Edsger W. Dijkstra
Emmanuel Florac
> Seules deux machines
> tournent chez moi en production avec des 2.6.30.9, mais patchés
jusqu'à
> la moëlle pour faire tourner correctement le iSCSI en 'target' et
> 'initiator' (et à cause d'une combre histoire de libpcap dont
l'API a
> subtilement changée).
Pour info il y a un patch pour iet 1.4.19 qui permet de fonctionner
correctement sur 2.6.32. BOn pour l'instant je l'ai simplement compilé :)
Puis le 2.6.27 a l'avantage d'être "version stable", c'est cool.
--
The first 90% of the code accounts for the first 90% of the development
time. The remaining 10% of the code accounts for the other 90% of the
development time.
Tom Cargill
Emmanuel Florac
> Sachant qu'il y a des développements en cours, le projet ne s'engage pas
> à ne rien changer dans les spécifications du système de fichiers dans
> l'avenir. Donc pour de la production, j'aurai tendance à dire non ; mais
> après il existe zfs qui lui est utilisable en prod mais que je trouve
> moins intéressant pour un usage personnel
Oui mais ZFS, c'est pas sous linux... Pour nilfs je compte monter une
grosse machine de test ( 2 ou 30 To) et la remplir pour stresser le
bidule un max, juste pour voir.
--
Le livre, comme livre, appartient à l'auteur, mais comme pensée, il
appartient - le mot n'est pas trop vaste - au genre humain. Toutes les
intelligences y ont droit. Si l'un des deux droits, le droit de
l'écrivain et le droit de l'esprit humain, devait être sacrifié, ce
serait, certes, le droit de l'écrivain, car l'intérêt public est notre
préoccupation unique, et tous, je le déclare, doivent passer avant nous.
Victor Hugo.
Stephan Peccini
> J'ai trouvé très bon. Un peu en dessous de XFS, mais meilleur qu'ext3. Je
> parle d'accès séquentiel avec un système qui marche, genre 300 ou
> 400 Mo/s.
Cela confirme en partie ce que j'ai pu voir avec xfs et ext4. Pour
l'instant, je pense que vais y rester uniquement pour le snapshot sinon
ce sera xfs.
--
Stéphan Peccini
Les photos : <URL:http://photonature.fr>
Les Pyrénées : <URL:http://photonature.fr/pyrenees>
Emmanuel Florac
> Plus de 4 heures pour 90 Go, ça fait tomber les perfs en dessous de 8
> Mo/s ... Une cata quoi!
Le principe de nilfs implique qu'il n'aime pas les tas de petits
fichiers, à mon avis.
--
That ideas should freely spread from one to another over the globe,
for the moral and mutual instruction of man, and the improvement of his
conditions, seems to have been peculiarly and benevolently designed by
nature, when she made them, like fire, expansible over all space,
without lessening their density in any point, and like the air in which
we breathe, move, and have our physical being, incapable of confinement
of exclusive appropriation. Inventions then cannot, in nature, be a
subject of property.
Thomas Jefferson.
Stephan Peccini
> Oui mais ZFS, c'est pas sous linux... Pour nilfs je compte monter une
> grosse machine de test ( 2 ou 30 To) et la remplir pour stresser le
> bidule un max, juste pour voir.
Oui et non. Non car c'est une bêtise de ma part de le proposer en
production sous Linux (je me suis emmêlé les pinceaux) mais oui car on
peut avoir zfs sous Linux (enfin pas dans le noyau).
--
Stéphan Peccini
Les photos : <URL:http://photonature.fr>
Les Pyrénées : <URL:http://photonature.fr/pyrenees>
JKB
Re: Trojan dans Linux,
> Le Fri, 11 Dec 2009 10:01:06 +0000, JKB a écrit:
>
>> Seules deux machines
>> tournent chez moi en production avec des 2.6.30.9, mais patchés
> jusqu'à
>> la moëlle pour faire tourner correctement le iSCSI en 'target' et
>> 'initiator' (et à cause d'une combre histoire de libpcap dont
> l'API a
>> subtilement changée).
>
> Pour info il y a un patch pour iet 1.4.19 qui permet de fonctionner
> correctement sur 2.6.32. BOn pour l'instant je l'ai simplement compilé :)
Le problème est surtout que le 2.6.32 merdoie joyeusement sur sun4u
(sous-système SCSI/FCAL particulièrement buggué). David Miller qui
maintient le noyau sparc64 est très bon, mais il a vraiment trop tendance
à faire des trucs bizarres dans son coin et chaque nouveau noyau
sparc est une aventure extrême ;-) C'est pour cela que j'ai arrêté
de soumettre des patches pour sparc32, je n'arrivais plus à suivre
des évolutions pas vraiment documentées autrement que dans le GIT
sparc...
Tout ça pour dire que je ne vais pas installer ce noyau
immédiatement en prod sur mes machines.
> Puis le 2.6.27 a l'avantage d'être "version stable", c'est cool.
Au problème près de la libcpap lorsque tu as un userland 32/64
bits !
Emmanuel Florac
>> Puis le 2.6.27 a l'avantage d'être "version stable", c'est cool.
>
> Au problème près de la libcpap lorsque tu as un userland 32/64
bits !
>
Vu que c'est exactement la configuration dans laquelle je travaille, tu
peux préciser? Je n'ai pas remarqué de gros souci (même si j'ai eu
quelques bizarreries en FC).
--
There are two ways of constructing a software design: One way is to make
it so simple that there are obviously no deficiencies, and the other way
is to make it so complicated that there are no obvious deficiencies. The
first method is far more difficult.
C.A.R. Hoare.
Emmanuel Florac
> Oui et non. Non car c'est une bêtise de ma part de le proposer en
> production sous Linux (je me suis emmêlé les pinceaux) mais oui car on
> peut avoir zfs sous Linux (enfin pas dans le noyau).
Je suis trop vieux, peut-être que dans 10 ans je pourrai éventuellement
admettre qu'on pourrait peut-être avoir un pilote fuse en production pour
un truc critique genre un fs, mais pour l'instant, non :) C'est même pour
ça que je ne me suis pas plongé dans gluster (pourtant maintenant ils ont
même une version commerciale).
--
La loi, dans un grand souci d'égalité, interdit aux riches comme aux
pauvres de coucher sous les ponts, de mendier dans les rues et de voler
du pain.
Anatole France.
Emmanuel Florac
> Cela confirme en partie ce que j'ai pu voir avec xfs et ext4. Pour
> l'instant, je pense que vais y rester uniquement pour le snapshot sinon
> ce sera xfs.
Oui, sans compter que nilfs n'a toujours pas d'acls et d'attributs
étendus. Il y a pas mal d'applications où c'est franchement problématique.
--
Mais monsieur, voudriez-vous que je me l'écorchasse?
Barbey d'Aurevilly.
Stephane TOUGARD
> Le problème est surtout que le 2.6.32 merdoie joyeusement sur sun4u
>
> Tout ça pour dire que je ne vais pas installer ce noyau
> immédiatement en prod sur mes machines.
Parce que t'as des machines de prod sur Sun4U ET tournant sous Linux.
Quand on voit la stabilite tres relative de Linux (et tu es le premier a en
parler) sur Sun Ultra. Le moins qu'on puisse dire c'est que melanger les
deux sur de la prod, c'est vraiment pas pro.
Stephan Peccini
> Le Fri, 11 Dec 2009 20:59:41 +0100, Stephan Peccini a écrit:
>
>> Oui et non. Non car c'est une bêtise de ma part de le proposer en
>> production sous Linux (je me suis emmêlé les pinceaux) mais oui car on
>> peut avoir zfs sous Linux (enfin pas dans le noyau).
>
> Je suis trop vieux, peut-être que dans 10 ans je pourrai éventuellement
> admettre qu'on pourrait peut-être avoir un pilote fuse en production pour
> un truc critique genre un fs, mais pour l'instant, non :)
On est bien d'accord. En fait là où je me suis mélangé les pinceaux,
c'est en proposant zfs comme alternative aux fonctionnalités de nilfs
que j'avais présentées (sachant que zfs est quand même plus complet)
mais en oubliant complétement de signaler que ce n'est pas sous Linux
qu'il faut l'utiliser en production. J'ai fait un peu court, disons.
Stephan Peccini
> Le Fri, 11 Dec 2009 20:52:46 +0100, Stephan Peccini a écrit:
>
>
>> Cela confirme en partie ce que j'ai pu voir avec xfs et ext4. Pour
>> l'instant, je pense que vais y rester uniquement pour le snapshot sinon
>> ce sera xfs.
>
> Oui, sans compter que nilfs n'a toujours pas d'acls et d'attributs
> étendus. Il y a pas mal d'applications où c'est franchement problématique.
Je parle bien d'usage de zfs à titre personnel et non en production.
J'apprécie le fait de pouvoir me faire des snapshots instantanés avant
de lancer des manipulations importantes et le fait d'avoir des
checkpoints continus pour pallier mes bêtises éventuelles. Sur mon poste
personnel, je n'ai pas besoin des acls et là où j'ai besoin des
attributs étendus je suis soit en ext[34] (historique), soit en xfs
uniquement pour l'attribut « i » (je suis un peu parano pour certains
fichiers). Par contre, j'apprécierai les outils de type "time-based"
comme tfind, tls, tgrep, ... et j'attends de voir ce que donnera le
"time slider".
Donc à l'arrivée j'ai nilfs pour une partie de mon répertoire personnel
(celle où les données sont les plus mouvantes sur un petit disque SSD),
xfs pour les autres données plus stables et pour les archives (hors
historique).
Stephan Peccini
> Oui, sans compter que nilfs n'a toujours pas d'acls et d'attributs
> étendus. Il y a pas mal d'applications où c'est franchement problématique.
Je parle bien d'usage de nilfs à titre personnel et non en production.
J'apprécie le fait de pouvoir me faire des snapshots instantanés avant
de lancer des manipulations importantes et le fait d'avoir des
checkpoints continus pour pallier mes bêtises éventuelles. Sur mon poste
personnel, je n'ai pas besoin des acls et là où j'ai besoin des
attributs étendus je suis soit en ext[34] (historique), soit en xfs
uniquement pour l'attribut « i » (je suis un peu parano pour certains
fichiers). Par contre, j'apprécierai les outils de type "time-based"
comme tfind, tls, tgrep, ... et j'attends de voir ce que donnera le
"time slider".
Donc à l'arrivée j'ai nilfs pour une partie de mon répertoire personnel
(celle où les données sont les plus mouvantes sur un petit disque SSD),
xfs pour les autres données plus stables et pour les archives (hors
historique sur ext).
Emmanuel Florac
> en oubliant complétement de signaler que ce n'est pas sous Linux qu'il
> faut l'utiliser en production.
Et apparemment, sous FreeBSD c'est pas encore tout à fait ça; sous Darwin
c'est mort.... Bon, il reste Solaris. QUelqu'un a testé Hammer sous
DragonFlyBSD? :)
--
In girum imus nocte ecce et consumimur igni
JKB
Re: Trojan dans Linux,
Emmanuel Florac ?crivait dans fr.comp.os.linux.debats :
>
>
>>> Puis le 2.6.27 a l'avantage d'être "version stable", c'est cool.
>>
>> Au problème près de la libcpap lorsque tu as un userland 32/64
> bits !
>>
>
> Vu que c'est exactement la configuration dans laquelle je travaille, tu
> peux préciser? Je n'ai pas remarqué de gros souci (même si j'ai eu
> quelques bizarreries en FC).
Certaines API du noyau ont changé, en particulier dans la couche
logique du réseau. Il y a un problème d'alignement mémoire qui fait
que les fonctions de récupération des paquets en mode utilisateur de
la libpcap bloquent indéfiniment sans jamais voir de paquets. Ce
changement a eu lieu entre les noyau 2.6.26 et 27 ou 27 et 28, je ne
sais plus. Mais j'ai eu la désagréable surprise de ne plus pouvoir
utiliser knockd, iftop, même p0f sur mes serveurs. Il faut donc
recompiler lors du passage la libpcap avec les en-têtes du noyau
courant. Je n'ai vu ce souci que sur mes sparcs qui utilisent un
noyau 64 bits, un userland 32 bits (avec quelques applications 64
bits). Je n'ai vu ça ni sur i386, ni sur amd64. Le truc est
mentionné en tout petit dans le ChangeLog du noyau.
Concernant le FCAL, le noyau 2.6.31 est buggué et n'arrive pas à
initialiser les adaptateurs. Ça se termine avec un timeout et un
panic. Les 2.6.31 se comportent aussi bizarrement sur sun4v et
n'arrivent pas à initialiser correctement les interfaces SAS. En
fait, j'ai deux machines strictement identiques qui fonctionnent
parfaitement en 2.6.30.9. En 2.6.31.x, l'une boote toujours, l'autre
plante toujours au boot sur des erreurs SAS. Ce n'est pas un
problème matériel, mais je n'arrive pas à savoir d'où vient le
souci.
Je vais peut-être utiliser un peu de temps ce week-end pour essayer
de débugguer le 2.6.32 sur sun4u (au moins pour régler le problème
du firmware FCAL et le i2c_bbc qui dysfonctionne à mort depuis le
2.6.26 inclus. En 2.6.27, les températures peuvent devenir
folkloriques et arrêtent la machine et depuis le 2.6.28, le module
se charge ou ne se charge pas, fait un panic lors du déchargement et
ne pilote plus rien...).
Cordialement,
JKB
Re: Trojan dans Linux,
Stephane TOUGARD ?crivait dans fr.comp.os.linux.debats :
Je te signale aimablement que je participe un poil au développement
sur sun4u et sun4v. Je sais donc à peu près comment rendre le truc
stable et à ce jour je n'ai pas eu de problème avec mes sparcs en prod
sous Linux. Si tu veux vraiment savoir, j'ai plus de problèmes avec mes
sparcs sous Solaris (le coup du crle de la semaine passée a été très
chaud !...).
Il y a un truc qui t'échappe, mais pour le comprendre, il faudrait
que tu puisses commencer à avoir le début d'un raisonnement logique.
Dans la vraie vie, on choisie une architecture en fonction de ses
capacités à encaisser des traitements et une charge. Un fois qu'on a
choisi cette architecture, on regarde les OS qui sont dessus et
s'ils peuvent répondre au problème posé. C'est comme ça qu'on se
retrouve avec plusieurs architectures et plusieurs OS dans une
grappe de machine. Faire tourner RDB sous Solaris, c'est une
connerie. Exactement la même que faire tourner un firewall sous
Solaris. Une fois ces choix faits, on regarde la stabilité desdits
OS. Au passage, mes sun4v tournant sous Linux avaient un uptime de
450 jours avant qu'une machine dans une baie à l'autre bout de la
salle disjoncte et entraîne une microcoupure électrique. Je pense
donc qu'on peut déclarer ces machines comme stables.
Au passage, j'ai assez de machines de test pour faire mes
modifications avant de les déployer. Je ne m'amuse pas à patcher un
système critique à chaud (c'est même pour cela que je ne m'amuse
plus à mettre en frontaux des machines sous Solaris !). Bref, une
architecture, ça se pense, c'est une histoire de compromis. C'est ça
le professionnalisme.
Michel Talon
> Le Sat, 12 Dec 2009 04:01:33 +0100, Stephan Peccini a �crit:
>
> > en oubliant compl�tement de signaler que ce n'est pas sous Linux qu'il
> > faut l'utiliser en production.
>
Il para�t que �a marche parfaitement en 64 bits sous FreeBSD. Je l'ai
sur une partition de ma machine en 32 bits, il ne m'a jamais fait de
panic, mais je ne le sollicite pas beaucoup, en gros uniquement la mise
� jour de l'arbre des ports tous les jours et quelques compilations.
J'ai r�duit drastiquement la taille du cache (arc) donc les perfs sont
limit�es, mais enfin �a marche sur une machine x86-32 avec 1.5 Gigs
de m�moire. En g�n�ral si on veut des perfs, il faut beaucoup de cache,
donc beaucoup de m�moire, donc 64 bits. Dans ces conditions, il semble
que les performances soient de haut niveau, sup�rieures � UFS, et
�videmment on a en plus toutes les commodit�s et s�curit�s de ZFS.
Je pense que dans le genre d'applications que tu as dans ton business,
FreeBSD + ZFS devrait �tre tr�s sup�rieur � Linux, pour toutes sortes de
raisons.
> c'est mort.... Bon, il reste Solaris. QUelqu'un a test� Hammer sous
> DragonFlyBSD? :)
>
C'est encore en d�veloppement, il faut au moins 5 ans pour d�velopper un
truc pareil, se lancer l� dedans au lieu de suivre l'id�e initiale de
dragonfly m'a toujours sembl� une id�e bizarre.
--
Michel TALON
Stephane TOUGARD
> plus à mettre en frontaux des machines sous Solaris !). Bref, une
> architecture, ça se pense, c'est une histoire de compromis. C'est ça
> le professionnalisme.
Je suis impressionne, 40 lignes pour ne rien dire. Tu devrais ecrire un
bouquin, j'en connais plein qui sont aussi interessants.
JKB
Re: Trojan dans Linux,
Stephane TOUGARD ?crivait dans fr.comp.os.linux.debats :
Explique-nous.
Stephane TOUGARD
>> JKB wrote:
>>> plus à mettre en frontaux des machines sous Solaris !). Bref, une
>>> architecture, ça se pense, c'est une histoire de compromis. C'est ça
>>> le professionnalisme.
>>
>> Je suis impressionne, 40 lignes pour ne rien dire. Tu devrais ecrire un
>> bouquin, j'en connais plein qui sont aussi interessants.
>
> Explique-nous.
Il y a rien a expliquer. T'as ecrit 40 lignes et tu n'as strictement
rien dit. Ah si, tu t'es gonfle les chevilles, ca tres fort. Franchement
j'admire ta capacite a t'auto-admirer.
Emmanuel Florac
> Il y a rien a expliquer. T'as ecrit 40 lignes et tu n'as strictement
> rien dit. Ah si, tu t'es gonfle les chevilles, ca tres fort. Franchement
> j'admire ta capacite a t'auto-admirer.
Dites donc, les amoureux, vous voudriez pas continuer votre scène de
ménage en privé?
Emmanuel Florac
> Je pense que dans le genre d'applications que tu as dans ton business,
> FreeBSD + ZFS devrait être très supérieur à Linux, pour toutes sortes de
> raisons.
Oui mais non, je suis un intégriste de la GPL, et puis les ports de
FreeBee, franchement c'est l'horreur :) Et je n'ai pas été tellement
impressioné par zfs sous OpenSolaris. Les performances oscille entre
pathétiques et juste décentes.
>> c'est mort.... Bon, il reste Solaris. QUelqu'un a testé Hammer sous
>> DragonFlyBSD?
>>
>>
> C'est encore en développement, il faut au moins 5 ans pour développer un
> truc pareil, se lancer là dedans au lieu de suivre l'idée initiale de
> dragonfly m'a toujours semblé une idée bizarre.
Je disais ça pour voir! j'ai installé une VM dragonfly avec Hammer, mais
je n'ai pas encore eu le temps d'aller au delà.
--
Measuring programming progress by lines of code is like measuring
aircraft building progress by weight.
Bill Gates
JKB
Re: Trojan dans Linux,
>
>
>> Il y a rien a expliquer. T'as ecrit 40 lignes et tu n'as strictement
>> rien dit. Ah si, tu t'es gonfle les chevilles, ca tres fort. Franchement
>> j'admire ta capacite a t'auto-admirer.
>
> Dites donc, les amoureux, vous voudriez pas continuer votre scène de
> ménage en privé?
Ce monsieur a besoin d'un public.
Stephane TOUGARD
>> Il y a rien a expliquer. T'as ecrit 40 lignes et tu n'as strictement
>> rien dit. Ah si, tu t'es gonfle les chevilles, ca tres fort. Franchement
>> j'admire ta capacite a t'auto-admirer.
>
> Dites donc, les amoureux, vous voudriez pas continuer votre scène de
> ménage en privé?
Certainement pas. M'amuse trop. Mais t'inquiete, a un moment va y avoir
un gros troll et on sera du meme cote de la barriere.
Tiens, si il etait moins bete le JKB, il aurait deja pu partir sur un
vrai troll VMS et je pense meme que j'aurais ete assez d'accord
(securite VMS contre Unix ou franchement, il y a pas photo).
JEf
> Acteuelement je suis sur : Linux DC2200 2.6.28-16-generic #55-Ubuntu
> SMP Tue Oct 20 19:48:32 UTC 2009 x86_64 GNU/Linux
Mettre stable et Ubuntu dans la m�me phrase ou comment faire le grand
�cart. Si tu mets du ubuntu sur tes serveurs, nilfs est stable assez :-)
JEf