Re: Substitute for archivemail
Leandro Noferini writes: > In these days I upgraded the server to bullseye and so I have not yet > archivemail: what could I use as subsitute? I wonder about that too, I use archivemail to clean up my spam folder of older spam. My email provider still runs Buster and they're in no hurry to upgrade so no problem right now but eventually I'll need a replacement. Oh, for now you could probably install archivemail from Buster.
Re: networking.service: start operation timed out [SOLVED]
The bind9 script I created in /etc/resolvconf/update.d executed systemctl reload named near the end (if systemd is active, which it is for me). Adding set -x to the script showed that this was where the process of bringing up the interfaces hung up. named is obviously not active when the network is coming up; I thought it would just fail. But, probably because named.service says After=network.service (network, not networking, but I assume they are related), it blocks. The solution was to test first: systemctl -q is-active named.service && systemctl reload named > /dev/null 2>&1 || : The stuff after the reload command was there all along. Tracing this back the chain, because the script blocks the resolvconf -a invocation in /etc/network/if-up.d/000resolvconf, that was the last script showing on my earlier posts. resolvconf -a is only invoked if there was some dns information in the interface stanza, which is why removing dns- lines from ethlan allowed the network to come up, and why bringing up ethworld automatically failed. Now everything just works. Thanks again to everyone. There are probably some general lessons, though I'm not sure what they are. Clearly the systemd semantics tripped me up; it's kind of an odd beast. I understand one of its major goals was to allow startup to proceed in parallel, which is pretty asynchronous. But it has to assure that certain things happen in a certain order, which results in some things being synchronous and blocking. I'm surprised that a tool intended for use from the command line (systemctl) is blocking. Ross
Substitute for archivemail
Ciao a tutti, I have a little mail server for a few users with dovecot as imap server. To compress the mailboxes of the users I had archivemail. In these days I upgraded the server to bullseye and so I have not yet archivemail: what could I use as subsitute? -- Ciao leandro
Questions Python
Bonjour la liste, Dans mon apprentissage de Python, je progresse et sèche sur des points. Pour obtenir une liste des méthodes d'un objet de classe Canvas, je lis qu'on peut exécuter : print dir (Canvas()) J'obtiens une erreur ; quelle est la bonne syntaxe ? D'autre part je ne trouve pas la méthode qui retourne le nom d'un widget pointé mais j'obtiens son type, en faisant : print (widget) L'instance widget a le focus et j'ai besoin de connaître son type, mais de plus son petit nom (ex: listbox1, entry2 etc). Merci de m'aider. -- Pierre ESTREM
Re: Hibernation issue [was: Bookworm : graphic glitches all over my screen after upgrade]
Hello, > Il giorno 29 ago 2022, alle ore 17:49, rudu ha scritto: > > Le 27/08/2022 à 11:42, Computer Enthusiastic a écrit : >> Hello, >> >>> […] > > Thank you very much, the boot parameters trick worked like a charm. > Now whatever Kernel I choose to boot, the hibernation process works as > expected. > > Rudu I’m happy I helped you to sort it out. :-) Please, if you can, report it to the Debian bug tracking system updating the bug report at [1]. Thanks. [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=989705
Re: Hibernation issue [was: Bookworm : graphic glitches all over my screen after upgrade]
Le 27/08/2022 à 11:42, Computer Enthusiastic a écrit : Hello, Il giorno 26 ago 2022, alle ore 19:31, piorunz ha scritto: On 26/08/2022 10:18, rudu wrote: You should be right, but after booting on both 5.10 kernels I found in my repositories : ii linux-image-5.10.0-13-amd64 5.10.106-1 amd64 Linux 5.10 for 64-bit PCs (signed) ii linux-image-5.10.0-16-amd64 5.10.127-1 amd64 Linux 5.10 for 64-bit PCs (signed) ... the hibernation process fails as described above ... With Linux birdynam 5.7.0-3-amd64 #1 SMP Debian 5.7.17-1 (2020-08-23) x86_64 GNU/Linux hibernation works as expected. I suggest you should report this error as soon as A bug report is already opened [1]. A workaround (using kernel boot parameters) and a kernel patch are reported in [1]. Working is in progress to let the patch reach upstream kernel [2]. I have successfully used both the workaround parameters or the patch and I’m currently using a custom Debian kernel with the aforementioned patch to solve this bug. HTH [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=989705 [2] https://lists.freedesktop.org/archives/nouveau/2022-August/040756.html Thank you very much, the boot parameters trick worked like a charm. Now whatever Kernel I choose to boot, the hibernation process works as expected. Rudu
Error con claves repositorios
root@debian:/home/cviur# sudo apt-get update Obj:1 http://deb.debian.org/debian bullseye InRelease Obj:2 http://security.debian.org/debian-security bullseye-security InRelease Obj:3 http://deb.debian.org/debian bullseye-updates InRelease Des:4 https://ftp.postgresql.org/pub/pgadmin/pgadmin4/apt/bullseye pgadmin4 InRelease [4.217 B] Err:4 https://ftp.postgresql.org/pub/pgadmin/pgadmin4/apt/bullseye pgadmin4 InRelease Las firmas siguientes no se pudieron verificar porque su clave pública no está disponible: NO_PUBKEY 8881B2A8210976F2 Leyendo lista de paquetes... Hecho W: Error de GPG: https://ftp.postgresql.org/pub/pgadmin/pgadmin4/apt/bullseye pgadmin4 InRelease: Las firmas siguientes no se pudieron verificar porque su clave pública no está disponible: NO_PUBKEY 8881B2A8210976F2 E: El repositorio « https://ftp.postgresql.org/pub/pgadmin/pgadmin4/apt/bullseye pgadmin4 InRelease» no está firmado. N: No se puede actualizar de un repositorio como este de forma segura y por tanto está deshabilitado por omisión. N: Vea la página de manual apt-secure(8) para los detalles sobre la creación de repositorios y la configuración de usuarios.
Re: imapsync notification
On 2022-08-29, OB-Linux GNU wrote: > Hello > > I use imapsync occasionally. In the new version, it sends emails to > users at every run. I want to prevent this. (h...@imapsync.tk) > > is there any way to prevent this? > > I don't think this soft is in the official repositories. Seems a little funky (maybe it isn't funky). The changelog entry for version 2.200 mentions a recent change that's possibly related to what you're referring to: Enhancement: Append a final email report on each account at the end of the synchronization. Use --noemailreport1 and --noemailreport2 to avoid final emails reports in each INBOX.
Re: nocache nice ionice -c3 ... chrt? for rsync.
Samuel Wales wrote: > i seem to get sluggish interactive x pointer etc. on rare occasions > with rsync. i use nocache nice ionice -c3. i am wondering why chrt > exists also, and what teh best set of options is for this kind of > purpose. Tell us about your hardware and network. lscpu free ip -s -s l show (narrow this one down to your primary interfaces) What disk technology is being used? How much data are you moving through rsync? How long does it usually take? How far is it going? -dsr-
Re: [OT] Debian decide sobre su política de paquetes firmware «non-free»
On Sun, 28 Aug 2022 10:11:03 +0200 Camaleón wrote: > Hola, > > A través de Phoronix¹ leo que en Debian² se está llevando a cabo una > consulta sobre la política a seguir con los paquetes de firmware > non-free, que actualmente se tienen que instalar por separado y de > manera plenamente consciente, con el consiguiente perjuicio que causa > en las instalaciones, principalmente a los nuevos usuarios. > > En fin, la habitual dicotomía entre hacer lo correcto y sufrir un poco > las consecuencias o pasarse al lado oscuro (lo que yo llamo «el > modo vago»). > > Las alternativas que hay sobre la mesa son: > > A. Meter los paquetes de firmware non-free dentro del medio de > instalación, como si fueran uno más, sin que sea obligatoio informar al > usuario de esto. > > B. Meter los paquetes non-free en el medio de instalación oficial pero > sólo cargarlos / instalarlos si son necesarios, informando al usuario y > permitiendo desactivar previamente esta opción. > > Se mantienen dos medios por separado, dando preeminencia al medio de > instalación que contienen los paquetes de non-free. > > C. Un poco como la situación actual, dos medios de instalación separados > para que el usuario elija cuál descargar e instalar. > > Desde mi punto de vista, la opción A no me convence en absoluto, > significa claudicar. > > De la opción B no me fío, porque el kernel recomienda paquetes non-free > que no son necesarios así que el automatismo no funciona. > > La opción C es la menos mala y la más sincera con los usuarios, pero > perjudica a los nuevos o a los más novatos que tienen que buscar e > informarse... lo que tampoco es malo >:-) > > ¿Qué pensáis? > > ¹https://www.phoronix.com/news/Debian-Non-Free-Firmware-GR > ²https://www.debian.org/vote/2022/vote_003 > > Saludos, > > -- > Camaleón > Yo me quedo con la C que es más o menos como estamos. Así yo elijo a qué nivel de desvenguenza quiero trabajar. Quien quiera comodidad a cambio de libertad que se vaya a otro sistema operativo. O sinó, ¿qué narices hacen usando debian? Pobres binarios, no los quieren en debian, no los quieren los del LGTBI... hubble, 8-) --
imapsync notification
Hello I use imapsync occasionally. In the new version, it sends emails to users at every run. I want to prevent this. (h...@imapsync.tk) is there any way to prevent this?
Re: Mariadb et systemd
didier gaumet a écrit : > ça se plante immédiatement (en quelques secondes, quoi...), ton histoire? Oui, avant même le lancement de mariadbd. Moins d'une seconde. > Parce que ce que j'avais vu l'autre fois dans la doc MariaDB, et ça > m'avait frappé en tant que spécificité Systemd, c'était qu'il y avait > dans leur service Systemd un délai de 90 secondes au-delà duquel le > service arrête le démarrage. Délai réglable pour éviter ça. J'ai aussi dû modifier ce genre de chose. Voir ma réponse plus haut, un nouveau dysfonctionnement de systemd. Je ne remplis même plus de bug report chez les développeurs, tous ceux que j'ai déjà remontés n'ont jamais été corrigés. Uniquement des "workarounds" qui m'ont été retournés par mail.
[résolu] Re: Mariadb et systemd
BERTRAND Joël a écrit : > Plus exactement, c'est cette commande qui semble renvoyer un SIGBUS : > ExecStartPre=/usr/bin/install -m 755 -o mysql -g root -d /var/run/mysqld > > Je peux pourtant, en root, la lancer à la main (elle s'exécute en root > dans l'unité en question). > > Si je la mets en commentaire, ça se bauge plus loin : > Process: 1084452 ExecStartPre=/bin/sh -c systemctl unset-environment > _WSREP_START_POSITION (code=killed, signal=BUS) > > Ça pue encore le bug systemd. Je vais redémarrer le serveur histoire de > voir si c'est reproductible (parce que ça s'est mis à merdouiller sans > aucune mise à jour). > Bon. J'ai simplement redémarré le serveur et, miracle, ça fonctionne à nouveau. Sauf que le swap a merdouillé parce que systemd qui DEMANDAIT (sous peine de ne pas lancer iscsi) précédemment ceci : hilbert:[~] > cat /etc/systemd/system/swap.target [Unit] Description=Swap Requires=open-iscsi.service After=open-iscsi.service Documentation=man:systemd.special(7) ne fonctionne plus si la ligne After est spécifiée. Toutes les mises à jour automatique sont naturellement désactivées. Naturellement, un shutdown -r now ne fonctionnait pas, preuve une fois de plus que systemd était parti en vacances. J'avoue que je commence à en avoir assez de ce genre de comportement. À l'époque où il fallait voter pour savoir si on voulait systemd ou pas, j'avais voté non pour tout un tas d'arguments, tas d'arguments qui n'a cessé de grossir depuis. Je ne compte plus le nombre de problèmes directement liés à systemd (ou usrmerge d'ailleurs) dès qu'on n'est plus dans une configuration "machine de bureau". Mes serveurs avec un init SysV ou BSD se font oublier, ceux avec systemd sont à surveiller comme le lait sur le feu. Je trouve à titre personnel déplorable d'avoir à redémarrer une machine Unix pour retrouver un comportement normal. J'ai l'impression qu'il a fallu trente ans d'évolution pour aboutir à un comportement du type Windows... JKB
Re: [OT] Debian decide sobre su política de paquetes firmware «non-free»
El 2022-08-29 a las 10:33 +0200, Javier Barroso escribió: > Hola, > > El lun., 29 ago. 2022 9:10, Camaleón escribió: > > > El 2022-08-29 a las 07:35 +0200, Javier Barroso escribió: > > > > Hola Javier, > > > > > El dom., 28 ago. 2022 10:11, Camaleón escribió: > > > > > > > Hola, > > > > > > > > A través de Phoronix¹ leo que en Debian² se está llevando a cabo una > > > > consulta sobre la política a seguir con los paquetes de firmware > > > > non-free, que actualmente se tienen que instalar por separado y de > > > > manera plenamente consciente, con el consiguiente perjuicio que causa > > > > en las instalaciones, principalmente a los nuevos usuarios. > > > > (...) > > > > > > ... > > > > > > > > ¿Qué pensáis? > > > > > > > > > La opción A sí informa de qué se instala (al menos lo interpreto así), > > > > No me queda claro este punto. > > > > Si el usuario va a descargar la ISO de Debian para instalar y sólo ve > > una opción (porque con la opción A sólo hay una imagen oficial que > > contiene firmware non-free) pocas alternativas tiene ese usuario. (...) > > > Aún con un instalador libre vas a estar corriendo tu equipo con firmwares > > > no libres (los que van integrados en la tarjeta gráfica, de red, etc), > > > > No, no... eso no es así, Javier. > > > > Yo ahora mismo no tengo habilitado el repo «non-free» y espero que mi > > equipo no tenga ninguna pieza de software de código cerrado, faltaría > > más. > > > > Ese es el tema da igual que tengas habilitado o no el repo non-free, las > tarjetas gráficas y demás ya tienen incorporados su propio firmware antes > de que el SO ponga nada. Ese firmware no es libre en el 99.9% de las veces > > ¿Ahora me explico mejor? La BIOS/UEFI tampoco es libre pero no es algo sobre lo que tengamos el control, ni nosotros ni Debian. De lo que se trata en la decisión que tenga que tomar Debian es, primero de carácter técnico (¿quién y cómo se determina si debo/tengo que instalar cierto firmaware propietario o no?) y luego de carácter vocacional (¿hacia dónde queremos dirigirnos, debemos fomentar el uso de códígo porpietario?). La opción A pretende «automatizar» y «simplificar» en exceso esa decisión, yo prefiero que sea el usuario quien decida lo que quiere hacer y que sea consecuente y plenamente consciente de sus actos, y que de manera predeterminada se fomente desde Debian las opciones libres, obviamente. Para que decidan por mi ya están Windows o Android :-) Saludos, -- Camaleón
Re: Mariadb et systemd
ça se plante immédiatement (en quelques secondes, quoi...), ton histoire? Parce que ce que j'avais vu l'autre fois dans la doc MariaDB, et ça m'avait frappé en tant que spécificité Systemd, c'était qu'il y avait dans leur service Systemd un délai de 90 secondes au-delà duquel le service arrête le démarrage. Délai réglable pour éviter ça.
Re: Mariadb et systemd
Plus exactement, c'est cette commande qui semble renvoyer un SIGBUS : ExecStartPre=/usr/bin/install -m 755 -o mysql -g root -d /var/run/mysqld Je peux pourtant, en root, la lancer à la main (elle s'exécute en root dans l'unité en question). Si je la mets en commentaire, ça se bauge plus loin : Process: 1084452 ExecStartPre=/bin/sh -c systemctl unset-environment _WSREP_START_POSITION (code=killed, signal=BUS) Ça pue encore le bug systemd. Je vais redémarrer le serveur histoire de voir si c'est reproductible (parce que ça s'est mis à merdouiller sans aucune mise à jour). JKB
Re: Mariadb et systemd
Frédéric BOITEUX a écrit : > Bonjour, > > Je regarderais si /var/run (en fait /run) est bien dispo pour le service… > C’est maintenant un répertoire monté en RAM (via tmpfs), et il me semble > qu’il y a des restrictions sur son accès… Voir la page de manuel de > systemd.exec et les paramètres RuntimeDirectory=, RuntimeDirectoryPreserve= … > > Cordialement, > Fred. En fait, ce qui m'inquiète, c'est le SIGBUS : mariadb.service: Control process exited, code=killed, status=7/BUS Je ne vois pas pourquoi il y aurait un SIGBUS lorsque mariadb est lancé par systemd et aucun lorsqu'il est lancé en ligne de commande.
Re: Cursos en Madrid
Excelente estimado, Muchas gracias por el consejo. Saludo. El lun, 29 de ago. de 2022 9:17 a. m., Camaleón escribió: > El 2022-08-29 a las 09:08 +0200, Yair De la cruz escribió: > > > Buenos días estimada comunidad @debian-user-spanish@lists.debian.org > > , > > > > Vengo a solicitar su amable y siempre apreciado consejo, > > > > Quiero realizar un curso de Linux, tengo conocimientos en debian pero > algo > > muy básico, > > > > Me podrían recomendar algún curso completo y económico? > > El mejor curso autodidacta, la guía de referencia de Debian y el manual > del administrador (también en español): > > https://www.debian.org/doc/user-manuals > > https://www.debian.org/doc/manuals/debian-reference/index.en.html > https://debian-handbook.info/ > > > Puede ser tanto online como presencial, vivo en Madrid. > > > > Saludo y muchas gracias. > > Para algo oficial y reglado, los cursos y certificados de LPI (online y > presencial) para linux en general: > > https://www.lpi.org/es > > Saludos, > > -- > Camaleón > >
Re: [OT] Debian decide sobre su política de paquetes firmware «non-free»
Hola, El lun., 29 ago. 2022 9:10, Camaleón escribió: > El 2022-08-29 a las 07:35 +0200, Javier Barroso escribió: > > Hola Javier, > > > El dom., 28 ago. 2022 10:11, Camaleón escribió: > > > > > Hola, > > > > > > A través de Phoronix¹ leo que en Debian² se está llevando a cabo una > > > consulta sobre la política a seguir con los paquetes de firmware > > > non-free, que actualmente se tienen que instalar por separado y de > > > manera plenamente consciente, con el consiguiente perjuicio que causa > > > en las instalaciones, principalmente a los nuevos usuarios. > > (...) > > > > ... > > > > > > ¿Qué pensáis? > > > > > > La opción A sí informa de qué se instala (al menos lo interpreto así), > > No me queda claro este punto. > > Si el usuario va a descargar la ISO de Debian para instalar y sólo ve > una opción (porque con la opción A sólo hay una imagen oficial que > contiene firmware non-free) pocas alternativas tiene ese usuario. > > Porque una vez que el instalador está en ejecución, poco margen de > maniobra tienes. Es decir, con la opción A facilitas las cosas al lado > oscuro y se las complicas a los caballeros Jedi. > > Es como darle un sable de luz a Vader y una ramita a Skywalker... y que > luchen :-) > > No me parece justo, además de con esa acción fomentas el uso de > firmware non-free en lugar de hacer pensar al usuario sobre las > consecuencias de su uso, instruirle sobre el hardware que compra o las > opciones que tiene. > > > lo que yo creo que sería deseable es que te dijera el instalador , > > "se va a instalar los componentes non free que te proporcionan la > > siguientes funcionalidades: > > > > - > > - > > > > Aceptar / instalar sin esos componentes (o incluso, (de)seleccione los > > componentes non free y pulsa siguiente) > > > > Donde e son tanto los nombres de los componentes como su > > descripción corta > > Ojalá fuera tan sencillo. > > Me temo que simplemente si el kernel «piensa» que necesita cierto > código para funcionar, lo instalará, sin más, pero queda por resolver > la cuestión técnica de si realmente el sistema necesita ese chorro de > software binario cerrado para funcionar sin problemas. > > La parte técnica NO es está resuelta. > > > En la lista de debian-vote daban el argumento de la accesibilidad (para > > ciegos por ejemplo) como algo fundamental para el instalador. > > Desconozco qué tipo de software-hardware gestiona esto, pero supongo > que será como en todo: lo habrá cerrado y lo habrá libre. Y los > usuarios que necesiten usarlo están en la misma tesitura que los demás: > decidir qué usar y con pleno conocimiento de lo que hacen. > > > Aún con un instalador libre vas a estar corriendo tu equipo con firmwares > > no libres (los que van integrados en la tarjeta gráfica, de red, etc), > > No, no... eso no es así, Javier. > > Yo ahora mismo no tengo habilitado el repo «non-free» y espero que mi > equipo no tenga ninguna pieza de software de código cerrado, faltaría > más. > Ese es el tema da igual que tengas habilitado o no el repo non-free, las tarjetas gráficas y demás ya tienen incorporados su propio firmware antes de que el SO ponga nada. Ese firmware no es libre en el 99.9% de las veces ¿Ahora me explico mejor?
Re: Mariadb et systemd
Frédéric BOITEUX a écrit : > Bonjour, > > Je regarderais si /var/run (en fait /run) est bien dispo pour le service… > C’est maintenant un répertoire monté en RAM (via tmpfs), et il me semble > qu’il y a des restrictions sur son accès… Voir la page de manuel de > systemd.exec et les paramètres RuntimeDirectory=, RuntimeDirectoryPreserve= … Bonjour, Merci, mais ça ne semble pas être cela. J'ai essayé de lancer le daemon avec ProtectSystem=off, le résultat est le même. Bien cordialement, JKB
Re: Cursos en Madrid
El 2022-08-29 a las 09:08 +0200, Yair De la cruz escribió: > Buenos días estimada comunidad @debian-user-spanish@lists.debian.org > , > > Vengo a solicitar su amable y siempre apreciado consejo, > > Quiero realizar un curso de Linux, tengo conocimientos en debian pero algo > muy básico, > > Me podrían recomendar algún curso completo y económico? El mejor curso autodidacta, la guía de referencia de Debian y el manual del administrador (también en español): https://www.debian.org/doc/user-manuals https://www.debian.org/doc/manuals/debian-reference/index.en.html https://debian-handbook.info/ > Puede ser tanto online como presencial, vivo en Madrid. > > Saludo y muchas gracias. Para algo oficial y reglado, los cursos y certificados de LPI (online y presencial) para linux en general: https://www.lpi.org/es Saludos, -- Camaleón
Re: [OT] Debian decide sobre su política de paquetes firmware «non-free»
El 2022-08-29 a las 07:35 +0200, Javier Barroso escribió: Hola Javier, > El dom., 28 ago. 2022 10:11, Camaleón escribió: > > > Hola, > > > > A través de Phoronix¹ leo que en Debian² se está llevando a cabo una > > consulta sobre la política a seguir con los paquetes de firmware > > non-free, que actualmente se tienen que instalar por separado y de > > manera plenamente consciente, con el consiguiente perjuicio que causa > > en las instalaciones, principalmente a los nuevos usuarios. (...) > > ... > > > > ¿Qué pensáis? > > > La opción A sí informa de qué se instala (al menos lo interpreto así), No me queda claro este punto. Si el usuario va a descargar la ISO de Debian para instalar y sólo ve una opción (porque con la opción A sólo hay una imagen oficial que contiene firmware non-free) pocas alternativas tiene ese usuario. Porque una vez que el instalador está en ejecución, poco margen de maniobra tienes. Es decir, con la opción A facilitas las cosas al lado oscuro y se las complicas a los caballeros Jedi. Es como darle un sable de luz a Vader y una ramita a Skywalker... y que luchen :-) No me parece justo, además de con esa acción fomentas el uso de firmware non-free en lugar de hacer pensar al usuario sobre las consecuencias de su uso, instruirle sobre el hardware que compra o las opciones que tiene. > lo que yo creo que sería deseable es que te dijera el instalador , > "se va a instalar los componentes non free que te proporcionan la > siguientes funcionalidades: > > - > - > > Aceptar / instalar sin esos componentes (o incluso, (de)seleccione los > componentes non free y pulsa siguiente) > > Donde e son tanto los nombres de los componentes como su > descripción corta Ojalá fuera tan sencillo. Me temo que simplemente si el kernel «piensa» que necesita cierto código para funcionar, lo instalará, sin más, pero queda por resolver la cuestión técnica de si realmente el sistema necesita ese chorro de software binario cerrado para funcionar sin problemas. La parte técnica NO es está resuelta. > En la lista de debian-vote daban el argumento de la accesibilidad (para > ciegos por ejemplo) como algo fundamental para el instalador. Desconozco qué tipo de software-hardware gestiona esto, pero supongo que será como en todo: lo habrá cerrado y lo habrá libre. Y los usuarios que necesiten usarlo están en la misma tesitura que los demás: decidir qué usar y con pleno conocimiento de lo que hacen. > Aún con un instalador libre vas a estar corriendo tu equipo con firmwares > no libres (los que van integrados en la tarjeta gráfica, de red, etc), No, no... eso no es así, Javier. Yo ahora mismo no tengo habilitado el repo «non-free» y espero que mi equipo no tenga ninguna pieza de software de código cerrado, faltaría más. Aunque se trata de algo distinto¹, hubo un momento en que sí instalaba el controlador propiedario de nvidia, pero ahora, aún y todo lo mal que está nouveau, me vale con el libre. > en mi opinión facilitar al usuario el mejor rendimiento del equipo es lo > deseable. Los firmwares llevan "toda la vida" en los repositorios, esto es > ponerlos en el instalador al alcance de cualquiera. Llevan toda la vida en repos separados y no habilitados de manera predeterninada, que no es lo mismo. Creo, sinceramente, que la base de Debian, y de cualquier sistema Linux debe ser la educación consciente del usuario, en hacer bien las cosas y no en atender a una necesidad o capricho puntual del usuario (eso significa pan para hoy y hambre para mañana). Uno de los fines últimos de un sistema operativo libre debe ser hacer pensar. Si perdemos eso, perderemos nuestra esencia. > Para los puristas con activar el modo libre al arrancar (igual que hemos > estado usando el modo experto mucho tiempo) les tendría que ser suficiente Yo quiero más ;-) Quiero poder indentificarme con los valores que promueve mi sistema operativo, que el sistema operativo que elijo esté en mi misma línea de acción y de pensamiento. Y con este paso que dan se aleja más de lo que espero de una distribución como Debian. De RedHat o Ubuntu lo puedo esperar; de Debian, no. > Cualquiera de las tres opciones será buena para Debian y sus usuarios Me cuesta ver algo bueno en recomendar y promover software propietario, la verdad :-/ ¹Lo que se debate ahora en Debian está relacionado exclusivamente con el código firmware, no con programas o controladores propietarios. Saludos, -- Camaleón
Cursos en Madrid
Buenos días estimada comunidad @debian-user-spanish@lists.debian.org , Vengo a solicitar su amable y siempre apreciado consejo, Quiero realizar un curso de Linux, tengo conocimientos en debian pero algo muy básico, Me podrían recomendar algún curso completo y económico? Puede ser tanto online como presencial, vivo en Madrid. Saludo y muchas gracias.
RE: Mariadb et systemd
Bonjour, Je regarderais si /var/run (en fait /run) est bien dispo pour le service… C’est maintenant un répertoire monté en RAM (via tmpfs), et il me semble qu’il y a des restrictions sur son accès… Voir la page de manuel de systemd.exec et les paramètres RuntimeDirectory=, RuntimeDirectoryPreserve= … Cordialement, Fred. -Message d'origine- De : BERTRAND Joël Envoyé : samedi 27 août 2022 16:53 À : Debian user french Objet : Mariadb et systemd Bonsoir à tous, Je viens de m'apercevoir qu'une réplique de bases mysql ne fonctionnait plus et j'avoue que je sèche. Une fois de plus, systemd semble faire ce que bon lui semble. Je m'explique. La base de données fonctionne parfaitement si je la lance en ligne de commande : Root hilbert:[~] > mariadbd 2022-08-27 16:45:02 0 [Note] mariadbd (server 10.6.9-MariaDB-1-log) starting as process 857896 ... hilbert:[~] > mysql -uroot -p Enter password: Welcome to the MariaDB monitor. Commands end with ; or \g. Your MariaDB connection id is 11 Server version: 10.6.9-MariaDB-1-log Debian buildd-unstable Copyright (c) 2000, 2018, Oracle, MariaDB Corporation Ab and others. Type 'help;' or '\h' for help. Type '\c' to clear the current input statement. MariaDB [(none)]> show slave status\G *** 1. row *** Slave_IO_State: Waiting for master to send event Master_Host: xxx.yyy.zzz Master_User: replica Master_Port: 3306 Connect_Retry: 10 Master_Log_File: mysql-bin.19 Read_Master_Log_Pos: 104080595 Relay_Log_File: mysqld-relay-bin.94 Relay_Log_Pos: 63666 Relay_Master_Log_File: mysql-bin.19 Slave_IO_Running: Yes Slave_SQL_Running: Yes Replicate_Do_DB: Replicate_Ignore_DB: Replicate_Do_Table: Replicate_Ignore_Table: ... Slave_SQL_Running_State: Slave has read all relay log; waiting for more updates Slave_DDL_Groups: 2 Slave_Non_Transactional_Groups: 103 Slave_Transactional_Groups: 44 1 row in set (0,000 sec) MariaDB [(none)]> Si je lance le daemon par systemctl start mariadb, je me prends une erreur dans la figure : Root hilbert:[/etc/systemd/system] > systemctl status mariadb.service ● mariadb.service - MariaDB 10.6.9 database server Loaded: loaded (/etc/systemd/system/mariadb.service; disabled; preset: enabled) Active: activating (auto-restart) (Result: signal) since Sat 2022-08-27 16:43:17 CEST; 2s ago Docs: man:mariadbd(8) https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmariadb.com%2Fkb%2Fen%2Flibrary%2Fsystemd%2Fdata=05%7C01%7Cfrederic.boiteux%40odigo.com%7C8bfee86a68db49c8b91a08da883e1a7f%7Cbfa2632f99e14088a16c21c08ca1b899%7C1%7C0%7C637972097560898749%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=6ExAzrZ8dc3FX26KrTKxYys8n%2BobIPwsHIiD9zCGXtg%3Dreserved=0 Process: 857728 ExecStartPre=/usr/bin/install -m 755 -o mysql -g root -d /var/run/mysqld (code=killed, signal=BUS) CPU: 613us Root hilbert:[/etc/systemd/system] > L'unité est quelque chose que j'ai modifié (la dépendance After est modifiée en After=network.target ypbind.service parce que cette station de travail est diskless et que les droits sont hérités du réseau). J'ai naturellement vérifié qu'il n'avait aucune autre différence entre les deux unités : Root hilbert:[/lib/systemd/system] > diff -u mariadb.service /etc/systemd/system/mariadb.service --- mariadb.service 2022-08-17 16:28:05.0 +0200 +++ /etc/systemd/system/mariadb.service 2022-08-27 16:39:29.142139130 +++ +0200 @@ -22,7 +22,7 @@ Description=MariaDB 10.6.9 database server Documentation=man:mariadbd(8) Documentation=https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmariadb.com%2Fkb%2Fen%2Flibrary%2Fsystemd%2Fdata=05%7C01%7Cfrederic.boiteux%40odigo.com%7C8bfee86a68db49c8b91a08da883e1a7f%7Cbfa2632f99e14088a16c21c08ca1b899%7C1%7C0%7C637972097560898749%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=6ExAzrZ8dc3FX26KrTKxYys8n%2BobIPwsHIiD9zCGXtg%3Dreserved=0 -After=network.target +After=network.target ypbind.service [Install] WantedBy=multi-user.target Root hilbert:[/lib/systemd/system] > De ce que je comprends, la commande /usr/bin/install -m 755 -o mysql -g root -d /var/run/mysqld lui pose problème. Or cette commande fonctionne parfaitement bien lancée depuis la ligne de commande. J'avoue ne plus comprendre et je prends tout avis. Bien cordialement, JKB
Re: networking.service: start operation timed out
Thanks Andrew, Felix, Jeremy, Anssi, Curt, Tomas and Greg for your suggestions and comments. I followed several of them by trimming my network/interfaces file to nothing and then slowly adding stuff back. The blank file and the one with only the loopback worked: networking.services reported successful completion, and everything mentioned in interfaces was configured. However, adding the ethlan stanza and auto declaration failed. Removing the 2 dns-* lines allowed it to complete successfully. This is consistent with the fact that the hangup seemed to be on /etc/network/if.up/000resolvconf which acts on the dns-* lines. However, I still can't see why it should have hung up. Adding in ethworld with an auto again produces a failure and doing ifdown --force ethworld; ifup -v ethworld did not entirely fix it: the result of the second command was #, /sbin/ip link set dev ethworld up /sbin/ip route add default via 66.181.128.1 dev ethworld onlink RTNETLINK answers: File exists ifup: failed to bring up ethworld and I was never able to get DNS and routing in a functional state (likely the routing was the key to the problem since the default route was to ethlan, leaving no way to reach external DNS). Note that the ethworld stanza also includes dns-* directives; I guess these account for the hangup in ethworld, but I haven't tested that theory. I removed the auto for ethworld and networking.service was able to complete without error. Once I manually brought up ethworld, networking seemed to be OK. I added the following 2 scripts to help trace what was going on; they show that in addition to the interface-specific events the scripts are also called once with special, generic values (e.g., IFACE=--all), explaining why the scripts seemed to be called too many times. These were in /etc/network/if-pre-up.d/ and /etc/network/if-up.d/: --- 000debug-- #! /bin/sh # scrap to trace activity LFILE=/root/000debug.log echo "" >> $LFILE echo "$0 $$">> $LFILE echo "$*" >> $LFILE date >> $LFILE printenv >> $LFILE echo "" >> $LFILE - zzzdebug #! /bin/sh # scrap to trace activity LFILE=/root/000debug.log echo "Finishing $0 $$">> $LFILE date >> $LFILE echo "" >> $LFILE end-- On the whole ifupdown, systemd, NetworkManager question, I'm trying to stick with ifupdown for several reasons 1. It's what I'm already using. 2. NetworkManager's intended use, as I understand it, is for a roaming laptop, not a box that is the main server and router on a home network. I'm not saying it can't fit my needs, just that I would anticipate getting it to do so might be difficult (as @Jeremy reports). 3. The parts of systemd I know are complex, and I'm frankly annoyed by its apparent desire to take over my whole computer. 4. Some of the components I use for bridging work specifically with the /etc/network/interfaces file. I'll admit that ifup/down is not so easy either! @Jeremy NetworkManager was already disabled. I wasn't aware of masking; at your suggestion I masked it too. The fact that I still had problems almost certainly means they are not NetworkManager's fault. @Ansi: I think I have wpa_supplicant as a result of a generic desktop install; I do also have a wireless card in the machine, though I've never used it and I don't think it works.
