`admin is not in the sudoers file`

Support
1

My YunoHost server

Hardware: VPS bought online
YunoHost version: 11.0.9.14 (stable)
I have access to my server : Through SSH, through the webadmin, and through hosting emergency console.
Are you in a special context or did you perform some particular tweaking on your YunoHost instance ? : no

Description of my issue

I’m moving Yunohost instance to another VPS hosting. Previously I’ve done it via creating backup archives and restoring them in the new place.

NB: full logs of Restore system from a backup archive: https://paste.yunohost.org/raw/inodiqojif. There are also few records for adjacent ops, including deletion of permissions for individual apps. Please, tell what of them could be useful.

The steps I took. Backup system part of existing Yunohost instance, created a fresh VPS Debian 11 instance, sftp get archives dir, ran install script, ran yunohost backup restore with backup name copied from list command, changed the port for SSH regarding hosting requirements, yunohost tools reboot, log in with admin, got admin is not in the sudoers file. This incident will be reported. And can’t get around it.

The problem. sudo, sudo su, su: all of them returns the aforementioned “not in sudoers” when ran from admin sshed.

PS Just noticed the difference between support category and discussions – sorry for x-posting.

2

Eeeeh okay … saw something similar on the forum so I’m starting to wonder there’s a hidden bug somewhere ?

Let’s look at the output of slapcat | grep admin | grep sudo

which should return :

dn: cn=admin,ou=sudo,dc=yunohost,dc=org
sudoUser: admin

Note that you need to be root for this, and you should be able to become root from any other account using su, entering root’s password (which should be admin’s user, though i’m not 100% sure because maybe restoring on a fresh system doesnt re-set root password to be admin’s password…)

3

Just saw the other post in which you explain that you cannot su … There may be a sort of “workaround” then, if you are able to connect to the webadmin : go in the Tools section and change the admin password, which should also change root’s password

4

Now su works! Still the error with sudoers though.

I guess it’s not what was expected.

# slapcat | grep admin | grep sudo
bash: slapcat: command not found
5

Eeeeeeeh wokay x_x

So uh let’s cheeeck … : systemctl | grep "slapd\|sudo"

and : dpkg --list | grep "slapd\|ldap"

6

Does this hosting use some non-standard Debian image? =((

# systemctl | grep "slapd\|sudo"
  slapd.service                                            loaded active running   LSB: OpenLDAP standalone server (Lightweight Directory Access Protocol)
  sudo-ldap.service                                        loaded active exited    LSB: Provide limited super user privileges to specific users
# dpkg --list | grep "slapd\|ldap"
ii  dovecot-ldap                          1:2.3.13+dfsg1-2+deb11u1                           amd64        secure POP3/IMAP server - LDAP support
ii  ldap-utils                            2.4.57+dfsg-3+deb11u1                              amd64        OpenLDAP utilities
ii  libdbd-ldap-perl                      0.20-1.1                                           all          Perl extension for LDAP access via an SQL/Perl DBI interface
ii  libldap-2.4-2:amd64                   2.4.57+dfsg-3+deb11u1                              amd64        OpenLDAP libraries
ii  libnet-ldap-perl                      1:0.6800+dfsg-1                                    all          client interface to LDAP servers
ii  libnss-ldapd:amd64                    0.9.11-1                                           amd64        NSS module for using LDAP as a naming service
ii  libpam-ldapd:amd64                    0.9.11-1                                           amd64        PAM module for using LDAP as an authentication service
ii  lua-ldap:amd64                        1.2.5-1+b1                                         amd64        LDAP library for the Lua language
ii  php7.4-ldap                           1:7.4.30-3+0~20220627.69+debian11~1.gbpf2b381      amd64        LDAP module for PHP
ii  postfix-ldap                          3.5.13-0+deb11u1                                   amd64        LDAP map support for Postfix
ii  python3-ldap:amd64                    3.2.0-4+b3                                         amd64        LDAP interface module for Python3
ii  slapd                                 2.4.57+dfsg-3+deb11u1                              amd64        OpenLDAP server (slapd)
ii  sudo-ldap                             1.9.5p2-3                                          amd64        Provide limited super user privileges to specific users
7

Hmnah, I’m thinking it’s just an artefact of su not having the proper PATH “as usual”

Anyway, let’s try :

/usr/sbin/slapcat | grep admin | grep sudo
8

here it go!

# /usr/sbin/slapcat | grep admin | grep sudo
dn: cn=admin,ou=sudo,dc=yunohost,dc=org
sudoUser: admin
1 Like
9

Soooo eeeh that sounds good I guess …

Naively, let’s try to randomly systemctl restart sudo-ldap, maybe that fixes the issue ? (Kinda random guess :/)

10

same error =(
(and, of course, I had reboot the server several times previously)

11

I have the same problem (same diagnosis), following buster migration. In my case, dpkg failed on a package (empty/faulty string on libaspell15) so I had to do some manual upgrade.
In that process, apt --fix-broken install and apt asked for replacement of some config file (“keep old or use new…”) and I may have given the wrong answer for ldap.

Is this a lead ?

12

So in my case, I was able to restore root password, thanks to the web-admin. And then diagonisis gave the solution :

[WARNING] Le fichier de configuration /etc/ldap/ldap.conf semble avoir été modifié manuellement.

So I just ran the provided commands with root acount, restarted slapd and sudo-ldap services, and it was solved.

yunohost tools regen-conf slapd --dry-run --with-diff
yunohost tools regen-conf slapd --force

Goog luck to you @petesim , I hope you find this useful!

13

Thank you, but unfortunately no. My migration was between VPSes, not Ynh versions.

It tells me everything is ok.

I like --dry-run part of it, so it worth to try anyway!

14

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.