[04:13:57]
<grahamalamadingdong> 👋 hey everyone. I'm thinking about how to follow [the docs](https://yunohost.org/en/external_storage) for adding external storage, but I want to do so securely.
I have yunohost installed on a Raspberry Pi at home which is exposed to the internet. I forward ports 22, 80, and 443 on my router to the Pi.
I also have a Synology NAS on my local network, which isn't currently exposed to the internet.
To add extra storage, I was thinking I'd mount a shared folder from my NAS on the Pi, but I want to do so securely.
What are some considerations that I should make here, if any? Does it matter which protocol I use (SMB with credentials or NFS), which user I mount the directory with, or where I mount the directory? Is this generally a bad idea?
[10:36:46]
<loickdiroll> Bonjour ! J'ai pas réussi a voir sur le forum on est d'accord que le packet Movim pour Yunoost est cassé non ? La je dois passer par mov.im pour l'utiliser.
[10:50:06]
<tituspijean> Selon le dernier test automatisé il y a 5 jours, il n'est pas cassé. Quel est ton problème ?
[10:57:41]
<anubis> Lors de mes derniers essais (mais cela remonte à plusieurs mois), je n'arrivais pas à me logger mais peut-être il y a une nouvelle version entre temps. Quel est le problème rencontré loickdiroll ?
[11:01:37]
<tituspijean> grahamalamadingdong: welcome! what do you mean by "securely"?
If ports for SMB and NFS are not opened in the router firewall, you should be safe from external threats.
- After a (too?) quick glance at the default SMB configuration of the samba_ynh package, there might (I am no expert) be conditions were data transfer is not encrypted (it depends on the client). Check the clients ;)
- I cannot answer on NFS
- another option is a SSHFS mount
Regarding which system user should perform the mount, or which groups should have access to it, it depends on what you want to do. If it's in a Nextcloud-like condition, I would give read and write access to the `multimedia` group. Note that any app belonging to it would have full access.
Note that if you only need Nextcloud for storage access, you can directly set an external storage as SFTP or SMB/CIFS without setting up a system mount point.
[11:52:59]
<loickdiroll> > Lors de mes derniers essais (mais cela remonte à plusieurs mois), je n'arrivais pas à me logger mais peut-être il y a une nouvelle version entre temps. Quel est le problème rencontré loickdiroll ?
Effectivement c'est dans ce sens là il est impossible de se connecter (en plus la version de Movim fournie est pas a jour).
Et quand j'arrivais à me connecter avant c'était impossible d'envoyer un media.
[12:17:40]
<anubis> cf https://github.com/YunoHost-Apps/movim_ynh/issues/56
https://github.com/YunoHost-Apps/movim_ynh/issues/47
il faudrait que le package soit mis à jour
[13:26:04]
<westbam> Salut, j'ai un souci pour utiliser tootctl sur mon instance mastodon (package yunohost)
[13:26:46]
<westbam> rbenv: version `3.2.3' is not installed (set by /var/www/mastodon/live/.ruby-version)
[13:39:54]
<westbam> c'est bon j'ai trouvé comment lancer les commandes tootctl ..... suffit de prendre le temps de trouver et lire la doc ;-)
[14:08:38]
<isAAAc> hi here,
i need your help to upgrade mastodon,
i tried to exclude data from backup, because during the upgrade:
`The archive will contain about 196.5GB of data` gives me a full disk issue
to exclude i did:
`yunohost app setting mastodon do_not_backup_data -v 1` cf https://yunohost.org/fr/backup/include_exclude_files
[14:09:37]
<isAAAc> but when i restart the upgrade, the backup size pointed in the log file is still saying 196.5GB of data
[14:09:48]
<isAAAc> did i missed something some step ?
[14:13:49]
<tituspijean> isAAAc: I think it's because there is no `--is_big` flag for the backup of the installation directory of Mastodon. Can you check that it's actually what's 197GB with `du -hs /var/www/mastodon` ?
[14:33:28]
<isAAAc> du -hs /var/www/mastodon launched, computing ...
[14:34:48]
<tituspijean> yeah hum... if it takes more than a few seconds, it's definitely the big directory 😅
[14:38:44]
<tituspijean> so, the issue is that I'm guessing most of the data is actually media shared on mastodon and stored on your server.
but it's stored in the same directory as the configuration for mastodon, and the backup script does not discriminate
[14:39:29]
<tituspijean> I would suggest first to do a bit of cleanup. I was about to look for a similar writeup I think I made on the forum, but obviously it's giving an error 500 right now...
[14:44:13]
<tituspijean> ```
sudo -u mastodon bash
cd /var/www/mastodon/live
bin/tootctl cache clear
bin/tootctl media remove-orphans --dry-run
bin/tootctl media remove --days 30 --dry-run
```
30 means it will remove any media older than 30 days.
For more information on what you can do: https://docs.joinmastodon.org/admin/tootctl/
If you are happy with the dry-run output, remove the `--dry-run` flags to actually remove data
[14:47:42]
<isAAAc> ok , i try this way, thx tituspijean ,
wip
[14:50:28]
<isAAAc> ```mastodon@krashboyz:~/live$ bin/tootctl cache clear
/usr/bin/env: ‘ruby’: No such file or directory
```
[14:50:35]
<tituspijean> `tootctl preview_cards remove --dry-run` might be a good command too (180 days by default)
[14:50:49]
<tituspijean> erf sorry... we need to update the PATH
[14:53:14]
<tituspijean> dang that would be much easier if the app were in packaging v2
[14:54:10]
<tituspijean> can you do `grep Environment /etc/systemd/system/mastodon-web.service` ?
[14:55:29]
<tituspijean> (in a root shell)
[14:55:30]
<isAAAc> ```
root@krashboyz:~# grep Environment /etc/systemd/system/mastodon-web.service
Environment="LD_PRELOAD=/usr/lib/x86_64-linux-gnu/libjemalloc.so"
Environment="RAILS_ENV=production"
Environment="PORT=3000"
Environment="PATH=/opt/rbenv/versions/mastodon/bin:/opt/node_n/n/versions/node/16/bin:/opt/node_n/bin:/opt/rbenv/shims:/opt/rbenv/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/opt/rbenv/shims:/opt/rbenv/bin:/opt/rbenv/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/opt/rbenv/shims:/opt/rbenv/bin:/opt/rbenv/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/opt/rbenv/shims:/opt/rbenv/bin:/opt/rbenv/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/opt/rbenv/shims:/opt/rbenv/bin:/opt/rbenv/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/opt/rbenv/shims:/opt/rbenv/bin:/opt/rbenv/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/opt/rbenv/shims:/opt/rbenv/bin:/opt/rbenv/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/opt/rbenv/shims:/opt/rbenv/bin:/opt/rbenv/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/opt/rbenv/shims:/opt/rbenv/bin:/opt/rbenv/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/opt/rbenv/shims:/opt/rbenv/bin:/opt/rbenv/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
```
[14:56:03]
<tituspijean> wow, I'll suggest to rename that variable PAAAAAAAAAAAAATH 🙃
[14:56:03]
<tituspijean> so, back to the bash shell running as mastodon:
[14:56:24]
<tituspijean> `export PATH=/opt/rbenv/versions/mastodon/bin:/opt/node_n/n/versions/node/16/bin:/opt/node_n/bin:/opt/rbenv/shims:/opt/rbenv/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/opt/rbenv/shims:/opt/rbenv/bin:/opt/rbenv/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/opt/rbenv/shims:/opt/rbenv/bin:/opt/rbenv/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/opt/rbenv/shims:/opt/rbenv/bin:/opt/rbenv/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/opt/rbenv/shims:/opt/rbenv/bin:/opt/rbenv/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/opt/rbenv/shims:/opt/rbenv/bin:/opt/rbenv/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/opt/rbenv/shims:/opt/rbenv/bin:/opt/rbenv/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/opt/rbenv/shims:/opt/rbenv/bin:/opt/rbenv/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/opt/rbenv/shims:/opt/rbenv/bin:/opt/rbenv/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/opt/rbenv/shims:/opt/rbenv/bin:/opt/rbenv/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin`
[14:57:14]
<tituspijean> (looking at it, there's definitely a bug in here, maybe it's reappended upon every upgrade)
[14:57:14]
<isAAAc> yep was thinking at this point too
[14:57:34]
<tituspijean> anyways, after that, you should be able to run the tootctl commands
[14:58:50]
<isAAAc> ERROR: Missing RAILS_ENV, i do `RAILS_ENV=production`
[14:59:10]
<isAAAc> hum it doesn't help
[14:59:38]
<isAAAc> ```
mastodon@krashboyz:~/live$ bin/tootctl cache clear
ERROR: Missing RAILS_ENV environment variable, please set it to "production", "development", or "test".
mastodon@krashboyz:~/live$ RAILS_ENV=production
mastodon@krashboyz:~/live$ bin/tootctl cache clear
ERROR: Missing RAILS_ENV environment variable, please set it to "production", "development", or "test".
```
[14:59:47]
<tituspijean> > yep was thinking at this point too
https://github.com/YunoHost-Apps/mastodon_ynh/issues/441 FYI
[15:00:13]
<tituspijean> > ```
> mastodon@krashboyz:~/live$ bin/tootctl cache clear
> ERROR: Missing RAILS_ENV environment variable, please set it to "production", "development", or "test".
> mastodon@krashboyz:~/live$ RAILS_ENV=production
> mastodon@krashboyz:~/live$ bin/tootctl cache clear
> ERROR: Missing RAILS_ENV environment variable, please set it to "production", "development", or "test".
> ```
try `export RAILS_ENV=production`
[15:06:38]
<oufmilo> RAILS_ENV=production bundle exec bin/tootctl media remove --days=60 --dry-run
[15:07:32]
<oufmilo> that's the command i run every weeks without --dry-run
[15:15:33]
<oufmilo> Does it work for you isAAAc ?
[15:17:17]
<isAAAc> `bin/tootctl media remove-orphans` is running
[15:17:40]
<isAAAc> oufmilo: you set your command in a cron ?
[15:18:33]
<isAAAc> i believed there was a masto setting to rm all datas more old than <T> time
[15:19:11]
<oufmilo> > i believed there was a masto setting to rm all datas more old than <T> time
nope i don't think so
[15:19:58]
<isAAAc> oh ok :)
[15:20:09]
<oufmilo> yes but, i'm not running my instance with YunoHost
[15:21:03]
<oufmilo> you should think about putting your media on an s3 host like scaleway
[15:21:12]
<isAAAc> we are thinking about getting masto out of our ynh too, to a separate vm
[15:21:55]
<isAAAc> > you should think about putting your media on an s3 host like scaleway
yep or a minio @ work :)
[15:23:18]
<isAAAc> our masto as not many users,
i think we can delete datas more than 3 months
masto information is not designed to been kept online imho
[15:24:02]
<isAAAc> important information should be saved on an other service (like a bookmark app, or anyelse)
[15:24:29]
<isAAAc> <afk coffee>
[15:34:08]
<Charles P.> Mastodon cleaning commands clean data that no user have interacted with, no bookmark, no answer, etc. that can safely be cleaned, no need to keep foreign toots older than a month, no user have interacted with them in a month it safe to assume no one will interact with them in the future, especially because Mastodon timeline is highly dependent on time, you will never see something old on the timeline except for retoots
[15:45:36]
<tituspijean> > timeline is highly dependent on time
don't forget the lines too! 🙃
[15:50:26]
<grahamalamadingdong> > <@titus:pijean.ovh> grahamalamadingdong: welcome! what do you mean by "securely"?
> If ports for SMB and NFS are not opened in the router firewall, you should be safe from external threats.
>
> - After a (too?) quick glance at the default SMB configuration of the samba_ynh package, there might (I am no expert) be conditions were data transfer is not encrypted (it depends on the client). Check the clients ;)
> - I cannot answer on NFS
> - another option is a SSHFS mount
>
> Regarding which system user should perform the mount, or which groups should have access to it, it depends on what you want to do. If it's in a Nextcloud-like condition, I would give read and write access to the `multimedia` group. Note that any app belonging to it would have full access.
>
> Note that if you only need Nextcloud for storage access, you can directly set an external storage as SFTP or SMB/CIFS without setting up a system mount point.
Thanks for this! I guess by securely, I was wondering if I could prevent damage in the case of an attempted directory traversal attack. I’m a little out of my element here, but I had a vague notion that one protocol might be better than the other so that yunohost only has access to the folder I want it to have access to, and not the entire NAS
[15:57:11]
<isAAAc> > <afk coffee>
<back>
[15:57:44]
<isAAAc> > `bin/tootctl media remove-orphans` is running
still running
[17:48:25]
<isAAAc> ok , more than 60g deleted
[17:55:46]
<isAAAc> upgrade restarted, i'm lurking the logs to know how many space the backup will use
[18:51:06]
<isAAAc> The archive will contain about 129.7GB of data
[19:04:31]
<isAAAc> i'll cron the clean commands
[20:43:44]
<pti-jean> C'est possible de créer un sous domaine de moi.nohost.me comme edf.moi.nohost.me ?
[20:53:50]
<Aleks (he/him/il/lui)> oui
[20:56:11]
<pti-jean> ok 👍️
[21:10:56]
<pti-jean> Ça fait une erreur:
Code d’erreur : SEC_ERROR_UNKNOWN_ISSUER
[21:11:18]
<pti-jean> pas possible de valider la clé!
[21:11:47]
<pti-jean> L’autorité de délivrance du certificat du pair n’est pas reconnue.
[21:28:17]
<Aleks (he/him/il/lui)> on ne sais pas ce qu'est le "ça" qui "fait une erreur"
[21:29:39]
<pti-jean> Ça passe avec Chrome, mais pas avec Firefox!
[21:30:22]
<pti-jean> Pas Chrome, mais Chromium
[21:40:43]
<Salamandar> il faut que tu ailles dans ton interface d'admin yunohost, et que tu rajoutes un certificat à ton sous-domaine :)