I got the update via admin web interface and I for sure didn’t switch to testing ever.
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 ???
hi, me too I don’t understand why I got this release in this server which should be stable ???
1 Like
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…
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
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 ??
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 …
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 …
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 ???
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.
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
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
@Aleks its fine, I get it. I just think I and others need a bit of reassurance which you have done. All cool
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:
- edit my apt yunohost.list to get upgrades from testing before edit again to stay on stable branch ?
- just wait the changes in a future stable upgrade ?
- 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)
- 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) ?
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 !!
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…
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
If you’re talking about logging on phpldapadmin or similar app/need, I need to publish a new micro-release for this, but after this this will be cn=admins,ou=groups,dc=yunohost,dc=org