Olivier a écrit 889 commentaires

Je te propose ceci:
- téléchargement du .deb de libc de chez Trisquel. Tu sauves le fichier sur une clé USB
- booter la machine sur un liveCD ou un liveUSB, afin d'avoir un système Linux opérationnel
- monter la partition "/" du Trisquel
- dans un répertoire temporaire, tu décompresse le .deb de la libc. Pour cela, tu as besoin du programme "ar" http://www.debian-fr.org/extraire-paquet-deb-t33047.html , voir aussi du programme "xz" (dans mes tests, j'ai trouvé un data.tar.xz dans le .deb)
- enfin, tu copies l'arborescence décompressé du "data.tar.*" dans le "/" de Trisquel
- demonté le "/"
-reboot sur disque dur de la machine.

je te conseille de te documenter un peu plus sur le sujet au risque de faire des grosses bétises et te retrouver avec une passoir en voulant faire une ligne Maginot

Il y a quelques années, j'ai écrit un tuto avec les bases de TCP/IP : http://olivieraj.free.fr/fr/linux/information/firewall/fw-01.html

Et la suite est un tuto sur iptables : http://olivieraj.free.fr/fr/linux/information/firewall/fw-03.html

Cela devrait être une bonne base assez simple pour commencer.

Sur mon portable de boulot, juste avant de partir en vacances, une mise à jour mineur de Windows 7 a complètement vautré le système : Impossible de booter windows, le système rebootait juste après le chargement du boot loader.

Problème : le disque dur était intégralement chiffré, donc impossible de récupérer les données par un boot sur une clé USB.

J'ai passé dans les 3 jours de vacances à déchiffrer le disque et à récupérer toutes mes données, en utilisant, mon linux perso. L'OS, lui, a eu droit à une réinstallation complète par le support informatique de ma boîte.

Bref, Windows est peut-être près pour le desktop. Mais lorsque qu'il se plante méchamment, c'est Linux que l'on appelle à la rescousse… :)

Debian est une distribution plutôt à cheval sur le respect des licences des softs, et il se trouve que bon nombre de drivers et de firmwares ne sont pas libres. Pour les firmware, il se trouve que ta carte wifi en a plus que probablement besoin.

Aussi, Debian a pour politique de ne pas proposer en standard ce type de softs. A la place, ils sont "isolés" dans le dépôt "non-free", et téléchargeable via divers paquets:
https://packages.debian.org/search?keywords=firmware&searchon=names&suite=stable&section=all

Il est très probable que la distribution "Kali" que tu utilises, elle, propose en standard ces fameux firmwares non-free

Pour t'en sortir:
- d'abord, il faut que tu identifies avec précision le chipset wifi que tu utilises. Sous "Kali", la commande "lspci" devrait t'aider. Sinon, il faut lire le contenu du "dmesg"
- une fois que tu as installé ta Debian, il te faut configurer le dépôt "non-free". Pour cela, tu auras besoin de connecter temporairement ta machine à la box ADSL, en passant par un câble réseau
- quelques liens qui peuvent t'aider (30s de recherche sur ton moteur favori):
https://wiki.debian.org/fr/SourcesList
http://www.debian-fr.org/comment-ajouter-la-section-non-free-aux-sources-list-t31143.html
https://www.isalo.org/wiki.debian-fr/Images_pour_firmwares_non_reconnus (une fois que tu as la liste, il faut installer le .deb manquant avec un "dpkg -i LE_NOM_DU_PAQUET.deb")

1: Fragmentation
J'ai une partition EXT4 sur lequel j'ai plusieurs flux de logs qui s'enregistrent en permanence et en parallèle (=> mauvais pour la fragmentation). Les fichiers les plus vieux (plusieurs Go par fichiers) sont purgés automatiquement lorsque il ne reste plus assez de place (=> encore plus mauvais pour la fragmentation).
Sur cette partition j'ai observé au fil du temps des baisses progressives de vitesse de lecture des fichiers (de 60Mo/s à 15Mo/s). A partir de ce moment là, le taux de fragmentation (indiqué par fsck.ext4) était supérieur à 50%.
En reformatant la partition et en remettant les derniers logs, la vitesse de lecture est revenu à 60M/s.

Conclusion : La fragmentation a vraiment un méchant impact sur les perfs d'un disque dur, spécialement lorsque 1) on y fait des écritures en parallèle (ex: les logs, qui allouent de petits blocs à chaque fois) ou 2) lorsque le disque est maintenu plein en permanence (ajout et suppression régulière de données).

2: Vieillissement du disque dur
Avec les temps, la mécanique du bras des têtes de lecture est moins précises. En cause, la graisse de l'axe de rotation du bras qui freine aléatoirement le déplacement du bras. Celui-ci a alors un déplacement de type "serpent" lorsqu'il doit se repositionner pour lire/écrire un nouveau bloc. Ces "hésitations" du bras coûte cher en milli-secondes, d'où une baisse de vitesse dans la lecture/écriture aléatoire de données.

3: Mise à jour:
Certaines distributions plus que d'autre ont tendance à laisser plein de vieux soft ou de veilles configurations après des mises à jour. Un grand nettoyage est parfois nécessaire.
Personnellement, je trouve qu'Ubuntu est assez pénalisée par ce phénomène, spécialement lorsque l'on fait les mises à jours tous les 6 mois.

A titre personnelle, j'avais une Debian Testing i686 qui a durée plus de 6 ans. Elle marchait encore bien, même après cette durée, mais je voulais un peu plus de réactivité. J'ai profité du passage au SSD pour la réinstaller en AMD64, les performances ont bien entendu été bluffantes.

Si tu veux JOUER, à des jeux demandant une grosse puissance graphique, tu ne vas pas avoir trop le choix que d'utiliser les drivers propriétaires, et une carte vidéo AMD ou NVIDIA.

Si ta machine est un portable avec du NVIDIA, il est fort probable que celui-ci soit utilisé en temps que processeur vidéo secondaire (technologie "Optimus" http://doc.ubuntu-fr.org/nvidia_optimus ), qui n'est pas sans être un peu compliqué sous Linux.

Personnellement, je suis sous Debian Testing, et l'installation/mise à jour des drivers proprio NVIDIA se résume à:
activer les dépots non-free (dans /etc/apt/sources.list):

# Testing
deb http://ftp.fr.debian.org/debian/ testing main contrib non-free
deb-src http://ftp.fr.debian.org/debian/ testing main contrib non-free

deb http://security.debian.org/ testing/updates main contrib non-free
deb-src http://security.debian.org/ testing/updates main contrib non-free

installer un paquet ("nvidia-kernel-amd64")

Après, pour ce qui est de AMD/NVIDIA, je dirais que ne jouant pas (plus), je ne serais pas de grand conseil. Cependant, il me semble que Steam recommande NVIDIA

Pour ce qui est du "logiciel espion indétectable", il se pourrait que le canard fasse référence à Computrace, dont il a été question ici il y a quelques temps :

http://linuxfr.org/users/kwak/journaux/computrace-une-backdoor-pour-votre-plus-grand-bien-0ef8c8b0-6354-4a4f-9d12-11f2d765bb5f
http://korben.info/computrace-lojack-absolute.html

Pour faire simple : Prise en main à distance, via une option présente dans les BIOS EFI. Certains "gros" constructeurs de machines le propose.

Enfin, certains constructeurs comme DELL, propose sur ses serveurs un mécanisme appelé "DARC", qui permet de prendre le contrôle de la machine http://fr.wikipedia.org/wiki/Carte_DRAC . C'est utilisé à des fins d'administration, comme par exemple:
- rebooter/arrêter la machine
- booter la machine sur une image ISO, placée en local ou à distance
- changer les paramètres de BIOS, et par exemple booter en PXE
- avoir accès à la sortie VGA, et ce même lors du boot de la machine (entre autre pour rentrer dans le BIOS)
- via un service installé sur un MS Windows, avoir une "vrai" prise en main à distance, de type "Terminal service"
- plus tout un tas d'autres mécanismes de monitoring/autre

J'imagine que les autres constructeurs doivent proposer des mécanismes similaires.

Tu pourrais commencer par vérifier que les mécanismes bas-niveaux d'hibernation fonctionnent.

Pour cela, lance un terminal, log-toi en root (sudo bash), et lance un :

/usr/sbin/pm-suspend pour mettre en veille
ou
/usr/sbin/pm-hibernate pour hiberner

Il y a des fichiers de logs dans /var/log/pm-*

Une fois cette partie-là validée, tu pourras regarder du coté de policikit.

Mais je suspecte que le problème vienne de XFCE : En effet, sur quelques machines que j'ai (Debian Testing) les upgrades de XFCE changent parfois les droits de l'utilisateur pour le shutdown/reboot/etc…

A noter que cela peut aussi venir du gestionnaire de session : gdm/gdm3/lightdm/slim, etc…

Personnellement, je suis en Debian Testing et j'utilise IceDove version 24 https://packages.debian.org/jessie/icedove , et cela marche très bien. La version actuelle de ThunderBird est justement la 24 : http://www.mozilla.org/en-US/thunderbird/24.5.0/releasenotes/

D'après sa phrase "Worse, it’s based upon obsolete Thunderbird/Icedove technology, which is dead since the release of Firefox® 17 and will only degrate over time", TB 24 est basé sur FF 17 qui est ancien. Je dirais "Et alors ?"

Ce n'est pas le problème d'Enigmail si TB se base sur une version de Geeko qui est ancienne.

Après, si cet article est là pour simplement lancer une guerre/troll des clients mails, c'est une autre chose ! :)

Bonjour,

Gruik a donc été plus sage cette fois-ci ?

Merci, et bravo aux admins !

sachant que la version de KDE est très ancienne

Cela dépend de la version de Debian que tu utilises.

Je suis en Debian Testing, et les paquets KDE* sont estampillés 4.11 et 4.12. Or, la version actuelle de KDE est la 4.13 : http://kde.org/download/ . On ne peut pas dire que cela soit très ancien…

La Debian stable utilise certes un KDE plus ancien (4.8), mais c'est normal, car elle est sortie il y a un an (4 mai 2013 https://www.debian.org/releases/stable/ ).

Petite question : il est parlé ici de convertisseur Direct3D -> OpenGL, donc pour ce qui concerne la vidéo. Mais qu'en est--il du reste ?
En plus de l'affichage, DirectX offre aussi la gestion du son, des inputs (clavier/souris/joystick/pad/…), du réseau. Est-ce qu'il existe d'autres mécanismes de conversion pour ces parties-là ?
Ou alors, les développeurs ne les utilisent pas ou utilisent d'autres toolkits, que l'on doit migrer indépendamment ?

et il tient dans 4Gb sur disque

4Gb sur le disque ? Et les mises à jours diverses et variées ?

Sur le Seven de mon boulot, le répertoire c:\windows\winsxs\ fait à lui tout seul 10Go ! Et je ne parle même pas des C:\windows\installer\ , C:\windows\$*\ , et autres joyeusetés.

Lorsque je compare les répertoire c:\windows\ d'un 95, NT, 2000, XP, Seven, j'ai l'impression qu'au file des versions majeurs, cela devient une poubelle où sont stockés sans cesse de nouveaux fichiers temporaires.

Au moins, Linux à un "/var" bien à part, dans lequel tous ces trucs temporaires peuvent être purgés facilement.

Quand au 4Go de Windows 8, j'ai comme un doute :

• http://www.nextinpact.com/news/74515-windows-8-quel-espace-disponible-pour-utilisateur-sur-tablette.htm

  Sur 64 Go disponibles, quasiment 10 Go sont avalés par la partition de restauration et une quinzaine sont réquisionnés par Windows 8, les pilotes, et les différentes applications du constructeur.

• http://www.itespresso.fr/microsoft-surface-windows-rt-cannibalise-lespace-disque-58494.html

  Pas moins de 16 Go sont nécessaires pour héberger le noyau et tout son écosystème.

Je suis en Debian Testing depuis des années, et cela marche plutôt bien.

C'est moins à jour que Sid/unstable (il y a 2/3 semaines de délais par rapport à Sid, si aucun problème n'a été détecté), ce qui permet d'avoir un OS qui évolue par petites touches, sans pour autant prendre trop de risques.

Le passage de KDE 3.5 à KDE4 a été un peu laborieux, mais tout le monde avait été impacté.

Quand à Gnome3, je reste en mode "fallsafe / flashback" (une interface de style "Gnome2"). Mise à part le fait que je n'ai plus de fond d'écran quand j'active les icônes de bureaux, je dirais que cela marche.

Dans le cadre de mon boulot, nous utilisons de temps en temps des softs destiné à dialoguer, via port SERIE, avec des contrôleurs de robots industriels. Cela reste assez basique : Mise à jour de firmware de robots, paramétrage et récupération de logs. Il y a toutes softs de robots différents, venant de de divers constructeurs.

Ces softs datent de l'époque des robots, entre 10 et 15 ans, et fonctionnent parfaitement sous Windows NT, 2000 et Windows XP. Par contre, la grande majorité ne fonctionnent plus sous Windows Seven, même en activant le mode de compatibilité, ou avec les droits administrateur.

Résultat : Nous devons garder des vieux portables sous Windows NT ou XP, afin de les faire fonctionner.

Il peut y avoir des informations intéressantes dans du code PHP. Comme par exemple le mot de passe du serveur MySQL que l'on utilise en parallèle (serveur LAMP par exemple).

Je rajoute que la référence pour avoir une idée de ce que "sed" peut faire est

http://sed.sourceforge.net/sed1line_fr.html

Il y a tout un tas d'exemples de trucs simples, pratiques, voir carrément tordus, donc indispensables !

Commence par faire un "fdisk -l /dev/sdb". Tu devrais avoir au moins une information sur la taille de la clé, quelque chose du genre :

Disque /dev/sdb : 64.0 Go, 64023257088 octets

Si il y a quelque chose, tu peux tenter de voir le contenu de la clé, en utilisant un éditeur hexadécimal. Par exemple, "hexedit"

hexedit /dev/sdb
(Utilise "ctrl+c" pour sortir).

Si tu vois des caractères autres que "00", c'est la clé fonctionne, mais que le système de fichier est corrompu. Essayes alors :

• soit tu essayes de retrouver tes partitions, et de potentiellement retrouver tes données. http://www.cgsecurity.org/wiki/TestDisk est dispo sur ta Debian
• soit tu décides de tout perdre, et tu reprends tout à zéro:
  • fdisk pour recréer la partition. Si tu veux la partager avec ta chaîne hifi, il faudra probablement créer une partition FAT32 (utilise le type "c")
  • et enfin tu formates la clé ("mkfs.vfat -F 32 /dev/sdb1" par exemple)

Je viens de faire un test, mais cela ne marche pas.

Personnellement, j'utilise déjà http://www.privoxy.org/ afin de filtrer le gros des sites de pub / analyse / autre

Et pour les requêtes Google de type http://ajax.googleapis.com/ajax/libs/jquery/*/jquery.min.js :
- j'installe un serveur web qui tourne sur mon localhost (un serveur apache, lighttpd, autre)
- je sauve une copie des fichiers google sur mon disque local:

# find /var/www/redirect/ajax.googleapis.com/ajax/libs/jquery -type f
/var/www/redirect/ajax.googleapis.com/ajax/libs/jquery/1.4.2/jquery.min.js
/var/www/redirect/ajax.googleapis.com/ajax/libs/jquery/1.5/jquery.min.js
/var/www/redirect/ajax.googleapis.com/ajax/libs/jquery/1.9.1/jquery.min.js
/var/www/redirect/ajax.googleapis.com/ajax/libs/jquery/1.5.1/jquery.min.js
[...]

• Je configure Privoxy pour qu'il redirige les requêtes de Google sur mon serveur local :

less /etc/privoxy/user.action
# Redirect remote requests to the local version delivered localhost
{ +redirect{s@^http://@http://localhost/redirect/@} }
ajax.googleapis.com/ajax/libs/jquery/[0-9\.]*/jquery.min.js.*
ajax.googleapis.com/ajax/libs/jqueryui/[0-9\.]*/jquery-ui.min.js.*
www.google.com/jsapi
www.google-analytics.com/ga.js

Ainsi, lorsque un site ZZZZZZ dépend de ces API google, c'est ma copie qui est envoyée au navigateur. Cela évite donc une connexion chez Google, avec échange de http-refer, cookies, autre…

Attention : Pour une connexion 10/100Mb/s, tu n'as besoin que de 2 paires de fils ethernet, et donc tu peux connecter 2 prises ethernet à un seul câble réseau.

Par contre, si tu veux du 1000Mb/s (gigabyte), alors il te faut les 4 paires (8 fils) du câble ethernet. Aussi, si tu as des prises doubles, il te faudra passer non plus un câble, mais deux.

C'est très très vieux cette histoire de SSL affaiblit.

D'après http://article.gmane.org/gmane.linux.debian.security.announce/1614 , le bug a été introduit en 2006, et corrigé en 2008. Plus d'info dans http://www.debian.org/security/2008/dsa-1571 , mais il faut bien voir que cela concerne les distribution Etch, Lenny, ce qui ne nous rajeunit pas.

Ici http://www.debian.org/security/key-rollover/ , il est expliqué que lorsque le patch est appliqué, cela change la signature du serveur, et donc que l'on voit apparaître le message du présent journal.

Il faudrait que le serveur en question ait été installé avec une très vielle distribution, et non mise à jour depuis très longtemps (5 ans) !

Si je comprends bien, tu déplaces un Windows 7 de /dev/sda3 vers /dev/sdb4, et tu n'arrives pas à le faire démarrer ?

Il y a pas mal de raison pour lesquelles cela ne marche pas, en voici quelques unes :
- comment as-tu transféré le Windows ? Un simple cp/rsync entre les partitions ?
- le Windows voir qu'il a changé de placé, aussi il peut considérer que c'est une copie illicite qui tente un boot -> Blocage
- le Windows est une version OEM (je le suppose, parce que tu parles d'une partition de restauration). Dans ce cas-là, il ne voit pas le tatouage (qui se trouve encore sur /dev/sda), et considère que c'est une copie illicite -> Blocage
- Bootmrg fait encore des siennes. Jette un coup d'oeil sur http://doc.ubuntu-fr.org/tutoriel/comment_amorcer_ubuntu_avec_bootmgr ou sur http://doc.ubuntu-fr.org/cohabitation_ubuntu_windows pour en savoir un peu plus sur bootmgr
- un problème lié à EFI ? (pas sûr du tout)

Bref, ce n'est pas gagné d'avance.

Le plus simple pour toi est probablement de laisser le Windows 7 là où il est (/dev/sda), et d'utiliser le mécanisme du "drivemap" de GRUB2 pour faire un échange entre tes disques.

Regardes de ce coté-là
https://www.google.fr/?q=grub2+drivemap
http://forums.justlinux.com/showthread.php?153276-Grub2-mapping-drives

Tu peux simplement mettre un mot de passe sur le site / page web.

Si tu utilises un serveur apache, tu peux restreindre l'accès à un répertoire/sous répertoires via un .htaccess .

Le robot ne trouvera pas tout seul le login / mot de passe.

Tu peux communiquer les login / mot de passe:
- soit de le même mail que celui de l'URL (hummm, pas terrible…)
- soit dans un mail à part
- soit par téléphone/SMS/autre

Attention, l'authentification du .htaccess n'est pas chiffrée, dont le mot de passe peut être récupérer par un sniffer de trames IP. Mais ici, il s'agit "juste" d'éviter les robots de Google, donc cela sera suffisant.

J'ai déjà observé de fort ralentissements réseaux, même l'ICMP/ping ne passait presque plus, lors de l'utilisation de clé USB. Le phénomène est arrivé après quelques mises à jours de ma Debian Testing.

J'ai changé pas mal de choses, tant hardware que software sur ma machine, et depuis je ne rencontre plus ce problème.