[07:56:32]
<orhtej2> > <@geoma:matrix.org> If I decide to use a static site generator (like Zola) instead of a CMS? what is an easy out of the way way to edit the files remotely quickly from my desktop? without having to each time log into ssh, and edit the files?
I'd run the generator locakly and upload to my_webapp
[07:56:33]
<orhtej2> Idk if sftp access is provided to edit via sshfs or winscp or whatever
[07:59:11]
<selfhoster1312> > If I decide to use a static site generator (like Zola) instead of a CMS? what is an easy out of the way way to edit the files remotely quickly from my desktop? without having to each time log into ssh, and edit the files?
some people i know have setup integration with NextCloud or forgejo for this purpose :-)
[09:36:52]
<geoma> Nextcloud is a nice idea! I am trying VS Codium with SSH access
[09:37:22]
<geoma> I guess I could also go VS Codium and upload through sftp?
[09:37:40]
<geoma> (Configure it to do so automatically)
[11:42:19]
<geoma> now, if I want to connect through SSH with a passkey, I want it to be with a non-root user... I just have to give that user write permissions to the /var/www/zola folder ?
[11:44:52]
<geoma> like
[11:51:44]
<geoma> or use the "zola" user? (I noticed there is a "zola" user but have no idea of its password)
[16:47:11]
<orhtej2> > <@geoma:matrix.org> or use the "zola" user? (I noticed there is a "zola" user but have no idea of its password)
Service users typically don't belong to ssh group hence have remote login disabled
[16:47:16]
<geoma> I guess it could be better then to use another user and grant privileges to the zola directory
[17:27:02]
<Chatpitaine Caverne #antifa> Salut,
La mise à jour de Peertube a planté (une fois n'est pas coutume) et la restauration automatique a planté (150Mds de fois est coutume, grâce à NodeJS).
Je joins ici la log de la mise à jour : https://paste.yunohost.org/raw/ituriyufik
Vais voir pour restaurer. Mais là, tout de suite, n'ai pas la force.
[17:41:58]
<Chatpitaine Caverne #antifa> Est-ce qu'il n'y aurait pas moyen de récupérer la version NodeJS installée dans les scripts de restauration plutôt que de prendre la dernière version en date ? Question pas forcément si simple, j'en conviens.
[17:45:18]
<otm33> Tu veux dire, celle utilisée par les fichiers de l'archive?
[17:46:54]
<Chatpitaine Caverne #antifa> Voui, mais aussi NodeJs reste installé, il me semble suite à une désinstall de Peertube après plantage, non ?
[17:51:16]
<otm33> Tu fais vim archive.tar, tu lis le fichier de service pour récupérer la version de nodejs. Puis yunohost app restore backup avec le flag --no-remove-on-failure (l'app ne redémarrera pas) puis tu réinstalles la version dont tu as besoin
`sudo N_PREFIX=/opt/node_n/ /usr/share/yunohost/helpers.v2.1.d/vendor/n/n install VERSION`
Si j'ai bien compris ton besoin, évidemment...
[19:05:31]
<Chatpitaine Caverne #antifa> ça a fonctionné nickel. J'ai donc désormais la version 24.19.0 (celle que voulait la restauration) et la 24.21.0 (la dernière en date).
Le service Peertube a redémarré.
Dans manifest.toml; je pensais, qu'il y avait la version de Node souhaitée, mais il n'y a que la main version (24). ça paraît compliqué de retrouver la version souhaitée par la restauration, mais elle doit être quelque part, vu qu'il demande la 24.19.0, il trouve bien cela quelque part.
[19:17:47]
<otm33> Si je me souviens bien, la restauration va réinstaller la dernière version dispo dans la majeure précisée (22 / 24). C'est donc la dernière mineure en date (par ex .21) qui est installée. Il y avait(a?) des applications pour lesquelles une version précise est pointée dans le manifeste (20.12) ou le \_common.sh. mais généralement c'est la seule majeure qui est précisée.
Cela ne pose problème que pour la restauration d'une archive trop "ancienne" et c'est un peu le serpent qui se mord la queue.
[19:28:30]
<Chatpitaine Caverne #antifa>
> Cela ne pose problème que pour la restauration d'une archive trop "ancienne" et c'est un peu le serpent qui se mord la queue
Pas trop ancienne, il suffit qu'une nouvelle version (ou sous version) de Node soit sortie depuis l'installation (ou la dernière mise à jour) de Peertube pour que la restauration, en cas de plantage d'une mise à jour, ne puisse se faire.
[19:51:18]
<otm33> Chatpitaine Caverne #antifa: Oui, d'où les guillemets.
[19:54:42]
<lautre> Pour Vaultwarden, il y a un "/" qui manque pour l'URL d'accès à l'admin. J'ai posté aujourd'hui un message à ce sujet sur le forum.
Par contre, je pense qu'il n'est pas au bon endroit. Je l'ai mis dans le support.apps. (vu que je donne la solution de contournement)
[19:56:27]
<Pwa> Hello, I'm having a pretty specific problem no one seems to have had and I'm looking for insights from more experienced users. I'm trying to use the Jitsi app, but I have a problem where Jitsi "crashes" (everyone gets disconnected and shown a "retrying connection in \[time\]" screen) as soon as more than one person connects to a room. After spending a few hours looking through logs and matching those logs with the Jitsi source code, I found that it's due to the Jitsi videobridge failing to bind a port on startup. I thought my ports configuration must be incorrect somehow, but after troubleshooting it more, that doesn't seem to be the case, because I found that restarting the jitsi-videobridge service made it work. The jitsi-videobridge service consistently fails to bind the port when I reboot the server, but it can just fine if I manually restart the service afterwards. Looking at the logs, I see that the nftables service responsible for opening ports is started simultaneously with other services, including the Jitsi videobridge service. My conclusion so far is thus that the Jitsi videobridge service is trying to bind the port too early, before the nftables service has fully configured all the ports. So I have two questions:
Does my hypothesis make sense or am I following a wrong trail? And, if it does make sense, how would I go about fixing it? I could just note down that I always need to manually restart the service after rebooting the server, but that's slightly inconvenient
[20:27:52]
<Pwa> Hello, I'm having a pretty specific problem no one seems to have had and I'm looking for insights from more experienced users. I'm trying to use the Jitsi app, but I have a problem where Jitsi "crashes" (everyone gets disconnected and shown a "retrying connection in \[time\]" screen) as soon as more than one person connects to a room. After spending a few hours looking through logs and matching those logs with the Jitsi source code, I found that it's due to the Jitsi videobridge failing to bind a port on startup. I thought my ports configuration must be incorrect somehow, but after troubleshooting it more, that doesn't seem to be the case, because I found that restarting the jitsi-videobridge service made it work. The jitsi-videobridge service consistently fails to bind the port when I reboot the server, but it can just fine if I manually restart the service afterwards. Looking at the logs, I see that the nftables service responsible for opening ports is started simultaneously with other services, including the Jitsi videobridge service. My conclusion so far is thus that the Jitsi videobridge service is trying to bind the port too early, before the nftables service has fully configured all the ports. So I have two questions:
Does my hypothesis make sense or am I following a wrong trail? And, if it does make sense, how would I go about fixing it? I could just note down that I always need to manually restart the service after rebooting the server, but that's slightly inconvenient (PS: J'ai écrit en anglais par défaut, le français est-il préférable sur ce tchat?)
[20:28:18]
<Pwa> Hello, I'm having a pretty specific problem no one seems to have had and I'm looking for insights from more experienced users. I'm trying to use the Jitsi app, but I have a problem where Jitsi "crashes" (everyone gets disconnected and shown a "retrying connection in \[time\]" screen) as soon as more than one person connects to a room. After spending a few hours looking through logs and matching those logs with the Jitsi source code, I found that it's due to the Jitsi videobridge failing to bind a port on startup. I thought my ports configuration must be incorrect somehow, but after troubleshooting it more, that doesn't seem to be the case, because I found that restarting the jitsi-videobridge service made it work. The jitsi-videobridge service consistently fails to bind the port when I reboot the server, but it can just fine if I manually restart the service afterwards. Looking at the logs, I see that the nftables service responsible for opening ports is started simultaneously with other services, including the Jitsi videobridge service. My conclusion so far is thus that the Jitsi videobridge service is trying to bind the port too early, before the nftables service has fully configured all the ports. So I have two questions:
Does my hypothesis make sense or am I following a wrong trail? And, if it does make sense, how would I go about fixing it? I could just note down that I always need to manually restart the service after rebooting the server, but that's slightly inconvenient (PS: J'ai écrit en anglais par habitude, le français est-il préférable sur ce tchat?)
[20:30:13]
<otm33> Pwa: Can you share the output of `sudo lsof -i | grep jitsi` (anonymize the output -domain name-) ?
[20:37:41]
<Pwa> ````
~# sudo lsof -i | grep jitsi
java 946 jitsi 197u IPv6 34836 0t0 TCP localhost:8888 (LISTEN)
java 946 jitsi 198u IPv6 27271 0t0 TCP localhost:33952->localhost:xmpp-client (ESTABLISHED)
java 4001 jitsi 157u IPv6 38343 0t0 UDP [domain name]:10000
java 4001 jitsi 158u IPv6 38344 0t0 UDP [domain name]:10000
java 4001 jitsi 159u IPv6 38345 0t0 UDP [domain name]:10000
java 4001 jitsi 160u IPv6 38346 0t0 UDP [domain name]:10000
java 4001 jitsi 161u IPv6 38347 0t0 UDP [domain name]:10000
java 4001 jitsi 162u IPv6 38348 0t0 UDP [domain name]:10000
java 4001 jitsi 163u IPv6 38349 0t0 UDP [domain name]:10000
java 4001 jitsi 164u IPv6 38350 0t0 UDP [domain name]:10000
java 4001 jitsi 165u IPv6 38351 0t0 UDP [domain name]:10000
java 4001 jitsi 166u IPv6 38352 0t0 UDP [domain name]:10000
java 4001 jitsi 167u IPv6 38353 0t0 UDP [domain name]:10000
java 4001 jitsi 168u IPv6 38354 0t0 UDP [domain name]:10000
java 4001 jitsi 169u IPv6 38355 0t0 UDP [domain name]:10000
java 4001 jitsi 170u IPv6 38356 0t0 UDP [domain name]:10000
java 4001 jitsi 171u IPv6 38357 0t0 UDP [domain name]:10000
java 4001 jitsi 172u IPv6 38358 0t0 UDP [domain name]:10000
java 4001 jitsi 173u IPv6 38359 0t0 UDP [domain name]:10000
java 4001 jitsi 174u IPv6 38360 0t0 UDP [domain name]:10000
java 4001 jitsi 175u IPv6 38361 0t0 UDP [domain name]:10000
java 4001 jitsi 176u IPv6 38362 0t0 UDP [domain name]:10000
java 4001 jitsi 177u IPv6 38363 0t0 UDP [domain name]:10000
java 4001 jitsi 178u IPv6 38364 0t0 UDP [domain name]:10000
java 4001 jitsi 179u IPv6 38365 0t0 UDP [domain name]:10000
java 4001 jitsi 180u IPv6 38366 0t0 UDP [domain name]:10000
java 4001 jitsi 181u IPv6 38367 0t0 UDP [domain name]:10000
java 4001 jitsi 182u IPv6 38368 0t0 UDP [domain name]:10000
java 4001 jitsi 183u IPv6 38369 0t0 UDP [domain name]:10000
java 4001 jitsi 184u IPv6 38370 0t0 UDP [domain name]:10000
java 4001 jitsi 185u IPv6 38371 0t0 UDP [domain name]:10000
java 4001 jitsi 186u IPv6 38372 0t0 UDP [domain name]:10000
java 4001 jitsi 187u IPv6 38373 0t0 UDP [domain name]:10000
java 4001 jitsi 188u IPv6 38374 0t0 UDP [domain name]:10000
java 4001 jitsi 189u IPv6 38375 0t0 UDP [domain name]:10000
java 4001 jitsi 190u IPv6 38376 0t0 UDP [domain name]:10000
java 4001 jitsi 191u IPv6 38377 0t0 UDP [domain name]:10000
java 4001 jitsi 192u IPv6 38378 0t0 UDP [domain name]:10000
java 4001 jitsi 193u IPv6 38379 0t0 UDP [domain name]:10000
java 4001 jitsi 194u IPv6 38380 0t0 UDP [domain name]:10000
java 4001 jitsi 195u IPv6 38381 0t0 UDP [domain name]:10000
java 4001 jitsi 196u IPv6 38382 0t0 UDP [domain name]:10000
java 4001 jitsi 200u IPv6 18983 0t0 TCP localhost:39770->localhost:xmpp-client (ESTABLISHED)
java 4001 jitsi 201u IPv6 38383 0t0 TCP *:9090 (LISTEN)
java 4001 jitsi 224u IPv6 38384 0t0 TCP localhost:http-alt (LISTEN)
````
[20:44:24]
<otm33> And videobridge failed to bind to 0.0.0.0.9090?
[20:46:13]
<Pwa> videobridge is supposed to bind to 10000, that output was from after I manually restarted the service, the output looks like this with a normal server boot where I don't manually restart:
```
sudo lsof -i | grep jitsi
java 944 jitsi 197u IPv6 32145 0t0 TCP localhost:8888 (LISTEN)
java 944 jitsi 198u IPv6 21900 0t0 TCP localhost:54962->localhost:xmpp-client (ESTABLISHED)
java 947 jitsi 160u IPv6 25968 0t0 TCP *:9090 (LISTEN)
java 947 jitsi 183u IPv6 25969 0t0 TCP localhost:http-alt (LISTEN)
java 947 jitsi 204u IPv6 21901 0t0 TCP localhost:54978->localhost:xmpp-client (ESTABLISHED)
```
[20:55:10]
<otm33> It also binds to port 9090 and that could be an issue in previous package versions. Can you share the log showing the failed bind message ?
[21:09:38]
<otm33> Are prosody or metronome installed on your server ?
[21:09:42]
<Pwa> I'm really not sure what's going on here, this is very consistent. If I restart the server and let the service start normally, it fails. If I manually restart the service afterwards, it works fine. But there's no way that's all there is to it because otherwise other users of the Jitsi package would be experiencing this. The log is not super helpful https://paste.yunohost.org/ratuvuqupu.yaml. As far as I could tell from going through the Jitsi source code, the bind failure happens when "No single-port harvesters created." is logged, from there Jitsi considers itself to be in an unhealthy state and while it is capable of recognizing that state and why it is in that state, it does not retry
(for the record, this log is after a server reboot)
[21:11:01]
<Pwa> prosody is installed yes, it's a dependency of the Jitsi package, metronome isn't, the Jitsi package documentation said it needed to be uninstalled, so I did try uninstalling it but it was never installed in the first place
[21:11:49]
<otm33> I mean the prosody application
[21:12:33]
<Pwa> uhhh then no (?) I didn't know there was a prosody application
[21:19:52]
<Pwa> uhhh then no (?) I didn't know there was a prosody application (looked it up, no the app itself is not on the server and never was)
[21:20:40]
<otm33> After restarting the videobridge service, I guess that lsof -i :5222 returns connections established for jitsi user and systemctl status prosody is ok ?
[21:27:46]
<Pwa> yes, but it also does when not restarting the videobridge service
[21:50:22]
<otm33> Try adding this to jitsi-videobridge service :
```
After=network.target <del>network-target.online</del>network-online.target
Wants=<del>network-target.online</del>network-online.target 😱
```
systemctl daemon-reload
That should delay its starting.
[21:50:53]
<otm33> Try adding this to jitsi-videobridge service :
```
After=network.target network-online.target
Wants=network-online.target
```
systemctl daemon-reload
That should delay its starting.
[21:51:32]
<otm33> Try adding this to jitsi-videobridge service :
`sudo nano /etc/systemd/system/jitsi-videobridge.service`
```
After=network.target network-online.target
Wants=network-online.target
```
systemctl daemon-reload
That should delay its starting.
[21:51:38]
<otm33> Try adding this to jitsi-videobridge service :
`sudo nano /etc/systemd/system/jitsi-videobridge.service`
```
After=network.target network-online.target
Wants=network-online.target
```
`systemctl daemon-reload`
That should delay its starting.
[22:05:28]
<Pwa> hm, it does appear to have delayed the start (now it starts ~5 seconds later), however, it still fails in the exact same manner
[22:06:26]
<Pwa> So seemingly I was wrong to think the issue might be that it starts too early