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 …
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:
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
Hello! I have the same useful question
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
I found some errors in the italian translation for admin web interface.
This is a screenshot as example:
Translations are managed on translate.yunohost.org, if you’re able to connect / create an account, you can send some corrections that will be included in the next upgrade
CLI management of the YunoHost settings is broken:
$ yunohost settings list
admin_strength: 1
backup_compress_tar_archives: False
nginx_compatibility: intermediate
nginx_redirect_to_https: 0
pop3_enabled: False
postfix_compatibility: intermediate
root_access_explain: None
root_password:
root_password_confirm:
security_experimental_enabled: False
smtp_allow_ipv6: True
smtp_relay_enabled: False
smtp_relay_host:
smtp_relay_password:
smtp_relay_port: 587
smtp_relay_user:
ssh_compatibility: modern
ssh_password_authentication: True
ssh_port: 22
ssowat_panel_overlay_enabled: False
user_strength: 1
webadmin_allowlist:
webadmin_allowlist_enabled: False
$ yunohost settings set nginx_redirect_to_https -v 1
Error: The filter key 'nginx_redirect_to_https' is incorrect.
Looks like the names have changed?
I try to set yunohost settings set webadmin.allowlist -v <IP_ADDRESS> and it did not works as excepted…