Closed oleole39 closed 1 year ago
Did you read the release note for 11.1 which mentions a fix for people that went through version 11.1.1 ... https://forum.yunohost.org/t/yunohost-11-1-release-sortie-de-yunohost-11-1/23378
No I had not thought about looking there, thank you for pointing it out - i will read next changelogs more carefully. I have now applied the manual fix regarding alias so I guess my issue is solved - let me wait till next Cron related email to confirm by closing the issue.
Side topic, I am happy to read also that deleting admin
is recommended. However, I notice one little strange thing - I cannot run su -
via SSH when connected as user me
(the admin account I use for the webadmin). It asks for a password, but when entering the password associated to the me
account, it fails to authenticate. If instead I enter password associated to admin
account, for some reason it succeeds (even though being originally logged as me
).
But sudo su
(or sudo su -
) does work with me
password and achieve similar purpose, so this is fine. I just don't understand why it is so (admin
is only in 2 groups - a deleted one referred to by an id which I find no track of via sudo cat /etc/group
nor sudo cat /etc/passwd
and the group admins
into which is also me
). So I remain slightly afraid to regret admin
user for more significant issue.
I have now applied the manual fix regarding alias so I guess my issue is solved - let me wait till next Cron related email to confirm by closing the issue.
Bad news, today's Apticron email came together with the usual email from MAILER-DAEMON, despite having applied the manual fix described in the changelog yesterday.
sudo yunohost user group info admins
outputs:
mail-aliases:
- postmaster@mydomain.tld
- root@mydomain.tld
- admins@mydomain.tld
- abuse@mydomain.tld
- admin@mydomain.tld
- webmaster@mydomain.tld
members:
- me
- admin
permissions:
More details about the emails received:
Note that I do not have deleted the admin
account yet.
Side topic, I am happy to read also that deleting admin is recommended. However, I notice one little strange thing - I cannot run su - via SSH when connected as user me (the admin account I use for the webadmin). It asks for a password, but when entering the password associated to the me account, it fails to authenticate. If instead I enter password associated to admin account, for some reason it succeeds (even though being originally logged as me).
su
asks for the root password, while sudo
asks for the user's password, yes ...
Bad news, today's Apticron email came together with the usual email from MAILER-DAEMON, despite having applied the manual fix described in the changelog yesterday.
Can you confirm that your postfix config is up to date and not flagged as manually modified ?
su
asks for the root password, whilesudo
asks for the user's password, yes ...
Ok thank you. Following your answer and some investigations I eventually found out what had been confusing me - I didn't realized that root
and admin
are actually associated to the same password on my instance. I believe that this is due to the fact that when initially installing YNH (my first install ever), I did not realized what the prompt for a "New administration password" during the postinstall script execution was accounting for (that got clear for me just now reading the code). Thus I had just entered my root password again as I did not intend to change my "administration password" (thinking of root
as the server administration account), misunderstanding that was actually expected here was a password for the creation of default account dedicated to YNH (and not server-wide) administration. I guess this relates also to me not having at first a clear picture of the scope of YNH as not-an-actual-distribution-but-a-Debian-layer.
The only impact I was able to notice so far from that misunderstanding was getting confused on the behavior of su -
, which is not a big deal. Still it is only now I got it that I feel I can delete as recommended the admin
account with tranquility and peace of mind!
Should I propose a pull request for a short disambiguation note to be added to that paragraph of the doc, basically stating that it differs from root
account and password, or it doesn't really matter ?
Can you confirm that your postfix config is up to date and not flagged as manually modified ?
Diagnosis says that "everything is okay" except:
I can't think of any manual tweak of Postfix I would have performed, and instance's /etc/postfix/main.cf
looks quite similar to to the last (20/12/2022) original project file (with only a few conditional statements not appearing).
Additionally, not sure that it makes any sense here, but i have noticed out of serendipity that cat /etc/aliases
outputs:
# See man 5 aliases for format
postmaster: root
Please let me know if you were expecting me to check something else.
I deleted the "admin" account few days after posting my previous message, and I've received today a new email related with "apticron" (one of those which would typically be accompanied by an email from Mailer-Daemon) and this time no email from Mailer-Deamon came together with it. So it seems that applying the manual fix described in the changelog AND deleting the default "admin" account solved the issue.
For the record, as I did not think of mentioning it earlier, I've been having the "Unattended upgrades" app installed to warn me about new YNH updates - I assume it is the one sending the "apticron"-related messages (and not YNH core).
It is not a very detailed bug resolution but I close the issue as my "minor" issue seems to be solved.
Describe the bug
Every time I receive an email from root@mydomain.tld (Cron/Apticron related) to the mailbox of the user I administrate a YNH instance with (I administrate the webadmin with user "me" and via SSH with user "admin"), I systematically receive an additional email from MAILER-DAEMON@mydomain.tld telling the message could not be delivered to admin@mydomain.tld due to the following error:
Also I can't create any email address for the user "admin". Saving the email creation setting results in:
Nor an alias admin@mydomain.tld for the user "me". Saving the "admin" alias creation setting results in:
It is far from being a major problem, and was referred to as a bug in that thread of the forum. I thought I would submit it as a Github issue for it to be better tracked since I couldn't find its equivalent here.
Context
Expected behavior