boboss a écrit 6 commentaires

  • [^] # Re: Faille de sécurité dans les noyaux Linux 2.4.18 à 2.4.22

    Posté par  . En réponse à la dépêche Faille de sécurité dans les noyaux Linux 2.4.18 à 2.4.22. Évalué à 1.

    Et bien, il est certain qu'il faut remercier et féliciter les équipes qui ont trouvé l'origine du problème... il est pourtant navrant d'identifier un problème qui était déjà connu depuis plusieurs semaines. On comprend qu'il est difficile de mettre à jour des serveurs dans la mesure où ils sont sollicités en permanence par le monde entier (apt-get dist-upgrade, mon amour ! ). Peut-être s'agit-il d'un manque de temps de l'équipe Debian ou d'un manque en personnel pour ce genre d'opération (faites un don !). Puisque ce n'est pas un problème spécifique à Debian, il va falloir que tout le monde y passe... J'imagine déjà M$ argumentant sur la vulnérabilité des serveurs linux, c'est le genre d'erreur qui tombe au mauvais moment. Il faut avouer que cette faille requiert à priori un sacré niveau pour l'exploiter... Pour conclure, la morale de l'histoire me direz vous ? On a tout de même un système gratuit, lequel on suppose être démuni de service après vente réel, ainsi le laisse sous-entendre les refourgueurs d' OS sur-bogués, et bien voilà quand même l'erreur corrigée par les mainteneurs du libre. Alors ce qui m'amuse en définitive, si une grosse société à plusieurs milliards de dollars ne corrige pas ses serveurs et se laisse envahir par un ver (conf. blaster.worm), comment pourrait-elle se prétendre meilleure ?

  • [^] # Re: Pour un démarrage plus rapide de Linux

    Posté par  . En réponse à la dépêche Pour un démarrage plus rapide de Linux. Évalué à 1.

    A bien y réfléchir, je me dis qu'un boot rapide, ça n'a pas tellement d'intérêt, dans la mesuse où le système est si stable que généralement, la machine est allumée le matin, et éteinte le soir (cas bureautique)... pour un serveur, la question deviendrait presque grotesque.

    Disons que le plus pénible, c'est d'avoir une machine bruyante qui nous souffle dans les oreilles, et que l'on utilise peu.

    Le projet acpi pour linux va de mieux en mieux gérer la suspension de la machine, au plus rapide on aurra le "suspend to ram", arrêt totale de la machine, mais la mémoire vive reste alimentée pour un retour très rapide, et le "suspend to disk", comme on a pu le lire dans les posts plus haut (swsusp), permet la sauvegarde de la ram sur disque dur et l'arrêt total de la machine.

    A vrai dire, il ne faut pas froncer les sourcils quand quelqu'un souhaite optimiser le comportement d'un système, bien que cela puisse parraître inutile au premier regard.

  • [^] # Re: Pour un démarrage plus rapide de Linux

    Posté par  . En réponse à la dépêche Pour un démarrage plus rapide de Linux. Évalué à 0.

    J'ai constasté la chose suivante :
    Il y a plusieurs éléments qui ralentissent le temps de démarrage au boot:

    1) La minuterie excessive accordée à lilo ou grub pour démarrer un système par défaut (ça, c'est facile à régler !), ca parrait idiot sur le moment, mais qui n'a jamais constaté que sa box ne s'était pas encore lancée après une longue absence...?

    2) Quand le kernel se charge, les modules sont chargés à leur tour. Le problème, c'est que l'accès au disque dur y est très important (c'est la fameuse séquence "calculating module dependencies"). J'ai remarqué qu'en recompilant ces modules particuliers et en les intégrant au kernel directement (on sacrifie un peu le côté "évolutif" du kernel...) , on y gagnait déjà plusieurs secondes, surtout quand on possède un disque lent.

    3) Les modules SCSI comme pour l'AI7CXXX, refont un scan complet des disques présents sur la machine...

    4) le choix des services lancés par défaut après l'installation d'une distribution, (dans /etc/rcS.d et /etc/rc5.d ou rc3.d suivant la distrib) mériretait une attention particulière (par ex. une machine pour la bureautique se passera bien de bind, du server dhcpd, etc...)

  • [^] # blockage par ipchains

    Posté par  . En réponse à la dépêche VeriSign détruit l'un des fondements d'Internet. Évalué à 3.

    Pour ceux qui voudraient bloquer les acces vers verisign avec le (bon) vieux ipchains:

    ipchains -A forward -s 0.0.0.0/0.0.0.0 -d 64.94.110.11 -j REJECT
    ipchains -A input -s 0.0.0.0/0.0.0.0 -d 64.94.110.11 -j REJECT
    ipchains -A output -s 0.0.0.0/0.0.0.0 -d 64.94.110.11 -j REJECT

    Ainsi, sur votre machine locale, ou sur les pc connectés derrière votre routeur, on obtientra par le ping un destination port unreachable, ou Connexion refusée par mozilla...

    c'est du provisoire, forcement...

  • [^] # Re: Validation de la norme 802.3af : l'électricité dans vos câbles réseau

    Posté par  . En réponse à la dépêche Validation de la norme 802.3af : l'électricité dans vos câbles réseau. Évalué à 6.

    48 Volts et 12 Watts, ok ca représente peu d'énergie pour la majorité du matériel actuel, mais on pourrait imaginer une imprimante munie d'une batterie, comme un pc portable avec une certaine autonomie, et bien sûr lorsque l'on ne la soliciterait pas trop celle-ci se rechargerait tranquilement. Il est rare que l'on imprime énormément de documents, c'est plutôt sporadique...1 feuille par là, 2 autres par ici... n'empêche que je me demande si l'arrivée massive d'une telle technologie n'entrainera pas d'effets secondaire sur la santé.

  • [^] # Re: Accélération du rythme de déploiement de l'ADSL

    Posté par  . En réponse à la dépêche Accélération du rythme de déploiement de l'ADSL. Évalué à 3.

    En effet, je bénéficie depuis fin d'année dernière de l'adsl 512, alors que j'étais trop loin du central, c'est parcequ' ils ont un système qui booste le signal, du moins sur quelques mètres...ca doit être couteux, donc quand plusieurs personnes veulent l'adsl, ils se joignent, et france télécom étudie le coup de revient de l'opération... il faut certainement un nombre mini d'abonnements pour être rentable ! (j'ai eu l'occasion de parler avec un vrp wanadoo)