Yunohost 11.1 spooky testing

Announcements
#56

Hi there.


yunohost:
  repo: testing
  version: 11.1.0.2
yunohost-admin:
  repo: testing
  version: 11.1.0.2
moulinette:
  repo: stable
  version: 11.0.9
ssowat:
  repo: stable
  version: 11.0.9

Updated yesterday, got issue when some bash script sends mail to root@mydomain.tld. Received this mail :

This is the mail system at host mydomain.tld.

I'm sorry to have to inform you that your message could not
be delivered to one or more recipients. It's attached below.

For further assistance, please send mail to postmaster.

If you do so, please include this problem report. You can
delete your own text from the attached returned message.

The mail system

<[admin@mydomain.tld](mailto:admin@mydomain.tld)> (expanded from <[root@mydomain.tld](mailto:root@mydomain.tld)>): user unknown

Reporting-MTA: dns; mydomain.tld
X-Postfix-Queue-ID: 942443862215
X-Postfix-Sender: rfc822; [root@mydomain.tld](mailto:root@mydomain.tld)
Arrival-Date: Fri, 4 Nov 2022 23:35:28 +0100 (CET)

Final-Recipient: rfc822; [admin@mydomain.tld](mailto:admin@mydomain.tld)
Original-Recipient: rfc822;[root@mydomain.tld](mailto:root@mydomain.tld)
Action: failed
Status: 5.1.1
Diagnostic-Code: x-unix; user unknown

[Original mail content]

Let’s check /var/log/mail.log :

Nov  5 00:08:35 mydomain postfix/pickup[2942463]: E9C8B386237F: uid=0 from=<root@mydomain.tld>
Nov  5 00:08:35 mydomain postsrsd[2961828]: srs_forward: <root@mydomain.tld> not rewritten: Domain excluded by policy
Nov  5 00:08:35 mydomain postfix/cleanup[2961824]: E9C8B386237F: message-id=<20221104230835.E9C8B386237F@mydomain.tld>
Nov  5 00:08:35 mydomain postfix/qmgr[2896068]: E9C8B386237F: from=<root@mydomain.tld>, size=529, nrcpt=3 (queue active)
Nov  5 00:08:36 mydomain postfix/pipe[2961830]: E9C8B386237F: to=<admin@mydomain.tld>, orig_to=<root@mydomain.tld>, relay=dovecot, delay=0.17, delays=0.12/0.01/0/0.04, dsn=5.1.1, status=bounced (user unknown)
Nov  5 00:08:36 mydomain dovecot: lda(someuserinadminsgroup@mydomain.tld)<2961835><fm7kAHSbZWOrMS0AUZszow>: sieve: msgid=<20221104230835.E9C8B386237F@mydomain.tld>: stored mail into mailbox 'INBOX'
Nov  5 00:08:36 mydomain postfix/pipe[2961833]: E9C8B386237F: to=<someuserinadminsgroup@mydomain.tld>, orig_to=<root@mydomain.tld>, relay=dovecot, delay=0.17, delays=0.12/0.02/0/0.03, dsn=2.0.0, status=sent (delivered via dovecot service)

Seems the system can’t find admin@mydomain.tld

Let’s have a look at the listed users :

root@mydomain:/home# yunohost user  list
users:
  admin:
    fullname: Admin
    mail: admin_legacy
    mailbox-quota: 0
    username: admin

  someuserinadminsgroup:
    fullname: xxx yyy
    mail: someuserinadminsgroup@mydomain.tld
    mailbox-quota: 0
    username: someuserinadminsgroup
	
[some regular users]

Is it normal to get admin_legacy mail instead of admin@mydomain.tld like the other users ?

Nota bene : the user someuserinadminsgroup@mydomain.tld which is in the group admins receives the two mails : the original one and the error one.

Here are the users in the admin & admins groups :

root@mydomain:~# getent group admin && getent group admins
admin:*:17762:someuserinadminsgroup
admins:*:4001:someuserinadminsgroup,admin
#57

I got the update via admin web interface and I for sure didn’t switch to testing ever.

#58

Hello, what’s the matter ?? I have a server for lot of users, I have verify before, the /etc/apt/sources.list.d/yunohost.list is edited with deb http://forge.yunohost.org/debian/ bullseye stable but this release has come and now I have this

# yunohost tools versions
yunohost: 
  repo: testing
  version: 11.1.0.2
yunohost-admin: 
  repo: testing
  version: 11.1.0.2
moulinette: 
  repo: stable
  version: 11.0.9
ssowat: 
  repo: stable
  version: 11.0.9

why ??
Ok, it is a nice job the new webadmin. I had to edit again the aliases for the principal admin user (webmaster postmaster, admin, root, abuse).

I am affraid having a testing branch in this server which is dedicated for few users and offer services … And don’t understand why the apt have decided do this !!

For another server with similar problem last week, I have restore a snapshot (from OVH) to get back to a stable branch… But in this server, I have backups (each night with Borg), but it I am affraid restoring all…

How can I stay to stable branch, even keeping these changes ?

Is it possible keep this upgrade from testing but stay now the stable branch, and how be sure to stay on this stable branch ???

#59

hi, me too I don’t understand why I got this release in this server which should be stable ???

1 Like
#60

It was a mistake, see Passage en "Testing" suite migration - #9 by yalh76

1 Like
#61

Ok, I have also problems with mails explain here: Passage en "Testing" suite migration - #20 by rodinux

What’s the better, do I have to make upgrade from testing to resolve these issues and back again to stable when a version 1.1 arrive ???
I stay in touch…

#62

Looking at slapcat | grep 'uid:\|cn=admins\|mail' | grep -C5 admin --color, we can see among other things:

dn: cn=admins,ou=groups,dc=yunohost,dc=org
objectClass: mailGroup
mail: root
mail: admin
mail: admins
mail: webmaster
mail: postmaster
mail: abuse

Which I thought would be enough for all mails sent to admin@ (and other adresses) to be dispatched to members of the admin group, but looking at other similar entries, I see that in fact the full email adress should be specified (so eg admin@domain.tld instead of just admin)

It’s a bit annoying because that makes that config bit dependent on the domain instead of catching all admin@* mails. I’m wondering if maybe we should switch to an alias regex somewhere in postfix’s conf instead …

1 Like
Bug de mise à jour DynDns?
#63

Ok, I don’t understand all, but as my first user1 (admin also) have also aliases I have this

slapcat | grep 'uid:\|cn=admins\|mail' | grep -C5 admin --color

objectClass: mailDomain
structuralObjectClass: mailDomain
objectClass: mailAccount
uid: user1
maildrop: user1
memberOf: cn=admins,ou=groups,dc=yunohost,dc=org
permission: cn=mail.main,ou=permission,dc=yunohost,dc=org
mailuserquota: 3000M
mail: user1@domaine.tld
mail: contact@domaine.tld
mail: dpo@domaine.tld
mail: root@domaine.tld
mail: admin@domaine.tld
mail: abuse@domaine.tld
mail: webmaster@domaine.tld
mail: postmaster@domaine.tld
objectClass: mailDomain
structuralObjectClass: mailDomain
--
structuralObjectClass: mailDomain
objectClass: mailDomain
structuralObjectClass: mailDomain
objectClass: mailDomain
structuralObjectClass: mailDomain
dn: cn=admins,ou=sudo,dc=yunohost,dc=org
dn: cn=admins,ou=groups,dc=yunohost,dc=org
objectClass: mailGroup
mail: root
mail: admin
mail: admins
mail: webmaster
mail: postmaster
mail: abuse
objectClass: mailAccount
uid: admin
mail: admin_legacy
maildrop: admin
mailuserquota: 0
memberOf: cn=admins,ou=groups,dc=yunohost,dc=org

Is it better for me to remove the alisases in user1 ?? or I can let them ??

#64

Well, I guess for now you need those if you want these email address to work, but soon™ they should be handled by the core and that will conflict …

#65

Hi, so is it a good way to edit the /etc/apt/sources.list.d/yunohost.list then add testing, do an upgrade with to have resolved issues about this, and then come back to only stable ? and when ??
Where is the branch that take care about these changes ? here GitHub - YunoHost/yunohost-admin: Web administration interface for YunoHost ?

Is it a good idea to remove the user admin later and keep only the users admins to receive messages from root admin postmaster webmaster etc …

#66

I don’t know what I need to do… If I edit my /etc/apt/sources.list.d/yunohost.list adding testing, I have this

sudo yunohost tools update
Info: Fetching available upgrades for system packages...
Info: Updating application catalog...
Success! The application catalog has been updated!
apps: 
important_yunohost_upgrade: False
pending_migrations: 
system: 
  0: 
    current_version: 11.0.9
    name: moulinette
    new_version: 11.1.0
  1: 
    current_version: 3.7.0+ynh11-1
    name: python3-lexicon
    new_version: 3.11.2+ynh11-1
  2: 
    current_version: 11.0.9
    name: ssowat
    new_version: 11.1.0

I am not sure I have to these upgrades if I want to stay on stable branch for this server in production with lot of users…

What the better thing to do ???

#67

Problem with smtp relay host in postfix config

After I unintentionally updated to 11.1.0.2 (testing), in “/etc/postfix/main.cf” the entry “relayhost = [smtp.my-relay.host]:587” was overwritten with “relayhost = []:”. It seems that when generating the configuration hostname and port were empty although they are configured in Yunohost.

#68

I too did this upgrade and was surprised it was a testing branch. I too got all the undeliverable emails. I too had the admin_legacy user.

I did a full backup and deleted the admin_legacy user. The emails stopped, of course, I was not able to log into the WebGUI with admin and the usual password. I was able to log in with the first created user from the first time of installation of YNH. SSH worked, and root works, in fact, everything is working fine, so far I think… Mail is going in and out, my 3 Nextcloud instances work, 4 website work, and I can install and uninstall apps. So far so good. The only app that wouldn’t work was Webmin. No credentials would work. No loss though really. I have a CRON job that backs up mail and users’ home every night, and that still works I still get the email from CRON with the status of the backup, which is root anyway.

What is worrying me is that when the stable version gets released, will I need the admin_legacy user, or is the plan to do away with this user?

On the new version updates, I switched on the tar.gz but had to turn it off as restoring didn’t work. I can’t find the logs of this to share. I tried restoring Snappymail, only 94meg, but three hours later it was still trying to restore. I had to reboot and restore from the non .tar.gz backup, which was ok.

Dj

#69

As stated in the release note :

Replace the ‘admin’ user

We recommend to get rid of the legacy ‘admin’ user once you validate that this is okay for you!

And of course, if you delete it … you can’t login with the admin user anymore … since you deleted it … that’s the point

I get that this will generate confusion because people got sort of used to the admin user, but on the long term the intention is to reduce the confusion that was caused by this technical user which was neither root nor a regular yunohost user

#70

@Aleks its fine, I get it. I just think I and others need a bit of reassurance which you have done. All cool

#71

Hi,

Please, what can we do with this unexpected upgrade ? If we want stay on stable branch ?? tell us what we need do ?

Do I need:

  1. edit my apt yunohost.list to get upgrades from testing before edit again to stay on stable branch ?
  2. just wait the changes in a future stable upgrade ?
  3. remove the admin user ? (I can connect now with my first user on webadmin and in ssh, but after have create a folder .ssh and edit authorized_keys with public key)
  4. keep my aliases for the first user like admin, root, postmaster, webmaster, abuse ? or remove them if they will be included in the core (for admins I imagine) ?
#72

Oups, what’s this ???
So I have remove the admin user.
My first user1 is available to connect on ssh and webadmin
I have also remove alias admin root postmaster webmaster abuse for this user1.

But now Looking at slapcat | grep 'uid:\|cn=admins\|mail' | grep -C5 admin --color, I see lot of things !! Why ???

objectClass: mailDomain
structuralObjectClass: mailDomain
objectClass: mailAccount
uid: user1
maildrop: user1
memberOf: cn=admins,ou=groups,dc=yunohost,dc=org
permission: cn=mail.main,ou=permission,dc=yunohost,dc=org
mailuserquota: 3000M
mail: user1@domain.tld
mail: contact@domain.tld
mail: dpo@domain.tld
--
maildrop: user2
permission: cn=mail.main,ou=permission,dc=yunohost,dc=org
mailuserquota: 3000M
objectClass: mailDomain
structuralObjectClass: mailDomain
groupPermission: cn=admins,ou=groups,dc=yunohost,dc=org
groupPermission: cn=admins,ou=groups,dc=yunohost,dc=org
objectClass: mailAccount
uid: user4
mail: user4@domain.tld
maildrop: user4
permission: cn=mail.main,ou=permission,dc=yunohost,dc=org
--
objectClass: mailDomain
virtualdomain: webmail.domain.tld
structuralObjectClass: mailDomain
objectClass: mailDomain
structuralObjectClass: mailDomain
groupPermission: cn=admins,ou=groups,dc=yunohost,dc=org
objectClass: mailDomain
structuralObjectClass: mailDomain
objectClass: mailAccount
uid: mobilizon_notifs
mailuserquota: 0
--
mailuserquota: 3000M
objectClass: mailDomain
structuralObjectClass: mailDomain
objectClass: mailDomain
structuralObjectClass: mailDomain
groupPermission: cn=admins,ou=groups,dc=yunohost,dc=org
objectClass: mailDomain
structuralObjectClass: mailDomain
groupPermission: cn=admins,ou=groups,dc=yunohost,dc=org
objectClass: mailDomain
structuralObjectClass: mailDomain
dn: cn=admins,ou=sudo,dc=yunohost,dc=org
dn: cn=admins,ou=groups,dc=yunohost,dc=org
objectClass: mailGroup
mail: root
mail: admin
mail: admins
mail: webmaster
mail: postmaster
mail: abuse
objectClass: mailDomain
structuralObjectClass: mailDomain
groupPermission: cn=admins,ou=groups,dc=yunohost,dc=org
objectClass: mailAccount
uid: user3
mail: user3@domain.tld
maildrop: user3
permission: cn=mail.main,ou=permission,dc=yunohost,dc=org
root@linux07:~# slapcat | grep 'uid:\|cn=admins\|mail' | grep -C5 admin --color
objectClass: mailDomain
structuralObjectClass: mailDomain
objectClass: mailAccount
uid: user1
maildrop: user1
memberOf: cn=admins,ou=groups,dc=yunohost,dc=org
permission: cn=mail.main,ou=permission,dc=yunohost,dc=org
mailuserquota: 3000M
mail: user1@domain.tld
mail: contact@domain.tld
mail: dpo@domain.tld
--
maildrop: user2
permission: cn=mail.main,ou=permission,dc=yunohost,dc=org
mailuserquota: 3000M
objectClass: mailDomain
structuralObjectClass: mailDomain
groupPermission: cn=admins,ou=groups,dc=yunohost,dc=org
groupPermission: cn=admins,ou=groups,dc=yunohost,dc=org
objectClass: mailAccount
uid: user4
mail: user4@domain.tld
maildrop: user4
permission: cn=mail.main,ou=permission,dc=yunohost,dc=org
--
objectClass: mailDomain
virtualdomain: webmail.domain.tld
structuralObjectClass: mailDomain
objectClass: mailDomain
structuralObjectClass: mailDomain
groupPermission: cn=admins,ou=groups,dc=yunohost,dc=org
objectClass: mailDomain
structuralObjectClass: mailDomain
objectClass: mailAccount
uid: mobilizon_notifs
mailuserquota: 0
--
mailuserquota: 3000M
objectClass: mailDomain
structuralObjectClass: mailDomain
objectClass: mailDomain
structuralObjectClass: mailDomain
groupPermission: cn=admins,ou=groups,dc=yunohost,dc=org
objectClass: mailDomain
structuralObjectClass: mailDomain
groupPermission: cn=admins,ou=groups,dc=yunohost,dc=org
objectClass: mailDomain
structuralObjectClass: mailDomain
dn: cn=admins,ou=sudo,dc=yunohost,dc=org
dn: cn=admins,ou=groups,dc=yunohost,dc=org
objectClass: mailGroup
mail: root
mail: admin
mail: admins
mail: webmaster
mail: postmaster
mail: abuse
objectClass: mailDomain
structuralObjectClass: mailDomain
groupPermission: cn=admins,ou=groups,dc=yunohost,dc=org
objectClass: mailAccount
uid: user3
mail: user3@domain.tld
maildrop: user3
permission: cn=mail.main,ou=permission,dc=yunohost,dc=org

Can’t understand !!

#73

Hello,
Somethings to ask for: I used before to hide the webadmin page yunohost settings set security.webadmin.allowlist -v <IP_ADDRESS> and yunohost settings set security.webadmin.allowlist.enabled -v True, but it seems doesn’t works anymore…

#74

Having a big issue with LDAP, what’s the bind info for admin access? Even being in the admin group doesn’t grant my user ldap admin

2 Likes
#75

Hello! I have the same useful question