[06:24:28]
<Werner> Good morning everybody! 🙂
[09:13:12]
<laurent20> Anacron job 'cron.daily' on akapache.co
[09:14:40]
<laurent5> yunohost.cli(
[09:14:41]
<laurent5> File "/bin/yunohost", line 71, in <module>
[09:14:41]
<laurent5> Traceback (most recent call last):
[09:14:41]
<laurent5> File "/usr/lib/python3/dist-packages/yunohost/__init__.py", line 25, in cli
[09:14:41]
<laurent5> File "/usr/lib/python3/dist-packages/moulinette/__init__.py", line 111, in cli
[09:14:41]
<laurent5> ret = moulinette.cli(
[09:14:44]
<laurent5> Cli(
[09:14:45]
<laurent5> ret = self.actionsmap.process(args, timeout=timeout)
[09:14:45]
<laurent5> File "/usr/lib/python3/dist-packages/moulinette/interfaces/cli.py", line 505, in run
[09:14:46]
<laurent5> return certificate_renew(domain_list, force, no_checks, email)
[09:14:46]
<laurent5> File "/usr/lib/python3/dist-packages/yunohost/certificate.py", line 316, in certificate_renew
[09:14:46]
<laurent5> File "/usr/lib/python3/dist-packages/moulinette/actionsmap.py", line 586, in process
[09:14:46]
<laurent5> File "/usr/lib/python3/dist-packages/yunohost/domain.py", line 554, in domain_cert_renew
[09:14:46]
<laurent5> return func(**arguments)
[09:14:48]
<laurent5> status = _get_status(domain)
[09:14:49]
<laurent5> File "/usr/lib/python3/dist-packages/yunohost/certificate.py", line 613, in _get_status
[09:14:50]
<laurent5> File "/usr/lib/python3/dist-packages/OpenSSL/__init__.py", line 8, in <module>
[09:14:50]
<laurent5> from OpenSSL import crypto # lazy loading this module for performance reasons
[09:15:29]
<laurent5> laurent@akapache.co
[09:15:45]
<laurent5> >.<
[10:43:24]
<gilrob> Bonjour, j’ai eu le message d’erreur suivants:
=================================
System configurations (regenconf)
[WARNING] Configuration file /usr/share/yunohost/yunohost-config/ssl/yunoCA/openssl.cnf appears to have been manually modified.
• This is probably OK if you know what you're doing! YunoHost will stop updating this file automatically... But beware that YunoHost upgrades could contain important recommended changes. If you want to, you can inspect the differences with 'yunohost tools regen-conf ssl --dry-run --with-diff' and force the reset to the recommended configuration with 'yunohost tools regen-conf ssl --force'
Faut-il que je fasse ce reset , vous pensez ? Merci.
[10:57:35]
<tituspijean> gilrob: peux-tu regarder sur le forum? Il me semble que ce problème y a été évoqué récemment. Il y a une commande à faire.
[10:57:52]
<tituspijean> (Soit celle qui a été mentionnée, soit une autre ^^)
[11:17:53]
<gilrob> Ok merci. J’ai vu des messages de Alejs et de Mario effectivement. On peut lancer la commande.regen si on est d’accord avec la sortie de la commande diff ou si cela nous paraît correct. Mais Je n’arrive pas trop à interpréter toute cette sortie de commande avec —diff
[11:29:20]
<gilrob> Ce problème est survenu après la migration vers yunohost 11. Par contre le dossier /usr/share/yunohost/yunohost-config/ssl/yunoCA/ n’existe plus.mais le fichier openssl.cnf existe toujours, mais dans un autre dossier.
[15:21:44]
<tituspijean> gilrob: tu peux partager le rendu de la commande avec `--diff` ici, s'il est trop long tu peux utiliser https://paste.yunohost.org
[15:27:34]
<jonathan> salut a tous
[15:34:41]
<gilrob> oui la voila : https://paste.yunohost.org/wegikewafe.diff
[15:40:58]
<tituspijean> gilrob: oui c'est tout bon, la commande avec `--force` va générer le bon fichier
[15:43:55]
<gilrob> ok merci. mais qu'est ce qui te fait dire çà ?la ligne 14 = /usr/share/yunohost/yunohost-config/ssl indique un chemin qui n'existe pas chez moi , le dossier yunohost-config n'existe pas chez moi (peut etre sur le yunohost 4.3 auparavant..)
[15:48:20]
<gilrob> le dossier yunoCA (ligne43) n,'existe pas non plus
[15:49:37]
<Aleks (he/him/il/lui)> à mon avis yunohost va le créer au moment du --force ...
[15:52:26]
<tituspijean> (j'étais partis à relire le code de la regen-conf pour vérifier ça, mais yolo ça coûte rien de tester xD)
[18:26:10]
<gilrob> bon, j'ai récrée les dossiers manquants et mis les fichiers dedans pui sj'ai fait la commande :sudo yunohost tools regen-conf ssl --dry-run --with-diff qui ne me donne plus de retour sur la console
[19:03:50]
<MF-DE> INFO - + libc6-dev : Beschädigt: libgcc-8-dev (< 8.4.0-2~) aber 8.3.0-6+rpi1 soll installiert werden
[19:06:02]
<christophe> bonsoir
[19:07:07]
<christophe> j'ai un soucis avec dovecot et postfix : à chaque réception de nouveau message, le dossier contenant les mails (/var/mail/nom_user) est renommé en BOGUS.nomuser.trucbizzare
[19:08:27]
<christophe> Est ce que vous savez comment je peux réparer cela ? Ca fonctionnait très bien et puis plus rien. Le fait de renommer le dossier BOGUS.nomuser en nomuser fait bien réapparaitre les dossiers, mais le problème revient au prochain message reçu...
[19:08:28]
<christophe> Merci d'avance de votre aide
[19:10:44]
<MF-DE> Bonsoir Christophe, malheureusement je ne peux pas aider, j'attends aussi :), Marcel
[19:28:58]
<Aleks (he/him/il/lui)> > <@MF-DE:libera.chat> https://paste.yunohost.org/raw/edakasegis
ffsync is blocking the upgrade and is not compatible with Bullseye because it relies on Python 2 (and ffsync is also unmaintained for years)
[19:29:22]
<MF-DE> So if I uninstall said package and try again, it might work?
[19:29:42]
<MF-DE> Dont even know what ffsync is
[19:30:22]
<MF-DE> Ah, Firfox Sync - don't use it. I will deinstall.
[19:31:31]
<MF-DE> Okay, removed it, should I start the migration again?
[19:32:11]
<Aleks (he/him/il/lui)> yup
[19:32:19]
<Aleks (he/him/il/lui)> NB: the migration, not a system upgrade
[19:32:35]
<MF-DE> Aleks (he/him/il/lui) ?
[19:32:47]
<Aleks (he/him/il/lui)> you should restart the **migration**
[19:32:47]
<MF-DE> will do thank you
[19:32:47]
<MF-DE> okay
[19:32:51]
<Aleks (he/him/il/lui)> not a "regular" system upgrade
[19:32:59]
<MF-DE> yes got it
[19:33:11]
<Aleks (he/him/il/lui)> seen too many people going to "System upgrade" in the webadmin etc
[19:33:15]
<Aleks (he/him/il/lui)> and that worsens the situation
[19:36:48]
<MF-DE> Next log is this https://paste.yunohost.org/raw/kebixegike
[19:37:08]
<MF-DE> I had ffsync removed and tried migration again
[19:39:09]
<MF-DE> Aleks (he/him/il/lui)
[19:39:53]
<MF-DE> system clock seems to be 1hour off
[19:40:49]
<Aleks (he/him/il/lui)> hmyeah that's not a huge deal, maybe the timezone is not properly configured
[19:41:46]
<Aleks (he/him/il/lui)> can you try to manually run from the command line: `LC_ALL=C DEBIAN_FRONTEND=noninteractive APT_LISTCHANGES_FRONTEND=none apt install --quiet -o=Dpkg::Use-Pty=0 --fix-broken --assume-yes gcc-8- libgcc-8-dev- equivs debhelper`
[19:41:46]
<MF-DE> Aleks (he/him/il/lui) check msg above please - next mig failed too
[19:42:02]
<Aleks (he/him/il/lui)> (that's basically the same command that failed in the migration, but with debhelper added at the end)
[19:42:26]
<Aleks (he/him/il/lui)> apt is super annoying because it doesn't clearly explain what's the issue ... so we have to force it >_>
[19:42:54]
<MF-DE> Yes I will. Haven't used ssh connect for ages, so it may take a while.
[19:48:03]
<MF-DE> As afraid, I struggle with PW. Is it the same user and PW as on the yunohost login?
[19:50:36]
<Aleks (he/him/il/lui)> you should login with `admin@yourdomain.tld` (or IP) and use the same admin password as the webadmin
[19:50:52]
<MF-DE> ok so ssh admin@... right?
[19:52:44]
<MF-DE> connection refused prt 22, probably too many bad tries in a short period of time, guess I have to wait
[19:53:21]
<MF-DE> Thank you for now! Very much appreciated.
[19:54:04]
<Aleks (he/him/il/lui)> root@ also works, but only if you're on the same local network
[19:54:57]
<MF-DE> connection refused . some sort of sec mechanism. It work before 10 mins ago.
[19:55:25]
<MF-DE> I think I tried th combi of root and the adminpw, but I'll try again 2moro.
[19:56:25]
<Aleks (he/him/il/lui)> yeah you get banned for 10~15 minutes by fail2ban if you try to bruteforce the login
[21:23:30]
<franck> hello à tous
[21:23:46]
<franck> qqun a noté un pb dns avec nohost.me ?
[21:40:28]
<Aleks (he/him/il/lui)> https://www.nme.com/wp-content/uploads/2019/01/homer-696x442.png
[21:48:04]
<radagast> hello, I'm not able to install nitter https://paste.yunohost.org/raw/kepimahuru any advice? Thank you in advance
[22:02:44]
<Aleks (he/him/il/lui)> for some reason there's already a /var/www/nitter
[22:03:08]
<Aleks (he/him/il/lui)> can you share a bit more story about what happened before this install ... did you cancel a previous install or something
[22:04:21]
<radagast> Yes I try to install two times. The first time the installation stuck
[22:05:53]
<Aleks (he/him/il/lui)> and how did you "unstuck" the situation
[22:06:34]
<radagast> I wasn't able also to access through ssh to stop the services, so I need to power off and restart
[22:09:06]
<Aleks (he/him/il/lui)> mokay so that's why it happened, usually a failed install results in the remove script being triggered to clean stuff up
[22:09:18]
<Aleks (he/him/il/lui)> though that doesnt really explain why it got stuck in the first place, maybe there's a bug in the install script
[22:09:46]
<Aleks (he/him/il/lui)> anyway, i would try to `rm -rf /var/www/nitter` and retry the install
[22:09:46]
<Aleks (he/him/il/lui)> though there may be other remains here and there
[22:10:14]
<Aleks (he/him/il/lui)> but maybe the second failed install already cleaned stuff up in fact
[22:10:42]
<Aleks (he/him/il/lui)> actually what would be great would be to share the logs of the *first* install attempt
[22:10:54]
<Aleks (he/him/il/lui)> that you can find in the webadmin in Tools > Logs
[22:11:22]
<Aleks (he/him/il/lui)> that may contain more clue as to where it got stuck
[22:18:11]
<radagast> https://paste.yunohost.org/raw/ujuzopajey
[22:19:12]
<radagast> here the first, I try four more times, also deleting the subdomain
[22:19:53]
<radagast> the last three without stuck, but failed
[22:30:31]
<PtitGNU> Does anyone know a way to reach a sysadmin of the yunohost forum? (the site is down for several weeks and I do not know who to contact)
[22:34:00]
<tituspijean> PtitGNU: which site?
[22:34:32]
<PtitGNU> forum.yunohost.org
[22:35:32]
<PtitGNU> telnet forum.yunohost.org 80 -> Trying 2001:bc8:608:1333::1... -> Connection failed: No route to host
[22:35:33]
<PtitGNU> (same with tcp/443)
[22:35:44]
<tituspijean> https://isitdownorjust.me/forum-yunohost-org/
[22:36:16]
<tituspijean> It's been working for me quite fine for the past 5 years
[22:36:17]
<PtitGNU> https://ipv6-test.com/validate.php?url=forum.yunohost.org
[22:38:09]
<PtitGNU> it seems to work only in ipv4...
[22:38:49]
<tituspijean> Indeed, and that's not normal. Thanks for the... erm... ping.
[22:39:01]
<PtitGNU> de rien :)
[22:39:17]
<tituspijean> I have no access to our infra tonight, I will have a look tomorrow.
[22:41:10]
<PtitGNU> thanks :)
[22:42:35]
<PtitGNU> (c'est vrai que ca manque souvent le monitoring des infras en dual-stack, et on s'en rends compte quand on est en ipv6-only)
[23:40:06]
<Thomas Freedman> I tried to post a bug report in github but the submit button is inactive. There is a popup saying to review the security policy which I followed all of those links etc but no reason / instructions as to how to file a bug report. I send a copy of it to yunohost@security.org.
[23:42:27]
<Aleks (he/him/il/lui)> sounds to me like you either have javascript disabled, or you forgot to put a title to your issue, which unlocks the green Submit button ...
[23:46:51]
<radagast> the second question is about the TOR relay app: after installed where I see the details, like Nickname, OR Address, etc?
[23:46:57]
<Thomas Freedman> Your were correct Aleks, bug filed.
The issue is that the website appears to have a self signed certificate although "yunohost domain cert-install mydomain.nohost.me" reports Error: The certificate for domain mydomain.nohost.me is not self-signed.
[23:47:49]
<radagast> I have search in metrics.torproject.org without success through my nickname
[23:50:34]
<Thomas Freedman> Ok, I see your reply in github, but not sure how to resolve it. Is there a resolution for my "boring edge case"?
[23:50:50]
<Aleks (he/him/il/lui)> I guess you can try adding `--force` to the command
[23:52:02]
<Thomas Freedman> To which command? Also, can you address why dyndns is involved? The IP address for my vps is static.
The instructions I referenced in the bug include dyndns
[23:52:15]
<Aleks (he/him/il/lui)> the `cert-install` command
[23:52:39]
<Thomas Freedman> I'll give that a try, thx
[23:59:04]
<Thomas Freedman> That appears to have worked, success reported on all aspects, no errors.
If it will take time for that to propagate, that's why no change in insecure status. Otherwise the problem still exists.
If yo look at the openssl report yo can see how the info for old & new certs were conflated. If that is still the case (haven't yet to run openssl again), is there a way to remove the cert entirely and then force a new one?