Re: ajuda reportar bug letsencrypt (systemd)
Hola Pedro, > Referència d'això que dius? Vols dir que si està systemd i el > cron llavors systemd té prioritat (i el cron en qüestió no > s'executa?). Que si paro el timer llavors només fa el cron? El certbot executa això al cron: 0 */12 * * * root test -x /usr/bin/certbot -a \! -d /run/systemd/system && perl -e 'sleep int(rand(3600))' && certbot -q renew Per tant, si existeix el directori /run/systemd/system ja no s'executa l'ordre certbot del final. A la versió de Debian 10 (ara mateix és la mateixa a testing i unstable), a més a més, han afegit un comentari explicant-ho, que també tanca un bug al respecte demanant més detalls: https://salsa.debian.org/letsencrypt-team/certbot/certbot/blob/master/debian/certbot.cron.d https://bugs.debian.org/908841 Salut, Alex -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Alex Muntada ⢿⡄⠘⠷⠚⠋ Debian Developer - log.alexm.org ⠈⠳⣄ signature.asc Description: PGP signature
Re: ajuda reportar bug letsencrypt (systemd)
Hola Narcís, inline: On Wed, Dec 5, 2018 at 3:54 PM Narcis Garcia wrote: > > Amb "systemctl status certbot" veuràs que se t'ha disparat el mateix > dia. Això vol dir que és un servei que fa una tasca (one-shot) i s'atura > fins el següent torn, que no sé si són una o dues vegades al dia. OK, però per aturar la tasca has d'atacar el timer, no el oneshot (que en aquest cas és llençat per un timer) Com he posat al fitxer de timer (i per lo que he vist als logs) és al voltant de les 12:00 OnCalendar=*-*-* 00,12:00:00 > Segons està anotat als «scripts», la tasca del Cron no té efecte si > Systemd està present. Aleshores aturant i deshabilitant només el > certbot.timer ja no hauria d'actuar en cap moment. Referència d'això que dius? Vols dir que si està systemd i el cron llavors systemd té prioritat (i el cron en qüestió no s'executa?). Que si paro el timer llavors només fa el cron? Salut, Pedro
Re: (deb-cat) Recuperar directoris
Hola Toni, > He hegut d'invocar ssh amb la opció -tt, amb una sola -t encara > no en fucnionava. Moltes gràcies! Ah! No sabia que es podia forçar amb -tt. Moltes gràcies a tu per compartir-ho :) Salut, Alex -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Alex Muntada ⢿⡄⠘⠷⠚⠋ Debian Developer - log.alexm.org ⠈⠳⣄ signature.asc Description: PGP signature
Re: ajuda reportar bug letsencrypt (systemd)
Narcís, no era així del tot així, ja que `systemctl disable certbot` sobreentén que es refereix a certbot.service així com `systemctl status certbot`, i si el veiem diu que està mort de per sí. Algú li està donant vida... Resulta que certbot per la part de systemd té un cron també i d'aquesta manera: - l'script /lib/systemd/system/certbot.service [1] - el disparador /lib/systemd/system/certbot.timer [2] per tant, es pot deshabilitar així per la sessió actual: systemctl stop certbot.timer per sessions futures (només aquest no fa sessió actual): systemctl disable certbot.timer Crec que continua sent un bug perquè està duplicat en cron i en systemd, perquè no avisa, és a dir: mal muntat en general, lo qual les modificacions per una banda i no l'altre no es propaguen bé. Però el meu problema sembla que ja està resolt! Gràcies! Pedro [1] # cat /lib/systemd/system/certbot.service [Unit] Description=Certbot Documentation=file:///usr/share/doc/python-certbot-doc/html/index.html Documentation=https://letsencrypt.readthedocs.io/en/latest/ [Service] Type=oneshot ExecStart=/usr/bin/certbot -q renew PrivateTmp=true [2] # cat /lib/systemd/system/certbot.timer [Unit] Description=Run certbot twice daily [Timer] OnCalendar=*-*-* 00,12:00:00 RandomizedDelaySec=3600 Persistent=true [Install] WantedBy=timers.target
ajuda reportar bug letsencrypt (systemd)
Hola, Crec que letsencrypt té un bug per com està empaquetat a debian Acostumo a treure els permisos de root a letsencrypt (i fer-ho amb un usuari dedicat), això implica que al meu /etc/cron.d/certbot [1] l'executa l'usuari letsencrypt enlloc de root que intel·ligentment m'avisa si el vull modificar en futures actualitzacions sorprenentment vaig veure que en paral·lel hi ha un servei systemd que fa el mateix aquí: /lib/systemd/system/certbot.service [2] per tant el modifico, però a les actualitzacions no m'avisa de canvis, directament el sobreescriu i aquí és on crec que es tracta d'un error. Degut a que utilitzo el meu usuari propi pel letsencrypt, si un procés com aquest de systemd s'executa com a root, llavors canvia els permisos d'alguns fitxers i directoris i letsencrypt ja no pot renovar / ho fa de la manera que jo no vull / problemes per a mi. Gràcies! Pedro [1] 0 */12 * * * letsencrypt test -x /usr/bin/certbot -a \! -d /run/systemd/system && perl -e 'sleep int(rand(3600))' && su - letsencrypt -s /bin/bash -c "certbot -q renew" [2] [Unit] Description=Certbot Documentation=file:///usr/share/doc/python-certbot-doc/html/index.html Documentation=https://letsencrypt.readthedocs.io/en/latest/ [Service] Type=oneshot #ExecStart=/usr/bin/certbot -q renew ExecStart=su - letsencrypt -s /bin/bash -c "certbot -q renew" PrivateTmp=true
Re: (deb-cat) Recuperar directoris
Hola, He hegut d'invocar ssh amb la opció -tt, amb una sola -t encara no en fucnionava. Moltes gràcies! Toni Mas Missatge de Alex Muntada del dia dl., 3 de des. 2018 a les 11:28: > Hola Toni, > > > El cas és que si intento executar fsck -vMsrp -t ext 4 sobre > > la UUID i a través de SSH de la partició que vull revisar em > > dóna error (return code 8). No em dóna més informació. En canvi, > > la mateixa sentència executada amb una terminal interactiva no > > em dóna cap problema. > > Prova a passar l'opció -t a l'ssh perquè reservi un tty. Si el > fsck espera una resposta interactiva, segons com cridis l'ssh > no es reserva cap tty i aleshores falla. > > Salut, > Alex > > -- > ⢀⣴⠾⠻⢶⣦⠀ > ⣾⠁⢠⠒⠀⣿⡁ Alex Muntada > ⢿⡄⠘⠷⠚⠋ Debian Developer - log.alexm.org > ⠈⠳⣄ > >
