ben dans ce cas, tu évites de laisser un boot graphique et on en parle plus.
Raison pour laquelle j'ai écrit "Personnellement, je préfère qu'il (le BIOS, l'OS, ...) affiche quelque chose"
Tu es un nerd.
Non, je suis le gars qui répare quotidiennement des machines industrielles dont les minutes d'arrêt se compte en centaines d'euros de perte. Donc le diagnostique rapide et efficace est mon boulot. Si le BIOS ou le boot de l'OS peut m'indiquer un problème dès le démarrage, c'est du temps gagné.
Les gens normaux veulent juste que ça marche, et en joli de préférence.
Les gens normaux n'en n'ont rien à faire de ce qu'il s'affiche sur leur écran au démarrage de leur machine. Ils veulent juste un "truc" pour se connecter à Internet. Si le "truc" est capable de démarrer sans trop attendre, ils sont content.
C'est que le geek qui va s'extasier d'avoir une quelconque animation lors du boot de sa machine.
Et après on s'étonne que Linux ne perce pas sur le desktop...
- Parles-en avec des "vrai" utilisateurs, qui ne connaissent rien à l'informatique. Tu comprendras pourquoi Linux ne perce pas sur le desktop.
- Parles-en avec des utilisateurs qui s'y connaissent un peu en informatique (mais qui font croire à leur entourage qu'ils la maitrisent). Tu comprendras pourquoi ils ne veulent pas que Linux ne perce pas sur le desktop.
- Et pour ceux qui s'y connaissent réellement en informatique, ils ne sont pas nombreux et ont déjà fait leur choix et n'en bougerons pas.
C'est très bien de ne pas afficher un truc moche (la console) à l'utilisateur, il ne demande que ça plutôt qu'un truc moche qu'il n'utilise jamais.
Personnellement, je préfère qu'il affiche quelque chose : En cas de fsck au démarrage, tu sais au moins exactement pourquoi la machine n'avance pas, et combien de temps il lui reste avant de finir.
Et puis, si il y a des turcs "anormaux" dans le boot (les scripts d'init), au moins on s'en rend compte très vite.
parfois quand même caché par une image de boot sur les CM pas trop à l'arrache
Là encore, je préfère voir ce qu'indique le BIOS. Si une barrette de mémoire ou un périphérique de stockage a des problèmes, on s'en rend compte plus vite. Et puis, sur une machine que l'on ne connaît pas (dépannage d'un ami), cela permet de trouver immédiatement (vu que cela s'affiche), les touches de pre-post BIOS intéressantes : Rentrer dans le BIOS (généralement supp, mais parfois c'est F1, F2, ...), changer la séquence de boot (parfois F12, F10, F8, ...).
Et il n'y a pas d'option, de touche à appuyer, pour afficher le menu de rescue?
Si cela existe, cela ne s'affiche pas clairement au démarrage.
J'ai regardé un peu vite, mais il me semble que le /boot/grub/grub.cfg est conçu pour ne rien afficher du tout au démarrage, et booter sans poser de question sur le "default=0". GRUB2 a en effet un mode d'utilisation de ce type.
Sous l'OS du mal, c'est simple (Ctrl de tête, je l'utilise très rarement mais retrouve à chaque fois)
Sous Windows XP, c'est "F8". C'était aussi le cas pour les Windows 2K, et 95/98 il me semble...
Pour les autres versions, je n'ai pas eu l'occasion de trop en torturer pour le tester... ;)
Si vous utilisez le driver de nvidia, le boot ne fonctionnera plus, mais par contre vous aurez les effets 3D.
Là, ce n'est pas (que) la faute d'Ubuntu, mais de Debian. Sur mes Debian Squeeze/Testing, j'ai ce bug depuis bien 6 mois (".run" pour les drivers NVIDIA, et kernel 2.6.32).
Le problème est apparu avec l'intégration des drivers "nouveau" dans le kernel, et de leur activation dès la phase de chargement du kernel.
Le GRUB_CMDLINE_LINUX_DEFAULT="quiet vga=791" dans /etc/default/grub corrige le problème, mais il faut surtout fait un "blacklist nouveau" dans le "/etc/modprobe.d/00local.conf", et relancer la génération du initrd (dpkg-reconfigure initramfs-tools)
Par exemple, pour thttpd, Il faut avoir l'idée d'aller modifier le contenu de /etc/default/thttpd pour l'activer. Apparemment c'est le seul comme ça. /etc/default à l'air d'être un peu l'équivalent de /etc/sysconfig ailleurs.
Sur Debian en effet (Ubuntu en est dérivé), on ne modifie pas les fichiers du /etc/init.d/* afin de configurer les services. Les scripts d'init sont configurés pour charger les préférences utilisateurs dans /etc/default/ . Cela surprend un peu au début, mais c'est finalement assez pratique.
D'une manière générale, Debian essaye de toujours séparer les fichiers de configurations par défaut, et ceux des utilisateurs. Ainsi, les paquets peuvent modifier "sans risques"(*) leurs fichiers de configuration, les spécificités de l'utilisateur n'étant pas touchées
(*): Pour certains services cependant, comme /etc/samba/smb.conf, les configurations utilisateurs ne sont pas séparés de celles par défaut. L'installeur du paquet propose alors soit de fusionner au mieux les deux configuration, soit de laisser la configuration initiale, ou encore de mettre en place la nouvelle configuration par défaut.
J'ai installé la 10.10 dans une VirtualBox, et je n'ai pas vu de menu GRUB2 au démarrage. Cela part directement sur le démarrage du kernel. Par contre, dans GDM il il y a des options permettant de passe en mode console.
Personnellement, ne pas avoir mon menu GRUB2 au démarrage m'a posé problème, car j'avais des soucis avec la virtualisation et l'installation des "VirtualGuest" de VirtualBox (Oracle a corrigé le problème dans une nouvelle version apparue 24h après mes tests). Donc je ne pouvais pas booter en mode sans X, et installer les addons de VB comme il fallait.
J'ai dus faire quelques manipulations pas très simples pour voir afficher démarrer en mode rescue, dont le changement du choix du boot par défaut...
Honnêtement, j'ai un peu peur de ce type de comportement dans le cas d'un X qui vautre complètement suite à une mise à jour défectueuse (drivers proprio, Xorg, etc...).
Ne pas pouvoir se connecter simplement et sans X au démarrage peut être pénalisant.
Ne serait-ce que pour ne pas pouvoir pour booter sur un ancien kernel (après une mise à jour du kernel qui s'est mal passée).
Le fait de faire du ssh n est pas une faille de sécurité mais le fait et je l'ai déjà vu d outrepasser la politique de filtrage de ta boite en faisant une connexion SSH via le proxy de la boite qui te permet de te forwarder le port du squid qui tourne sur ton petit serveur Linux a la maison...
Voir mon message plus haut, j'y ai expliqué comment empêcher l'utilisation de SSH
J'arrive un peu après le troll la bataille, mais je vais quand même rajouter mon commentaire:
C'est en effet un proxy MITM... Mais rien avoir avec une attaque... (ca je sais le faire ;)
Vis à vis de l'utilisateur, il y a tromperie, car il pense que son flux SSL ne peut pas être déchiffré, or c'est le cas ici. Je pense que c'est le genre de chose qui devrait être clairement affiché dans la charte informatique de la société, celle que l'employé signe en disant qu'il s'engage à ne pas faire mauvaise usage du système informatique. Mais par contre, il y a fort à parier qu'une telle charte soit dénoncée devant un tribunal.
Que l'admin système (ou son équipe IT), détourne ou non l'usage "sécurité" de ce proxy est un autre débat : Grand groupe ou petite société, ce sont au final toujours des être humains qui ont entre les mains des données sensibles. Et parfois, elles les utilisent à mauvais escient.
pour le fait que ce soit installé dans chaque navigateur: étonnant il y avait 200000 utilisateurs!
Alors là, aucun soucis. Exemple de techniques de déployment :
- installation de ce CA à distance, en "poussant" un patch sécurité
- utilisation de WMI pour modifier automatiquement la configuration des postes clients
- modification de la configuration, en utilisant le script de login de la machine
- ou plus simplement encore : Rajout du CA dans l'image disque des machines, en parallèle des xxx applications utilisés par cette entreprise.
Le fait que les users puissent utiliser ton proxy pour se connecter chez eux en SSH ça ce n'est pas secure!
Il faut :
- contrôller les applications installées sur la machine
- limiter les droits d'accès aux machines
- etc...
Le moindre firewall applicatif est capable d'empêcher une application qui ne serait pas dans une "white list" de se connecter à un réseau. Il suffit de définir la liste des ces applis, avec leur somme MD5/autre, afin d'empêcher un client SSH de se connecter
Après un utilisateur peut toujours sortir sa clé USB/live CD pour passer outre l'OS de la société. Dans ce cas-là, un par-feu identifiant, comme http://fr.wikipedia.org/wiki/NuFW bloquera ce live-OS non autorisé
Donc j'aimerais 2 minutes mettre les questions de "pseudos-ethiques" de côté et réfléchir à la solution technique qui pourrait remplacer un outil commercial par une solution opensource...
Idées en vrac (je précise que je ne cautionne pas ce qui est fait ici):
- pour le détournement de la requête au CA (Verisign, ou autre), il faut changer la configuration du DNS (bind9 ou autre)
- pour simuler automatiquement le CA, je ne vois pas trop. J'imagine que cela peut se faire avec un serveur Apache, plus des scripts de génération de certificat à la volée. Ou du moins : Génération d'un certificat lors de la première demande, et sauvegarde de celui-ci sur le serveur. Aux prochaines demandes, on ira piocher dans la "base de certificats" déjà généré
- pour la phase déchiffrement / chiffrement, il faut là probablement encore passer par un serveur web, qui se chargera de cela. Mais c'est du boulot...
Avec les machines actuelle qui ont beaucoup de ram, j'ai l'impression que le swap est nettement moins utile qu'avant.
Encore qu'avec l'omniprésence du web, on peut se demander si le placement de la partition accueillant le cache des navigateurs (/var/tmp ou /tmp) n'est pas plus important.
Cependant je me demande si le mécanisme d'hibernation n'évite justement pas de sauver le cache disque avant d'hiberner (ce qui en soit est une bonne idée, car cela ne sert pas à grand chose d'hiberner le cache).
J'ai lancé la commande "free" avant et après hibernation :
Avant
total used free shared buffers cached
Mem: 4149980 2816232 1333748 0 20856 2507080
-/+ buffers/cache: 288296 3861684
=> 2Go de mémoire utilisé par le cache
Après
total used free shared buffers cached
Mem: 4149980 363984 3785996 0 2868 172244
-/+ buffers/cache: 188872 3961108
=> 172Mo de mémoire utilisé par le cache (j'ai un script de sortie d'hibernation qui lance plusieurs commandes avant de lancer le "free")
Conclusion : En sortie d'hibernation, il y a moins de mémoire vive utilisée par le cache disque, ce qui amène à penser que l'hibernation ne sauve pas le cache.
Du moment que l'on ne maîtrise ni le serveur DNS, ni le moyen de certification, le proxy / homme du milieu, peut signer tout les certificats qu'il veut, et faire son boulot d'interception.
Mais ce genre de pratique est quand même sacrément malhonnête de la part de l'admin réseau...
La seule solution que je vois pour éviter une telle interception, dans le cas par exemple de l'utilisation d'un wifi publique sur lequel on pourrait avoir ce genre de mécanisme d'homme du milieu:
- utiliser un DNS "externe" bien précis (pas celui qui est fournit par le serveur DHCP). Mais la solution n'est pas 100% fiable, car le hotspot wifi peut très bien intercepter et modifier les requêtes DNS
- ET de n'utiliser que des certificats de CA dans lesquels on a confiance. Donc surtout ne pas accepter des certificats qui viennent de cette connexion wifi.
Sur ma machine princpale (Desktop), j'utilise l'hibernate tout les jours. Mais récemment, je me suis amusé à y toucher, et j'ai pas mal eu de soucis pour retrouver un truc qui marche.
Voici des astuces (testées sous Debian Squeeze/Testing) :
- Commencer par virer tout les trucs permettant le joli boot graphique. Le plus simple est de virer le "splash" dans le /boot/grub/grub.cfg
- évidement, il faut avoir le paquet "hibernate" d'installé
- pour toutes les modifications ci-dessous de /etc/hibernate/*, il faut re-générer le "vmlinuz", en utilisant "dpkg-reconfigure update-initramfs" ou "update-initramfs -u -k all". Parfois, ce n'est pas la peine, mais bon...
- le paramètre "SuspendDevice swap:/dev/sdaXX" permet d'indiquer la position du swap. Il est parfois nécessaire de le configurer, si le mécanisme de vmlinuz/initramfs n'y arrive pas
- il existe 2 modes d'hibernation : ususpend et sysfs. Parfois l'un marche, parfois c'est l'autre. On contrôle le mécanisme que l'on utiliser via "/etc/hibernate/disk.conf", en commentant celui que l'on ne veut pas :
# This file is used when suspending to disk. Use the *-disk.conf files to add
# configuration options, or add them before the TryMethod lines in this file.
# Options are not case-sensitive.
#
# See hibernate.conf(5) for help on the configuration items.
Chez moi, "ususpend-disk.conf" affiche un joli pourcentage d'avancement de l'hibernation, mais il ne fait pas d'arrêt électrique de la machine.
"sysfs-disk.conf" n'affiche pas de progression, mais fait l'arrêt électrique...
On peut forcer la manière dont le système s'arrêt, via l'option "PowerdownMethod" . Chez moi :
PowerdownMethod shutdown
Les différents options disponibles sont dans :
$ cat /sys/power/disk
platform test testproc [shutdown] reboot
- pour ceux qui comme moi utilise les drivers proprio NVIDIA (no comment...), il faut désactiver le "blacklistage" du driver dans "/etc/hibernate/blacklisted-modules"
$ less /etc/hibernate/blacklisted-modules
#nvidia
- Enfin, pour arriver à débugger l'hibernation, rien ne vaut de le faire en mode ligne de commande, avec affichage des logs :
hibernate -v 3
La valeur du "-v " permet de définir le niveau de verbosité
- A noter que les options "LogFile" et "LogVerbosity" permettent d'écrire les logs d'hibernation dans un fichier de log, si l'on n'a pas le temps de tout lire à l'écran :
$ grep -ir log /etc/hibernate/
/etc/hibernate/common.conf:# LogFile /var/log/hibernate.log
/etc/hibernate/common.conf:# LogVerbosity 1
/etc/hibernate/common.conf:# LogTimestamp yes
A noter que l'on peut sérieusement booster l'hibernation / retour d'hibernation, en jouant sur 2 paramètres :
- la compression du fichier d'hibernation : Nos CPU sont actuellement suffisamment puissant pour que le temps "perdu" à compresser l'image soit gagné par le plus petit volume de données à écrire sur le disque. Et pour la décompression, celle-ci prend encore moins de temps. Option "Compressor lzf" dans /etc/hibernate/
- la position du swap : Sous Linux, et contrairement à Windows, le fichier d'hibernation est stocké dans le SWAP, ce qui a 2 avantages :
- pas besoin d'avoir 2 fichiers swap et hibernation sur le "C:"
- et surtout, pas de fragmentation du fichier d'hibernation (puisque le swap est une partition)
Mais surtout, il convient d'optimiser la vitesse de lecture / écriture du swap, et pour cela, de placer le swap AU DEBUT du disque dur. Donc, en /dev/sda1.
J'ai personnellement testé les perfs d'un disque dur de 1To avec la commande "dd. J'ai mesuré 100Mo/s en début de disque, et seulement 50Mo/s en fin de disque.
Bien entendu, la présence d'une partition swap en début de disque peut être pénible, dans le cas des BIOS qui sont encore affectés du problème des "1024 cyclindres". Dans cas :
- pour une machine Linux seul, on crée un "/boot" de disons 200Mo en /dev/sda1, puis le swap en /dev/sda2, et le / en /dev/sda3
- pour une machine en dualboot, il n'y a généralement pas d'autres choix que de placer Windows en /dev/sda1, et le swap en /sda/sda2. Si nécessaire, on fera un "C:" Windows assez petit, seulement pour le système, et on placera le gros du "Program Files" en "D:", avec le "Documents and Settings", le tout, après le swap Linux.
J'utilise SLIM sur mes machines en Debian Squeeze/Testing depuis longtemps, mais j'ai toujours 2 bugs chiants :
- le "/etc/init.d/slim stop" n'arrive pas à arrêter SLIM. Soit il faut le lancer 2 fois, soit il faut le tuer à la main
- si je le relance depuis un tty (ctrl+alt+f1), alors systématiquement, lorsque j'utilise ce tty-là, j'ai des caractères qui ne sont pas affichés. C'est assez déroutant. Je dois alors ouvrir un autre tty (ctrl+alt+f2), et là je n'ai pas de problème
La MoFo vient de trouver un accord avec Debian sur la problématique des marques. Ainsi Firefox va pouvoir revenir, avec son nom et ses icones, dans Debian.
C'est une info intéressante, tu as un lien là-dessus ? On trouve beaucoup de page que la "rupture" de Debian et Mozilla, avec la création des des "Ice" applications http://en.wikipedia.org/wiki/Mozilla_Corporation_software_re(...) , mais rien sur cette "réconciliation".
J'ai eu le même problème lorsque j'ai ugradé une machine qui était déjà en Squeeze, qui n'avait pas eu de mise à jour depuis quelques mois (la machine n'est pas connecté au réseau, et la Debian installé dessus est l'OS de secours).
J'avais écrit ceci à l'époque :
Aussi, voici ce que je vous recommande lorsque vous faites des
"grosses" mises à jour (à chaque fois, le système doit se débrouiller
pour mettre à jour les dépendances) :
- mise à jour des paquets d'installation : aptitude install aptitude
- mise à jour du kernel : aptitude install linux-image-xxxx
example : "linux-image-686-bigmem"
- reboot de la machine, sur le nouveau kernel bien sûr...
- mise à jour du démon SSH, ou des outils de prise en main à distance (pour ceux qui en ont besoin) : aptitude install openssh-server
reboot de la machine UNIQUEMENT si tout s'est bien passé
- on peut alors envoyer le gros des mises à jour : aptitude full-upgrade --without-recommends
Le xhost c'est bien pratique, mais les risques ne se situent pas que au niveau de Xorg.
En effet, skype ainsi lancé à accès à tout le réseau de la machine, dont notamment :
- les connexions à Internet, où il peut envoyer ce qu'il veut. Bon, ca c'est connu depuis longtemps
- les connexions aux réseau local : 192.168.x.x, 10.x.x.x : Donc, attention si il y a un partage de fichiers NFS, SMB, FTP, ou autre qui n'a pas de mot de passe
- les connexions réseaux localhost (127.0.0.1). Là, c'est encore plus délicat, car cette interface est généralement moins sécurisé (c'est assez rare que l'on se pirate soit-même). Donc, si il y a du portmap, SMTP, SMB, ou autre en localhost, Skype peut aussi y acceder
=> Pour réduire les risques, on peut mettre en place un filtrage netfilter / iptables, qui restreint les accès à un certain utilisateur (ici "sandbox"). Voir , rechercher http://linux.die.net/man/8/iptables --uid-owner ou --gid-owner
Enfin, c'est évident mais il faut le souligner, skype a aussi accès au / : Donc:
- attentions aux périphériques externes montées dans le /media/
- attention aux montages réseaux (SMB, NFS, ...) montés généralement dans le /mnt/
- attention bien sur au /home, dont il faut proteger les accès
- /tmp est aussi assez critique, car généralement autorisé en écriture pour tout le monde...
- enfin, d'autres répertoires (/root, /etc avec son passwd notamment), sont aussi sensibles.
=> Pour tout ces répertoires, un bon usages des droits d'accès UNIX aux fichiers (chown, chmod, ...) permet de limiter les problèmes.
A la rigueur, il serait préférable de faire tourner Skype dans un environnement virtualisé, comme VirtualBox. Mais cela ne résout pas tout les problèmes.
tu veux les drivers nvidia ta l'impression d'installer Iter dans ton jardin … En plus t'as pas intérêt a prendre la derniere CG à la mode à 400€ car ça marche pas ou si mais comme une 3DFX …
Rien ne t'empêche d'installer le dernier ".run" de NVIDIA sur ta Debian Squeeze/Testing ou Sid : Tu es un power-user, donc tu sauras bien relancer le dir ".run"à chaque upgrade du kernel.
Personnellement, c'est ce que je fais sur les machines que j'installe, et ca marche très bien.
Du coup quand firefox4 sort en beta en français toi ta la beta de Iceweasel 3.6 en anglais dans experimental
Là encore, tu peux installer dans ton /usr/local/ le dernier .tgz tout compilé de Mozilla . Ca marche aussi très bien.
Dans les deux cas, tu dois faire les mises à jours de ces softs à la main. Mais en temps que power-user, tu y arriveras sans problème... ;)
Tu peux visiter un site en mettant le site lui-même en referant.
Cela n'aura pas d'influence sur ta vie privée, car le site n'aura pas connaissance du lien dont tu viens. Le site estimera que tu es arrivé directement sur la page en question, en tapant l'URL complète à la main (ou en utilisant un bookmark)
Sans forcément désactiver le http-referrer, il "suffit" que le site web (exemple ici avec LinuxFR) applique la configuration suivante :
- pas de http-referrer -> Pas d'image affichée, ou renvoi vers une image de 1x1 pixel, ou message d'avertissement
- http-referrer de linuxfr.org -> Affichage des images normal
- http-referrer d'autre chose -> Affichage d'une image aléatoire, ou de quelque chose de plus "provoquant"
Personnellement, j'utilise privoxy pour, par défaut, cacher le http-referer. Certains sites n'apprécient pas, et le disent clairement lorsque l'on visite les pages. Il suffit alors de rajouter une règle dans privoxy :
Pour se faire un avis rapide sur le soft, sans avoir à se pallucher des heures de lecture de code (et encore faut-il en avoir les connaissances), d'autant pour Chromium qui semble particulièrement "lourd", il est en effet plus rapide de faire appel aux applis externes (strace, tcpdump/wirshark, etc...).
Evidement, ce n'est qu'une première approche rapide du problème. Mais si il s'agit comme ici de savoir si oui ou non Chromium discute avec Google, cela s'avère suffisant.
Après, il est toujours possible (je n'ai pas dit "facile") de patcher/forker Chrominum pour éliminer les codes de discussion avec Google. Mais c'est du gros boulot.
Personnellement, je préfère utiliser un autre navigateur, même si celui-ci est plus lent (dixtit le journal de Patrick G : http://linuxfr.org/~patrick_g/30163.html )
bref chromium c'est juste une recompilation de chrome (et moi qui croyais que certaines briques étaient virées, pas seulement celles pas libres éventuellement par rapport à chrome mais aussi celles qui concerne la vie privée)
N'étant ni un utilisateur de Chome ni de Chromium, j'aimerai savoir ce qu'en pense les utilisateurs de Chromium : Est-il vrai que ce dernier fait comme son "grand frère", et qu'il communique lui aussi avec Google ? Mise à part peut-être pour les mises à jour des bases de données anti-phishing ?
J'avoue que je ne suis que moyennent motivé par utiliser un navigateur qui communique avec son créateur, même si c'est de nature (parfaitement ?) anonyme (envoie des URL visitées par exemple).
Par contre 192.168.2.1/24 ne veut rien dire, même si on en comprends la signification. Le dernier bit est à 1 mais le masque indique qu'on n'en tient pas compte. Il est plus propre d'écrire 192.168.2.0
Oui et non.
Pour un /24, je suis assez d'accord avec toi (c'est plus "propre" d'écrire ".0"). Mais pour un /25 (et les valeurs supérieures), le dernier chiffre de l'adresse IP est primordial.
Example : un /25 sur un réseau en 192.168.0.xx
Ici, il y a donc 2 sous-réseaux :
- 192.168.0.0/25
+ Plage d'adresses IP: 192.168.0.1 à 192.168.0.126
+ Adresse de broadcast : 192.168.0.127
+ Masque de sous réseau : 255.255.255.128
- 192.168.0.128/25
+ Plage d'adresses IP: 192.168.0.129 à 192.168.0.254
+ Adresse de broadcast : 192.168.0.255
+ Masque de sous réseau : 255.255.255.128
Evidement, on peut reproduire ce mécanisme avec un /26, /27, etc..., mais aussi avec des /23, /22, /21, etc...
N'est-ce pas étonnant d'utiliser de l'ext 3/4 sur un hardware qui utilise une mémoire flash ?
Il me semblait que pour ce type de support, qui n'apprécie pas les ré-écriture successives toujours au même endroit, n'est pas adapté aux ext 3/4, à cause justement de la journalisation. A moins que ces systèmes de fichiers soient monté sans journalisation, mais l'intérêt est plus faible, non ?
- Si ton réseau local est un "hub", ou un switch bien foireux, alors les personnes sur le même brin réseau que toi peuvent espionner tout ton trafic réseau
- Plus loin, sur les gros switch/routeur du réseau local, l'admin réseau peut employer des "sondes" sur ses équipement, afin d'analyser les trafics qui passent par ceux-ci
- Au niveau de la "porte de sortie" de ton réseau local, ton administrateur réseau peut là encore installer une sonde
- Et si il utilise un proxy transparent, cela arrive souvent, les logs de celui-ci peuvent lui donner toutes les informations qu'il veut
- Plus loin sur le réseau, les fournisseurs d'accès, hébergeurs, noeuds de connexions divers et variés, peuvent aussi analyser ce qui les intéresse.
- On parle actuellement pas mal du DPI (Deep Packet Inspection), à propos notamment de la loie HADOPI. D'après http://www.pcinpact.com/actu/news/59106-hadopi-dpi-vedicis-s(...) , il y a depuis 2 ans des tests qui se font en grandeur nature dans ce sens-là. Le DPI, est clairement destiné a analyser du trafic, et est soit-disant destiné à lutter contre, je cite, le "piratage d'oeuvres culturels". Mais on pourrait très bien l'utiliser pour surveiller tes commentaires sur LinuxFR
- Enfin, il est toujours possible d'installer des mouchards, tant sur ta machine cliente que sur la machine serveur. Ceux-ci peuvent alors avoir accès au contenu déchiffré des pages HTTPS, ce qui est plus problématique.
[^] # Re: GRUB
Posté par Olivier (site web personnel) . En réponse à la dépêche Ubuntu 42, la réponse universelle aux besoins de Madame Michu. Évalué à 3.
Raison pour laquelle j'ai écrit "Personnellement, je préfère qu'il (le BIOS, l'OS, ...) affiche quelque chose"
[^] # Re: GRUB
Posté par Olivier (site web personnel) . En réponse à la dépêche Ubuntu 42, la réponse universelle aux besoins de Madame Michu. Évalué à 4.
Non, je suis le gars qui répare quotidiennement des machines industrielles dont les minutes d'arrêt se compte en centaines d'euros de perte. Donc le diagnostique rapide et efficace est mon boulot. Si le BIOS ou le boot de l'OS peut m'indiquer un problème dès le démarrage, c'est du temps gagné.
Les gens normaux veulent juste que ça marche, et en joli de préférence.
Les gens normaux n'en n'ont rien à faire de ce qu'il s'affiche sur leur écran au démarrage de leur machine. Ils veulent juste un "truc" pour se connecter à Internet. Si le "truc" est capable de démarrer sans trop attendre, ils sont content.
C'est que le geek qui va s'extasier d'avoir une quelconque animation lors du boot de sa machine.
Et après on s'étonne que Linux ne perce pas sur le desktop...
- Parles-en avec des "vrai" utilisateurs, qui ne connaissent rien à l'informatique. Tu comprendras pourquoi Linux ne perce pas sur le desktop.
- Parles-en avec des utilisateurs qui s'y connaissent un peu en informatique (mais qui font croire à leur entourage qu'ils la maitrisent). Tu comprendras pourquoi ils ne veulent pas que Linux ne perce pas sur le desktop.
- Et pour ceux qui s'y connaissent réellement en informatique, ils ne sont pas nombreux et ont déjà fait leur choix et n'en bougerons pas.
[^] # Re: GRUB
Posté par Olivier (site web personnel) . En réponse à la dépêche Ubuntu 42, la réponse universelle aux besoins de Madame Michu. Évalué à 4.
Personnellement, je préfère qu'il affiche quelque chose : En cas de fsck au démarrage, tu sais au moins exactement pourquoi la machine n'avance pas, et combien de temps il lui reste avant de finir.
Et puis, si il y a des turcs "anormaux" dans le boot (les scripts d'init), au moins on s'en rend compte très vite.
parfois quand même caché par une image de boot sur les CM pas trop à l'arrache
Là encore, je préfère voir ce qu'indique le BIOS. Si une barrette de mémoire ou un périphérique de stockage a des problèmes, on s'en rend compte plus vite. Et puis, sur une machine que l'on ne connaît pas (dépannage d'un ami), cela permet de trouver immédiatement (vu que cela s'affiche), les touches de pre-post BIOS intéressantes : Rentrer dans le BIOS (généralement supp, mais parfois c'est F1, F2, ...), changer la séquence de boot (parfois F12, F10, F8, ...).
Et il n'y a pas d'option, de touche à appuyer, pour afficher le menu de rescue?
Si cela existe, cela ne s'affiche pas clairement au démarrage.
J'ai regardé un peu vite, mais il me semble que le /boot/grub/grub.cfg est conçu pour ne rien afficher du tout au démarrage, et booter sans poser de question sur le "default=0". GRUB2 a en effet un mode d'utilisation de ce type.
Sous l'OS du mal, c'est simple (Ctrl de tête, je l'utilise très rarement mais retrouve à chaque fois)
Sous Windows XP, c'est "F8". C'était aussi le cas pour les Windows 2K, et 95/98 il me semble...
Pour les autres versions, je n'ai pas eu l'occasion de trop en torturer pour le tester... ;)
[^] # Re: Ma première expérience avec Ubuntu
Posté par Olivier (site web personnel) . En réponse à la dépêche Ubuntu 42, la réponse universelle aux besoins de Madame Michu. Évalué à 2.
Là, ce n'est pas (que) la faute d'Ubuntu, mais de Debian. Sur mes Debian Squeeze/Testing, j'ai ce bug depuis bien 6 mois (".run" pour les drivers NVIDIA, et kernel 2.6.32).
Le problème est apparu avec l'intégration des drivers "nouveau" dans le kernel, et de leur activation dès la phase de chargement du kernel.
Le GRUB_CMDLINE_LINUX_DEFAULT="quiet vga=791" dans /etc/default/grub corrige le problème, mais il faut surtout fait un "blacklist nouveau" dans le "/etc/modprobe.d/00local.conf", et relancer la génération du initrd (dpkg-reconfigure initramfs-tools)
Par exemple, pour thttpd, Il faut avoir l'idée d'aller modifier le contenu de /etc/default/thttpd pour l'activer. Apparemment c'est le seul comme ça. /etc/default à l'air d'être un peu l'équivalent de /etc/sysconfig ailleurs.
Sur Debian en effet (Ubuntu en est dérivé), on ne modifie pas les fichiers du /etc/init.d/* afin de configurer les services. Les scripts d'init sont configurés pour charger les préférences utilisateurs dans /etc/default/ . Cela surprend un peu au début, mais c'est finalement assez pratique.
D'une manière générale, Debian essaye de toujours séparer les fichiers de configurations par défaut, et ceux des utilisateurs. Ainsi, les paquets peuvent modifier "sans risques"(*) leurs fichiers de configuration, les spécificités de l'utilisateur n'étant pas touchées
(*): Pour certains services cependant, comme /etc/samba/smb.conf, les configurations utilisateurs ne sont pas séparés de celles par défaut. L'installeur du paquet propose alors soit de fusionner au mieux les deux configuration, soit de laisser la configuration initiale, ou encore de mettre en place la nouvelle configuration par défaut.
[^] # Re: Inutile d'essayer la version netbook dans VirtualBox
Posté par Olivier (site web personnel) . En réponse à la dépêche Ubuntu 42, la réponse universelle aux besoins de Madame Michu. Évalué à 3.
La dernière version de VB corrige ce problème
Peut-être que ton problème y est lié...
[^] # Re: GRUB
Posté par Olivier (site web personnel) . En réponse à la dépêche Ubuntu 42, la réponse universelle aux besoins de Madame Michu. Évalué à 2.
Personnellement, ne pas avoir mon menu GRUB2 au démarrage m'a posé problème, car j'avais des soucis avec la virtualisation et l'installation des "VirtualGuest" de VirtualBox (Oracle a corrigé le problème dans une nouvelle version apparue 24h après mes tests). Donc je ne pouvais pas booter en mode sans X, et installer les addons de VB comme il fallait.
J'ai dus faire quelques manipulations pas très simples pour voir afficher démarrer en mode rescue, dont le changement du choix du boot par défaut...
Honnêtement, j'ai un peu peur de ce type de comportement dans le cas d'un X qui vautre complètement suite à une mise à jour défectueuse (drivers proprio, Xorg, etc...).
Ne pas pouvoir se connecter simplement et sans X au démarrage peut être pénalisant.
Ne serait-ce que pour ne pas pouvoir pour booter sur un ancien kernel (après une mise à jour du kernel qui s'est mal passée).
[^] # Re: Bizarre, bizarre
Posté par Olivier (site web personnel) . En réponse au message Solution pour filtrer du contenu HTTPS. Évalué à 2.
Voir mon message plus haut, j'y ai expliqué comment empêcher l'utilisation de SSH
[^] # Re: Bizarre, bizarre
Posté par Olivier (site web personnel) . En réponse au message Solution pour filtrer du contenu HTTPS. Évalué à 8.
C'est en effet un proxy MITM... Mais rien avoir avec une attaque... (ca je sais le faire ;)
Vis à vis de l'utilisateur, il y a tromperie, car il pense que son flux SSL ne peut pas être déchiffré, or c'est le cas ici. Je pense que c'est le genre de chose qui devrait être clairement affiché dans la charte informatique de la société, celle que l'employé signe en disant qu'il s'engage à ne pas faire mauvaise usage du système informatique. Mais par contre, il y a fort à parier qu'une telle charte soit dénoncée devant un tribunal.
Que l'admin système (ou son équipe IT), détourne ou non l'usage "sécurité" de ce proxy est un autre débat : Grand groupe ou petite société, ce sont au final toujours des être humains qui ont entre les mains des données sensibles. Et parfois, elles les utilisent à mauvais escient.
2 exemples récemment dans l'actualité informatique :
- un employé de facebook a utilisé ses droits d'accès privilégiés pour connaître l'identité d'un client : http://www.infos-du-net.com/actualite/17513-vie-privee.html
- des employés de SFR auraient exploités illégalement des codes de desimlockage : http://www.generation-nt.com/fraude-reseau-codes-desimlockag(...)
pour le fait que ce soit installé dans chaque navigateur: étonnant il y avait 200000 utilisateurs!
Alors là, aucun soucis. Exemple de techniques de déployment :
- installation de ce CA à distance, en "poussant" un patch sécurité
- utilisation de WMI pour modifier automatiquement la configuration des postes clients
- modification de la configuration, en utilisant le script de login de la machine
- ou plus simplement encore : Rajout du CA dans l'image disque des machines, en parallèle des xxx applications utilisés par cette entreprise.
Le fait que les users puissent utiliser ton proxy pour se connecter chez eux en SSH ça ce n'est pas secure!
Il faut :
- contrôller les applications installées sur la machine
- limiter les droits d'accès aux machines
- etc...
Le moindre firewall applicatif est capable d'empêcher une application qui ne serait pas dans une "white list" de se connecter à un réseau. Il suffit de définir la liste des ces applis, avec leur somme MD5/autre, afin d'empêcher un client SSH de se connecter
Après un utilisateur peut toujours sortir sa clé USB/live CD pour passer outre l'OS de la société. Dans ce cas-là, un par-feu identifiant, comme http://fr.wikipedia.org/wiki/NuFW bloquera ce live-OS non autorisé
Donc j'aimerais 2 minutes mettre les questions de "pseudos-ethiques" de côté et réfléchir à la solution technique qui pourrait remplacer un outil commercial par une solution opensource...
Idées en vrac (je précise que je ne cautionne pas ce qui est fait ici):
- pour le détournement de la requête au CA (Verisign, ou autre), il faut changer la configuration du DNS (bind9 ou autre)
- pour simuler automatiquement le CA, je ne vois pas trop. J'imagine que cela peut se faire avec un serveur Apache, plus des scripts de génération de certificat à la volée. Ou du moins : Génération d'un certificat lors de la première demande, et sauvegarde de celui-ci sur le serveur. Aux prochaines demandes, on ira piocher dans la "base de certificats" déjà généré
- pour la phase déchiffrement / chiffrement, il faut là probablement encore passer par un serveur web, qui se chargera de cela. Mais c'est du boulot...
[^] # Re: Quelques idées
Posté par Olivier (site web personnel) . En réponse au journal Ubuntu, top c'est trop. Évalué à 2.
Encore qu'avec l'omniprésence du web, on peut se demander si le placement de la partition accueillant le cache des navigateurs (/var/tmp ou /tmp) n'est pas plus important.
C'est effectivement une bonne idée,
[^] # Re: Quelques idées
Posté par Olivier (site web personnel) . En réponse au journal Ubuntu, top c'est trop. Évalué à 4.
Cependant je me demande si le mécanisme d'hibernation n'évite justement pas de sauver le cache disque avant d'hiberner (ce qui en soit est une bonne idée, car cela ne sert pas à grand chose d'hiberner le cache).
J'ai lancé la commande "free" avant et après hibernation :
Avant
total used free shared buffers cached
Mem: 4149980 2816232 1333748 0 20856 2507080
-/+ buffers/cache: 288296 3861684
=> 2Go de mémoire utilisé par le cache
Après
total used free shared buffers cached
Mem: 4149980 363984 3785996 0 2868 172244
-/+ buffers/cache: 188872 3961108
=> 172Mo de mémoire utilisé par le cache (j'ai un script de sortie d'hibernation qui lance plusieurs commandes avant de lancer le "free")
Conclusion : En sortie d'hibernation, il y a moins de mémoire vive utilisée par le cache disque, ce qui amène à penser que l'hibernation ne sauve pas le cache.
[^] # Re: Bizarre, bizarre
Posté par Olivier (site web personnel) . En réponse au message Solution pour filtrer du contenu HTTPS. Évalué à 6.
Du moment que l'on ne maîtrise ni le serveur DNS, ni le moyen de certification, le proxy / homme du milieu, peut signer tout les certificats qu'il veut, et faire son boulot d'interception.
Mais ce genre de pratique est quand même sacrément malhonnête de la part de l'admin réseau...
La seule solution que je vois pour éviter une telle interception, dans le cas par exemple de l'utilisation d'un wifi publique sur lequel on pourrait avoir ce genre de mécanisme d'homme du milieu:
- utiliser un DNS "externe" bien précis (pas celui qui est fournit par le serveur DHCP). Mais la solution n'est pas 100% fiable, car le hotspot wifi peut très bien intercepter et modifier les requêtes DNS
- ET de n'utiliser que des certificats de CA dans lesquels on a confiance. Donc surtout ne pas accepter des certificats qui viennent de cette connexion wifi.
[^] # Re: Hibernation
Posté par Olivier (site web personnel) . En réponse au journal Ubuntu, top c'est trop. Évalué à 4.
Voici des astuces (testées sous Debian Squeeze/Testing) :
- Commencer par virer tout les trucs permettant le joli boot graphique. Le plus simple est de virer le "splash" dans le /boot/grub/grub.cfg
- évidement, il faut avoir le paquet "hibernate" d'installé
- pour toutes les modifications ci-dessous de /etc/hibernate/*, il faut re-générer le "vmlinuz", en utilisant "dpkg-reconfigure update-initramfs" ou "update-initramfs -u -k all". Parfois, ce n'est pas la peine, mais bon...
- le paramètre "SuspendDevice swap:/dev/sdaXX" permet d'indiquer la position du swap. Il est parfois nécessaire de le configurer, si le mécanisme de vmlinuz/initramfs n'y arrive pas
- il existe 2 modes d'hibernation : ususpend et sysfs. Parfois l'un marche, parfois c'est l'autre. On contrôle le mécanisme que l'on utiliser via "/etc/hibernate/disk.conf", en commentant celui que l'on ne veut pas :
# This file is used when suspending to disk. Use the *-disk.conf files to add
# configuration options, or add them before the TryMethod lines in this file.
# Options are not case-sensitive.
#
# See hibernate.conf(5) for help on the configuration items.
#TryMethod ususpend-disk.conf
TryMethod sysfs-disk.conf
Chez moi, "ususpend-disk.conf" affiche un joli pourcentage d'avancement de l'hibernation, mais il ne fait pas d'arrêt électrique de la machine.
"sysfs-disk.conf" n'affiche pas de progression, mais fait l'arrêt électrique...
On peut forcer la manière dont le système s'arrêt, via l'option "PowerdownMethod" . Chez moi :
PowerdownMethod shutdown
Les différents options disponibles sont dans :
$ cat /sys/power/disk
platform test testproc [shutdown] reboot
- pour ceux qui comme moi utilise les drivers proprio NVIDIA (no comment...), il faut désactiver le "blacklistage" du driver dans "/etc/hibernate/blacklisted-modules"
$ less /etc/hibernate/blacklisted-modules
#nvidia
- Enfin, pour arriver à débugger l'hibernation, rien ne vaut de le faire en mode ligne de commande, avec affichage des logs :
hibernate -v 3
La valeur du "-v " permet de définir le niveau de verbosité
- A noter que les options "LogFile" et "LogVerbosity" permettent d'écrire les logs d'hibernation dans un fichier de log, si l'on n'a pas le temps de tout lire à l'écran :
$ grep -ir log /etc/hibernate/
/etc/hibernate/common.conf:# LogFile /var/log/hibernate.log
/etc/hibernate/common.conf:# LogVerbosity 1
/etc/hibernate/common.conf:# LogTimestamp yes
[^] # Re: Quelques idées
Posté par Olivier (site web personnel) . En réponse au journal Ubuntu, top c'est trop. Évalué à 2.
- la compression du fichier d'hibernation : Nos CPU sont actuellement suffisamment puissant pour que le temps "perdu" à compresser l'image soit gagné par le plus petit volume de données à écrire sur le disque. Et pour la décompression, celle-ci prend encore moins de temps. Option "Compressor lzf" dans /etc/hibernate/
- la position du swap : Sous Linux, et contrairement à Windows, le fichier d'hibernation est stocké dans le SWAP, ce qui a 2 avantages :
- pas besoin d'avoir 2 fichiers swap et hibernation sur le "C:"
- et surtout, pas de fragmentation du fichier d'hibernation (puisque le swap est une partition)
Mais surtout, il convient d'optimiser la vitesse de lecture / écriture du swap, et pour cela, de placer le swap AU DEBUT du disque dur. Donc, en /dev/sda1.
J'ai personnellement testé les perfs d'un disque dur de 1To avec la commande "dd. J'ai mesuré 100Mo/s en début de disque, et seulement 50Mo/s en fin de disque.
Bien entendu, la présence d'une partition swap en début de disque peut être pénible, dans le cas des BIOS qui sont encore affectés du problème des "1024 cyclindres". Dans cas :
- pour une machine Linux seul, on crée un "/boot" de disons 200Mo en /dev/sda1, puis le swap en /dev/sda2, et le / en /dev/sda3
- pour une machine en dualboot, il n'y a généralement pas d'autres choix que de placer Windows en /dev/sda1, et le swap en /sda/sda2. Si nécessaire, on fera un "C:" Windows assez petit, seulement pour le système, et on placera le gros du "Program Files" en "D:", avec le "Documents and Settings", le tout, après le swap Linux.
[^] # Re: Rolling Release attitude
Posté par Olivier (site web personnel) . En réponse au journal Ubuntu, top c'est trop. Évalué à 1.
- le "/etc/init.d/slim stop" n'arrive pas à arrêter SLIM. Soit il faut le lancer 2 fois, soit il faut le tuer à la main
- si je le relance depuis un tty (ctrl+alt+f1), alors systématiquement, lorsque j'utilise ce tty-là, j'ai des caractères qui ne sont pas affichés. C'est assez déroutant. Je dois alors ouvrir un autre tty (ctrl+alt+f2), et là je n'ai pas de problème
[^] # Re: -
Posté par Olivier (site web personnel) . En réponse au journal Firefox & Bing (Take the Money and Run (c'est un très bon Woody Allen)). Évalué à 2.
C'est une info intéressante, tu as un lien là-dessus ? On trouve beaucoup de page que la "rupture" de Debian et Mozilla, avec la création des des "Ice" applications http://en.wikipedia.org/wiki/Mozilla_Corporation_software_re(...) , mais rien sur cette "réconciliation".
# Même problème pendant une upgrade "standard"
Posté par Olivier (site web personnel) . En réponse au journal Upgrade de Lenny à Squeeze à la coyote.... Évalué à 3.
J'avais écrit ceci à l'époque :
Aussi, voici ce que je vous recommande lorsque vous faites des
"grosses" mises à jour (à chaque fois, le système doit se débrouiller
pour mettre à jour les dépendances) :
- mise à jour des paquets d'installation :
aptitude install aptitude
- mise à jour du kernel :
aptitude install linux-image-xxxx
example : "linux-image-686-bigmem"
- reboot de la machine, sur le nouveau kernel bien sûr...
- mise à jour du démon SSH, ou des outils de prise en main à distance (pour ceux qui en ont besoin) :
aptitude install openssh-server
reboot de la machine UNIQUEMENT si tout s'est bien passé
- on peut alors envoyer le gros des mises à jour :
aptitude full-upgrade --without-recommends
# Sécurité vis à vis du réseau, et tout particulièrement de localhost
Posté par Olivier (site web personnel) . En réponse au message Utiliser Skype en toute sécurité. Évalué à 7.
En effet, skype ainsi lancé à accès à tout le réseau de la machine, dont notamment :
- les connexions à Internet, où il peut envoyer ce qu'il veut. Bon, ca c'est connu depuis longtemps
- les connexions aux réseau local : 192.168.x.x, 10.x.x.x : Donc, attention si il y a un partage de fichiers NFS, SMB, FTP, ou autre qui n'a pas de mot de passe
- les connexions réseaux localhost (127.0.0.1). Là, c'est encore plus délicat, car cette interface est généralement moins sécurisé (c'est assez rare que l'on se pirate soit-même). Donc, si il y a du portmap, SMTP, SMB, ou autre en localhost, Skype peut aussi y acceder
=> Pour réduire les risques, on peut mettre en place un filtrage netfilter / iptables, qui restreint les accès à un certain utilisateur (ici "sandbox"). Voir , rechercher http://linux.die.net/man/8/iptables --uid-owner ou --gid-owner
Enfin, c'est évident mais il faut le souligner, skype a aussi accès au / : Donc:
- attentions aux périphériques externes montées dans le /media/
- attention aux montages réseaux (SMB, NFS, ...) montés généralement dans le /mnt/
- attention bien sur au /home, dont il faut proteger les accès
- /tmp est aussi assez critique, car généralement autorisé en écriture pour tout le monde...
- enfin, d'autres répertoires (/root, /etc avec son passwd notamment), sont aussi sensibles.
=> Pour tout ces répertoires, un bon usages des droits d'accès UNIX aux fichiers (chown, chmod, ...) permet de limiter les problèmes.
A la rigueur, il serait préférable de faire tourner Skype dans un environnement virtualisé, comme VirtualBox. Mais cela ne résout pas tout les problèmes.
[^] # Re: Oui mais …
Posté par Olivier (site web personnel) . En réponse au journal Zoom sur la récente Debian 5.0.6. Évalué à 5.
Rien ne t'empêche d'installer le dernier ".run" de NVIDIA sur ta Debian Squeeze/Testing ou Sid : Tu es un power-user, donc tu sauras bien relancer le dir ".run"à chaque upgrade du kernel.
Personnellement, c'est ce que je fais sur les machines que j'installe, et ca marche très bien.
Du coup quand firefox4 sort en beta en français toi ta la beta de Iceweasel 3.6 en anglais dans experimental
Là encore, tu peux installer dans ton /usr/local/ le dernier .tgz tout compilé de Mozilla . Ca marche aussi très bien.
Dans les deux cas, tu dois faire les mises à jours de ces softs à la main. Mais en temps que power-user, tu y arriveras sans problème... ;)
[^] # Re: Vol de bande passante
Posté par Olivier (site web personnel) . En réponse à la dépêche De l'utilisation abusive des images des autres et du vol de bande passante. Évalué à 1.
Cela n'aura pas d'influence sur ta vie privée, car le site n'aura pas connaissance du lien dont tu viens. Le site estimera que tu es arrivé directement sur la page en question, en tapant l'URL complète à la main (ou en utilisant un bookmark)
[^] # Re: Vol de bande passante
Posté par Olivier (site web personnel) . En réponse à la dépêche De l'utilisation abusive des images des autres et du vol de bande passante. Évalué à 1.
- pas de http-referrer -> Pas d'image affichée, ou renvoi vers une image de 1x1 pixel, ou message d'avertissement
- http-referrer de linuxfr.org -> Affichage des images normal
- http-referrer d'autre chose -> Affichage d'une image aléatoire, ou de quelque chose de plus "provoquant"
Personnellement, j'utilise privoxy pour, par défaut, cacher le http-referer. Certains sites n'apprécient pas, et le disent clairement lorsque l'on visite les pages. Il suffit alors de rajouter une règle dans privoxy :
{ -hide-referrer }
linuxfr.org
[^] # Re: Données personnelles....
Posté par Olivier (site web personnel) . En réponse à la dépêche Pas de Chromium pour Debian Squeeze. Évalué à 3.
Evidement, ce n'est qu'une première approche rapide du problème. Mais si il s'agit comme ici de savoir si oui ou non Chromium discute avec Google, cela s'avère suffisant.
Après, il est toujours possible (je n'ai pas dit "facile") de patcher/forker Chrominum pour éliminer les codes de discussion avec Google. Mais c'est du gros boulot.
Personnellement, je préfère utiliser un autre navigateur, même si celui-ci est plus lent (dixtit le journal de Patrick G : http://linuxfr.org/~patrick_g/30163.html )
# Données personnelles....
Posté par Olivier (site web personnel) . En réponse à la dépêche Pas de Chromium pour Debian Squeeze. Évalué à 5.
La lecture de ceci me rend un peu perplexe http://linuxfr.org//comments/1161641.html#1161641 :
bref chromium c'est juste une recompilation de chrome (et moi qui croyais que certaines briques étaient virées, pas seulement celles pas libres éventuellement par rapport à chrome mais aussi celles qui concerne la vie privée)
N'étant ni un utilisateur de Chome ni de Chromium, j'aimerai savoir ce qu'en pense les utilisateurs de Chromium : Est-il vrai que ce dernier fait comme son "grand frère", et qu'il communique lui aussi avec Google ? Mise à part peut-être pour les mises à jour des bases de données anti-phishing ?
J'avoue que je ne suis que moyennent motivé par utiliser un navigateur qui communique avec son créateur, même si c'est de nature (parfaitement ?) anonyme (envoie des URL visitées par exemple).
[^] # Re: CIDR
Posté par Olivier (site web personnel) . En réponse au message Configuration ignore IP de fail2ban. Évalué à 3.
Oui et non.
Pour un /24, je suis assez d'accord avec toi (c'est plus "propre" d'écrire ".0"). Mais pour un /25 (et les valeurs supérieures), le dernier chiffre de l'adresse IP est primordial.
Example : un /25 sur un réseau en 192.168.0.xx
Ici, il y a donc 2 sous-réseaux :
- 192.168.0.0/25
+ Plage d'adresses IP: 192.168.0.1 à 192.168.0.126
+ Adresse de broadcast : 192.168.0.127
+ Masque de sous réseau : 255.255.255.128
- 192.168.0.128/25
+ Plage d'adresses IP: 192.168.0.129 à 192.168.0.254
+ Adresse de broadcast : 192.168.0.255
+ Masque de sous réseau : 255.255.255.128
Evidement, on peut reproduire ce mécanisme avec un /26, /27, etc..., mais aussi avec des /23, /22, /21, etc...
# Ext 3/4 ?
Posté par Olivier (site web personnel) . En réponse à la dépêche Sortie de CyanogenMod 6. Évalué à 3.
Il me semblait que pour ce type de support, qui n'apprécie pas les ré-écriture successives toujours au même endroit, n'est pas adapté aux ext 3/4, à cause justement de la journalisation. A moins que ces systèmes de fichiers soient monté sans journalisation, mais l'intérêt est plus faible, non ?
A moins que l'on compte sur le http://fr.wikipedia.org/wiki/Wear_levelling , afin de limiter la casse ?
Personnellement, pour les clés USB que je format en ext, je choisi toujours le ext2...
# Beaucoup trop de monde peut y avoir accès...
Posté par Olivier (site web personnel) . En réponse au message HTTPS sur linuxfr. Évalué à 10.
- Plus loin, sur les gros switch/routeur du réseau local, l'admin réseau peut employer des "sondes" sur ses équipement, afin d'analyser les trafics qui passent par ceux-ci
- Au niveau de la "porte de sortie" de ton réseau local, ton administrateur réseau peut là encore installer une sonde
- Et si il utilise un proxy transparent, cela arrive souvent, les logs de celui-ci peuvent lui donner toutes les informations qu'il veut
- Plus loin sur le réseau, les fournisseurs d'accès, hébergeurs, noeuds de connexions divers et variés, peuvent aussi analyser ce qui les intéresse.
- On parle actuellement pas mal du DPI (Deep Packet Inspection), à propos notamment de la loie HADOPI. D'après http://www.pcinpact.com/actu/news/59106-hadopi-dpi-vedicis-s(...) , il y a depuis 2 ans des tests qui se font en grandeur nature dans ce sens-là. Le DPI, est clairement destiné a analyser du trafic, et est soit-disant destiné à lutter contre, je cite, le "piratage d'oeuvres culturels". Mais on pourrait très bien l'utiliser pour surveiller tes commentaires sur LinuxFR
- Enfin, il est toujours possible d'installer des mouchards, tant sur ta machine cliente que sur la machine serveur. Ceux-ci peuvent alors avoir accès au contenu déchiffré des pages HTTPS, ce qui est plus problématique.