[01:03:06]
<miro5001> I think we need a spam filter for the forum
https://meta.discourse.org/t/discourse-akismet/109337
[05:12:27]
<orhtej2> > <@miro5001:matrix.org> I think we need a spam filter for the forum
> https://meta.discourse.org/t/discourse-akismet/109337
Holy cow the spam is real
[07:00:16]
<Seb l'e-Woke végétal> Je cherche une application VPN sur Yunohost, pas dans le sens où mon serveur Yunohost utilise un VPN mais dans le sens où mon PC perso puisse utiliser la connexion de mon serveur Yunohost. *VPN client* semble être dans l’autre sens.
En fait, je suis embêté sur mon PC perso, qui utilise une connexion FAImaison (FFDN). Certains services (comme Youtube, mais il y en a d’autres) blacklistent les connexions FFDN, ce qui m’oblige à créer de comptes chez eux. J’aimerai éviter ça. Mon serveur Yunohost est sur une connexion NordNet (Orange). J’aimerai donc pouvoir l’utiliser juste pour certains services.
[08:18:56]
<montaropdf> OpenVPN n'est pas disponible sur Yunohost, ou le système Debian sur lequel il se base?
[08:27:20]
<Seb l'e-Woke végétal> ¿ De cette façon là ça marcherait ?
https://www.it-connect.fr/debian-11-et-openvpn-comment-creer-son-propre-serveur-vpn/
[09:49:35]
<Salamandar> Il existe https://apps.yunohost.org/app/wireguard elle est marquée comme cassée, elle s'installe correctement, mais je crois que personne n'a vérifié qu'elle fonctionne entièrement correctement
[09:50:11]
<centralscrutinizer> It woks for me very well
[10:12:11]
<pinq> Any good ways to hard remove app? I removed trilium in cli, but when I connect to server, I can still se the trilium files in yunohost.app folder
[11:58:57]
<orhtej2> > <@pinq:kapsi.fi> Any good ways to hard remove app? I removed trilium in cli, but when I connect to server, I can still se the trilium files in yunohost.app folder
Just delete the folder, purging data dir is some additional switch in cli
[14:43:17]
<thatoo> Hello,
I have fresh installed ynh on the domain `` yuno.domain.tld `` that manage also the following domain : `` domain.tld ``, `` nextcloud.domain.tld ``
If I go to the page `` yuno.domain.tld/yunohost/admin/#/domains/plans-construction.fr/dns `` to get information to enter in the DNS zone, it gives me the DKIM only for the domain `` yuno.domain.tld `` .
I need the DKIM for the main domain `` domain.tld `` .
In other ynh I manage, it gives me all DKIM for all domain and subdomain but this time, it seems to be missing.
Of course, all email I send from @domain.tld are going into spam because the DKIM is missing.
[14:44:58]
<Aleks (he/him/il/lui)> so YunoHost gives you the DKIM dns stuff for the sub domain but not the main domain ? x_X
[14:48:51]
<Aleks (he/him/il/lui)> Is the 'mail outgoing' feature enabled for that main domain ?
[14:50:46]
<thatoo> I don't know, I've never checked that before, will do right now
[14:51:32]
<thatoo> yes it does. They all have it enabled
[14:52:05]
<thatoo> I'm tryiung toi disable it and enable it again
[14:52:48]
<thatoo> it didn't help
[15:05:09]
<thatoo> I'd say for one sub domain but not the main domain nor other sub domain.
I mention that I install ynh on thsi subdomain and I addes the other domain (the main domain and other sub domain) after installation.
[15:19:37]
<thatoo> I of course tried to reboot ynh but it didn't help.
[15:40:18]
<thatoo> If I click on "Define as default" for the main domain what does it do?
Could that help?
Can I reverse and again "Define as default" yuno.domain.tld?
[15:49:50]
<thatoo> I did that after a snapshot of the VM and it did solve my issue
[15:50:22]
<thatoo> ynh gives a dkim for the main domain and all sub domain
[15:50:29]
<thatoo> cool and thanks
[20:31:02]
<pinq> > <@pinq:kapsi.fi> Hi everyone, I'm still fighting with trilium backup. I can install my trilium backup, but it dosent work. I get bad gateway. I tried to install new trilium from app:s and the replace the db with old one, but then I will get this error `App db version is 228, while db version is 194. Migration needed.`
Manage to install old yunohost and replace the database. Now I want to update from 50->63, but can I do it step by step(50->51->52->53)? Not like 50->63?
[21:16:00]
<Hook> Is there a good reason why by default mail in and out is enabled for all domains? Is there a good reason to turn these off for most of them?
[21:16:01]
<Wally> Greetings, friends -
I've had Yunohost running on an old computer for a year or two, currently at version 12.0.
```
# yunohost --version
yunohost:
repo: stable
version: 12.0.9.1
yunohost-admin:
repo: stable
version: 12.0.4
yunohost-portal:
repo: stable
version: 12.0.7
moulinette:
repo: stable
version: 12.0.3
ssowat:
repo: stable
version: 12.0.3
```
I have an unhelpful habit of overlooking errors when they're brought to my attention ("but, things seem like they're working, so I'll just wait and see what happens," I say foolishly), and since the end of July I've been overlooking the fact that mongod.service keeps failing on boot and also when I attempt to restart it manually. Yesterday I simply disabled mongod for the time being.I'm finally digging into the mongodb logs (all 1.5GB of them) and
[21:22:33]
<Aleks (he/him/il/lui)> not sure about mail in, but "mail out" is somewhat important because apps are likely to need to be able to send mails ... maybe
[21:23:34]
<Aleks (he/him/il/lui)> theoretically it would be cool if yunohost could infer that apps need to be able to send/receive email and then check the consistency between this and the fact that mail in/out is enabled for the domain
[21:24:02]
<Hook> That would be very cool, yes. Thanks for explaining :)
[21:24:46]
<Hook> OK, I have a silly SSH question, if anyone’s up for that …
Since my long-winded migration, I have also tried to clean up the `~/.ssh/known_hosts` on my laptop, and it seems I was a bit too hasty.
[21:26:06]
<Hook> What happens now is that when I try to `ssh` to my ynh server, I get
• “Host key for $IP has changed and you have requested strict checking”; or
• $user@$domain: Permission denied (publickey).”
[21:27:23]
<Hook> But if I force it with using `ssh -i $private_key_i_still_have`, then it works.
[21:28:24]
<Hook> Does anyone know by heart what exactly is needed to get this working again? (RTFM is a very acceptable answer, but would take me quite some time to find the right info)
[21:31:04]
<hueso> is the key you pass with -i the same as the default one?
[21:33:10]
<hueso> you might have some entries in `~/.ssh/config` besides `known_hosts`
[21:33:14]
<Hook> hueso , no it’s one I specifically made for the my_laptop-to-ynh_server connection
[21:33:59]
<Hook> I know I messed around with `known_hosts` XD
[21:34:32]
<hueso> so you tweaked your config to use that specific key for that host
[21:35:00]
<Hook> > <hueso> you might have some entries in ~/.ssh/config besides known_hosts
I think I see a solution. BBL
[21:35:21]
<Hook> > <hueso> so you tweaked your config to use that specific key for that host
Apparently not, which is odd, because I did for the other specific server keys. I’ll do that now.
[21:35:51]
<Wally> I'm not done yet, but I hit the return key to send the message and I don't want to delete it and repost. I'll continue my plea here.
[21:39:22]
<Wally> Greetings, friends -
I've had Yunohost running on an old computer for a year or two, currently at version 12.0.
```
# yunohost --version
yunohost:
repo: stable
version: 12.0.9.1
yunohost-admin:
repo: stable
version: 12.0.4
yunohost-portal:
repo: stable
version: 12.0.7
moulinette:
repo: stable
version: 12.0.3
ssowat:
repo: stable
version: 12.0.3
```
I have an unhelpful habit of overlooking errors when they're brought to my attention ("but, things seem like they're working, so I'll just wait and see what happens," I say foolishly), and since the end of July I've been overlooking the fact that mongod.service keeps xiting with [status 62](https://www.mongodb.com/community/forums/t/mongod-service-control-process-exited-code-exited-status-62/200143) on boot and also when I attempt to restart it manually. Yesterday I simply disabled mongod for the time being.
```
# service mongod status
○ mongod.service - MongoDB Database Server
Loaded: loaded (/lib/systemd/system/mongod.service; disabled; preset: enabled)
Active: inactive (dead)
Docs: https://docs.mongodb.org/manual
```
I'm finally digging into the mongodb logs (all 1.5GB of them) and have found the first instance of what I believe is my problem, an upgrade from MongoDB 4.4 to something > 6.0 without walking through 5.0 territory.
```
# mongod --version
db version v7.0.12
Build Info: {
"version": "7.0.12",
"gitVersion": "b6513ce0781db6818e24619e8a461eae90bc94fc",
"openSSLVersion": "OpenSSL 1.1.1w 11 Sep 2023",
"modules": [],
"allocator": "tcmalloc",
"environment": {
"distmod": "debian11",
"distarch": "x86_64",
"target_arch": "x86_64"
}
}
```
```
# grep featureCompatibilityVersion mongod.log | head -3 | tail -1 | jq
{
"t": {
"$date": "2024-07-31T17:54:55.752-07:00"
},
"s": "F",
"c": "CONTROL",
"id": 20573,
"ctx": "initandlisten",
"msg": "Wrong mongod version",
"attr": {
"error": "UPGRADE PROBLEM: Found an invalid featureCompatibilityVersion document (ERROR: Location4926900: Invalid featureCompatibilityVersion document in admin.system.version: { _id: \"featureCompatibilityVersion\", version: \"4.4\" }. See https://docs.mongodb.com/master/release-notes/6.0-compatibility/#feature-compatibility. :: caused by :: Invalid feature compatibility version value '4.4'; expected '6.0' or '6.3' or '7.0'. See https://docs.mongodb.com/master/release-notes/6.0-compatibility/#feature-compatibility.). If the current featureCompatibilityVersion is below 6.0, see the documentation on upgrading at https://docs.mongodb.com/master/release-notes/6.0/#upgrade-procedures."
}
}
```
I understand from the MongoDB docs that I need to upgrade to 5.0, then 6.0, then 7.0 in order to keep featureCompatibilityVersion happy.
While I'm comfortable at the linux command line, I'm wary of the cascading dependencies that may bury me if I uninstall mongodb-org-server 7.0.12 and install 4.4.29, then pursue the upgrades.
[21:39:30]
<Wally> So, here's the mongo bits on my system:
```
# apt list | grep mongodb-org
WARNING: apt does not have a stable CLI interface. Use with caution in scripts.
mongodb-org-database-tools-extra/now 4.4.29 amd64 [installed,local]
mongodb-org-database/now 7.0.12 amd64 [installed,local]
mongodb-org-mongos/now 4.4.29 amd64 [installed,local]
mongodb-org-server/now 7.0.12 amd64 [installed,local]
mongodb-org-shell/now 4.4.29 amd64 [installed,local]
mongodb-org-tools/now 7.0.12 amd64 [installed,local]
mongodb-org/now 7.0.12 amd64 [installed,local]
```
[21:40:12]
<Hook> > <@silverhook:matrix.org> Apparently not, which is odd, because I did for the other specific server keys. I’ll do that now.
This worked. Thanks for pointing me in the right direction, hueso ♥️
[21:40:30]
<Wally> What is the path back to MongoDB wholeness?
[21:47:28]
<Wally> The upgrade to MongoDB 7.0 was part of a system or application upgrade. I have installed nothing on this machine outside of the Yunohost interface except for a command line web browser `lynx`.
[21:49:41]
<orhtej2> > <@wwharton:matrix.org> What is the path back to MongoDB wholeness?
https://www.youtube.com/watch?v=LPTVdbjWd-I
[21:55:05]
<Wally> Thanks, @orhtej2 ! I'll put that in the queue :-)
Still wondering about a safe upgrade path.
[21:58:59]
<orhtej2> you're on bookworm?
[22:00:23]
<orhtej2> > https://www.youtube.com/watch?v=LPTVdbjWd-I
it's an 18s clip of Dead Space where Elisabeth (?) says 'Make us whole again', end of off topic joke ;)
[22:00:58]
<orhtej2> > <@wwharton:matrix.org> Thanks, @orhtej2 ! I'll put that in the queue :-)
> Still wondering about a safe upgrade path.
reason I'm asking is Bookworm ships 6.x (?) at least so with 5.x you're out of luck from official sources I think
[22:03:20]
<Wally> Yep, bookworm.
```
# cat /etc/os-release
PRETTY_NAME="Debian GNU/Linux 12 (bookworm)"
NAME="Debian GNU/Linux"
VERSION_ID="12"
VERSION="12 (bookworm)"
VERSION_CODENAME=bookworm
ID=debian
HOME_URL="https://www.debian.org/"
SUPPORT_URL="https://www.debian.org/support"
BUG_REPORT_URL="https://bugs.debian.org/"
```
[22:03:20]
<orhtej2> steps to fix are
1. add repo with version N, starting with 5
2. run ```
mongosh --quiet \<\<EOF
db.adminCommand({setFeatureCompatibilityVersion: "$next\_mongo\_version"})
quit()
EOF
}
```
substituting `$next_mongo_version` with N IIRC
3) repeat step 1 untill you reach version 7
[22:03:32]
<orhtej2> > <@wwharton:matrix.org> Yep, bookworm.
> ```
> # cat /etc/os-release
> PRETTY_NAME="Debian GNU/Linux 12 (bookworm)"
> NAME="Debian GNU/Linux"
> VERSION_ID="12"
> VERSION="12 (bookworm)"
> VERSION_CODENAME=bookworm
> ID=debian
> HOME_URL="https://www.debian.org/"
> SUPPORT_URL="https://www.debian.org/support"
> BUG_REPORT_URL="https://bugs.debian.org/"
> ```
you're toast
[22:03:51]
<orhtej2> the other way around that is to dump the database, go straight to 7.x and restore the database
[22:04:02]
<orhtej2> (dump while you still can with 4.x)
[22:04:20]
<orhtej2> (and you can't because you're on bookworm)
[22:04:28]
<orhtej2> (MongoDB was a mistake)
[22:07:21]
<Wally> So, dumping the database is *not* possible because I'm on bookworm?
[22:08:15]
<orhtej2> you need mongo that's able to load the data AND run on bookworm, I see no such option here: https://repo.mongodb.org/apt/debian/dists/bookworm/mongodb-org/5.0/main/binary-amd64/
[22:10:28]
<orhtej2> yeah, all of these require running `mongod`
[22:12:12]
<orhtej2> wait, do you happen to have an app installed that uses MongoDB or there's a lefrover MongoDB failing randomly?
[22:12:48]
<orhtej2> (if the latter just uninstall, remove with `yunohost service remove mongod` and move on with your life, MongoDB is not a hard dependency for ynh)
[22:13:15]
<orhtej2> you can clean up stale data files afterwards
[22:15:52]
<Wally> It might have been a trial install of Wekan that I had for a couple months and uninstalled, maybe because of problems I was uninterested in tracking down. If mongod isn't needed for ynh, I'm willing to remove it.
Will ynh raise an error if there are dependencies when I remove the service?
[22:20:30]
<orhtej2> theoretically yes but i've seen no
[22:21:09]
<Wally> fair. It's gone now.
[22:21:23]
<orhtej2> would you mind sharing output of `sudo yunohost app list`?
[22:21:42]
<orhtej2> `wekan` was my prime suspect of the one pulling MongoDB and being a fairly popular app
[22:22:10]
<orhtej2> > would you mind sharing output of `sudo yunohost app list`?
(this lists the apps you have installed)
[22:22:12]
<Wally> ```
# yunohost app list
apps:
0:
description: Browsing, reading and downloading eBooks using a Calibre database
domain_path: yh.walstr.org/calibre
id: calibreweb
name: Calibre-web
version: 0.96.24~ynh1
1:
description: RSS aggregator with a nice and mobile-friendly design
domain_path: yh.walstr.org/rss
id: freshrss
name: FreshRSS
version: 1.24.3~ynh1
2:
description: Media System that manage and stream your media
domain_path: yh.walstr.org/jellyfin
id: jellyfin
name: Jellyfin
version: 10.10.1~ynh1
3:
description: Online storage, file sharing platform and various other applications
domain_path: yh.walstr.org/nextcloud
id: nextcloud
name: Nextcloud
version: 29.0.10~ynh2
4:
description: AI-Powered Photos App for the Decentralized Web
domain_path: yh.walstr.org/photoprism
id: photoprism
name: Photoprism
version: 2024.05.31~ynh1
5:
description: Web interface for generating QR codes
domain_path: yh.walstr.org/libreqr
id: qr
name: LibreQR
version: 2.0.1~ynh1
6:
description: Manage passwords and other sensitive informations
domain_path: yh.walstr.org/vault
id: vaultwarden
name: Vaultwarden
version: 1.32.6~ynh1
7:
description: Save and classify articles. Read them later
domain_path: yh.walstr.org/wallabag
id: wallabag2
name: Wallabag
version: 2.5.4~ynh9
```
[22:22:47]
<orhtej2> you're good, there was/is a bug in helper that does not clean up the stale mongodb instances
[22:23:04]
*Wally notes the bad habit of living in the shell as root. oops.
[22:23:12]
<orhtej2> I would still hunt down MongoDB data dir and kill it in case you need it in the future
[22:24:14]
<Wally> kill it, as in `rm -r /var/lib/mongodb`?
[22:25:03]
<orhtej2> > * <@wwharton:matrix.org> notes the bad habit of living in the shell as root. oops.
that's OK given `yunohost` has to be run as `root`, OTOH I once issued `chmod whatever .` being in the wrong dir as `root` so 0/10, would not recommend
[22:25:43]
<Wally> That's where all the *.wt files are, and the path found in /etc/mongod.conf
[22:26:31]
<orhtej2> > <@wwharton:matrix.org> kill it, as in `rm -r /var/lib/mongodb`?
kill it as in search the internet for where does mongo store the data and if it happens to be `/var/lib/mongodb` then yes, but thinking twice takes 1 second, being wrong as `root` takes restoring VM from the backup
[22:27:20]
<orhtej2> > kill it as in search the internet for where does mongo store the data and if it happens to be `/var/lib/mongodb` then yes, but thinking twice takes 1 second, being wrong as `root` takes restoring VM from the backup
(ask me how I know)
[22:29:06]
<orhtej2> (yes, I know by restoring/reimaging and restoring from backup after `chown /`)
[22:31:34]
<Wally> ```
storage:
dbPath: /var/lib/mongodb
systemLog:
destination: file
logAppend: true
path: /var/log/mongodb/mongod.log
net:
port: 27017
bindIp: 127.0.0.1
processManagement:
timeZoneInfo: /usr/share/zoneinfo
```
[22:31:58]
<Wally> Thanks for the reality check about the data dir.
[22:35:23]
<Wally> I've removed the mongod service and the data files remain in place. I'll bounce the server and watch what happens, and I'm feeling pretty good about this.
Thank you for your help, orhtej2