Par exemple si je chiffre un volume (avec LUKS) rempli avec /dev/zero au préalable (dans lequel il n'y a qu'un fichier texte contenant 4 caractères), c'est l'intégralité du disque qui est chiffré (et pas uniquement le fichier texte).
1) Lorsque tu lances ta commande de création du volume chiffré ("cryptsetup luksFormat …."), tu notes qu'il ne faut que quelques secondes pour que le programme te rende la main. Cela veut dire que "cryptsetup" n'a écrit que quelques octets sur le disque, à savoir les informations de chiffrement. La grande majorité du disque, elle, n'a pas été touchée, donc ton disque est toujours plein de de zéro.
2) Après avoir monté ton volume chiffré, et avant sa première utilisation, tu vas devoir le formater (en ext4 par exemple, mais tu peux aussi mettre du FAT32, NTFS, brtfs, etc …). Dans le cas de l'ext4, cela donnerait "mkfs.ext4 /dev/mapper/xxxxx". La commande en question va alors écrire quelques blocs de donnés sur le disque (ce que l'on appelle des "inodes"), que luks va bien entendu chiffrer.
3) Si on analysé le disque après cela, que voit t'on ? Beaucoup de zero, et éparpillé à des endroits bien précis, des blocs de données chiffrés, mais dont la taille et le nombre peuvent d'identifier que ce sont des blocs d'inodes, et donc, que le volume chiffré est formaté en ext4.
4) Si tu connais des éléments de signatures précis du système de fichiers (la structure des blocs d'inode est quelque chose de donnu), alors tu peux comparer ces signatures aux données chiffrés. Cela peut t'aider à déchiffré le volume complet.
5) Conclusion: remplir le disque dur de données aléatoires permet de rendre plus difficile l'identification des blocs connus du volume chiffré.
Pour faire simple, dans une utilisation combinée de ssh + ("screen" ou "tmux"), ces derniers se coupaient lorsque que la connexion SSH tombait. Le "coupable" était une option de systemd activée par défaut dans Debian (en testing et +).
Debian a rapidement corrigé le tir, en revenant au comportement par défaut de /etc/systemd/logind.conf .
Je ne nie pas la nécessité de mettre en place un mécanisme de déchiffrement du SSL, du moins au niveau des entreprises.
Ce qui me gène, c'est que l'utilisateur est mal informé du fait que le SSL va être cassé, déchiffré, et les données éventuellement stockées pour une post-analyse.
Peu de personnes savent que le "petit cadenas" dans le navigateur veut dire que la connexion est sécurisée. Mais maintenant, il faut expliquer à ces rare personnes que non, la présence du cadenas ne suffit pas, et qu'il faut vérifier le "Root certificat". C'est nettement moins simple… :(
Aussi, je pense que lorsqu'une entreprise se livre à du déchiffrement SSL, il faudrait que le proxy SSL rajoute à la volée un morceau de code HTM/Javascript à la 1ère page, afin d'afficher une popup, ou un bandeau du style de ceux qui s'affiche actuellement "le site sur lequel vous surfez contient des cookies". Histoire qu'avant de taper son login/password, l'utilisateur se dise "Tiens, je vais me faire piquer mon mot de passe, je vais peut-être ne pas le faire".
lorsque le proxy déchiffre, il s'agit de l'AC interne, sinon c'est une AC "reconnnue" (Gandi, Commodo, Thawte, Verisign, let's Encrypt, …)
C'est ce que je pensais faire initialement, mais rien n'empêche l'admin de se créer un certificat root qui s'appellerait "Verisign", "Thawte", ou autre, et qu'il utilise pour signer tout les sites.
Ou utiliser un nom très proche, comme "Verisig*m*".
D'où l'idée d'utiliser un site web externe qui permette de comparer le certificat officiel avec ce qu'affiche le navigateur.
Si je prends l'exemple de ma machine pro, sous Windows 7, je remarque que depuis quelques mois le ventilateur tourne presque tout le temps.
La raison : la poussière. Avec le temps, la poussière s'accumule dans la machine, et réduit l'efficacité de la dissipation thermique.
Solution : Ouvrir la machine, avec un portable cela peut-être pénible, et tout dépoussiérer.
Tu peux aussi en profiter pour changer la pâte thermique des CPU et GPU.
Le facteur-risque est trop important par rapport à mes besoins :
- je ne suis pas contre avoir des softs à jours, mais pas au point d'attendre la toute dernière version
- si je dois attendre 10 jours pour que le paquet descende de unstable à testing, je peux faire avec.
L'autre critère important, pour moi, est que je gère les machines des membres de ma famille, d'amis, de collègues de boulot etc … Et la plus grand partie se fait par SSH. Afin d'assurer un support correct, il est plus facile pour moi de ne travaille que sur une seule version, donc j'ai mis tout le monde en Testing.
Donc dans ce cas-là, c'est pas mal si j'ai une version qui "stabilisée" pendant quelques jours, avant que je ne fasse des déploiement de mises à jours.
Depuis une dizaine d'années, je n'utilise que des Debian Testing sur toutes mes machines (usages perso, mais j'ai aussi différentes machines qui font serveurs).
J'apprécie le "rolling release" qui permet de faire évoluer l'OS par petites touches, et d'avoir des softs "assez" à jour.
De temps en temps, il y a un petit truc qui casse (il y a quelques jours, c'était "krunner"), mais c'est souvent corrigé quelques jours plus tard.
Lorsqu'une upgrade modifie un comportement d'un soft (nouvelle interprétation des fichiers de conf par exemple), c'est seulement le soft en question qui est planté, ce qui laisse le temps de le réparer. Alors que pour les distributions qui font des upgrades majeurs tous les 6 mois ou xx ans, on peut se retrouver à devoir réparer plusieurs softs en même temps après l'upgrade, ce qui est assez pénible.
Conclusion : Je préfère avoir des "petits problèmes" plus ou moins souvent, que de grosses galères tous les 6 mois.
En terme d'utilisation:
- j'ai un XFCE en plus de KDE sur ma machine principale. Si KDE est planté par des mises à jours, je peux continuer à travailler sur un desktop alternatif
- mon déport principal est en testing, mais il m'arrive de saupoudrer la machine de paquets "unstable" ou "experimentale", en utilisant le "Pinning" : http://jaqque.sbih.org/kplug/apt-pinning.html : La machine fonctionne en "testing", mais je peux lui forcer l'installation d'un paquet unstable ("aptitude install -t unstable firefox-esr" pour installer le Firefox d'Unstable). L'avantage, c'est que le gestionnaire de paquets ne téléchargera de unstable, que les paquets strictement nécessaires.
- lorsque le niveau de stabilité de ma machine principale est satisfaisant, je mets à jour mes autres machines.
Conclusion:
- "Testing" nécessite d'avoir un minimum de connaissances de Linux, et de ne pas avoir peur de fouiller dans les forums, ou de trouver soit-même une solution.
- Je trouve que c'est ce qui fait son charme, puisque cela permet de s'autoformer en réparant les trucs qui cassent. Tout en ayant un minimum de risque de tout casser (unstable & experimental).
- Un bémol cependant : Le volume des mises à jour. En mise à jour hebdomadaire, une Debian Testing c'est environ 200Mo chaque semaine. Et en mensuelle, il font compter 1Go par mois. Si tu as une connexion ADSL moyenne/faible (1Mb/s ou 128Ko/s), il vaut mieux évier , ou être patient…
Au démarrage, on ne voit plus les logs du kernel et les services qui démarrent.
C'est lié au paramètre "quiet" qui est passé au kernel.
Tu as 2 solutions:
- tu veux temporairement voir les lignes de services. Lorsque GRUB2 s'affiche, tu edites les paramètres du menu que tu sélectionnes (ctrl+…), et tu supprimes le mot "quiet" de la ligne "linux ….". Cette modification ne sera pris en compte que pour ce boot-là. Au prochain reboot, les lignes seront de nouveau cachées.
- tu veux systématiquement afficher les lignes de services. Edites le /etc/default/grub, et supprimes le paramètre "quiet". Puis, lances un "update-grub2", et rebootes la machine.
Je ne suis pas sûr que cela puisse être lié à ton problème, mais tu pourrais vérifier quel est l'alignement des partitions ?
Sur une machine récente, les blocs de données font généralement 4K (4096 octets), au lieu de 512 octets (héritage des premiers PC). Donc il est préférable que toutes les partitions commencent par un multiple de 4K. Si ce n'est pas le cas, les perfs peuvent êtres sérieusement dégradés.
Chez moi :
fdisk -l /dev/sda
Disque /dev/sda : 59,6 GiB, 64023257088 octets, 125045424 secteurs
Unités : secteur de 1 × 512 = 512 octets
Taille de secteur (logique / physique) : 512 octets / 512 octets
taille d'E/S (minimale / optimale) : 512 octets / 512 octets
Type d'étiquette de disque : dos
Identifiant de disque : 0x762214ee
Périphérique Amorçage Début Fin Secteurs Taille Id Type
/dev/sda1 2048 63162367 63160320 30,1G 83 Linux
/dev/sda2 63162368 125044735 61882368 29,5G 83 Linux
J'ai des blocs de 512 octets, mais ils sont quand même aligné sur du 4K (512 * 2048 / 4096 = 256)
Sous Linux, si tu veux installer un paquet (.deb, .rpm, …), il faut en effet être root/administrateur. C'est normal, c'est la cohérence des paquets installés sur la machine qui en dépendant.
Par contre, rien ne t'empêche:
de télécharger des sources du logiciel, de les compiler, et de les installer dans ton /home/riendf/soft/
ou, si l'admin n'a pas installé de compilo, tu peux aussi installer ton propre compilo dans ton /home
ou alors, tu peux compiler les sources sur une tierce machine, et les transférer sur ton /home
il existe des softs Linux qui, à partir d'un exécutable, sont capable de t'extraire toutes les dépendances du soft (librairies), et te générer une arborescence de fichiers, que tu pourras transférer sur la machine dont tu n'as pas les droits d'administrtation
afin de forcer un programme à utiliser les librairies de ton /home, à la place de celles du système, il y a un mécanisme très simple : LD_LIBRARY_PATH . Exemple:
export LD_LIBRARY_PATH=/home/riendf/soft/lib/
/home/riendf/soft/bin/le_programme_que_tu_veux_lancer
Là où cela peut devenir pénible, c'est si le programme utilise des chemins hard-codés, comme par exemple pour écrire un fichier de log dans /var/log/ , alors que seul le root est supposé faire cela (*). Mais généralement, les programmes permettent de changer les chemins hard-codés, via des paramètres en ligne de commande, ou un option d'un fichier de configuration.
En fait, ce sur quoi les droits root vont vraiment te manquer, c'est si tu veux lancer un programme qui va ouvrir un port inférieur à 1024, comme par exemple un serveur web (ports 80 et 443). Ca oui, c'est la chasse gardée du root (*).
Mais les programmes ne sont pas stupides, ils proposent généralement de changer les ports par défauts. Par exemple dans le serveur web Apache, c'est une ligne de configuration qui permet de changer le port d'écoute, afin d'écouter sur le classique "8888" (ou autre) à la place du "80".
(*): Certains programmes non-root peuvent le faire, mais c'est parce qu'ils ont été initialement lancés par le root, qui l'a ensuite délégué à un utilisateur spécifique. Exemple très classique : L'utilisateur "www-data" qui exécute le process Apache.
Dans pavucontrol, est-ce que'il n'y a pas un icone, du genre haut-parleur barré, qui indique que la sortie audio est désactivé ?
Lorsque tu lances une vidéo / piste musicale, est-ce que pavuncontrol affiche le nom de l'applie, avec une réglette de niveau sonore, que tu peux modifier ?
Enfin, est-ce que tu as essayé les touches audio de ton clavier, afin de monter / descendre /mute / un-mute le son ? Normalement, en utilisant cela, du devrait voir un icone de haut-parleur qui s'affiche brièvement à l'écran.
soit lancer "pavucontrol", une interface graphique pour PulseAudio https://doc.ubuntu-fr.org/pavucontrol , qui permet de changer la priorité des deux sorties son (et faire plein d'autres trucs …).
tu peux booter sur un LiveCD d'une distribution récente, Ubuntu ou autre, et voir si elle détecte ton disque chiffré.
Si ce n'est pas le cas, utilise le mécanisme de package de cette distrib afin d'installer (dans le ramdrive qui aura été créé), les paquets cryptkeeper. Attention, au prochain reboot du LiveCD, il te faudra réinstaller les paquets, donc tu as intérêt à tout faire en une seule fois….
Une fois que le disque externe est ouvert, tu dois pouvoir aussi ouvrir le disque dur interne de ta machine. Il te sera alors facile de copier les fichiers du disque externe sur le disque interne.
Je créé régulièrement des clès USB bootables à 3 partitions (2 partitions ext4 et une partition NTFS), afin de permettre à mes utilisateurs d'avoir 1) un environnement Linux en bootant un PC sur la clé et 2) de pouvoir sauver, sur la partition NTFS, des fichiers depuis un Windows ou un Linux, qui soit visible par l'autre OS.
J'ai observé que Windows (XP, Seven) à parfois un problème avec les clés multi-partition, spécialement si le numéro de la la partition NTFS/FAT se trouve "après" un numéro de partition qu'il ne connaît pas (une partition Linux). Dans certains cas, Windows propose tout simplement de formater les partitions Linux, si celles-ci se trouve "avant" une partition Windows… Sympa… :(
Aussi, j'ai trouvé une astuce : Créer les partitions Linux en DEBUT de clé, mais avec un ID qui ne soit pas "1". Cela se fait facilement avec "fdisk".
# fdisk -l /dev/sdc
Disque /dev/sdc : 14,9 GiB, 15938355200 octets, 31129600 secteurs
Unités : secteur de 1 × 512 = 512 octets
Taille de secteur (logique / physique) : 512 octets / 512 octets
taille d'E/S (minimale / optimale) : 512 octets / 512 octets
Type d'étiquette de disque : dos
Identifiant de disque : 0x6a0a84e2
Périphérique Amorçage Début Fin Secteurs Taille Id Type
/dev/sdc1 10487808 31129599 20641792 9,9G 7 HPFS/NTFS/exFAT
/dev/sdc2 * 2048 9218047 9216000 4,4G 83 Linux
/dev/sdc3 9218048 10487807 1269760 620M 83 Linux
Ici, on voit que:
- afin de faciliter le boot, la partition système Linux (4.4Go) se trouve en début de clé, mais elle a pour ID 2
- pour que Windows ne soit pas perturbé par les partitions Linux, l'ID de la partition NTFS est en 1. Le fait que les partitions ne soient pas dans l'ordre de leur position physique ne pose pas de problème.
sur les vielles machines, il peut être utile de booter le kernel en désactivant certaines fonctionnalités qui sont mal supportées par des matos obsolètes.
lors du boot sur le CDROM, modifie mes paramètres du kernel (utilise "e" ou "tab" pour avoir accès à la ligne de paramètres du kernel, et rajoute ceci :
noapic acpi=noirq libata.noacpi
ou
noapic acpi=noirq libata.force=noncq,1.5Gbps
ou
noapic acpi=off libata.noacpi
ou
noapic acpi=off libata.force=noncq,1.5Gbps
Pour répondre à la question "Sinon à quoi sert l'adresse MAC?" :
L'adresse MAC est un numéro unique qui est définie par le constructeur de la carte réseau. C'est assez bizarre que ce soit lié au BIOS de ta machine, j'en doute, par contre il n'est pas étonnant que le BIOS te montre cette information.
La partie gauche de l'adresse MAC identifie le constructeur de la carte réseau, tandis que la partie droite identifie de manière unique la carte. C'est définie en usine, en programmant une zone de mémoire du contrôleur.
Pour une communication IP, cette adresse MAC est utilisée de cette manière :
- la machine A (IP_A) veut envoyer un paquet à la machine B (IP_B)
- Si A et B ne sont pas dans le même sous réseau, définit par le masque de sous-réseau, alors A va envoyer un message à la passerelle réseau en lui disant "débrouilles-toi pour envoyer ce paquet à IP_B"
- Si A et B sont dans le même sous-réseau :
- A envoie un message 'ARP' qui demande "qui a l'adresse IP IP_B". Le paquet Ethernet ARP contient un broadcast en temps qu'adresse de destination
- B va répondre "Je suis l'adresse IP_B. Mon adresse MAC est x.x.x.x.x.x
- A peut alors remplir un paquet ethernet, qui contient l'adresse MAC de B
- La carte réseau de B écoute tous les messages qui passent sur le réseau. Mais lorsqu'elle en voit un qui contient son adresse MAC, elle l'intercepte, et la fait remonter à l'OS
Résumé :
- l'adresse MAC est utilisé par le hardware, afin d'identifier si un paquet est destiné à la machine
- en IPv4, cette adresse MAC NE sert QUE pour la connexion locale (sans utiliser la passerelle), entre deux machines du même réseau IP
- en IPv6 c'est aussi le cas. Cependant, les adresses IPv6 contiennent généralement aussi l'adresse MAC (partie droite de l'adresse IP), afin de rendre les adresses IP plus "uniques". Effet collatéral : Cela réduit l'anonymat des machines (l'adresse MAC est supposé être unique), mais cela peut se contourner (le kernel Linux peut gérer une adresse IPv6 différente pour chaque transaction IP (du SYN jusqu'au FIN).
Chez un constructeur, il peut se passer un temps assez long entre la création de l'image de disque dans le labo, et celui de la commercialisation de la machine, voir de l'achat par le client.
Entre les deux, il peut y avoir plusieurs "Tuesday patch" de passé, donc la machine à peine sortie de son emballage est déjà non sécurisée, et peu se faire trouer par tous les bots/virus de la terre.
En plus de cela, lorsque le lab va créer l'image du disque, il est possible/probable qu'ils n'appliquent pas tous les patchs de MS, simplement parce qu'ils craignent des incompatibilité entre ces patchs et leurs propres softs (drivers), ou les softs qu'ils vont installer (version d'évaluation d'antivirus, etc…, parfois eux-même non mis à jour). Bref, rien de garanti que l'image qui sort du lab soit elle-même à jour !
un serveur de mail est fait pour distribuer / échanger des courriers. Si tu dis que tu dis que tu veux y accéder via chrome, cela veut dire que tu veux discuter avec un serveur web.
D'après le "It works!", cela veut dire que tu as installé un serveur web "apache" sur la machine. OK, c'est très bien.
Mais pourquoi veux-tu que ce serveur web te fournisse un accès aux mails ? Cela n'est pas le rôle du serveur Apache, ou en tout cas, pas sans une couche logiciel intermédiaire entre le serveur web et le serveur de mail.
Reprends la doc que tu as lu pour arriver à ce résultat, à mon avis, tu as du en oublier un morceau.
# L'intégralité du disque n'est pas chiffré
Posté par Olivier (site web personnel) . En réponse au message Remplir un volume de données aléatoires avant de le chiffrer ?. Évalué à 7.
1) Lorsque tu lances ta commande de création du volume chiffré ("cryptsetup luksFormat …."), tu notes qu'il ne faut que quelques secondes pour que le programme te rende la main. Cela veut dire que "cryptsetup" n'a écrit que quelques octets sur le disque, à savoir les informations de chiffrement. La grande majorité du disque, elle, n'a pas été touchée, donc ton disque est toujours plein de de zéro.
2) Après avoir monté ton volume chiffré, et avant sa première utilisation, tu vas devoir le formater (en ext4 par exemple, mais tu peux aussi mettre du FAT32, NTFS, brtfs, etc …). Dans le cas de l'ext4, cela donnerait "mkfs.ext4 /dev/mapper/xxxxx". La commande en question va alors écrire quelques blocs de donnés sur le disque (ce que l'on appelle des "inodes"), que luks va bien entendu chiffrer.
3) Si on analysé le disque après cela, que voit t'on ? Beaucoup de zero, et éparpillé à des endroits bien précis, des blocs de données chiffrés, mais dont la taille et le nombre peuvent d'identifier que ce sont des blocs d'inodes, et donc, que le volume chiffré est formaté en ext4.
4) Si tu connais des éléments de signatures précis du système de fichiers (la structure des blocs d'inode est quelque chose de donnu), alors tu peux comparer ces signatures aux données chiffrés. Cela peut t'aider à déchiffré le volume complet.
5) Conclusion: remplir le disque dur de données aléatoires permet de rendre plus difficile l'identification des blocs connus du volume chiffré.
# Et 4 mois plus tôt, chez Debian ...
Posté par Olivier (site web personnel) . En réponse au journal systemd: attention à RemoveIPC. Évalué à 2.
Ce problème ressemble à celui-ci, https://linuxfr.org/users/err404/journaux/attention-avec-systemd-tmux-ne-survit-plus-apres-la-fermeture-de-la-session
Pour faire simple, dans une utilisation combinée de ssh + ("screen" ou "tmux"), ces derniers se coupaient lorsque que la connexion SSH tombait. Le "coupable" était une option de systemd activée par défaut dans Debian (en testing et +).
Debian a rapidement corrigé le tir, en revenant au comportement par défaut de /etc/systemd/logind.conf .
[^] # Re: vérifier l'autorité qui a délivré le certificat
Posté par Olivier (site web personnel) . En réponse au message Man in the middle ? Vérifier la validité du SSL. Évalué à 3.
Je ne nie pas la nécessité de mettre en place un mécanisme de déchiffrement du SSL, du moins au niveau des entreprises.
Ce qui me gène, c'est que l'utilisateur est mal informé du fait que le SSL va être cassé, déchiffré, et les données éventuellement stockées pour une post-analyse.
Peu de personnes savent que le "petit cadenas" dans le navigateur veut dire que la connexion est sécurisée. Mais maintenant, il faut expliquer à ces rare personnes que non, la présence du cadenas ne suffit pas, et qu'il faut vérifier le "Root certificat". C'est nettement moins simple… :(
Aussi, je pense que lorsqu'une entreprise se livre à du déchiffrement SSL, il faudrait que le proxy SSL rajoute à la volée un morceau de code HTM/Javascript à la 1ère page, afin d'afficher une popup, ou un bandeau du style de ceux qui s'affiche actuellement "le site sur lequel vous surfez contient des cookies". Histoire qu'avant de taper son login/password, l'utilisateur se dise "Tiens, je vais me faire piquer mon mot de passe, je vais peut-être ne pas le faire".
[^] # Re: vérifier l'autorité qui a délivré le certificat
Posté par Olivier (site web personnel) . En réponse au message Man in the middle ? Vérifier la validité du SSL. Évalué à 2.
C'est ce que je pensais faire initialement, mais rien n'empêche l'admin de se créer un certificat root qui s'appellerait "Verisign", "Thawte", ou autre, et qu'il utilise pour signer tout les sites.
Ou utiliser un nom très proche, comme "Verisig*m*".
D'où l'idée d'utiliser un site web externe qui permette de comparer le certificat officiel avec ce qu'affiche le navigateur.
[^] # Re: Oui oui je saisis un peu mieux...
Posté par Olivier (site web personnel) . En réponse au message Attention ça brûle ! . Évalué à 4.
Ce n'est pas forcément lié à la distribution.
Si je prends l'exemple de ma machine pro, sous Windows 7, je remarque que depuis quelques mois le ventilateur tourne presque tout le temps.
La raison : la poussière. Avec le temps, la poussière s'accumule dans la machine, et réduit l'efficacité de la dissipation thermique.
Solution : Ouvrir la machine, avec un portable cela peut-être pénible, et tout dépoussiérer.
Tu peux aussi en profiter pour changer la pâte thermique des CPU et GPU.
[^] # Re: Pour les utilisateurs qui s'y connaissent un minimum
Posté par Olivier (site web personnel) . En réponse au message Utilisation de debian testing. Évalué à 2.
Le facteur-risque est trop important par rapport à mes besoins :
- je ne suis pas contre avoir des softs à jours, mais pas au point d'attendre la toute dernière version
- si je dois attendre 10 jours pour que le paquet descende de unstable à testing, je peux faire avec.
L'autre critère important, pour moi, est que je gère les machines des membres de ma famille, d'amis, de collègues de boulot etc … Et la plus grand partie se fait par SSH. Afin d'assurer un support correct, il est plus facile pour moi de ne travaille que sur une seule version, donc j'ai mis tout le monde en Testing.
Donc dans ce cas-là, c'est pas mal si j'ai une version qui "stabilisée" pendant quelques jours, avant que je ne fasse des déploiement de mises à jours.
# Pour les utilisateurs qui s'y connaissent un minimum
Posté par Olivier (site web personnel) . En réponse au message Utilisation de debian testing. Évalué à 3.
Depuis une dizaine d'années, je n'utilise que des Debian Testing sur toutes mes machines (usages perso, mais j'ai aussi différentes machines qui font serveurs).
J'apprécie le "rolling release" qui permet de faire évoluer l'OS par petites touches, et d'avoir des softs "assez" à jour.
De temps en temps, il y a un petit truc qui casse (il y a quelques jours, c'était "krunner"), mais c'est souvent corrigé quelques jours plus tard.
Lorsqu'une upgrade modifie un comportement d'un soft (nouvelle interprétation des fichiers de conf par exemple), c'est seulement le soft en question qui est planté, ce qui laisse le temps de le réparer. Alors que pour les distributions qui font des upgrades majeurs tous les 6 mois ou xx ans, on peut se retrouver à devoir réparer plusieurs softs en même temps après l'upgrade, ce qui est assez pénible.
Conclusion : Je préfère avoir des "petits problèmes" plus ou moins souvent, que de grosses galères tous les 6 mois.
En terme d'utilisation:
- j'ai un XFCE en plus de KDE sur ma machine principale. Si KDE est planté par des mises à jours, je peux continuer à travailler sur un desktop alternatif
- mon déport principal est en testing, mais il m'arrive de saupoudrer la machine de paquets "unstable" ou "experimentale", en utilisant le "Pinning" : http://jaqque.sbih.org/kplug/apt-pinning.html : La machine fonctionne en "testing", mais je peux lui forcer l'installation d'un paquet unstable ("aptitude install -t unstable firefox-esr" pour installer le Firefox d'Unstable). L'avantage, c'est que le gestionnaire de paquets ne téléchargera de unstable, que les paquets strictement nécessaires.
- lorsque le niveau de stabilité de ma machine principale est satisfaisant, je mets à jour mes autres machines.
Conclusion:
- "Testing" nécessite d'avoir un minimum de connaissances de Linux, et de ne pas avoir peur de fouiller dans les forums, ou de trouver soit-même une solution.
- Je trouve que c'est ce qui fait son charme, puisque cela permet de s'autoformer en réparant les trucs qui cassent. Tout en ayant un minimum de risque de tout casser (unstable & experimental).
- Un bémol cependant : Le volume des mises à jour. En mise à jour hebdomadaire, une Debian Testing c'est environ 200Mo chaque semaine. Et en mensuelle, il font compter 1Go par mois. Si tu as une connexion ADSL moyenne/faible (1Mb/s ou 128Ko/s), il vaut mieux évier , ou être patient…
[^] # Re: Un an après, qui a changé l'init par défaut ou est passé à une autre distribution ?
Posté par Olivier (site web personnel) . En réponse à la dépêche Debian Jessie, 1 an plus tard. Évalué à 5.
C'est lié au paramètre "quiet" qui est passé au kernel.
Tu as 2 solutions:
- tu veux temporairement voir les lignes de services. Lorsque GRUB2 s'affiche, tu edites les paramètres du menu que tu sélectionnes (ctrl+…), et tu supprimes le mot "quiet" de la ligne "linux ….". Cette modification ne sera pris en compte que pour ce boot-là. Au prochain reboot, les lignes seront de nouveau cachées.
- tu veux systématiquement afficher les lignes de services. Edites le /etc/default/grub, et supprimes le paramètre "quiet". Puis, lances un "update-grub2", et rebootes la machine.
# Alignement ?
Posté par Olivier (site web personnel) . En réponse au message Débit ridicule du disque. Évalué à 4.
Je ne suis pas sûr que cela puisse être lié à ton problème, mais tu pourrais vérifier quel est l'alignement des partitions ?
Sur une machine récente, les blocs de données font généralement 4K (4096 octets), au lieu de 512 octets (héritage des premiers PC). Donc il est préférable que toutes les partitions commencent par un multiple de 4K. Si ce n'est pas le cas, les perfs peuvent êtres sérieusement dégradés.
Chez moi :
fdisk -l /dev/sda
Disque /dev/sda : 59,6 GiB, 64023257088 octets, 125045424 secteurs
Unités : secteur de 1 × 512 = 512 octets
Taille de secteur (logique / physique) : 512 octets / 512 octets
taille d'E/S (minimale / optimale) : 512 octets / 512 octets
Type d'étiquette de disque : dos
Identifiant de disque : 0x762214ee
Périphérique Amorçage Début Fin Secteurs Taille Id Type
/dev/sda1 2048 63162367 63160320 30,1G 83 Linux
/dev/sda2 63162368 125044735 61882368 29,5G 83 Linux
J'ai des blocs de 512 octets, mais ils sont quand même aligné sur du 4K (512 * 2048 / 4096 = 256)
[^] # Re: Compte administrateur ?
Posté par Olivier (site web personnel) . En réponse à la dépêche Nouvelle compilation de logiciels libres pour Windows 64 bits. Évalué à 8.
Lis la 2nd ligne :
Et la 3ème ligne:
Parfois, cela sert de lire jusqu'à la fin les commentaires …
[^] # Re: Compte administrateur ?
Posté par Olivier (site web personnel) . En réponse à la dépêche Nouvelle compilation de logiciels libres pour Windows 64 bits. Évalué à 8. Dernière modification le 18 mai 2016 à 17:02.
Sous Linux, si tu veux installer un paquet (.deb, .rpm, …), il faut en effet être root/administrateur. C'est normal, c'est la cohérence des paquets installés sur la machine qui en dépendant.
Par contre, rien ne t'empêche:
Là où cela peut devenir pénible, c'est si le programme utilise des chemins hard-codés, comme par exemple pour écrire un fichier de log dans /var/log/ , alors que seul le root est supposé faire cela (*). Mais généralement, les programmes permettent de changer les chemins hard-codés, via des paramètres en ligne de commande, ou un option d'un fichier de configuration.
En fait, ce sur quoi les droits root vont vraiment te manquer, c'est si tu veux lancer un programme qui va ouvrir un port inférieur à 1024, comme par exemple un serveur web (ports 80 et 443). Ca oui, c'est la chasse gardée du root (*).
Mais les programmes ne sont pas stupides, ils proposent généralement de changer les ports par défauts. Par exemple dans le serveur web Apache, c'est une ligne de configuration qui permet de changer le port d'écoute, afin d'écouter sur le classique "8888" (ou autre) à la place du "80".
(*): Certains programmes non-root peuvent le faire, mais c'est parce qu'ils ont été initialement lancés par le root, qui l'a ensuite délégué à un utilisateur spécifique. Exemple très classique : L'utilisateur "www-data" qui exécute le process Apache.
[^] # Re: Double sortie son ?
Posté par Olivier (site web personnel) . En réponse au message Problème de son avec debian Jessie. Évalué à 2.
Dans pavucontrol, est-ce que'il n'y a pas un icone, du genre haut-parleur barré, qui indique que la sortie audio est désactivé ?
Lorsque tu lances une vidéo / piste musicale, est-ce que pavuncontrol affiche le nom de l'applie, avec une réglette de niveau sonore, que tu peux modifier ?
Enfin, est-ce que tu as essayé les touches audio de ton clavier, afin de monter / descendre /mute / un-mute le son ? Normalement, en utilisant cela, du devrait voir un icone de haut-parleur qui s'affiche brièvement à l'écran.
# Double sortie son ?
Posté par Olivier (site web personnel) . En réponse au message Problème de son avec debian Jessie. Évalué à 2.
Tu n'aurais pas par hasard une sortie HDMI, qui serait alors considéré par Linux comme une 2nd carte son ?
Tu peux :
- soit jouer avec les paramètres du module, afin de rendre le snd-hda-intel prioritaire. Issue d'une doc pour une autre machine :
https://wiki.debian.org/InstallingDebianOn/Thinkpad/T450s/jessie
Swap HDMI / Analogic audio output order
options snd_hda_intel index=1,0
# Boot sur un LiveCD
Posté par Olivier (site web personnel) . En réponse au message Récupération de documents dans Cryptkeeper. Évalué à 3.
Bonjour,
tu peux booter sur un LiveCD d'une distribution récente, Ubuntu ou autre, et voir si elle détecte ton disque chiffré.
Si ce n'est pas le cas, utilise le mécanisme de package de cette distrib afin d'installer (dans le ramdrive qui aura été créé), les paquets cryptkeeper. Attention, au prochain reboot du LiveCD, il te faudra réinstaller les paquets, donc tu as intérêt à tout faire en une seule fois….
Une fois que le disque externe est ouvert, tu dois pouvoir aussi ouvrir le disque dur interne de ta machine. Il te sera alors facile de copier les fichiers du disque externe sur le disque interne.
# Windows et ordre des partitions
Posté par Olivier (site web personnel) . En réponse au message clé usb avec plusieurs partitions (pour windows). Évalué à 4.
Je créé régulièrement des clès USB bootables à 3 partitions (2 partitions ext4 et une partition NTFS), afin de permettre à mes utilisateurs d'avoir 1) un environnement Linux en bootant un PC sur la clé et 2) de pouvoir sauver, sur la partition NTFS, des fichiers depuis un Windows ou un Linux, qui soit visible par l'autre OS.
J'ai observé que Windows (XP, Seven) à parfois un problème avec les clés multi-partition, spécialement si le numéro de la la partition NTFS/FAT se trouve "après" un numéro de partition qu'il ne connaît pas (une partition Linux). Dans certains cas, Windows propose tout simplement de formater les partitions Linux, si celles-ci se trouve "avant" une partition Windows… Sympa… :(
Aussi, j'ai trouvé une astuce : Créer les partitions Linux en DEBUT de clé, mais avec un ID qui ne soit pas "1". Cela se fait facilement avec "fdisk".
Ici, on voit que:
- afin de faciliter le boot, la partition système Linux (4.4Go) se trouve en début de clé, mais elle a pour ID 2
- pour que Windows ne soit pas perturbé par les partitions Linux, l'ID de la partition NTFS est en 1. Le fait que les partitions ne soient pas dans l'ordre de leur position physique ne pose pas de problème.
[^] # Re: Debian
Posté par Olivier (site web personnel) . En réponse au journal Faille de sécurité dans la GNU libc avec les requêtes DNS. Évalué à 4.
Merci pour l'astuce du lsof !
Ce soir à 20h, Strech est lui aussi patché :
[^] # Re: privoxy
Posté par Olivier (site web personnel) . En réponse au journal Un outil pour gérer une blacklist DNS. Évalué à 3.
Oui, cela existe (je n'ai pas testé) :
https://projects.zubr.me/wiki/adblock2privoxy
http://andrwe.org/scripting/bash/privoxy-blocklist
# Connexion en direct
Posté par Olivier (site web personnel) . En réponse au message Comment découvrir l'ip de la machine sur le réseau ?. Évalué à 3.
Bonjour,
Elle est supposée envoyer une requête ARP, ou une requête DHCP, que tu verras au niveau du sniffe de trames.
# Paramètres du kernel
Posté par Olivier (site web personnel) . En réponse au message demande d'aide svp: LiveCD problème noyau. Évalué à 2.
Bonjour,
sur les vielles machines, il peut être utile de booter le kernel en désactivant certaines fonctionnalités qui sont mal supportées par des matos obsolètes.
noapic acpi=noirq libata.noacpi
ou
noapic acpi=noirq libata.force=noncq,1.5Gbps
ou
noapic acpi=off libata.noacpi
ou
noapic acpi=off libata.force=noncq,1.5Gbps
la définition des paramètres : https://www.kernel.org/doc/Documentation/kernel-parameters.txt
Si cela boot, tu peux redémarrer en ne rajoutant que 1 ou 2 paramètres, afin de voir lequel permet réellement le boot.
A vue de nez, je dirait que le problème vient de l'ACPI
[^] # Re: Alternative : Pipelight
Posté par Olivier (site web personnel) . En réponse au journal flash player à jour avec debian sid. Évalué à 2.
Exact. La version spéciale de Wine qui est chargée est une version 32bit, donc cela nécessite d'avoir du multi-arch.
Sur une Debian c'est facile à activer, mais cela coûte un peu en place disque (quelques dizaines de Mo).
# Adresse MAC : Les bases
Posté par Olivier (site web personnel) . En réponse au message Rapport d'intervention chez Monsieur Tartampion. Évalué à 4.
Pour répondre à la question "Sinon à quoi sert l'adresse MAC?" :
L'adresse MAC est un numéro unique qui est définie par le constructeur de la carte réseau. C'est assez bizarre que ce soit lié au BIOS de ta machine, j'en doute, par contre il n'est pas étonnant que le BIOS te montre cette information.
La partie gauche de l'adresse MAC identifie le constructeur de la carte réseau, tandis que la partie droite identifie de manière unique la carte. C'est définie en usine, en programmant une zone de mémoire du contrôleur.
Pour une communication IP, cette adresse MAC est utilisée de cette manière :
- la machine A (IP_A) veut envoyer un paquet à la machine B (IP_B)
- Si A et B ne sont pas dans le même sous réseau, définit par le masque de sous-réseau, alors A va envoyer un message à la passerelle réseau en lui disant "débrouilles-toi pour envoyer ce paquet à IP_B"
- Si A et B sont dans le même sous-réseau :
- A envoie un message 'ARP' qui demande "qui a l'adresse IP IP_B". Le paquet Ethernet ARP contient un broadcast en temps qu'adresse de destination
- B va répondre "Je suis l'adresse IP_B. Mon adresse MAC est x.x.x.x.x.x
- A peut alors remplir un paquet ethernet, qui contient l'adresse MAC de B
- La carte réseau de B écoute tous les messages qui passent sur le réseau. Mais lorsqu'elle en voit un qui contient son adresse MAC, elle l'intercepte, et la fait remonter à l'OS
Résumé :
- l'adresse MAC est utilisé par le hardware, afin d'identifier si un paquet est destiné à la machine
- en IPv4, cette adresse MAC NE sert QUE pour la connexion locale (sans utiliser la passerelle), entre deux machines du même réseau IP
- en IPv6 c'est aussi le cas. Cependant, les adresses IPv6 contiennent généralement aussi l'adresse MAC (partie droite de l'adresse IP), afin de rendre les adresses IP plus "uniques". Effet collatéral : Cela réduit l'anonymat des machines (l'adresse MAC est supposé être unique), mais cela peut se contourner (le kernel Linux peut gérer une adresse IPv6 différente pour chaque transaction IP (du SYN jusqu'au FIN).
# Alternative : Pipelight
Posté par Olivier (site web personnel) . En réponse au journal flash player à jour avec debian sid. Évalué à 4.
Il existe une alternative qui se base sur une version spécifique de Wine, et qui fait fonctionner le plugin Windows de Flash sous Linux :
Doc :
http://pipelight.net/cms/install/installation-debian.html
Procédure plus récente pour, entre autre, Debian Stretch :
https://github.com/wine-compholio/wine-staging/wiki/Installation#-debian-jessiestretchsid
Autre "avantage" (si l'on a besoin d'autres plugins proprio) : Pipelight gère aussi SilverLight et quelques autres plugins.
[^] # Re: Bots malveillants ?
Posté par Olivier (site web personnel) . En réponse au message Des virus chez lenovo. Évalué à 2.
Chez un constructeur, il peut se passer un temps assez long entre la création de l'image de disque dans le labo, et celui de la commercialisation de la machine, voir de l'achat par le client.
Entre les deux, il peut y avoir plusieurs "Tuesday patch" de passé, donc la machine à peine sortie de son emballage est déjà non sécurisée, et peu se faire trouer par tous les bots/virus de la terre.
En plus de cela, lorsque le lab va créer l'image du disque, il est possible/probable qu'ils n'appliquent pas tous les patchs de MS, simplement parce qu'ils craignent des incompatibilité entre ces patchs et leurs propres softs (drivers), ou les softs qu'ils vont installer (version d'évaluation d'antivirus, etc…, parfois eux-même non mis à jour). Bref, rien de garanti que l'image qui sort du lab soit elle-même à jour !
# Chezmoicamarche
Posté par Olivier (site web personnel) . En réponse au message Partage samba freebox en lecture seule même si monter rw. Évalué à 2.
Bonjour,
chez moi j'ai ceci :
//freebox/Disque\040dur /mnt/freebox cifs rw,auto,uid=1000,gid=1000,credentials=/root/.smbcredentials,iocharset=utf8,sec=ntlm
Où le /root/.smbcredentials contient le login/mdp du compte FTP freebox:
cat ~/.smbcredentials
username=xxxxxx
password=yyyyy
# Serveur de != serveur web
Posté par Olivier (site web personnel) . En réponse au message INTERFACE graphique serveur mail . Évalué à 6.
Bonjour,
un serveur de mail est fait pour distribuer / échanger des courriers. Si tu dis que tu dis que tu veux y accéder via chrome, cela veut dire que tu veux discuter avec un serveur web.
D'après le "It works!", cela veut dire que tu as installé un serveur web "apache" sur la machine. OK, c'est très bien.
Mais pourquoi veux-tu que ce serveur web te fournisse un accès aux mails ? Cela n'est pas le rôle du serveur Apache, ou en tout cas, pas sans une couche logiciel intermédiaire entre le serveur web et le serveur de mail.
Reprends la doc que tu as lu pour arriver à ce résultat, à mon avis, tu as du en oublier un morceau.