Je n'ai rien de particulier à conseiller qui n'a pas déjà été dit, mais vu ton niveau de pratique, ne t'interdit pas à regarder du coté des distributions en rolling release (Arch, Gentoo…)
Pour donner mon avis sur le TL-WR710N (que je n'ai pas), 8mo de flash, j'ai déjà donné avec la fonera ! On arrive à tout y entrer (IPv6, QoS…) même en gardant une petite interface web pour la configuration, mais après y'a pu de places, n'espérez pas utiliser ipkg dessus, et le "online flash" avec sysupgrade ne marchera pas (faute de place), pour mettre à jour faudra repasser par un flashage à partir du boot loader.
De plus j'imagine que linuxfr.org est en cache chez lui :D Sur un domaine qu'il dois résoudre depuis le net se sera kif-kif avec les autres resolvers.
Selon ma propre expérience, l’intérêt d'un cache DNS sur un petit réseau = NUL, Ton navigateur web à un cache (il n'envoi pas une requête DNS pour chaque contenu sur le même serveur), la GLibC à un cache DNS : nscd, alors rajouter un autre niveau cache DNS entre ceux-là et le cache DNS de ton FAI/Google…
Les DNS de Google sont bons parce-qu'ils ont un cache rempli par pleins d'utilisateurs, sur un petit réseau de quelques utilisateurs, soit c'est pas un domaine visité fréquemment par la maisonnée et il ne sera dans aucun des caches, soit c'est un domaine très visité et il sera déjà en cache localement sur la machine (navigateur ouvert ou nscd)
Par contre un DNS local permet d'attaquer directement les roots en iteratif sans passer par aucun serveur cache (vie privée) et d’accéder facilement aux autres machines de son LAN
Exemple chez moi, toutes les machines connectées en wifi :
Routeur/pare-feu IPv4 (avec des vrai règles de pare-feu) et pas juste du NAT qui "fait comme", entre les appareils et internet, mais aussi à l’intérieur du LAN.
Routeur/pare-feu IPv6 (Parce-que pas de pare-feu IPv6 sur freebox, alors qu'il n'y a même plus le NAT pour filtrer un peu les entrées).
Endpoint pour mon tunnel IPv6 (parce-que l'IPv6 de free n'est pas pour moi, pauvre non-dégroupé, et de toutes façons elle manque encore légèrement de fonctionnalités, genre reverse DNS).
DHCP pour l’auto-configuration IPv4
Radvd pour l’auto-configuration IPv6 (comme ça mon routeur masque le tunnel IPv6 et présente l'IPv4 et l'IPv6 sur la même interface).
QoS "basique" sans DPI (je rend prioritaire les flux sur les ports 80 et 443 pour une navigation internet fluide, le reste attendra), marche bien pour mon usage.
Cache DNS (OSEF), mais plus important DNS pour le réseau local.
Éventuellement, faire passer tout mon trafic par un VPN. N'a servi qu'une fois, quand suite à une panne ADSL j'ai dû utiliser ma connexion 3G, mais mon opérateur refusais les usages modem. Autrement je configure plutôt le VPN directement sur les machines.
Pas de réseaux multiples/DMZ/VLAN faute d'assez de ports, mais j'ai un autre routeur directement relié à la freeboiboite pour les services, c'est encore mieux séparé du coup !
je ne savais même pas qu'en 2013 il existait encore de la mémoire sous forme de Mo.
Et bientôt en ko si ça continu ! Sur les routeurs l'évolution va dans ce sens, on est passé de 8mo courant à 4mo quasi-généralisé sauf sur les modèles "certifiés open-source", maintenant y'a de plus en plus de modèles "pas chers" équipés de 2mo seulement…
Et ce serait pas intéressant de pouvoir rajouter, supprimer, changer, monitorer les instances de postgresql démarrées par l'init via un petit utilitaire ?
Certes on peut rajouter des commandes à /etc/init.d/postgresql, mais autant faire un truc qui marchera partout non ?
Et puis je suis pas fan perso quand l'init fait trop de choses sans même me demander mon avis.
Tu démarre le service pour la première fois t'a une base de données utilisable, bien, très bien, mais si tu ne voulait pas ça ? Si tu voulait importer ta base de données avant ? Raté ! apt-get install postgresql lancera automatiquement l'initscript qui va te créer une base inutile et quand tu va importer la tienne après, l'initscript va gueuler que l'instance 9.1/main entre en conflit avec l'instance 9.1/main. Obligé d'aller lire le contenu du script pour voir comment il fonctionne et comment déboguer alors qu'une commande externe aurait eu sa page de manuel.
Et puis n’espérez transférer une base de donnée de RHEL à Debian comme-ça, la façon dont sont choisies les instances à démarrer est spécifique à chaque distrib, le transfert ne se fera pas sans mal.
C'est pas comme si j'avais pas cité les bashisms entre-autres.
Quasiment toutes les distribs sont passés à du pure SH (Debian, Gentoo…), mais reste quelques bashisms chez RH par ex, et si l'auteur d'un programme fournit un initscript pour RH, ben ça marchera pas ailleurs.
Après, tous ces init utilisent le même langage, mais pas les mêmes fonctions,
CentOS : /etc/rc.d/init.d/functions
Debian : /lib/lsb/init-functions
Gentoo : /lib/rc/sh/runscript.sh
Et ces fichiers contiennent tous des commandes spécifiques à chaque init (log_warning_msg pour un, ewarn pour l'autre…)
Sortir le gros de la gestion du daemon hors de l'init permet un meilleur contrôle de l'utilisateur via un outil unifié, mais aussi de minimiser le code spécifique à la distribution.
Après bizarre de voir les bsdistes me tomber dessus alors que j'ai cité jail en bon exemple, mais bon j'ai dit systemd, c'est un gros mot.
J'ai rien contre le langage shell, mais en mettre un gros pâté dans un initscript est pour moi un indicateur de solution gruik posée à la va-vite. Se sera pas pas portable (bash d'un coté, Ash de l'autre, paths hardcodés, appels de fonctions spécifiques…), pas porté (chacun fera sa petite cuisine dans son coin), inélégant, le contraire du prétendu "esprit" du SysV RC qu'on nous chantes chaque fois qu'on parle de SystemD.
En des temps immémoriaux, à ma première LSF, pour monter les systèmes de fichiers l'initscript était un simple appel à mount -a.
Maintenant pour faire ça t'a des centaines de lignes dans /etc/rc.sysvinit pour RHEL, Pour Debian des milliers de lignes dans /etc/init.d et /etc/network/if-up.d…
Bon ces scripts font des choses utiles genre attendre le réseau pour monter du NSF, des dizaines de mainteneurs de distributions ont implémentés ce genre de truc, mais personne n'a penser à moderniser mount pour qu'ils réponde aux nouveaux besoins de l'init, alors que c'est son rôle :
mount -a [-t type] [-O optlist]
(**usually given in a bootscript**) causes all filesystems mentioned in fstab (of the proper type
and/or having or not having the proper options) to be mounted as indicated, except for those
whose line contains the noauto keyword. Adding the -F option will make mount fork, so that the
filesystems are mounted simultaneously.
Des scripts shell je suis le premier à en faire, mais dès que tu te pose la question "comment faire ça proprement ?" ben tu les sort de l'init.
Avec LXC beaucoup de distributions ont ajoutés un initscript "complexe" pour lancer de containers au démarrage.
Alors c'est pratique, tu file le nom de tes containers dans /etc/default/lxc et ils seront démarrés/arrêtés automatiquement.
Mais si j'en arrête un par moi même, l'init gueulera à l’arrêt du service que toto était lancé et qu'il ne l'est plus, ou plein d'autres petits dysfonctionnements.
On s’aperçoit vite que pour faire ça proprement, il faut un système qui permette la gestion complète des containers "automatiques" ajout/suppression/démarrage/arrêt/démarrage-individuel/arrêt-individuel/statut d'un containers/statut de tous les containers… et que la place d'un tel utilitaire n'est pas dans l'init, par contre un l'init peut appeler cet utilitaire pour le démarrage/arrêt du service.
Après faire ça en shell, pourquoi pas, c'est un choix de langage comme un autre.
Il est (ou a été) utilisé par défaut par de nombreuses distributions : Ubuntu, Red Hat Entreprise Linux, Fedora et Chrome OS.
Faut le dire très vite.
RHEL utilise un gros script /etc/rc.sysvinit au démarrage qui se charge de monter les fs, définir le hostname, l'équivalant du niveau rcS de Debian quoi… Après il appelle upstart pour trois merdes (le spash screen, l'initialisation des tty…) puis utilise la couche de compatibilité SysV d'upstart pour lancer les services de /etc/init.d
Bref il utilise Upstart de la façon la plus inutile qu'il soit, su RHEL 7 fait pareil avec SystemD, ça promet !
Bon faut dire après qu'ils sont bloqué avec la version 0.6 d'Upstart qui n'offre même pas de façon propre d'activer/désactiver les services (un comble pour un gestionnaire de services)
Pour les performances, cherche pas, on te dira que blabla c’est pas nécessaire sur serveur et que sur le bureau tout le monde utilise systemd de toutes façons.
En tout cas entre SystemD et OpenRC y'a pas photo, surtout que j'ai jamais réussi à faire du lancement parallèle avec OpenRC sans bugs.
Les autres, pas fait de comparaison sérieuses, mais pas l'air très véloces. Après ça vient plus de la lourdeurs des script que des choix technologiques eux-mêmes, regarde les scripts d'init "SysV" de Debian ou RHEL ça reimplemente tout "mount -a" en Bash directement dans l'initscript.
Alors quand je lis que les *BSD ont remplacés des milliers de ligne en shell d'init par une commande "jail -c" je dit bravo, c'est dans ce sens qu'il faut aller, et c'est ce sens qu'encourage SystemD en "virant" l'interprétation shell des fichiers de définition des services.
Debian, SysV RC, tout autre système sans suivi du processus via pid/cgroups : faut chercher soit-même avec ps, netstat ou parfois /etc/init.d/ status s'il propose la fonction.
LOL, à pars Debian qui utilise encore cette m sous Linux ? Un système d'init même pas capable de suive le statut des processus qu'il a lancé…
Je suis méchant mais demandez à n'importe qui dans la rue ce que je déteste sur Debian il répondra "le système d'init" et ce que j'aime ? /etc/network/interfaces
echo "pouet" > /etc/hostname
Debian specific, variable hostname du fichier /etc/conf.d/hostname pour Gentoo, variable HOSTNAME du fichier /etc/sysconfig/network pour RHEL/CentOS…
Google pas directement, mais indirectement pourquoi pas. Internet est vaste et je ne mettrait pas ma main au feu que personne ne diffuse une liste d'url valides récupérés par "bruteforce" (on teste domaine.ext/a puis domaine.ext/b…) ou dictionnaire (on teste domaine.ext/index.php puis domaine.ext/admin…).
Google est remplis de pages qui ne sont pas sensées être publiques !
Autre domaine, mais tout aussi surprenant, y'a quelque-temps je montais un serveur mail pour une nouvelle association.
J'ai pas encore d'enregistrement MX que je reçoit déjà un spam chinois et directement sur une adresse valide que je vient tout juste de créer. C'étais pas une adresse 'standard' genre admin@ ou postmaster@ mais mon compte perso et tomber direct dessus comme-ça, je ne comprend toujours pas.
Comme déjà dit, chiffrer ses messages confidentiels.
Et j'ajoute : Ne pas compter sur la non diffusion (ou la diffusion limitée) d'une URL pour protéger un contenu confidentiel et/ou privée, http auth ou les certificats ssl clients sont conçus pour ça, eux.
Bref tu a fait là une chose du même genre que confondre NAT et firewall ou RAID et sauvegarde ;)
Du boot sur CD à cette époque, je ne pense pas ! ma carte-mère FIC PT-2200 était une des première capable de faire ça (et de supporter l'USB aussi, en version "draft") en 1997.
Par contre avec un disque-dur (ou même une disquette), pas de raison que ça ne fonctionne pas, reste à faire la bonne 'image' qui bootera sans problème, aura les bons pilotes réseau ou serie et lancera sshd/telnetd.
Sauf si tu lui demande le contraire, zip ne gère pas les liens symboliques par défaut, donc au lieu de copier vers une destination temporaire, il suffit de faire un symlink vers celle-ci. Plus rapide, moins gourmand.
Posté par Tonton Benoit .
En réponse au message Gros malin.
Évalué à 2.
Dernière modification le 23 novembre 2013 à 15:28.
Le contrôle sur le PlayStore est léger et plus basé sur le signalement à posteriori des applications litigieuses.
Sur l'AppStore d'Apple le contrôle a-priori des applications est plus poussé, mais ça n'a pas évité des problèmes malgré-tout (surtout qu'Apple cherche plus les applications nuisibles pour lui que pour les utilisateurs), et du coup les délais (jusqu'à 10 jours pour voir son application validée) sont assez lourds à supporter pour les développeurs.
# RR
Posté par Tonton Benoit . En réponse au message changement de distrib.. Évalué à 3.
Je n'ai rien de particulier à conseiller qui n'a pas déjà été dit, mais vu ton niveau de pratique, ne t'interdit pas à regarder du coté des distributions en rolling release (Arch, Gentoo…)
[^] # Re: Fedora?
Posté par Tonton Benoit . En réponse au message changement de distrib.. Évalué à 3.
Surtout que Fedora, la 20 va bientôt sortir :) Tu part pour quelques mois de tranquillité sur une distrib pérenne.
[^] # Re: Mo
Posté par Tonton Benoit . En réponse au journal OpenWRT et TP-Link TL-WR710N. Évalué à 2.
C'est sur que si tu te base sur la liste du matériel supporté, tu vire déjà la tonne de routeurs à 2mb qui inonde le marché !
[^] # Re: Mo
Posté par Tonton Benoit . En réponse au journal OpenWRT et TP-Link TL-WR710N. Évalué à 3.
Et je rajoute que la ram, elle, augmente bien, avec l'ethernet gigabits et le wifi 150/300 il faut des buffers plus gros pour tenir les débits.
[^] # Re: Sinon
Posté par Tonton Benoit . En réponse au journal OpenWRT et TP-Link TL-WR710N. Évalué à 2.
Mais du coup il faut avoir assez de ram libre…
Bon avec 32mo ça passe peut-être, avec 16 sur la fonera ça plantait.
Au fait, je suis peut-être bigleux, mais la page d'OpenWRT parle d'un port série, mais je voit pas où il est sur le PCB.
[^] # Re: Mo
Posté par Tonton Benoit . En réponse au journal OpenWRT et TP-Link TL-WR710N. Évalué à 2.
Non c'est bien la flash qui baisse.
# Sinon
Posté par Tonton Benoit . En réponse au journal OpenWRT et TP-Link TL-WR710N. Évalué à 3. Dernière modification le 06 décembre 2013 à 23:21.
Pour donner mon avis sur le TL-WR710N (que je n'ai pas), 8mo de flash, j'ai déjà donné avec la fonera ! On arrive à tout y entrer (IPv6, QoS…) même en gardant une petite interface web pour la configuration, mais après y'a pu de places, n'espérez pas utiliser ipkg dessus, et le "online flash" avec sysupgrade ne marchera pas (faute de place), pour mettre à jour faudra repasser par un flashage à partir du boot loader.
[^] # Re: Utilisation ?
Posté par Tonton Benoit . En réponse au journal OpenWRT et TP-Link TL-WR710N. Évalué à 3.
De plus j'imagine que linuxfr.org est en cache chez lui :D Sur un domaine qu'il dois résoudre depuis le net se sera kif-kif avec les autres resolvers.
Selon ma propre expérience, l’intérêt d'un cache DNS sur un petit réseau = NUL, Ton navigateur web à un cache (il n'envoi pas une requête DNS pour chaque contenu sur le même serveur), la GLibC à un cache DNS : nscd, alors rajouter un autre niveau cache DNS entre ceux-là et le cache DNS de ton FAI/Google…
Les DNS de Google sont bons parce-qu'ils ont un cache rempli par pleins d'utilisateurs, sur un petit réseau de quelques utilisateurs, soit c'est pas un domaine visité fréquemment par la maisonnée et il ne sera dans aucun des caches, soit c'est un domaine très visité et il sera déjà en cache localement sur la machine (navigateur ouvert ou nscd)
Par contre un DNS local permet d'attaquer directement les roots en iteratif sans passer par aucun serveur cache (vie privée) et d’accéder facilement aux autres machines de son LAN
[^] # Re: Utilisation ?
Posté par Tonton Benoit . En réponse au journal OpenWRT et TP-Link TL-WR710N. Évalué à 4.
Exemple chez moi, toutes les machines connectées en wifi :
Routeur/pare-feu IPv4 (avec des vrai règles de pare-feu) et pas juste du NAT qui "fait comme", entre les appareils et internet, mais aussi à l’intérieur du LAN.
Routeur/pare-feu IPv6 (Parce-que pas de pare-feu IPv6 sur freebox, alors qu'il n'y a même plus le NAT pour filtrer un peu les entrées).
Endpoint pour mon tunnel IPv6 (parce-que l'IPv6 de free n'est pas pour moi, pauvre non-dégroupé, et de toutes façons elle manque encore légèrement de fonctionnalités, genre reverse DNS).
DHCP pour l’auto-configuration IPv4
Radvd pour l’auto-configuration IPv6 (comme ça mon routeur masque le tunnel IPv6 et présente l'IPv4 et l'IPv6 sur la même interface).
QoS "basique" sans DPI (je rend prioritaire les flux sur les ports 80 et 443 pour une navigation internet fluide, le reste attendra), marche bien pour mon usage.
Cache DNS (OSEF), mais plus important DNS pour le réseau local.
Éventuellement, faire passer tout mon trafic par un VPN. N'a servi qu'une fois, quand suite à une panne ADSL j'ai dû utiliser ma connexion 3G, mais mon opérateur refusais les usages modem. Autrement je configure plutôt le VPN directement sur les machines.
Pas de réseaux multiples/DMZ/VLAN faute d'assez de ports, mais j'ai un autre routeur directement relié à la freeboiboite pour les services, c'est encore mieux séparé du coup !
[^] # Re: Mo
Posté par Tonton Benoit . En réponse au journal OpenWRT et TP-Link TL-WR710N. Évalué à 5.
Et bientôt en ko si ça continu ! Sur les routeurs l'évolution va dans ce sens, on est passé de 8mo courant à 4mo quasi-généralisé sauf sur les modèles "certifiés open-source", maintenant y'a de plus en plus de modèles "pas chers" équipés de 2mo seulement…
[^] # Re: systemd
Posté par Tonton Benoit . En réponse à la dépêche Petit état de l'art des systèmes d'initialisation (1). Évalué à 6.
Et ce serait pas intéressant de pouvoir rajouter, supprimer, changer, monitorer les instances de postgresql démarrées par l'init via un petit utilitaire ?
Certes on peut rajouter des commandes à /etc/init.d/postgresql, mais autant faire un truc qui marchera partout non ?
Et puis je suis pas fan perso quand l'init fait trop de choses sans même me demander mon avis.
Tu démarre le service pour la première fois t'a une base de données utilisable, bien, très bien, mais si tu ne voulait pas ça ? Si tu voulait importer ta base de données avant ? Raté ! apt-get install postgresql lancera automatiquement l'initscript qui va te créer une base inutile et quand tu va importer la tienne après, l'initscript va gueuler que l'instance 9.1/main entre en conflit avec l'instance 9.1/main. Obligé d'aller lire le contenu du script pour voir comment il fonctionne et comment déboguer alors qu'une commande externe aurait eu sa page de manuel.
Et puis n’espérez transférer une base de donnée de RHEL à Debian comme-ça, la façon dont sont choisies les instances à démarrer est spécifique à chaque distrib, le transfert ne se fera pas sans mal.
[^] # Re: systemd
Posté par Tonton Benoit . En réponse à la dépêche Petit état de l'art des systèmes d'initialisation (1). Évalué à 3. Dernière modification le 05 décembre 2013 à 13:10.
C'est pas comme si j'avais pas cité les bashisms entre-autres.
Quasiment toutes les distribs sont passés à du pure SH (Debian, Gentoo…), mais reste quelques bashisms chez RH par ex, et si l'auteur d'un programme fournit un initscript pour RH, ben ça marchera pas ailleurs.
Après, tous ces init utilisent le même langage, mais pas les mêmes fonctions,
CentOS : /etc/rc.d/init.d/functions
Debian : /lib/lsb/init-functions
Gentoo : /lib/rc/sh/runscript.sh
Et ces fichiers contiennent tous des commandes spécifiques à chaque init (log_warning_msg pour un, ewarn pour l'autre…)
Sortir le gros de la gestion du daemon hors de l'init permet un meilleur contrôle de l'utilisateur via un outil unifié, mais aussi de minimiser le code spécifique à la distribution.
Après bizarre de voir les bsdistes me tomber dessus alors que j'ai cité jail en bon exemple, mais bon j'ai dit systemd, c'est un gros mot.
[^] # Re: systemd
Posté par Tonton Benoit . En réponse à la dépêche Petit état de l'art des systèmes d'initialisation (1). Évalué à 5.
J'ai rien contre le langage shell, mais en mettre un gros pâté dans un initscript est pour moi un indicateur de solution gruik posée à la va-vite. Se sera pas pas portable (bash d'un coté, Ash de l'autre, paths hardcodés, appels de fonctions spécifiques…), pas porté (chacun fera sa petite cuisine dans son coin), inélégant, le contraire du prétendu "esprit" du SysV RC qu'on nous chantes chaque fois qu'on parle de SystemD.
En des temps immémoriaux, à ma première LSF, pour monter les systèmes de fichiers l'initscript était un simple appel à mount -a.
Maintenant pour faire ça t'a des centaines de lignes dans /etc/rc.sysvinit pour RHEL, Pour Debian des milliers de lignes dans /etc/init.d et /etc/network/if-up.d…
Bon ces scripts font des choses utiles genre attendre le réseau pour monter du NSF, des dizaines de mainteneurs de distributions ont implémentés ce genre de truc, mais personne n'a penser à moderniser mount pour qu'ils réponde aux nouveaux besoins de l'init, alors que c'est son rôle :
Des scripts shell je suis le premier à en faire, mais dès que tu te pose la question "comment faire ça proprement ?" ben tu les sort de l'init.
Avec LXC beaucoup de distributions ont ajoutés un initscript "complexe" pour lancer de containers au démarrage.
Alors c'est pratique, tu file le nom de tes containers dans /etc/default/lxc et ils seront démarrés/arrêtés automatiquement.
Mais si j'en arrête un par moi même, l'init gueulera à l’arrêt du service que toto était lancé et qu'il ne l'est plus, ou plein d'autres petits dysfonctionnements.
On s’aperçoit vite que pour faire ça proprement, il faut un système qui permette la gestion complète des containers "automatiques" ajout/suppression/démarrage/arrêt/démarrage-individuel/arrêt-individuel/statut d'un containers/statut de tous les containers… et que la place d'un tel utilitaire n'est pas dans l'init, par contre un l'init peut appeler cet utilitaire pour le démarrage/arrêt du service.
Après faire ça en shell, pourquoi pas, c'est un choix de langage comme un autre.
# Upstart
Posté par Tonton Benoit . En réponse à la dépêche Petit état de l'art des systèmes d'initialisation (1). Évalué à 9. Dernière modification le 03 décembre 2013 à 23:53.
Faut le dire très vite.
RHEL utilise un gros script /etc/rc.sysvinit au démarrage qui se charge de monter les fs, définir le hostname, l'équivalant du niveau rcS de Debian quoi… Après il appelle upstart pour trois merdes (le spash screen, l'initialisation des tty…) puis utilise la couche de compatibilité SysV d'upstart pour lancer les services de /etc/init.d
Bref il utilise Upstart de la façon la plus inutile qu'il soit, su RHEL 7 fait pareil avec SystemD, ça promet !
Bon faut dire après qu'ils sont bloqué avec la version 0.6 d'Upstart qui n'offre même pas de façon propre d'activer/désactiver les services (un comble pour un gestionnaire de services)
[^] # Re: systemd
Posté par Tonton Benoit . En réponse à la dépêche Petit état de l'art des systèmes d'initialisation (1). Évalué à 1.
Pour les performances, cherche pas, on te dira que blabla c’est pas nécessaire sur serveur et que sur le bureau tout le monde utilise systemd de toutes façons.
En tout cas entre SystemD et OpenRC y'a pas photo, surtout que j'ai jamais réussi à faire du lancement parallèle avec OpenRC sans bugs.
Les autres, pas fait de comparaison sérieuses, mais pas l'air très véloces. Après ça vient plus de la lourdeurs des script que des choix technologiques eux-mêmes, regarde les scripts d'init "SysV" de Debian ou RHEL ça reimplemente tout "mount -a" en Bash directement dans l'initscript.
Alors quand je lis que les *BSD ont remplacés des milliers de ligne en shell d'init par une commande "jail -c" je dit bravo, c'est dans ce sens qu'il faut aller, et c'est ce sens qu'encourage SystemD en "virant" l'interprétation shell des fichiers de définition des services.
[^] # Re: État des services une fois le système démarré
Posté par Tonton Benoit . En réponse à la dépêche Petit état de l'art des systèmes d'initialisation (1). Évalué à 4.
Debian, SysV RC, tout autre système sans suivi du processus via pid/cgroups : faut chercher soit-même avec ps, netstat ou parfois /etc/init.d/ status s'il propose la fonction.
Gentoo/OpenRC : rc-status
Upstart : initctl list
Systemd : Déjà dit
[^] # Re: GNU/SystemD/Linux
Posté par Tonton Benoit . En réponse au journal Systemd va gagner une console système, un bootsplash et un login-screen. Évalué à 3. Dernière modification le 02 décembre 2013 à 15:17.
LOL, à pars Debian qui utilise encore cette m sous Linux ? Un système d'init même pas capable de suive le statut des processus qu'il a lancé…
Je suis méchant mais demandez à n'importe qui dans la rue ce que je déteste sur Debian il répondra "le système d'init" et ce que j'aime ? /etc/network/interfaces
[^] # Re: Solutions
Posté par Tonton Benoit . En réponse au message Envoyer une url sur une adresse en gmail sans que Googlebot aille fourrer son nez ensuite. Évalué à 2.
Pas de catchall.
Mais bon mon client peut-être vérolé, ssl peut être cassé par les chinois du fbi, le serveur a peut-être un rootkit…
[^] # Re: Solutions
Posté par Tonton Benoit . En réponse au message Envoyer une url sur une adresse en gmail sans que Googlebot aille fourrer son nez ensuite. Évalué à 2.
Google pas directement, mais indirectement pourquoi pas. Internet est vaste et je ne mettrait pas ma main au feu que personne ne diffuse une liste d'url valides récupérés par "bruteforce" (on teste domaine.ext/a puis domaine.ext/b…) ou dictionnaire (on teste domaine.ext/index.php puis domaine.ext/admin…).
Google est remplis de pages qui ne sont pas sensées être publiques !
Autre domaine, mais tout aussi surprenant, y'a quelque-temps je montais un serveur mail pour une nouvelle association.
J'ai pas encore d'enregistrement MX que je reçoit déjà un spam chinois et directement sur une adresse valide que je vient tout juste de créer. C'étais pas une adresse 'standard' genre admin@ ou postmaster@ mais mon compte perso et tomber direct dessus comme-ça, je ne comprend toujours pas.
[^] # Re: robot.txt ?
Posté par Tonton Benoit . En réponse au message Envoyer une url sur une adresse en gmail sans que Googlebot aille fourrer son nez ensuite. Évalué à 3.
Pourquoi ? Tu interdit juste l'indexage de ton URL privée dans le rebot.txt et plus besoin d'y toucher, le reste du site ne sera pas concerné :
http://www.commentcamarche.net/contents/1268-robots-txt
# Solutions
Posté par Tonton Benoit . En réponse au message Envoyer une url sur une adresse en gmail sans que Googlebot aille fourrer son nez ensuite. Évalué à 8.
Bref tu a fait là une chose du même genre que confondre NAT et firewall ou RAID et sauvegarde ;)
[^] # Re: changer la carte graphique
Posté par Tonton Benoit . En réponse au message Comment lire un vieux HDD SCSI doté d'un connecteur IDC50 ?. Évalué à 4. Dernière modification le 28 novembre 2013 à 01:02.
Du boot sur CD à cette époque, je ne pense pas ! ma carte-mère FIC PT-2200 était une des première capable de faire ça (et de supporter l'USB aussi, en version "draft") en 1997.
Par contre avec un disque-dur (ou même une disquette), pas de raison que ça ne fonctionne pas, reste à faire la bonne 'image' qui bootera sans problème, aura les bons pilotes réseau ou serie et lancera sshd/telnetd.
[^] # Re: unzip/move/zip
Posté par Tonton Benoit . En réponse au message Créer une archive zip de 2Go en modifiant les chemins dans l'archive. Évalué à 5.
Sauf si tu lui demande le contraire, zip ne gère pas les liens symboliques par défaut, donc au lieu de copier vers une destination temporaire, il suffit de faire un symlink vers celle-ci. Plus rapide, moins gourmand.
[^] # Re: ouais enfin non
Posté par Tonton Benoit . En réponse au message Gros malin. Évalué à 2. Dernière modification le 23 novembre 2013 à 15:28.
Le contrôle sur le PlayStore est léger et plus basé sur le signalement à posteriori des applications litigieuses.
Sur l'AppStore d'Apple le contrôle a-priori des applications est plus poussé, mais ça n'a pas évité des problèmes malgré-tout (surtout qu'Apple cherche plus les applications nuisibles pour lui que pour les utilisateurs), et du coup les délais (jusqu'à 10 jours pour voir son application validée) sont assez lourds à supporter pour les développeurs.
[^] # Re: Tags
Posté par Tonton Benoit . En réponse au journal AOL arrête Winamp. Évalué à 2.
QuodLibet à plusieurs vues, dont "répertoire".