halfgaar
-
Posts
31 -
Joined
-
Last visited
-
Days Won
1
Posts posted by halfgaar
-
-
The Dovecot docs say:
QuoteThe password scheme can be overridden for each password by prefixing it with {SCHEME}, for example:
{PLAIN}pass.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 logsI 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.
-
1
-
-
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.
-
-
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/nullIt'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/froxlorI 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.
-
24 minutes ago, d00p said:
Or simply just stop the cron service
You never know what apt restarts, and also because of reboots, I prefer to make it permanent.
24 minutes ago, d00p said:Beware of removing old but possibly still in use php-versions...I'd recommend removing older php-version after validating froxlor or customers do not use them anylonger
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.
24 minutes ago, d00p said:no maintainer, I don't know anyone still using courier. You are welcome to provide required configuration-templates for it
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.
24 minutes ago, d00p said:Sure it's regenerated, but only with data from the settings. If you have php5 in there you need to adjust the corresponding setting first
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")!"
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.
-
On 1/26/2020 at 3:10 PM, d00p said:
Yes, First through all Debians nothing special. Remember to backup everything! If on latest Debian you don't necessarily need to add the repository of you already have froxlor installed. the repository is official and includes the latest stable release of froxlor. It is safe to use.
Don't forget that due to changes in many services I'd recommend re-configure these. Also don't forget to adjust Froxlors settings according to the new environment (apache 2.2 -> 2.4, if using php-fpm, need to use mod_proxy,etc.) all prior to reconfiguring the services.
Because I had to revert a failed upgrade some time ago from Debian 8 with Froxlor 0.9 with Courier IMAP/POP3, I learned some things that may be relevant to others upgrading, so I thought I'd post them.
Important pre-steps:
- Tip: put /etc all in git.
- Disable all lines in /etc/cron.d/froxlor before doing anything.
- When upgrading Debian, it always leaves the old PHP versions around. You have to explicitly remove them after 'dist-upgrade'. Having php5 still around, unknowingly, was one of my previous problems. See your installed packages with 'aptitude search php | grep ^i'.
Further, I can't seem to find much info about it, but Froxlor dropped Courier support? At least when suggesting configs in its system setup, it only suggests Dovecot. I decided to retain Courier (for the foreseeable future). There was a big warning by apt saying ''the Courier MTA packaging has been extensively rewritten...", but in the end, I only had to fix minor permission things.
Because Froxlor only gives you Postfix+Dovecot default configs, I retained my Postfix configs, except the virtual mail configuration configs that define mysql queries. They had to be selectively taken from the system setup page in the admin panel. The tables where users reside changed, so that was important. My Postfix config still defined a 'virtual_mailbox_base', so the default 'mysql-virtual_mailbox_maps.cf' didn't work. The original file did work.
Courier didn't need changes related to logins or maildir, but it will give some errors in the error log that are easy to fix. The new courier did, however, change in which files the CA chain needs to be stored. I now have cert, key and chain all in 'TLS_CERTFILE'. My Nagios/Icinga ssl checker script is happy again.
Apt will mark courier as 'no longer needed', so you need to 'apt install' manually to make sure apt doesn't 'autoremove' it later.
/etc/cron.d/froxlor is still never regenerated. I had to edit it to replace 'php5' with php. I've had this before. Still looking into it.
-
What is the recommended upgrade path when running Debian 8 (Jessie) with Froxlor 0.9.40.1-1+jessie1? Upgrade Debian twice, then add the repo 'deb https://deb.froxlor.org/debian buster main', then upgrade Froxlor?
Also, is that repo still only 'testing', as was mentioned here (earlier in this thread)?
I will make an VPS snapshot so I have some room for experimentation (I can revert in a pinch), but knowing what to expect is better of course
-
I see the Debian packages aren't available yet?
-
Sounds good. I've always been impressed by the way Froxlor updates with the migrations, and how it manages system configs non-intrusively (unlike Plesk in both areas ?), so I'm looking forward to it.
-
Is it easy to upgrade to the API based version from 0.9, and/or is it automatic? I'm currently running 0.9 on Debian 8 (Jessie) using debs from debian.froxlor.org.
froxlor 2.1 - Security and domains enhancements, One-Time-Login-Link and nightlies
in Announcements
Posted
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.