[04:53:40]
<ynhuser> hey guys, I'm having trouble upgrading nextcloud from v22 to v24. The upgrade to v23 appears to go successfully, but upgrade to v24 fails when it fails to locate nextcloud-ynh-deps, except apt says that package is already installed
[04:54:04]
<ynhuser> https://paste.yunohost.org/raw/ilefihirey
[04:54:05]
<ynhuser> looks like fulltextsearch is broken...
[04:54:05]
<ynhuser> 2022-11-30 21:43:30,248: DEBUG - Update app fulltextsearch from App Store
[04:54:06]
<ynhuser> 2022-11-30 21:43:33,483: DEBUG - An unhandled exception has been thrown:
[04:54:06]
<ynhuser> 2022-11-30 21:43:33,484: DEBUG - Error: Undefined constant OCA\FullTextSearch\Service\ConfigService::MIGRATION_24 in /var/www/nextcloud/apps/fulltextsearch/lib/Migration/Version2400Date202201301329.php:159
[04:54:16]
<ynhuser> 2022-11-30 21:43:33,484: DEBUG - Stack trace:
[04:54:16]
<mcint> I'm having issues when multiple ips. It seems I can't use the wireguard app, because it expects its own ip, while yuno ... autodetects IPs and complains if DNS differs (from the first it finds in the interfaces)
[04:55:26]
<ynhuser> FYI, I resolved my issue by disabling fulltextsearch and then upgraded to v24
[09:23:00]
<alwi[m]> > <@bamf[m]:libera.chat> > <@alwi[m]:libera.chat> uefi-Stick? that's very new to me. Many other OS that I test now and then are detected under UEFI.
>
> you can format the stick in a way so that it works with uefi boot. try https://rufus.ie/
bamf[m]: Your reference to Rufus has helped. Thank you. If I start with UEFI now, the error message "No EFI partition was found" comes.
If I continue to try what is still possible, another message appears: "Create the file system ext4 of partition 1 on /dev/nvme0n 1 has failed". The partition program does not work properly.
In my attempts, LAN was not recognized 2 x and a connection was searched for WLAN but this did not work.
[09:26:12]
<bamf> > <@alwi[m]:libera.chat> > <@bamf[m]:libera.chat> > <@alwi[m]:libera.chat> uefi-Stick? that's very new to me. Many other OS that I test now and then are detected under UEFI.
> >
> > you can format the stick in a way so that it works with uefi boot. try https://rufus.ie/
>
> bamf[m]: Your reference to Rufus has helped. Thank you. If I start with UEFI now, the error message "No EFI partition was found" comes.
> If I continue to try what is still possible, another message appears: "Create the file system ext4 of partition 1 on /dev/nvme0n 1 has failed". The partition program does not work properly.
> In my attempts, LAN was not recognized 2 x and a connection was searched for WLAN but this did not work.
hm, never had this issue. secure boot is disabled? and you can really not enable legacy boot / CSM?
[09:27:14]
<alwi[m]> I cannot disable secureboot
[09:28:39]
<bamf> if you cannot disable secure boot, you will never be able to boot unsigned bootloaders via UEFI. if you also cannot disable UEFI boot, you're pretty stuck I guess?
[09:29:04]
<alwi[m]> I was wrong, secureboot is dsabled
[09:29:39]
<bamf> ok. but you said you can boot other iso's?
[09:30:03]
<alwi[m]> yes, for example debian server
[09:31:05]
<bamf> ok then just install a current debian and then run the installer https://yunohost.org/en/install/hardware:vps_debian
[10:55:43]
<craigvb[m]> so...if I install a package on yunohost server on the command line... how do I prevent the yunohost portal firing up when I go to access it (it's not a yunohost app, it's a system app bound to mydomian.com)
[11:05:54]
<Aleks (he/him/il/lui)> not sure what you mean by "it's a system app", but maybe you want to looking into https://github.com/YunoHost-Apps/my_webapp_ynh
[11:17:27]
<craigvb[m]> it's pydio cells that I've installed from the cli...
[11:19:02]
<Aleks (he/him/il/lui)> (Either mywebapp, or https://github.com/YunoHost-Apps/redirect_ynh )
[11:21:26]
<craigvb[m]> it's pydio cells, so I've installed from the cli
[11:22:18]
<craigvb[m]> if I run it on port 8080 it works fine with a self signed certificate, but if I try and bind it to any domain names yunohost takes over and loads the user interface / installed apps selection page
[11:22:34]
<Aleks (he/him/il/lui)> yes, but you still need to handle the exposure, and you can't just edit the nginx conf manually because SSOwat / the yunohost portal will still forbid access to it
[11:22:47]
<Aleks (he/him/il/lui)> hence you probably want to use redirect_ynh which will handle all this
[11:23:02]
<Aleks (he/him/il/lui)> in reverse proxy mode, bind it to port 8080, etc
[11:24:48]
<craigvb[m]> Is that something easily explained or something I'm better to go do some reading for?
[11:29:32]
<craigvb[m]> actually the instructions don't look to bad....will give that a try in the morning (or later in the morning I should say <sigh>) Thx !!
[12:00:35]
<alwi[m]> > <@craigvb:matrix.org> so...if I install a package on yunohost server on the command line... how do I prevent the yunohost portal firing up when I go to access it (it's not a yunohost app, it's a system app bound to mydomian.com)
Worked ok. Many thanks!
[13:42:48]
<Felix Bartsch> Hello, I have problems during update nextcloud. It fails every time. Does somebody know this issue? I've pasted the logs here: https://paste.yunohost.org/raw/ratevevuda
[13:52:55]
<Aleks (he/him/il/lui)> ```
2022-12-01 13:41:50,480: DEBUG - Update app fulltextsearch from App Store
2022-12-01 13:41:52,189: DEBUG - An unhandled exception has been thrown:
2022-12-01 13:41:52,189: DEBUG - Error: Undefined constant OCA\FullTextSearch\Service\ConfigService::MIGRATION_24 in /var/www/nextcloud/apps/fulltextsearch/lib/Migration/Version2400Date202201301329.php:159
```
[13:53:01]
<Aleks (he/him/il/lui)> this seems related to the fulltextsearch extension
[13:53:09]
<Aleks (he/him/il/lui)> could it be something you installed manually ?
[13:56:13]
<Felix Bartsch> > <@Alekswag:matrix.org> could it be something you installed manually ?
I don't think so - there are only apps from YH catalogue.
But: I had deleted some apps from nextcloud - they where installed only for testing.
[13:56:35]
<Aleks (he/him/il/lui)> i mean a nextcloud extension, not a yunohost app
[13:57:05]
<Felix Bartsch> no, only apps from nextcloud apps stor
[13:57:22]
<Aleks (he/him/il/lui)> yes, so not a "default" module shipped with Nextcloud
[13:57:45]
<Aleks (he/him/il/lui)> i.e. this module is maintained by some folks of the community and doesnt seem to support the migration to 24.x (yet?)
[13:58:24]
<Felix Bartsch> this could be. There are a lot of community-made apps at nextcloud, right?
[13:58:47]
<Felix Bartsch> so you mean one of these apps could be the reason for this error?
[13:58:55]
<Aleks (he/him/il/lui)> yes
[14:01:58]
<Felix Bartsch> okay. Do you have an idea how to solve it? Is there a way to disable/ remove such apps by using the command line/ console?
[14:02:38]
<Aleks (he/him/il/lui)> dunno about the command line but you should be able to go in the admin GUI of Nextcloud and disable the "fulltextsearch" app i suppose
[14:06:08]
<Felix Bartsch> https://aria.im/_matrix/media/v1/download/server-fb.de/QVbpiSAEyEkKjbGZUWUpvbIy
[14:06:40]
<Felix Bartsch> okay, new problem: if i try to open nextcloud I get an error message and the whole server is lagging
[14:07:23]
<Felix Bartsch> so i think admin gui is not possible in this case
[14:08:51]
<Aleks (he/him/il/lui)> dunno what Fehler means, is this like "unauthorized" or something
[14:09:09]
<Felix Bartsch> No, it means "Error"
[17:07:49]
<yvanq> > <@felix:server-fb.de> No, it means "Error"
I had this "crash" trying to solve , through ldap integration in nextcloud, an error in nextcloud "user_ldap Bind failed: 49: Invalid credentials" , I didn't find other solution than restore a backup or reinstall the app. This error stills but I don't touch ldap integration in nextcloud anymore...
[18:06:10]
<Willy> Bonsoir à tous
[18:06:17]
<Willy> J'ai un doute sur le contenu du fichier /etc/yunohost/dyndns/zone
[18:06:38]
<Willy> est ce que quelqu'un pourrait me partager le contenu du sien s'il vous plait?
[18:21:12]
<Guest13> Hi, is it possible to turn off the email verification need of Element / Matrix on Yunohost? I can not find anything about this in the documentation (neither on Element nor Synapse). Thank you in advancec
[18:27:57]
<Thomas Freedman> Debian has what I call a severe BUG that yunohost fails to address, that being the default PATH in the root account - it fails to include /sbin, /usr/sbin, /usr/local/sbin !!!
Many commands, such as adduser cannot be executed because of this problem.
This is not a new issue, it has been a problem for debian since at least the buster release. The fix is to install yunohost using this command line:
curl https://install.yunohost.org > /tmp/yunohost.bash; chmod +x /tmp/yunohost.bash; sed -i -e 's|^set -u|set -u\nexport PATH="/sbin:/usr/sbin:/usr/local/sbin:\$PATH"|' /tmp/yunohost.bash; /tmp/yunohost.bash
[18:34:47]
<Aleks (he/him/il/lui)> hm actually there's a PR for that https://github.com/YunoHost/install_script/pull/67
[18:35:07]
<Aleks (he/him/il/lui)> though I was thinking we could delete that ugly hack about avahi (which is why adduser is needed)
[18:35:47]
<Aleks (he/him/il/lui)> tituspijean: since you are our .local expert ;) -> did you encounter any issue related to the fact that yunohost cannot locally resolve the .local domains
[18:35:57]
<Thomas Freedman> Still, surprising the fix hasn't been incorporated into the install script.
[18:36:01]
<Aleks (he/him/il/lui)> (which is kinda paradoxical haha)
[18:36:57]
<Aleks (he/him/il/lui)> but that's related to the fact that we remove our dependency to the avahi-daemon (server) which in fact is needed to install the client lib ~_~
[18:44:08]
<tituspijean> > <@Alekswag:matrix.org> tituspijean: since you are our .local expert ;) -> did you encounter any issue related to the fact that yunohost cannot locally resolve the .local domains
Do you mean that a YunoHost server cannot do `ping yunohost.local`? 😵💫
[18:45:43]
<Aleks (he/him/il/lui)> yeah
[18:45:48]
<Aleks (he/him/il/lui)> at least if avahi-daemon is not installed
[18:47:24]
<Aleks (he/him/il/lui)> that's because this special resolution needs the nscd/nslcd(?) "mdns" module which is like .. packaged in avahi-daemon
[18:47:27]
<Aleks (he/him/il/lui)> i don't remember the details, that's just the way the debian package exists
[18:47:48]
<tituspijean> Erf you might be right
[18:53:13]
<tituspijean> (Doing some tests...)
[18:53:58]
<Aleks (he/him/il/lui)> ah that's : https://packages.debian.org/bullseye/libnss-mdns
[18:54:03]
<Aleks (he/him/il/lui)> dep: avahi-daemon
[18:56:18]
<Aleks (he/him/il/lui)> but i'm surprised the domain isn't resolved by dnsmasq maybe .. or do we skip .local domain for dnsmasq ?
[18:58:27]
<tituspijean> My VPS (v11.1 broadcasting `vps.local`, both avahi-daemon and libnss-mdns installed) cannot resolve any .local domains. So crazy I never tried it out
[19:00:07]
<tituspijean> And the nsswitch.conf foes refer to mdns
[19:00:29]
<Aleks (he/him/il/lui)> ah even with avahi-daemon and libnss-mdns installed ? x_X
[19:00:49]
<Aleks (he/him/il/lui)> zblerg
[19:00:59]
<tituspijean> yup
[19:01:24]
<tituspijean> /etc/nsswitch/conf:
`hosts: files myhostname mdns4_minimal [NOTFOUND=return] dns`
[19:01:49]
<Aleks (he/him/il/lui)> well that's a good news in some way, that mean we can totally get rid of avahi-stuff in the install script xD
[19:02:14]
<Aleks (he/him/il/lui)> i guess one way to solve the issue could be to dev our own libnss-mdns-like package but hmf
[19:02:24]
<tituspijean> Going back to use avahi for discovery would be simpler
[19:02:49]
<Aleks (he/him/il/lui)> (the issue is also that ideally you want to resolve .local names from other machines too)
[19:03:09]
<Aleks (he/him/il/lui)> yeah
[19:03:14]
<tituspijean> And that would match my "discovery" that we'd need it to resolve .local domains across wireguard
[19:03:19]
<Aleks (he/him/il/lui)> i don't remember why i got rid of it, i just thought it was easy to drop the dependency and voila
[19:03:29]
<tituspijean> I think we confused .local domain broadcasting and .local domain discovery done both with the avahi package
[19:03:39]
<tituspijean> ah yeah, the package is present but the service is disabled on my VPS
[19:03:54]
<tituspijean> yup that's it
[19:03:59]
<Aleks (he/him/il/lui)> hmmmyeah isn't it like going to conflict with port 5353 maybe ?
[19:05:34]
<tituspijean> with `allow-interfaces=wg0,zt3jnskpna` (for wireguard and zerotier respectively) in /etc/avahi/avahi-daemon.conf, it works
[19:05:53]
<tituspijean> > <@Alekswag:matrix.org> hmmmyeah isn't it like going to conflict with port 5353 maybe ?
how could I test that?
[19:06:49]
<Aleks (he/him/il/lui)> eeeh idk, naively `netstat -tulpn | grep 5353`
[19:06:54]
<tituspijean> ```
netstat -tulpn | grep 5353
udp 0 0 0.0.0.0:5353 0.0.0.0:* 3425936/avahi-daemo
udp 0 0 10.145.123.1:5353 0.0.0.0:* 2951537/python3
udp 0 0 0.0.0.0:5353 0.0.0.0:* 2951537/python3
udp 0 0 172.18.0.1:5353 0.0.0.0:* 2951537/python3
udp 0 0 0.0.0.0:5353 0.0.0.0:* 2951537/python3
udp 0 0 172.17.0.1:5353 0.0.0.0:* 2951537/python3
udp 0 0 0.0.0.0:5353 0.0.0.0:* 2951537/python3
udp 0 0 10.10.10.0:5353 0.0.0.0:* 2951537/python3
udp 0 0 0.0.0.0:5353 0.0.0.0:* 2951537/python3
udp 0 0 10.0.0.1:5353 0.0.0.0:* 2951537/python3
udp 0 0 0.0.0.0:5353 0.0.0.0:* 2951537/python3
udp 0 0 10.11.0.1:5353 0.0.0.0:* 2951537/python3
udp 0 0 0.0.0.0:5353 0.0.0.0:* 2951537/python3
udp 0 0 10.0.3.1:5353 0.0.0.0:* 2951537/python3
udp 0 0 0.0.0.0:5353 0.0.0.0:* 2951537/python3
udp6 0 0 :::5353 :::* 3425936/avahi-daemo
```
[19:09:16]
<tituspijean> `Dec 01 20:06:54 rpi.local avahi-daemon[4165419]: *** WARNING: Detected another IPv4 mDNS stack running on this host. This makes mDNS unreliable and is thus>`
eh...
[19:12:20]
<Aleks (he/him/il/lui)> 😬
[19:14:58]
<tituspijean> time to drop yunomdns and use `/etc/avahi/hosts` ? 🙃
[19:21:59]
<Guest13> Thomas Freedman was that directed to me? I did that, but when I try to use the Synapse Admin UI I can not login with any existing user, even though I granted the rights
[19:22:58]
<Aleks (he/him/il/lui)> > <@titus:pijean.ovh> time to drop yunomdns and use `/etc/avahi/hosts` ? 🙃
or to add nss bindings to yunomdns to resolve stuff 😅
[19:23:02]
<Aleks (he/him/il/lui)> python3-zeroconf seems to provide such tools
[19:24:35]
<Aleks (he/him/il/lui)> but i don't know about the nss binding
[19:24:52]
<tituspijean> ooooh
[19:25:03]
<tituspijean> ooooh. :(
[19:25:11]
<Aleks (he/him/il/lui)> yeah
[19:52:00]
<Willy> can you show me your /etc/yunohost/dyndns/zone file please
[19:52:00]
<Willy> Hi
[19:52:27]
<Willy> I think i have a pb with this file
[19:52:38]
<tituspijean> I don't have one since I don't use YunoHost's DynDNS, but IIRC each is unique :/
[19:53:22]
<Willy> ok merci quand même ;) peut-etre quelqu'un d'autre ... :°
[21:02:20]
<Thomas Freedman> I made the mistake of changing the ssh port manually, now I can't use yunohost tools to make further changes to sshd. It says on https://yunohost.org/en/commandline page to use yunohost tools regen-conf --with-diff --dry-run to see changes, which confirm the port number change.
But how can I fix the system so it will resume full control of the modified file? Somewhere yunohost has logged I changed it and regardless of changing it back it will not modify it for any changes now.
Until DNS updates I must use the command line tools via ssh.
[21:03:12]
<tituspijean> `yunohost tools regen-conf ssh --force`
[21:03:36]
<tituspijean> (for my own info, didn't your ssh file had a warning at its beginning?)
[21:04:02]
<Thomas Freedman> Yes, it did. Muy bad! I learned my lesson!!!
[21:04:09]
<tituspijean> (do keep a terminal open before and after running this command...)
[21:04:26]
<Thomas Freedman> Ok, I'll do it now...
[21:08:51]
<Thomas Freedman> I can still login using alternate port, so good. Now to resume my initial config / setup, to disable password auth / login so only ssh keys can be used.
[21:10:26]
<tituspijean> Have you seen we have a global setting for that?
[21:11:45]
<Thomas Freedman> I know there's one in the sshd_config, but haven't stumbled on it in the docs just yet
[21:12:18]
<Thomas Freedman> Or, perhaps I saw the cmd for it in the sshd _config comments.
[21:12:20]
<tituspijean> there you go: https://yunohost.org/en/administer/tutorials/security#ssh-authentication-via-ke :)
[21:12:38]
<Thomas Freedman> Thx!
[21:15:38]
<Thomas Freedman> I disabled the api after reading about it on one of the security pages and thought it was a bit odd to encourage that, as I suspected doing so would disable portions if not most of the web interface. I did get the warning the api wasn't running in the web I/F, even tho I was accessing only with IP address and not logged in. So I re-enabled & restarted it.
[21:16:56]
<tituspijean> What's your feedback on this?
[21:24:42]
<Thomas Freedman> It was actually on that same page as the disable pw auth command you just posted.
My feedback is to explain more directly that ALL administration via the web interface is disabled if you kill the api service.
Once I get more familiar with yunohost I may disable it, but not yet.
Also, as I mentioned, I got the warning without even being logged in or issuing any admin commands. Perhaps if the api is shut down the systemd unit could change the nginx config to disable the web yunohost admin login page entirely, if it's not useful without it.
[21:26:12]
<tituspijean> Thanks for your suggestions. :) Indeed the documentation should be much clearer about it.
[21:39:50]
<tituspijean> Done: https://github.com/YunoHost/doc/pull/2157 :)
[21:49:34]
<Thomas Freedman> What is the sggi user for? It appears to be the first user created with id 1000.
Also, although the user I added via yunohost cmd line shows a valid ssh key, I can't login with it via ssh. I didn't generate the keys on this host, I copied them from elsewhere and moved into place for root, then admin user. Only the pub key, not the private one. For the alternate user:
ssh-copy-id -i ~/.ssh/id_rsa.pub jakedude@mydomain.tld
Failed since it referenced the private key in /root. I just did a "touch /root/id_rsa" then repeated that cmd. Then it reported:
ERROR: ssh: connect to host mydomain.tld port 22: Connection refused
There still seems to be some remnant of the original ssh port saved somewhere in yunohost files.
[21:50:34]
<Thomas Freedman> Or perhpas the ldap server?
[21:55:30]
<Thomas Freedman> I added the -f force option but still complains about port 22
[21:59:37]
<Thomas Freedman> I haven't used ldap in decades. I hope it doesn't require both public AND private keys, that would be bad! I typically just add the pub keys I want to use into .ssh/authorized_keys of the account(s). I won't be scattering my private keys around the universe!
[22:01:36]
<tituspijean> > What is the sggi user for? It appears to be the first user created with id 1000.
That is not included within YunoHost, that's from the initial state of your server.
[22:04:14]
<tituspijean> > Failed since it referenced the private key in /root. I just did a "touch /root/id_rsa" then repeated that cmd. Then it reported:
> ERROR: ssh: connect to host mydomain.tld port 22: Connection refused
If you look at the logs on the server, you'll get the reason. My guess is that the private key does not have the right permissions (`chmod 600 /root/id_rsa`.... but shouldn't it be in /root/.ssh?)
[22:04:58]
<tituspijean> > I haven't used ldap in decades. I hope it doesn't require both public AND private keys, that would be bad! I typically just add the pub keys I want to use into .ssh/authorized_keys of the account(s). I won't be scattering my private keys around the universe!
That is not the case.
[22:05:43]
<tituspijean> I always found the add-key command a bit funky. I do it like you, by appending a one-liner version of the pubkey in `/root/.ssh/authorized_keys`
[22:18:06]
<yvanq> I progress in my Invalid credential loop with Nextcloud...
I don't know if it's my config or a bug, try to switch from a Yunohost user to another one on Firefox, then open a shared link makes nextcloud looping endless...
https://forum.yunohost.org/t/external-access-with-shared-link-almost-impossible-nextcloud-24-07/22402
[22:18:36]
<Thomas Freedman> >If you look at the logs on the server, you'll get the reason. My guess is that the private key does not have the right permissions (chmod 600 /root/id_rsa.... but shouldn't it be in /root/.ssh?)
Nothing about port 22 in /var/log/yunohost/yunohost-cli.log.
I'm trying to give jakedude ssh login ability using ssh keys. I get permission denied on remote side, but looking at his account via another terminal as admin all files & perms look good, as compared with admins.
Isn't there some restriction about only admin is allowed to login via ssh? If so can I open that up? Still puzzled about the port 22 tho, that makes no sense and I see nothing in logs about that error.
[22:20:19]
<tituspijean> > Nothing about port 22 in /var/log/yunohost/yunohost-cli.log.
that would rather be in `journalctl -xe --unit=ssh`
[22:20:27]
<tituspijean> Why are you puzzled by port 22?
[22:22:21]
<tituspijean> Oh my bad, has your user been given the `SSH` permission in the webadmin?
[22:24:41]
<Thomas Freedman> Not using the webadmin until DNS updates. There's a cmd line equiv, right?
Looking in the sysstemd journal...
[22:26:59]
<Thomas Freedman> Here it is:
'none of user's groups are listed in AllowGroups
[22:32:10]
<Thomas Freedman> Trying to figure out how to fix that now...
[22:34:17]
<tituspijean> `yunohost user permission add ssh.main jakedude`
[22:34:31]
<tituspijean> (gotta sleep now, good luck and good night :) )
[22:35:58]
<Thomas Freedman> Thanks a lot for all your help! Sleep well Titus!