Re: Installation de VirtualBox par les dépots Debian?
On 28/03/24 at 03:57 +0100, hamster wrote: > Le 27/03/2024 à 10:29, Alex PADOLY a écrit : > > Bonsoir à tous, > > > > > > Peut-on installer VirtualBox par les dépôts Debian, en effet > > l'installation à partir du paquet Debian sur le site d'Oracle génère des > > erreurs difficiles à résoudre. > > Je suis pas sur d'avoir bien compris mais j'ai lu un truc du genre "la boite > qui fait virtualbox a été rachetée par une boite pas du tout favorable aux > valeurs du libre, virtualbox a cessé d'etre libre et donc a été virée des > dépots débian". VirtualBox est libre (les paquets sont dans Debian "contrib" pour unstable, car ils dépendent d'un autre paquet non libre), mais Oracle refuse de fournir des détails sur les problèmes de sécurité, ce qui rend impossible une intégration dans Debian stable. Voir https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=794466#215 A ma connaissance la situation n'a pas évolué depuis ce message. Lucas
Re: Installation de VirtualBox par les dépots Debian?
On 27/03/24 at 12:29 +0300, Alex PADOLY wrote: > Bonsoir à tous, > > Peut-on installer VirtualBox par les dépôts Debian, en effet l'installation > à partir du paquet Debian sur le site d'Oracle génère des erreurs difficiles > à résoudre. Bonjour, Des paquets pour VirtualBox sont disponibles dans fasttrack.debian.net Voir https://wiki.debian.org/VirtualBox#Debian_10_.22Buster.22.2C_Debian_11_.22Bullseye.22.2C_and_Debian_12_.22Bookworm.22 Lucas
Re: Smokeping et ce de systemd
On 25/03/19 at 07:24 +0100, BERTRAND Joël wrote: > Lucas Nussbaum a écrit : > > > > Et quand tu lances smokeping à la main avec /usr/sbin/smokeping > > --pid-dir=/run/smokeping, où crée-t-il smokeping.pid ? > > > > est-ce que tu peux faire 'systemctl cat smokeping.service' pour vérifier > > que tu as bien le même contenu que ci-dessus (cad que tu n'as pas > > d'overrides dans /etc) ? > > Root rayleigh:[/lib/systemd/system] > systemctl cat smokeping.service > # /lib/systemd/system/smokeping.service > [Unit] > Description=Latency Logging and Graphing System > Documentation=man:smokeping(1) > file:/usr/share/doc/smokeping/examples/systemd/slave_mode.conf > After=network.target > > [Service] > # It would in theory be simpler to run smokeping with the --nodaemon > option and > # Type=simple, but smokeping does not work properly when in "slave" mode > with > # --nodaemon set. > Type=forking > RuntimeDirectory=smokeping > PIDFile=/run/smokeping/smokeping.pid > User=smokeping > Group=smokeping > StandardError=syslog > > # If you need to run smokeping in slave/master mode, see the example unit > # override in /usr/share/doc/smokeping/examples/systemd/slave_mode.conf > ExecStart=/usr/sbin/smokeping --pid-dir=/run/smokeping > > ExecReload=/bin/kill -HUP $MAINPID > > [Install] > WantedBy=multi-user.target > Root rayleigh:[/lib/systemd/system] > > > Ça semble bien être la même chose (petite remarque en passant, le truc > qui intercepte les scripts SysV me semble lui aussi être une connerie > sans nom au fonctionnement aléatoire dans le machin systemd, on est bien > loin du KISS du monde Unix...). > > Si je lance le daemon à la main : > Root rayleigh:[/lib/systemd/system] > /usr/sbin/smokeping > --pid-dir=/run/smokeping > > je récupère un pid dans /run : > Root rayleigh:[/lib/systemd/system] > ls /run/ > ... > smokeping.pid > ... > > Je pensais naïvement qu'il devait être dans > /run/smokeping/smokeping.pid... > > Même si je crée avant de lancer smokeping un répertoire /run/smokeping, > je me retrouve avec le pid dans /run/smokeping.pid. Voila, donc à la fin, c'est un probleme coté smokeping qui ne semble pas respecter l'option --pid-dir. Rien à voir avec systemd. Je t'invite à ouvrir un bug sur le paquet smokeping. Lucas
Re: Smokeping et ce de systemd
On 24/03/19 at 22:26 +0100, BERTRAND Joël wrote: > Lucas Nussbaum a écrit : > > Qu'as-tu juste après ? Dans le paquet, j'ai: > > ExecStart=/usr/sbin/smokeping --pid-dir=/run/smokeping > > > > qui demande donc à smokeping d'écrire son fichier .pid dans > > /run/smokeping. > > > > Donc, soit: > > - cette ligne n'est pas présente > > - cette ligne ne fonctionne pas > > Voici le fichier complet (jamais touché) : > > > Root rayleigh:[/lib/systemd/system] > cat smokeping.service > [Unit] > Description=Latency Logging and Graphing System > Documentation=man:smokeping(1) > file:/usr/share/doc/smokeping/examples/systemd/slave_mode.conf > After=network.target > > [Service] > # It would in theory be simpler to run smokeping with the --nodaemon > option and > # Type=simple, but smokeping does not work properly when in "slave" mode > with > # --nodaemon set. > Type=forking > RuntimeDirectory=smokeping > PIDFile=/run/smokeping/smokeping.pid > User=smokeping > Group=smokeping > StandardError=syslog > > # If you need to run smokeping in slave/master mode, see the example unit > # override in /usr/share/doc/smokeping/examples/systemd/slave_mode.conf > ExecStart=/usr/sbin/smokeping --pid-dir=/run/smokeping > > ExecReload=/bin/kill -HUP $MAINPID > > [Install] > WantedBy=multi-user.target > Root rayleigh:[/lib/systemd/system] > > > Naturellement, /run existe et un lien /var/run vers /run existe aussi. Et quand tu lances smokeping à la main avec /usr/sbin/smokeping --pid-dir=/run/smokeping, où crée-t-il smokeping.pid ? est-ce que tu peux faire 'systemctl cat smokeping.service' pour vérifier que tu as bien le même contenu que ci-dessus (cad que tu n'as pas d'overrides dans /etc) ? Lucas
Re: Smokeping et ce de systemd
(Merci de me Cc les réponses éventuelles, je ne suis pas la liste de près) Bonsoir, On 24/03/19 at 19:46 +0100, BERTRAND Joël wrote: > Bonsoir à tous, > > Je viens d'avoir un plantage sévère sur un serveur (kernel panic avec > le dernier noyau de testing). Au redémarrage, je m'aperçois que > smokeping ne se lance pas : > > Root rayleigh:[/run] > systemctl status smokeping.service > ● smokeping.service - Latency Logging and Graphing System >Loaded: loaded (/lib/systemd/system/smokeping.service; enabled; > vendor preset: enabled) >Active: failed (Result: timeout) since Sun 2019-03-24 18:06:51 CET; > 1h 32min ago > Docs: man:smokeping(1) >file:/usr/share/doc/smokeping/examples/systemd/slave_mode.conf > > mars 24 18:05:21 rayleigh smokeping[11095]: All probe processes started > successfully. > mars 24 18:05:21 rayleigh smokeping[11097]: FPing: probing 7 targets > with step 300 s and offset 279 s. > mars 24 18:05:21 rayleigh systemd[1]: smokeping.service: Can't open PID > file /run/smokeping/smokeping.pid (yet > mars 24 18:06:51 rayleigh systemd[1]: smokeping.service: Start operation > timed out. Terminating. > mars 24 18:06:51 rayleigh smokeping[11095]: Got TERM signal, terminating > child processes. > mars 24 18:06:51 rayleigh smokeping[11096]: got TERM signal, terminating. > mars 24 18:06:51 rayleigh smokeping[11097]: got TERM signal, terminating. > mars 24 18:06:51 rayleigh smokeping[11095]: All child processes > successfully terminated, exiting. > mars 24 18:06:51 rayleigh systemd[1]: smokeping.service: Failed with > result 'timeout'. > mars 24 18:06:51 rayleigh systemd[1]: Failed to start Latency Logging > and Graphing System. > > Très bien. Donc, systemd démarre smokeping, s'attend à ce qu'il crée un fichier avec son PID (/run/smokeping/smokeping.pid), mais il ne le fait pas, donc systemd décide qu'il n'a pas démarré correctement, et l'arrête. > Un tour dans les logs (les vrais) donne : > > Mar 24 18:05:21 rayleigh smokeping[11086]: Starting syslog logging > Mar 24 18:05:21 rayleigh smokeping[11086]: Note: logging to syslog as > local0/info. > Mar 24 18:05:21 rayleigh smokeping[11086]: Daemonizing > /usr/sbin/smokeping ... > Mar 24 18:05:21 rayleigh smokeping[11086]: creating > /var/run/smokeping.pid: Permission denied > Mar 24 18:05:21 rayleigh smokeping[11095]: Smokeping version 2.007003 > successfully launched. > Mar 24 18:05:21 rayleigh smokeping[11095]: Entering multiprocess mode. > Mar 24 18:05:21 rayleigh smokeping[11095]: Child process 11096 started > for probe FPing6. > Mar 24 18:05:21 rayleigh smokeping[11096]: FPing6: probing 2 targets > with step 300 s and offset 201 s. > Mar 24 18:05:21 rayleigh smokeping[11095]: Child process 11097 started > for probe FPing. > Mar 24 18:05:21 rayleigh smokeping[11095]: All probe processes started > successfully. > Mar 24 18:05:21 rayleigh smokeping[11097]: FPing: probing 7 targets with > step 300 s and offset 279 s. > Mar 24 18:05:21 rayleigh systemd[1]: smokeping.service: Can't open PID > file /run/smokeping/smokeping.pid (yet?) after start: No such file or > directory > Mar 24 18:06:51 rayleigh systemd[1]: smokeping.service: Start operation > timed out. Terminating. > Mar 24 18:06:51 rayleigh smokeping[11095]: Got TERM signal, terminating > child processes. > Mar 24 18:06:51 rayleigh smokeping[11096]: got TERM signal, terminating. > Mar 24 18:06:51 rayleigh smokeping[11097]: got TERM signal, terminating. > Mar 24 18:06:51 rayleigh smokeping[11095]: All child processes > successfully terminated, exiting. > Mar 24 18:06:51 rayleigh systemd[1]: smokeping.service: Failed with > result 'timeout'. > > Ce qui est intéressant, c'est le "creating /var/run/smokeping.pid: > Permission denied". oui. Car du coup, ça veut dire que smokeping essaie de créer un fichier .pid, mais pas à l'endroit attendu dans le fichier .service. Même s'il avait réussi, systemd ne l'aurait pas trouvé et l'aurait tué. > Et là, je ne comprends pas. smokeping se lance en tant que smokeping. > Mais systemd le sait, c'est sans son fichier de configuration : > > [Service] > # It would in theory be simpler to run smokeping with the --nodaemon > option and > # Type=simple, but smokeping does not work properly when in "slave" mode > with > # --nodaemon set. > Type=forking > RuntimeDirectory=smokeping > PIDFile=/run/smokeping/smokeping.pid > User=smokeping > Group=smokeping > StandardError=syslog Qu'as-tu juste après ? Dans le paquet, j'ai: ExecStart=/usr/sbin/smokeping --pid-dir=/run/smokeping qui demande donc à smokeping d'écrire son fichier .pid dans /run/smokeping. Donc, soit: - cette ligne n'est pas présente - cette ligne ne fonctionne pas Lucas
Re: renommer en masse des fichiers m4a.mp3 en mp3
On 18/08/16 at 10:33 +0200, Bernard Schoenacker wrote: > bonjour, > > après avoir encodé au format mp3, je me retrouve avec des fichiers > nommés : > > mon_fichier.m4a.mp3 > > > comment supprimer le m4a ? Dans le paquet Debian moreutils, il y a la commande vidir, qui ouvre un éditeur de texte avec le contenu du répertoire. Tu peux y modifier les noms (renommer) ou supprimer des lignes (supprimer des fichiers). Lucas
Re: initd et syvinit
On 27/05/15 at 16:51 +0200, David Pinson wrote: > Est-ce que quelqu'un peut me répondre pourquoi mes 2 PC se mettent en > hibernation toutes les 30 secondes. > (vérifié montre en mains!). Que ce soit en console (debian de base) ou avec > interface graphique (LXDE), c'est le même problème et j'ai déjà trouvé le > coupable : systemd ! D'un autre côté, tu n'as pas daigné répondre à ma question sur la présence d'informations dans le journal qui auraient pu aiguiller sur la source du problème. C'est probablement beaucoup plus facile de se plaindre :-) Lucas -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe" vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: https://lists.debian.org/20150527171227.ga5...@xanadu.blop.info
Re: [RESOLU] Voulez-vous avec ou sans systemd ? (était Re: apache2 ne redémarre plus - supprimer systemd)
On 26/05/15 at 19:07 +0200, David Pinson wrote: > Le 25/05/2015 21:37, maderios a écrit : > >On 05/25/2015 08:32 PM, Erwan David wrote: > >>Le 25/05/2015 20:27, maderios a écrit : > >>>On 05/25/2015 06:21 PM, David Pinson wrote: > > Difficile de voir clair avec systemd... > Pour ceux qui veulent se débarrasser de systemd.. > Suivez ces instructions du wiki "without systemd" > > >>>Salut > >>>C'est reculer pour mieux sauter. Ce ne serait pas plus simple de > >>>commencer par le commencement: lire une doc/wiki sur Systemd et ses > >>>commandes? > >> > >>T'en as de bons à conseiller s'adressant à des admins unix ? (plutôt doc > >>que wiki pour moi dans un premier temps, avec une progression et un > >>ordre de lecture). > >> > >La doc est abondante sur le net. > >(Merci de ne pas m'adresser de mail personnel) > > > J'avais Debian 7 et je me suis lancé à la migration qui s'est bien passé, > sauf un cas ! > Est-ce que quelqu'un peut me répondre pourquoi mon PC se met en hibernation > toutes les 30 secondes. > > Je n'ai pas trouvé d'écho dans les informations (wiki, tutos, forums, etc..) > > En reinstallant syvinit puis procédant à la désinstallation de systemd, le > problème a disparu... Ouch. Y a-t-il qqchose dans journalctl qui pourrait mettre sur une piste ? Lucas -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe" vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: https://lists.debian.org/20150526192633.ga5...@xanadu.blop.info
Re: [RESOLU] Voulez-vous avec ou sans systemd ? (était Re: apache2 ne redémarre plus - supprimer systemd)
On 25/05/15 at 20:27 +0200, maderios wrote: > On 05/25/2015 06:21 PM, David Pinson wrote: > > > >Difficile de voir clair avec systemd... > >Pour ceux qui veulent se débarrasser de systemd.. > >Suivez ces instructions du wiki "without systemd" > > > Salut > C'est reculer pour mieux sauter. Ce ne serait pas plus simple de commencer > par le commencement: lire une doc/wiki sur Systemd et ses commandes? Il y a quelques semaines, j'ai préparé quelques slides d'intro à systemd: https://github.com/lnussbaum/slides-lectures/raw/master/systemd.pdf Je suis preneur de retours/questions pour les améliorer. Pour l'instant, c'est en anglais. Je les traduirai en français que je serai suffisamment satisfait de l'état en anglais. Lucas -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe" vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: https://lists.debian.org/20150525200723.ga27...@xanadu.blop.info
Re: DésaStreuse communication sur la page 'Debian bug tracking system'
On 21/05/15 at 14:35 +0900, Charles Plessy wrote: > Le Wed, May 20, 2015 at 09:12:09AM +0200, maderios a écrit : > > > > Le choix des mots du sujet 'Désastreuse communication' est important. > > Une 'communication' s'adresse à un public pas forcément initié, un simple > > utilisateur. Les pages arch et gentoo (il y en a d'autres) permettent de > > balayer du regard la liste des bugs. > > C'est un minimum, simple et efficace. > > Bonjour, > > je pense que le BTS est conçu en premier lieu pour les responsables de > paquets. > On peut déplorer qu'il n'y ait pas de présentation tabulaire des données, mais > la solution au problème, ça serait d'envoyer un patch. > > Ou alors, le BTS exporte ses données dans la « banque de données ultime de > Debian » (https://udd.debian.org/), et un autre « patch bienvenu » pourrait > créer une interface qui produirait une table comme chez Arch ou Gentoo. https://udd.debian.org/bugs/?release=stretch&merged=ign&fnewerval=7&flastmodval=7&dmd=1&packages=iceweasel&sortby=id&sorto=asc&format=html#results ? Lucas -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe" vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: https://lists.debian.org/20150521085949.ga22...@xanadu.blop.info
Re: Jessie et habitude vis à vis de systemd
On 12/05/15 at 21:50 +0200, Christophe Mehay wrote: > Je me permets de répondre car je souhaiterais apporter quelques précisions > sur la raison pour laquelle unbound ici n'affiche pas d'erreur. > > Je pense que vous vous fourvoyez sur la façon dont systemd démarre les > services, il n'y a pas de binaire compatible ou non avec systemd, la réalité > c'est qu'un service initialisé avec systemd doit dans l'idéal ne pas forker > lui-même, Non, systemd supporte les deux cas (fork avec Type=forking, pas de fork avec Type=simple). La motivation forte pour ne pas forker, c'est que ce n'est pas forcément utile, donc autant ne pas le faire. Mais on a vu dans cette discussion qu'utiliser Type=forking fournissait une manière peu chère de signaler qu'une partie de l'initialisation du service s'était bien passée, notamment pour détecter des problèmes de configuration. Mais c'est loin d'être parfait: le service pourrait très bien lire sa config après avoir forké. Et il y a des opérations d'initialisation qui sont souvent faites après le fork, par exemple ouvrir le port réseau du service. S'il y a un autre service qui écoute sur le port, ça serait alors non détecté. Du coup, la vraie solution, c'est utiliser /socket activation/, ou Type=notify, pour que le service soit vraiment opérationnel à la fin de son démarrage. > et dans le cas présent, unbound n'utilise pas un service systemd > mais le script de sysvinit démarré via systemd. > > Le soucis que l'on a avec ce système, c'est que systemd n'a plus de pid du > processus attaché à lui-même, et il ne se contente que d'exécuter le script > qui va forker unbound avec start-stop-daemon unbound. > > Pour systemd, le script a bien été exécuté et il a quitté correctement vu > que c'est ce qu'on lui a demandé de faire. > > Le problème vient ici du fait que le mainteneur n'a pas fait de fichier > .service conforme pour unbound mais a préféré utiliser le script de sysvinit > au dessus de systemd, ce qui fonctionne dans le meilleur des cas, mais qui > n'est pas correcte. Oui et non. Pour utiliser les scripts sysv, systemd génère à la volée des fichiers .service englobant le script d'init (visible avec systemctl cat unbound). Et il le fait plutôt bien (gestion des en-têtes LSB, des dépendances, etc, cf http://www.freedesktop.org/software/systemd/man/systemd-sysv-generator.html). Utiliser un fichier .service ne réglerait vraiment le problème que si le service n'utilise pas Type=simple, mais ce n'est pas forcément simple ;) Voir une discussion sur le cas de sshd (qui utilise type=simple, ce qui empêche de détecter au lancement des erreurs de configuration): https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=778913#30 Lucas -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe" vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: https://lists.debian.org/20150513054225.ga8...@xanadu.blop.info
Re: Jessie et habitude vis à vis de systemd
On 10/05/15 at 11:38 +0200, Wallace wrote: > Bonjour, > Je tâche depuis la sortie officielle de me dire que si systemd est > fourni c'est qu'il l'est sans bug et sans régression aussi par rapport à > mes tests pré sortie j'essaye de ne plus être négatif sauf que j'ai > vraiment l'impression d'avoir perdu. > > Exemple récent, serveur physique chez un hébergeur, installée Jessie, il > est installé par défaut Bind pour la résolution dns, je veux changer et > mettre Unbound à la place. > > service bind9 stop > > Première remarque avant on savait si un processus était bien démarré ou > éteint là j'en sais strictement rien, mais après tout il pourrait juste > afficher les erreurs et ne rien afficher si tout se passe bien, de plus > mon zsh m'affiche le code retour si il est en erreur et là rien ok. > > apt-get install unbound ok pas de soucis > > Je télécharge la configuration localhost only que j'ai d'unbound qui > fonctionne sur Debian 6 et 7 et je lance > > service unbound start > > Là toujours rien d'affiché, mon shell me dit que la commande s'est bien > exécutée mais dans les faits unbound ne s'est pas lancé... > Là pour moi il y a clairement régression, avant j'avais une ligne qui > m'aurait dit erreur au démarrage, là rien et pire le code retour est bon > ce qui fait qu'il est impossible de scripter autour des services de > démarrage ... En fait, ça dépend des cas. Dans ton cas (erreur de configuration), le service est bien démarré, mais juste après avoir démarré, il lit sa configuration, découvre qu'elle est fausse, et sort immédiatement. Le problème, c'est que comme le service avait bien démarré, systemctl ou 'service' avait déjà retourné que tout s'était bien passé. Avec sysvinit, ça fonctionnait un peu différemment: comme le service plantait avant de forker, start-stop-daemon détectait qu'il plantait et affichait un message d'erreur. (qui d'ailleurs, ne résulte pas en un code de retour différent de 0) La "bonne" solution avec systemd serait probablement que unbound "prévienne" systemd qu'il s'est correctement initialisé. C'est possible avec un Type=notify, et systemd-notify / sd_notify. Mais à part ça, c'est dur de trouver une solution: combien de temps systemd devrait-il attendre après le lancement d'un service pour conclure que "c'est bon, il tourne depuis X secondes, on peut dire que s'il a a pas planté jusque là, il fonctionne vraiment!" ? > Ensuite réflex je fais un tail de /var/log/syslog pour trouver un > message d'erreur et là rien. J'introduis volontairement une ligne non > conforme dans le fichier de configuration pour voir et là rien aussi, > aucun log dans syslog. > Je suppose que c'est systemd qui a attrapé ces logs mais vu que ce n'est > pas du fichier texte et qu'il faut passer par une commande que j'arrive > pas encore à retenir ... > J'ai fait la même erreur dans le fichier config sur Debian 6 et 7 j'ai > bien mes logs et le script de démarrage me précise bien que le processus > n'a pas démarré. Alors ça, par contre, ça m'étonne beaucoup. J'ai testé: J'ai modifié /etc/unbound/unbound.conf pour y ajouter une erreur. J'ai redémarré unbound (service unbound restart). Je n'ai pas de message d'erreur à cause du problème ci-dessus. Mais avec 'service unbound status, qui appelle en fait 'systemctl status unbound', j'ai bien l'extrait de log: # service unbound status ● unbound.service - (null) Loaded: loaded (/etc/init.d/unbound) Drop-In: /run/systemd/generator/unbound.service.d └─50-insserv.conf-$named.conf, 50-unbound-$named.conf Active: active (exited) since Tue 2015-05-12 10:44:36 CEST; 1min 17s ago Process: 1827 ExecStop=/etc/init.d/unbound stop (code=exited, status=0/SUCCESS) Process: 1834 ExecStart=/etc/init.d/unbound start (code=exited, status=0/SUCCESS) May 12 10:44:36 debian unbound-anchor[1843]: /var/lib/unbound/root.key has content May 12 10:44:36 debian unbound-anchor[1843]: success: the anchor is ok May 12 10:44:36 debian unbound[1834]: Starting recursive DNS server: unbound/etc/unbound/unboundqqd' May 12 10:44:36 debian unbound[1834]: read /etc/unbound/unbound.conf failed: 1 errors in configur...file May 12 10:44:36 debian unbound[1834]: [1431420276] unbound[1845:0] fatal error: Could not read co...conf May 12 10:44:36 debian unbound[1834]: failed! Hint: Some lines were ellipsized, use -l to show in full. J'ai les mêmes messages avec 'journalctl', et dans /var/log/syslog Aurais-tu désactivé la redirection vers syslog, par hasard ? (ForwardToSyslog= dans /etc/systemd/journald.conf) Lucas -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe" vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: https://lists.debian.org/20150512085826.ga6...@xanadu.blop.info
Re: migration jessie : empecher mise en veille laptop fermé
On 23/04/15 at 13:03 +0200, Olivier Marceau wrote: > Salut, > > Essaie de modifier /etc/systemd/logind.conf... Oui, avec HandleLidSwitch=lock (par exemple) Lucas -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe" vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: https://lists.debian.org/20150423130208.ga27...@xanadu.blop.info
Re: HS_Re: Debian 8 bientôt publiée !
On 14/04/15 at 15:57 +0200, Vincent Lefevre wrote: > On 2015-04-09 15:22:15 +0200, Lucas Nussbaum wrote: > > On 09/04/15 at 12:46 +0200, Vincent Lefevre wrote: > > > On 2015-04-08 20:35:06 +0200, maderios wrote: > > > > On 04/08/2015 05:50 PM, Vincent Lefevre wrote: > > > > >On 2015-04-07 18:59:29 +0200, maderios wrote: > > > > >>Systemd ne sera jamais "fini" mais pour le moment, avec Debian, c'est > > > > >>stable par rapport aux débuts. > > > > > > > > > >Il faudrait surtout qu'il n'y ait plus de régression par rapport > > > > >à sysvinit. > > > > > > > > > Vu la prudence légendaire de Debian, dernière distrib à adopter > > > > systemd, le risque est mince... Tu as constaté une régression? > > > > > > Pas encore testé systemd (vu que mes deux vieilles machines vont > > > bientôt être remplacées), mais d'après ce que j'ai lu, il y a le > > > verbose qui n'est pas implémenté. > > > > Qu'appeles-tu "le verbose" ? (quelles infos veux-tu ?) > > Des messages sur ce qui est fait lors du boot. > > Il y a aussi ça: > > http://cgit.freedesktop.org/systemd/systemd/tree/TODO > - Add a verbose mode to "systemctl start" and friends that explains > what is being done or not done > > Cf la discussion > > | Date: Wed, 11 Mar 2015 18:16:48 -0300 > | From: Martinx - ジェームズ > | To: Debian User > | Subject: No feedback from systemd / "systemctl stop X"... Nothing > | on stdout, nothing that `echo $?` can see... Franchement, je te conseille d'essayer et de te faire ta propre opinion. Concernant les messages de boot, ils sont cachés par défaut, mais tu peux appuyer sur ESC pour les voir. Et une grosse différence entre systemd et sysvinit, c'est qu'avec systemd, tu peux voir ce qui a effectivement démarré, après le boot, avec 'systemctl status'. Lucas -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe" vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: https://lists.debian.org/20150415131055.ga3...@xanadu.blop.info
Re: HS_Re: Debian 8 bientôt publiée !
On 09/04/15 at 12:46 +0200, Vincent Lefevre wrote: > On 2015-04-08 20:35:06 +0200, maderios wrote: > > On 04/08/2015 05:50 PM, Vincent Lefevre wrote: > > >On 2015-04-07 18:59:29 +0200, maderios wrote: > > >>Systemd ne sera jamais "fini" mais pour le moment, avec Debian, c'est > > >>stable par rapport aux débuts. > > > > > >Il faudrait surtout qu'il n'y ait plus de régression par rapport > > >à sysvinit. > > > > > Vu la prudence légendaire de Debian, dernière distrib à adopter > > systemd, le risque est mince... Tu as constaté une régression? > > Pas encore testé systemd (vu que mes deux vieilles machines vont > bientôt être remplacées), mais d'après ce que j'ai lu, il y a le > verbose qui n'est pas implémenté. Qu'appeles-tu "le verbose" ? (quelles infos veux-tu ?) Lucas -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe" vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: https://lists.debian.org/20150409132215.ga32...@xanadu.blop.info
Re: Debian 8 bientôt publiée !
On 08/04/15 at 13:50 +0200, Francois Lafont wrote: > Bonjour, > > Le 08/04/2015 08:48, Lucas Nussbaum a écrit : > > >> Par exemple, au niveau des paquets qui installent un daemon (apache etc. > >> etc.), il faut bien que le postinst du paquet « active » le daemon, or > >> il me semble bien que les commandes ne sont pas les mêmes d'un système > >> init à l'autre. Comment ils font les développeurs de paquet pour que le > >> postinst marche quel que soit le système d'init mis en place sur l'OS ? > > > > systemd a un "generator" qui cherche tous les scripts LSB (=~ SysV) qui > > n'ont pas de fichier service correspondant, en extrait diverses infos, > > et génère un fichier service pour systemd correspondant. > > > > ces fichiers .service générés sont visibles dans > > /run/systemd/generator.late/, ou avec systemctl cat mon_service > > > > Un exemple pour apache2 (on voit bien les appels au script dans > > /etc/init.d/ à la fin): > > >8 > > # Automatically generated by systemd-sysv-generator > > > > [Unit] > > SourcePath=/etc/init.d/apache2 > > Description=LSB: Apache2 web server > > Before=runlevel2.target runlevel3.target runlevel4.target runlevel5.target > > shutdown.target > > After=local-fs.target remote-fs.target network-online.target > > systemd-journald-dev-log.socket nss-lookup.target > > Wants=network-online.target > > Conflicts=shutdown.target > > > > [Service] > > Type=forking > > Restart=no > > TimeoutSec=5min > > IgnoreSIGPIPE=no > > KillMode=process > > GuessMainPID=no > > RemainAfterExit=yes > > SysVStartPriority=1 > > ExecStart=/etc/init.d/apache2 start > > ExecStop=/etc/init.d/apache2 stop > > ExecReload=/etc/init.d/apache2 reload > > >8 > > > > La description du service est préfixée par "LSB:", ce qui permet de > > lister ces scripts avec "systemctl list-units | grep LSB:". > > Ah ok, tout s'explique alors. En un mot, on peut dire en fait > que systemd assure une compatibilité avec SysV. Voilà qui a dû > soulager pas mal de développeurs de paquets (qui fournissent > un daemon). > > >> De même, si un paquet a été développé et propose un joli script script > >> init pour System-V (ie un /etc/init.d/), comment ils font > >> les développeurs du paquet pour leur paquet puisse aussi marcher avec > >> systemd ? Ils doivent se fendre aussi d'un fichier de conf pour que > >> systemd puisse aussi démarrer le daemon ? En gros les développeurs > >> doivent-ils fournir, pour chaque système d'init proposé par la distrib, > >> tout le nécessaire au niveau conf et/ou script de lancement etc. ? > > > > Soit ils utilisent le mécanisme ci-dessus, soit ils fournissent un fichier > > .service. L'inconvénient avec les .service auto-générés, c'est que du coup, > > on > > passe à côté de certaines fonctionnalités de systemd. Par exemple, une des > > forces de systemd, c'est d'être capable de vraiment tuer tous les processus > > d'un service lors de l'arrêt, grâce au suivi avec les cgroups. Mais > > systemd-sysv-generator ne peut pas savoir si c'est une bonne idée de > > nettoyer > > un service particulier de cette manière (il y a des contre-exemples, comme > > sshd). Du coup, il utilise "KillMode=process", qui ne tue que le processus > > principal. > > Merci beaucoup Lucas pour toutes des ces explications très intéressantes. > Mais j'ai encore une petite question du coup. ;) > > Imaginons un développeur d'un paquet Debian fournissant un daemon. Supposons > que ce développeur soit très soucieux d'être « à la page ». Jusqu'à présent > il fournissait dans son paquet un script init sysV et du coup il se dit « zut > alors ! Faut que je fournisse un .service pour être dans les clous par rapport > à systemd ». Et supposons qu'il vire de son paquet, du coup, le script init.d > sysV. Alors dans ce cas, son paquet ne sera plus utilisable via sysV (qui > lui n'est pas compatible systemd), non ? Où alors la Debian policy lui « > interdit » > peut-être tout simplement de supprimer le script init.d sysV de son paquet ? Il y a une décision du comité technique de Debian qui dit, en août 2014: For the record, the TC expects maintainers to continue to support the multiple available init systems in Debian. That includes merging reasonable contributions, and not reverting existing support without a compelling reason. (https://lists.debian.org/debian-devel-announce/2014/08/msg1.html) - Lucas -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe" vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: https://lists.debian.org/20150408122457.gb5...@xanadu.blop.info
Re: Debian 8 bientôt publiée !
On 08/04/15 at 13:48 +0200, BERTRAND Joël wrote: > Lucas Nussbaum a écrit : > >On 08/04/15 at 11:10 +0200, BERTRAND Joël wrote: > >>Lucas Nussbaum a écrit : > >>>Note qu'une force de systemd dans ce contexte est qu'écrire un fichier > >>>service est beaucoup plus simple et rapide qu'écrire un script d'init, > >>>vu qu'une grosse partie de la complexité est gérée par systemd au lieu > >>>du script d'init. systemd simplifie aussi l'écriture des daemons, > >>>puisqu'il n'y a plus besoin de forker, d'écrire des fichiers pid, de > >>>gérer syslog, etc. (C'est lié à un des arguments des détracteurs de > >>>systemd: "puisqu'il n'y a plus besoin de s'embeter avec ça, les daemons > >>>vont arrêter de le faire, et ça ne marchera plus avec sysvinit"). > >> > >>Je gros problème est surtout que systemd est un point unique de plantage > > > >Je ne comprends pas cet argument: > >Oui, systemd est un assez gros logiciel (même s'il y a en a plus gros > >qui sont aussi critiques, comme le noyau). > > Rien à voir. systemd est le premier truc appelé par le noyau. S'il > plante > (et il a un paquet de raison pour planter), tout le système est en carafe > sauf à reboote avec un init=/bin/bash. J'ai donné plus souvent qu'à mon > tour. As-tu ouvert des bugs pour les différents problèmes que tu as rencontré avec systemd ? > >Mais à la limite, le fait que > >ce soit un gros logiciel englobant rend plutot la résolution de bugs > >plus facile, puisqu'il y a moins de problèmes d'interactions avec > >d'autres logiciels extérieurs. Est-ce que ça serait mieux si à la place > >de systemd, on avait une douzaine de petits logiciels avec la même > >fréquence de plantage ? > > Je n'ai jamais dit cela. Je trouve qu'un système comme init SysV est > bien > plus efficace parce qu'il lance dans des espaces mémoire différents les > différents daemons. Cette phrase ne veut rien dire. 1) systemd et sysvinit lancent tous deux les différents daemons dans des espaces mémoires différents. C'est la base de ce qu'est un processus. 2) en fait, en général, c'est moins efficace de séparer les espaces mémoires. C'est pour ça qu'on fait des threads, et aussi pour ça que GNU Hurd a du mal à concurrencer Linux ;) > Init SysV étant simple, il est facilement correctible en > cas de problème. Lorsque systemd se viande, il est très difficile de voir > pourquoi et de corriger les problèmes. Je ne nie pas que systemd soit plus difficile à appréhender que sysvinit, qu'il y a besoin de se former, et que ça n'est pas forcément évident. > >>qui balance ses logs dans un fichier journal en binaire > > > >Là non plus, je ne comprends pas pourquoi c'est un problème. On utilise > >plein de formats binaires tous les jours. Les systèmes de fichiers > >utilisent un format binaire. Les systèmes de gestion de base de données > >aussi. Et pourtant, on n'entend personne dire qu'avoir un format binaire > >pour les dentries est trop dangereux, ou qu'il faudrait un backend CSV > >dans postgresql. > >(Et on utilise aussi plein de formats texte qui ne sont pas > >particulièrement robustes à la corruption. Par exemple JSON.) > > Sauf que je veux bien avoir des logs binaires (même si je trouve cela > idiot). Lire des logs binaires, c'est bien lorsque le système est démarré et > actif. Lorsqu'il se viande au boot, et que tu n'as sous la main qu'un shell, > les logs en clair visualisables par un simple more ou less, c'est vraiment > bien. On peut utiliser tous les outils système, ce qui n'est vraiment pas le > cas avec un format binaire. 1) si tu n'as pas désactivé la redirection vers syslog, tu as toujours les logs texte. Tu peux très bien ignorer complètement journald. 2) Etant donné que journalctl est dans /bin, je ne vois pas vraiment de situation où tu ne pourrais pas consulter tes logs. Tu peux toujours les transférer vers une autre machine et utiliser le journalctl d'une autre machine (avec --file=). > >>et qu'il faut penser > >>à lui demander aussi de bien vouloir les balancer dans syslog. > > > >... ce qui est le comportement par défaut. (configurable dans > >journald.conf, avec ForwardToSyslog=) > > J'aimerais bien savoir comment. Une fois que syslogd est lancé, > certainement. Mais pour les premières traces de systemd, tu repasseras. De quelles traces parles-tu ? Pour voir les [OK]/[FAILED], il faut enlever le paramètre quiet de la ligne de commande du n
Re: Debian 8 bientôt publiée !
On 08/04/15 at 12:39 +0200, Wallace wrote: > Clairement j'aimerais pas me retrouver à gérer un package avec un daemon > à l'heure actuelle, si on veut satisfaire tout le monde, il faut > bidouiller au niveau du soft pour détecter si oui ou non systemd gère > l'init et donc gérer ou pas le pid au niveau du programme. Je comprend > mieux la réticence des développeurs. En fait non, ça ne fait pas de mal si le démon écrit le fichier pid quand même, même s'il ne sert à rien pour systemd. Lucas -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe" vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: https://lists.debian.org/20150408112002.ga1...@xanadu.blop.info
Re: Debian 8 bientôt publiée !
On 08/04/15 at 11:10 +0200, BERTRAND Joël wrote: > Lucas Nussbaum a écrit : > >Note qu'une force de systemd dans ce contexte est qu'écrire un fichier > >service est beaucoup plus simple et rapide qu'écrire un script d'init, > >vu qu'une grosse partie de la complexité est gérée par systemd au lieu > >du script d'init. systemd simplifie aussi l'écriture des daemons, > >puisqu'il n'y a plus besoin de forker, d'écrire des fichiers pid, de > >gérer syslog, etc. (C'est lié à un des arguments des détracteurs de > >systemd: "puisqu'il n'y a plus besoin de s'embeter avec ça, les daemons > >vont arrêter de le faire, et ça ne marchera plus avec sysvinit"). > > Je gros problème est surtout que systemd est un point unique de plantage Je ne comprends pas cet argument: Oui, systemd est un assez gros logiciel (même s'il y a en a plus gros qui sont aussi critiques, comme le noyau). Mais à la limite, le fait que ce soit un gros logiciel englobant rend plutot la résolution de bugs plus facile, puisqu'il y a moins de problèmes d'interactions avec d'autres logiciels extérieurs. Est-ce que ça serait mieux si à la place de systemd, on avait une douzaine de petits logiciels avec la même fréquence de plantage ? > qui balance ses logs dans un fichier journal en binaire Là non plus, je ne comprends pas pourquoi c'est un problème. On utilise plein de formats binaires tous les jours. Les systèmes de fichiers utilisent un format binaire. Les systèmes de gestion de base de données aussi. Et pourtant, on n'entend personne dire qu'avoir un format binaire pour les dentries est trop dangereux, ou qu'il faudrait un backend CSV dans postgresql. (Et on utilise aussi plein de formats texte qui ne sont pas particulièrement robustes à la corruption. Par exemple JSON.) > et qu'il faut penser > à lui demander aussi de bien vouloir les balancer dans syslog. ... ce qui est le comportement par défaut. (configurable dans journald.conf, avec ForwardToSyslog=) > Avec un > démarrage de type SysV, il était vraiment rare de tout foirer et d'empêcher > le démarrage d'une machine. Avec systemd, j'ai déjà eu de très mauvaises > surprises (jusqu'à un segfault de systemd qui m'a permis d'aller en urgence > en salle blanche à l'autre bout de Paris pour récupérer une machine !). > L'autre problème est qu'il surcharge les scripts d'init par ses propres > scripts et qu'il ne les lit pas dynamiquement (pour le coup, ce ne serait > pas difficile à implanter avec un truc aussi trivial qu'une somme de > hashage). Tu cherches peut-être "systemctl daemon-reload" ? Ou alors, je n'ai pas compris ton problème. > Bref, pour valider un truc avec systemd, il vaut mieux redémarrer > plutôt que de tester un script pour être sûr que ça passe. C'est un progrès. > > Je suis aussi assez stupéfié de la façon dont le bloatware gère les > dépendances. L'algorithme est en n**2 avec essais successifs. [citation needed]. Mais même si c'est le cas, vu que 'n' est petit, je ne vois pas le problème. > C'est d'une > efficacité redoutable et permet de bien voir ce qui foire et ce qui > fonctionne normalement puisque les logs sont constellés de 'failed'. Ce n'est pas mon expérience. > Même l'argument des cgroups ne tient pas puisqu'il est parfaitement > possible (redhat le faisait depuis au moins la version 6 qui doit dater du > dernier millénaire et debian le faisait aussi depuis longtemps) de fournir > un script de base pour le lancement des daemons qui s'occupait justement de > cela (à savoir fork, enregistrement du PID et j'en passe). Effectivement, on peut s'en sortir dans certains cas simples ainsi, mais il y a plein de cas pénibles où cette méthode ne suffit pas. Lucas -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe" vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: https://lists.debian.org/20150408111723.ga32...@xanadu.blop.info
Re: Debian 8 bientôt publiée !
On 08/04/15 at 10:00 +0200, Wallace wrote: > > > Le 08/04/2015 08:48, Lucas Nussbaum a écrit : > > > > systemd a un "generator" qui cherche tous les scripts LSB (=~ SysV) qui > > n'ont pas de fichier service correspondant, en extrait diverses infos, > > et génère un fichier service pour systemd correspondant. > > > > > > ExecStart=/etc/init.d/apache2 start > > ExecStop=/etc/init.d/apache2 stop > > ExecReload=/etc/init.d/apache2 reload > Je n'avais pas regardé Apache car je l'utilise plus depuis des années, > mais si les packages qui ne fournissent pas de configuration systemd, la > gestion se transforme en dépendance au script init avec une surcouche au > niveau systemd, aucun intérêt si ce n'est d'amener des problèmes à cours > ou moyen terme. C'est amusant de voir que d'un côté, tu te fais l'avocat de la "philosophie Unix" consistant à combiner des outils indépendants (et donc à empiler des couches), et de l'autre, tu argumentes que la génération de fichiers service au-dessus des scripts LSB est de l'empilage de couches qui va amener des problèmes. > En gros on va avoir pendant un bon bout de temps une dépendance forte > aux scripts init pour que systemd fonctionne... On peut voir ça comme ça, ou voir ça comme un chemin de migration relativement tranquille, permettant de mettre à jour les paquets progressivement. > Pour information, chez plusieurs éditeurs de progiciels dans le domaine > médical, BI ou bancaire, j'ai déjà du mal à obtenir un script init > fonctionnel, on est obligé de débugger avec eux et ils ne comprennent > pas pourquoi on demande de tels scripts, eux lancent les daemons à la > main ... Avec l'arrivée de systemd dans Debian 8 j'ai préparé le terrain > en disant vous devrez nous fournir lors de la migration des systèmes > vers la nouvelle Debian, la configuration du service pour systemd. La > réponse de TOUS ces éditeurs FR ou étrangers, nous n'avons pas prévu de > supporter systemd pire certains m'ont demandé ce que c'était alors que > leur boite ne développe que pour Linux pour plusieurs distros. > > C'est en tout cas un argument pour nous pour continuer à utiliser les > scripts init standards car bien sur vis à vis du client final si cela ne > marche pas ça sera de notre faute pas celle de l'éditeur. Passer du > temps à faire la conversion de notre côté c'est potentiellement > contourner le problème pour garder systemd mais c'est aussi s'assurer > d'un non soutient des supports applicatifs au moindre problème, ils > diront que la plateforme n'est pas valide. Note qu'une force de systemd dans ce contexte est qu'écrire un fichier service est beaucoup plus simple et rapide qu'écrire un script d'init, vu qu'une grosse partie de la complexité est gérée par systemd au lieu du script d'init. systemd simplifie aussi l'écriture des daemons, puisqu'il n'y a plus besoin de forker, d'écrire des fichiers pid, de gérer syslog, etc. (C'est lié à un des arguments des détracteurs de systemd: "puisqu'il n'y a plus besoin de s'embeter avec ça, les daemons vont arrêter de le faire, et ça ne marchera plus avec sysvinit"). Lucas -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe" vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: https://lists.debian.org/20150408082825.ga24...@xanadu.blop.info
Re: Debian 8 bientôt publiée !
On 08/04/15 at 00:58 +0200, Francois Lafont wrote: > Par exemple, au niveau des paquets qui installent un daemon (apache etc. > etc.), il faut bien que le postinst du paquet « active » le daemon, or > il me semble bien que les commandes ne sont pas les mêmes d'un système > init à l'autre. Comment ils font les développeurs de paquet pour que le > postinst marche quel que soit le système d'init mis en place sur l'OS ? systemd a un "generator" qui cherche tous les scripts LSB (=~ SysV) qui n'ont pas de fichier service correspondant, en extrait diverses infos, et génère un fichier service pour systemd correspondant. ces fichiers .service générés sont visibles dans /run/systemd/generator.late/, ou avec systemctl cat mon_service Un exemple pour apache2 (on voit bien les appels au script dans /etc/init.d/ à la fin): >8 # Automatically generated by systemd-sysv-generator [Unit] SourcePath=/etc/init.d/apache2 Description=LSB: Apache2 web server Before=runlevel2.target runlevel3.target runlevel4.target runlevel5.target shutdown.target After=local-fs.target remote-fs.target network-online.target systemd-journald-dev-log.socket nss-lookup.target Wants=network-online.target Conflicts=shutdown.target [Service] Type=forking Restart=no TimeoutSec=5min IgnoreSIGPIPE=no KillMode=process GuessMainPID=no RemainAfterExit=yes SysVStartPriority=1 ExecStart=/etc/init.d/apache2 start ExecStop=/etc/init.d/apache2 stop ExecReload=/etc/init.d/apache2 reload >8 La description du service est préfixée par "LSB:", ce qui permet de lister ces scripts avec "systemctl list-units | grep LSB:". > De même, si un paquet a été développé et propose un joli script script > init pour System-V (ie un /etc/init.d/), comment ils font > les développeurs du paquet pour leur paquet puisse aussi marcher avec > systemd ? Ils doivent se fendre aussi d'un fichier de conf pour que > systemd puisse aussi démarrer le daemon ? En gros les développeurs > doivent-ils fournir, pour chaque système d'init proposé par la distrib, > tout le nécessaire au niveau conf et/ou script de lancement etc. ? Soit ils utilisent le mécanisme ci-dessus, soit ils fournissent un fichier .service. L'inconvénient avec les .service auto-générés, c'est que du coup, on passe à côté de certaines fonctionnalités de systemd. Par exemple, une des forces de systemd, c'est d'être capable de vraiment tuer tous les processus d'un service lors de l'arrêt, grâce au suivi avec les cgroups. Mais systemd-sysv-generator ne peut pas savoir si c'est une bonne idée de nettoyer un service particulier de cette manière (il y a des contre-exemples, comme sshd). Du coup, il utilise "KillMode=process", qui ne tue que le processus principal. Lucas -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe" vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: https://lists.debian.org/20150408064829.ga15...@xanadu.blop.info
concours Boost Your Code
Hello, Chaque année, Inria organise un concours (Boost Your Code) permettant de financer le développement d'un projet libre pendant un an (en employant le développeur -- c'est limité à des personnes qui ont été ou seront diplomées bac+5 en 2013 ou 2014). Et chaque année, je me dis que ça serait classe de monter un dossier autour de Debian. On pourrait imaginer par exemple un projet autour de l'amélioration de la confiance et de la qualité (infrastructure de tests de qualité -- cf Debile ou Reproducible Builds), ou de la confidentialité et de l'anonymat (cf Tails). Est-ce qu'il y a des (ex-)étudiants qui seraient intéressés par creuser l'idée ? Lucas - Forwarded message from ribas - From: ribas To: teaching-foss-irill Date: Tue, 8 Apr 2014 09:16:46 +0200 Subject: [teaching-foss-irill] Concours logiciel Libre et rejoindre INRIA ! Message-Id: Reply-To: ribas List-Id: Bonjour et désolé pour le bruit :-) J'espère que vous allez tous bien ! J'aurais besoin de votre aide pour promouvoir une initiative : - Concours logiciel libre en collaboration avec Roberto Di Cosmo (IRILL) Pourriez vous copier/coller le texte ci dessous et le transmettre à vos étudiants ? Merci!! - Boost Your Code 2014 Les dépôts de candidatures au concours Boost your code sont ouverts jusqu'au 13 avril prochain, plus que quelques jours ! Le concours Boost your code est un appel à projet qui permet à un ingénieur ou master 2 diplômé en 2013 ou 2014 de venir développer son propre projet de logiciel libre chez Inria pendant un an. Pour tenter sa chance c'est très simple : . il suffit d'aller sur http://www.inria.fr/actualite/actualites-inria/boost-your-code-2014 . récupérer le dossier de candidature, le compléter et, . le déposer sur le même site. L'examen des dossiers permettra de présélectionner quatre finalistes qui seront auditionnés le 27 mai à Paris devant un jury présidé par Roberto di Cosmo. Chaque finaliste recevra une tablette internet sous Android et celui dont le projet aura été retenu viendra passer un an dans l'un des huit centres de recherche Inria pour réaliser son projet. Peut-on rêver d'un meilleur départ pour booster son cv tout en assouvissant sa passion ? Voici les projets réalisés par les lauréats des années précédentes : 2011 : http://www.claw-studio.com/ 2012 : http://www.reador.net/ 2013 : http://natron.inria.fr/ 2014 : votre projet ! Nous allons aussi sous peu vous adresser une liste d'environ 60 postes (fin avril) à pourvoir dans les différents centres de recherches INRIA. Si vous voulez être informé de toutes les offres d'emploi d'ingénieur chez Inria inscrivez-vous ici : https://boostyourcode.inria.fr/subscribe.php A très bientôt ! Stephane. /end. - End forwarded message - -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe" vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: https://lists.debian.org/20140408075459.gb15...@xanadu.blop.info
Re: Athlon XP 1600+ mal reconnu ?
On Tue, Sep 03, 2002 at 06:29:22PM -0400, Mikael Lambert <[EMAIL PROTECTED]> wrote: > Je viens d'installer Debian 3 sur mon nouvel ordinateur équipé d'un Athlon > XP 1600+ ; or il ne semble être reconnu que comme un 1000. Je te rappelle que les AMD 1600+ ne tourne pas à 1600 Mhz. La fréquence indiquée dans /proc/cpuinfo est la fréquence *réelle* à laquelle il tourne. Exemple avec mon AMD 1800+ : [...] model name : AMD Athlon(TM) XP 1800+ [...] cpu MHz : 1536.845 [...] Maintenant, c'est vrai que 1050, ca ressemble plus à une fréquence par défaut (donc minimale) de carte mère. Ton vendeur a peut-etre oublié de configurer la fréquence du proc. Bon courage pour trouver les bons paramètres à entrer dans le Bios :) > Il aurait-il > un problème avec Linux ou mon vendeur m'a-t-il passé un sapin :) Au contraire, te rends-tu compte que grace à Linux, tu viens de découvrir que tu pouvais peut-être faire tourner ton proc plus vite ? :) a+ lucas
Re: Debian vs FreeBSD
On Mon, Jul 15, 2002 at 11:28:22PM +0200, Stephane ISNARD <[EMAIL PROTECTED]> wrote: > j'utilise Debian depuis qq temps et je dois que je l'apprecie pas mal du > tout, meme si finalement je me dis que je n'ai jamais autant pratiqué > d'autres distributions ... > Pour des raisons diverses, je dois monter un routeur et un firewall, et > le technicien auquel je fais, en general, référence me dis que le mieux > et que je monte une machine avec ... FreeBSD ! J'ai utilisé FreeBSD pendant 2 ans sur mon PC (utilisation avec X et tout). Je suis passé à Debian il y a 2 mois, et j'avoue ne pas regretter du tout. Le système de ports (ou de packages, cela revient au même) gère très mal les dépendances, et on se retrouve au bout de quelques mois avec un système complètement pourri. Maintenant, si ton but est de configurer une machine minimaliste qui ne sert que de routeur/firewall, pourquoi ne pas essayer OpenBSD ? Je l'utilise sur ma passerelle, et la syntaxe de PF est un vrai plaisir (attention, pas d'IPFilter dans OpenBSD, mais un Packet Filter fait maison suite à des problemes de licence d'IPF qui est réputé bien plus rapide). Si en plus tu ne connais pas cet OS, ca te permettra de découvrir qqchose de très différent de GNU/Linux. Concernant les mises à jour, elles se font facilement, soit en réinstallant les .tgz du systeme à chaque nouvelle version (ca va tres vite), soit en recompilant à partir des sources que tu récupères via CVS (il est qd meme conseillé de les avoir puisqu'il faut svt pouvoir patcher un ptit truc). Et point de vue sécurité, "One remote hole in the default install, in nearly 6 years!", c'est tout de même pas dramatique. lucas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [OT?] Ethereal et Securité
On Mon, Jul 01, 2002 at 11:24:08PM -, [EMAIL PROTECTED] wrote: > Bonjour, > j'ai un doute quand ? la pertinence de ma question sur ce forum, mais comme > j'attend pas une reponse hyper technique n'etant pas (encore je l'espere) > hyper > connaisseur ... > > j'ai quelques notions de reseau, et je viens de decouvrir avec stupeur avec > quelle facilit? j'ai pu recuperer mes propres mots de passes POP et Telnet sur > mon r?seau grace ? l'utilitaire ethereal !! Si tu as un réseau local comme ça : / --X--\ || | AB C A B et C étant trois postes. si X est un Hub, toutes les données envoyées de A à B sont sniffables par C. si X est un Switch, seul B recoit les données : C ne voit rien. Maintenant, en dehors du réseau local, SS(H|L) règnent en maitre pour éviter l'envoi de pass en clair. lucas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: PRocmail et regles de filtrage
> Olivier Poitrey <[EMAIL PROTECTED]> a écrit :
> Au fil des listes j'ai rajouté des headers :
>
> *
> ^(From|To|Cc|cc|Reply-To|Resent-From|X-Mailing-List|X-Loop|List-Id):.*(D|d)ebian-user-french
:0
* ^X-Mailing-List: <[EMAIL PROTECTED]>
{
:0:
* ^X-Mailing-List: <[EMAIL PROTECTED]>
mail/ml/debian/news
:0:
* ^X-Mailing-List: <[EMAIL PROTECTED]>
mail/ml/debian/user
[...]
}
suffit, en fait.
lucas
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: fetchmail/mutt
On Sun, Jun 09, 2002 at 11:19:14PM +0200, Matthieu Moy <[EMAIL PROTECTED]> wrote: > :0 > ^TO.*debian-bla-bla-bla Il vaut mieux filter sur le X-Mailing-List, ca evite tous les problemes de Cc/Bcc lucas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bind9 question [ demande d'informations ]
On Tue, Jun 04, 2002 at 12:53:51PM +0200, Jean-Charles Preaux <[EMAIL
PROTECTED]> wrote:
> Bonjour
>
> Je me permets de vous écrire pour vous demander quelques questions:
> Je désire monter (apparrement de la meme maniere que vous) un dns interne
> pour nommer les machine de mon lan.
> Mais je veux aussi que ce dns "forward" les requetes externes vers un dns
> "public" genre oleane.
Qqchose dans ce style dans le named.conf suffit :
options {
[...]
forwarders {
213.166.201.1;
};
[...]
};
zone "in.local.net" {
type master;
file "in.local.net";
};
lucas
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Linux c trop cool!!!!!
On Wed, May 29, 2002 at 04:58:56PM +0200, Matthieu Moy <[EMAIL PROTECTED]> wrote: > Question à 2 balles : Avec > > Mail-Copies-To: never > [...] > Mail-Followup-To: > > Dans mes en têtes, ton mutt ne devrait-il pas répondre uniquement à la > liste ? Ou c'est moi qui n'ai pas compris ? > > Ca m'étonne de mutt, qui est, je le confirme un très bon mailer. (Mais > pour un fan d'Emacs, c'est un paradoxe de ne pas utiliser Gnus ...) Bizarre... avec mutt 1.3.99i : r (reply) -> reponse a l'auteur g (group-reply) -> reponse a la liste uniquement donc ca fonctionne correctement ! Lucas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: jdk 1.4.0 lent chez vous aussi ?
On Fri, May 24, 2002 at 10:42:44AM +0200, Pac <[EMAIL PROTECTED]> wrote: > bah un athmon 1500+ > 256 de DDRAM > j'ai ça comme sortie de time (je viens de le refaire ): > > real0m13.430s > user0m11.190s > sys 0m0.060s > > t'as quoi toi ? real0m3.917s user0m3.760s sys 0m0.150s P3 128 megs de ram IBM JDK 1.3.0 > t as essayé avec le jdk1.4 non, je l'ai pas ici > by the way est ce que 1e8 est dans le domaine des int ??? 2147483647 = 2e9 > 1e8 donc sans probleme Mnt, on teste sur une seule fonction, qui plus est mathematique... j'ai cherché un peu mais je trouve pas de benchmarks qui comparent les JDK de Sun et IBM. lucas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: jdk 1.4.0 lent chez vous aussi ?
> un time sur j'execution de > time java Test sur un jdk 1.3.1_02 me donne 13 secondes > me donne un temps en minutes !!! 3.7 secondes ici avec un JDK 1.3.0 d'IBM. sur un P3 500 avec 128 de ram. Tu as quoi comme machine ? lucas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
