My YunoHost server
Debian 11 Homeserver with local root access;
Versions: YunoHost 11.2.10.3, yunohost-admin:
repo: stable version: 11.2.4.1, moulinette: repo: stable
version: 11.2, ssowat: repo: stable version: 11.2
After accidentally running “dpkg-reconfigure slapd”(and canceling it) I can’t login to yunohost webinterface any more.
=> “wrong username or password”.
I fear there is no more any connection between slapd and yunohost.
Is it possible to reset only the ldap/sso configuration of my yunohost installation without restoring or resetting any app data?
There are data.mdb and lock.mdb in /var/backup/unknown-2.4.57+dfsg-3+deb11u1-20240322-194549.ldapdb
And I have a backup of /etc/ldap
Can I restore this?
If you do have local root access try sudo yunohost tools regen-conf slapd -f
1 Like
Try to run the diagnosis on cli
1 Like
sudo yunohost tools regen-conf slapd -f
[sudo] Passwort für *****:
Info: Der Vorgang’Systemkonfiguration neu generieren ‘slapd’’ konnte nicht abgeschlossen werden. Bitte teile das vollständige Protokoll dieser Operation mit dem Befehl ‘yunohost log share 20240326-145441-regen_conf-slapd’, um Hilfe zu erhalten
Fehler: error during LDAP search operation with: base=‘ou=domains,dc=yunohost,dc=org’, filter=‘virtualdomain=*’, attrs=[‘virtualdomain’] and exception {‘desc’: ‘No such object’, ‘matched’: ‘dc=yunohost,dc=org’}
$ sudo yunohost log share 20240326-145441-regen_conf-slapd
Warnung: For some reason, YunoHost was not able to anonymize the pasted data. Sorry about that. Be careful about sharing the link, as it may contain somewhat private infos like domain names or IP addresses. Error: error during LDAP search operation with: base=‘ou=domains,dc=yunohost,dc=org’, filter=‘virtualdomain=*’, attrs=[‘virtualdomain’] and exception {‘desc’: ‘No such object’, ‘matched’: ‘dc=yunohost,dc=org’}
Info: Das Protokoll ist nun via https://paste.yunohost.org/raw/kahogiqoga verfügbar
is ldap running?
systemctl status slapd.service
1 Like
Yes, slapd.service is running:
$ systemctl status slapd
● slapd.service - LSB: OpenLDAP standalone server (Lightweight Directory Access Protocol)
Loaded: loaded (/etc/init.d/slapd; generated)
Drop-In: /usr/lib/systemd/system/slapd.service.d
└─slapd-remain-after-exit.conf
/etc/systemd/system/slapd.service.d
└─ynh-override.conf
Active: active (running) since Tue 2024-03-26 23:36:26 CET; 4min 38s ago
Docs: man:systemd-sysv-generator(8)
Process: 2997 ExecStart=/etc/init.d/slapd start (code=exited, status=0/SUCCESS)
Tasks: 3 (limit: 57659)
Memory: 9.7M
CPU: 35ms
CGroup: /system.slice/slapd.service
└─3085 /usr/sbin/slapd -h "ldap://127.0.0.1:389/ ldaps:/// ldapi:///" -g openldap -u openldap -F /etc/ldap/slapd.d
Mar 26 23:36:26 <REMOVED> systemd[1]: Starting slapd.service - LSB: OpenLDAP standalone server (Lightweight Direct>
Mar 26 23:36:26 <REMOVED> slapd[3081]: @(#) $OpenLDAP: slapd 2.4.57+dfsg-3+deb11u1 (May 14 2022 18:32:57) $
Debian OpenLDAP Maintainers <pkg-openldap-devel@lists.alioth.debian>
Mar 26 23:36:26 <REMOVED> slapd[3085]: slapd starting
Mar 26 23:36:26 <REMOVED> slapd[2997]: Starting OpenLDAP: slapd.
Mar 26 23:36:26 <REMOVED> systemd[1]: Started slapd.service - LSB: OpenLDAP standalone server (Lightweight Directo>
Mar 26 23:37:40 <REMOVED> slapd[3085]: get_filter: conn 1004 unknown attribute type=sudoUser (17)
Mar 26 23:37:40 <REMOVED> slapd[3085]: get_ssa: conn 1004 unknown attribute type=sudoUser (17)
!!! I have changed my URL manually to <REMOVED> in this posting!
$ sudo yunohost user list
Error: error during LDAP search operation with:
base='ou=users,dc=yunohost,dc=org', filter='(&
(objectclass=person)(!(uid=root))(!(uid=nobody)))',
attrs={'uid', 'cn', 'mailuserquota', 'mail'} and exception
{'desc': 'No such object', 'matched': 'dc=yunohost,dc=org'}
How can I reset the ldap/sso user configuration of yunohost without loosing my app data. There are only a few users, so it is no problem to configure the users again. But I need admin-access again for login to yunohost.
yunohost diagnosis show --issues --human-readable
=> There are no sso/ldap-related warnings/issues.
I can’t believe that accidentally running “dpkg-reconfigure slapd” kills a yunohost Installation. Is it really not possible to reconfigure slapd so it will work with yunohost again? Is there really no other way than reinstalling yunohost and restoring the backup? Is it not possible to restore only the user configuration/ldap part from the backup? Or reconfigure the users with default settings? What are the ldap settings and where are they backuped?
I can’t believe that accidentally running “dpkg-reconfigure slapd” kills a yunohost Installation.
i doubt that anyone can do that by accident, I mean a real accident
anyway, here are some of the config files:
ldap config files
cat /etc/ldap/ldap.conf
#
# LDAP Defaults
#
# See ldap.conf(5) for details
# This file should be world readable but not world writable.
BASE dc=yunohost,dc=org
URI ldap://localhost:389
SIZELIMIT 10000
#TIMELIMIT 15
#DEREF never
# TLS certificates (needed for GnuTLS)
TLS_CACERT /etc/ssl/certs/ca-certificates.crt
sudoers_base ou=sudo,dc=yunohost,dc=org
cat /etc/ldap/ldap.conf.dpkg-dist
#
# LDAP Defaults
#
# See ldap.conf(5) for details
# This file should be world readable but not world writable.
#BASE dc=example,dc=com
#URI ldap://ldap.example.com ldap://ldap-provider.example.com:666
#SIZELIMIT 12
#TIMELIMIT 15
#DEREF never
# TLS certificates (needed for GnuTLS)
TLS_CACERT /etc/ssl/certs/ca-certificates.crt
do you have those files?
ls /etc/ldap/schema/
collective.ldif core.schema dyngroup.ldif java.schema nis.schema pmi.schema
collective.schema cosine.ldif dyngroup.schema mailserver.ldif openldap.ldif ppolicy.ldif
corba.ldif cosine.schema inetorgperson.ldif misc.ldif openldap.schema ppolicy.schema
corba.schema duaconf.ldif inetorgperson.schema misc.schema permission.ldif README
core.ldif duaconf.schema java.ldif nis.ldif pmi.ldif sudo.ldif
1 Like
Thank you for your hint. All files are here too, with same content as described.
Sometimes an accident is caused by stupidity… ;-(
I didn’t know that there is no way to break a started dpkg-reconfigure without destroying things.
You wrote you started the command then immediately cancelled it. Can you try letting it complete? (Most likely it won’t work, but who knows…)
1 Like
You are right, it did not even work after restarting “dpkg-reconfigure slapd” again and bringing it to an end.
I was asked for a password… what should I use?
I think the slapd/pam/sso-configuration is really complex and the most users of YUNOHOST didn’t understand the interrelations - like me. So if there is going something wrong with authorization there is no chance to repair it, without a deep understanding of ldap / PAM / SSO and what YUNOHOST does.
But If I would have this understanding - I wouldn’t need YUNOHOST.
Today I have recognized that login per ssh isn’t possible any more (login is only from localhost possible), so i think the problem is more a PAM, than a LDAP problem. But how does this interact - I don’t know.
yunohost user permission add ssh ralphgl
Error: error during LDAP search operation with: base='ou=permission,dc=yunohost,dc=org', filter='(objectclass=permissionYnh)', attrs=['cn', 'groupPermission', 'inheritPermission', 'URL', 'additionalUrls', 'authHeader', 'label', 'showTile', 'isProtected'] and exception {'desc': 'No such object', 'matched': 'dc=yunohost,dc=org'}
My insight from this YUNOHOST experience: Don’t use a system which is too complex for your understanding - so you can’t fix it.
1 Like
After searching for a solution of my problem, I found another YUNOHOST user with same problem and without a solution, see How to clean a messed up LDAP config
Trying repairing the broken state with yunohost cli always end with:
Error: error during LDAP search operation with: base=‘ou=domains,dc=yunohost,dc=org’, filter=‘virtualdomain=*’, attrs=[‘virtualdomain’] and exception {‘desc’: ‘No such object’, ‘matched’: ‘dc=yunohost,dc=org’}
Another insight: do backups. If you have one, now is the time to use it.
If you don’t, let’s try to reset LDAP. This is untested:
sudo su
source /usr/share/yunohost/hooks/conf_regen/06-slapd
# Should reset slapd
do_init_regen
#Here make sure ldap works again. If not try
yunohost tools regen-conf slapd -f
#Recreate your users now
#yunohost user create <user>
#Assign at least one to be admin
#yunohost user group add admins <user>
#Since ldap base is empty, let's regenerate the apps permissions by force-upgrading them
#Sorry for having you rebuild whole apps, there surely is a way to only update the permissions but this is faster to write
for a in $(yunohost app list --output-as json | jq -r '.apps[]|.id'
do
yunohost app upgrade $a --force
done
If it’s still failing, still report the errors you see here, but I am out of ideas.
3 Likes
Hi tituspijean,
thank you very much, for your help. With your hints, I could repair my yunohost installation, so I could login again.
Things I have done:
sudo su
/usr/share/yunohost/hooks/conf_regen/06-slapd init
yunohost user create <USERNAME>
yunohost domain list
#Some Domains must be added again, then I created letsencrypt certs for the domains.
/usr/share/yunohost/hooks/conf_regen/06-slapd init
yunohost user group add admins <USERNAME>
yunohost domain cert-install <DOMAINNAME>
# Some apps could be used after this, some doesn't work
yunohost app upgrade <APPNAME> --force
# Didn't work with error "failed to get label for app <APPNAME>"
# I could Upgrade some apps, some apps must be removed and installed again.
2 Likes
Glad to read you managed to fix it!
Thank you for the feedback. Out of curiosity, which apps were still failing?
For example I had to reinstall uptime-kuma - but the settings were gone. And removing the app again and installing my backup brought me the old problem back, that I couldn’t login at uptime-kuma. (Settings the rights to user is OK). I fear I have to set my monitoring again.
Better was the situation with grist, paperless-ngx, hedgedoc and glpi. The data are still there after getting access back.