I opened a duplicate bifrost for this at https://bifrost.kolabsystems.com/T21031 .
One of the cases should end up in a commit and a new pykolab version, I think.
Jan 13 2017
I opened a duplicate bifrost for this at https://bifrost.kolabsystems.com/T21031 .
Jan 12 2017
Dec 16 2016
Dec 3 2016
Nov 8 2016
got new Version here
Nov 4 2016
Translation was added to transifex: https://www.transifex.com/kolab/kolab/translate/#de/pykolab/93629155
Nov 3 2016
was not intended to change supscribers...
This issue was resolved with https://git.kolab.org/rPe75b015fa96721968083a10d205187ffe8e335d3 in respect to T1417 and D209. The implementation is quite close to what the submitted patch was meant for. So we should close this T1389 and T10702
Oct 20 2016
This issue is not about instability but inreliability of the base mechanism.
Oct 18 2016
What do you meen by "exact commands"?
One of those?
- "kolabd" is started during system boot
- "kolab sync" some times "kolab sync -d 9" some times "kolab sync -d 9 -l debug"
- "kolab sync --resync" some times "kolab sync --resync -d 9" some times "kolab sync --resync -d 9 -l debug"
Oct 14 2016
would you like to change the status of this to some other Status than open? As far as I see now a kolab package for 2.5.9 exists right now.
Oct 13 2016
Oct 11 2016
The mechanism of "kolab sync" did not change an remains inreliable even with T1414 and the related commit D208.
Maybe the OPT_TIMEOUT on immediate LDAP connect mentioned there will go away with the new (not yet provided) version of pykolab but that will not make the process itself enterprise like reliable
Sep 29 2016
Due to already created online trainings needed to withdraw the better fitting translations of "on date" and "on dates" back to an earlier translation version with "genau am" for both.
Sep 28 2016
We made some more tests today and find the following on folders for android:
Since I have currently no chance to retest this (security guys closed public access, so mobile devices have no access at the moment), here all I have on cyrus log of the date-time where the folder creation problem happend:
Sep 22 2016
I agree, looks like a cyrus ACL problem.
The first MOVE "<f78gclud>" results in a "COPYUID" but needs to be rejected as the second one "<04c9c116>" is/was.
# for i in $(seq 100 102); do kolab list-mailbox-metadata email@example.com | grep -e server -e user ; done Folder firstname.lastname@example.org /shared/vendor/cmu/cyrus-imapd/server kolabbek002.srv.ha3.dir.muenchen.de Folder email@example.com /shared/vendor/cmu/cyrus-imapd/server kolabbek002.srv.ha3.dir.muenchen.de Folder firstname.lastname@example.org /shared/vendor/cmu/cyrus-imapd/server kolabbek003.srv.ha3.dir.muenchen.de
I just changed the layout to more "code" blocks because else the format of 1-10 lists was scrambled.
I'll provide additional info some later today.
Sep 21 2016
adding those file versions to our currently installed KE14 roundcubemail 22.214.171.124 roundcubemail-plugin-tasklist 3.2.15-4.1.el6.kolab_14 ends up in this error message:
[21-Sep-2016 11:48:54 Europe/Berlin] PHP Fatal error: Call to undefined method kolab_storage_config::apply_links() in /usr/share/roundcubemail/plugins/tasklist/drivers/kolab/tasklist_kolab_driver.php on line 604
So we can't test it. Do those changes suite on kolab enterprise 14 on REL6 roundcube and plugins?
Sep 20 2016
OK, it was wrong that 3a. was wrong. The relevant time was just not in focus.
Here a screenshot of a later status but the event is available.
Adding the "kolab_auth_admin_rights" enables everybody to use/login/enter roundcube as an other user and disables any other restriction made before.
So the mentioned configuration will just open the functuionality to everyone and not restrict anything. If thsi is as you say a config issue, than please tell me where I can find the documentation of any of those helpdesk things to be configured with all the opetions and coincidents they have.
Sep 19 2016
No I didn't think about recognizing it by name but thought about getting the annotations.
If you say that's impossible to find out if a folder of another user is by anotation his drafts folder and should be mapped to "Entwürfe" in my german RoundCube Interface because that's what's configured in Settings->Settings->Special folders.
This is relevant especially for languages which are not so popular as english is.
I would have a real problem to find out which of the french terms means "Entwürfe" but it would be possible to map that via the annotation becaus those are lang independent.
Thanks, but could you please describe what "joining" in this case realy means?
Is there an android client working correctly with "custom folders"? Could you please tell me the name of one?
Sep 15 2016
Aug 23 2016
Aug 22 2016
yes, I understand what you mean and would not have expected anything else
may be, but the view is the view for this certain user, so if user A uses special folders of user B nothing would hurt user B because the special folder mapping of user A would be required here.
Since I'm not sure if roundcubemail does that already cyrus may not be the source of the umlauts problem.
This fits for labels and icons and doesn't work with shared folders too
Aug 18 2016
ok, thank's, I've missed that
For normal mailboxes and users I'd be happy with the implementation as I read it.
We'll test it in Kolab Enterprise 14 repos if available.
As Jeroen already wrote, I think that is absolutely correct, it "should use" this
[cyrus-sasl] result_attribute = mail
but the filter "-d 9" uses is
so it includes "alias" into the search and I don't know why.
I may would have agreed, but after roundcube provides a "helpdesk-login" function and independently of that provides delegation or password plugins performing such LDAP "edit" tasks, someone using the heldesk-login feature should either
- get a warning that those plugin functions are just readonly and not an adminstration frontend replacement
- find any edit functionality involved by those plugins disabled
- have just no access to those plugins (Could you please give me a hint how to disable delegate from settings?)
- enable edit/admin/helpdesk tasks for "helpdesk-login" usage by what ever possible action/task
Aug 17 2016
Aug 16 2016
With pykolab 0.7.28 we discover the same issue.
at least, intense tests where at pykolab 0.7.27 we are currently testing pykolab 0.7.28 but discover other porblems "TIMEOUT" as reported of someone else in T1414 first. We are analysing this and tend to add our findings and logs to T1414 before we preceede testing reliability of 0.7.28 in conjunction with T1307 (this).
Aug 12 2016
Aug 11 2016
Aug 10 2016
Aug 9 2016
Aug 4 2016
As far as we know until now this is the same with shared folders where the KolabTargetFolder gets edited.
Aug 2 2016
Jul 29 2016
Ok, when it's not used but should, then what's to do here?
The goal is to only try to sync_mailhost_attrs on LDAP items that realy belong to kolab relevant items.
So either one can do it as we did patch our current version or in a simpler way as you mentioned.
Jul 28 2016
Jul 25 2016
We added this new "__init__.py" to our system and restarted kolabd and found some TIMEOUT tracebacks and a kolabd stooping after processing a buch of new users created.
Jul 15 2016
I tested on a system where I copied the sound files to the correct location some earlier, and that's why the test seamed to work but unfortunately this is not solved. The sound files are still not available at the correct path after package new/first installation.
Jul 13 2016
Because I have no clue of erlang and am not a even gifted with developer skills, I realy don't know what do now.
Jul 12 2016
Jul 11 2016
after testing I'd say it's FIXED now
Jul 8 2016
Ok, I tried that with 0.8.2 now and think I found one problem or missing info in the test you run.
Is the guam realy responding on that "nc -z"?
If I do the test you described I get at least one/a few "Success" messages returned by "nc -z". Did you just not copy those to the case (like the trailing "done")?
Jul 7 2016
Jul 6 2016
Jun 23 2016
opened a new bugzilla #5461 issue to bring this special packaging problem back into focus
Jun 20 2016
Jun 17 2016
We installed new guam version guam.x86_64 0:0.7.3-4.1.el6.kolab_14 and get an init script but this is not executable by default. After chmod 555 it's executable but complains about some "erlexec: HOME must be set".
Jun 15 2016
Jun 3 2016
I didn't say the last but the easiest.
The options we thought about:
We are fully aware of the fact, that kolab-saslauthd is not a full https://tools.ietf.org/html/rfc4422 implementation but based on this RFC our request is just to get kolab-saslauthd closer to this.
And based on the https://en.wikipedia.org/wiki/CRAM-MD5 second point of weeknesses explaination, based on RFC 2104, it could be possible to add some security too.
May 31 2016
tested as maunal patch --> works
please make it packaged
May 12 2016
We already added this code snipet to our test system and run a huge "sync --resync" which seams to add users which where not added earlier.
So I'd like to say we tested it intensively and feel real good with this patch. It's working as intended.
May 3 2016
We tested this in our three environments and it works perfectly.
Now we just need it build and packaged.