- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
All Stories
Oct 9 2024
Oct 7 2024
You asked for hints!
The crash should not happen, but there are still to much variables included.
I just analyzed, the information I had.
Oct 4 2024
- Don't require specific file name
- Support multipart/form-data file uploads, they don't need so much memory
Oct 3 2024
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.
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.
Oct 2 2024
- Set back SWOOLE_PACKAGE_MAX_LENGTH to 10MB
Oct 1 2024
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:
Sep 30 2024
Sep 27 2024
Sep 25 2024
The package has been updated; closing this task.
Packaging fix: https://obs.kolabsys.com/request/show/3324