Reprise du message précédent :

Ca finira par sortir mais ce n'est pas "urgent" car de toute façon quoi qu'il arrive:
-Il faut mettre à jour régulièrement sont système.
-A l'installation les maj sont faites automatiquement depuis internet
 
Sinon la faille ne peut pas être exploité à distance:  
Elle permet à utilisateur déjà loggé sur la machine en utilisateur normal de passer root, c'est très grave comme faille sur des serveurs d'application/multi-utilisateurs mais en général ces machines là sont maintenues par des personnes sérieuses (maj régulières, au courant des problèmes de sécurité etc..)

Oui ça j'avais compris, d'où le terme "rassurant" : c'est psychologique, mais c'est important en entreprise ou les décideurs compétents peuvent être effrayé par une OS troué à l'install (même si pas dangereux).

 
En fait à l'installation, l'installateur Debian va récupérer la liste des paquets mis-à-jours sur internet avant même l'installation, donc le paquet troué n'est pas installé une seule seconde sur le système, le nouveau paquet est installé séparement et simplement à la place.
L'installateur à été assez bien réfléchi de ce coté là, si les décideur compétents sont réellement "compétents" il doivent pouvoir comprendre la relative sécurité du truc  
(mais aucun système n'est infaillible).
 
Il sortiront sûrement une version corrigée mais pas forcement en toute urgence vu que du point de vue de la sécurité réelle ce n'est pas urgent.

ah ? Dans le cas du netinstall peut être, mais pour une iso "complète" ? Il me semble qu'il installe le "vieux" noyal non

 
quand t'installe un nouveau système, tu fais *toujours* les mises à jour de sécu.

 
moi oui

Dans une iso complète il me semblait qu'il récupérait quand même les mises à jour ( mais je confond peut-être entre les deux), sinon avec l'installation iso il est toujours possible de s'isoler du monde extérieur pendant l'installation, d'installer le nouveau kernel (juste un .deb) et de se rebrancher au réseau (enfin de dire ça au décideurs pour la psychologie puisque de toute façon branché ou pas, il n'y pas de risque de ce côté là)

Franchement, si c'était le cas tu crois honnêtement qu'il y aurait autant de postes sous Windows dans les boîtes ?
De là à conclure qu'il n'y a pas beaucoup de décideurs compétents...

Je connais des décideurs qui n'ont pas le pouvoir pour passer les postes desktop sous autre chose que MS...

En fait dans "décideurs", je voulais dire chef de service info compétent et au courant de l'open source.. Je parle pas des n + x convaincu par les costards cravate de chez $nomdungroséditeurdelogiciel

 
en même temps, si des decideurs etaient competents (techniquement, j'entends) ça se serait
 

J'ai été responsable info, et mis a part la grande direction qui ne me laissait pas migrer le parc entier sous linux j'ai réussi a passer 10-20% des postes...

Saurait

 
c'est bien de ceux là dont je parlais

J'ai un problemes pour la recuperation de paquet via apt-get.
 
Il me met souvent erreur de lecture du serveur (104 la connexion a ete reinitialise par les correspondant).
 
J'ai changer de serveurs dans mon sources list, mais le probleme perdure

Bonsoir à tous,    
 
 

Les décideurs seront à présent rassurés psychologiquement, puisqu'une version mise à jour de stable est disponible depuis hier.
 
Il s'agit de la troisième révision importante de Etch depuis sa sortie, celle-ci concernant essentiellement des mises à jour de sécurité. On retrouve bien sûr une version 2.6.18 du noyau Linux incluant notamment le patch corrigeant la fameuse faille "vmsplice", mais aussi des versions fixant des problèmes importants dans la Glibc, Apache et Apache 2, Java, Xorg, KDE ou encore dans PHP5, MySQL 5, PostGreSQL 7.4 et 8.1, Tomcat 5 et 5.5, XulRunner... *
 
   ---> les infos qui vont bien : Debian GNU/Linux 4.0 updated
 
 
Les images ISO étiquettées « 4.0r3 » seront très prochainement disponibles (première page du topic déjà à jour).
 
 
 
* Note: pour le détail complet de toutes les modifications, se rapporter au changelog fournis en lien dans la news Debian.

Parfait

Salut !
 
J'ai 2 HD SATA 320 Go sur lesquels je fais du RAID soft mais les perfs ne sont pas là... Je m'attendais à avoir le double de débit en Timing buffered disk reads sur /dev/md1 mais ce n'est pas le cas :
 

 
Des idées pour améliorer un peu tout ça ?

[raid1]
 

Je crois que y'en a qui n'ont pas les notions de bases du Raid là

Qlqun peut m'aider à installer une carte wifi ?
 
Visible par lsusb :

Faut le savoir hein
 
Module rt2500 chargé.
Mais rien du tout dans les interfaces réseau (rausb0, ethx)
 

Pareil chez moi pour le RAID1 sous Etch.
J'ai la flemme de remonter une Sarge, mais je suis quasi sur que j'avais teste et qu'il y avait bien amelioration des perfs en lecture.

 
Sur la mailing list du LUG du coin (Guilde, Grenoble), la question avait été soulevée également (pourquoi pas d'améliorations de perf en lecture avec du raid1).
De ce que je me souviens, le module qui gère ça de manière software dans Linux ne fonctionne pas comme ça.
Mais j'arrive pas à remettre la main sur le mail en question À priori, l'explication était marquée dans la doc du noyau, mais je retrouve pas non plus ...

M'enfin t'es très très loin d'avoir le double des perfs normalement

Mail retrouvé
 
Bon, j'avais pas tout compris en fait

Même constat sur mes serveurs persos/pros. Pas d'augmentation de perf en raid1 en écriture alors que ça devrait être le cas.
 
Si quelqu'un a une explication...

en écriture c'est normal... labsus ?

Euh... C'est moi ou en RAID les perfs sont soumises à la loi du disque le plus lent de la grappe ? Vous êtes sur que c'est pas en RAID0, 0+1 ou 5 qu'on a des perfs qui augmentent ? Ou alors j'ai oublié tous mes cours...

En raid1, les données sont dupliquées sur deux disques.
Donc, on peut imaginer que quand tu as besoin de lire des données, au lieu de lire tout sur un disque (ou sur les deux en même temps, au même endroit), tu en lis un peu sur un disque, un peu sur l'autre.

Donc, en théorie, tu peux lire des données aussi vite que le peuvent les deux disques en parallèle (si c'est les même disques, tu doubles le taux de transfert).
Après, c'est la théorie et tout.

Edit: en raid0, 0+1 et raid5, les perfs en écriture augmentent aussi, vu que les données sont écrites en parallèle sur plusieurs disques.

 
Augmentation des perfs = Raid0 ou Raid5.
 
Pas d'augmentation des perfs en Raid1.
Sur le Raid1 tu as ton disque (le plus lent effectivement) et le reste se content de copier exactement et de prendre le place en cas de pannes.
 
Le Raid0 tu écris sur 2 disques en // donc effectivement en théorie tu peux doubler tes perfs, vu que tu peux écrire ou lire sur 2 disques en même temps.
En raid 5 c'est comme le raid0 mais avec un disque qui fait la parité des 2 qui permet d'avoir une image valide si un des disque plante.
 
Donc Raid1 pas d'augmentation de perfs, normalement tu lis pas sur les 2 disques en même temps des données différentes par ce que sinon tes têtes de lecture sont mal placés et tu perds beaucoup de temps de synchro en écriture.
 
Après c'est la théorie et la pratique des serveurs de prod en unix ou en hard.
En soft et en debian je sais pas si ils ont fait des tweak ou autre mais normalement non.

D'après le code du 2.6.24, md fait du read balancing : quand il y a une lecture sur le RAID-1, il vérifie d'abord si c'est une lecture séquentielle auquel cas il garde le même disque sinon il vérifie la position des têtes des différents disques et effectue la lecture sur le disque qui a sa tête la plus proche des données à lire. Donc à priori, ça doit booster la lecture sur de multiples fichiers (sauf qu'apparemment md ne prend pas en compte la charge des disques) mais dans le cas d'un hdparm qui fait du séquentiel, on n'obtient que les performances d'un disque. Y'a plus qu'à tester bonnie++ pour voir...
 

Et donc en aucun cas de la lecture de donnée en parallèle sur les 2 disques, donc le gain restera faible .
 
C'est plutôt un gain en temps d'accés qu'en vitesse de lecture en fait

 
RAID 5 write hole...

J'avais pas pensé à ça
Après, comme je disais, c'est la théorie ce que j'ai raconté, en pratique ça se justifie pas forcément, effectivement.
 

Oui ?
 

ah tient, je devrais commencer à lire ce sujet moi  

 
En effet: s/écriture/lecture/

Oui mais non, en gros:
raid0+1/raid1 meilleur en ecriture car on attend l'acquitement de l'ecriture en parrallele (mais on peut aussi imaginer attente des 2 acquittements pour verifier que tout s'est bien passe) et puis surtout on n'a pas le probleme du calcul de la parite.
raid5 meilleur en lecture car on fait tourner plusieurs disques pour fetcher des donnees. mais excecrable en ecriture a cause du calcul de la parite sur ton volume du meme nom a chaque fois que tu ecris. C'est toujours deconseille pour les applications sensibles aux latences, type ecriture dans les redologs d'Oracle.

En pratique sur de la prod, ces concepts sont implementes dans ta baie de disques

bonjour,
j'avais installé iceape sur une stable, seulement il était en anglais, ça ne me dérangeait pas trop, mais j'aimerai donner ce pc à ma mère donc ça serait cool si c'était plutôt en français.
comme ya pas beaucoup de paquet iceape* j'en avais déduis qu'il n'était pas disponible en francais, mais ça m'étonne.
vous connaissez une manip?
merci

iceape-l10n-fr - French language package for Iceape
disponible sur testing et unstable uniquement

Bonjour,
J'ai changé de carte mere et depuis j'ai perdu ssh et apache2.
Par contre mon partage samba est ok (hormis que les debits soient lamentables)
 
Donc depuis que j'ai rebranché, j'ai fait un ifconfig avec l'ip du serv (192.168.2.2)
 ifconfig
eth1      Lien encap:Ethernet  HWaddr C2:35:47:66:19:00
          inet adr:192.168.2.2  Bcast:192.168.2.255  Masque:255.255.255.0
          adr inet6: fe80::c035:47ff:fe66:1900/64 Scope:Lien
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:8187132 errors:0 dropped:0 overruns:0 frame:0
          TX packets:8819964 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 lg file transmission:1000
          RX bytes:9040922600 (8.4 GiB)  TX bytes:2130525657 (1.9 GiB)
          Interruption:209 Adresse de base:0x4000
 
lo        Lien encap:Boucle locale
          inet adr:127.0.0.1  Masque:255.0.0.0
          adr inet6: ::1/128 Scope:Hôte
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:216761 errors:0 dropped:0 overruns:0 frame:0
          TX packets:216761 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 lg file transmission:0
          RX bytes:15028369 (14.3 MiB)  TX bytes:15028369 (14.3 MiB)
 
Et dans mon :etc/network/interfaces, j'ai changé eth0 par eth1 (qui apparaissait dans ifconfig):
 
# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).
 
# The loopback network interface
auto lo
iface lo inet loopback
 
# The primary network interface
allow-hotplug eth0
iface eth0 inet static
address 192.168.2.2
netmask 255.255.255.0
gateway 192.168.2.1
 
auto eth1
~
~
 
 
Comment recuperer ma config ?
Je pense qu'il s'agit d'une erreur de gateway, non ?

 
Non elle est en RaidDP (Raid6)