Yunohost 11.1 spooky testing

Announcements
101

Hmf can you confirm that the postfix conf is up to date with yunohost tools regen-conf postfix --dry-run --with-diff

102

The first thing I did was a yunohost tools regen-conf --force, then I rebooted the server.

103

Hmyeah after investigating I see why this is happening : the legacy admin user is not really member of the all_users group and therefore doesnt have the “mail.mail” permission, yet it is still supposed to receive the mails sent to root@ (and other aliases) 
 but postfix complains that the user is unknown

I recommend the following solution:

  • ultimately the advice is to get rid of the legacy admin user, which implicitly fixes the issue
  • if you really do want to keep the admin user, it’s probably better to delete it and recreate it, just to make sure it’s really a regular user (the one we recreate during the 11.1 migration is only meant to be a tmp user just to allow people to still login using their “old” admin credentials to minimize confusion 
)
  • if neither of these satisfy you, you can also run yunohost user permission add mail.main admins, which will re-add the mail permission to the legacy admin, and then postfix will be happy about it
1 Like
104

Deleting the user admin solves the problem (according to my mind we shouldn’t have a superuser called admin for security reasons).

I just saw that :

# yunohost user list
users:
  admin:
    fullname: Admin
    mail: admin_legacy
    mailbox-quota: 0
    username: admin

Shouldn’t the mail be like admin@mydomain.tld?

105

Nope because that alias is meant to be an alias for the admins@ group (mainly for backward compatibility and typo stuff)

Would be glad to hear your detailed opinion on that 
 Naively my answer is “root already exists, why would having an additional ‘admin’ be better for security?”

106

Mmmmmmkay for the alias.

More naively©, why having a superuser called admin (which is probably the most tested user by attackers after root) when we can choose any user to be the admin (and iirc, for each app installed we choose a user to be the app admin, why not the same for the whole system after yunohost installation ?).

I suppose the choice of automatically create the user admin was made to avoid using root ?

Sorry if the question is stupid (or worse, already answered).

107

Hum I am on 11.1.0.2 (testing), what to do to go back to stable? :grinning:

108

Ah I misread your initial message and missed the “shouldn’t”, I though you meant we should /o. But yeah what you’re saying is pretty much the reason we’re doing this migration, new installs of YunoHost won’t have any “admin” at all, instead the very first user should be in the admins group, and other users created can be added to the admins group

I think historically admin was created because some sort of LDAP admin user was needed (but then we realize we could manipulate the LDAP db using the unix root). Though historically the “admins” group did existed, I think the intention was to somehow allow people to be added to that admins group, but was never implemented until now (80% of the worktime ends up being caught in “how do you handle the transition from existing installs”)

109

You do not, because there is no way to rollback the changes introduced in 11.1. The recommendation is to upgrade to 11.1.1 (testing) to fix the aliases issues and other bugs existing in 11.1.0, and 11.1.x will ultimately become stable at some point. (At least 11.1.1 is “more stable” than 11.1.0)

1 Like
110

11.1.1.2 according to the last apticron :stuck_out_tongue_winking_eye:

To go back to stable, maybe remove the “testing” /etc/apt/sources.list.d/yunohost.list after the update ?

111

Just a quick question before I remove the user admin:

  • when I ssh using user@server + sudo su = I enter my user password. Success!
  • when I ssh using user@server + su = I need to enter the root password, user password get me Authentication failure.

Is this the expected behaviour?

112

Yes, sudo asks for the user password, su asks for the root password

1 Like
113

Thank you, it worked.

114

I’m still unable to use my account to modify LDAP on the version this was included in.

115

Can you elaborate on what tool exactly you’re using and what you’re trying 


116

I’m using Apache Directory Studio and am using “uid=username,ou=users,dc=yunohost,dc=org” to authenticate.

117

Hello,
On a domain with a let’s encrypt certificat there is no possibility to go back to a self signed one.

Screenshot 2022-12-05 at 01-43-10 tube.xx _ Domaines YunoHost Admin
Screenshot 2022-12-05 at 01-43-10 tube.xx _ Domaines YunoHost Admin709×413 36.4 KB

118

Yes 
 do you really need this feature 


119

No, you’re right I don’t need it.
But I can’t have the box “Ignore diagnosis checks” in state ON/YES. There is nothing to validate this state and it didn’t ‘remember’ it.

120

Great! Can someone tell me when 11.1 will be stable (estimated)?