Patch merged.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Today
Yesterday
Feb 1 2024
Jan 3 2024
Seems to be fixed by D3692 and rPbd3a9e74745461089d7afc4e51a39c21958907bf.
Fixed by D3851.
Patch submitted as D4625.
Oct 1 2023
Old. Not enough info.
Sep 27 2023
@mollekopf, imap.user_mailbox_create() returns False on error.
I think it is better to pass the invitation to Inbox for manual processing.
This specific issue may be fixed with:
--- a/pykolab/setup/setup_roundcube.py +++ b/pykolab/setup/setup_roundcube.py @@ -26,10 +26,11 @@ import hashlib import os import random import re +import six import subprocess import sys import time -import six +import urllib.parse
It looks to me it's rather CentOS7 issue. And it's old.
Aug 10 2023
I think this got fixed in the python3 migration. Please reopen if you run into this issue again on a python3 system (>= Debian 11)
Mar 12 2023
Mar 7 2023
imap.user_mailbox_create() always returns a string, so this should be fine. Is there a command-line way to reproduce this issue?
Jul 15 2022
D3692 and D3710 should fix this
I ran into same error, when testing for Python 3
Jul 7 2022
Feb 17 2022
Feb 6 2022
Feb 4 2022
The exception comes from inside cache_update(). See attached the traceback, from the log file that Johannes sent me.
Do you happen to have a log containing a backtrace for the case where the sender column is too short? After skimming the code, I would assume SQLAlchemy throws an exception which then gets caught in bin/kolab_smtp_access_policy.py:1717. That's obviously too late.
Feb 3 2022
According to the log, the script tries to create a user named '@'. That's, well, weird. Unfortunately, I'm not sufficiently familiar with the pykolab codebase to make a qualified guess where this username may have originated from.
Jan 15 2022
May 20 2021
Jan 25 2021
Dec 4 2020
Oct 22 2020
Aug 25 2020
I didn't know that wallace created generate calender placeholder. Do they have an update for this? Hoping that they fix it as soon as possible.
Aug 12 2020
Any thoughts about how to fix this issue?
May 3 2020
Apr 1 2020
Jan 17 2020
Closing Ticket. Change has been merged
Jan 9 2020
Patch seems to work. I haven't seen this issue after applying the patch. Thanks a lot!
Dec 23 2019
Additionally I get the following traceback:
2019-12-23 14:05:25,670 pykolab.auth ERROR [21425] An error occured using _paged_search: NameError("global name 'LDAP_CONTROL_PAGED_RESULTS' is not defined",) 2019-12-23 14:05:25,670 pykolab.auth ERROR [21425] Traceback (most recent call last): File "/usr/lib/python2.7/dist-packages/pykolab/auth/ldap/__init__.py", line 3168, in _search secondary_domains File "<string>", line 10, in <module> File "/usr/lib/python2.7/dist-packages/pykolab/auth/ldap/__init__.py", line 2940, in _paged_search if c.controlType == LDAP_CONTROL_PAGED_RESULTS NameError: global name 'LDAP_CONTROL_PAGED_RESULTS' is not defined
Dec 22 2019
This happend on a Debian 10 system with most recent pykolab package
- pykolab 0.8.17-0~kolab2
- python-ldap 3.1.0-2
Dec 9 2019
Dec 6 2019
Nov 26 2019
ups, reopen
A workaround could be to move the hosted_root_dn from the [kolab_web] to [kolab] section and make a check for it. If hosted_mode is configured then look for ou=domain,$hosted_root_dn instead of the dc version. Another workaround would be to load all hosted domains into memory to avoid ldap query for every sync run. But we then need to trigger kolabd somehow to reload the domain list when domains have been changed or added
Nov 23 2019
Okay ... first issue (in my case) is that mgmt_root_dn is in the same domain name space ... One issue, but that's not the root cause
Yepp. the chmod mask was held against the umask and therefore resulted in the wrong chmod mask. After changing this to a correct umask octcal number it's okay.
Nov 19 2019
This is especially useful for fully automated setup runs like
setup-kolab \ [...] --mysqlserver=existing \ --mysqlrootpw=unix_socket [...]
--- setup_mysql.py.bak 2019-11-19 00:37:07.398064712 +0100 +++ setup_mysql.py 2019-11-19 00:46:13.000342080 +0100 @@ -143,6 +143,9 @@ _(""" Please supply the root password for MySQL, so we can set up user accounts for other components that use MySQL. + + Use password 'unix_socket' if you're using MariaDBs + unix_socket authentication plugin. """) )
Nov 18 2019
The individual directories in /run/ are secured, so there's little need to secure the files within them.
Nov 16 2019
Uploaded D847
Uploaded D853
Nov 15 2019
See Debian Bug Entry: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=921016
Nov 8 2019
@machniak Thanks a lot! I'll try the patch. This .ics arrived from Microsoft Exchange Server 2010 (based on the PRODID field in .ics).
Fixed.
Further investigation shows that actually Kolab format has CutypeRoom and CutypeUnknown defined. So, we can add these to the map, but still we should probably silently ignore unsupported values.
According to RFC5545 ROOM, UNKNOWN, X-* are valid values. Those aren't supported by Kolab, but we definitely should not throw exceptions on these. I wouldn't touch the map variable. Probably better to handle these in set_cutype().
Nov 6 2019
Sep 30 2019
spam ^^
Sep 29 2019
Sep 25 2019
I suppose it should. If it doesn't, we'll take a ticket.
Is it ok if the FQDN resolves only to an IPv6 address (working and reachable)?
This also produces a broken configuration file:
Jul 5 2019
Strange. There's a new line after import re, so the error does not make sense. And no one complained about this, so looks like an issue with your system only. It's old, anyway.
If I understand this correctly toki.space is a domain space, FQDN should include hostname.
Jun 25 2019
Jun 23 2019
Yes, I can confirm that 0.8.13-0~kolab2 solves the problem. I suggest to close this issue.
Jun 22 2019
On my system wallace has been updated to 0.8.13-0~kolab2 and restarts seem to work now. I'l have an eye on it. If other people can confirm the fix we can close the ticket.
Jun 12 2019
The problem can be reproduced on CentoOS, and Ubuntu as well. There is no matter which distro is used and I’m sure that every current build is affected.
Jun 1 2019
My python is Python 2.7.13 from the debian packages:
May 31 2019
No such issue on CentOS with wallace-0.8.11-7.1.el7.kolab_16.
May 30 2019
I've tried reading the wallace source but didn't see an easy fix. For now I use a cron job
with the following script to fix wallace up:
May 29 2019
Confirmed. If I then try to start wallace, I got:
2019-05-29 11:36:24,741 pykolab.wallace WARNING [10320] Could not bind to socket on port 10026 on bind address localhost 2019-05-29 11:36:24,741 pykolab.wallace WARNING [10320] Could not shut down socket 2019-05-29 11:36:25,743 pykolab.wallace WARNING [10320] Could not shut down socket 2019-05-29 11:36:26,745 pykolab.wallace WARNING [10320] Could not shut down socket 2019-05-29 11:36:27,747 pykolab.wallace WARNING [10320] Could not shut down socket 2019-05-29 11:36:28,750 pykolab.wallace WARNING [10320] Could not shut down socket ...
and
# ps ax | grep wallace 3595 ? S 0:00 /usr/bin/python /usr/sbin/wallaced -l warning --fork --user kolab 10320 ? Sl 0:00 /usr/bin/python /usr/sbin/wallaced -l warning --fork --user kolab 10321 ? S 0:00 /usr/bin/python /usr/sbin/wallaced -l warning --fork --user kolab 10322 ? S 0:00 /usr/bin/python /usr/sbin/wallaced -l warning --fork --user kolab 10323 ? S 0:00 /usr/bin/python /usr/sbin/wallaced -l warning --fork --user kolab 10324 ? S 0:00 /usr/bin/python /usr/sbin/wallaced -l warning --fork --user kolab