I think for some of these jobs we should probably keep trying at an hourly or even daily interval. So if we e.g. have infrastructure issues over a couple of hours the system still eventually recovers without manual intervention.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
All Stories
Yesterday
this link of yours https://kb.kolab.org/2023/03/install-kolab-16-on-alma-linux-9/solar smash The package is missing when doing dnf install kolab.
Wed, Oct 2
- Set back SWOOLE_PACKAGE_MAX_LENGTH to 10MB
Tue, Oct 1
Yes, the user hr1@os-s.de does not exist in the LDAP. It is not a vaild usser. Therefore no authentication is possible. But this should not be a cause for saslauthd to fail and terminate, am I correct?
The kolab-saslauthd terminates. I reconfigured systemd to automatically restart the daemon because otherwise the login would fail for valid users as well.
as long as I could see, it is still a Domain address issue!
Addressed comments, avoid using the magic 51 status
Looks good, but for consistency both queries should use tenant context and the same way of comparing user status.
Actually the logs continue. Apparently my copy buffer did not copy the complete log. I guess the failed login of hr1 is the last thing of the old process. Then the saslauthd is restarted reading its configuration files:
Mon, Sep 30
Fri, Sep 27
Wed, Sep 25
The package has been updated; closing this task.
Packaging fix: https://obs.kolabsys.com/request/show/3324