For your ssh server config, you can check what has been modified by executing this command (via SSH) :
sudo yunohost tools regen-conf --dry-run --with-diff ssh
For your ssh server config, you can check what has been modified by executing this command (via SSH) :
sudo yunohost tools regen-conf --dry-run --with-diff ssh
>
> -##-> my_webapp
> - # Hardening user connection
> - Match User webapp1
> - ChrootDirectory %h
> - ForceCommand internal-sftp
> - AllowTcpForwarding no
> - PermitTunnel no
> - X11Forwarding no
> - PasswordAuthentication yes
> -##<- my_webapp
> + PermitRootLogin yes
> status: modified
Seems to be my_webappâŠ
Indeed. my_webapp
adds a post-hook that appends this config to the SSH server config.
This is normal then.
Thanks for the update ! Everything went smoothly, as usual .
I still have two warnings about DNS: it is pihole which change /etc/resolv.conf
and /etc/dnsmasq.conf
.
For people (@ericg) who meet this issue, we need returns of these commands AFTER you add made the upgrade and force-rerun the diagnosis. Feel free to send us the result on a private message if you prefer
yunohost --version
cat /etc/resolv.conf
curl ip.yunohost.org
curl ip6.yunohost.org
yunohost diagnosis show mail --issues
yunohost app list
If your public IPv4 is AAA.BBB.CCC.DDD, do these commands (note the ip is âreversedâ) for each blacklist which failed, example with zen.spamhaus.org. You can find the dnsbl to use by refering to our dnsbl list https://github.com/YunoHost/yunohost/blob/stretch-unstable/data/other/dnsbl_list.yml
dig +short A DDD.CCC.BBB.AAA.zen.spamhaus.org
dig +short A DDD.CCC.BBB.AAA.zen.spamhaus.org @127.0.0.1
dig +short A DDD.CCC.BBB.AAA.zen.spamhaus.org @8.8.8.8
If you are not blacklisted these commands should return nothing.
Next try directly by calling:
yunohost tools shell -c "from yunohost.utils.network import dig ; print(dig('DDD.CCC.BBB.AAA.zen.spamhaus.org', 'A'));"
yunohost tools shell -c "from yunohost.utils.network import dig ; print(dig('DDD.CCC.BBB.AAA.zen.spamhaus.org', 'A', 'force_external'));"
yunohost tools shell -c "from yunohost.utils.network import dig ; print(dig('DDD.CCC.BBB.AAA.zen.spamhaus.org', 'A', ['8.8.8.8']));"
yunohost tools shell -c "from yunohost.utils.network import dig ; print(dig('DDD.CCC.BBB.AAA.zen.spamhaus.org.', 'A'));"
yunohost tools shell -c "from yunohost.utils.network import dig ; print(dig('DDD.CCC.BBB.AAA.zen.spamhaus.org.', 'A', 'force_external'));"
yunohost tools shell -c "from yunohost.utils.network import dig ; print(dig('DDD.CCC.BBB.AAA.zen.spamhaus.org.', 'A', ['8.8.8.8']));"
If the system says it is not able to find the expiration date of your domain, please send us you domain, like that we could improve our system. Especially if you have domain with a particular TLD.
You can also verify your domain expiration displayed by your registrar with the one we display. The 2 date should be distant from 2 days maximum, if itâs more, say us.
Iâm blacklisted because of Orange ISP. Thanks to the diagnostic system for for bringing this to me.
About the WHOIS expiration date feature
If the system says it is not able to find the expiration date of your domain, please send us you domain, like that we could improve our system. Especially if you have domain with a particular TLD.
You can also verify your domain expiration displayed by your registrar with the one we display. The 2 date should be distant from 2 days maximum, if itâs more, say us.
2 days for me, so I guess itâs ok
Thank you so much for your work
3.8.2.1 was released with a couple of additional small fixes, in particular for the false-negatives about blacklists, as reported by @ericg and @pascalv (thanks for the tests !)
That was a sneaky subtle issue but should (really) be fixed now
Yes it works! , that was quick.
Jâai encore une question.
Concernant le reverse DNS, le diagnostic me renvoie deux alertes:
- Le DNS inverse n'est pas correctement configurĂ© en IPv4. Certains e-mails seront peut-ĂȘtre refusĂ©s ou considĂ©rĂ©s comme des spam. - Aucun DNS inverse nâest dĂ©fini pour IPv6. Certains e-mails seront peut-ĂȘtre refusĂ©s ou considĂ©rĂ©s comme des spam.
Je ne retrouve pas ces erreurs aprĂšs un essai avec mail-tester qui me donne un joli 10/10âŠ
Ces erreurs viennent dâapparaĂźtre avec la version 3.8.2.1.
mail-tester ne teste que lâIPv4 ⊠du coup le truc sur lâIPv6 est probablement juste, par contre câest Ă©trange effectivement pour lâipv4 ⊠Que raconte les dĂ©tails ? (Ă©ventuellement remplace les donnĂ©es privĂ©es par âdomain.tldâ par exemple)
I try the upgrade a few minutes ago and encoutered an error during metronome upgrade. Failed to restart because of a syntax error.
Unpacking ldap-utils (2.4.44+dfsg-5+deb9u4) over (2.4.44+dfsg-5+deb9u3) ...
Setting up ldap-utils (2.4.44+dfsg-5+deb9u4) ...
(Reading database ... 48048 files and directories currently installed.)
Preparing to unpack .../metronome_3.13.6+yunohost-1_armhf.deb ...
Unpacking metronome (3.13.6+yunohost-1) over (3.12.0+yunohost-1) ...
Setting up metronome (3.13.6+yunohost-1) ...
Job for metronome.service failed because the control process exited with error code.
See "systemctl status metronome.service" and "journalctl -xe" for details.
invoke-rc.d: initscript metronome, action "start" failed.
â metronome.service - LSB: Metronome XMPP Server
Loaded: loaded (/etc/init.d/metronome; generated; vendor preset: enabled)
Active: failed (Result: exit-code) since Fri 2020-05-01 13:07:12 UTC; 72ms ago
Docs: man:systemd-sysv-generator(8)
Process: 19477 ExecStart=/etc/init.d/metronome start (code=exited, status=1/FAILURE)
May 01 13:07:12 yunolime2test.local metronome[19477]: [C]: in function '_real_require'
May 01 13:07:12 yunolime2test.local metronome[19477]: /usr/bin/metronome:154: in function 'require'
May 01 13:07:12 yunolime2test.local metronome[19477]: /usr/bin/metronome:108: in function 'init_net_server'
May 01 13:07:12 yunolime2test.local metronome[19477]: /usr/bin/metronome:376: in main chunk
May 01 13:07:12 yunolime2test.local metronome[19477]: [C]: ?
May 01 13:07:12 yunolime2test.local metronome[19477]: failed!
May 01 13:07:12 yunolime2test.local systemd[1]: metronome.service: Control process exited, code=exited status=1
May 01 13:07:12 yunolime2test.local systemd[1]: Failed to start LSB: Metronome XMPP Server.
May 01 13:07:12 yunolime2test.local systemd[1]: metronome.service: Unit entered failed state.
May 01 13:07:12 yunolime2test.local systemd[1]: metronome.service: Failed with result 'exit-code'.
dpkg: error processing package metronome (--configure):
subprocess installed post-installation script returned error exit status 1
Errors were encountered while processing:
metronome
E: Sub-process /usr/bin/dpkg returned an error code (1)
The crash logs
-- Unit metronome.service has begun starting up.
May 01 13:07:12 yunolime2test.local metronome[19477]: Starting Metronome XMPP Server: metronomelua5.1: error loading module 'net.server_event' from file '/usr/lib/metronome/n
May 01 13:07:12 yunolime2test.local metronome[19477]: /usr/lib/metronome/net/server_event.lua:139: unexpected symbol near ';'
May 01 13:07:12 yunolime2test.local metronome[19477]: stack traceback:
May 01 13:07:12 yunolime2test.local metronome[19477]: [C]: ?
May 01 13:07:12 yunolime2test.local metronome[19477]: [C]: in function '_real_require'
May 01 13:07:12 yunolime2test.local metronome[19477]: /usr/bin/metronome:154: in function 'require'
May 01 13:07:12 yunolime2test.local metronome[19477]: /usr/lib/metronome/net/server.lua:12: in main chunk
May 01 13:07:12 yunolime2test.local metronome[19477]: [C]: in function '_real_require'
May 01 13:07:12 yunolime2test.local metronome[19477]: /usr/bin/metronome:154: in function 'require'
May 01 13:07:12 yunolime2test.local metronome[19477]: /usr/bin/metronome:108: in function 'init_net_server'
May 01 13:07:12 yunolime2test.local metronome[19477]: /usr/bin/metronome:376: in main chunk
May 01 13:07:12 yunolime2test.local metronome[19477]: [C]: ?
May 01 13:07:12 yunolime2test.local metronome[19477]: failed!
May 01 13:07:12 yunolime2test.local systemd[1]: metronome.service: Control process exited, code=exited status=1
May 01 13:07:12 yunolime2test.local systemd[1]: Failed to start LSB: Metronome XMPP Server.
I check the code of metronome v3.13.6 and the code is not the same so do we use master branch instead of a tagged release to build the package ?
@HugoPoi : indeed, Maranda the maintainer just warned me about this, fix on the way ⊠:s
(The builds are from https://github.com/YunoHost/metronome on branch Debian, itâs sync with the upstream when we do releases )
We sync on master on every commit ?
Uuuuh not sure âon every commitâ, itâs synced manually with a âgit merge upstream/masterâ basically (or âgit merge <tag>â)
Ok not great, we should used the tagged release, and I see that we packaged for Debian, a PR in the upstream could be doable ?
We do use the tagged release, Maranda warns us when thereâs a new tag and we do merge the new tag at that time
I guess yup, but thereâs also the question of how to actually build the package (and until recently I didnât know about platforms that allow to request build like salsa.debian or idk which one arthurlutz mentionned âŠ)
I have also my metronome not starting - what to do here?
waiting an update?
Weird about the tag stuff because YunoHost/metronome pull upstream until 18d162c
commit but the v3.13.6 point to 1e43613
. Maranda has probably moved the tags after fixing the issue ? which is very bad if itâs the case
I think he did
Quâon lui coupe la tĂȘte
I think we can used Github Worflows for building ⊠and would be really cool to make the package available in Debian repository too but probably lot of work