Je pense plutôt que ça continu à ouvrir selon le type mime, mais que la définition de celui-ci ne se base que sur l'extension du fichier pour le déterminer.
Faut pas confondre trois choses :
1: Le type MIME qui définit le contenu d'un fichier, genre video/mpeg, image/gif, etc.
2: Les "Magic Numbers" qui sont un moyen d'identifier le contenu d'un fichier (=lui attribuer un type MIME), genre le GIF89a au début d'une image gif, le #! au début d'un script… C'est ce que Linux (entre-autre) utilise, mais pas Windows.
3: L'extension qui est un autre moyen (peu fiable) d'identifier le type d'un fichier et de lui attribuer un type MIME. Utilisé majoritairement par Windows mais aussi sous Linux si le type du fichier n’est pas identifiable par son contenu (chiffré ?) ou si personne ne s'est encore fait chier à spécifier les "Magic infos" (le cas du mp4) ?
Sous Unix les fichiers sont identifiés par leur type MIME et tous les explorateurs de fichiers se basent sur ça.
Si tu veux ouvrir un fichier en te basant sur son extension, il ne te reste plus qu'à créer un nouveau type MIME (genre application/extension-monext) qui match uniquement sur l’extension du fichier.
Je sais que c'est possible, mais je n'ai personnellement jamais modifié à la main la "mimeinfo database".
Ce qui prend le plus de temps c'est le BIOS maintenant.
Et quant le BIOS/EFI/OpenBoot sera enfin de nouveau rapide ou se re-souciera de la performance du système d'init ?
Combien de lignes en C (A comparer au shell) pour un non problème ?
Et grep combien de lignes de C ?
Si on en arrive à un script complexe à la place d'un truc avec trois fonctions (start/stop/reload) et juste deux appels à start-stop-daemon c'est bien qu'on as un "problème" à résoudre non ?
La bonne pratique voudrait que tout les trucs plus complexes que le démarrage d'un service simple où l’exécution d'une configuration basique (l'init c'est pas que du lancement de service) soit placé dans un helper externe, peu importe le langage utilisé, mais vu que les systèmes d'init Unix interprètent le shell on s'est vite retrouvé avec par flemmardise du code bien gruik dans /etc/init.d, ici systemd ne fait qu'imposer une bonne pratique qui aurait dû être la norme bien avant son arrivé !
Microsoft sait qu'il a déjà perdu la guerre des smartphones. Avec Windows 8 il tente de créer son "Android" à lui avec pour marché le tactile et l'embarqué. Objectif ? Gagner de l'argent avec son market et sa régie publicitaire bien-sûr.
Pour Microsoft c'est tout benef, non seulement sur ce marché le hardware verrouillé est la norme, mais en plus il va tirer via sa politique "labellisation" tout les constructeurs sur un marché de machines ARM ou de puissance moindre par rapport aux PC d'aujourd'hui.
On dit que Steam critique Windows 8 à cause du market, mais pas que, Alors qu’aujourd’hui a peu près n'importe-quelle machine vendu dans le commerce peut faire tourner des jeux classiques, Microsoft tourne le marché de façon à rendre la vie difficile aux jeux classiques, pas forcement de clavier ni de capacité 3D très avancés sur l'informatique grand-public de demain, la fragmentation des technologies et des capacités hardwares est une galère pour les développeurs et une chance pour Microsoft qui pourra vendre sa plate-forme x-box aux casual gamers.
Si ça marche tout va être plateformisé, la tablette pour la maison avec 100% des données dans le cloud, la console pour le jeu, une machine à écrire moderne et bien-sûr au hardware verrouillé pour le boulot…
Steam aussi va dans ce sens, son intérêt récent pour Linux montre peut-être les prémices d'un "SteamOS" basé sur Linux et tournant sur du hardware performant et plus proche de ce qu'on connait aujourd’hui (écran séparé, clavier, souris…)
L’embarqué grand-public c'est l'eldorado. Microsoft, Google, Mozilla, Gnome… tous le monde y va.
C'est pourtant un marché difficile, si tu n'a pas assez de parts de marché tu n'attire pas les développeurs et beaucoup de bons sont morts (ou presque) avec comme cause principale le manque d’engouement des développeurs pour leur market.
Le marché du smartphone déjà mature montre qu'il y a peu de places, même le puissant Microsoft peine à y percer.
Un SSD améliore très fortement une partie du boot en réglant le problème des IO (au boot on lit plein de petits fichiers), mais les systèmes de boot "à l’ancienne" comme tu dit, en shell posent un autre problème de performance : l'appel dans les scripts à de nombreux programmes externes (grep, sed, cut) met la pression sur les caches des processeurs et fait énormément chuter les performances.
Je lis plus haut qu'on reproche à systemd d'être un bloatware parce qu'il est capable de remplacer un cron ou un atd, mais l'utilisation de fichiers de configuration et de "helpers" en C plutôt que de faire des scripts 300 lignes qui appellent moult programmes externes pour gérer le choses complexes le rendent systématiquement plus rapide que n'importe-quel système d'init que j'ai croisé.
Anéfé je croyait les fonctions LSB plus riches que ça. Faudrait voir la documentation de Upstart (RHEL 6) si y'a moyen de préciser un "before net", comme sous gentoo, sinon faut jouer à l’ancienne avec les liens dans /etc/rc?.d/SXXnomduscript
/etc/sysconfig/iptables doit contenir les règles courantes, enregistrées par /etc/init.d/iptables save
L'état dans lequel on veut trouver le firewall au démarrage quoi. La procédure que j'utilise sous centOS :
1: Je crée un script iptables (à l’ancienne, mais su tu est familiarisé avec la syntaxe d'iptables-restore tu peux l'utiliser)
2: J’exécute le script
3: Je vérifie que tout convient
4: Je sauvegarde (/etc/init.d/iptables save) pour que ce soit pris en compte à chaque démarrage.
Et si je veux modifier les règles je reprend à partir de 1.
Pourquoi utilise t'on un fichier script dans lequel nous mettons les règles iptables plutôt que dans le fichier par défaut /etc/sysconfig/iptables ?? (je suis sous CentOS)
C'est pas une bonne idée, /etc/sysconfig/iptables est régénéré automatiquement avec les règles en cours quand on fait /etc/init.d/iptables save, jamais une bonne idée de mettre ses configurations perso dans un fichier qui peut être écrasé automatiquement par un script.
On utilise /etc/sysconfig/iptables pour charger automatiquement et de façon atomique les règles iptables au démarrage, mais on stocke sa config perso ailleurs pour modification ultérieure.
Avec Ebtables peut-on utiliser un fichier configuration comme sous iptables /etc/sysconfig/ebtables ?
Jamais utilisé ebtables sous centOS, mais en tout cas les fichiers sont installés par le rpm:
Et donc pour clôturer ces questions peut-on rendre ces scripts exécutables avec un lancement au démarrage en procédant comme suit ???
update-rc.d c'est pour Debian, CentOS c'est chkconfig et si tu met le script en conformité avec certaines règles spécifiques aux initscripts RedHat, http://fedoraproject.org/wiki/Packaging:SysVInitScript , qui explique aussi comment gérer l'ordre de démarrage, oui ça marchera.
Je m'attends en général lorsque je demande un paquet du même nom que le logiciel qu'il contient, à trouver ledit logiciel dedans.
Pour OpenOffice ça na jamais été le cas, sur quasiment toutes les distros, déjà avant quand tu installait OpenOffice tu te retrouvait plutôt avec XimianOffice ou Go-oo !
C'est vrai que j'ai utilisé une page man de l'internet sans faire attention, sur mon système la seule option proposé par read est '-r' surement la seule POSIX ?
On peux remplacer le '-p' par un echo et virer le '-s' si besoin, vu que de toute façons le mot de passe final finira imprimé dans la ligne de commande…
Et j'ajoute à ma méthode, deux autres avantages que j'ai oublier de citer :
On peux facilement générer une carte pour un mot de passe pre-existant, si on n'a pas les moyens de faire une carte tout de suite, ou qu'on s'est vu attribuer un code/mot de passe qu'on ne peut pas changer (genre code de carte bleu, digicode d’accès à une salle ou un bâtiment, admin idiot…).
Si on veux changer le mot de passe d'un service pas besoin de changer de méthode pour obtenir le nouveau mot de passe (tiens, un inconvénient que j'ai oublié de citer pour les autres méthodes : les mots de passes obtenus sons statiques), suffit de générer une autre carte.
La méthode proposée par l'auteur du journal ressemble beaucoup à celle que j'utilisais avant ! Avantage : jamais de blocage devant une fenêtre de password "compatible", on prend vite l'habitude de générer rapidement le mot de passe de n'importe-quel service même ceux qu'on utilise rarement. Inconvénient : Tous les sites ne supportent pas les caractères spéciaux, les majuscules, plus de 8 lettres. etc., et un attaquant pourra facilement déduire la logique du mot de passe, surtout s'il réussit à en obtenir plusieurs.
Passer tout ça au hachoir comme le propose ouasse résout le second problème mais l'obligation de passer par un logiciel pour générer le mot de passe rend l'utilisation peu pratique pour les services plus rarement utilisés (les autres, on finit par retenir la chaîne), avec le risque qu'à terme le mot de passe transite par le presse papier, ou d'oublier un terminal ouvert à la vue de tous avec le résultat de la commande. Pour ceux qui voudrait quand-même utiliser cette méthode je me permet de proposer une petite amélioration, passer par read pour taper le mot de passe 'sel' permet d'éviter de l'enregistrer malencontreusement dans l'historique du terminal :
#!/bin/sh
prg_name=`basename $0`
if [ $# -ne 2 ] ; then
echo "usage: $prg_name user domain"
exit 1
fi
read -rsp "type master password: " m_pwd
echo
echo "${1}${m_pwd}${2}" | openssl dgst -sha1 -binary | base64 | cut -c 1-8
Je passe rapidement sur remplacer les caractères par des mots à la xkcd, vu que ça ne change rien au problème, si tu utilises le même partout tu vas t'en rappeler facilement, mais avec un différent par site ça va vite être lourd à moins d'utiliser une méthode pour déduire le mot de passe à partir du nom du service, mais du coup mêmes problèmes qu'avec la solution n° 1…
Finalement j'utilise actuellement un mélange de la solution N°1 avec la N°2 le tout combiné avec des cartes de code.
Je déduis le chemin sur la carte de code à partir du nom d'utilisateur et du nom du service comme avec la solution N°1, la carte peut contenir des caractères spéciaux et génère un mot de passe totalement aléatoire comme avec la solution N°2, mais si le service l’exige je peux faire une carte qu'avec des caractères minuscules voir avec seulement des chiffres. Si la longueur de mot de passe est limité, je peux le noter sur ma carte pour me rappeler qu'il ne faut parcourir que la moitié du chemin.
Vu que je stocke mes cartes au format papier sur un agenda rotatif modifié, je suis obligé de recopier les mots de passes à la main, pas de risque qu'ils se retrouvent dans l'historique du terminal ou dans le presse-papier.
Un attaquant distant ne pourra pas générer mes autres mots de passe s'il en obtiens un car il n'a pas le jeu de cartes (une par service) celui qui volera ou copiera mon jeu de carte devra encore trouver le cheminement de mon esprit taré pour générer les mots de passes, mais je reconnais que là est le point faible de cette méthode !
Éviter les mots de passe à la "toto", ou d'utiliser le même mot de passe partout, on se retrouve vite avec son compte mail pro piraté suite à une inscription sur un site de boules russe. Après y'a des dizaines de façons de faire, plus ou moins sécures, plus ou moins chiantes, suivant votre degrés de paranoïa, la geekitude de votre entourage et la sensibilité de vos données car pour le simple piratage du gmail d'un inconnu, dans 99,999% le pirate stoppera sans même réfléchir si ça passe pas avec le mot de passe qu'il a récupéré dans la base de données du site de boules russe, même si seulement une lettre diffère entre les deux !
Pareil, une municipalité n'est pas une entités autonome déconnectée de tout, si je croise pas mal de Linux sur serveurs (CentOS, vielle Mandrake 9.2 pas rebootée depuis son install*….), sur les postes clients par contre ça coince. Si l'extranet IE6 only à tendance à disparaître., le suivi, genre les dépôts de RSA du service d'action sociale se fait toujours à grand coup d'envoi par mails de fichiers .xls bourrés de macros incompatibles avec Open/LibreOffice. Çela pose de nombreux problèmes dont la dépendance à Windows.
*RIP à cette machine déconnectée dans la liquidation de l'association qui l’hébergeait, elle servait de passerelle entre deux réseaux et personne n'en connaissait plus le mot de passe, potentiellement un des plus gros uptime jamais vu, je regrette maintenant de ne pas avoir cherché une vielle faille pour m'y connecter et taper "uptime" :'(
Ah, et note a propos de ton bureau basique, tu auras plus de chance de le faire tourner decement si tu utilises systemd (consomation memoire inferieur, moins de process, tout ca, tout ca…).
Ça quand on arrive d'un init classique la légèreté et la rapidité de systemd étonne, faut pas confondre fonctionnalités et lourdeur. J'ai testé sous Gentoo, même distrib pour OpenRC et systemd c'est encore plus flagrant.
Et ifupdown supporte quel pourcentage des fonctionnalités du système ? Il n'en est pas nul pour autant !
Après je ne dit pas que ça ne peut marcher qu'avec une poignée de distribs, je dit justement que ça ne marche qu'avec une poignée de distribs ACTUELLEMENT, que c’est un FAIT, et qu'aujourd'hui on a la capacité avec dbus et une norme freedesktop de changer ça pour avoir un vrai gestionnaire de réseau graphique.
+1 l'auto-hébergement c'est bien beau, mais je ne peut pas me permettre d'avoir mon mail HS 60 jours parce-que engin agricole a détruit une ligne téléphonique ou qu'une branche est rentrée dans un sous répartiteur et a ravagée l’installation (ce qui m’est arrivé de janvier à mars, puis déjà avant et encore avant…)
Du coup je suis chez un hébergeur de VPS lui-même hébergé par OVH-London, je ne sait pas ce que ça vaux niveau "protection juridique", mais aux moins je contrôle mon serveur mail, mon SPF…
Oui mais si un utilisateur de base veux modifier sa config via le clickodrome de gnome il faut fournir une interface adaptée à la modification de ces paramètres via un processus (gnome-network existe depuis gnome2 mais sa config n'était pas persistante et il ne marchait qu'avec une poignée de distribs), ça c'est le boulot de dbus (communication avec le processus) + policykit (contrôle d’accès) + un bon schéma (uniformisation) et quoi qu'on en dise, cette solution elle marche bien.
Au fait NetworkManager exporte aussi un très bon schéma pour la modification des paramètres réseaux via dbus, et y'a un backend de NetWorkManager qui permet d'utiliser les fichiers de conf natifs de Debian, du coup nm-applet devient une superbe interface graphique à /etc/network/interfaces :D
-> ca n'apporte rien a l'existant (les confs de modif de fichiers de conf ca existait déà)
Si, l'uniformisation, le contrôle d’accès…
-> ca centralise des droits étendus
Comme sudo ?
-> ca augmente de la surface d'attaque
Ça j'en sait rien j'ai pas audité le code, mais ça ne me semble pas pire que l'init redhat actuel qui gère déjà les services basés sur xinetd
-> ce n'est pas scalable
-> ce n'est que difficilement maintenable pour un parc de machine.
Actuellement les développements se sont surtout orientés vers le bureau, mais je ne voit pas dans l’architecture du système ce qui empêche un système à la puppet basé sur des interfaces dbus.
Ben si tu veux une TZ spéciale pour ta session tu modifie ton .xinitrc et c'est marre.
Gnome fournis dans son environnement de bureau des outils d'administration SYSTÈME depuis au moins la version 1.xx (le lecteur de fichiers log). S'ils ont envies de proposer un outil d'admin dédié à la mise à jour de la timezone du système je ne voit pas de raison de les en empêcher. Et si tu as envie de voir dans cet outil une case à cocher « appliquer uniquement à la session courante » tu sait ce qu'on dit, propose un patch !
[^] # Re: MIME pas mage
Posté par Tonton Benoit . En réponse au message [résolu] Ouvrir les fichiers selon leur extension. Évalué à 3.
Je pense plutôt que ça continu à ouvrir selon le type mime, mais que la définition de celui-ci ne se base que sur l'extension du fichier pour le déterminer.
Faut pas confondre trois choses :
1: Le type MIME qui définit le contenu d'un fichier, genre video/mpeg, image/gif, etc.
2: Les "Magic Numbers" qui sont un moyen d'identifier le contenu d'un fichier (=lui attribuer un type MIME), genre le GIF89a au début d'une image gif, le #! au début d'un script… C'est ce que Linux (entre-autre) utilise, mais pas Windows.
3: L'extension qui est un autre moyen (peu fiable) d'identifier le type d'un fichier et de lui attribuer un type MIME. Utilisé majoritairement par Windows mais aussi sous Linux si le type du fichier n’est pas identifiable par son contenu (chiffré ?) ou si personne ne s'est encore fait chier à spécifier les "Magic infos" (le cas du mp4) ?
# MIME pas mage
Posté par Tonton Benoit . En réponse au message [résolu] Ouvrir les fichiers selon leur extension. Évalué à 2.
Sous Unix les fichiers sont identifiés par leur type MIME et tous les explorateurs de fichiers se basent sur ça.
Si tu veux ouvrir un fichier en te basant sur son extension, il ne te reste plus qu'à créer un nouveau type MIME (genre application/extension-monext) qui match uniquement sur l’extension du fichier.
Je sais que c'est possible, mais je n'ai personnellement jamais modifié à la main la "mimeinfo database".
Tu trouvera des infos en cherchant sur internet, genre là : http://standards.freedesktop.org/shared-mime-info-spec/shared-mime-info-spec-latest.html
[^] # Re: Si tu reboot une fois par an ça va !
Posté par Tonton Benoit . En réponse au journal De la façon dont un problème de boot est résolu sous FreeBSD. Évalué à 2. Dernière modification le 31 juillet 2012 à 02:10.
Et quant le BIOS/EFI/OpenBoot sera enfin de nouveau rapide ou se re-souciera de la performance du système d'init ?
Et grep combien de lignes de C ?
Si on en arrive à un script complexe à la place d'un truc avec trois fonctions (start/stop/reload) et juste deux appels à start-stop-daemon c'est bien qu'on as un "problème" à résoudre non ?
La bonne pratique voudrait que tout les trucs plus complexes que le démarrage d'un service simple où l’exécution d'une configuration basique (l'init c'est pas que du lancement de service) soit placé dans un helper externe, peu importe le langage utilisé, mais vu que les systèmes d'init Unix interprètent le shell on s'est vite retrouvé avec par flemmardise du code bien gruik dans /etc/init.d, ici systemd ne fait qu'imposer une bonne pratique qui aurait dû être la norme bien avant son arrivé !
# Saborder le PC pour promouvoir des plates-formes spécialisés et fermés
Posté par Tonton Benoit . En réponse au journal Microsoft est-il en train de se suicider ?. Évalué à 4.
Microsoft sait qu'il a déjà perdu la guerre des smartphones. Avec Windows 8 il tente de créer son "Android" à lui avec pour marché le tactile et l'embarqué. Objectif ? Gagner de l'argent avec son market et sa régie publicitaire bien-sûr.
Pour Microsoft c'est tout benef, non seulement sur ce marché le hardware verrouillé est la norme, mais en plus il va tirer via sa politique "labellisation" tout les constructeurs sur un marché de machines ARM ou de puissance moindre par rapport aux PC d'aujourd'hui.
On dit que Steam critique Windows 8 à cause du market, mais pas que, Alors qu’aujourd’hui a peu près n'importe-quelle machine vendu dans le commerce peut faire tourner des jeux classiques, Microsoft tourne le marché de façon à rendre la vie difficile aux jeux classiques, pas forcement de clavier ni de capacité 3D très avancés sur l'informatique grand-public de demain, la fragmentation des technologies et des capacités hardwares est une galère pour les développeurs et une chance pour Microsoft qui pourra vendre sa plate-forme x-box aux casual gamers.
Si ça marche tout va être plateformisé, la tablette pour la maison avec 100% des données dans le cloud, la console pour le jeu, une machine à écrire moderne et bien-sûr au hardware verrouillé pour le boulot…
Steam aussi va dans ce sens, son intérêt récent pour Linux montre peut-être les prémices d'un "SteamOS" basé sur Linux et tournant sur du hardware performant et plus proche de ce qu'on connait aujourd’hui (écran séparé, clavier, souris…)
# Tous le monde y va, sauf
Posté par Tonton Benoit . En réponse au journal GNOME 4.0 et GNOME OS prévus pour 2014 : abandon du pc, (même si on en était pas loin avec Gnome3). Évalué à 7.
L’embarqué grand-public c'est l'eldorado. Microsoft, Google, Mozilla, Gnome… tous le monde y va.
C'est pourtant un marché difficile, si tu n'a pas assez de parts de marché tu n'attire pas les développeurs et beaucoup de bons sont morts (ou presque) avec comme cause principale le manque d’engouement des développeurs pour leur market.
Le marché du smartphone déjà mature montre qu'il y a peu de places, même le puissant Microsoft peine à y percer.
[^] # Re: Si tu reboot une fois par an ça va !
Posté par Tonton Benoit . En réponse au journal De la façon dont un problème de boot est résolu sous FreeBSD. Évalué à 2.
Un SSD améliore très fortement une partie du boot en réglant le problème des IO (au boot on lit plein de petits fichiers), mais les systèmes de boot "à l’ancienne" comme tu dit, en shell posent un autre problème de performance : l'appel dans les scripts à de nombreux programmes externes (grep, sed, cut) met la pression sur les caches des processeurs et fait énormément chuter les performances.
Je lis plus haut qu'on reproche à systemd d'être un bloatware parce qu'il est capable de remplacer un cron ou un atd, mais l'utilisation de fichiers de configuration et de "helpers" en C plutôt que de faire des scripts 300 lignes qui appellent moult programmes externes pour gérer le choses complexes le rendent systématiquement plus rapide que n'importe-quel système d'init que j'ai croisé.
# Si tu reboot une fois par an ça va !
Posté par Tonton Benoit . En réponse au journal De la façon dont un problème de boot est résolu sous FreeBSD. Évalué à 4.
Totalement sous-optimal tu va lancer un sous-shell juste pour développer sshd_enable="NO" et faire un test.
Bon pour un serveur qui reboot tout les 36 du mois ça va, pour un desktop l'optimisation du boot reste cruciale.
[^] # Re:
Posté par Tonton Benoit . En réponse au message Iptables ebtables scripts - mode débutant. Évalué à 2.
Anéfé je croyait les fonctions LSB plus riches que ça. Faudrait voir la documentation de Upstart (RHEL 6) si y'a moyen de préciser un "before net", comme sous gentoo, sinon faut jouer à l’ancienne avec les liens dans /etc/rc?.d/SXXnomduscript
[^] # Re: autre petite question concernant Iptables
Posté par Tonton Benoit . En réponse au message Iptables ebtables scripts - mode débutant. Évalué à 3.
Désolé de répondre si tard.
/etc/sysconfig/iptables doit contenir les règles courantes, enregistrées par /etc/init.d/iptables save
L'état dans lequel on veut trouver le firewall au démarrage quoi. La procédure que j'utilise sous centOS :
1: Je crée un script iptables (à l’ancienne, mais su tu est familiarisé avec la syntaxe d'iptables-restore tu peux l'utiliser)
2: J’exécute le script
3: Je vérifie que tout convient
4: Je sauvegarde (/etc/init.d/iptables save) pour que ce soit pris en compte à chaque démarrage.
Et si je veux modifier les règles je reprend à partir de 1.
# Re:
Posté par Tonton Benoit . En réponse au message Iptables ebtables scripts - mode débutant. Évalué à 4.
C'est pas une bonne idée, /etc/sysconfig/iptables est régénéré automatiquement avec les règles en cours quand on fait /etc/init.d/iptables save, jamais une bonne idée de mettre ses configurations perso dans un fichier qui peut être écrasé automatiquement par un script.
On utilise /etc/sysconfig/iptables pour charger automatiquement et de façon atomique les règles iptables au démarrage, mais on stocke sa config perso ailleurs pour modification ultérieure.
Jamais utilisé ebtables sous centOS, mais en tout cas les fichiers sont installés par le rpm:
update-rc.d c'est pour Debian, CentOS c'est chkconfig et si tu met le script en conformité avec certaines règles spécifiques aux initscripts RedHat, http://fedoraproject.org/wiki/Packaging:SysVInitScript , qui explique aussi comment gérer l'ordre de démarrage, oui ça marchera.
# Déjà fait
Posté par Tonton Benoit . En réponse au journal Et les lecteurs de Linuxfr, ils votent pour qui ?. Évalué à 5.
On n'a pas étendu les agences américaines pour confirmer ce qu'on savait déjà !
https://linuxfr.org/sondages/pour-les-%C3%A9lections-pr%C3%A9sidentielles-je-vais
https://linuxfr.org/sondages/pour-les-%C3%A9lections-pr%C3%A9sidentielles-je-vais--2
Bref les linuxfriens sont plutôt du centre avec une tendance à gauche (et non de centre-gauche)
Mais bon ça date de 2007,ça a peut-être un peu bougé depuis.
Et puis pas besoin d'études ou de sondage pour voir la tendance d'un site, tu lis une dizaine de commentaires dessus et ça transpire déjà.
[^] # Re: défauts et qualités
Posté par Tonton Benoit . En réponse au journal Gé(né)rer ses mots de passe. Évalué à 2.
Entre faire un +v dans le dos de l'utilisateur et installer un keylogger avec un /home monté en noexec la difficulté n'est pas la même.
[^] # Re: Moi y'en a pas comprendre
Posté par Tonton Benoit . En réponse au message Ubuntu et OpenOffice : tromperie. Évalué à 5.
Pour OpenOffice ça na jamais été le cas, sur quasiment toutes les distros, déjà avant quand tu installait OpenOffice tu te retrouvait plutôt avec XimianOffice ou Go-oo !
[^] # Re: défauts et qualités
Posté par Tonton Benoit . En réponse au journal Gé(né)rer ses mots de passe. Évalué à 2.
C'est vrai que j'ai utilisé une page man de l'internet sans faire attention, sur mon système la seule option proposé par read est '-r' surement la seule POSIX ?
On peux remplacer le '-p' par un echo et virer le '-s' si besoin, vu que de toute façons le mot de passe final finira imprimé dans la ligne de commande…
[^] # Re: défauts et qualités
Posté par Tonton Benoit . En réponse au journal Gé(né)rer ses mots de passe. Évalué à 2. Dernière modification le 30 juin 2012 à 03:54.
Et j'ajoute à ma méthode, deux autres avantages que j'ai oublier de citer :
On peux facilement générer une carte pour un mot de passe pre-existant, si on n'a pas les moyens de faire une carte tout de suite, ou qu'on s'est vu attribuer un code/mot de passe qu'on ne peut pas changer (genre code de carte bleu, digicode d’accès à une salle ou un bâtiment, admin idiot…).
Si on veux changer le mot de passe d'un service pas besoin de changer de méthode pour obtenir le nouveau mot de passe (tiens, un inconvénient que j'ai oublié de citer pour les autres méthodes : les mots de passes obtenus sons statiques), suffit de générer une autre carte.
# défauts et qualités
Posté par Tonton Benoit . En réponse au journal Gé(né)rer ses mots de passe. Évalué à 3.
La méthode proposée par l'auteur du journal ressemble beaucoup à celle que j'utilisais avant ! Avantage : jamais de blocage devant une fenêtre de password "compatible", on prend vite l'habitude de générer rapidement le mot de passe de n'importe-quel service même ceux qu'on utilise rarement. Inconvénient : Tous les sites ne supportent pas les caractères spéciaux, les majuscules, plus de 8 lettres. etc., et un attaquant pourra facilement déduire la logique du mot de passe, surtout s'il réussit à en obtenir plusieurs.
Passer tout ça au hachoir comme le propose ouasse résout le second problème mais l'obligation de passer par un logiciel pour générer le mot de passe rend l'utilisation peu pratique pour les services plus rarement utilisés (les autres, on finit par retenir la chaîne), avec le risque qu'à terme le mot de passe transite par le presse papier, ou d'oublier un terminal ouvert à la vue de tous avec le résultat de la commande. Pour ceux qui voudrait quand-même utiliser cette méthode je me permet de proposer une petite amélioration, passer par read pour taper le mot de passe 'sel' permet d'éviter de l'enregistrer malencontreusement dans l'historique du terminal :
Je passe rapidement sur remplacer les caractères par des mots à la xkcd, vu que ça ne change rien au problème, si tu utilises le même partout tu vas t'en rappeler facilement, mais avec un différent par site ça va vite être lourd à moins d'utiliser une méthode pour déduire le mot de passe à partir du nom du service, mais du coup mêmes problèmes qu'avec la solution n° 1…
Finalement j'utilise actuellement un mélange de la solution N°1 avec la N°2 le tout combiné avec des cartes de code.
Je déduis le chemin sur la carte de code à partir du nom d'utilisateur et du nom du service comme avec la solution N°1, la carte peut contenir des caractères spéciaux et génère un mot de passe totalement aléatoire comme avec la solution N°2, mais si le service l’exige je peux faire une carte qu'avec des caractères minuscules voir avec seulement des chiffres. Si la longueur de mot de passe est limité, je peux le noter sur ma carte pour me rappeler qu'il ne faut parcourir que la moitié du chemin.
Vu que je stocke mes cartes au format papier sur un agenda rotatif modifié, je suis obligé de recopier les mots de passes à la main, pas de risque qu'ils se retrouvent dans l'historique du terminal ou dans le presse-papier.
Un attaquant distant ne pourra pas générer mes autres mots de passe s'il en obtiens un car il n'a pas le jeu de cartes (une par service) celui qui volera ou copiera mon jeu de carte devra encore trouver le cheminement de mon esprit taré pour générer les mots de passes, mais je reconnais que là est le point faible de cette méthode !
Éviter les mots de passe à la "toto", ou d'utiliser le même mot de passe partout, on se retrouve vite avec son compte mail pro piraté suite à une inscription sur un site de boules russe. Après y'a des dizaines de façons de faire, plus ou moins sécures, plus ou moins chiantes, suivant votre degrés de paranoïa, la geekitude de votre entourage et la sensibilité de vos données car pour le simple piratage du gmail d'un inconnu, dans 99,999% le pirate stoppera sans même réfléchir si ça passe pas avec le mot de passe qu'il a récupéré dans la base de données du site de boules russe, même si seulement une lettre diffère entre les deux !
[^] # Re: Quel est le plus dur ? Quitter windows XP ou passer à linux ?
Posté par Tonton Benoit . En réponse au journal Pourquoi plus aucune ville ne passe à Linux ?. Évalué à 3.
Pareil, une municipalité n'est pas une entités autonome déconnectée de tout, si je croise pas mal de Linux sur serveurs (CentOS, vielle Mandrake 9.2 pas rebootée depuis son install*….), sur les postes clients par contre ça coince. Si l'extranet IE6 only à tendance à disparaître., le suivi, genre les dépôts de RSA du service d'action sociale se fait toujours à grand coup d'envoi par mails de fichiers .xls bourrés de macros incompatibles avec Open/LibreOffice. Çela pose de nombreux problèmes dont la dépendance à Windows.
*RIP à cette machine déconnectée dans la liquidation de l'association qui l’hébergeait, elle servait de passerelle entre deux réseaux et personne n'en connaissait plus le mot de passe, potentiellement un des plus gros uptime jamais vu, je regrette maintenant de ne pas avoir cherché une vielle faille pour m'y connecter et taper "uptime" :'(
[^] # Re: Irrémédiable
Posté par Tonton Benoit . En réponse au journal Gnome3 et systemd, c'est la fin des haricots!. Évalué à 2.
Au hasard je dirait pour pouvoir accueillir une adresse IPv6 pleine-longueur ?
# Fedora
Posté par Tonton Benoit . En réponse au sondage Quelle distribution de logiciels libres installez-vous aux copains non geeks?. Évalué à 4.
Pour une distrib VRAIMENT simple et agréable à administrer (vu qu'au final y'a des chances que ce soit moi qui m'en occupe)
Avant c'était Ubuntu pour la cohésion de l'interface, mais depuis Gnome a rattrapé son retard.
[^] # Re: avant de s'énerver
Posté par Tonton Benoit . En réponse au journal Gnome3 et systemd, c'est la fin des haricots!. Évalué à 7.
Ça quand on arrive d'un init classique la légèreté et la rapidité de systemd étonne, faut pas confondre fonctionnalités et lourdeur. J'ai testé sous Gentoo, même distrib pour OpenRC et systemd c'est encore plus flagrant.
[^] # Re: Irrémédiable
Posté par Tonton Benoit . En réponse au journal Gnome3 et systemd, c'est la fin des haricots!. Évalué à 3.
Et ifupdown supporte quel pourcentage des fonctionnalités du système ? Il n'en est pas nul pour autant !
Après je ne dit pas que ça ne peut marcher qu'avec une poignée de distribs, je dit justement que ça ne marche qu'avec une poignée de distribs ACTUELLEMENT, que c’est un FAIT, et qu'aujourd'hui on a la capacité avec dbus et une norme freedesktop de changer ça pour avoir un vrai gestionnaire de réseau graphique.
[^] # Re: Auto-hébergement
Posté par Tonton Benoit . En réponse au journal Vie privée sur internet et demandes gouvernementales. Évalué à 3. Dernière modification le 13 juin 2012 à 00:53.
+1 l'auto-hébergement c'est bien beau, mais je ne peut pas me permettre d'avoir mon mail HS 60 jours parce-que engin agricole a détruit une ligne téléphonique ou qu'une branche est rentrée dans un sous répartiteur et a ravagée l’installation (ce qui m’est arrivé de janvier à mars, puis déjà avant et encore avant…)
Du coup je suis chez un hébergeur de VPS lui-même hébergé par OVH-London, je ne sait pas ce que ça vaux niveau "protection juridique", mais aux moins je contrôle mon serveur mail, mon SPF…
[^] # Re: Irrémédiable
Posté par Tonton Benoit . En réponse au journal Gnome3 et systemd, c'est la fin des haricots!. Évalué à 3. Dernière modification le 13 juin 2012 à 00:42.
Oui mais si un utilisateur de base veux modifier sa config via le clickodrome de gnome il faut fournir une interface adaptée à la modification de ces paramètres via un processus (gnome-network existe depuis gnome2 mais sa config n'était pas persistante et il ne marchait qu'avec une poignée de distribs), ça c'est le boulot de dbus (communication avec le processus) + policykit (contrôle d’accès) + un bon schéma (uniformisation) et quoi qu'on en dise, cette solution elle marche bien.
Au fait NetworkManager exporte aussi un très bon schéma pour la modification des paramètres réseaux via dbus, et y'a un backend de NetWorkManager qui permet d'utiliser les fichiers de conf natifs de Debian, du coup nm-applet devient une superbe interface graphique à /etc/network/interfaces :D
[^] # Re: Irrémédiable
Posté par Tonton Benoit . En réponse au journal Gnome3 et systemd, c'est la fin des haricots!. Évalué à 4.
Tout comme selinux…
Si, l'uniformisation, le contrôle d’accès…
Comme sudo ?
Ça j'en sait rien j'ai pas audité le code, mais ça ne me semble pas pire que l'init redhat actuel qui gère déjà les services basés sur xinetd
Actuellement les développements se sont surtout orientés vers le bureau, mais je ne voit pas dans l’architecture du système ce qui empêche un système à la puppet basé sur des interfaces dbus.
[^] # Re: Irrémédiable
Posté par Tonton Benoit . En réponse au journal Gnome3 et systemd, c'est la fin des haricots!. Évalué à 2.
Ben si tu veux une TZ spéciale pour ta session tu modifie ton .xinitrc et c'est marre.
Gnome fournis dans son environnement de bureau des outils d'administration SYSTÈME depuis au moins la version 1.xx (le lecteur de fichiers log). S'ils ont envies de proposer un outil d'admin dédié à la mise à jour de la timezone du système je ne voit pas de raison de les en empêcher. Et si tu as envie de voir dans cet outil une case à cocher « appliquer uniquement à la session courante » tu sait ce qu'on dit, propose un patch !