[stretch] hdparm -B et sortie de veille
Bonjour, J'ai un portable avec 2 disques: un principal et un autre qui ne fonctionne que rarement. J'avais donc décidé de régler le second avec hdparm -B 1afin qu'il soit coupé au maximum. Pour ce faire j'ai 2 scripts dans /etc/pm/power.d et /etc/pm/sleep.d (script en pj). Jusqu'à maintenant ça fonctionnait mais aujourd'hui je m'aperçois qu'en sortie de veille la valeur est à 128 au lieu de 1. Auriez-vous une idée de la cause ? Gaëtan 50-hdparm_pm Description: application/shellscript 50-hdparm_pm Description: application/shellscript signature.asc Description: This is a digitally signed message part
Re: Les cyber menaces basculent vers Linux et les serveurs Web
Je prends note; je préfère ce genre de solution mécanique plutôt que recourir à la chimie. Merci d'avoir partagé :) Le dimanche 13 août 2017 à 21:46 +0200, Haricophile a écrit : > Le Thu, 10 Aug 2017 10:27:51 +0200, > "Pierre L." a écrit : > > > Les poux !!! > > Prépare ton peigne fin et tes produits anti-poux, sinon tondeuse > > sans > > sabot (équivalent formatage...) ! > > Complètement HS mais comme il s'agit d'un problème récurent, je > réagit > quand même. > > Le problème est résolu depuis l'apparition du peigne Assy2000 : > Un peigne en inox avec des grosses dents rondes avec une cannelure en > spirale gravée au laser qui casse les lentes et les œufs de poux. > > Fini les produits, ça marche en préventif (une ou deux fois par > semaine) et en curatif (2 ou 3 fois par jour), c'est presque > inusable, > ça peux servir à l'infirmière scolaire pour toute une classe en > passant > sous l'eau bouillante entre chaque tête et c'est autorisé puisque pas > de > produit ! et si je fais la pub pour ce modèle c'est qu'il a été créé > et > mis au point avec des subventions de l'OMS je crois afin de résoudre > le > problème des poux dans les pays du tiers-monde (c'est pas cher). Il > s'agit réellement d'une grande avancée dans la santé publique faite à > moindre coût. > > Le seul problème est de trouver un pharmacien qui accepte de te le > vendre vu qu'il va perdre la très juteuse rente de ses > produits toxiques : santé publique vs business... > > Et je peut te garantir que pour l'avoir utilisé dans un village ou > personne n'avait de poux mais où le pharmacien te disait franchement > : > « Ça m'étonnerait beaucoup vu la quantité de produits que je vend », > je > lui ait fait du tort à son chiffre d'affaire en donnant des peignes > au > médecin scolaire du collège et de l'école, mais c'était un pharmacien > bien qui pensait que la santé des enfant passait avant son intérêt > personnel et il a référencé le peigne. > > >
Re: renommer l'interface réseau
Bonjour, On 08/14/2017 04:49 PM, bernard.schoenac...@free.fr wrote: > en vérifiant le nom de mon interface réseau, je constate qu'elle > a changé de désignation (enp3s0) comment corriger le tir ? Ce n'est pas indiqué dans le message mais on va supposer que c'est sur Debian Stretch. > merci de m'indiquer le fil de discussion Voir dans la page man systemd.link(5) au niveau de l'exemple 2. Cela donne le type de fichier à créer pour fixer le nom d'une interface réseau (en "eth0" par exemple etc). Je pense que c'est « la bonne » façon de faire sur Stretch. On ne passe plus par udev mais par systemd (qui lui-même fait peut-être appel à udev, je ne sais pas). Il faut reconnaître que la syntaxe du fichier est on ne peut plus simple. -- François Lafont
Re: renommer l'interface réseau
À mon avis il ne faut pas mettre au même niveau les device node (niveau périphérique) et les UUID (niveau système de fichiers) sauf erreur de ma part) Par contre, identifier les systèmes à monter par leur UUID est un véritable progrès : je me suis déjà fait pourrir la vie par un lecteur capricieux dont les dysfonctionnements aléatoires décalaient toute l'énumération, avec un échec de boot à la clef. Le 15 août 2017 6:32 PM, "Pierre L." a écrit : Dans le même registre, mais coté disques durs, je vois toujours des histoires de sda/sdb/sdX, c'est un peu le même principe à mon avis... Certes les UUIDs dans la fstab sont gérées, mais les quelques commandes que j'utilise me ressortent toujours ces sdX...? Prochaine étape ? Le 14/08/2017 à 16:55, JF Straeten a écrit : > C'est voulu sous Stretch, voir ici : > > https://www.debian.org/releases/stable/amd64/release- notes/ch-whats-new.fr.html#new-interface-names > > La méthode de retour est décrite aussi. > > A+
Re: renommer l'interface réseau
Le 15/08/2017 à 18:31, Pierre L. a écrit : Dans le même registre, mais coté disques durs, je vois toujours des histoires de sda/sdb/sdX, c'est un peu le même principe à mon avis... Ça dépend de quoi on parle. Le nommage initial des disques et des interfaces réseau par le noyau suit le même principe : les périphériques peuvent apparaître dans n'importe quel ordre et sont nommés par le noyau dans l'ordre de leur apparition. Par contre la gestion de la situation par udev dans les deux cas est totalement différente. Dans le cas des interfaces réseau, udev les renomme avec des noms stables, alors que dans le cas des disques udev leur crée des alias stables. C'est seulement la méthode de renommage des interfaces réseau qui a changé entre Jessie et Stretch.
Re: renommer l'interface réseau
Dans le même registre, mais coté disques durs, je vois toujours des histoires de sda/sdb/sdX, c'est un peu le même principe à mon avis... Certes les UUIDs dans la fstab sont gérées, mais les quelques commandes que j'utilise me ressortent toujours ces sdX...? Prochaine étape ? Le 14/08/2017 à 16:55, JF Straeten a écrit : > C'est voulu sous Stretch, voir ici : > > https://www.debian.org/releases/stable/amd64/release-notes/ch-whats-new.fr.html#new-interface-names > > La méthode de retour est décrite aussi. > > A+ signature.asc Description: OpenPGP digital signature
Re: Les cyber menaces basculent vers Linux et les serveurs Web
Le 13/08/2017 à 21:46, Haricophile a écrit : >> Les poux !!! >> Prépare ton peigne fin et tes produits anti-poux, sinon tondeuse sans >> sabot (équivalent formatage...) ! > Complètement HS mais comme il s'agit d'un problème récurent, je réagit > quand même. Haha ! Superbe présentation du produit écolo/économique tueur de lobbys pour saletés à s'enduire le crâne ! (Oui c'est bon de temps en temps un gros HS esprit libre, et aussi riche en partage !) Même si entre nous, le produit devrait évoluer pour avoir l'occasion de renouveler son nom, le "2000" fait maintenant un peu moins vendeur... Mais que pense la ligue de la protection des poux quand ils abordent le sujet qu'est cette arme de destruction massive ? signature.asc Description: OpenPGP digital signature
Re: CUPS
Merci Benoit pour ton retour ! Oui j'avais omis cette option de changer de pilote, certainement parce que la dernière fois celui-ci même ne de vait pas fonctionner :p Je m'en va tenter ca dès le retour... en croisant les doigts... Mais ca parait bien parti si tu es ok :) Le 11/08/2017 à 11:41, Benoit B a écrit : > Si je remet le CUPS+Gutenprint V5.2.11, ça ne fonctionne plus, voila > la seule chose reproductible. Désolé de ne pas pouvoir apporter > quelque chose de constructif. signature.asc Description: OpenPGP digital signature
Re: installation samba incomplète dans stretch 9.1
Bonjour Fausse alerte. J'ai re-réinstallé une 9.1 depuis deb.debian.org Terminal, root, installation de samba. status smbd.dervice : running. Je ne sais pas ce que j'ai pu faire et qui a provoqué le précédent échec. Bon 15 aout !
installation samba incomplète dans stretch 9.1
Bonjour Le contexte : Netinst d'une 9.1 "toute neuve" sur un disque entier, sans personnalisation particulière. Source list : deb http://deb.debian.org/debian/ stretch main contrib non-free deb http://security.debian.org/ stretch/updates main contrib non-free deb http://deb.debian.org/debian/ stretch-updates main contrib non-free J'ai déjà installé samba (sans cups) sur d'autres machines avec simplement : (root) > apt-get install samba Résultat : il manque des paquets et si j'essaie d'ajouter ce qui manque, ça provoque d'autres arrêts sans solution (avec mes compétences). J'ai ajouté dans source list: deb http://deb.debian.org/debian/ stretch-proposed-updates main contrib non-free deb http://deb.debian.org/debian stretch-backports main contrib non-free Résultat : action "start" failed Samba detected misconfigured 'server role' and exited. Check logs for details, error code 22 Les logs ne me donnent pas d'info que je sais interpréter. Ma question de départ est simple : samba est-il dispo pour la 9.1 ou je dois juste attendre et refaire un apt-get install samba dans quelques jours / semaines ?
Re: problème reconnexion ppp0 au démarrage (stretch)
Le 15/08/2017 à 01:14, Louis-Philippe a écrit : Mon interface ppp0 ne se monte plus automatiquement au démarrage de mon serveur suite à la migration à Debian Stretch. Si je fais la commande "pon dsl-provider", tout fonctionne bien. Et avec ifup ? Un ifup eth0 donne : ifup: interface eth0 already configured Je parlais de la connexion PPPoE, pas de l'interface ethernet sous-jacente. D'après le fichier interface, c'est dsl-provider. Voici les 4 lignes concernant mon interface. (J'ai une eth1 qui est pour le lan...): auto dsl-provider iface dsl-provider inet ppp provider dsl-provider iface eth0 inet manual Je mettrais eth0 avant dsl-provider, c'est mieux si elle est activée avant que la connexion PPPoE soit démarrée. As-tu regardé dans les logs (/var/log/syslog notamment) ? au moment du reboot : Je suis à chercher l'information pour le "Terminating on signal 15" Aug 14 19:00:53 toto pppd[499]: Plugin rp-pppoe.so loaded. Aug 14 19:00:53 toto pppd[506]: pppd 2.4.7 started by root, uid 0 Aug 14 19:00:53 toto pppd[506]: error sending pppoe packet: Network is down Aug 14 19:00:53 toto pppd[506]: error receiving pppoe packet: Network is down Je suppose que c'est parce que eth0 n'est pas encore activée. La permutation dans le fichier interface devrait corriger cela. Mais cela ne semble pas bloquant. A cause de l'asynchronisme de l'init, je pensais que l'interface ethernet pouvait ne pas encore exister au moment où pppd est lancé. Mais visiblement ce n'est pas le cas. Aug 14 19:00:58 toto pppd[506]: PPP session is 1417 Aug 14 19:00:58 toto pppd[506]: Connected to 00:11:ZZ:YY:XX:XX via interface eth0 Aug 14 19:00:58 toto pppd[506]: Using interface ppp0 Aug 14 19:00:58 toto pppd[506]: Connect: ppp0 <--> eth0 Aug 14 19:00:59 toto pppd[506]: Terminating on signal 15 Aug 14 19:01:02 toto pppd[506]: Connection terminated. Aug 14 19:01:02 toto pppd[506]: Exit. Donc quelque chose envoie un signal de fin SIGTERM à pppd. Mais je n'ai pas la moindre idée de quoi. Tu peux ajouter l'option "debug" au fichier /etc/ppp/peers/dsl-provider pour avoir des logs plus détaillés.