[09:58:41]
<hook> Is `unattended_updates` save (and smart) to enable?
[10:16:33]
<Salamandar> > <hook> Is `unattended_updates` save (and smart) to enable?
welp I installed it on multiple servers and until now i'm not even sure it does its job because I only enabled "security updates", not all of them
[10:16:40]
<Salamandar> (except when the kernel is destroying your ext4 filesystems because they didn't even care to read the test report…)
[10:17:01]
<Salamandar> If you want to install the unattended_upgrade package, and if you're willing to test "beta quality" code, I'd love to have some feedback on my packaging v2 port of the package:
https://github.com/YunoHost-Apps/unattended_upgrades_ynh/pull/23
[10:17:33]
<Salamandar> But, without speaking of the yunohost package: YES, unattended_updates is a sane thing to install on your server.
[10:18:07]
<hook> Salamandar, I’m in general fine with testing beta stuff, but I only have this one server, so if it messes up the system (instead of just an app), that’d be pretty painful.
[10:30:49]
<Salamandar> hmm
[10:30:49]
<Salamandar> actually let me install it on my server first
[10:30:49]
<Salamandar> it shouldn't delete anything from your system :D
[10:33:13]
<hook> That’s somewhat reassuring :D
[10:37:45]
<Salamandar> https://github.com/YunoHost-Apps/unattended_upgrades_ynh/blob/9380b6ebe0127f1badc5e1c1e60f2a966a855e0f/scripts/install
[10:37:45]
<Salamandar> If you're not feeling safe, you just have to read the scripts ;)
[10:37:45]
<Salamandar> welp it looks okay on my side
[10:53:08]
<hook> Salamandar, I’ll check it out and might try, yes. Will provide feedback to the PR if I do
[10:53:27]
<Salamandar> <3
[11:00:26]
<hook> Salamandar, any difference if I directly install the testing version, or if I first install the stable version and update to testing?
[11:00:46]
<Salamandar> nah it should be the same
[11:01:09]
<hook> And when I’m done, simply uninstall and install stable?
[11:01:44]
<Salamandar> because in the end install and upgrade scripts both call the same code
[11:01:56]
<Salamandar> > <hook> And when I’m done, simply uninstall and install stable?
you will be able to upgrade from testing to stable when I merge into stable
[11:02:04]
<hook> Perfect
[11:02:51]
<Salamandar> but to be honest I think the current testing branch will be merged soon as is, so it will be strictly the same code as stable
[11:03:08]
<hook> “Install Yunohost packages automatically” is for apps or for system packages?
[11:06:20]
<hook> Install went fine.
[11:07:09]
<hook> Three warnings for Packagers, but that’s all
[11:11:30]
<hook> Salamandar, anything specific you’d like me to try out?
[11:12:10]
<Salamandar> > <hook> Three warnings for Packagers, but that’s all
ho which are those ?
[11:12:32]
<Salamandar> > <hook> Salamandar, anything specific you’d like me to try out?
No not really. I mean if you enabled emails but never receive them that might be something worth pinging me for :D
[11:14:06]
<hook> > > <hook> Three warnings for Packagers, but that’s all
>
> ho which are those ?
WARNING Packagers: options upgrade_level has 'choices' but has type 'string', use 'select' instead to remove this warning.
[11:14:23]
<hook> Same for `unattended_mail` and `unattended_verbosity` options.
[11:28:26]
<Salamandar> oh hum
[11:28:26]
<Salamandar> thanks
[11:31:20]
<Salamandar> > <hook> Same for `unattended_mail` and `unattended_verbosity` options.
You shouldn't have warnings for those, only for upgrade_level_though o.o
[11:32:33]
<hook> 🤷♂️
[11:50:46]
<hook> What IP(s) should I put into Nextcloud WOPI settings to run Colabora safely?
https://docs.nextcloud.com/server/latest/admin_manual/office/configuration.html#wopi-settings
[11:51:40]
<hook> …or is it safe enough to just rely on the `<post_allow>` settings in `/ect/coolswd/coolwsd.xml`?
[12:13:36]
<hook> Salamandar, some UX feedback on the `unattended_updates` app:
It is surprising/confusing that the admin gets asked through (WebG|T)UI `yunohost/admin/#/apps/install/unattended_upgrades` some questions on what to update, how to be notified, etc; but then specifically those settings are missing from the admin interface `yunohost/admin/#/apps/unattended_upgrades/main`
[12:13:59]
<hook> I would expect to find those settings also in the admin interface.
[12:15:28]
<Salamandar> hah agreed
[12:16:08]
<Salamandar> (tbh I only upgraded the app, I did not change its behaviour… but I note your remarks, I'd like to take the time and implement those changes)
[12:18:52]
<hook> Salamandar, awesome, thanks :)
[12:37:42]
<clawfire> > <@Alekswag:matrix.org> yeah that's not the culprit
Do you think reinstalling YNH could help? Or should I do like clean install and move apps ?
[12:39:01]
<Aleks (he/him/il/lui)> ¯\_(ツ)_/¯
[12:49:08]
<Chatpitaine Caverne> Hello, I have a question, if I choose to save system parts in separate backup like the backup command line allow.
What is the correct order to restore it ?
[13:28:25]
<clawfire> > <@Alekswag:matrix.org> ¯\_(ツ)_/¯
to reintall YNH and the SSO part, should I just reinstall the YNH package or take a closer look at what's the sh script is doing in terms of magic ?
[13:30:16]
<Aleks (he/him/il/lui)> reinstalling the debian packages can just be achieved using `apt install yunohost ssowat --reinstall` but i absolutely doubt that this fixes anything ... however maybe completely reinstalling the entire machine may change something mysterious somewhere ..
[13:31:20]
<clawfire> yes, but since it's ± in prod I will probably set up a new machine, move all the apps using app backup from actual server then restore on the new one. I'm just concerned about how to achieve this since I want to use the same domain name 😁
[13:35:47]
<clawfire> Found some warning when reinstalling:
```
Regenerating configuration, this might take a while...
Warning: The configuration file '/etc/ldap/slapd.ldif' has been manually modified and will not be updated
Success! Configuration updated for 'dnsmasq'
Warning: configuration error - unknown item 'NONEXISTENT' (notify administrator)
Warning: configuration error - unknown item 'PREVENT_NO_AUTH' (notify administrator)
Warning: configuration error - unknown item 'NONEXISTENT' (notify administrator)
Warning: configuration error - unknown item 'PREVENT_NO_AUTH' (notify administrator)
```
[13:36:12]
<Aleks (he/him/il/lui)> wtf
[13:38:55]
<clawfire> The `/etc/ldap/slapd.ldif` is
```
# OpenLDAP server configuration for Yunohost
# ------------------------------------------
#
# Because of the Yunohost's regen-conf mechanism, it is NOT POSSIBLE to
# edit the config database using an LDAP request.
#
# If you wish to edit the config database, you should edit THIS file
# and update the config database based on this file.
#
# Config database customization:
# 1. Edit this file as you want.
# 2. Apply your modifications. For this just run this following command in a shell:
# $ /usr/share/yunohost/hooks/conf_regen/06-slapd apply_config
#
# Note that if you customize this file, YunoHost's regen-conf will NOT
# overwrite this file. But that also means that you should be careful about
# upgrades, because they may ship important/necessary changes to this
# configuration that you will have to propagate yourself.
#
# Main configuration
#
dn: cn=config
objectClass: olcGlobal
cn: config
olcConfigFile: /etc/ldap/slapd.conf
olcConfigDir: /etc/ldap/slapd.d/
# List of arguments that were passed to the server
olcArgsFile: /var/run/slapd/slapd.args
#
olcAttributeOptions: lang-
olcAuthzPolicy: none
olcConcurrency: 0
olcConnMaxPending: 100
olcConnMaxPendingAuth: 1000
olcIdleTimeout: 0
olcIndexSubstrIfMaxLen: 4
olcIndexSubstrIfMinLen: 2
olcIndexSubstrAnyLen: 4
olcIndexSubstrAnyStep: 2
olcIndexIntLen: 4
olcListenerThreads: 1
olcLocalSSF: 71
# Read slapd.conf(5) for possible values
olcLogLevel: None
# Where the pid file is put. The init.d script
# will not stop the server if you change this.
olcPidFile: /var/run/slapd/slapd.pid
olcReverseLookup: FALSE
olcThreads: 16
# TLS Support
olcTLSCertificateFile: /etc/yunohost/certs/yunohost.org/crt.pem
olcTLSCertificateKeyFile: /etc/yunohost/certs/yunohost.org/key.pem
olcTLSVerifyClient: never
olcTLSProtocolMin: 0.0
# The tool-threads parameter sets the actual amount of cpu's that is used
# for indexing.
olcToolThreads: 1
structuralObjectClass: olcGlobal
#
# Schema and objectClass definitions
#
dn: cn=schema,cn=config
objectClass: olcSchemaConfig
cn: schema
include: file:///etc/ldap/schema/core.ldif
include: file:///etc/ldap/schema/cosine.ldif
include: file:///etc/ldap/schema/nis.ldif
include: file:///etc/ldap/schema/inetorgperson.ldif
include: file:///etc/ldap/schema/mailserver.ldif
include: file:///etc/ldap/schema/sudo.ldif
include: file:///etc/ldap/schema/permission.ldif
#
# Module management
#
dn: cn=module{0},cn=config
objectClass: olcModuleList
cn: module{0}
# Where the dynamically loaded modules are stored
olcModulePath: /usr/lib/ldap
olcModuleLoad: {0}back_mdb
olcModuleLoad: {1}memberof
structuralObjectClass: olcModuleList
#
# Frontend database
#
dn: olcDatabase={-1}frontend,cn=config
objectClass: olcDatabaseConfig
objectClass: olcFrontendConfig
olcDatabase: {-1}frontend
olcAddContentAcl: FALSE
olcLastMod: TRUE
olcSchemaDN: cn=Subschema
# Hashes to be used in generation of user passwords
olcPasswordHash: {SSHA}
structuralObjectClass: olcDatabaseConfig
#
# Config database Configuration (#0)
#
dn: olcDatabase={0}config,cn=config
objectClass: olcDatabaseConfig
olcDatabase: {0}config
# Give access to root user.
# This give the possiblity to the admin to customize the LDAP configuration
olcAccess: {0}to * by * none
olcAddContentAcl: TRUE
olcLastMod: TRUE
olcRootDN: cn=config
structuralObjectClass: olcDatabaseConfig
#
# Main database Configuration (#1)
#
dn: olcDatabase={1}mdb,cn=config
objectClass: olcDatabaseConfig
objectClass: olcMdbConfig
olcDatabase: {1}mdb
# The base of your directory in database #1
olcSuffix: dc=yunohost,dc=org
#
# The userPassword by default can be changed
# by the entry owning it if they are authenticated.
# Others should not be able to see it, except the
# admin entry below
# These access lines apply to database #1 only
olcAccess: {0}to attrs=userPassword,shadowLastChange
by dn.base="cn=admin,dc=yunohost,dc=org" write
by dn.base="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth" write
by anonymous auth
by self write
by * none
#
# Personnal information can be changed by the entry
# owning it if they are authenticated.
# Others should be able to see it.
olcAccess: {1}to attrs=cn,gecos,givenName,mail,maildrop,displayName,sn
by dn.base="cn=admin,dc=yunohost,dc=org" write
by dn.base="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth" write
by self write
by * read
#
# Ensure read access to the base for things like
# supportedSASLMechanisms. Without this you may
# have problems with SASL not knowing what
# mechanisms are available and the like.
# Note that this is covered by the 'access to *'
# ACL below too but if you change that as people
# are wont to do you'll still need this if you
# want SASL (and possible other things) to work
# happily.
olcAccess: {2}to dn.base=""
by * read
#
# The admin dn has full write access, everyone else
# can read everything.
olcAccess: {3}to *
by dn.base="cn=admin,dc=yunohost,dc=org" write
by dn.base="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth" write
by group/groupOfNames/member.exact="cn=admin,ou=groups,dc=yunohost,dc=org" write
by * read
#
olcAddContentAcl: FALSE
# Save the time that the entry gets modified, for database #1
olcLastMod: TRUE
# Where the database file are physically stored for database #1
olcDbDirectory: /var/lib/ldap
# Checkpoint the BerkeleyDB database periodically in case of system
# failure and to speed slapd shutdown.
olcDbCheckpoint: 512 30
olcDbNoSync: FALSE
# Indexing options for database #1
olcDbIndex: objectClass eq
olcDbIndex: entryUUID eq
olcDbIndex: entryCSN eq
olcDbIndex: cn eq
olcDbIndex: uid eq,sub
olcDbIndex: uidNumber eq
olcDbIndex: gidNumber eq
olcDbIndex: sudoUser eq,sub
olcDbIndex: member eq
olcDbIndex: mail eq
olcDbIndex: memberUid eq
olcDbIndex: uniqueMember eq
olcDbIndex: virtualdomain eq
olcDbIndex: permission eq
olcDbMaxSize: 10485760
structuralObjectClass: olcMdbConfig
#
# Configure Memberof Overlay (used for Yunohost permission)
#
# Link user <-> group
dn: olcOverlay={0}memberof,olcDatabase={1}mdb,cn=config
objectClass: olcOverlayConfig
objectClass: olcMemberOf
olcOverlay: {0}memberof
olcMemberOfDangling: error
olcMemberOfDanglingError: constraintViolation
olcMemberOfRefInt: TRUE
olcMemberOfGroupOC: groupOfNamesYnh
olcMemberOfMemberAD: member
olcMemberOfMemberOfAD: memberOf
structuralObjectClass: olcMemberOf
# Link permission <-> groupes
dn: olcOverlay={1}memberof,olcDatabase={1}mdb,cn=config
objectClass: olcOverlayConfig
objectClass: olcMemberOf
olcOverlay: {1}memberof
olcMemberOfDangling: error
olcMemberOfDanglingError: constraintViolation
olcMemberOfRefInt: TRUE
olcMemberOfGroupOC: permissionYnh
olcMemberOfMemberAD: groupPermission
olcMemberOfMemberOfAD: permission
structuralObjectClass: olcMemberOf
# Link permission <-> user
dn: olcOverlay={2}memberof,olcDatabase={1}mdb,cn=config
objectClass: olcOverlayConfig
objectClass: olcMemberOf
olcOverlay: {2}memberof
olcMemberOfDangling: error
olcMemberOfDanglingError: constraintViolation
olcMemberOfRefInt: TRUE
olcMemberOfGroupOC: permissionYnh
olcMemberOfMemberAD: inheritPermission
olcMemberOfMemberOfAD: permission
structuralObjectClass: olcMemberOf
```
[13:38:56]
<clawfire> But seems more a dnsmasq issue
[14:35:22]
<nightbronze> I would only like to use its reverse-proxy, mail server, yuno-redirect and the firewall
[14:35:22]
<nightbronze> Could yunohost only work in a docker container?
[14:40:27]
<Aleks (he/him/il/lui)> sure just try to install it in docker
[14:41:19]
<nightbronze> I found a docker image of yunohost but it is not up to date https://hub.docker.com/r/domainelibre/yunohost
[14:42:37]
<nightbronze> Will yunohost SSO work with docker containers added using yuno-redirect?
[14:45:37]
<nightbronze> > <@Alekswag:matrix.org> sure just try to install it in docker
If I install yunohost on a Debian 11 docker I might not be able to update it to Debian 12 when the time comes. Because the containers reset after reboot
[14:45:38]
<Aleks (he/him/il/lui)> you do realize we know who you are, don't you ?
[14:45:47]
<nightbronze> > <@Alekswag:matrix.org> you do realize we know who you are, don't you ?
How so ?
[14:45:47]
<Aleks (he/him/il/lui)> 💤
[15:27:22]
<clawfire> > <@Alekswag:matrix.org> wtf
From what I found on internet, seems to be an issue when assigning groups to users :/
[15:36:17]
<clawfire> Any recommended hosting ? Since I'm gonna try moving all apps ?
[17:18:32]
<Salamandar> > <@nightbronze:matrix.org> Could yunohost only work in a docker container?
Hi, tl;dr yunohost uses systemd as a service handler, and docker decided to not support it, so no
[17:19:10]
<Aleks (he/him/il/lui)> Some people succeeded tho, dont get discouraged
[17:19:11]
<tufek> hi everyone, when failing to enter sudo or root password an email is automatically sent to admin, which is very neat feature! I just wonder how it works and where is located the script to learn about it.
[17:19:20]
<Aleks (he/him/il/lui)> That's regular debian (though in yunohost root email is an alias to the admins group)
[17:19:38]
<clawfire> Can I change the "main" domain used by YNH afterward? If I use a nohost.me for now and then, once all app moved, change the domain to use the already in use one ?
[17:20:36]
<nightbronze> > <@Salamandar:matrix.org> Hi, tl;dr yunohost uses systemd as a service handler, and docker decided to not support it, so no
I will install it in an LXC container then
[17:22:53]
<tufek> > <@clawfire:matrix.org> Can I change the "main" domain used by YNH afterward? If I use a nohost.me for now and then, once all app moved, change the domain to use the already in use one ?
yep, I think `sudo yunohost domain main-domain -n your.new.domain` should do the trick
[17:49:28]
<clawfire> Ok so now I have my 2 servers running ynh. I should just make a new backup of each app I want to move and upload them on the new server
[17:50:35]
<clawfire> and that's it ?
[18:01:21]
<clawfire> OH! Aleks (he/him/il/lui) guess which version of debian is running on the server -_-
[18:05:44]
<Aleks (he/him/il/lui)> 😬
[18:06:26]
<clawfire> Debian **12** !!! WTF >.<
[18:06:54]
<Aleks (he/him/il/lui)> how dare they
[18:07:36]
<clawfire> It smell the "would you like to upgrade your distro" button being clicked in the Gandi VPS panel -_-
[18:09:03]
<clawfire> Anyway so ... I'm not going through a system downgrade, I'll just backup apps and move to Debian **11** server
[18:12:22]
<tonton> hmm, so I installed vaultwarden, and it told me to run some commands for the admin token, so I did and entered it in the web admin. I saw the token already there didn't have the $argon2... part so I entered only the last part of what was generated from the argon command. Now I can't authorize as admin and I don't understand how to reset the admin token to something that works... I can see the token in my /etc/yunohost/apps/vaultwarden/settings.yml but I can't authorize as admin with it...
[19:29:22]
<clawfire> Hummm. Backup restoration doesn't goes well :/ https://paste.yunohost.org/raw/usasokujaj
[19:30:52]
<clawfire> Ok it seems it's "just" one of them. Just the one that is the most important 😂
[21:32:01]
<clawfire> Is it possible to abort a backup process started from the webmin ?
[22:04:55]
<Aleks (he/him/il/lui)> not really
[22:24:57]
<clawfire> okay so, I have an issue restauring one app: dolibarr. Seems the restore script fails at some point
[22:26:17]
<clawfire> Log is here https://paste.yunohost.org/raw/ocuqeqebab
The error is
```
2024-01-13 22:22:54,560: WARNING - /usr/share/yunohost/helpers.d/php: line 203: $phpfpm_path: ambiguous redirect
```
[22:31:38]
<Aleks (he/him/il/lui)> aaaaaaaaand
[22:31:59]
<Aleks (he/him/il/lui)> i have the honor to announce that it's probably because your archive contain spaces
[22:38:38]
<clawfire> in the name ?
[22:38:38]
<clawfire> I can rename the folder name if it's just that :p
[22:39:01]
<clawfire> it will solve the issue isn't it ?
[22:39:58]
<Aleks (he/him/il/lui)> what folder name, isn't your backup archive a .tar.gz ?
[22:58:29]
<clawfire> it's a .tar.gz but when uploaded on the server it's been uncompress into a json and a tar
[22:58:30]
<clawfire> both with spaces in the name
[23:26:31]
<clawfire> ok that's weird. The backup of my mastodon app is 16 Go. While i've purged all the old media in cache and the usage is about 60Mo locally. How it can take so much then ?
[23:35:22]
<Aleks (he/him/il/lui)> ¯\_(ツ)_/¯
[23:37:48]
<clawfire> ok nevermind. The tootctl says it removed cache but there's still like 10 Go on disk
[23:38:28]
<clawfire> Backup is working properly