Thursday, April 04, 2024
support@conference.yunohost.org
April
Mon Tue Wed Thu Fri Sat Sun
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19 20
21
22
23
24
25
26
27
28
29
30
         
             

[08:20:25] <Chatpitaine Caverne> Hello people,
Upgrade of nextcloud, no prooblem.
But, wouldn't there be any issue with the CalDAV/CardDAV nginx config, cause in the log it says :

```
2024-04-04 10:04:08,460: DEBUG - + is_url_handled --domain=nub.maindomain.tld --path=/.well-known/caldav
2024-04-04 10:04:08,464: DEBUG - + declare -Ar args_array
2024-04-04 10:04:08,610: DEBUG - ++ curl --insecure --silent --output /dev/null --write-out '%{http_code};%{redirect_url}' https://127.0.0.1/.well-known/caldav --header 'Host: nub.maindomain.tld' --resolve nub.maindomain.tld:443:127.0.0.1
2024-04-04 10:04:08,682: DEBUG - + local 'curl_output=301;https://nub.maindomain.tld/remote.php/dav/'
2024-04-04 10:04:08,683: DEBUG - + local http_code=301
2024-04-04 10:04:08,684: DEBUG - + local redirection=https://nub.maindomain.tld/remote.php/dav/
2024-04-04 10:04:08,686: DEBUG - + '[' 301 = 404 ']'
2024-04-04 10:04:08,687: DEBUG - + [[ https://nub.maindomain.tld/remote.php/dav/ =~ /yunohost/admin ]]
2024-04-04 10:04:08,688: DEBUG - + [[ https://nub.maindomain.tld/remote.php/dav/ =~ /yunohost/sso ]]
2024-04-04 10:04:08,689: DEBUG - + ynh_print_warn '--message=Another app already uses the domain nub.maindomain.tld to serve a CalDAV/CardDAV feature. You may encounter issues when dealing with your calendar or address book.'
2024-04-04 10:04:08,739: DEBUG - + ynh_print_log 'Another app already uses the domain nub.maindomain.tld to serve a CalDAV/CardDAV feature. You may encounter issues when dealing with your calendar or address book.'
2024-04-04 10:04:08,740: DEBUG - + echo -e 'Another app already uses the domain nub.maindomain.tld to serve a CalDAV/CardDAV feature. You may encounter issues when dealing with your calendar or address book.'
2024-04-04 10:04:08,742: WARNING - Another app already uses the domain nub.maindomain.tld to serve a CalDAV/CardDAV feature. You may encounter issues when dealing with your calendar or address book.
2024-04-04 10:04:08,745: DEBUG - + sed --in-place --regexp-extended '/location = \/\.well\-known\/(caldav|carddav)/d' ../conf/nginx.conf
2024-04-04 10:04:08,773: DEBUG - + ynh_add_nginx_config
2024-04-04 10:04:08,775: DEBUG - + local finalnginxconf=/etc/nginx/conf.d/nub.maindomain.tld.d/nextcloud__2.conf
2024-04-04 10:04:08,779: DEBUG - + ynh_add_config --template=nginx.conf --destination=/etc/nginx/conf.d/nub.maindomain.tld.d/nextcloud__2.conf
```

Like if the weel-know was redirected to yunohost-admin and not handled in nginx.

Anyone else encountered that ?
[08:29:11] <Chatpitaine Caverne> Like if this part of the nginx config was missing (indded, it is):

```
# Make a regex exception for `/.well-known` so that clients can still
# access it despite the existence of the regex rule
# `location ~ /(\.|autotest|...)` which would otherwise handle requests
# for `/.well-known`.
location ^~ /.well-known {
# The rules in this block are an adaptation of the rules
# in `.htaccess` that concern `/.well-known`.

location = /.well-known/carddav { return 301 /remote.php/dav/; }
location = /.well-known/caldav { return 301 /remote.php/dav/; }

location /.well-known/acme-challenge { try_files $uri $uri/ =404; }
location /.well-known/pki-validation { try_files $uri $uri/ =404; }

# Let Nextcloud's API for `/.well-known` URIs handle all other
# requests by passing them to the front-end controller.
return 301 /index.php$request_uri;
}
```

Source : https://docs.nextcloud.com/server/28/admin\_manual/installation/nginx.html
[08:38:44] <Chatpitaine Caverne> Sorry I got to move out for important meet. I hate launching a subject and leave. Sorry for that, but no choice. Back in about 3 hours max (hope so).
[08:41:20] <Chatpitaine Caverne> Just in case, here is the full log of the update process, in case there would be something I missed :
https://paste.yunohost.org/raw/amojamuqoj
[10:39:53] <colm> Hi all, I'm looking for any tips or examples of how to setup a custom ynh app (or any alternative process) to host a static website that is updated on a githook. Any ideas? Thanks * 1000 !
[11:33:22] <Chatpitaine Caverne> colm: The my_webapp app can be a good candidate for such needs.
[11:35:23] <colm> > <@chatpitaine:cirkau.art> colm: The my_webapp app can be a good candidate for such needs.

Yes, I found this forum thread https://forum.yunohost.org/t/static-site-app/22393 but not sure where / how to setup a chron or a hook exactly. I'll build fron there!
[12:05:05] <schmorpel> > Hi all, I'm looking for any tips or examples of how to setup a custom ynh app (or any alternative process) to host a static website that is updated on a githook. Any ideas? Thanks * 1000 !
I would like to do sth like this (I think, just learning git though). I'm hosting my static websites using My Webapp and would like to send changes over git. When I try to SSH into the folder on the server I get 'fatal: protocol error: bad line length character: This'
[12:11:26] <schmorpel> > I would like to do sth like this (I think, just learning git though). I'm hosting my static websites using My Webapp and would like to send changes over git. When I try to SSH into the folder on the server I get 'fatal: protocol error: bad line length character: This'
... which I now found is part of the error message 'This service allows sftp connections only.'
[12:17:55] <Salamandar> > <schmorpel> > I would like to do sth like this (I think, just learning git though). I'm hosting my static websites using My Webapp and would like to send changes over git. When I try to SSH into the folder on the server I get 'fatal: protocol error: bad line length character: This'
> ... which I now found is part of the error message 'This service allows sftp connections only.'

what do you mean ssh into the folder ? What’s the exact command you try to run ?
[13:53:15] <Fell> Has anyone ever tried the Element Call app? I just installed it and it's got a lot of 403s and 404s.
[13:53:41] <Fell> I also noticed there's not even a forum for it... is it like really new still?
[13:54:31] <Fell> (I installed it by converting from Debian 11, maybe that's the culprit, lots of apps seem broken)
[14:47:08] <tituspijean> What do you mean by "not even a forum for it", and by "converting from Debian 11"?
And about the 403 and 404s... browser logs?
[16:22:25] <Fell> Yes, I see that in the browser's debug menu, you can look here: https://call.old.fellr.net/
Well, the app page directs me here, which appears to be a dead link: https://forum.yunohost.org/tag/element-call
But I just realised that probably just nobody ever posted anything about Element Call yet.
By "converting from Debian 11" I meant the "VPS or dedicated server with Debian 11" installation method described here: https://yunohost.org/en/install/hardware:vps_debian
[16:22:36] <Fell> Yes, I see that in the browser's debug menu, you can look here to see the problem: https://call.old.fellr.net/
Well, the app page directs me here, which appears to be a dead link: https://forum.yunohost.org/tag/element-call
But I just realised that probably just nobody ever posted anything about Element Call yet.
By "converting from Debian 11" I meant the "VPS or dedicated server with Debian 11" installation method described here: https://yunohost.org/en/install/hardware:vps_debian
[16:23:16] <Fell> Yes, I see that in the browser's debug menu, you can look here to see the problem: https://call.old.fellr.net/

Forum: Well, the app page directs me here, which appears to be a dead link: https://forum.yunohost.org/tag/element-call
(But I just realised that probably just nobody ever posted anything about Element Call yet.)

By "converting from Debian 11" I meant the "VPS or dedicated server with Debian 11" installation method described here: https://yunohost.org/en/install/hardware:vps_debian
[16:33:20] <tituspijean> OK thanks for explaining !
- I have added the element-call tag in the forum, thanks for the heads up! now the page is not giving an error, but indeed there is no threads about that app 🙂
- The method for installing YunoHost should not matter 🙂

Regarding the app, indeed it looks like its frontend is loaded (I see the login form), but all the backend (translations, some fonts, and communication with the Matrix server) is broken. Hell, it even tries to explicitely load the Matrix server from localhost. That does not look right, but I am more used to Element (not Element Call)
[16:35:07] <Fell> When I saw the localhost thing I thought I had forgot to configure the domain, but Yunohost app doesn't even have any settings.
[16:38:23] <tituspijean> It looks like some work has been started to fix that: https://github.com/YunoHost-Apps/element-call_ynh/pull/2
If you are feeling investigative, you can try it too. Remove the current app and reinstall it with this URL `https://github.com/YunoHost-Apps/element-call_ynh/tree/server`
[16:38:30] <Fell> > <@titus:pijean.ovh> OK thanks for explaining !
> - I have added the element-call tag in the forum, thanks for the heads up! now the page is not giving an error, but indeed there is no threads about that app 🙂
> - The method for installing YunoHost should not matter 🙂
>
> Regarding the app, indeed it looks like its frontend is loaded (I see the login form), but all the backend (translations, some fonts, and communication with the Matrix server) is broken. Hell, it even tries to explicitely load the Matrix server from localhost. That does not look right, but I am more used to Element (not Element Call)

The method for installing YunoHost matters at least a little bit. When testing it last year I had an issue with an app (I forgot which) because my clean Debian 11 came with a package preinstalled that YNH didn't expect. I'm really sorry I can't recall the name 🤔
[16:39:13] <tituspijean> ah yeah that can happen. If you can remember both the Debian 11 image source and the package, that would be great 😆
[16:40:51] <tituspijean> (if it was on VPS, I am more inclined to think it's the provider's fault since they tend to add some custom repos or cloud configs, standard Debian 11 images should be fine 🙂 )
[16:49:00] <Fell> > <@titus:pijean.ovh> (if it was on VPS, I am more inclined to think it's the provider's fault since they tend to add some custom repos or cloud configs, standard Debian 11 images should be fine 🙂 )

There! I dug through my browser history for you. I had this issue: https://forum.yunohost.org/t/impossible-dinstaller-lapplication-lxd/19408
I wanted to install LXD and had to remove `busybox` to get it installed.
[16:49:50] <tituspijean> ... are you Collector?
[16:50:01] <Fell> No, I don't speak French.
[16:50:55] <Fell> Interestingly, my current provider's image also comes with busybox
[16:51:58] <Fell> But I never got LXD to work anyways, I just wanted to mention it. I just assumed the original YunoHost images wouldn't have this problem.
[16:52:14] <tituspijean> burn the busibox then 😆
[17:01:36] <Aleks (he/him/il/lui)> > <@fell:fellr.net> There! I dug through my browser history for you. I had this issue: https://forum.yunohost.org/t/impossible-dinstaller-lapplication-lxd/19408
> I wanted to install LXD and had to remove `busybox` to get it installed.

this is an apt dependency issue, but apt is dumb and doesn't provide the appropriate explanation.

You may dig deeper by manually running `apt install --dry-run btrfs-progs liblzo2-2 lxc bridge-utils debootstrap libpam-cgfs lxcfs lxc-templates uidmap squashfs-tools tcl8.6 libtcl8.6` (note the --dry-run flag to tell that it's just a simulation such that it spits the error message)
[17:03:23] <Fell> > <@Alekswag:matrix.org> this is an apt dependency issue, but apt is dumb and doesn't provide the appropriate explanation.
>
> You may dig deeper by manually running `apt install --dry-run btrfs-progs liblzo2-2 lxc bridge-utils debootstrap libpam-cgfs lxcfs lxc-templates uidmap squashfs-tools tcl8.6 libtcl8.6` (note the --dry-run flag to tell that it's just a simulation such that it spits the error message)

Hm It looks like my current server wouldn't have this problem. The dry run went without any issues. Maybe there _was_ something weird about the Netcup image.
[17:06:14] <Fell> It appears busybox gets replaced with busybox-static. Come to think of it, Netcome preinstalled some autoconfiguration scripts, maybe those depended on busybox? Eh, it's all in the past. ¯\\_(ツ)_/¯
[17:06:32] <Fell> It appears busybox gets replaced with busybox-static. Come to think of it, Netcome preinstalled some autoconfiguration scripts, maybe those depended on busybox? Eh, it's all in the past. ¯\\\_(ツ)\_/¯
[17:06:38] <Fell> It appears busybox gets replaced with busybox-static. Come to think of it, Netcome preinstalled some autoconfiguration scripts, maybe those depended on busybox? Eh, it's all in the past. `¯\_(ツ)_/¯`
[17:08:09] <tituspijean> FYI I tried to install it on my server, but I don't have enough ram/swap to compile it 😕
[17:12:18] <Fell> > <@titus:pijean.ovh> It looks like some work has been started to fix that: https://github.com/YunoHost-Apps/element-call_ynh/pull/2
> If you are feeling investigative, you can try it too. Remove the current app and reinstall it with this URL `https://github.com/YunoHost-Apps/element-call_ynh/tree/server`

I installed it through the URL you gave me, and it looks like it made the problem even worse: https://call.old.fellr.net/
*sigh* I really love the idea of YunoHost, but it's not as simple as it seems. Maybe I can help fix the package when I got a bit more time.
[17:13:34] <tituspijean> Yeah thanks for investigating. Here the issue is that the app has been declared as working, while it is absolutely not. Sorry about that :/
[17:18:35] <Fell> Can it be declared as broken?
[17:32:56] <Mateusz Szymański> If you feel like experimenting I have a gut feeling that changing NGINX `root` from `$install_dir` to `$install_dir/dist` will solve the issue
[17:33:01] <Salamandar> As a temporary fallback you can install cinny
[17:41:34] <tituspijean> It supports Element Call? ... and actually, what's the difference between Element Call and the phone and camera buttons I see at the top of the page in Element?
[17:44:45] <Fell> Element Call is a completely separare project which aims to replace Jitsi (which I also can't get to work lol)
[17:45:54] <Salamandar> ah no, sorry didnt see you were talking about element call
[17:46:03] <Salamandar> i only saw element
[17:52:19] <orhtej2> > <@orhtej2:matrix.org> If you feel like experimenting I have a gut feeling that changing NGINX `root` from `$install_dir` to `$install_dir/dist` will solve the issue

it's already doing that
[18:59:14] <qasm> 839ty9:
[19:46:30] <orhtej2> > it's already doing that

solution for `element-call` woes is `chgrp -R www-data /var/www/element-call/dist` and `chmod 444 /var/www/element-call/config.json`