halfgaar

Upon upgrade to version 2.1.4 from 2.0.24, I had the same issue as llucps, where it said the domain was not configured. When I removed the www part, it worked. I then set this setting: Then the login shows, but I can't log in. After entering the 2FA, it just redirects back to the login prompt. The inspector shows it's just a '302 Found' with a rendered login prompt. I don't see reasons or HTTP codes given. Edit: it later started working OK. My browser removes cookies upon exit, so that may be related.

The Dovecot docs say: But because the $1$, $2$, etc string is already in it, this seems unnecessary? My hack is incomplete BTW: when you change the password, it changes the scheme, like to {BLF-CRYPT}. But again, because it says "$2y$", why include an override?

About the config file backups; I put my /etc/ folder under git version control. No remote repo or anything, just the ability to see and commit changes locally. There's also a project called 'etckeeper', which does the same. I never tried it though. I do it manually. I performed the upgrade to 2.0.10 about a week ago. Aside from the courier-imap thing, it went fine (on Debian 11). One small notable thing is that the proftpd SQLAuthType change mentioned in the migration guide, wasn't necessary for me. And FYI: I saw this various times: sh: line 1: /etc/init.d/bind9: No such file or directory [error] Error while running `/etc/init.d/bind9 reload`: exit code (127) - please check your system logs I don't know why it calls the sysv script.

It didn't work. After the update, the password_enc field contains {MD5-CRYPT}, like {MD5-CRYPT}$1$IcUfpkfoobar. I created a DB view to strip that content: create view mail_users_backwards as select *, replace(password_enc, '{MD5-CRYPT}', '') as password_enc_old from mail_users; I then changed authmysqlrc to use mail_users_backwards and password_enc_old. Courier doesn't support that {MD5-CRYPT} string. I also don't know why it would be there, because the $1$ specifies enough?

The migration guide mentions the password hashing algorithm Dovecot uses. Is anything known about Courier IMAP? My current authmysqlrc is: # cat /etc/courier/authmysqlrc | sed -e 's/^MYSQL_PASSWORD.*$/MYSQL_PASSWORD removed/' MYSQL_OPT 0 MYSQL_SERVER 127.0.0.1 MYSQL_USERNAME froxlor MYSQL_PASSWORD removed MYSQL_PORT 3306 MYSQL_DATABASE froxlor MYSQL_USER_TABLE mail_users MYSQL_CRYPT_PWFIELD password_enc MYSQL_UID_FIELD uid MYSQL_GID_FIELD gid MYSQL_LOGIN_FIELD username MYSQL_HOME_FIELD homedir MYSQL_MAILDIR_FIELD maildir MYSQL_QUOTA_FIELD (quota*1024*1024) MYSQL_AUXOPTIONS_FIELD CONCAT("allowimap=",imap,",allowpop3=",pop3) Because password_enc looks like $1$zEOfoobarB4hjtXhJqEH/ and contains a algorithm type, I guess that's why the migration guide says to disable the default scheme, and it will use the $1$ to detect it? Is it always $1$, or are there also newer algorithms that Courier doesn't like?

I saw the Github notification. I didn't have the opportunity to test. Anyway, that fix worked.

I'm still not 100% on the original issue I had, but it's probably related to this ticket I just made.

I'm confused. That's how it's run from the crontab /etc/cron.d/froxlor. See my original post. But, it doesn't seem to do anything (the files in /etc/ssl/froxlor were not updated), until I add --debug. And even then, it keeps thinking the domain 'thedomain.nl' (and only this one) has a new certificate, every time I run it. Once dealt with, I expect it not to show up as 'Updated Let's Encrypt certificate' anymore.

Something still amiss. The certificate wasn't updated. It was created in /root/.acme.sh, but not in /etc/ssl/froxlor. It didn't do anything, until I ran the cronjob with the --debug flag. That's something that seems to happen more often to me (requiring --debug to make the jobs work). When I run it multiple times, now, I see it still wants to pick up that domain again and again: root@myfroxlorserver: /etc/cron.d <master> # /usr/bin/php -q /var/www/froxlor/scripts/froxlor_master_cronjob.php --letsencrypt --debug [information] Updated Let's Encrypt certificate for thedomain.nl [information] Let's Encrypt certificates have been updated [notice] Checking system's last guid root@myfroxlorserver: /etc/cron.d <master> # /usr/bin/php -q /var/www/froxlor/scripts/froxlor_master_cronjob.php --letsencrypt --debug [information] Updated Let's Encrypt certificate for thedomain.nl [information] Let's Encrypt certificates have been updated [notice] Checking system's last guid root@myfroxlorserver: /etc/cron.d <master> # /usr/bin/php -q /var/www/froxlor/scripts/froxlor_master_cronjob.php --letsencrypt --debug [information] Updated Let's Encrypt certificate for thedomain.nl [information] Let's Encrypt certificates have been updated [notice] Checking system's last guid I'm at work now, so I can't check further. As for the crobjob, I keep typing that for some reason...

Fast as lightning.

Done.

I had just finished writing it 😢 😀.

I had checked that actually, there is no cron for root. There are no crons in /var/spool/cron/crontabs. I just ran 'acme.sh --install-crobjob' by hand, and it created a cron job. runIssueFor() in AcmeSh.php runs 'acme.sh --install-crobjob' on issue. So in other words, when you upgrade to the Froxlor version with the new acme system, you won't get the cronjob until you issue new certificates?

My monitoring alerted me that SSL certificates from Froxlor sites are expiring. As in, the first one triggered my warning level of 24 days. I see the PHP code only loads certificates from disk now, and a recent commit message says that acme.sh is supposed to renew? Am I missing a cron? My /etc/cron.d/froxlor is: # automatically generated cron-configuration by froxlor # do not manually edit this file as it will be re-generated periodically. PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin # */5 * * * * root /usr/bin/nice -n 5 /usr/bin/php -q /var/www/froxlor/scripts/froxlor_master_cronjob.php --tasks 1> /dev/null 0 0 * * * root /usr/bin/nice -n 5 /usr/bin/php -q /var/www/froxlor/scripts/froxlor_master_cronjob.php --traffic 1> /dev/null 5 0 * * * root /usr/bin/nice -n 5 /usr/bin/php -q /var/www/froxlor/scripts/froxlor_master_cronjob.php --usage_report 1> /dev/null 0 */6 * * * root /usr/bin/nice -n 5 /usr/bin/php -q /var/www/froxlor/scripts/froxlor_master_cronjob.php --mailboxsize 1> /dev/null */5 * * * * root /usr/bin/nice -n 5 /usr/bin/php -q /var/www/froxlor/scripts/froxlor_master_cronjob.php --letsencrypt 1> /dev/null It's dated 2020-03-08, 10:20: # lh /etc/cron.d/froxlor -rw-r----- 1 root root 840 mrt 8 10:20 /etc/cron.d/froxlor I think that's when I dist-upgraded Debian. My latest Froxlox update was 2020-06-14 09:23:52, to version 0.10.18-1. The files in /etc/ssl/froxlor are not newer, so it's not an issue with loading the certificates, what 'froxlor_master_cronjob.php --letsencrypt' now does.

You never know what apt restarts, and also because of reboots, I prefer to make it permanent. Froxlor went haywire last time running on php5, so I wanted to be sure this time. I communicated the PHP5 to 7.3 upgrade to users before the upgrade, so I was covered there. I could, perhaps, but I don't have any special reason to use it (. I just didn't want to tag a Courier-to-dovecot migration to my upgrade as well. People installing fresh would like not care, but people upgrading like me do. But, I've found very little comments that people do. This forum post may help the few who do. The cronjob settings page says: "Cron execution command (php-binary): Command to execute our cronjobs. Change this only if you know what you are doing (default: "/usr/bin/nice -n 5 /usr/bin/php5 -q")!" Here in source. Shouldn't that have been covered in a migration? I just changed that setting, and the cronjob, that I had added some test comments too, is indeed regenerated.