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.

got new Version here

Translation was added to transifex: https://www.transifex.com/kolab/kolab/translate/#de/pykolab/93629155

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

This issue is not about instability but inreliability of the base mechanism.

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"

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.

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

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.

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:

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.

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.

adding those file versions to our currently installed KE14 roundcubemail 1.1.5.21 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?

OK, it was wrong that 3a. was wrong. The relevant time was just not in focus.

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.

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?

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

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

(&(&(objectclass=kolabinetorgperson)(objectclass=mailrecipient)(mail=*))(|(mail=pitb.mse@domain.de)(alias=pitb.mse@domain.de)))

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

or

• find any edit functionality involved by those plugins disabled

or

• have just no access to those plugins (Could you please give me a hint how to disable delegate from settings?)

or

• enable edit/admin/helpdesk tasks for "helpdesk-login" usage by what ever possible action/task

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).

As far as we know until now this is the same with shared folders where the KolabTargetFolder gets edited.

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.

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.

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.

Because I have no clue of erlang and am not a even gifted with developer skills, I realy don't know what do now.

after testing I'd say it's FIXED now

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")?

florian.eder@esg.de

florina.eder@esg.de

opened a new bugzilla #5461 issue to bring this special packaging problem back into focus

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".

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.

tested as maunal patch --> works
please make it packaged

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.

We tested this in our three environments and it works perfectly.
Now we just need it build and packaged.