From kolab-issues at intevation.de  Mon Sep  1 14:47:04 2008
From: kolab-issues at intevation.de (Ludwig Reiter)
Date: Mon, 01 Sep 2008 12:47:04 +0000
Subject: [Kolab-devel] [issue3021] Crash in
	KMail::ImapAccountBase::removeJob after unsubscribtion of a
	local folder
Message-ID: <1220273224.71.0.0153094026373.issue3021@intevation.de>


New submission from Ludwig Reiter <ludwig at intevation.de>:

enterprise35 20080602.814375

A customer reported a crash. His account was changed to mixed mode a weeek ago.
He deactived "Hide groupware folders" and locally subscribed shared groupware
folders in the dimap part of the account. Then the shared groupware folders are
shown in both account. He tried to locally unsubscribe the shared folders from 
the imap account, but Kontact crashed.

I couldn't reproduce this bug. In my tests after locally subscribing the shared 
groupware folders in the dimap account, they were not displayed.

output of stderr:
kmail: delimiterForNamespace user
kmail: found namespace folder user
kmail: shared in namespace :true
kmail: checkFolders - shared disappeared
kmail: connections to server slugis.knut.univention.de now 0
kmail: processNextCheck, remaining 0
kmail: account Kolab-Server f<FC>r E-Mail finished check
kmail: processNextCheck, remaining 1
kmail: for host slugis.knut.univention.de current connections=0 and limit is 0
kmail: connection limit reached: false
kmail: processing next mail check for Kolab-Server f<FC>r E-Mail
kmail: check mail started - connections for host slugis.knut.univention.de now
is 1
kmail: KMFolderImap::processNewMail - waiting for connection: kalender
kmail: KMFolderImap::checkValidity of: /user/shared/shared/
kmail: CheckValidity - waiting for connection
kmail: ListJob - waiting for connection
kmail: slotListNamespaces - waiting for connection
*** KMail got signal 11 (Crashing)
KCrash: Application 'kontact' crashing...

----------
assignedto: till
files: Kontact-Crash-080901.kcrash
messages: 16434
nosy: bh, ludwig, osterfeld, pradeepto, till, vkrause
priority: bug
status: need-eg
title: Crash in KMail::ImapAccountBase::removeJob after unsubscribtion of a local folder
topic: kde client, prokde35
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3021>
___________________________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Kontact-Crash-080901.kcrash
Type: application/octet-stream
Size: 4639 bytes
Desc: not available
Url : http://kolab.org/pipermail/kolab-devel/attachments/20080901/53108e7b/Kontact-Crash-080901.exe

From bernhard at intevation.de  Mon Sep  1 14:55:35 2008
From: bernhard at intevation.de (Bernhard Reiter)
Date: Mon, 1 Sep 2008 14:55:35 +0200
Subject: [Kolab-devel] Developers vacations
Message-ID: <200809011455.40772.bernhard@intevation.de>

Hi All,
in case you wonder, of course our hard working Kolab Server and Client
developers go on vacation from time to time or are otherwise unavailable.
Gunnar Wrobel is gone this work week.
Thomas Arendsen Hein this and the following week (37).

So if reaction from them or others is delayed, fear not.
(And as with most Free Software communities: Ask again if a reaction is 
missing after a reasonable timeframe.)

Best,
Bernhard

-- 
Managing Director - Owner: www.intevation.net       (Free Software Company)
Germany Coordinator: fsfeurope.org. Coordinator: www.Kolab-Konsortium.com.
Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998
Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://kolab.org/pipermail/kolab-devel/attachments/20080901/93b276b9/attachment.bin

From kolab-issues at intevation.de  Mon Sep  1 15:08:08 2008
From: kolab-issues at intevation.de (Ludwig Reiter)
Date: Mon, 01 Sep 2008 13:08:08 +0000
Subject: [Kolab-devel] [issue3022] CSS-Properties of an attached mail
	changes the display of the first part of a mail.
Message-ID: <1220274488.25.0.397294287887.issue3022@intevation.de>


New submission from Ludwig Reiter <ludwig at intevation.de>:

enterprise35 20080725.837785

A user prefered HTML to plain text. He received a mail with an attached HTML mail.
The HTML properties of the attached mail are also used for the first part of the
mail.

----------
assignedto: till
messages: 16437
nosy: bh, ludwig, osterfeld, pradeepto, till, vkrause
priority: bug
status: unread
title: CSS-Properties of an attached mail changes the display of the first part of a mail.
topic: enterprise35, kde client
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3022>
___________________________________________________


From kolab-issues at intevation.de  Mon Sep  1 15:30:38 2008
From: kolab-issues at intevation.de (Bernhard Reiter)
Date: Mon, 01 Sep 2008 13:30:38 +0000
Subject: [Kolab-devel] [issue3023] Allow SSL X509 certificates for the Kolab
	KDE Client Kontact to be set by the administrator
Message-ID: <1220275838.17.0.281873279962.issue3023@intevation.de>


New submission from Bernhard Reiter <bernhard at intevation.de>:

If the ssl certificate of a Kolab Server changes,
all KDE Kolab Clients might pop up a dialog asking for the trust
of the SSL certificate (chain). 

It would be nice to have a way as an administrator for a KDE machine
to set up a certificate chain. We found out for the proko2 client
that you could place certificates in /etc/kde3/ksslcalist, but this was not
enough.

Till, first analysis is kkc so far: 
Do you have a pointer within KDE what would be
the right place to see documentation or ask? Should this above work with 
enterprise35.

----------
assignedto: till
messages: 16439
nosy: bernhard, ludwig, till, vkrause
priority: wish
status: unread
title: Allow SSL X509 certificates for the Kolab KDE Client Kontact to be set by the administrator
topic: enterprise35, kde client, kkc, proko2branch
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3023>
___________________________________________________


From kolab-issues at intevation.de  Mon Sep  1 15:52:58 2008
From: kolab-issues at intevation.de (Ludwig Reiter)
Date: Mon, 01 Sep 2008 13:52:58 +0000
Subject: [Kolab-devel] [issue3024] Crash in KCal::Incidence::revision
Message-ID: <1220277178.11.0.154514043853.issue3024@intevation.de>


New submission from Ludwig Reiter <ludwig at intevation.de>:

enterprise35 20080829.854247

Test:
1. User A sent an invitation to user B's account.
2. User B syncs and looks at the invitation mail.
=> Crash.

----------
assignedto: till
files: crash-20080901-opening-invitation.txt
messages: 16440
nosy: bh, ludwig, osterfeld, pradeepto, till, vkrause
priority: critical
status: unread
title: Crash in KCal::Incidence::revision
topic: kde client, prokde35
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3024>
___________________________________________________
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: crash-20080901-opening-invitation.txt
Url: http://kolab.org/pipermail/kolab-devel/attachments/20080901/28063c23/crash-20080901-opening-invitation.txt

From bh at intevation.de  Tue Sep  2 15:34:23 2008
From: bh at intevation.de (Bernhard Herzog)
Date: Tue, 2 Sep 2008 15:34:23 +0200
Subject: [Kolab-devel] Annotation Plugin for dovecot
Message-ID: <200809021534.26589.bh@intevation.de>

Hi,

as has been discussed on this list briefly, we are working on extensions for 
the dovecot IMAP server to make it possible to use it instead of Cyrus IMAPd 
in the Kolab Server.  One of the extensions needed for that, the metadata 
plugin that implements the annotations, has been published now.  It's still 
more or less a prototype and hasn't been tested very well yet, but it should 
be possible to actually use it.  For details on the status and how to use it 
with dovecot, see the README file.

Currently the plugin is available as a mercurial repository at 
http://hg.intevation.org/kolab/dovecot-metadata-plugin/

Regards,

   Bernhard


-- 
Bernhard Herzog                              Intevation GmbH, Osnabr?ck
Amtsgericht Osnabr?ck, HR B 18998             http://www.intevation.de/
Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
Url : http://kolab.org/pipermail/kolab-devel/attachments/20080902/187ff39e/attachment.bin

From kolab-issues at intevation.de  Wed Sep  3 09:03:25 2008
From: kolab-issues at intevation.de (=?utf-8?q?Albrecht_Dre=C3=9F?=)
Date: Wed, 03 Sep 2008 07:03:25 +0000
Subject: [Kolab-devel] [issue3025] Security check for Passwords
Message-ID: <1220425404.97.0.0864681829601.issue3025@intevation.de>


New submission from Albrecht Dre? <albrecht.dress at lios-tech.com>:

Currently, there is no check performed in the Kolab admin Web UI if the
passwords entered by the administrator or the user fulfil basic strength
requirements.  This is a security risk (thus a bug) and violates the
requirements set by the German Bundesamt f?r Sicherheit in der
Informationstechnik (BSI, <http://www.bsi.bund.de>).  The relevant standard
seems to be available in German only:
<http://www.bsi.bund.de/gshb/deutsch/m/m02011.htm>; there is also a HUGE pdf
containing everything in English.  I believe you will find similar requirements
elsewhere, though.

In issue <https://www.intevation.de/roundup/kolab/issue2997>, I presented a
method (including a tiny C source code) to check passwords using the standard
"cracklib" library.  I suggest to make this check mandatory by default, and give
administrators the option to switch it off if it's really not needed.

As an alternative, the method used by Horde might be used, but it has the
drawback that it doesn't check for dictionary words like Cracklib (which should
therefore be the preferred method).

----------
messages: 16470
nosy: albrecht.dress, rbos
priority: bug
status: unread
title: Security check for Passwords
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3025>
___________________________________________________


From kolab-issues at intevation.de  Wed Sep  3 10:43:03 2008
From: kolab-issues at intevation.de (Ludwig Reiter)
Date: Wed, 03 Sep 2008 08:43:03 +0000
Subject: [Kolab-devel] [issue3026] Toolbar configuration "kmail_part"
	contains a "New Message..." action , which is not displayed.
Message-ID: <1220431383.25.0.819293071424.issue3026@intevation.de>


New submission from Ludwig Reiter <ludwig at intevation.de>:

enterprise 20080829.854247

After opening the toolbar configuration of kmail and switching to the 
"kmail part" toolbar, you can find a action "New Message..." as first action in
the action list. But this action is not needed and not displayed in the toolbar
of the kmailplugin. So I think it should be deleted from the action list.

----------
assignedto: till
messages: 16475
nosy: bh, ludwig, osterfeld, pradeepto, till, vkrause
priority: minor bug
status: unread
title: Toolbar configuration "kmail_part" contains a "New Message..." action , which is not displayed.
topic: enterprise35, kde client
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3026>
___________________________________________________


From kolab-issues at intevation.de  Wed Sep  3 10:49:36 2008
From: kolab-issues at intevation.de (Enrico)
Date: Wed, 03 Sep 2008 08:49:36 +0000
Subject: [Kolab-devel] [issue3027] In horde can't save spam level
Message-ID: <1220431776.87.0.620224647976.issue3027@intevation.de>


New submission from Enrico <ezaffa at gmail.com>:

In Kolab 2.2 whenever users change spam level within horde any modifications are
lost after logout. At new login spam level is always reverted to default (5).

----------
messages: 16476
nosy: ezaffa
priority: minor bug
status: unread
title: In horde can't save spam level
topic: web client
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3027>
___________________________________________________


From kolab-issues at intevation.de  Wed Sep  3 10:52:27 2008
From: kolab-issues at intevation.de (Enrico)
Date: Wed, 03 Sep 2008 08:52:27 +0000
Subject: [Kolab-devel] [issue3028] List of users that activate spam
Message-ID: <1220431947.31.0.972191053792.issue3028@intevation.de>


New submission from Enrico <ezaffa at gmail.com>:

Is there any way to count and identify users that have activated spam filter
within horde?
I'm running a kolab server with about 800 users and this could be a very useful
feature for me.
Thanks

----------
messages: 16477
nosy: ezaffa
priority: wish
status: unread
title: List of users that activate spam
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3028>
___________________________________________________


From kolab-issues at intevation.de  Thu Sep  4 13:41:50 2008
From: kolab-issues at intevation.de (Ludwig Reiter)
Date: Thu, 04 Sep 2008 11:41:50 +0000
Subject: [Kolab-devel] [issue3029] A changed series of appointments created
	by toltec are not displayed by kontact
Message-ID: <1220528509.94.0.300431397919.issue3029@intevation.de>


New submission from Ludwig Reiter <ludwig at intevation.de>:

proko2 2.1.12
toltec 2.2.0

Test:
1. Create a series of appointment with a toltec account.
2. Sync and look with kontact on the account.
=> The series is displayed in the calendar of kontact.
3. Use toltec to change a subevent of the series.
4. Sync with kontact.
=> The changed sub series appointment is not displayed in kontact.

----------
assignedto: till
messages: 16501
nosy: bh, joonradley, ludwig, till, vkrause
priority: bug
status: unread
title: A changed series of appointments created by toltec are not displayed by kontact
topic: enterprise35, kde client, proko2branch, toltec
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3029>
___________________________________________________


From kolab-issues at intevation.de  Fri Sep  5 08:02:49 2008
From: kolab-issues at intevation.de (Alex Potter)
Date: Fri, 05 Sep 2008 06:02:49 +0000
Subject: [Kolab-devel] [issue3030] clamav: Crash with crafted chm,
	CVE-2008-1389
Message-ID: <1220594569.0.0.0150446098449.issue3030@intevation.de>


New submission from Alex Potter <alex at ap-consulting.co.uk>:

There is a new release of clamav
ClamAV update process started at Fri Sep  5 07:00:07 2008
WARNING: Your ClamAV installation is OUTDATED!
WARNING: Local version: 0.93.3 Recommended version: 0.94

----------
messages: 16503
nosy: alepot
priority: urgent
status: unread
title: clamav: Crash with crafted chm, CVE-2008-1389
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3030>
___________________________________________________


From kolab-issues at intevation.de  Sat Sep  6 16:57:59 2008
From: kolab-issues at intevation.de (Richard Bos)
Date: Sat, 06 Sep 2008 14:57:59 +0000
Subject: [Kolab-devel] [issue3031] Make kolab.globals readonly
Message-ID: <1220713079.45.0.666332213717.issue3031@intevation.de>


New submission from Richard Bos <ml at radoeka.nl>:

Make kolab.globals readonly as it should never be changed, after
installing a package.

Attached change will be committed to cvs

This issue is created so it can be included in the release-notes.

----------
assignedto: rbos
files: kolabd_Makefile.am.diff
messages: 16509
nosy: rbos
priority: bug
status: in-progress
title: Make kolab.globals readonly
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3031>
___________________________________________________
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: kolabd_Makefile.am.diff
Url: http://kolab.org/pipermail/kolab-devel/attachments/20080906/c362260a/kolabd_Makefile.am.txt

From kolab-issues at intevation.de  Mon Sep  8 15:29:19 2008
From: kolab-issues at intevation.de (Ludwig Reiter)
Date: Mon, 08 Sep 2008 13:29:19 +0000
Subject: [Kolab-devel] [issue3032] Kontact changes diff-attachments
Message-ID: <1220880559.43.0.662155939036.issue3032@intevation.de>


New submission from Ludwig Reiter <ludwig at intevation.de>:

enterprise35 ver. 20080829.854247

A file containing Newlines and Windows-Carrige Returns is changed after 
Sending, receiving and saving.

Test:
1. Create a testfile or use test.diff
2. Send a mail with this file as attachment to yourself.
3. Save the attachment.
4. diff both files.
=> The Windows cr has disappeared.

----------
assignedto: till
files: test.diff
messages: 16520
nosy: bh, ludwig, osterfeld, pradeepto, till, vkrause
priority: urgent
status: unread
title: Kontact changes diff-attachments
topic: kde client, prokde35
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3032>
___________________________________________________
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: test.diff
Url: http://kolab.org/pipermail/kolab-devel/attachments/20080908/7d495a66/test.txt

From wrobel at pardus.de  Thu Sep 11 09:39:57 2008
From: wrobel at pardus.de (Gunnar Wrobel)
Date: Thu, 11 Sep 2008 09:39:57 +0200
Subject: [Kolab-devel] Modifying the LDAP user representation
	for	a	distributed Kolab server system?
In-Reply-To: <200808261238.12841.bernhard@intevation.de>
References: <871w1drtk6.fsf@home.pardus.de>
	<200808140949.59704.bernhard@intevation.de>
	<20080815064150.15837km92i9ik18o@devmail.pardus.de>
	<200808261238.12841.bernhard@intevation.de>
Message-ID: <20080911093957.57147fvy5dk1frsw@webmail2.pardus.de>

Quoting "Bernhard Reiter" <bernhard at intevation.de>:

> On Friday 15 August 2008 06:41, Gunnar Wrobel wrote:
>> Quoting Bernhard Reiter <bernhard at intevation.de>:
>> > On Tuesday 29 July 2008 14:05, Gunnar Wrobel wrote:
>> >> Inventing a new Kolab user LDAP attribute for each and every service
>> >> of the Kolab server to support such splitting seems like an overhead
>> >> and people did not like the suggestion too much.
>> >>
>> >> So let me suggest an alternative by using the existing
>> >> "kolabHomeserver" attribute. Would it be okay to extend its syntax to
>> >> allow for several settings like:
>> >>
>> >>   "example.org"
>> >>   "MTA:smtp.example.org"
>> >>   "IMAP:imap.example.org"
>> >>   "FreeBusy:fb.example.org"
>> >>
>> >> The default would be the entry without "prefix:" but it would be
>> >> possible to provide redirects for specific services.
>> >
>> > This looks quite ugly to me. Somehow inventing more parsing within
>> > an LDAP attribute really feel wrong to me.
>> > So if we need the attributes, we can for sure come up with enough for
>> > them.
>>
>> Okay, I agree with the parsing thing.
>>
>> > I am not sure that we need it per user, though.
>>
>> p at rdus does :) If you have an array of IMAP servers behind an MTA
>> layer the MTA layer should actually know which IMAP server to deliver
>> to. And that is per user. I know this is not possible with
>> Kolab2/OpenPKG at the moment but such distributed setup are feasible
>> with Kolab.
>
> Ah, you also want to split up below one homeserver.
> Of course, if you want to do this, it needs to be saved somewhere.
> For most deployment I would normally recommend having one imap server (which
> can be a cluster) per homeserver. It does not hurt to have one MTA per IMAP
> server and might help in many situations. I guess this is why I did not get
> the idea.

Yes in general I would agree. Having a seperate MTA layer gives you  
some additional options concerning failover and redundancy though. And  
for me it drastically reduces maintainance efforts but that is of  
course more related to not using the OpenPKG version.

I consider the fact that you can easily split the Kolab server to that  
degree an very important plus for the groupware server. Hence the wish  
for this feature as it is nothing too complex even if it is irrelevant  
in the default setup.

>
>> > For the user, most should be transparent (means: not visible).
>>
>> The admin sets this stuff in the web admin frontend. It should
>> obviously not be editable by the user as this concerns the server
>> infrastructure and is no user setting.
>>
>> > This is why I am also against putting anything server specific in the
>> > login information. This could change during the lifetime of an account.
>>
>> Login information? Sorry, didn't understand this comment. Can you clarify?
>
> I believe I've refered to the upcoming point where I saw "USER:PASS at SERVER"
> and I wanted to outrule this as part of an LDAP entry.
>>
>> >> If I consider the point Bernhard mentioned recently concerning
>> >> splitted IMAP storage per user it might also make sense to have a
>> >> syntax like
>> >>  "imap://USER:PASS at SERVER"
>> >
>> > For what in particular?
>> > The splitted IMAP storage will only be known the the user's client
>> > mostly.
>>
>> So the user would set the storage spaces in Kontact and in the Kolab
>> web client again?
>
> Yes.
> Even if we find a desired way of saving client configuration on one server
> somehow.
>
>> Storing that in LDAP would remove this redundancy or not?
>
> It would, but it would also defeat the security aspect of the idea.
> If you have server A and server B, you would not want admin of server
> A to be able to log into server B to have some separation. :)
> So putting credentials in the directory service of server A
> is not that helpful.

Yes, forget my initial comments. I confused two concepts that were not  
related at all.

Concerning the Kolab web client the user could store the necessary  
configuration on the primary IMAP store. For the web client this might  
actually be the only reasonable solution. Currently we store the  
configuration of the web client in LDAP though.

We would have to think that through once we really start implementing  
such a feature. I must admit that I'm rather interested though. I'd  
like to be able to  add other IMAP storage spaces to my accounts  
(gmail for example). It might also be possible to network to a higher  
degree between the Kolab Konsortium partners if we provide IMAP  
accounts to our partners for joint projects. Just some ideas.

Cheers,

Gunnar

>
>
>
> --
> Managing Director - Owner: www.intevation.net       (Free Software Company)
> Germany Coordinator: fsfeurope.org. Coordinator: www.Kolab-Konsortium.com.
> Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998
> Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
>



-- 
____ http://www.pardus.de _________________ http://gunnarwrobel.de _

E-mail : p at rdus.de                                 Dr. Gunnar Wrobel
Tel.   : +49 700 6245 0000                         Bundesstrasse 29
Fax    : +49 721 1513 52322                        D-20146 Hamburg
--------------------------------------------------------------------
    >> Mail at ease - Rent a kolab groupware server at p at rdus <<
--------------------------------------------------------------------


----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.


From kolab-issues at intevation.de  Thu Sep 11 13:50:43 2008
From: kolab-issues at intevation.de (T. Ribbrock)
Date: Thu, 11 Sep 2008 11:50:43 +0000
Subject: [Kolab-devel] [issue3034] Kontact stays in online mode while
	synching with Palm PDA
Message-ID: <1221133843.38.0.721919489403.issue3034@intevation.de>


New submission from T. Ribbrock <itsef-admin at brightsight.com>:

I've recently done some experimenting with kontact enterprise35/kpilot and
synching with my Palm Tungsten E2. I noticed that - contrary to proko2 - the new
kontact does not switch to offline mode while synching with the PDA. I've tried
synchs in this mode for a couple of times and observed the following:

- Seemingly, kontact/korganizer tries to update the events on the server several
times during the synch. This seems to result in a heavy performance penalty -
the synchs take unusally long and the status meter at the bottom of the kontact
window is continually busy.
- Also, I came across tons of "conflict" pop-ups in each synch, which is
extremely annoying
- The very first time I synched after switching from proko2 to enterprise35, I
even lost a couple of events.

Based on those experiences, I decided to try a different approach:
1) Before synching, I switch Kontact to offline mode
2) Synch with PDA
3) Switch Kontact back to online, then initiate a synch with the server

So far, that has worked *a lot* better - the synchs are much faster and I have
yet to see my first "conflict" pop-up.

Hence, my conclusion: The enterprise35 kontact should switch to offline (just
like proko2 did) when synching with a Palm.

As for versions: I'm basically following the Debian unstable packages from
Kolab, but rebuilding them for Kubuntu 8.04. Currently, I'm on 837785.

----------
messages: 16605
nosy: itsef_admin
priority: bug
status: unread
title: Kontact stays in online mode while synching with Palm PDA
topic: enterprise35, kpilot
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3034>
___________________________________________________


From kolab-issues at intevation.de  Thu Sep 11 14:27:12 2008
From: kolab-issues at intevation.de (=?utf-8?q?Albrecht_Dre=C3=9F?=)
Date: Thu, 11 Sep 2008 12:27:12 +0000
Subject: [Kolab-devel] [issue3035] Initialise internal Horde parameters when
	creating a user
Message-ID: <1221136032.12.0.319065902251.issue3035@intevation.de>


New submission from Albrecht Dre? <albrecht.dress at lios-tech.com>:

When a new user has been created and logs in into Horde, it will complain that
the identity must be configured before appointments can be created.  This
information is known to kolab, so it should add the proper entity when creating
the user.  Looking through the LDAP data after creating the user, this is
apparently an 'hordePrefs' element with the value 'identities:[base64-encoded
string]', where the base64 encoded string contains something like

<snip>
a:1:{i:0;a:4:{s:2:"id";s:18:"Standardidentit?t";s:8:"fullname";s:15:"Test 1
Benutzer";s:9:"from_addr";s:19:"test1 at my-domain.com";s:16:"default_identity";s:1:"0";}}
</snip>

Furthermore, the Global Kolab Address Book is by default not used.  Related to
the one above, a 'turbaPrefs' element with value 'addressbooks:[base64-encoded
string]' should be added, where the base64 encoded string contains something
(watch the newline between the two elements!)

<snip>
test1 at lios-tech.com
kolab_global
<snip>

----------
messages: 16606
nosy: albrecht.dress
priority: feature
status: unread
title: Initialise internal Horde parameters when creating a user
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3035>
___________________________________________________


From wilde at intevation.de  Thu Sep 11 16:23:53 2008
From: wilde at intevation.de (Sascha Wilde)
Date: Thu, 11 Sep 2008 16:23:53 +0200
Subject: [Kolab-devel] Kolab Security Issue 22 (clamav)
Message-ID: <s7w63p24v7q.fsf@intevation.de>

Kolab Security Issue 22 20080911
================================

Package:              Kolab Server, ClamAV
Vulnerability:        denial of service
Kolab Specific:       no
Dependent Packages:   none


Summary
~~~~~~~

Various unspecified memory corruption vulnerabilities and a bug in the
chm parser allowed remote attackers to cause a denial of service.
Further unknown attack vectors might exist.


Affected Versions
~~~~~~~~~~~~~~~~~

This affects versions of ClamAV up to version 0.93.1
Kolab Server 2.1.0 and previous releases of the 2.1 branch are affected.
Kolab Server 2.0.4 and previous releases of the 2.0 branch are affected.
Kolab Server 2.2.0 and previous prereleases are affected.


Fix
~~~

Upgrade to ClamAV 0.94.

The ClamAV source RPM patched to be compilable with Kolab Server 2.1 and 2.0
is available from the Kolab download mirrors as:
security-updates/20080911/clamav-0.94-20080905_kolab.src.rpm

For Kolab Server 2.2.0 the unmodified OpenPKG rpm can be used:
security-updates/20080911/clamav-0.94-20080905.src.rpm

A binary RPM for Kolab Server 2.1.0 (ix86 Debian GNU/Linux Sarge) is available:
security-updates/20080911/clamav-0.94-20080905_kolab.ix86-debian3.1-kolab.rpm

A binary RPM for Kolab Server 2.2.0 (ix86 Debian GNU/Linux Etch) 
is available from:
security-updates/20080911/clamav-0.94-20080905_kolab.ix86-debian4.0-kolab.rpm

All other server versions: Please build from the src.rpm.


The mirrors are listed on http://kolab.org/mirrors.html
While the mirrors are catching up, you can also get the package via rsync:
# rsync -tvP rsync://rsync.kolab.org/kolab/server/security-updates/20080911/clamav-0.94-20080905_kolab.src.rpm .
# rsync -tvP rsync://rsync.kolab.org/kolab/server/security-updates/20080911/clamav-0.94-20080905_kolab.ix86-debian3.1-kolab.rpm .
# rsync -tvP rsync://rsync.kolab.org/kolab/server/security-updates/20080911/clamav-0.94-20080905.src.rpm .
# rsync -tvP rsync://rsync.kolab.org/kolab/server/security-updates/20080911/clamav-0.94-20080905.ix86-debian4.0-kolab.rpm .

MD5 sums:
35acf995ef8927a8ea76afb8502eb648  clamav-0.94-20080905.ix86-debian4.0-kolab.rpm
0b6be1bf21deef9de8582a56d330aaef  clamav-0.94-20080905.src.rpm
67ffd197c991b5d1dc83520a91b5ff57  clamav-0.94-20080905_kolab.ix86-debian3.1-kolab.rpm
0b7d3a2a22f9a2c2e12bc0b14cc3b800  clamav-0.94-20080905_kolab.src.rpm


The package can be installed on your Kolab Server with

# /kolab/bin/openpkg rpm --rebuild clamav-0.93.1-20080610_kolab.src.rpm
# /kolab/bin/openpkg rpm \
  -Uvh /kolab/RPM/PKG/clamav-0.93.1-20080610_kolab.<ARCH>-<OS>-kolab.rpm
# rm /kolab/etc/clamav/*.rpmsave
# /kolab/bin/openpkg rc clamav stop
# /kolab/bin/openpkg rc clamav start
# su - kolab-r
$ freshclam
$ rm -r /kolab/share/clamav/*.inc

For Kolab Server 2.0.4 you have to copy the new /kolab/etc/clamav/clamd.conf
to /kolab/etc/kolab/templates/clamd.conf.template so it will not be
overwritten by kolabconf. Do NOT copy this file with Kolab Server 2.1 or 2.2!


Details
~~~~~~~

http://sourceforge.net/project/shownotes.php?release_id=623661&group_id=86638
	ClamAV 0.94 release notes

http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-1389
https://wwws.clamav.net/bugzilla/show_bug.cgi?id=1089
	clamav chm handler: crasher bugs

http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-3912
http://www.securityfocus.com/bid/31051
https://wwws.clamav.net/bugzilla/show_bug.cgi?id=1141
	DOS related to out-of-memory in libclamav

http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-3913
http://www.securityfocus.com/bid/31051
https://wwws.clamav.net/bugzilla/show_bug.cgi?id=1141
	DOS caused by multiple memory leaks in freshclam/manager.c

http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-3914
http://www.securityfocus.com/bid/31051
https://wwws.clamav.net/bugzilla/show_bug.cgi?id=1141
	Multiple unspecified vulnerabilities with unknown impact

Timeline
~~~~~~~~
    20080902 ClamAV release 0.94.
    20080905 OpenPKG 0.94 package release.
    20080905 Kolab Bug Tracker Issue created.
    20080611 Kolab Server security advisory published.

-- 
Sascha Wilde                                      OpenPGP key: 4BB86568
Intevation GmbH, Osnabr?ck             http://www.intevation.de/~wilde/
Amtsgericht Osnabr?ck, HR B 18998             http://www.intevation.de/
Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 188 bytes
Desc: not available
Url : http://kolab.org/pipermail/kolab-devel/attachments/20080911/ce7a05d0/attachment.bin

From ml at radoeka.nl  Thu Sep 11 17:55:13 2008
From: ml at radoeka.nl (Richard Bos)
Date: Thu, 11 Sep 2008 17:55:13 +0200
Subject: [Kolab-devel] Is it okay to commit the samba patch to cvs?
Message-ID: <200809111755.13871.ml@radoeka.nl>

Now that the syncprov code has been committed to cvs, I would
like to look at the samba patch that is provided in issue2997:
https://www.intevation.de/roundup/kolab/issue2997

Is it okay to commit the patch to cvs?  The code must be adapted to cvs and 
some files must be added to a Makefile that I'll take care off.  If somebody 
finds the time to review the patch, I think that it is important to look the 
ldap attribute definitions and perhaps the quality of the code.

-- 
Richard Bos
We are borrowing the world of our children,
It is not inherited from our parents.


From alex at ap-consulting.co.uk  Thu Sep 11 23:39:01 2008
From: alex at ap-consulting.co.uk (Alex Potter)
Date: Thu, 11 Sep 2008 22:39:01 +0100
Subject: [Kolab-devel] Kolab Security Issue 22 (clamav)
In-Reply-To: <s7w63p24v7q.fsf@intevation.de>
References: <s7w63p24v7q.fsf@intevation.de>
Message-ID: <200809112239.02000.alex@ap-consulting.co.uk>

On Thursday 11 September 2008 15:23:53 Sascha Wilde wrote:
> Kolab Security Issue 22 20080911
> ================================
>
> Package:              Kolab Server, ClamAV
> Vulnerability:        denial of service
> Kolab Specific:       no
> Dependent Packages:   none

Thanks.

>
>
> The package can be installed on your Kolab Server with
>
> # /kolab/bin/openpkg rpm --rebuild clamav-0.93.1-20080610_kolab.src.rpm
> # /kolab/bin/openpkg rpm \
>   -Uvh /kolab/RPM/PKG/clamav-0.93.1-20080610_kolab.<ARCH>-<OS>-kolab.rpm

Minor nitpick: these instructions refer to the previous release...

Regards

Alex


From alex at ap-consulting.co.uk  Thu Sep 11 23:43:38 2008
From: alex at ap-consulting.co.uk (Alex Potter)
Date: Thu, 11 Sep 2008 22:43:38 +0100
Subject: [Kolab-devel] Bug in configure when building new clamav package
	from source rpm
Message-ID: <200809112243.38994.alex@ap-consulting.co.uk>

I noticed this while installing the clamav update at the configure stage of 

	`/kolab/bin/openpkg rpm --rebuild clamav-0.94-20080905_kolab.src.rpm`

checking for CVE-2008-1372... bugged
configure: WARNING: ****** bzip2 libraries are affected by the CVE-2008-1372 
bug
configure: WARNING: ****** We strongly suggest you to update to bzip2 1.0.5.

Regards

Alex


From bernhard at intevation.de  Fri Sep 12 09:41:01 2008
From: bernhard at intevation.de (Bernhard Reiter)
Date: Fri, 12 Sep 2008 09:41:01 +0200
Subject: [Kolab-devel] Enhancing Kolab decision making(re: Is it okay to
	commit the samba patch to cvs?)
In-Reply-To: <200809111755.13871.ml@radoeka.nl>
References: <200809111755.13871.ml@radoeka.nl>
Message-ID: <200809120941.06039.bernhard@intevation.de>

Hi Richard,

On Thursday 11 September 2008 17:55, Richard Bos wrote:
>  I would
> like to look at the samba patch that is provided in issue2997:
> https://www.intevation.de/roundup/kolab/issue2997
>
> Is it okay to commit the patch to cvs? ?The code must be adapted to cvs and
> some files must be added to a Makefile that I'll take care off. ?If
> somebody finds the time to review the patch, I think that it is important
> to look the ldap attribute definitions and perhaps the quality of the code.

thanks for the reminder. I am still trying to find a way to deal with larger 
proposals to extend Kolab Server (and Kolab as in Kolab Solution).
I scanned the issue and the wiki page and what I am personally missing
is an overview about the implications of making the change.
This would include possible alternatives, for whom, which use cases are 
solved, why this technical approach was choosen on so on.
Maybe we do need something like a KEP (Kolab Enhancement Proposal)
going by the example of Python's PEPs: http://www.python.org/dev/peps/ .
The problem is: How do we make decisions of this importance? How do we keep 
the design philosophy?

Any CVS person could commit, (including Richard), but none would take such a 
decison alone. Others have a hard time making up their mind, because they 
would need to take 3 hours or so out, to completely read through the material 
to be able to have a opinion on it.

For Samba, this has traditionally be orthogonal to Kolab Server and was 
integrated during project, because of the difference needs. If we add 
something to Kolab Server (and the Kolab Solution) this should cater almost 
all reasonable needs and it should not add complexity for non-samba users.
Discussing this is not trivial and goes beyond the code itself.

Albert, Richard, Alain, I really appreciate your contribution towards this 
topic, it sometimes must look like I or other developers are not interested.
This is not the case, we are highly interested, still be are somehow blocked 
as well and I have tried to share some ideas why above.

All, how shall we should procede? There are some obvious ideas, but they also 
mean work in one or the other way.

Best,
Bernhard

-- 
Managing Director - Owner: www.intevation.net       (Free Software Company)
Germany Coordinator: fsfeurope.org. Coordinator: www.Kolab-Konsortium.com.
Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998
Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://kolab.org/pipermail/kolab-devel/attachments/20080912/28e318db/attachment-0001.bin

From liste at gelpi.it  Fri Sep 12 16:27:13 2008
From: liste at gelpi.it (Gelpi Andrea)
Date: Fri, 12 Sep 2008 16:27:13 +0200
Subject: [Kolab-devel] Kolab server 2.1.0 & bzip2 bug
Message-ID: <48CA7C41.7070602@gelpi.it>

Hi,
	during clamav upgrade on debian sarge I noted the following line messages

checking for CVE-2008-1372... bugged
configure: WARNING: ****** bzip2 libraries are affected by the CVE-2008-1372 bug
configure: WARNING: ****** We strongly suggest you to update to bzip2 1.0.5.
configure: WARNING: ****** Please do not report stability problems to the ClamAV developers!

I solved with these steps:

a) cd /kolab/RPM/SRC
b) Download bzip2-1.0.5-20080318.src.rpm from openpkg site
c) /kolab/bin/openpkg rpm --rebuild bzip2-1.0.5-20080318.src.rpm
d) /kolab/bin/openpkg rpm -Uvh ../PKG/bzip2-1.0.5-20080318.ix86-debian-kolab.rpm

I suggest to add it as a security patch

Regards,
-- 
ing. Andrea Gelpi
***************************************************
La Terra non la abbiamo ereditata dai nostri avi,
ma la abbiamo presa in prestito dai nostri bambini.
***************************************************
We do not inherit the Earth from our parents,
but borrow it from our children.
***************************************************


From wilde at intevation.de  Fri Sep 12 17:18:15 2008
From: wilde at intevation.de (Sascha Wilde)
Date: Fri, 12 Sep 2008 17:18:15 +0200
Subject: [Kolab-devel] Kolab Security Issue 22 (clamav)
In-Reply-To: <200809112239.02000.alex@ap-consulting.co.uk> (Alex Potter's
	message of "Thu, 11 Sep 2008 22:39:01 +0100")
References: <s7w63p24v7q.fsf@intevation.de>
	<200809112239.02000.alex@ap-consulting.co.uk>
Message-ID: <s7wprn9fl54.fsf@intevation.de>

Alex Potter <alex at ap-consulting.co.uk> writes:
> On Thursday 11 September 2008 15:23:53 Sascha Wilde wrote:
>> The package can be installed on your Kolab Server with
>>
>> # /kolab/bin/openpkg rpm --rebuild clamav-0.93.1-20080610_kolab.src.rpm
>> # /kolab/bin/openpkg rpm \
>>   -Uvh /kolab/RPM/PKG/clamav-0.93.1-20080610_kolab.<ARCH>-<OS>-kolab.rpm
>
> Minor nitpick: these instructions refer to the previous release...

Thanks for pointing this out.

Fixed this (as well as the release date in the time line) in CVS.  Will
be automatically updated on the Websites soon.

cheers
sascha
-- 
Sascha Wilde                                      OpenPGP key: 4BB86568
Intevation GmbH, Osnabr?ck             http://www.intevation.de/~wilde/
Amtsgericht Osnabr?ck, HR B 18998             http://www.intevation.de/
Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 188 bytes
Desc: not available
Url : http://kolab.org/pipermail/kolab-devel/attachments/20080912/591c6899/attachment.bin

From wilde at intevation.de  Fri Sep 12 18:07:35 2008
From: wilde at intevation.de (Sascha Wilde)
Date: Fri, 12 Sep 2008 18:07:35 +0200
Subject: [Kolab-devel] Bug in configure when building new clamav package
	from source rpm
In-Reply-To: <200809112243.38994.alex@ap-consulting.co.uk> (Alex Potter's
	message of "Thu, 11 Sep 2008 22:43:38 +0100")
References: <200809112243.38994.alex@ap-consulting.co.uk>
Message-ID: <s7wljxxfiuw.fsf@intevation.de>

Alex Potter <alex at ap-consulting.co.uk> writes:
> I noticed this while installing the clamav update at the configure stage of 
>
> 	`/kolab/bin/openpkg rpm --rebuild clamav-0.94-20080905_kolab.src.rpm`
>
> checking for CVE-2008-1372... bugged
> configure: WARNING: ****** bzip2 libraries are affected by the CVE-2008-1372 
> bug
> configure: WARNING: ****** We strongly suggest you to update to bzip2 1.0.5.

Thanks for .  I will try to make a security update for
bzip2 early next week...

cheers
sascha
-- 
Sascha Wilde                                      OpenPGP key: 4BB86568
Intevation GmbH, Osnabr?ck             http://www.intevation.de/~wilde/
Amtsgericht Osnabr?ck, HR B 18998             http://www.intevation.de/
Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 188 bytes
Desc: not available
Url : http://kolab.org/pipermail/kolab-devel/attachments/20080912/b4829ba7/attachment.bin

From bernhard at intevation.de  Fri Sep 12 18:13:01 2008
From: bernhard at intevation.de (Bernhard Reiter)
Date: Fri, 12 Sep 2008 18:13:01 +0200
Subject: [Kolab-devel] Kolab server 2.1.0 & bzip2 bug
In-Reply-To: <48CA7C41.7070602@gelpi.it>
References: <48CA7C41.7070602@gelpi.it>
Message-ID: <200809121813.02699.bernhard@intevation.de>

Andrea,
Alex,

On Friday 12 September 2008 16:27, Gelpi Andrea wrote:
> ????????during clamav upgrade on debian sarge I noted the following line
> messages
>
> checking for CVE-2008-1372... bugged
> configure: WARNING: ****** bzip2 libraries are affected by the
> CVE-2008-1372 bug configure: WARNING: ****** We strongly suggest you to
> update to bzip2 1.0.5.

thanks for pointing this out. I know Sascha is investigating it.

Best,
Bernhard

-- 
Managing Director - Owner: www.intevation.net       (Free Software Company)
Germany Coordinator: fsfeurope.org. Coordinator: www.Kolab-Konsortium.com.
Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998
Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://kolab.org/pipermail/kolab-devel/attachments/20080912/d2117653/attachment.bin

From ml at radoeka.nl  Fri Sep 12 21:56:39 2008
From: ml at radoeka.nl (Richard Bos)
Date: Fri, 12 Sep 2008 21:56:39 +0200
Subject: [Kolab-devel] Enhancing Kolab decision making(re: Is it okay to
	commit the samba patch to cvs?)
In-Reply-To: <200809120941.06039.bernhard@intevation.de>
References: <200809111755.13871.ml@radoeka.nl>
	<200809120941.06039.bernhard@intevation.de>
Message-ID: <200809122156.39912.ml@radoeka.nl>

Op Friday 12 September 2008 09:41:01 schreef Bernhard Reiter:
> Hi Richard,
>
> On Thursday 11 September 2008 17:55, Richard Bos wrote:
> >  I would
> > like to look at the samba patch that is provided in issue2997:
> > https://www.intevation.de/roundup/kolab/issue2997
> >
> > Is it okay to commit the patch to cvs? ?The code must be adapted to cvs
> > and some files must be added to a Makefile that I'll take care off. ?If
> > somebody finds the time to review the patch, I think that it is important
> > to look the ldap attribute definitions and perhaps the quality of the
> > code.
>
> thanks for the reminder. I am still trying to find a way to deal with
> larger proposals to extend Kolab Server (and Kolab as in Kolab Solution). I
> scanned the issue and the wiki page and what I am personally missing is an
> overview about the implications of making the change.
> This would include possible alternatives, for whom, which use cases are
> solved, why this technical approach was choosen on so on.
> Maybe we do need something like a KEP (Kolab Enhancement Proposal)
> going by the example of Python's PEPs: http://www.python.org/dev/peps/ .
> The problem is: How do we make decisions of this importance? How do we keep
> the design philosophy?

That would make things clearer from the start indeed.  Perhaps a KEP is too 
much, and perhaps it is sufficient to provide a template (or a wiki page) 
that contains the questions that you want to know.

> Any CVS person could commit, (including Richard), but none would take such
> a decison alone. Others have a hard time making up their mind, because they
> would need to take 3 hours or so out, to completely read through the
> material to be able to have a opinion on it.

I agree.  While working on issue2997 I was already afraid that someone would 
make a statement like the one above.

> For Samba, this has traditionally be orthogonal to Kolab Server and was
> integrated during project, because of the difference needs. 

I don't understand what  you want to say.  What do you mean?

> If we add 
> something to Kolab Server (and the Kolab Solution) this should cater almost
> all reasonable needs and it should not add complexity for non-samba users.

The current patch has a switch that enables or disables samba support.  For 
kolab this means that 2 functions are added and some if statements to 
determine whether samba support is enabled.  If it is enables data is written 
to the ldap database.  The current patch does not add complexity for 
non-samba users, it actually takes care that the same password can be used 
for kolab and samba (MS) logins, providing single sign on, which is a good 
thing if you ask me.  Everything else related to samba is AFAIK done with 
another GUI.

> Discussing this is not trivial and goes beyond the code itself.

You're making me curious, please elaborate.

> All, how shall we should procede? There are some obvious ideas, but they
> also mean work in one or the other way.

If I get the approval to commit the patch, I'll commit it.  But I need to get 
the approval first.  It looks like that the following questions need to be 
answered:

1) Implications of making the change (this would include possible 
alternatives)

2) For whom, which use cases are solved

3) Why this technical approach was choosen


Hopefully Albrecht wants to answers the questions.  Albrecht can you do that?

From my point of view there are the following answers:

1) Implications: the kolab team must support more code.  New ldap schemas are 
included.  No idea whether that is a problem or not.  More ldap attibutes are 
stored in ldap which could be accessed if the ACL is not correct.

2) It provides SSO (single sign on), which is very convenient for users.  
Hence making kolab even more attractive for companies :)


I hope this is a start to come to a decision about samba support in kolab.  


-- 
Richard Bos
We are borrowing the world of our children,
It is not inherited from our parents.


From kolab-issues at intevation.de  Sun Sep 14 07:32:58 2008
From: kolab-issues at intevation.de (wenzhuo)
Date: Sun, 14 Sep 2008 05:32:58 +0000
Subject: [Kolab-devel] [issue3036] cn = "givenName sn" ?
Message-ID: <1221370378.27.0.789894383249.issue3036@intevation.de>


New submission from wenzhuo <wenzhuo at zhmail.com>:

In kolab 2.2, the cn of a user account is defined as "givenName sn", which is
supposed to be the user's full name. This is not true for the following scenarios:

1. In East Asia, people don't use spaces to separate words. The full name of a
person is therefore written as $sn . $givenName (no space between surname and
givenName).

2. People may have a middle name in western cultures.

3. People may like being referred to as something other than their full names.

Therefore, I suggest adding a cn input to the "Create new user" page. It
defaults to "givenName sn", but can be changed to something else.

----------
messages: 16624
nosy: wenzhuo
priority: wish
status: unread
title: cn = "givenName sn" ?
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3036>
___________________________________________________


From bernhard at intevation.de  Mon Sep 15 10:37:41 2008
From: bernhard at intevation.de (Bernhard Reiter)
Date: Mon, 15 Sep 2008 10:37:41 +0200
Subject: [Kolab-devel] Enhancing Kolab decision making(re: Is it okay to
	commit the samba patch to cvs?)
In-Reply-To: <200809122156.39912.ml@radoeka.nl>
References: <200809111755.13871.ml@radoeka.nl>
	<200809120941.06039.bernhard@intevation.de>
	<200809122156.39912.ml@radoeka.nl>
Message-ID: <200809151037.42321.bernhard@intevation.de>

Hi,

On Friday 12 September 2008 21:56, Richard Bos wrote:
> > Maybe we do need something like a KEP (Kolab Enhancement Proposal)
> > going by the example of Python's PEPs: http://www.python.org/dev/peps/ .
> > The problem is: How do we make decisions of this importance? How do we
> > keep the design philosophy?
>
> That would make things clearer from the start indeed. ?Perhaps a KEP is too
> much, and perhaps it is sufficient to provide a template (or a wiki page)
> that contains the questions that you want to know.

this can be a start of something like a KEP process.
Questions will change with the proposal at hand and one important thing
is to have all the implication together as a summary and main arguments,
with pointers towards the detailed discussions.

> > Any CVS person could commit, (including Richard), but none would take
> > such a decison alone. Others have a hard time making up their mind,
> > because they would need to take 3 hours or so out, to completely read
> > through the material to be able to have a opinion on it.
>
> I agree. ?While working on issue2997 I was already afraid that someone
> would make a statement like the one above.

:)

> It looks like that the following questions need to
> be answered:
>
> 1) Implications of making the change (this would include possible
> alternatives)
>
> 2) For whom, which use cases are solved
>
> 3) Why this technical approach was choosen

All good questions.
1) might be split up into at least giving the reason why this is doing more 
good than bad. Security implications probably also should be discussed.

Bernhard



-- 
Managing Director - Owner: www.intevation.net       (Free Software Company)
Germany Coordinator: fsfeurope.org. Coordinator: www.Kolab-Konsortium.com.
Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998
Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://kolab.org/pipermail/kolab-devel/attachments/20080915/5a52f36d/attachment.bin

From bernhard at intevation.de  Mon Sep 15 10:54:10 2008
From: bernhard at intevation.de (Bernhard Reiter)
Date: Mon, 15 Sep 2008 10:54:10 +0200
Subject: [Kolab-devel] Samba KEP (Re: Enhancing Kolab decision making(re: Is
	it okay to commit the samba patch to cvs?))
In-Reply-To: <200809122156.39912.ml@radoeka.nl>
References: <200809111755.13871.ml@radoeka.nl>
	<200809120941.06039.bernhard@intevation.de>
	<200809122156.39912.ml@radoeka.nl>
Message-ID: <200809151054.15938.bernhard@intevation.de>

[This basically is the start of the samba Kolab Enhancement Proposal (KEP)]

On Friday 12 September 2008 21:56, Richard Bos wrote:
> > For Samba, this has traditionally be orthogonal to Kolab Server and was
> > integrated during project, because of the difference needs.
>
> I don't understand what ?you want to say. ?What do you mean?

Samba integration was done by several parties in the past. Usually as part
of a project for a customer or as integration into a special product,
e.g. Univention's UGS/UCS or Gonicus' Gosa.
Integration mainly meant integration into the directory server.
Kolab Server brings its own directory server, but customers tend to have their
own sometimes, so this again is a typical situation where Kolab Server has to 
be adapted to the existing directory server (may it be OpenLDAP or FDS or 
something else).

So my feeling is that customers may have different technicals needs towards
a directory service or a samba integration. In this case it might be a wise 
thing for Kolab Server not to offer a fixed integration, which might make it 
harder for someone to integrate their own, but offer the hooks only.
(This is what I call orthogonal, you could had or not add a feature to an 
installation, without interference of the Kolab Server (or minimal 
interference)).

This question is hard for me to decide: Am I improve Kolab Server by offering
an "example" Samba integration or am I making life harder for the majority
of users that would do their own integration anyway.
Not being an expert on Samba usage scenarios, this is where I would go 
next to make up my mind.

> > If we add
> > something to Kolab Server (and the Kolab Solution) this should cater
> > almost all reasonable needs and it should not add complexity for
> > non-samba users.
>
> The current patch has a switch that enables or disables samba support. ?For
> kolab this means that 2 functions are added and some if statements to
> determine whether samba support is enabled. ?If it is enables data is
> written to the ldap database. ?The current patch does not add complexity
> for non-samba users, 

Sounds good so far.

> it actually takes care that the same password can be 
> used for kolab and samba (MS) logins, providing single sign on, which is a
> good thing if you ask me.

Usually it is, but using weaker password algorithm on samba would lower 
security and raise requirements for any directory service too to write both 
passwords right? Do all Samba installations requires this NT password or 
could they go without?

> Everything else related to samba is AFAIK done with another GUI.

This sounds suboptimal. If I have a web admin which basically is a directory 
service client, why not handle Samba with it as well?

> > Discussing this is not trivial and goes beyond the code itself.
> You're making me curious, please elaborate.

The next point is one of the target group for Kolab Server users.
Any IT solution, just like Kolab or a competitor will not conquer the market
in one go. It better to first target specific markets.
So the question is: Will adding a feature (like Samba) help us to conquer 
the next market we would want to go for with Kolab and its Server?
Samba integration seems to be possible so the problem is not keeping anybody
from "buying" Kolab Server.

> If I get the approval to commit the patch, I'll commit it. ?But I need to
> get the approval first. 

Yes, somehow we need to beef up the decision process.
It also need to help us make up our minds about what do decide first.
I wrote about the decision process in my other email, this one is about Samba.

> Hopefully Albrecht wants to answers the questions. ?Albrecht can you do
> that?

It would be helpful indeed. You could also start a wiki-page or so for the KEP
doing a summary. We can try to find out of Univention and Gosa would be helped 
by the change as well and approaching them with a summary wiki-page
or a comitted KEP would be helpful in doing so.

> From my point of view there are the following answers:
>
> 1) Implications: the kolab team must support more code. ?New ldap schemas
> are included. ?No idea whether that is a problem or not. 

Any more code is adding weigth which is bad it inself, the question is
what we gain from it and how deep it is coupled.

> More ldap attibutes are stored in ldap which could be accessed 
> if the ACL is not correct.

> 2) It provides SSO (single sign on), which is very convenient for users. ?
> Hence making kolab even more attractive for companies :)

How compatible are we with the several ideas of SSO and the applications?

> I hope this is a start to come to a decision about samba support in kolab.

It certainly is, so thanks for progressing it. :)
Bernhard
 ?

-- 
Managing Director - Owner: www.intevation.net       (Free Software Company)
Germany Coordinator: fsfeurope.org. Coordinator: www.Kolab-Konsortium.com.
Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998
Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://kolab.org/pipermail/kolab-devel/attachments/20080915/3edde4b2/attachment.bin

From kolab-issues at intevation.de  Mon Sep 15 11:45:15 2008
From: kolab-issues at intevation.de (=?utf-8?q?Albrecht_Dre=C3=9F?=)
Date: Mon, 15 Sep 2008 09:45:15 +0000
Subject: [Kolab-devel] [issue3037] Free/Busy List interaction for Horde
	broken
Message-ID: <1221471915.27.0.642587601535.issue3037@intevation.de>


New submission from Albrecht Dre? <albrecht.dress at lios-tech.com>:

Symptoms:
The Free/Busy feature doesn't work if I create new users and *exclusively* use
Horde for appointments (neither Kontact nor Lookout through a connector). 
Specifically, for the /inviting/ user, the free/busy lists are displayed, but
for everyone /being invited/, the GUI simply says "not available" although the
user *has* other appointments during this period. 

The Apache log file says that the trigger is not available (HTTP 404 error):

kolab.my-domain.com - - [11/Sep/2008:15:12:35 +0200] "GET
/freebusy/trigger/test2 at my-domain.com/Kalender.xpfb HTTP/1.1" 404 386

The reason for this might be that the Apache config doesn't contain a rule for
xpfb files:

<snip>
RewriteRule ^/freebusy/trigger/(.+)\.pfb
%{DOCUMENT_ROOT}/freebusy/pfb.php?folder=$1&cache=0
RewriteRule ^/freebusy/(.+)\.pfb %{DOCUMENT_ROOT}/freebusy/pfb.php?folder=$1&cache=1
RewriteRule ^/freebusy/(.+)\.pxfb
%{DOCUMENT_ROOT}/freebusy/pfb.php?folder=$1&cache=1&extended=1
</snip>

However, pxfb files are covered...

----------
messages: 16632
nosy: albrecht.dress
priority: urgent
status: unread
title: Free/Busy List interaction for Horde broken
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3037>
___________________________________________________


From kolab-issues at intevation.de  Mon Sep 15 14:09:24 2008
From: kolab-issues at intevation.de (=?utf-8?q?Emanuel_Sch=C3=BCtze?=)
Date: Mon, 15 Sep 2008 12:09:24 +0000
Subject: [Kolab-devel] [issue3038] Kontact mac crashes when drag&drop a file
	attachment from mail
Message-ID: <1221480564.59.0.394431006459.issue3038@intevation.de>


New submission from Emanuel Sch?tze <emanuel at intevation.de>:

Try to move a email file attachment (per drag&drop) from email to e.g. desktop. 
-> Kontact crashed. Backtrace attached.

----------
assignedto: till
files: kontact-mac-crash-20080915-2_backtrace.txt
messages: 16636
nosy: emanuel, till
priority: urgent
status: unread
title: Kontact mac crashes when drag&drop a file attachment from mail
topic: kowi, macos
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3038>
___________________________________________________
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: kontact-mac-crash-20080915-2_backtrace.txt
Url: http://kolab.org/pipermail/kolab-devel/attachments/20080915/fdfa1b33/kontact-mac-crash-20080915-2_backtrace.txt

From kolab-issues at intevation.de  Mon Sep 15 14:14:16 2008
From: kolab-issues at intevation.de (=?utf-8?q?Emanuel_Sch=C3=BCtze?=)
Date: Mon, 15 Sep 2008 12:14:16 +0000
Subject: [Kolab-devel] [issue3039] Kontact mac: *.txt attachment only opens
	with Kwrite
Message-ID: <1221480856.1.0.699817953208.issue3039@intevation.de>


New submission from Emanuel Sch?tze <emanuel at intevation.de>:

Try to open an email txt-file attachment.
-> Only Kwrite available to open file. Where can I change the default app? 
("Save As" works fine.)

----------
assignedto: till
messages: 16638
nosy: emanuel, till
status: unread
title: Kontact mac: *.txt attachment only opens with Kwrite
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3039>
___________________________________________________


From kolab-issues at intevation.de  Mon Sep 15 14:51:14 2008
From: kolab-issues at intevation.de (=?utf-8?q?Emanuel_Sch=C3=BCtze?=)
Date: Mon, 15 Sep 2008 12:51:14 +0000
Subject: [Kolab-devel] [issue3040] Kontact mac: Scroll bar of the message
	preview pane moves attachment list
Message-ID: <1221483074.82.0.839702787811.issue3040@intevation.de>


New submission from Emanuel Sch?tze <emanuel at intevation.de>:

Show a mail with attachment(s) in Kmail's preview pane. 
Reduce the message preview pane so that a scroll bar comes visible.
The attachment list should be show below the preview pane should.

When you move the preview pane scroll bar the attachment list moves strange with
the scroll bar movement.

----------
assignedto: till
messages: 16639
nosy: emanuel, till
priority: bug
status: unread
title: Kontact mac: Scroll bar of the message preview pane moves attachment list
topic: kowi, macos
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3040>
___________________________________________________


From wrobel at pardus.de  Mon Sep 15 17:19:44 2008
From: wrobel at pardus.de (Gunnar Wrobel)
Date: Mon, 15 Sep 2008 17:19:44 +0200
Subject: [Kolab-devel] Samba KEP (Re: Enhancing Kolab
	decision	making(re: Is it okay to commit the samba patch to cvs?))
In-Reply-To: <200809151054.15938.bernhard@intevation.de>
References: <200809111755.13871.ml@radoeka.nl>
	<200809120941.06039.bernhard@intevation.de>
	<200809122156.39912.ml@radoeka.nl>
	<200809151054.15938.bernhard@intevation.de>
Message-ID: <20080915171944.12014zft5h1fnhss@webmail2.pardus.de>

Quoting "Bernhard Reiter" <bernhard at intevation.de>:

> [This basically is the start of the samba Kolab Enhancement Proposal (KEP)]
>
> On Friday 12 September 2008 21:56, Richard Bos wrote:
>> > For Samba, this has traditionally be orthogonal to Kolab Server and was
>> > integrated during project, because of the difference needs.
>>
>> I don't understand what  you want to say.  What do you mean?
>
> Samba integration was done by several parties in the past. Usually as part
> of a project for a customer or as integration into a special product,
> e.g. Univention's UGS/UCS or Gonicus' Gosa.
> Integration mainly meant integration into the directory server.
> Kolab Server brings its own directory server, but customers tend to  
> have their
> own sometimes, so this again is a typical situation where Kolab Server has to
> be adapted to the existing directory server (may it be OpenLDAP or FDS or
> something else).
>
> So my feeling is that customers may have different technicals needs towards
> a directory service or a samba integration. In this case it might be a wise
> thing for Kolab Server not to offer a fixed integration, which might make it
> harder for someone to integrate their own, but offer the hooks only.
> (This is what I call orthogonal, you could had or not add a feature to an
> installation, without interference of the Kolab Server (or minimal
> interference)).
>
> This question is hard for me to decide: Am I improve Kolab Server by offering
> an "example" Samba integration or am I making life harder for the majority
> of users that would do their own integration anyway.
> Not being an expert on Samba usage scenarios, this is where I would go
> next to make up my mind.
>
>> > If we add
>> > something to Kolab Server (and the Kolab Solution) this should cater
>> > almost all reasonable needs and it should not add complexity for
>> > non-samba users.
>>
>> The current patch has a switch that enables or disables samba support.  For
>> kolab this means that 2 functions are added and some if statements to
>> determine whether samba support is enabled.  If it is enables data is
>> written to the ldap database.  The current patch does not add complexity
>> for non-samba users,
>
> Sounds good so far.
>
>> it actually takes care that the same password can be
>> used for kolab and samba (MS) logins, providing single sign on, which is a
>> good thing if you ask me.
>
> Usually it is, but using weaker password algorithm on samba would lower
> security and raise requirements for any directory service too to write both
> passwords right? Do all Samba installations requires this NT password or
> could they go without?
>
>> Everything else related to samba is AFAIK done with another GUI.
>
> This sounds suboptimal. If I have a web admin which basically is a directory
> service client, why not handle Samba with it as well?
>
>> > Discussing this is not trivial and goes beyond the code itself.
>> You're making me curious, please elaborate.
>
> The next point is one of the target group for Kolab Server users.
> Any IT solution, just like Kolab or a competitor will not conquer the market
> in one go. It better to first target specific markets.
> So the question is: Will adding a feature (like Samba) help us to conquer
> the next market we would want to go for with Kolab and its Server?
> Samba integration seems to be possible so the problem is not keeping anybody
> from "buying" Kolab Server.

This sounds a little bit as if the suggested KEP process does not  
distinguish between a structural enhancement and an extension. I see  
that as an important difference.

If a KEP could suggest enhancing the Kolab Server with a specific  
application as an addon (e.g. the Open Ticket Request System (OTRS) or  
Munin as a monitoring tool) then the Kolab Konsortium would always  
have to ask: Does this have significant market value? Do we really  
want to add it? For any additional application additional testing is  
required.

But adding such extensions to the Kolab Server is already possible  
today. An experienced user could build OpenPKG extension packages  
(even if nobody does it yet and I consider this still way too  
complicated - but that is not the point here). So for such extensions  
I don't see the need for a KEP process as anybody could build and  
distribute packages without additional overhead.

But I consider KEPs relevant once we talk about structural changes to  
the core Kolab Server in order to *enable* specific additional  
extensions. This is of course the case for Samba. This is in fact a  
very good example of that. Adding this functionality won't be possible  
without some general hooks in the server that allow such an extension.

Do people agree that we should keep the focus for KEPs like this?

Cheers,

Gunnar

>
>> If I get the approval to commit the patch, I'll commit it.  But I need to
>> get the approval first.
>
> Yes, somehow we need to beef up the decision process.
> It also need to help us make up our minds about what do decide first.
> I wrote about the decision process in my other email, this one is  
> about Samba.
>
>> Hopefully Albrecht wants to answers the questions.  Albrecht can you do
>> that?
>
> It would be helpful indeed. You could also start a wiki-page or so  
> for the KEP
> doing a summary. We can try to find out of Univention and Gosa would  
> be helped
> by the change as well and approaching them with a summary wiki-page
> or a comitted KEP would be helpful in doing so.
>
>> From my point of view there are the following answers:
>>
>> 1) Implications: the kolab team must support more code.  New ldap schemas
>> are included.  No idea whether that is a problem or not.
>
> Any more code is adding weigth which is bad it inself, the question is
> what we gain from it and how deep it is coupled.
>
>> More ldap attibutes are stored in ldap which could be accessed
>> if the ACL is not correct.
>
>> 2) It provides SSO (single sign on), which is very convenient for  
>> users.  Hence making kolab even more attractive for companies :)
>
> How compatible are we with the several ideas of SSO and the applications?
>
>> I hope this is a start to come to a decision about samba support in kolab.
>
> It certainly is, so thanks for progressing it. :)
> Bernhard
>   --
> Managing Director - Owner: www.intevation.net       (Free Software Company)
> Germany Coordinator: fsfeurope.org. Coordinator: www.Kolab-Konsortium.com.
> Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998
> Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
>



-- 
____ http://www.pardus.de _________________ http://gunnarwrobel.de _

E-mail : p at rdus.de                                 Dr. Gunnar Wrobel
Tel.   : +49 700 6245 0000                         Bundesstrasse 29
Fax    : +49 721 1513 52322                        D-20146 Hamburg
--------------------------------------------------------------------
    >> Mail at ease - Rent a kolab groupware server at p at rdus <<
--------------------------------------------------------------------


----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.


From ml at radoeka.nl  Mon Sep 15 22:42:05 2008
From: ml at radoeka.nl (Richard Bos)
Date: Mon, 15 Sep 2008 22:42:05 +0200
Subject: [Kolab-devel] gunnar: server/patches/horde-webmail/1.2_rc1
	horde-webmail-1.2_rc1_kolab_openpkg.patch, NONE, 1.1
In-Reply-To: <20080915185801.0256460014F@lists.intevation.de>
References: <20080915185801.0256460014F@lists.intevation.de>
Message-ID: <200809152242.05813.ml@radoeka.nl>

Hi Gunnar,

Op Monday 15 September 2008 20:58:01 schreef cvs at kolab.org:
> Added Files:
> ????????horde-webmail-1.2_rc1_kolab_openpkg.patch
> Log Message:
> Added the patch for the new webmail release candidate. Horde was quick this
> time and we now have the release available that will be the basis for the
> next few Kolab server years. All native ports are encouraged to switch to
> ?horde-webmail-1.2.* as soon as possible.

Instead of all the seperate modules do you mean?  What is the advantage, less 
packaging?


-- 
Richard Bos
We are borrowing the world of our children,
It is not inherited from our parents.


From ml at radoeka.nl  Mon Sep 15 23:11:16 2008
From: ml at radoeka.nl (Richard Bos)
Date: Mon, 15 Sep 2008 23:11:16 +0200
Subject: [Kolab-devel] Samba KEP (Re: Enhancing Kolab decision
	making(re: Is it okay to commit the samba patch to cvs?))
In-Reply-To: <200809151054.15938.bernhard@intevation.de>
References: <200809111755.13871.ml@radoeka.nl>
	<200809122156.39912.ml@radoeka.nl>
	<200809151054.15938.bernhard@intevation.de>
Message-ID: <200809152311.16736.ml@radoeka.nl>

Op Monday 15 September 2008 10:54:10 schreef Bernhard Reiter:
> > it actually takes care that the same password can be
> > used for kolab and samba (MS) logins, providing single sign on, which is
> > a good thing if you ask me.
>
> Usually it is, but using weaker password algorithm on samba would lower
> security and raise requirements for any directory service too to write both
> passwords right? Do all Samba installations requires this NT password or
> could they go without?

With the samba patch, a password strongness check was added as well.  It has 
been moved to its seperate issue, but the samba solution is in this aspect 
better than kolab....

> > Everything else related to samba is AFAIK done with another GUI.
>
> This sounds suboptimal. If I have a web admin which basically is a
> directory service client, why not handle Samba with it as well?

That's true, but this makes it possible to first adapt the server and after 
that adapt the GUI is needed.

> > > Discussing this is not trivial and goes beyond the code itself.
> >
> > You're making me curious, please elaborate.
>
> The next point is one of the target group for Kolab Server users.
> Any IT solution, just like Kolab or a competitor will not conquer the
> market in one go. It better to first target specific markets.
> So the question is: Will adding a feature (like Samba) help us to conquer
> the next market we would want to go for with Kolab and its Server?
> Samba integration seems to be possible so the problem is not keeping
> anybody from "buying" Kolab Server.

But now at least 2 people needs to patch, and patch, and patch kolab to 
provide kolab support.  It shows that there is a desire to have kolab support 
samba.

> > If I get the approval to commit the patch, I'll commit it. ?But I need to
> > get the approval first.
>
> Yes, somehow we need to beef up the decision process.
> It also need to help us make up our minds about what do decide first.
> I wrote about the decision process in my other email, this one is about
> Samba.
[............]
> > 1) Implications: the kolab team must support more code. ?New ldap schemas
> > are included. ?No idea whether that is a problem or not.
>
> Any more code is adding weigth which is bad it inself, the question is
> what we gain from it and how deep it is coupled.

It prevents that at least 2 people need to patch kolab with every new release.  
Is 2 people the top of the iceberg or not?

> > More ldap attibutes are stored in ldap which could be accessed
> > if the ACL is not correct.
> >
> > 2) It provides SSO (single sign on), which is very convenient for users.
> > ? Hence making kolab even more attractive for companies :)
>
> How compatible are we with the several ideas of SSO and the applications?
>
> > I hope this is a start to come to a decision about samba support in
> > kolab.
>
> It certainly is, so thanks for progressing it. :)

I don't have the feeling that we are progressing at all with the issue at hand 
(2997).  It looks like that we need to develop a KEP, invite Univention and 
Gonicus to the table to ask for their view on samba integration with kolab.  
While all the folks that are working on issue2997 want to have their code 
integrated into kolab (I think).  I understand that a process is needed, but 
it's not something that I and I think Albrecht are going to setup and 
foster...  Now is the kolab core team going to setup a samba KEP and see if 
it works by e.g. getting Univention and Gonicus to provide information to the 
samba KEP.  I'm afraid that this is going to result in a dead lock situation 
situation, in which the issue2997 attributors must work out a KEP and the 
core team must setup a KEP.  In the end nothing would happen, which would be 
a pity as the current samba patch is quite nice!


-- 
Richard Bos
We are borrowing the world of our children,
It is not inherited from our parents.


From aspineux at gmail.com  Mon Sep 15 23:53:59 2008
From: aspineux at gmail.com (Alain Spineux)
Date: Mon, 15 Sep 2008 23:53:59 +0200
Subject: [Kolab-devel] Enhancing Kolab decision making(re: Is it okay to
	commit the samba patch to cvs?)
In-Reply-To: <200809151037.42321.bernhard@intevation.de>
References: <200809111755.13871.ml@radoeka.nl>
	<200809120941.06039.bernhard@intevation.de>
	<200809122156.39912.ml@radoeka.nl>
	<200809151037.42321.bernhard@intevation.de>
Message-ID: <71fe4e760809151453p10f6b727u223f7352b9c3c818@mail.gmail.com>

Bernhard asked my advice about the inclusion of this patch in CVS .... :

As I say for long time now, I'm more in favor of a plugin interface than
the inclusion of any Samba's specific code into Kolab.

The pros and cons of the plugin architecture :

- require more code than the simple Samba's specific patch
+ the plugin architecture could be helpful to future Kolab's plugin
projects ( Asterisk integration, black and grey listing, ....)
+ The two projects (kolab and the samba plugin) will be able to
evolute independently. Changes in one will not automatically implies
change in the other. This is true for bug too.

For remember the Kolab's plugin interface should contains a least :
- some kolab's perl and PHP "function helper", "
- some php "hooks" to add screen and functionalities to the admin interface,
- some "hook" from inside the kolabd and the template generation ?process

Regards


-- 
Alain Spineux
aspineux gmail com
May the sources be with you


From kolab-issues at intevation.de  Tue Sep 16 03:33:38 2008
From: kolab-issues at intevation.de (Maude Rosa)
Date: Tue, 16 Sep 2008 01:33:38 +0000
Subject: [Kolab-devel] [issue3041] no obtain
Message-ID: <001201c91783$d80dafa0$06a1d3bc@CPD>


New submission from Maude Rosa <tkbhypothesis at 9zero9.com>:

products, or real estate. They would not find it useful to medium tool would be an added skill to other artists like myself. 
Multinational companies are now known as Global companies.This

----------
messages: 16644
nosy: tkbhypothesis
status: unread
title: no obtain
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3041>
___________________________________________________


From wrobel at pardus.de  Tue Sep 16 05:29:53 2008
From: wrobel at pardus.de (Gunnar Wrobel)
Date: Tue, 16 Sep 2008 05:29:53 +0200
Subject: [Kolab-devel] Packaging of the Kolab web client (Horde) (was: Re:
	gunnar:
	server/patches/horde-webmail/1.2_rc1	horde-webmail-1.2_rc1_kolab_openpkg.patch,
	NONE, 1.1)
In-Reply-To: <200809152242.05813.ml@radoeka.nl>
References: <20080915185801.0256460014F@lists.intevation.de>
	<200809152242.05813.ml@radoeka.nl>
Message-ID: <20080916052953.79386h4td6eirk00@webmail2.pardus.de>

Quoting Richard Bos <ml at radoeka.nl>:

> Hi Gunnar,
>
> Op Monday 15 September 2008 20:58:01 schreef cvs at kolab.org:
>> Added Files:
>>         horde-webmail-1.2_rc1_kolab_openpkg.patch
>> Log Message:
>> Added the patch for the new webmail release candidate. Horde was quick this
>> time and we now have the release available that will be the basis for the
>> next few Kolab server years. All native ports are encouraged to switch to
>>  horde-webmail-1.2.* as soon as possible.
>
> Instead of all the seperate modules do you mean?

Yes.

> What is the advantage, less packaging?

Yes that is one part.

In addition the patch handling is way easier. One Kolab specific patch  
for Horde and that's it.

This is strongly against my personal Gentoo nature :) but I believe it  
is a significantly easier approach for all parties involved.

Usually in packaging you would try to break the functionality down  
into the different existing pieces (like the PEAR packages in the  
Horde framework + horde + kronolith + imp + ...) and ensure the  
dependencies are correct. This is much less bloat for the user and  
allows for more flexibility.

In fact I'm using the splitted approach for the other sections of the  
Kolab Server. Kolab free/busy and the Kolab mail filters will be based  
on pure PEAR packages from upstream in the next Kolab Server release.  
That is what I commited into server/pear in CVS recently. Here I feel  
the splitted approach is better as it allows us to only install a  
third of the Horde framework instead of the whole thing which is  
actually also not distributed by upstream (there is only Horde base +  
framework).

But concerning the Kolab web client I believe it will be easier if we  
can tell people that there is this one horde-webmail package and you  
can just install it on your webserver, add the Kolab specific patch  
and configure it for your Kolab server. Instead of having seven or  
eight different applications with about fifteen patches.

The patches are of course still available in their separate form as I  
generate the combined patch from the sources at  
http://hg.pardus.de/cgi-bin/hg.cgi/horde/HORDE/. You have to know a  
little bit about Mercurial queues though in order to grasp how I  
manage the patches for the different Horde branches I'm working on.

I made this comment a little bit more elaborate as I would like to see  
the native ports to switch over to horde-webmail so that we have a  
common base. The Gentoo users already have the kolabified  
horde-webmail available in the main distribution, Univention switched  
also, and OpenPKG will have it in the next release.

Cheers,

Gunnar


>
>
> --
> Richard Bos
> We are borrowing the world of our children,
> It is not inherited from our parents.
>
> _______________________________________________
> Kolab-devel mailing list
> Kolab-devel at kolab.org
> https://kolab.org/mailman/listinfo/kolab-devel
>



-- 
____ http://www.pardus.de _________________ http://gunnarwrobel.de _

E-mail : p at rdus.de                                 Dr. Gunnar Wrobel
Tel.   : +49 700 6245 0000                         Bundesstrasse 29
Fax    : +49 721 1513 52322                        D-20146 Hamburg
--------------------------------------------------------------------
    >> Mail at ease - Rent a kolab groupware server at p at rdus <<
--------------------------------------------------------------------


----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.


From ml at radoeka.nl  Tue Sep 16 21:32:07 2008
From: ml at radoeka.nl (Richard Bos)
Date: Tue, 16 Sep 2008 21:32:07 +0200
Subject: [Kolab-devel] Enhancing Kolab decision making(re: Is it okay to
	commit the samba patch to cvs?)
In-Reply-To: <71fe4e760809151453p10f6b727u223f7352b9c3c818@mail.gmail.com>
References: <200809111755.13871.ml@radoeka.nl>
	<200809151037.42321.bernhard@intevation.de>
	<71fe4e760809151453p10f6b727u223f7352b9c3c818@mail.gmail.com>
Message-ID: <200809162132.07436.ml@radoeka.nl>

Hi,

Op Monday 15 September 2008 23:53:59 schreef Alain Spineux:
> Bernhard asked my advice about the inclusion of this patch in CVS .... :
>
> As I say for long time now, I'm more in favor of a plugin interface than
> the inclusion of any Samba's specific code into Kolab.
>
> The pros and cons of the plugin architecture :
>
> - require more code than the simple Samba's specific patch
> + the plugin architecture could be helpful to future Kolab's plugin
> projects ( Asterisk integration, black and grey listing, ....)
> + The two projects (kolab and the samba plugin) will be able to
> evolute independently. Changes in one will not automatically implies
> change in the other. This is true for bug too.
>
> For remember the Kolab's plugin interface should contains a least :
> - some kolab's perl and PHP "function helper", "
> - some php "hooks" to add screen and functionalities to the admin
> interface, - some "hook" from inside the kolabd and the template generation
> ?process

Let me put it this way: let us know when the plugin interface is available we 
can than use it to add the samba functionality.

Of course a plugin interface would be nice, but it is not here and I think 
that it will take a long (very long) time till it arrives.  Now with regards 
to the samba patch, it is of course possible to wait till the plugin 
interface arrives or as the patch is about ready to be committed to cvs that 
could be done as well.  If one waits long enough the current patch can't be 
committed anymore as the sources in cvs will have changed and a nice 
oppertunity will have passed to include some samba functionality.  The kolab 
devs could of course state that the patch will be included if someone 
provides the plugin structure, hoping that e.g. Albrecht or Christian (the 
samba patch providers) will provide the plugin structure.  But Albrecht e.g. 
already stated that he won't customize the patch further, so forget he'll 
provide a plugin structure...

Let's see what difficulties we run into if the samba patch would be made a 
plugin:

The patch provides a template file (samba.php.template.in).  So it needs to be 
build.  This makes it already much less attractive as a plain plugin.  The 
samba.php include file much be included in the file www/admin/user/user.php.  
How should happen with a plugin structure?  Should there be 
a /usr/lib/php/kolab/plugins directory? Should all the php files in that 
directory be included in the www/admin/user/user.php?  Or should the plugin 
have a kind of  include tag that states that it should be included in 
user.php?  This is I believe still the easy part.  Next is that the plugin 
should be triggered when a new user is saved, or removed and when the 
password is saved.  How is that to be done?  Here some smart plugin mechanism 
needs to be developed.

Next is the slapd.conf.template; 2 schema's have to be included, some indexing 
keys are defined and new acl's are added.  The latter can be achieved when 
kolab is going to use the new openldap configuration method (what is it 
called Real Time Configuration, I believe).  The plugin openldap stuff can 
just be dumped in the RTC openldap directory.  I don't believe that the 
plugin additions can be easily added to the current slapd.conf file.

Last for this patch is the addition of variables to kolab.conf.  This can be 
achieved when kolab is going to use a conf.d (/etc/kolab/conf.d) directory.  
Plugins could just dump their variable definitions there and kolabconf would 
read them.

For the RTC slapd.conf there is already an issue.  For all the other 
challenges there isn't.

Perhaps issues should be opened for the ideas mentioned above (and that others 
agree with).  But I also think it shows that the plugin interface is not 
available for a long time.  Hence the samba patch should be committed to cvs 
the way it is now available, if it is to be accepted by the kolab devs at 
all.

My 2ct.


-- 
Richard Bos
We are borrowing the world of our children,
It is not inherited from our parents.


From ml at radoeka.nl  Tue Sep 16 22:00:16 2008
From: ml at radoeka.nl (Richard Bos)
Date: Tue, 16 Sep 2008 22:00:16 +0200
Subject: [Kolab-devel] Packaging of the Kolab web client (Horde)
In-Reply-To: <20080916052953.79386h4td6eirk00@webmail2.pardus.de>
References: <20080915185801.0256460014F@lists.intevation.de>
	<200809152242.05813.ml@radoeka.nl>
	<20080916052953.79386h4td6eirk00@webmail2.pardus.de>
Message-ID: <200809162200.16292.ml@radoeka.nl>

Op Tuesday 16 September 2008 05:29:53 schreef Gunnar Wrobel:
> Quoting Richard Bos <ml at radoeka.nl>:
> > Hi Gunnar,
> >
> > Op Monday 15 September 2008 20:58:01 schreef cvs at kolab.org:
> >> Added Files:
> >>         horde-webmail-1.2_rc1_kolab_openpkg.patch
> >> Log Message:
> >> Added the patch for the new webmail release candidate. Horde was quick
> >> this time and we now have the release available that will be the basis
> >> for the next few Kolab server years. All native ports are encouraged to
> >> switch to horde-webmail-1.2.* as soon as possible.
> >
> > Instead of all the seperate modules do you mean?
>
> Yes.
>
> > What is the advantage, less packaging?
>
> Yes that is one part.
>
> In addition the patch handling is way easier. One Kolab specific patch
> for Horde and that's it.
>
> This is strongly against my personal Gentoo nature :) but I believe it
> is a significantly easier approach for all parties involved.

Sounds good indeed.  I had a look at the patch, and there are some changes 
that you make against the horde lib/core/app code.  Are these changes 
provided upstream, or are they really kolab specific?  I'm not talking about 
the $conf[''] changes, but e.g. the lines between:
if ($GLOBALS['conf']['kolab']['enabled']) {
}
and the changes to Horde/iCalendar.php or lib/SyncML/Backend.php, etc.


[............]

> I made this comment a little bit more elaborate as I would like to see
> the native ports to switch over to horde-webmail so that we have a
> common base. The Gentoo users already have the kolabified
> horde-webmail available in the main distribution, Univention switched
> also, and OpenPKG will have it in the next release.

Having to apply one patch is convincing enough ;)

-- 
Richard Bos
We are borrowing the world of our children,
It is not inherited from our parents.


From aspineux at gmail.com  Wed Sep 17 01:49:25 2008
From: aspineux at gmail.com (Alain Spineux)
Date: Wed, 17 Sep 2008 01:49:25 +0200
Subject: [Kolab-devel] Enhancing Kolab decision making(re: Is it okay to
	commit the samba patch to cvs?)
In-Reply-To: <200809162132.07436.ml@radoeka.nl>
References: <200809111755.13871.ml@radoeka.nl>
	<200809151037.42321.bernhard@intevation.de>
	<71fe4e760809151453p10f6b727u223f7352b9c3c818@mail.gmail.com>
	<200809162132.07436.ml@radoeka.nl>
Message-ID: <71fe4e760809161649o205f59a1p9a3bda7ef48d8531@mail.gmail.com>

On Tue, Sep 16, 2008 at 9:32 PM, Richard Bos <ml at radoeka.nl> wrote:
> Hi,
>
> Op Monday 15 September 2008 23:53:59 schreef Alain Spineux:
>> Bernhard asked my advice about the inclusion of this patch in CVS .... :
>>
>> As I say for long time now, I'm more in favor of a plugin interface than
>> the inclusion of any Samba's specific code into Kolab.
>>
>> The pros and cons of the plugin architecture :
>>
>> - require more code than the simple Samba's specific patch
>> + the plugin architecture could be helpful to future Kolab's plugin
>> projects ( Asterisk integration, black and grey listing, ....)
>> + The two projects (kolab and the samba plugin) will be able to
>> evolute independently. Changes in one will not automatically implies
>> change in the other. This is true for bug too.
>>
>> For remember the Kolab's plugin interface should contains a least :
>> - some kolab's perl and PHP "function helper", "
>> - some php "hooks" to add screen and functionalities to the admin
>> interface, - some "hook" from inside the kolabd and the template generation
>> ?process
>
> Let me put it this way: let us know when the plugin interface is available we
> can than use it to add the samba functionality.

Any already working program is better than any nice idea to come :-)

>
> Of course a plugin interface would be nice, but it is not here and I think
> that it will take a long (very long) time till it arrives.  Now with regards
> to the samba patch, it is of course possible to wait till the plugin
> interface arrives or as the patch is about ready to be committed to cvs that
> could be done as well.  If one waits long enough the current patch can't be
> committed anymore as the sources in cvs will have changed and a nice
> oppertunity will have passed to include some samba functionality.  The kolab
> devs could of course state that the patch will be included if someone
> provides the plugin structure, hoping that e.g. Albrecht or Christian (the
> samba patch providers) will provide the plugin structure.  But Albrecht e.g.
> already stated that he won't customize the patch further, so forget he'll
> provide a plugin structure...

Add and maintain a plugins interface seem to be more acceptable to the
Kolab's team than add a Samba patch. The plugin structure looks more
realistic from Kolab's point of view.
Of course the plugin interface is not needed by the kolab's and
samba's to work together !
And the patch is already available. Congratulation !

If I was a kolab's core developer I would have rejected the Samba patch, but
would have encouraged it as a product manager.

>
> Let's see what difficulties we run into if the samba patch would be made a
> plugin:

You expose some technical difficulties, I try to give a way to solve them !

>
> The patch provides a template file (samba.php.template.in).  So it needs to be
> build.

Build it at plugin installation time, using variable available in
kolab.conf and kolab.global

> This makes it already much less attractive as a plain plugin.  The
> samba.php include file much be included in the file www/admin/user/user.php.
> How should happen with a plugin structure?  Should there be
> a /usr/lib/php/kolab/plugins directory? Should all the php files in that
> directory be included in the www/admin/user/user.php?  Or should the plugin
> have a kind of  include tag that states that it should be included in
> user.php?  This is I believe still the easy part.  Next is that the plugin
> should be triggered when a new user is saved, or removed and when the
> password is saved.  How is that to be done?  Here some smart plugin mechanism
> needs to be developed.

squirrelmail is mostly made of plugins !
Any plugin live in a subdirectory in /kolab/share/squirrelmail/plugins/
in this directory you find a least one file called setup.php that is
called by the main
squirellmail code and that add "hooks" to the squirrelmail core

Here is a small part of /kolab/share/squirrelmail/plugins/check_quota/setup.php

function squirrelmail_plugin_init_check_quota()
{
  global $squirrelmail_plugin_hooks;
  $squirrelmail_plugin_hooks['left_main_before']['check_quota']
    = 'check_quota_graph_before_do';
....

This will ask squirellmail to call check_quota_graph_before_do when drawing
part of the left panel.  check_quota_graph_before_do will generate
HTML code required to draw the "quota" bare

That's the idea for php extension

>
> Next is the slapd.conf.template; 2 schema's have to be included, some indexing

The plugins can add samba.schema into /kolab/etc/openldap/schema and insert line

include /kolab/etc/openldap/schema/horde.schema

into the slapd.conf.template file  at install time

> keys are defined and new acl's are added.  The latter can be achieved when
> kolab is going to use the new openldap configuration method (what is it
> called Real Time Configuration, I believe).  The plugin openldap stuff can
> just be dumped in the RTC openldap directory.  I don't believe that the
> plugin additions can be easily added to the current slapd.conf file.

The RTC could help

>
> Last for this patch is the addition of variables to kolab.conf.  This can be
> achieved when kolab is going to use a conf.d (/etc/kolab/conf.d) directory.
> Plugins could just dump their variable definitions there and kolabconf would
> read them.

use of conf.d directory is a nice solution

>
> For the RTC slapd.conf there is already an issue.  For all the other
> challenges there isn't.
>
> Perhaps issues should be opened for the ideas mentioned above (and that others
> agree with).  But I also think it shows that the plugin interface is not
> available for a long time.  Hence the samba patch should be committed to cvs
> the way it is now available, if it is to be accepted by the kolab devs at
> all.
>
> My 2ct.

With my, this is now 4ct.

Regards.

>
>
> --
> Richard Bos
> We are borrowing the world of our children,
> It is not inherited from our parents.
>
> _______________________________________________
> Kolab-devel mailing list
> Kolab-devel at kolab.org
> https://kolab.org/mailman/listinfo/kolab-devel
>



-- 
Alain Spineux
aspineux gmail com
May the sources be with you


From kolab-issues at intevation.de  Wed Sep 17 10:39:38 2008
From: kolab-issues at intevation.de (Ludwig Reiter)
Date: Wed, 17 Sep 2008 08:39:38 +0000
Subject: [Kolab-devel] [issue3042] The "New Message" button doesn't open a
	composer
Message-ID: <1221640778.6.0.409263779305.issue3042@intevation.de>


New submission from Ludwig Reiter <ludwig at intevation.de>:

enterprise4 Windows
Kontact-Installer_20080916.exe(kdepimlibs: 860269, kdepim: 861200)

In the kmail-plugin the toolbar button "New Message" does not open a composer.
It just freeze kontact for a moment.
<Ctrl>+N doesn't work, too.

----------
assignedto: till
messages: 16654
nosy: bh, jstaniek, ludwig, till
priority: urgent
status: unread
title: The "New Message" button doesn't open a composer
topic: kde client, kowi
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3042>
___________________________________________________


From bernhard at intevation.de  Wed Sep 17 10:48:25 2008
From: bernhard at intevation.de (Bernhard Reiter)
Date: Wed, 17 Sep 2008 10:48:25 +0200
Subject: [Kolab-devel] Enhancing Kolab decision making(re: Is it okay to
	commit the samba patch to cvs?)
In-Reply-To: <71fe4e760809151453p10f6b727u223f7352b9c3c818@mail.gmail.com>
References: <200809111755.13871.ml@radoeka.nl>
	<200809151037.42321.bernhard@intevation.de>
	<71fe4e760809151453p10f6b727u223f7352b9c3c818@mail.gmail.com>
Message-ID: <200809171048.27120.bernhard@intevation.de>

Alain,

On Monday 15 September 2008 23:53, Alain Spineux wrote:
> As I say for long time now, I'm more in favor of a plugin interface than
> the inclusion of any Samba's specific code into Kolab.

A plug-in interface to Kolab Server certainly would be nice,
it would be a KEP by itself I guess. :)

What do you think about the decision processes?

Bernhard

-- 
Managing Director - Owner: www.intevation.net       (Free Software Company)
Germany Coordinator: fsfeurope.org. Coordinator: www.Kolab-Konsortium.com.
Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998
Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://kolab.org/pipermail/kolab-devel/attachments/20080917/b157a151/attachment.bin

From bernhard at intevation.de  Wed Sep 17 10:54:54 2008
From: bernhard at intevation.de (Bernhard Reiter)
Date: Wed, 17 Sep 2008 10:54:54 +0200
Subject: [Kolab-devel]
	=?utf-8?q?Samba_KEP_=28Re=3A_Enhancing_Kolab_decisi?=
	=?utf-8?q?on=09making_=28re=3A_Is_it_okay_to_commit_the_samba_patc?=
	=?utf-8?b?aCB0byBjdnM/KSk=?=
In-Reply-To: <20080915171944.12014zft5h1fnhss@webmail2.pardus.de>
References: <200809111755.13871.ml@radoeka.nl>
	<200809151054.15938.bernhard@intevation.de>
	<20080915171944.12014zft5h1fnhss@webmail2.pardus.de>
Message-ID: <200809171054.55089.bernhard@intevation.de>

On Monday 15 September 2008 17:19, Gunnar Wrobel wrote:
> > The next point is one of the target group for Kolab Server users.
> > Any IT solution, just like Kolab or a competitor will not conquer the
> > market in one go. It better to first target specific markets.
> > So the question is: Will adding a feature (like Samba) help us to conquer
> > the next market we would want to go for with Kolab and its Server?
> > Samba integration seems to be possible so the problem is not keeping
> > anybody from "buying" Kolab Server.
>
> This sounds a little bit as if the suggested KEP process does not ?
> distinguish between a structural enhancement and an extension. I see ?
> that as an important difference.

A good remark!

> If a KEP could suggest enhancing the Kolab Server with a specific ?
> application as an addon (e.g. the Open Ticket Request System (OTRS) or ?
> Munin as a monitoring tool) then the Kolab Konsortium would always ?
> have to ask: Does this have significant market value? Do we really ?
> want to add it? For any additional application additional testing is ?
> required.
>
> But adding such extensions to the Kolab Server is already possible ?
> today. An experienced user could build OpenPKG extension packages ?
> (even if nobody does it yet and I consider this still way too ?
> complicated - but that is not the point here). So for such extensions ?
> I don't see the need for a KEP process as anybody could build and ?
> distribute packages without additional overhead.

Still there is the decision whether this should come with the default
Kolab Server/OpenPKG distribution ...
One value of Kolab Server has been its integrated testing.
(This has been relaxed a bit with the Webklient now being in Beta,
but still part of the Kolab Server/OpenPKG release.)

The idea to have add-ons with a different support or maturity levels
still is a good one, but of course we are lacking structure, concept
and all this for it right now.

> But I consider KEPs relevant once we talk about structural changes to ?
> the core Kolab Server in order to *enable* specific additional ?
> extensions. This is of course the case for Samba. This is in fact a ?
> very good example of that. Adding this functionality won't be possible ?
> without some general hooks in the server that allow such an extension.
>
> Do people agree that we should keep the focus for KEPs like this?

The question of inclusion in the core distribution needs to be a KEP as well.
A proposal is needed if the effects of a decision is potentially large.
Creating extensions in a certain way can have such a large effect, 
even when it is decided to not to pick them up for distribution as Kolab 
development community.

I agree that a KEP should clearly state what its goal is of course! :)

Best,
Bernhard
-- 
Managing Director - Owner: www.intevation.net       (Free Software Company)
Germany Coordinator: fsfeurope.org. Coordinator: www.Kolab-Konsortium.com.
Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998
Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://kolab.org/pipermail/kolab-devel/attachments/20080917/73195f18/attachment-0001.bin

From bernhard at intevation.de  Wed Sep 17 11:03:50 2008
From: bernhard at intevation.de (Bernhard Reiter)
Date: Wed, 17 Sep 2008 11:03:50 +0200
Subject: [Kolab-devel] Samba KEP (Re: Enhancing Kolab decision
	making(re: Is it okay to commit the samba patch to cvs?))
In-Reply-To: <200809152311.16736.ml@radoeka.nl>
References: <200809111755.13871.ml@radoeka.nl>
	<200809151054.15938.bernhard@intevation.de>
	<200809152311.16736.ml@radoeka.nl>
Message-ID: <200809171103.51724.bernhard@intevation.de>

On Monday 15 September 2008 23:11, Richard Bos wrote:
> > The next point is one of the target group for Kolab Server users.
> > Any IT solution, just like Kolab or a competitor will not conquer the
> > market in one go. It better to first target specific markets.
> > So the question is: Will adding a feature (like Samba) help us to conquer
> > the next market we would want to go for with Kolab and its Server?
> > Samba integration seems to be possible so the problem is not keeping
> > anybody from "buying" Kolab Server.
>
> But now at least 2 people needs to patch, and patch, and patch kolab to
> provide kolab support. ?It shows that there is a desire to have kolab
> support samba.

Maybe them not needing to patch would increase the efforts for other to patch.
Okay, those others are not explicitely named in the discussion - yet.

> > It certainly is, so thanks for progressing it. :)
>
> I don't have the feeling that we are progressing at all with the issue at
> hand (2997). 

Each argument in the open is progress.
If the arguments are on the non-technical side, 
this is something which is common to many decision and update processes.
So yes, I believe there is progress, even when it is only in my mind.
As a community we need to develop ways to deal with this and we do have a 
backlog.

> It looks like that we need to develop a KEP, invite 
> Univention and Gonicus to the table to ask for their view on samba
> integration with kolab. While all the folks that are working on issue2997
> want to have their code integrated into kolab (I think). ?I understand that
> a process is needed,

Again progress. :)

> but it's not something that I and I think Albrecht are 
> going to setup and foster... ?Now is the kolab core team 

I consider you and Marcus part of the core team. Of course I respect if you do 
not want or can set up such a process. I am just trying to make this all more 
explicit. Other Kolab Server developers like Thomas should also not do such a 
large change without consulting with others. And it fact we did not do large 
changes for a longer time. That is one symtom of the problem to me.

> going to setup a 
> samba KEP and see if it works by e.g. getting Univention and Gonicus to
> provide information to the samba KEP. ?I'm afraid that this is going to
> result in a dead lock situation situation, in which the issue2997
> attributors must work out a KEP and the core team must setup a KEP. ?In the
> end nothing would happen, which would be a pity as the current samba patch
> is quite nice!

I want something to happen and yes I am taking this issue as occasion
to point out to the larger problem we (as a community) have.
Possible deadlock is a problem of any process.

The problem I have with just dealing with the issue is 
that we would set precedent and the pile of other issues is getting higher in 
the end. So an improvement in the process should be our priority to get things 
moving. Note I am not interesting in getting buerocracy build up, but in a 
good decision. I think we should produce a summary discussion and then 
approach Univention and others, seek opinions and decide.

Bernhard 

-- 
Managing Director - Owner: www.intevation.net       (Free Software Company)
Germany Coordinator: fsfeurope.org. Coordinator: www.Kolab-Konsortium.com.
Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998
Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://kolab.org/pipermail/kolab-devel/attachments/20080917/71cdebbd/attachment.bin

From kolab-issues at intevation.de  Wed Sep 17 12:03:11 2008
From: kolab-issues at intevation.de (Ludwig Reiter)
Date: Wed, 17 Sep 2008 10:03:11 +0000
Subject: [Kolab-devel] [issue3043] Configuration of a second dimap account
	freezes kontact
Message-ID: <1221645791.43.0.687974033604.issue3043@intevation.de>


New submission from Ludwig Reiter <ludwig at intevation.de>:

enterprise4 Windows
Kontact-Installer_20080916.exe(kdepimlibs: 860269, kdepim: 861200)

Test:
1. Restart kontact without any old kde processes.
2. Switch to Kmail.
3. Configure a new imap account. Set: "Save IMAP password".
=> After prssing okay, a kwallet dialog pops up.
4. Enter a password twice and press okay.
=> The configuration dialog stays in front the main window and freezes.
It is possible to close kontact.

----------
assignedto: till
messages: 16659
nosy: bh, jstaniek, ludwig, till
priority: bug
status: unread
title: Configuration of a second dimap account freezes kontact
topic: kde client, kowi
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3043>
___________________________________________________


From kolab-issues at intevation.de  Wed Sep 17 12:38:00 2008
From: kolab-issues at intevation.de (Ludwig Reiter)
Date: Wed, 17 Sep 2008 10:38:00 +0000
Subject: [Kolab-devel] [issue3044] A kontact's "section" is not saved.
Message-ID: <1221647880.39.0.951993260788.issue3044@intevation.de>


New submission from Ludwig Reiter <ludwig at intevation.de>:

enterprise4 Windows
Kontact-Installer_20080916.exe(kdepimlibs: 860269, kdepim: 861200)

Test:
1. Switch to Addressbook.
2. Start to create a new kontact.
   Enter a section under details->section.(e.g. "test lab")
3. Sync.
A reopening of the kontact shows, that the section is not saved.

----------
assignedto: till
messages: 16660
nosy: bh, jstaniek, ludwig, till
priority: minor bug
status: unread
title: A kontact's "section" is not saved.
topic: kde client, kowi
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3044>
___________________________________________________


From kolab-issues at intevation.de  Thu Sep 18 12:46:52 2008
From: kolab-issues at intevation.de (Ludwig Reiter)
Date: Thu, 18 Sep 2008 10:46:52 +0000
Subject: [Kolab-devel] [issue3045] A valid signature is not recognized.
Message-ID: <1221734812.44.0.76234967572.issue3045@intevation.de>


New submission from Ludwig Reiter <ludwig at intevation.de>:

enterprise4 Windows
Kontact-Installer_20080916.exe(kdepimlibs: 860269, kdepim: 861200)
gpg4win-1.9.7-beta.exe

Test:
1. Create an openPGP  secret key.
2. Import a public key of a test account.
3. Sign the public key with the secret key.
4. The test account sends a signatured mail to the user.
5. Look at the mail.
=> The signature is yellow, because the valid signature is not recognized by
kontact.

----------
assignedto: till
messages: 16676
nosy: bh, jstaniek, ludwig, till
priority: bug
status: unread
title: A valid signature is not recognized.
topic: kde client, kowi
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3045>
___________________________________________________


From kolab-issues at intevation.de  Thu Sep 18 12:56:25 2008
From: kolab-issues at intevation.de (Ludwig Reiter)
Date: Thu, 18 Sep 2008 10:56:25 +0000
Subject: [Kolab-devel] [issue3046] freebusy list show wrong event.
Message-ID: <1221735385.78.0.725120749217.issue3046@intevation.de>


New submission from Ludwig Reiter <ludwig at intevation.de>:

enterprise4 Windows
Kontact-Installer_20080916.exe(kdepimlibs: 860269, kdepim: 861200)

Test:
1. Create a test event.
2. Sync
3. Start to create another test event and look at the freebusy list.
=> The event is at a wrong time.

----------
assignedto: till
messages: 16677
nosy: bh, jstaniek, ludwig, till
priority: bug
status: unread
title: freebusy list show wrong event.
topic: kde client, kowi
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3046>
___________________________________________________


From kolab-issues at intevation.de  Thu Sep 18 12:59:17 2008
From: kolab-issues at intevation.de (Ludwig Reiter)
Date: Thu, 18 Sep 2008 10:59:17 +0000
Subject: [Kolab-devel] [issue3047] freebusy list is not fully loaded
Message-ID: <1221735557.31.0.153651882742.issue3047@intevation.de>


New submission from Ludwig Reiter <ludwig at intevation.de>:

enterprise4 Windows
Kontact-Installer_20080916.exe(kdepimlibs: 860269, kdepim: 861200)

Test:
1. Start to create an event at the current day.
2. Look at the freebusy list
Notice the first part of the fb list is not loaded.

----------
assignedto: till
messages: 16678
nosy: bh, jstaniek, ludwig, till
priority: minor bug
status: unread
title: freebusy list is not fully loaded
topic: kde client, kowi
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3047>
___________________________________________________


From kolab-issues at intevation.de  Thu Sep 18 13:04:14 2008
From: kolab-issues at intevation.de (Ludwig Reiter)
Date: Thu, 18 Sep 2008 11:04:14 +0000
Subject: [Kolab-devel] [issue3048] day scale is wrong in the calendar plugin
	after a restart
Message-ID: <1221735853.93.0.653639354886.issue3048@intevation.de>


New submission from Ludwig Reiter <ludwig at intevation.de>:

enterprise4 Windows
Kontact-Installer_20080916.exe(kdepimlibs: 860269, kdepim: 861200)

Test:
1. Switch to calendar plugin and select one week.
2. Close kontact.
3. Kill the kde processes.
4. Restart kontact.
Notice the day scale of calendar is displayed wrongly.

----------
assignedto: till
messages: 16679
nosy: bh, jstaniek, ludwig, till
priority: minor bug
status: unread
title: day scale is wrong in the calendar plugin after a restart
topic: kde client, kowi
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3048>
___________________________________________________


From kolab-issues at intevation.de  Thu Sep 18 13:10:16 2008
From: kolab-issues at intevation.de (Ludwig Reiter)
Date: Thu, 18 Sep 2008 11:10:16 +0000
Subject: [Kolab-devel] [issue3049] After removing of a second dimap account
	and syncing, kontact throws a lot of error messages.
Message-ID: <1221736216.11.0.417445254805.issue3049@intevation.de>


New submission from Ludwig Reiter <ludwig at intevation.de>:

enterprise4 Windows
Kontact-Installer_20080916.exe(kdepimlibs: 860269, kdepim: 861200)

I couldn't reproduce this bug and I hadn't noted the error messages, but after I
had removed a second dimap from the receiving account list and from the sending
account list I encountered a lot of error messages. Something like Could not
write to the second dimap account because of UID error.(?).

----------
assignedto: till
messages: 16680
nosy: bh, jstaniek, ludwig, till
priority: bug
status: unread
title: After removing of a second dimap account and syncing, kontact throws a lot of error messages.
topic: kde client, kowi
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3049>
___________________________________________________


From kolab-issues at intevation.de  Thu Sep 18 13:55:39 2008
From: kolab-issues at intevation.de (=?utf-8?q?Albrecht_Dre=C3=9F?=)
Date: Thu, 18 Sep 2008 11:55:39 +0000
Subject: [Kolab-devel] [issue3050] Horde VCALENDAR 2.0 mime part violates
	RFC 2445
Message-ID: <1221738938.94.0.693420841373.issue3050@intevation.de>


New submission from Albrecht Dre? <albrecht.dress at lios-tech.com>:

VCALENDAR 2.0 MIME parts (type text/calendar) created by Horde may contain a
"Description" entry like like

<snip>
SUMMARY:Test

DESCRIPTION:Zeit:

  Donnerstag\, 25. September 2008 14:00-16:30 (GMT+01:00) Amsterdam\,

  Berlin\, Bern\, Rom\, Stockholm\, Wien.



*~*~*~*~*~*~*~*~*~*

DTSTART:20080925T120000Z

</snip>

The "DESCRIPTION" entry *violates* RFC 2445 [1] which in Section 4.1 "Content
Lines" requires the following:

<snip>
   Lines of text SHOULD NOT be longer than 75 octets, excluding the line
   break. Long content lines SHOULD be split into a multiple line
   representations using a line "folding" technique. That is, a long
   line can be split between any two characters by inserting a CRLF
   immediately followed by a single linear white space character (i.e.,
   SPACE, US-ASCII decimal 32 or HTAB, US-ASCII decimal 9).
</snip>

According to this, in the above example, the last line MUST start with a
whitespace, and the line preceding it MUST contain at least one whitespace. 
Interpreting the DESCRIPTION as RFC 2445 requires, it ends with "Wien.",
followed by an empty line and the malformed tag "*~*~*~*~*~*~*~*~*~*".

This bug may be the cause for Outlook refusing to interpret any text/calendar
parts created by Horde [2].

[1] <http://tools.ietf.org/html/rfc2445>
[2] <http://www.kolab.org/pipermail/kolab-users/2008-September/008661.html>

----------
messages: 16681
nosy: albrecht.dress
priority: urgent
status: unread
title: Horde VCALENDAR 2.0 mime part violates RFC 2445
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3050>
___________________________________________________


From kolab-issues at intevation.de  Thu Sep 18 14:10:29 2008
From: kolab-issues at intevation.de (Ludwig Reiter)
Date: Thu, 18 Sep 2008 12:10:29 +0000
Subject: [Kolab-devel] [issue3051] Pressing Shift+R at a shown mail opens a
	composer with a reference to the mail
Message-ID: <1221739828.92.0.918047520886.issue3051@intevation.de>


New submission from Ludwig Reiter <ludwig at intevation.de>:

enterprise35 20080916.860192

Test:
1. Switch to kmail.
2. Press shift + r in the preview of a mail.
=> A composer pops up, with just a line:
"On Wednesday 30 July 2008 15:06:58 you wrote:"
and no text.
This line should not appear.

----------
assignedto: till
messages: 16683
nosy: bh, ludwig, osterfeld, pradeepto, till, vkrause
priority: minor bug
status: unread
title: Pressing Shift+R at a shown mail opens a composer with a reference to the  mail
topic: enterprise35, kde client
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3051>
___________________________________________________


From alex at ap-consulting.co.uk  Fri Sep 19 04:35:49 2008
From: alex at ap-consulting.co.uk (Alex Potter)
Date: Fri, 19 Sep 2008 03:35:49 +0100
Subject: [Kolab-devel] Kolab CVS build failure
Message-ID: <200809190335.50023.alex@ap-consulting.co.uk>

I seem to have run into a dependancy issue whiles trying to follow the build 
instructions in the wiki.

The log from the failed build may be seen at:

http://speedy.ap-consulting.co.uk/builderr.html

I note that the package in question is available in neither the release nor 
development branch sources. Can anyone point me to the correct location of 
the sources for a cvs build?

TIA

Alex


From wrobel at pardus.de  Fri Sep 19 06:37:13 2008
From: wrobel at pardus.de (Gunnar Wrobel)
Date: Fri, 19 Sep 2008 06:37:13 +0200
Subject: [Kolab-devel] Kolab CVS build failure
In-Reply-To: <200809190335.50023.alex@ap-consulting.co.uk>
References: <200809190335.50023.alex@ap-consulting.co.uk>
Message-ID: <20080919063713.20396o97rx9a1ns4@webmail.pardus.de>

Hi Alex!

Quoting Alex Potter <alex at ap-consulting.co.uk>:

> I seem to have run into a dependancy issue whiles trying to follow the build
> instructions in the wiki.
>
> The log from the failed build may be seen at:
>
> http://speedy.ap-consulting.co.uk/builderr.html
>
> I note that the package in question is available in neither the release nor
> development branch sources. Can anyone point me to the correct location of
> the sources for a cvs build?

My mistake. The package resides in "server/pear/PHP-Horde-Channel" and  
was not yet included in server/Makefile until yesterday.

We tend to break Kolab CVS from time to time when we are on the road  
to the next release. This has also been happening in the last two  
weeks. I fully restructured how we install the Kolab web client, the  
Kolab free/busy library and the Kolab postfix filters.

CVS should be clean again since yesterday evening but you can still  
expect some major bugs in the system.

Usually we only have very few people really building from CVS so we  
don't have a policy to be more strict or gentle with CVS when we work  
with it. If there are more people interested in CVS here, speak up so  
that we change that if necessary.

Cheers,

Gunnar

>
> TIA
>
> Alex
>
> _______________________________________________
> Kolab-devel mailing list
> Kolab-devel at kolab.org
> https://kolab.org/mailman/listinfo/kolab-devel
>



-- 
____ http://www.pardus.de _________________ http://gunnarwrobel.de _

E-mail : p at rdus.de                                 Dr. Gunnar Wrobel
Tel.   : +49 700 6245 0000                         Bundesstrasse 29
Fax    : +49 721 1513 52322                        D-20146 Hamburg
--------------------------------------------------------------------
    >> Mail at ease - Rent a kolab groupware server at p at rdus <<
--------------------------------------------------------------------


----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.


From kolab-issues at intevation.de  Fri Sep 19 09:59:16 2008
From: kolab-issues at intevation.de (T. Ribbrock)
Date: Fri, 19 Sep 2008 07:59:16 +0000
Subject: [Kolab-devel] [issue3052] Renaming folder with subfolders sometimes
	unsubscribes subfolders or crashes
Message-ID: <1221811156.55.0.353119175674.issue3052@intevation.de>


New submission from T. Ribbrock <itsef-admin at brightsight.com>:

Two of our users recently ran into the following problem:

- IMAP account
- The user renames a folder that contains several subfolders
- After having clicked OK, the user immediately clicks into one of the
subfolders of the renamed-to-be folder - KMail is (most likely) still busy at
that time renaming the folder
- In some cases, this causes some or all subfolders to be unsubscribed
- In the worst case, Kontact crashes (see backtrace)

Versions:
kontact --version
Qt: 3.3.8b
KDE: 3.5.9
Kontact: 1.2.9 (enterprise35 20080725.837785)
(Kubuntu 8.04.1)

----------
files: Crash_on_renaming_IMAP_folder_and_switching_subfolder_of_this_IMAP_folder-837785.txt
messages: 16688
nosy: itsef_admin
priority: urgent
status: unread
title: Renaming folder with subfolders sometimes unsubscribes subfolders or crashes
topic: enterprise35, kde client
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3052>
___________________________________________________
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: Crash_on_renaming_IMAP_folder_and_switching_subfolder_of_this_IMAP_folder-837785.txt
Url: http://kolab.org/pipermail/kolab-devel/attachments/20080919/20eafb39/Crash_on_renaming_IMAP_folder_and_switching_subfolder_of_this_IMAP_folder-837785.txt

From wrobel at pardus.de  Fri Sep 19 13:44:44 2008
From: wrobel at pardus.de (Gunnar Wrobel)
Date: Fri, 19 Sep 2008 13:44:44 +0200
Subject: [Kolab-devel] Enhancing Kolab decision making(re: Is it okay	to
	commit the samba patch to cvs?)
In-Reply-To: <200809162132.07436.ml@radoeka.nl>
References: <200809111755.13871.ml@radoeka.nl>
	<200809151037.42321.bernhard@intevation.de>
	<71fe4e760809151453p10f6b727u223f7352b9c3c818@mail.gmail.com>
	<200809162132.07436.ml@radoeka.nl>
Message-ID: <20080919134444.56195ipb7n5ri084@webmail.pardus.de>

Quoting Richard Bos <ml at radoeka.nl>:

> Hi,
>
> Op Monday 15 September 2008 23:53:59 schreef Alain Spineux:
>> Bernhard asked my advice about the inclusion of this patch in CVS .... :
>>
>> As I say for long time now, I'm more in favor of a plugin interface than
>> the inclusion of any Samba's specific code into Kolab.
>>
>> The pros and cons of the plugin architecture :
>>
>> - require more code than the simple Samba's specific patch
>> + the plugin architecture could be helpful to future Kolab's plugin
>> projects ( Asterisk integration, black and grey listing, ....)
>> + The two projects (kolab and the samba plugin) will be able to
>> evolute independently. Changes in one will not automatically implies
>> change in the other. This is true for bug too.
>>
>> For remember the Kolab's plugin interface should contains a least :
>> - some kolab's perl and PHP "function helper", "
>> - some php "hooks" to add screen and functionalities to the admin
>> interface, - some "hook" from inside the kolabd and the template generation
>> ?process
>
> Let me put it this way: let us know when the plugin interface is available we
> can than use it to add the samba functionality.
>
> Of course a plugin interface would be nice, but it is not here

I disagree. Any package management system is meant to be used for  
extensions. Granted the OpenPKG based Kolab Server has a long history  
of not enabling users to choose.

Currently the list of packages you can install when running  
install-kolab.sh is fixed. No choices allowed. But that does not  
change the fact that a user could generate an experimental RPM package  
for the Kolab Server and distribute it. It is actually not that hard.  
You could for example package a PHP web application (e.g. PHP-BB or  
some other fancy stuff) and provide it to other Kolab users so they  
can install it in their server. That is indeed a plugin interface.

Of course that interface is quite limited. It is mainly file based but  
this is enough to reach a lot of things. You actually mention some of  
these things further down and I'll comment them there.

> and I think
> that it will take a long (very long) time till it arrives.  Now with regards
> to the samba patch, it is of course possible to wait till the plugin
> interface arrives or as the patch is about ready to be committed to cvs that
> could be done as well.  If one waits long enough the current patch can't be
> committed anymore as the sources in cvs will have changed and a nice
> oppertunity will have passed to include some samba functionality.  The kolab
> devs could of course state that the patch will be included if someone
> provides the plugin structure, hoping that e.g. Albrecht or Christian (the
> samba patch providers) will provide the plugin structure.  But Albrecht e.g.
> already stated that he won't customize the patch further, so forget he'll
> provide a plugin structure...
>
> Let's see what difficulties we run into if the samba patch would be made a
> plugin:
>
> The patch provides a template file (samba.php.template.in).  So it  
> needs to be
> build.  This makes it already much less attractive as a plain plugin.

Why? Any plugin package will have to be build using rpm. That is an  
essential part of package management when using binary packages and I  
don't see a problem with it.

> The
> samba.php include file much be included in the file www/admin/user/user.php.
> How should happen with a plugin structure?  Should there be
> a /usr/lib/php/kolab/plugins directory? Should all the php files in that
> directory be included in the www/admin/user/user.php?  Or should the plugin
> have a kind of  include tag that states that it should be included in
> user.php?  This is I believe still the easy part.  Next is that the plugin
> should be triggered when a new user is saved, or removed and when the
> password is saved.  How is that to be done?  Here some smart plugin mechanism
> needs to be developed.

kolab-webadmin is really the only problem I see. More on this at the  
end of the mail.

>
> Next is the slapd.conf.template; 2 schema's have to be included,  
> some indexing
> keys are defined and new acl's are added.  The latter can be achieved when
> kolab is going to use the new openldap configuration method (what is it
> called Real Time Configuration, I believe).  The plugin openldap stuff can
> just be dumped in the RTC openldap directory.  I don't believe that the
> plugin additions can be easily added to the current slapd.conf file.

Why not? I don't know at the moment if the "include" statement in  
slapd.conf would allow something like "include  
/etc/openldap/plugins/*.conf". If not you could still use such a  
directory and have kolabconf compile the single files in  
"/etc/openldap/plugins" into one file "/etc/openldap/plugins.conf"  
which you include with "include /etc/openldap/plugins.conf" in  
slapd.conf. Does not sound that hard to me.

>
> Last for this patch is the addition of variables to kolab.conf.  This can be
> achieved when kolab is going to use a conf.d (/etc/kolab/conf.d) directory.
> Plugins could just dump their variable definitions there and kolabconf would
> read them.

Sounds pretty easy. Why shouldn't we do it this way?

>
> For the RTC slapd.conf there is already an issue.  For all the other
> challenges there isn't.
>
> Perhaps issues should be opened for the ideas mentioned above (and  
> that others
> agree with).  But I also think it shows that the plugin interface is not
> available for a long time.  Hence the samba patch should be committed to cvs
> the way it is now available,

I really don't think so. You had some very good suggestions which are  
not that hard to implement and I think just fixing the  
/etc/kolab/conf.d/ and the /etc/openldap/plugins/ issues would already  
allow you to package the biggest part of the samba patch in a plugin.

Of course that still excludes the kolab-webadmin package and I  
acknowledge that this is a problem indeed. File-based extensions are  
currently not possible there.

I started rewriting the code once but I failed to get it done for time  
constraints. I still believe this is a thing that is in dire need of  
full rewrite.

Nevertheless: When I look at the discussion above and the good  
proposals you already made, maybe finding a a simple solution for  
kolab-webadmin wouldn't be that hard either? I'm certainly willing to  
discuss that.

In any case thanks for fostering the discussions. Even if the whole  
process is slow I believe we are getting somewhere :)

Cheers,

Gunnar

> if it is to be accepted by the kolab devs at
> all.
>
> My 2ct.
>
>
> --
> Richard Bos
> We are borrowing the world of our children,
> It is not inherited from our parents.
>
> _______________________________________________
> Kolab-devel mailing list
> Kolab-devel at kolab.org
> https://kolab.org/mailman/listinfo/kolab-devel
>



-- 
____ http://www.pardus.de _________________ http://gunnarwrobel.de _

E-mail : p at rdus.de                                 Dr. Gunnar Wrobel
Tel.   : +49 700 6245 0000                         Bundesstrasse 29
Fax    : +49 721 1513 52322                        D-20146 Hamburg
--------------------------------------------------------------------
    >> Mail at ease - Rent a kolab groupware server at p at rdus <<
--------------------------------------------------------------------


----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.


From wrobel at pardus.de  Fri Sep 19 13:54:54 2008
From: wrobel at pardus.de (Gunnar Wrobel)
Date: Fri, 19 Sep 2008 13:54:54 +0200
Subject: [Kolab-devel] Packaging of the Kolab web client (Horde)
In-Reply-To: <200809162200.16292.ml@radoeka.nl>
References: <20080915185801.0256460014F@lists.intevation.de>
	<200809152242.05813.ml@radoeka.nl>
	<20080916052953.79386h4td6eirk00@webmail2.pardus.de>
	<200809162200.16292.ml@radoeka.nl>
Message-ID: <20080919135454.37375g7t2qt4cfsw@webmail.pardus.de>

Quoting Richard Bos <ml at radoeka.nl>:

> Op Tuesday 16 September 2008 05:29:53 schreef Gunnar Wrobel:
>> Quoting Richard Bos <ml at radoeka.nl>:
>> > Hi Gunnar,
>> >
>> > Op Monday 15 September 2008 20:58:01 schreef cvs at kolab.org:
>> >> Added Files:
>> >>         horde-webmail-1.2_rc1_kolab_openpkg.patch
>> >> Log Message:
>> >> Added the patch for the new webmail release candidate. Horde was quick
>> >> this time and we now have the release available that will be the basis
>> >> for the next few Kolab server years. All native ports are encouraged to
>> >> switch to horde-webmail-1.2.* as soon as possible.
>> >
>> > Instead of all the seperate modules do you mean?
>>
>> Yes.
>>
>> > What is the advantage, less packaging?
>>
>> Yes that is one part.
>>
>> In addition the patch handling is way easier. One Kolab specific patch
>> for Horde and that's it.
>>
>> This is strongly against my personal Gentoo nature :) but I believe it
>> is a significantly easier approach for all parties involved.
>
> Sounds good indeed.  I had a look at the patch, and there are some changes
> that you make against the horde lib/core/app code.  Are these changes
> provided upstream, or are they really kolab specific?

Somewhere in between. The patch queue I maintain is something that I  
try to keep as small as possible. Meaning that I commit patches  
upstream once they have the required quality. But sometimes I'm  
required to provide a hotfix for an issue that will need to get  
reworked to have the necessary quality to go in upstream. Or I touch  
areas upstream where Jan or Chuck have to review the patch. Or there  
are important fixes upstream that are not yet available in a release.  
So I always have some stuff in my patch queue that helps to get the  
one or the other functionality working on the Kolab server.

Most of this is actually not Kolab specific anymore. The days of  
massive Kolab patching in Horde have been over for a while now. You  
could download a standard horde release package and it would mostly  
run fine with a Kolab server.

> I'm not talking about
> the $conf[''] changes, but e.g. the lines between:
> if ($GLOBALS['conf']['kolab']['enabled']) {
> }

These lines just comment dummy configurations that are not needed when  
running with Kolab.

> and the changes to Horde/iCalendar.php or lib/SyncML/Backend.php, etc.

These are special SyncML related fixes that have been submitted  
upstream but did not yet go into CVS.

>
>
> [............]
>
>> I made this comment a little bit more elaborate as I would like to see
>> the native ports to switch over to horde-webmail so that we have a
>> common base. The Gentoo users already have the kolabified
>> horde-webmail available in the main distribution, Univention switched
>> also, and OpenPKG will have it in the next release.
>
> Having to apply one patch is convincing enough ;)

In general the idea of this patch is to provide a method to get a  
correctly configured Horde web client for the Kolab Server with a  
minimum of fuss.

Of course Horde is a very big system and very configurable. So I can  
imagine that my patch won't work for everyone and people might wish to  
modify it in the one or other way.

In that case they will have to experiment themselves. As mentioned a  
plain horde release should already work well enough with a Kolab  
Server. It does not hurt to check the patches at hg.pardus.de in that  
case though.

Cheers,

Gunnar

>
> --
> Richard Bos
> We are borrowing the world of our children,
> It is not inherited from our parents.
>
> _______________________________________________
> Kolab-devel mailing list
> Kolab-devel at kolab.org
> https://kolab.org/mailman/listinfo/kolab-devel
>



-- 
______ http://kdab.com _______________ http://kolab-konsortium.com _

p at rdus Kolab work is funded in part by KDAB and the Kolab Konsortium

____ http://www.pardus.de _________________ http://gunnarwrobel.de _
E-mail : p at rdus.de                                 Dr. Gunnar Wrobel
Tel.   : +49 700 6245 0000                          Bundesstrasse 29
Fax    : +49 721 1513 52322                          D-20146 Hamburg
--------------------------------------------------------------------
    >> Mail at ease - Rent a kolab groupware server at p at rdus <<
--------------------------------------------------------------------


----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.


From wrobel at pardus.de  Fri Sep 19 14:05:17 2008
From: wrobel at pardus.de (Gunnar Wrobel)
Date: Fri, 19 Sep 2008 14:05:17 +0200
Subject: [Kolab-devel] Samba KEP (Re: Enhancing Kolab
	decision	making	(re: Is it okay to commit the samba patch to cvs?))
In-Reply-To: <200809171054.55089.bernhard@intevation.de>
References: <200809111755.13871.ml@radoeka.nl>
	<200809151054.15938.bernhard@intevation.de>
	<20080915171944.12014zft5h1fnhss@webmail2.pardus.de>
	<200809171054.55089.bernhard@intevation.de>
Message-ID: <20080919140517.11356dcw98cjnmo0@webmail.pardus.de>

Quoting Bernhard Reiter <bernhard at intevation.de>:

> On Monday 15 September 2008 17:19, Gunnar Wrobel wrote:
>> > The next point is one of the target group for Kolab Server users.
>> > Any IT solution, just like Kolab or a competitor will not conquer the
>> > market in one go. It better to first target specific markets.
>> > So the question is: Will adding a feature (like Samba) help us to conquer
>> > the next market we would want to go for with Kolab and its Server?
>> > Samba integration seems to be possible so the problem is not keeping
>> > anybody from "buying" Kolab Server.
>>
>> This sounds a little bit as if the suggested KEP process does not   
>> distinguish between a structural enhancement and an extension. I  
>> see  that as an important difference.
>
> A good remark!
>
>> If a KEP could suggest enhancing the Kolab Server with a specific   
>> application as an addon (e.g. the Open Ticket Request System (OTRS)  
>> or  Munin as a monitoring tool) then the Kolab Konsortium would  
>> always  have to ask: Does this have significant market value? Do we  
>> really  want to add it? For any additional application additional  
>> testing is  required.
>>
>> But adding such extensions to the Kolab Server is already possible   
>> today. An experienced user could build OpenPKG extension packages   
>> (even if nobody does it yet and I consider this still way too   
>> complicated - but that is not the point here). So for such  
>> extensions  I don't see the need for a KEP process as anybody could  
>> build and  distribute packages without additional overhead.
>
> Still there is the decision whether this should come with the default
> Kolab Server/OpenPKG distribution ...
> One value of Kolab Server has been its integrated testing.
> (This has been relaxed a bit with the Webklient now being in Beta,
> but still part of the Kolab Server/OpenPKG release.)
>
> The idea to have add-ons with a different support or maturity levels
> still is a good one, but of course we are lacking structure, concept
> and all this for it right now.
>
>> But I consider KEPs relevant once we talk about structural changes  
>> to  the core Kolab Server in order to *enable* specific additional   
>> extensions. This is of course the case for Samba. This is in fact a  
>>  very good example of that. Adding this functionality won't be  
>> possible  without some general hooks in the server that allow such  
>> an extension.
>>
>> Do people agree that we should keep the focus for KEPs like this?
>
> The question of inclusion in the core distribution needs to be a KEP as well.

But wouldn't this be a completely different decision process?

Lets say somebody would propose to restructure the kolab-webadmin or  
add minor features to kolabconf and we'd discuss this via a KEP. Then  
this can easily be a community process. But inclusion of complete  
applications is a different thing in my eyes. Complete applications  
have completely different needs concerning the testing. You already  
mentioned that this has (or is) a problem with the Kolab Server web  
client which did not get the testing to make it rock solid in the  
current server version.

Would a decision on such a KEP also be a community process? The  
testing would still be done by KK.

I believe we should just try to be more open to such extensions and  
provide some upload place or some other structures instead of going  
all KEPpy on extensions that provide new applications.

Cheers,

Gunnar

> A proposal is needed if the effects of a decision is potentially large.
> Creating extensions in a certain way can have such a large effect,
> even when it is decided to not to pick them up for distribution as Kolab
> development community.
>
> I agree that a KEP should clearly state what its goal is of course! :)
>
> Best,
> Bernhard
> --
> Managing Director - Owner: www.intevation.net       (Free Software Company)
> Germany Coordinator: fsfeurope.org. Coordinator: www.Kolab-Konsortium.com.
> Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998
> Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
>



-- 
____ http://www.pardus.de _________________ http://gunnarwrobel.de _

E-mail : p at rdus.de                                 Dr. Gunnar Wrobel
Tel.   : +49 700 6245 0000                         Bundesstrasse 29
Fax    : +49 721 1513 52322                        D-20146 Hamburg
--------------------------------------------------------------------
    >> Mail at ease - Rent a kolab groupware server at p at rdus <<
--------------------------------------------------------------------


----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.


From m.gabriel at das-netzwerkteam.de  Sat Sep 20 00:22:18 2008
From: m.gabriel at das-netzwerkteam.de (Mike Gabriel)
Date: Sat, 20 Sep 2008 00:22:18 +0200
Subject: [Kolab-devel] external-horde-cvs.sh removed
Message-ID: <20080920002218.1789471r4fc8gbh6@mail.das-netzwerkteam.de>

hi gunnar,

can you give a short info on how to create a snapshot of kolab's horde  
version (kolab-webclient snapshot so to say...). till now i used the  
external-horde-cvs.sh script that you have moved to the Attic on the  
18th September 2008.

any hint is welcome!!!

or is it also possible just to use horde-cvs? are there any patches  
that are in the kolab-webclient but not in horde's cvs (HEAD)?

thanks a lot,
mike


-- 

das netzwerkteam
mike gabriel, dorfstr. 27, 24245 barmissen
fon: +49 (4302) 281418, fax: +49 (4302) 281419
mail: m.gabriel at das-netzwerkteam.de, http://das-netzwerkteam.de
freeBusy:
https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xfb

----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.


From ml at radoeka.nl  Sat Sep 20 11:53:03 2008
From: ml at radoeka.nl (Richard Bos)
Date: Sat, 20 Sep 2008 11:53:03 +0200
Subject: [Kolab-devel]
	=?utf-8?q?Enhancing_Kolab_decision_making=28re=3A_I?=
	=?utf-8?q?s_it_okay=09to_commit_the_samba_patch_to_cvs=3F=29?=
In-Reply-To: <20080919134444.56195ipb7n5ri084@webmail.pardus.de>
References: <200809111755.13871.ml@radoeka.nl>
	<200809162132.07436.ml@radoeka.nl>
	<20080919134444.56195ipb7n5ri084@webmail.pardus.de>
Message-ID: <200809201153.04671.ml@radoeka.nl>

Op Friday 19 September 2008 13:44:44 schreef Gunnar Wrobel:
> Quoting Richard Bos <ml at radoeka.nl>:
[............]
> > Let's see what difficulties we run into if the samba patch would be made
> > a plugin:
> >
> > The patch provides a template file (samba.php.template.in).  So it
> > needs to be
> > build.  This makes it already much less attractive as a plain plugin.
>
> Why? Any plugin package will have to be build using rpm. That is an
> essential part of package management when using binary packages and I
> don't see a problem with it.

Because it needs a Makefile and the makefile must include the dist-conf file.  
Which is not straight forward to do.  However, Alain suggestion to use kolab.
{global,conf} as much as possible is a good one.  I only don't know if this 
will work for setting which binary to use, e.g. in case of perl, php and the 
like (@PERL@ should be expanded to /usr/bin/perl, etc).

[....]

> > Next is the slapd.conf.template; 2 schema's have to be included,
> > some indexing
> > keys are defined and new acl's are added.  The latter can be achieved
> > when kolab is going to use the new openldap configuration method (what is
> > it called Real Time Configuration, I believe).  The plugin openldap stuff
> > can just be dumped in the RTC openldap directory.  I don't believe that
> > the plugin additions can be easily added to the current slapd.conf file.
>
> Why not? I don't know at the moment if the "include" statement in
> slapd.conf would allow something like "include
> /etc/openldap/plugins/*.conf". If not you could still use such a
> directory and have kolabconf compile the single files in
> "/etc/openldap/plugins" into one file "/etc/openldap/plugins.conf"
> which you include with "include /etc/openldap/plugins.conf" in
> slapd.conf. Does not sound that hard to me.

The problem is more related to the hiearchy in the slap.conf file.  As there 
is a global part (top of file), settings that belong to the database (like 
the syncrepl stuff, which should be under the database config option about 
the middle of slapd.conf file) and there are the access control lists.  The 
latter is about the bottom of the file.  If this conclusion is indeed 
correct, there should be at least 3 include lines:
include /etc/openldap/slapd.global.d/*conf
include /etc/openldap/slapd.db.d/*conf
include /etc/openldap/slapd.access.d/*conf
But doing it this way is like re-inventing openldap Real Time Configuration 
(RTC).  Hence I suggested to move to openldap RTC right away!

> > Last for this patch is the addition of variables to kolab.conf.  This can
> > be achieved when kolab is going to use a conf.d (/etc/kolab/conf.d)
> > directory. Plugins could just dump their variable definitions there and
> > kolabconf would read them.
>
> Sounds pretty easy. Why shouldn't we do it this way?

Just do it, but we / somebody needs to code it.

> > For the RTC slapd.conf there is already an issue.  For all the other
> > challenges there isn't.
> >
> > Perhaps issues should be opened for the ideas mentioned above (and
> > that others
> > agree with).  But I also think it shows that the plugin interface is not
> > available for a long time.  Hence the samba patch should be committed to
> > cvs the way it is now available,
>
> I really don't think so. You had some very good suggestions which are
> not that hard to implement and I think just fixing the
> /etc/kolab/conf.d/ and the /etc/openldap/plugins/ issues would already
> allow you to package the biggest part of the samba patch in a plugin.

Thanks, nice to read :) 

> Of course that still excludes the kolab-webadmin package and I
> acknowledge that this is a problem indeed. File-based extensions are
> currently not possible there.
>
> I started rewriting the code once but I failed to get it done for time
> constraints. I still believe this is a thing that is in dire need of
> full rewrite.

Hmm, full rewrite....  Now that horde is about to be released by default with 
kolab, would a full rewrite be possible with the horde libraries?  Would that 
make it easier to do the rewrite?  It would at least give a consistent 
interface which is an important aspect too.

> Nevertheless: When I look at the discussion above and the good
> proposals you already made, maybe finding a a simple solution for
> kolab-webadmin wouldn't be that hard either? I'm certainly willing to
> discuss that.

Let's take user.php which creates, modify and remove users.  This is probably 
needed by more than 1 plugin => most likely a file based extension is needed.
Let's say the trigger is called 'create-user' to create a user.  Now if the 
plugins store there code in:
/var/lib/kolab/plugins/plugin-1/create-user.php
/var/lib/kolab/plugins/plugin-q/create-user.php

Inside the plugin there is just 1 function that's called create-user-plugin-1 
and create-user-plugin-q, would it be possible to use those functions in 
user.php?

user.php should check for the files, build an array of the available plugins 
and call them one for one on the correct trigger point.  All plugins get the 
same arguments from the trigger point.  Would this be possible?

-- 
Richard Bos
We are borrowing the world of our children,
It is not inherited from our parents.


From ml at radoeka.nl  Sat Sep 20 12:17:53 2008
From: ml at radoeka.nl (Richard Bos)
Date: Sat, 20 Sep 2008 12:17:53 +0200
Subject: [Kolab-devel]
	=?utf-8?q?Enhancing_Kolab_decision_making=28re=3A_I?=
	=?utf-8?q?s_it_okay=09to_commit_the_samba_patch_to_cvs=3F=29?=
In-Reply-To: <20080919134444.56195ipb7n5ri084@webmail.pardus.de>
References: <200809111755.13871.ml@radoeka.nl>
	<200809162132.07436.ml@radoeka.nl>
	<20080919134444.56195ipb7n5ri084@webmail.pardus.de>
Message-ID: <200809201217.54371.ml@radoeka.nl>

Op Friday 19 September 2008 13:44:44 schreef Gunnar Wrobel:
> > Next is the slapd.conf.template; 2 schema's have to be included, ?
> > some indexing
> > keys are defined and new acl's are added. ?The latter can be achieved
> > when kolab is going to use the new openldap configuration method (what is
> > it called Real Time Configuration, I believe). ?The plugin openldap stuff
> > can just be dumped in the RTC openldap directory. ?I don't believe that
> > the plugin additions can be easily added to the current slapd.conf file.
>
> Why not? I don't know at the moment if the "include" statement in ?
> slapd.conf would allow something like "include ?
> /etc/openldap/plugins/*.conf".

It does not seem to be possible (this is for openldap-2.3)

# /usr/lib/openldap/slapd -h 
ldap://127.0.0.1:389/ -f /etc/openldap/slapd.conf -u ldap -g ldap -d 255
@(#) $OpenLDAP: slapd 2.3.37 (Nov  8 2007 03:04:49) $
reading config file /etc/openldap/slapd.conf
line 19 (include /etc/openldap/schema/*.schema)
could not stat config file "/etc/openldap/schema/*.schema": No such file or 
directory (2)
/etc/openldap/slapd.conf: line 19: <include> handler exited with 1!
slapd destroy: freeing system resources.
slapd stopped.

and
line 94 (include /etc/openldap/*.access)
could not stat config file "/etc/openldap/*.access": No such file or directory 
(2)
/etc/openldap/slapd.conf: line 94: <include> handler exited with 1!

line 202 (include /etc/openldap/*.replicas)
could not stat config file "/etc/openldap/*.replicas": No such file or 
directory (2)
/etc/openldap/slapd.conf: line 202: <include> handler exited with 1!


> If not you could still use such a  
> directory and have kolabconf compile the single files in  
> "/etc/openldap/plugins" into one file "/etc/openldap/plugins.conf"  
> which you include with "include /etc/openldap/plugins.conf" in  
> slapd.conf. Does not sound that hard to me.


-- 
Richard Bos
We are borrowing the world of our children,
It is not inherited from our parents.


From kolab-issues at intevation.de  Sun Sep 21 22:42:20 2008
From: kolab-issues at intevation.de (John Shatz)
Date: Sun, 21 Sep 2008 20:42:20 +0000
Subject: [Kolab-devel] [issue3056] Mann lebt nur einmal - probiers aus !
Message-ID: <011957617.49400048065783@servicenterprises.com>


New submission from John Shatz <dwservicenterprisesm at servicenterprises.com>:

Haben Sie das Gefuhl, dass die Potenz wahrend des Sex nachlasst? Es lauft im Bett nicht mehr wie fruher?
"Kommen" Sie zu fruh? Oder hatten Sie einfach gerne langeren und intensiveren Sex?

Das Leben ist zu kurz - geniessen Sie das in vollen Zuegen.
Mit Geld kann man nicht alles kaufen! Die Potenz und uber 30 Minuten Standhaftigkeit schon! 

Mit unserem Produkt vergessen die Potenzprobleme und haben wieder Spass am Sex. Wir haben genau das Richtige fur Sie!
Das Geld kommt und geht - unvergessliches Sex-Erlebnis bleibt!

Angebote des Monats: 
NEU - Vi. Super Active 100 mg 30 Tab. 81,08 Euro
Vi. 10 Tab. 100 mg + Ci. 10 Tab. x 20 mg 48,95 Euro 

Vi. 10 Tab. 22,00 Euro
Vi. 30 Tab. 55,00 Euro - Sie sparen: 17,00 Euro
Vi. 60 Tab. 82,70 Euro - Sie sparen: 53,00 Euro
Vi. 90 Tab. 118,20 Euro - Sie sparen: 85,00 Euro

Ci. 10 - 27,80 Euro
Ci. 20 - 54,00 Euro - Sie sparen: 2,00 Euro
Ci. 30 - 72,90Euro - Sie sparen: 11,00 Euro

- keine versteckte Kosten
- Visa verifizierter Onlineshop
- bequem und diskret online bestellen.
- diskrete Verpackung 
- diskrete Zahlung
- kein peinlicher Arztbesuch erforderlich
- kostenlose, arztliche Telefon-Beratung
- kein langes Warten - Auslieferung innerhalb von 2-3 Tagen

Bestellen Sie noch heute und vergessen Sie Ihre Enttauschungen, anhaltende Versagensangste und wiederholte peinliche Situationen!

Vier Packchen gibts bei jeder Bestellung umsonst
http://img523.imageshack.us/img523/8701/hrmlupsyofv8.swf

----------
messages: 16703
nosy: dwservicenterprisesm, georg
status: unread
title: Mann lebt nur einmal - probiers aus !
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3056>
___________________________________________________


From wrobel at pardus.de  Mon Sep 22 11:57:39 2008
From: wrobel at pardus.de (Gunnar Wrobel)
Date: Mon, 22 Sep 2008 11:57:39 +0200
Subject: [Kolab-devel] external-horde-cvs.sh removed
In-Reply-To: <20080920002218.1789471r4fc8gbh6@mail.das-netzwerkteam.de>
References: <20080920002218.1789471r4fc8gbh6@mail.das-netzwerkteam.de>
Message-ID: <20080922115739.13266v9tppjxqokc@webmail.pardus.de>

Quoting Mike Gabriel <m.gabriel at das-netzwerkteam.de>:

> hi gunnar,
>
> can you give a short info on how to create a snapshot of kolab's horde
> version (kolab-webclient snapshot so to say...). till now i used the
> external-horde-cvs.sh script that you have moved to the Attic on the
> 18th September 2008.

The script was primarily removed as it was outdated. We are currently  
still discussing if we want to support this installation variant but  
it looks like the recommended setup for an external web client will be  
a second, nearly complete Kolab Server. While the external-horde.sh  
script is more flexible it won't be easy to control many of the  
necessary parameters on the external web server and so the chance for  
failure is quite high.

>
> any hint is welcome!!!
>
> or is it also possible just to use horde-cvs? are there any patches
> that are in the kolab-webclient but not in horde's cvs (HEAD)?

The recommended way of installing Horde for Kolab is to download the  
horde-webmail package and patch it with the corresponding patch in  
Kolab CVS.

The new package definition for kolab-webclient  
(http://kolab.org/cgi-bin/viewcvs-kolab.cgi/server/kolab-webclient/kolab-webclient.spec) should basically tell you what you need to  
do.

I guess I won't continue to provide a direct snapshot of my  
development efforts as that is too prone to failure when used by  
somebody else. Working on base of a release candidate is easier.

It is still possible to follow my day-to-day development on  
http://hg.pardus.de/cgi-bin/hg.cgi/horde/HORDE/. The patches in there  
apply to Horde CVS most of the time. Problem is that you need to be  
familiar with Mercurial and its patch queue management to understand  
how I work with the different branches there.

Cheers,

Gunnar

>
> thanks a lot,
> mike
>
>
> --
>
> das netzwerkteam
> mike gabriel, dorfstr. 27, 24245 barmissen
> fon: +49 (4302) 281418, fax: +49 (4302) 281419
> mail: m.gabriel at das-netzwerkteam.de, http://das-netzwerkteam.de
> freeBusy:
> https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xfb
>
> ----------------------------------------------------------------
> This message was sent using IMP, the Internet Messaging Program.
>
> _______________________________________________
> Kolab-devel mailing list
> Kolab-devel at kolab.org
> https://kolab.org/mailman/listinfo/kolab-devel
>



-- 
____ http://www.pardus.de _________________ http://gunnarwrobel.de _

E-mail : p at rdus.de                                 Dr. Gunnar Wrobel
Tel.   : +49 700 6245 0000                         Bundesstrasse 29
Fax    : +49 721 1513 52322                        D-20146 Hamburg
--------------------------------------------------------------------
    >> Mail at ease - Rent a kolab groupware server at p at rdus <<
--------------------------------------------------------------------


----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.


From kolab-issues at intevation.de  Mon Sep 22 13:16:06 2008
From: kolab-issues at intevation.de (Gunnar Wrobel)
Date: Mon, 22 Sep 2008 11:16:06 +0000
Subject: [Kolab-devel] [issue3061] horde/kronolith - Handling of event
	states.
Message-ID: <1222082166.75.0.359182250014.issue3061@intevation.de>


New submission from Gunnar Wrobel <p at rdus.de>:

Kronolith does not know event state "outofoffice", the Kolab format does not
know the state "cancelled".

Currently Kronolith will map "cancelled" to "free" when writing the format. It
will convert "outofoffice" to "busy" when reading the format (and hence writing
it back to storage if the event is modified within Horde).

----------
assignedto: wrobel
messages: 16727
nosy: bernhard, thomas, wilde, wrobel
priority: minor bug
status: unread
title: horde/kronolith - Handling of event states.
topic: format, web client
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3061>
___________________________________________________


From m.gabriel at das-netzwerkteam.de  Mon Sep 22 14:01:05 2008
From: m.gabriel at das-netzwerkteam.de (Mike Gabriel)
Date: Mon, 22 Sep 2008 14:01:05 +0200
Subject: [Kolab-devel] external-horde-cvs.sh removed
In-Reply-To: <20080922115739.13266v9tppjxqokc@webmail.pardus.de>
References: <20080920002218.1789471r4fc8gbh6@mail.das-netzwerkteam.de>
	<20080922115739.13266v9tppjxqokc@webmail.pardus.de>
Message-ID: <20080922140105.13741tix6pztuznl@mail.das-netzwerkteam.de>

hi gunnar,

thx for your reply!

On Mo 22 Sep 2008 11:57:39 CEST Gunnar Wrobel wrote:

> Quoting Mike Gabriel <m.gabriel at das-netzwerkteam.de>:
> I guess I won't continue to provide a direct snapshot of my
> development efforts as that is too prone to failure when used by
> somebody else. Working on base of a release candidate is easier.
>
> It is still possible to follow my day-to-day development on
> http://hg.pardus.de/cgi-bin/hg.cgi/horde/HORDE/. The patches in there
> apply to Horde CVS most of the time. Problem is that you need to be
> familiar with Mercurial and its patch queue management to understand
> how I work with the different branches there.

ah, ok... there is a misunderstanding (as i did not mention the  
purpose of my horde instances...). for a stable / production your  
proposed way probably is best.

the purpose for my horde instance would rather focus on code  
contribution. with an old stable/rc instance patches will not be  
really be up-to-date... i filed some bugs recently to horde.org, and  
jan schneider made me aware of my old CVS checkouts (i used the  
external-horde-cvs script and only then became aware of the hard-coded  
checkout $DATE).

so again the more precised question: what is the best way to obtain a  
relatively recent kolab-webclient development snapshot. a snapshot  
that i can use as reference when finding a bug in the production  
instance (already solved in CVS or not), a snapshot to start working  
on fixes/enhancements and patch against...

thx for any hints,
mike

-- 

das netzwerkteam
mike gabriel, dorfstr. 27, 24245 barmissen
fon: +49 (4302) 281418, fax: +49 (4302) 281419
mail: m.gabriel at das-netzwerkteam.de, http://das-netzwerkteam.de
freeBusy:
https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xfb

----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.


From kolab-issues at intevation.de  Mon Sep 22 14:02:26 2008
From: kolab-issues at intevation.de (=?utf-8?q?Albrecht_Dre=C3=9F?=)
Date: Mon, 22 Sep 2008 12:02:26 +0000
Subject: [Kolab-devel] [issue3062] Horde: Cannot use object of type
	PEAR_Error as array
Message-ID: <1222084946.37.0.287753288215.issue3062@intevation.de>


New submission from Albrecht Dre? <albrecht.dress at lios-tech.com>:

I see the following symptoms when doing the following in Horde with an account
which usually uses Outlook and the Konsec connector (and has several
appointments the the calendar):

- Log into Horde;
- Open (German UI) "Organisieren";
- Click on "Kalender".

The top bar stays empty (i.e. grey), and the region where the calendar should
appear is empty.

In /kolab/var/apache/log/php/php-errors.log, the following messages appear:

PHP Fatal error:  Cannot use object of type PEAR_Error as array in
/kolab/lib/php/Horde/Share/kolab.php on line 1464
PHP Notice:  Unknown: SECURITY PROBLEM: insecure server advertised AUTH=PLAIN
(errflg=1) in Unknown on line 0
PHP Notice:  Unknown: Mailbox does not exist (errflg=2) in Unknown on line 0
PHP Notice:  Unknown: SECURITY PROBLEM: insecure server advertised AUTH=PLAIN
(errflg=1) in Unknown on line 0

When I click on e.g. the "Webmail", the top bar re-appears, and I see the error
message as in the attached screenshot.

----------
files: event.png
messages: 16730
nosy: albrecht.dress
priority: bug
status: unread
title: Horde: Cannot use object of type PEAR_Error as array
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3062>
___________________________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: event.png
Type: image/png
Size: 19957 bytes
Desc: not available
Url : http://kolab.org/pipermail/kolab-devel/attachments/20080922/099be1f7/event-0001.png

From wrobel at pardus.de  Mon Sep 22 14:10:27 2008
From: wrobel at pardus.de (Gunnar Wrobel)
Date: Mon, 22 Sep 2008 14:10:27 +0200
Subject: [Kolab-devel] external-horde-cvs.sh removed
In-Reply-To: <20080922140105.13741tix6pztuznl@mail.das-netzwerkteam.de>
References: <20080920002218.1789471r4fc8gbh6@mail.das-netzwerkteam.de>
	<20080922115739.13266v9tppjxqokc@webmail.pardus.de>
	<20080922140105.13741tix6pztuznl@mail.das-netzwerkteam.de>
Message-ID: <20080922141027.88053ws62qdxkegw@webmail.pardus.de>

Quoting Mike Gabriel <m.gabriel at das-netzwerkteam.de>:

> hi gunnar,
>
> thx for your reply!
>
> On Mo 22 Sep 2008 11:57:39 CEST Gunnar Wrobel wrote:
>
>> Quoting Mike Gabriel <m.gabriel at das-netzwerkteam.de>:
>> I guess I won't continue to provide a direct snapshot of my
>> development efforts as that is too prone to failure when used by
>> somebody else. Working on base of a release candidate is easier.
>>
>> It is still possible to follow my day-to-day development on
>> http://hg.pardus.de/cgi-bin/hg.cgi/horde/HORDE/. The patches in there
>> apply to Horde CVS most of the time. Problem is that you need to be
>> familiar with Mercurial and its patch queue management to understand
>> how I work with the different branches there.
>
> ah, ok... there is a misunderstanding (as i did not mention the
> purpose of my horde instances...). for a stable / production your
> proposed way probably is best.
>
> the purpose for my horde instance would rather focus on code
> contribution. with an old stable/rc instance patches will not be
> really be up-to-date... i filed some bugs recently to horde.org, and
> jan schneider made me aware of my old CVS checkouts (i used the
> external-horde-cvs script and only then became aware of the hard-coded
> checkout $DATE).
>
> so again the more precised question: what is the best way to obtain a
> relatively recent kolab-webclient development snapshot. a snapshot
> that i can use as reference when finding a bug in the production
> instance (already solved in CVS or not), a snapshot to start working
> on fixes/enhancements and patch against...

I'd suggest using plain Horde CVS for that. The code within Horde CVS  
now has a structure that I intend to keep that way for the next few  
years. So there is nothing really major left within the patch queue on  
hg.pardus.de. I'm commiting minor fixes directly to Horde CVS and just  
keep them in the patch queue so that I can apply them to the current  
stable release or release candidate.

I would consider the probability of your development clashing with  
what I do in my patch queue to be really minor if you use plain Horde  
CVS.

Looking forward to your patches :) I couldn't look at your recent  
batch yet but will do it once I'm less busy on the next Kolab Server  
release.

Cheers,

Gunnar

>
> thx for any hints,
> mike
>
> --
>
> das netzwerkteam
> mike gabriel, dorfstr. 27, 24245 barmissen
> fon: +49 (4302) 281418, fax: +49 (4302) 281419
> mail: m.gabriel at das-netzwerkteam.de, http://das-netzwerkteam.de
> freeBusy:
> https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xfb
>
> ----------------------------------------------------------------
> This message was sent using IMP, the Internet Messaging Program.
>
> _______________________________________________
> Kolab-devel mailing list
> Kolab-devel at kolab.org
> https://kolab.org/mailman/listinfo/kolab-devel
>



-- 
____ http://www.pardus.de _________________ http://gunnarwrobel.de _

E-mail : p at rdus.de                                 Dr. Gunnar Wrobel
Tel.   : +49 700 6245 0000                         Bundesstrasse 29
Fax    : +49 721 1513 52322                        D-20146 Hamburg
--------------------------------------------------------------------
    >> Mail at ease - Rent a kolab groupware server at p at rdus <<
--------------------------------------------------------------------


----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.


From kolab-issues at intevation.de  Tue Sep 23 00:05:32 2008
From: kolab-issues at intevation.de (Uk Online Promo)
Date: Mon, 22 Sep 2008 22:05:32 +0000
Subject: [Kolab-devel] [issue3063] You Have Just Won
Message-ID: <20080922220524.MFUR1599.simmts12-srv.bellnexxia.net@simip10-ac.srvr.bell.ca>


New submission from Uk Online Promo <maryt at nb.sympatico.ca>:

You have just won 1,000,000.00 GBP in our Monthly UK-PROMO,contact Mr.Edward Wright with your 

Name,Address,Phone,Sex,Occupation,Age,Country.Email: mr.edwardwright001 at hotmail.co.uk

----------
messages: 16742
nosy: info3, maryt
status: unread
title: You Have Just Won
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3063>
___________________________________________________


From kolab-issues at intevation.de  Tue Sep 23 11:38:39 2008
From: kolab-issues at intevation.de (T. Ribbrock)
Date: Tue, 23 Sep 2008 09:38:39 +0000
Subject: [Kolab-devel] [issue3064] "New Mail" notification only works in
	currently viewed (IMAP) folder
Message-ID: <1222162719.56.0.815282854304.issue3064@intevation.de>


New submission from T. Ribbrock <itsef-admin at brightsight.com>:

I have configured KMail to notify me when new mail arrives ("Settings ->
Configure Norifications"). Originally, I wanted to have a sound played but could
not get this to work at all. Subsequently, I enabled "Show a message in a pop-up
window" and "Execute a program" (which then plays a sound). Unfortunately, both
notifications only work for new mail arriving in the folder I am currently
viewing. As I have mail filters and several accounts in use, I would expect that
the notification is initiated whenever new mail arrives in any folder that does
not have "Act on new/unread mail" disabled in its properties. All folders in
question are IMAP.

kontact --version
Qt: 3.3.8b
KDE: 3.5.9
Kontact: 1.2.9 (enterprise35 20080908.858460)
(Kubuntu 8.04)

----------
messages: 16753
nosy: itsef_admin
priority: bug
status: unread
title: "New Mail" notification only works in currently viewed (IMAP) folder
topic: enterprise35, kde client
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3064>
___________________________________________________


From kolab-issues at intevation.de  Wed Sep 24 08:57:56 2008
From: kolab-issues at intevation.de (Bernhard Reiter)
Date: Wed, 24 Sep 2008 06:57:56 +0000
Subject: [Kolab-devel] [issue3065] Crash in KOAgendaItem::paintEvent ..
	DwMailbox .. DwString
Message-ID: <1222239476.33.0.0483938049562.issue3065@intevation.de>


New submission from Bernhard Reiter <bernhard at intevation.de>:

Kontact: 1.2.9 (enterprise35 20080908.858460)
Etch 3.5.9.enterprise.0.20080908.858460-kk1

While doing a sync, I've switched from email to the calender view.
with Kontact: 1.2.9 (enterprise35 20080908.858460) Debian Etch
(freshly upgraded from proko2, still running the first new instance,
but a sync was done successfully before.)

The backtrace seems to be close to the old crash for proko2
kolab/issue1434 (Crash in KOAgendaItem::paintEvent)

----------
assignedto: till
messages: 16765
nosy: bernhard, ludwig, till, vkrause
priority: bug
status: unread
title: Crash in KOAgendaItem::paintEvent .. DwMailbox .. DwString
topic: kde client, prokde35
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3065>
___________________________________________________


From kolab-issues at intevation.de  Wed Sep 24 09:09:49 2008
From: kolab-issues at intevation.de (Bernhard Reiter)
Date: Wed, 24 Sep 2008 07:09:49 +0000
Subject: [Kolab-devel] [issue3066] Unnecessary encryption key check when
	sending signed.
Message-ID: <1222240189.61.0.3027562613.issue3066@intevation.de>


New submission from Bernhard Reiter <bernhard at intevation.de>:

Kontact: 1.2.9 (enterprise35 20080908.858460)
Etch 3.5.9.enterprise.0.20080908.858460-kk1

I have an email address which goes to a mailinglist for which
I sometimes encrypt. So I have entered this email address,
let's call it team at example.com in my list of contacts
and selected several encryption keys in the encryption settings.
Also there is no preferred setting for encryption and "try to always sign"
configured for this contact entry.

When know sending an email to the list unencrypted, sometimes as carbon copy,
I get a dialog that some of the keys are not trustworthy and whether I would 
want to abort or continue. This question should not come as it does not make 
sense, because I do not want to encrypt.
Also no matter if I press abort or continue, the email gets send as far 
as I can see.

Ludwig, can you try to reproduce and give a more concise recipe 
for reproduction?

----------
assignedto: ludwig
messages: 16768
nosy: bernhard, emanuel, ludwig, till, vkrause
priority: bug
status: unread
title: Unnecessary encryption key check when sending signed.
topic: kde client, prokde35
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3066>
___________________________________________________


From kolab-issues at intevation.de  Wed Sep 24 12:19:32 2008
From: kolab-issues at intevation.de (Alex Potter)
Date: Wed, 24 Sep 2008 10:19:32 +0000
Subject: [Kolab-devel] [issue3067] Missing depenency in CVS build of sqlite
Message-ID: <1222251572.63.0.188644895618.issue3067@intevation.de>


New submission from Alex Potter <alex at ap-consulting.co.uk>:

10:47:17 (206.82 KB/s) - `sqlite-2.8.17.tar.gz' saved [969805/969805]

cp sqlite.spec sqlite.patch /kolabdevel/RPM/SRC/sqlite
cd /kolabdevel/RPM/SRC/sqlite && /kolabdevel/bin/openpkg rpm -ba sqlite.spec
--define 'with_pth no'
error: Failed build dependencies:
        gawk is needed by sqlite-2.8.17-20080919
make[1]: *** [sqlite-2.8.17-20080919.src.rpm] Error 1
make[1]: Leaving directory `/kolabdevel/CVS/server/sqlite'
make: *** [base] Error 2
Not installing! Looks like the Kolab developers broke CVS. Bug them at
https://www.intevation.de/roundup/kolab
s

----------
messages: 16775
nosy: alepot
priority: bug
status: unread
title: Missing depenency in CVS build of sqlite
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3067>
___________________________________________________


From kolab-issues at intevation.de  Wed Sep 24 12:59:40 2008
From: kolab-issues at intevation.de (Ludwig Reiter)
Date: Wed, 24 Sep 2008 10:59:40 +0000
Subject: [Kolab-devel] [issue3068] A mail with attachment is displayed in
	the maillist without attachment in a online imap account.
Message-ID: <1222253980.27.0.703090141501.issue3068@intevation.de>


New submission from Ludwig Reiter <ludwig at intevation.de>:

enterprise35 20080919.862683

The user has a online imap account. He configures the maillist to notice, if a
mail has an attachment. Someone sends a mail with attachment to him.
The mail is displayed with out an attachment icon in the list, but in the
preview window it has an attachment.

Test:
A has a mixed mode account.
1. A switch to kmail.
2. A activates the "has attachment"-column in the maillist.
3. B sends a mail with attachment to A.
4. A syncs and looks at the mail.

----------
assignedto: till
messages: 16779
nosy: bh, ludwig, osterfeld, pradeepto, till, vkrause
priority: bug
status: unread
title: A mail with attachment is displayed in the maillist without attachment in a online imap account.
topic: enterprise35, kde client
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3068>
___________________________________________________


From kolab-issues at intevation.de  Wed Sep 24 14:18:19 2008
From: kolab-issues at intevation.de (Ludwig Reiter)
Date: Wed, 24 Sep 2008 12:18:19 +0000
Subject: [Kolab-devel] [issue3069] After syncing a online imap account,
	mails in a second account are not displayed in the mail preview
Message-ID: <1222258699.08.0.191018385142.issue3069@intevation.de>


New submission from Ludwig Reiter <ludwig at intevation.de>:

enterprise35 20080919.862683

Test:
User A has a online imap and a mixed mode account configured.
The inbox in the online imap account has a lot of unsynced mails.
Select the inbox of the imap account.
While syncing , switch to the second account.
After sync, the mails of the second account are not displayed in the preview.

----------
assignedto: till
messages: 16783
nosy: bh, ludwig, osterfeld, pradeepto, till, vkrause
priority: minor bug
status: unread
title: After syncing a online imap account, mails in a second account are not displayed in the mail preview
topic: enterprise35, kde client
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3069>
___________________________________________________


From kolab-issues at intevation.de  Wed Sep 24 14:59:21 2008
From: kolab-issues at intevation.de (Ludwig Reiter)
Date: Wed, 24 Sep 2008 12:59:21 +0000
Subject: [Kolab-devel] [issue3070] Crash in KMCommand::slotStart while
	replying to a mail
Message-ID: <1222261161.35.0.536276561888.issue3070@intevation.de>


New submission from Ludwig Reiter <ludwig at intevation.de>:

enterprise35 20080602.814375

A customer repooted a crash. He wanted to reply a mail and pressed on the
toolbar button and kontact crashed. (See bugtrace.)
This bug was not reproducable.

----------
assignedto: till
files: kontact-replay-crash.txt
messages: 16784
nosy: bh, ludwig, osterfeld, pradeepto, till, vkrause
priority: bug
status: unread
title: Crash in KMCommand::slotStart while replying to a mail
topic: kde client, prokde35
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3070>
___________________________________________________
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: kontact-replay-crash.txt
Url: http://kolab.org/pipermail/kolab-devel/attachments/20080924/159e2ac1/kontact-replay-crash.txt

From kolab-issues at intevation.de  Wed Sep 24 21:04:11 2008
From: kolab-issues at intevation.de (farley broderick)
Date: Wed, 24 Sep 2008 19:04:11 +0000
Subject: [Kolab-devel] =?utf-8?b?W2lzc3VlMzA3MV0g0L/QuNC30LTRiw==?=
Message-ID: <000501c91e78$02a81e38$760851af@wagfofpa>


New submission from farley broderick <fusun.avci at etcbase.com>:

??????-_

----------
messages: 16787
nosy: fusun.avci
status: unread
title: ?????
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3071>
___________________________________________________


From kolab-issues at intevation.de  Thu Sep 25 09:52:04 2008
From: kolab-issues at intevation.de (Ema Brenna)
Date: Thu, 25 Sep 2008 07:52:04 +0000
Subject: [Kolab-devel] [issue3072] University Degree based on Work
	Experience, No exam/test abnd d87c
In-Reply-To: <c81001c91ae5$165504f0$5732ae31@ojgqle3>
Message-ID: <1222327675.5858@infinito.it>


New submission from Ema Brenna <e.brennast at infinito.it>:

Would you like to:      
Increase your salary?       
Increase your desirability?      
Increase your ability to find other work?       
Increase your marketability?   

Call: 1-718-989-5740 (inside USA)        
     +1-718-989-5740 (outside USA)      

Is an University Degree/Dip1oma Holding you Back?  
Call us to inquire about our degree programs.      

Whether you are seeking a Bacheelors, M B A or P h D   
We can provide you credentials to get you better career        
No study, test, exam or coursework required  

Call: 1-718-989-5740 (inside USA)      
     +1-718-989-5740 (outside USA)   

Leave us your "Name, Country & Phone No. with Countrycode"  

We will get back to you real soon

----------
messages: 16790
nosy: cvs, e.brennast
status: unread
title: University Degree based on Work Experience, No exam/test abnd d87c
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3072>
___________________________________________________


From kolab-issues at intevation.de  Thu Sep 25 11:19:22 2008
From: kolab-issues at intevation.de (Ludwig Reiter)
Date: Thu, 25 Sep 2008 09:19:22 +0000
Subject: [Kolab-devel] [issue3073] Enterprise35: Kontact should warn a user
	if he select one encryption type and select a key of the other type.
Message-ID: <1222334361.93.0.509688687017.issue3073@intevation.de>


New submission from Ludwig Reiter <ludwig at intevation.de>:

enterprise35 20080919.862683

Test:
AccountA has a openpgp and a SMIME key configured.
1. Switch to kmail
2. Start to send a SMIME encrypted mail to a different user. Press sending.
=> A key information pops up.
3. Change the own key and choose the OpenPGP key.
4. Send the mail.
 
Notice: no warning dialog appears, but the user sent a mail which should be
encrypted with a SMIME key with encrypted with an Openpgp key.

----------
assignedto: till
messages: 16794
nosy: bh, ludwig, osterfeld, pradeepto, till, vkrause
priority: bug
status: unread
title: Enterprise35: Kontact should warn a user if he select one encryption type and select a key of the other type.
topic: kde client, prokde35
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3073>
___________________________________________________


From kolab-issues at intevation.de  Thu Sep 25 11:32:32 2008
From: kolab-issues at intevation.de (Bernhard Reiter)
Date: Thu, 25 Sep 2008 09:32:32 +0000
Subject: [Kolab-devel] [issue3074] Freebusy trigger fails for other users's
	calenders.
Message-ID: <1222335151.99.0.649167117816.issue3074@intevation.de>


New submission from Bernhard Reiter <bernhard at intevation.de>:

Kolab Server 2.2.0,        
a pfb trigger like       
       
https://kolabserver.example.org/freebusy/trigger/test2/Calendar/subcalendar.pfb      
should work with the credentials of a user that can write the folder.      
      
To reproduce, you need users test1 and test2.      
Make sure a folder for test2 exists: Calender/subcalendar with type event.      
Give at least write access for this folder to test1.      
      
Try to trigger the fb creating with test1.      
(You can use a client like Kontact for it, Kontact does the right trigger,     
as you can see in the logs.)     
You can also use a web browser with the URL above and enter test1 credentials.   
    
a typical log entry in apache-access.log is    
 x.example.org - test1 at example.org [25/Sep/2008:10:58:27 +0200]    
"GET /freebusy/trigger/ltest2/Calendar/subcalendar.pfb HTTP/1.1" 404 407    
   
This is critical, because it will lead free-busy lists which might be  
less accurate than they should be. Depending on the usage pattern this 
can be harmful.

----------
assignedto: thomas
messages: 16796
nosy: bernhard, thomas, wilde, wrobel
priority: critical
status: unread
title: Freebusy trigger fails for other users's calenders.
topic: prokde35, server
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3074>
___________________________________________________


From kolab-issues at intevation.de  Thu Sep 25 11:59:38 2008
From: kolab-issues at intevation.de (Bernhard Reiter)
Date: Thu, 25 Sep 2008 09:59:38 +0000
Subject: [Kolab-devel] [issue3075] Extra slash ('/') in freebusy trigger for
	calender folders in "user" namespace
Message-ID: <1222336778.76.0.615578436219.issue3075@intevation.de>


New submission from Bernhard Reiter <bernhard at intevation.de>:

Kontact Version 1.2.9 (enterprise35 20080919.862683),    
triggering a folder which user test1 has write access to    
leads to a double slash in the URL, e.g. like    
GET /freebusy/trigger//john.doe/Calendar.pfb   
as can be seen in apache-access.log

----------
assignedto: till
messages: 16800
nosy: bernhard, ludwig, till, vkrause
priority: minor bug
status: unread
title: Extra slash ('/') in freebusy trigger for calender folders in "user" namespace
topic: enterprise35, kde client
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3075>
___________________________________________________


From kolab-issues at intevation.de  Thu Sep 25 12:09:50 2008
From: kolab-issues at intevation.de (Bernhard Reiter)
Date: Thu, 25 Sep 2008 10:09:50 +0000
Subject: [Kolab-devel] [issue3076] Failed pfb triggers should be dealt with
Message-ID: <1222337390.43.0.117466799883.issue3076@intevation.de>


New submission from Bernhard Reiter <bernhard at intevation.de>:

Kontact Version 1.2.9 (enterprise35 20080919.862683),    
  
after writing a calender folder, a Kolab Client must trigger  
the partial freebusy list (pfb) creation, see freebusy.txt.  
Kontact does this, but does not report failures.    
  
Here is a console out put:  
kontact: Triggering PFB update for  
imaps://test1%40example.org at kolabserver.example.org:993/user/test2/Calendar/subcalendar/ :  
getting  
https://test1%40example.org at kolabserver.example.org/freebusy/trigger//ltest2/Calendar/subcalendar.pfb  
   
the apache log shows that this request failed with status code 404. 
Retrying in a webbrowser also shows this. 
 
a) The result should be logged. 
b) I guess we should also bring up a warning which can be switched off. 
   The warning should be okay because I should be able to trigger when 
   I can write to the IMAP server.

----------
assignedto: till
messages: 16802
nosy: bernhard, ludwig, till, vkrause
priority: bug
status: unread
title: Failed pfb triggers should be dealt with
topic: kde client, prokde35
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3076>
___________________________________________________


From kolab-issues at intevation.de  Thu Sep 25 12:42:43 2008
From: kolab-issues at intevation.de (Bernhard Reiter)
Date: Thu, 25 Sep 2008 10:42:43 +0000
Subject: [Kolab-devel] [issue3077] Warning when encrypting email to
	untrusted OpenPGP recipients should always come
Message-ID: <1222339363.03.0.783561925252.issue3077@intevation.de>


New submission from Bernhard Reiter <bernhard at intevation.de>:

Kontact Version 1.2.9 (enterprise35 20080919.862683),        
when sending an email to untrusted OpenPGP keys       
you'll get a warning, this warning should always come.       
(Thus _no_ Do not show this again button!)       
       
this means the following kontactrc entry shall not be effective      
(nor there):      
| [Notification Messages]      
| not fully trusted encryption key warning=false      
     
Rationale: This is a security problem to completely disable this warning.     
There are other ways to overcome the annoyance for certain keys:    
a) build a trust path      
   a1) fully sign the key directly     
   a2) build a trust chain through the web of trust   
http://pgp.cs.uu.nl/mk_path.cgi   
b) locally sign the key in question    
     
Other information:    
Currently this warning can be switched on again, by switching all   
warning on again on the email settings -> security -> Warnings page    
on the lower right.

----------
assignedto: till
messages: 16804
nosy: bernhard, ludwig, till, vkrause
priority: bug
status: unread
title: Warning when encrypting email to untrusted OpenPGP recipients should always come
topic: kde client, kowi, prokde35
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3077>
___________________________________________________


From kolab-issues at intevation.de  Thu Sep 25 15:45:47 2008
From: kolab-issues at intevation.de (Ludwig Reiter)
Date: Thu, 25 Sep 2008 13:45:47 +0000
Subject: [Kolab-devel] [issue3079] After a restart of kontact events are not
	shown.
Message-ID: <1222350347.19.0.391655699303.issue3079@intevation.de>


New submission from Ludwig Reiter <ludwig at intevation.de>:

enterprise4 Windows
Kontact-Installer_20080923.exe (kdepimlibs: 863546, kdepim: 863546)

Test:
1. Switch to calendar plugin.
2. Create an event. Sync.
3. Restart kontact.

Notice: the event is not shown.

----------
assignedto: till
messages: 16818
nosy: bh, jstaniek, ludwig, till
priority: bug
status: unread
title: After a restart of kontact events are not shown.
topic: kde client, kowi
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3079>
___________________________________________________


From kolab-issues at intevation.de  Thu Sep 25 15:53:35 2008
From: kolab-issues at intevation.de (Ludwig Reiter)
Date: Thu, 25 Sep 2008 13:53:35 +0000
Subject: [Kolab-devel] [issue3080] Sometimes sync of kontact freezes at 100%
	for a moment.
Message-ID: <1222350814.95.0.00181420062176.issue3080@intevation.de>


New submission from Ludwig Reiter <ludwig at intevation.de>:

enterprise4 Windows
Kontact-Installer_20080923.exe (kdepimlibs: 863546, kdepim: 863546)

Sometimes I sync and kontact syncs to 100%. But then it freezes for a moment.
After that everything works again.

----------
assignedto: till
messages: 16820
nosy: bh, jstaniek, ludwig, till
priority: bug
status: unread
title: Sometimes sync of kontact freezes at 100% for a moment.
topic: kde client, kowi
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3080>
___________________________________________________


From kolab-issues at intevation.de  Thu Sep 25 15:58:46 2008
From: kolab-issues at intevation.de (Ludwig Reiter)
Date: Thu, 25 Sep 2008 13:58:46 +0000
Subject: [Kolab-devel] [issue3081] Rebuild index just of the index doubles
	its mails
Message-ID: <1222351126.63.0.643208238941.issue3081@intevation.de>


New submission from Ludwig Reiter <ludwig at intevation.de>:

enterprise4 Windows
Kontact-Installer_20080923.exe (kdepimlibs: 863546, kdepim: 863546)

I rebuilt the index of the inbox only and suddenly my mail were doubled.
I couldn't reproduce this bug.

I rebuilt the index, because I noticed that the inbox favorite displayed a
unread mail, but there was no unread mail in the folder.

----------
assignedto: till
messages: 16822
nosy: bh, jstaniek, ludwig, till
priority: bug
status: unread
title: Rebuild index just of the index doubles its mails
topic: kde client, kowi
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3081>
___________________________________________________


From kolab-issues at intevation.de  Thu Sep 25 17:07:53 2008
From: kolab-issues at intevation.de (Michael)
Date: Thu, 25 Sep 2008 15:07:53 +0000
Subject: [Kolab-devel] [issue3082] Kolab LDAP User Creation Problem
Message-ID: <1222355273.22.0.296106682933.issue3082@intevation.de>


New submission from Michael <mb at mic-net.org>:

I have installed the Kolab-Server 2.2.0 yesterday on a debian etch system. I
used the source and it installed without any problems.

But now I would create 2 Users with the same First Name and the same Last Name....
and it is not possible. Here is some explanation for this problem:

I added domain1.com and domain2.org

I created user1 at domain1.com with the First Name userfn and with the Last Name
userln. That's no problem...

But now I want to create a new user like user1 at domain.org with the First Name
userfn and with the Last Name userln (the same like the user before). 

This is now not possible, because I got always the folowing error message:
LDAP Error: could not add object cn=userfn userln ,dc=domain1,dc=com: Already exists

Could i save the users in a subdirectory like domain1.com and the others in one
like domain2.com?

Greetings, 

MIC

----------
messages: 16831
nosy: micologe
status: unread
title: Kolab LDAP User Creation Problem
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3082>
___________________________________________________


From kolab-issues at intevation.de  Fri Sep 26 02:13:24 2008
From: kolab-issues at intevation.de (Thomas H., Spielbank Berlin)
Date: Fri, 26 Sep 2008 00:13:24 +0000
Subject: [Kolab-devel] [issue3083] Hier habe ich gestern 2542.- EURO gewonnen
Message-ID: <15F743A9.D85A1D00@automakeup-walldorf.de>


New submission from Thomas H., Spielbank Berlin <yoizv at automakeup-walldorf.de>:

Thomas meinte, unglaubliche 1000.- Start-Bonus und ?ber 250 Gewinn-Spiele warten auf dich

G?ezi Bruno,

Thomas meinte, unglaubliche 1000.- Start-Bonus und ?ber 250 Gewinn-Spiele warten auf dich
http://sqyelo*.*maltytotrough*.*com/?   remove * entfernen

Gruss
Thomas H., Spielbank Berlin

----------
messages: 16839
nosy: yoizv
status: unread
title: Hier habe ich gestern 2542.- EURO gewonnen
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3083>
___________________________________________________


From kolab-issues at intevation.de  Fri Sep 26 10:16:08 2008
From: kolab-issues at intevation.de (Ludwig Reiter)
Date: Fri, 26 Sep 2008 08:16:08 +0000
Subject: [Kolab-devel] [issue3084] An organizor of an event cannot change
	his status
Message-ID: <1222416968.54.0.239174094871.issue3084@intevation.de>


New submission from Ludwig Reiter <ludwig at intevation.de>:

enterprise35 20080919.862683

An organizator of an event cannot change his status with the status field to
'decline'. But in the freebusy view he can.
Use case: Someone wants to be organizator of an event, but not attendee.

Test:
1. Switch to calendar.
2. Start to create a new event.
3. Switch to attendee tab.
4. Select the organizator.
5. Try to change the status field to 'decline'.
This doesn't work.

----------
assignedto: till
messages: 16842
nosy: bh, ludwig, osterfeld, pradeepto, till, vkrause
priority: minor bug
status: unread
title: An organizor of an event cannot change his status
topic: enterprise35, kde client
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3084>
___________________________________________________


From kolab-issues at intevation.de  Mon Sep 29 17:28:19 2008
From: kolab-issues at intevation.de (Wim Bonis)
Date: Mon, 29 Sep 2008 15:28:19 +0000
Subject: [Kolab-devel] [issue3085] cleanup ldap tree by makeing a cn= for
	every Domain
Message-ID: <1222702099.1.0.447782404678.issue3085@intevation.de>


New submission from Wim Bonis <bonis at bonis.de>:

For large companys with many domains it is very hard to navigate in the current
flat LDAP-tree.

This patch cleans up the ldap tree.

Every domain is managed in its own subtree under cn=domains.

it also uses the idea from kolab/issue1549 to change the dn to 
"mail=user at doma.in,cn=doma.in,cn=domains,dc=doma,dc=in"

----------
files: tree-ldap.diff
messages: 16855
nosy: bonis
priority: feature
status: chatting
title: cleanup ldap tree by makeing a cn= for every Domain
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3085>
___________________________________________________
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: tree-ldap.diff
Url: http://kolab.org/pipermail/kolab-devel/attachments/20080929/29a5fbca/tree-ldap.txt

From kolab-issues at intevation.de  Mon Sep 29 19:22:25 2008
From: kolab-issues at intevation.de (Orberson, Brenda)
Date: Mon, 29 Sep 2008 17:22:25 +0000
Subject: [Kolab-devel] [issue3086] Apply for loan now.
Message-ID: <670D3F13EC348A43A0ADFA6E38505F3F02927AF2@usplm203.amer.corp.eds.com>


New submission from Orberson, Brenda <brenda.orberson at eds.com>:

WILLIAMS HARRIS LOAN FIRM.   

Reliable loan offer!!!
Apply for loan now.
Here is an opportunity for those in financial problem and those who want financial up lift in their life, We give out loan at a very reasonable interest rate, we give out all kind of loan to help the nation from financial stress.
Many are suffering and needs help to improve their life status, Many are jobless and need financial help to start a business, Many needs financial help to clear their bills and debt. Here is a wise decision for you now, Just apply for loan with us and you will be very glad for the rest of your life.
Our loan offer is unsecured loan which means there is no collateral involved.
As a loan seeker you are eligible to apply for loan with the following contact below. 
Email: williamsloanmortgage3 at hotmail.com
Phone: +2347031249416
   You are required to apply with the following important details.
1. Full name...2. Sex...3. Age...4. country...5...occupation.6. Amount of loan needed
7. Duration of loan...8. phone number 
PLEASE ALL RESPONDS MUST GO TO williamsloanmortgage3 at hotmail.com

----------
messages: 16856
nosy: brenda.orberson
status: unread
title: Apply for loan now.
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3086>
___________________________________________________


From kolab-issues at intevation.de  Mon Sep 29 20:27:20 2008
From: kolab-issues at intevation.de (Richard Bos)
Date: Mon, 29 Sep 2008 18:27:20 +0000
Subject: [Kolab-devel] [issue3087] How to deal with a domain change in the
	login name?
Message-ID: <1222712839.7.0.374140163887.issue3087@intevation.de>


New submission from Richard Bos <ml at radoeka.nl>:

How to deal with a domain change in the login name, say the login
should be changed from user at domain1.tld to user1 at domain2.tld.

A discussion started at the user kolab ML list.  This issue is to track
this.  Perhaps someone comes with the start of a conversion, and this issue
may help to show the progress or its succesfull usage, etc.

The ML discussion is archived here:
http://www.kolab.org/pipermail/kolab-users/2008-September/008769.html

> > It would be nice if a script pops up, that could take care of the change.
> > Perhaps that the script can be stored / developed on the wiki or perhaps an
> > issue should be opened for this.
> >
> > Related to this is a domain name change from domain1.tld to domain2.tld.  
At
> > the end the users login name (user at domain.tld) should be changed to.  This
> > will be quite challenging...  Also in this case a supporting script would 
be
> > nice to have.
> 
> I guess the old domain should be kept. 

That might be, but company names changes happen often.  Have a look at the
financials its changes everyday there nowadays...  Take for example
abnamro, which was bought was Fortis last year, and yesterday it was sold
to Ing.  I can't believe that people want to stick with the old company
names as that might be "political" incorrect.  As such it should be
possible to rename the stored data, isn't it?
Perhaps a solution is a domain that is not tight to the company domain,
something like user at group.wr, but that is a bit weird.

> Renaming all the users does not  
> make too much sense as that also affects the data stored in IMAP. Its  
> easier to solve that by using aliases.

Ah, that is a good trick.  But in the end it might be that there will
be user data stored under e.g. abnamro, fortis and ing (see example
above).

> On the other hand this might also cause problems if you add newer  
> users in your new domain. They won't be able to share IMAP folders  
> with user created in the old domain.
> 
> So there are indeed other things to think of. Would be nice to do that  
> via a script, yes.

Ah, we agree :)

And more was added by Andrew J. Kopciuch:
Not to mention the breakage of the mail itself.  The mail spool is stored on 
disk under the domain.  That would have to be moved, and I have no idea about 
the side-effects of that.

You already mentioned the ACLs stored in IMAP, which would also be broken.  
There's also the sieve and freebusy information that would need to be moved, 
and I'm also not sure about any data changes required there.

To throw another wrench in the mix, imagine multiple slaves?

There are several pieces that are tied to the FQDN, both in LDAP, and on disk.   
It's not a trivial thing to change the FQDN.

Aliases could instantly provide a new email address, but the UID would still 
remain under the previous domain (if you just used the default UID ... which 
I assume most people would).

I realize I am not providing much help here, but my brain is flying in all 
directions thinking about what a FQDN change would require.  Large 
installations would be a massive amount of work.

----------
messages: 16858
nosy: rbos
priority: wish
status: unread
title: How to deal with a domain change in the login name?
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3087>
___________________________________________________


From kolab-issues at intevation.de  Tue Sep 30 06:33:02 2008
From: kolab-issues at intevation.de (Gunnar Wrobel)
Date: Tue, 30 Sep 2008 04:33:02 +0000
Subject: [Kolab-devel] [issue3088] Adding kolabImapServer and
	kolabFreeBusyServer in the kolab2.schema for distributed Kolab
Message-ID: <1222749182.64.0.261190262211.issue3088@intevation.de>


New submission from Gunnar Wrobel <p at rdus.de>:

I suggest adding these two entries to the kolab2.schema in order to allow for
distributed Kolab Server setups.

# fqdn of the imap server containg the actual user mailbox
attributetype ( 1.3.6.1.4.1.19419.1.1.1.19
  NAME 'kolabImapServer'
  DESC 'IMAP server which keeps the users mailbox'
  EQUALITY caseIgnoreIA5Match
  SUBSTR caseIgnoreIA5SubstringsMatch
  SYNTAX 1.3.6.1.4.1.1466.115.121.1.26{256} )

# fqdn of the free/busy server providing the users free/busy information
attributetype ( 1.3.6.1.4.1.19419.1.1.1.20
  NAME 'kolabFreeBusyServer'
  DESC 'Free/Busy server which keeps the users free/busy information.'
  EQUALITY caseIgnoreIA5Match
  SUBSTR caseIgnoreIA5SubstringsMatch
  SYNTAX 1.3.6.1.4.1.1466.115.121.1.26{256} )

----------
assignedto: bernhard
messages: 16859
nosy: bernhard, martin, thomas, wilde, wrobel
priority: feature
status: unread
title: Adding kolabImapServer and kolabFreeBusyServer in the kolab2.schema for distributed Kolab
topic: server
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3088>
___________________________________________________


From wrobel at pardus.de  Tue Sep 30 06:34:11 2008
From: wrobel at pardus.de (Gunnar Wrobel)
Date: Tue, 30 Sep 2008 06:34:11 +0200
Subject: [Kolab-devel] Modifying the LDAP user representation
	for	a	distributed Kolab server system?
In-Reply-To: <200808261238.12841.bernhard@intevation.de>
References: <871w1drtk6.fsf@home.pardus.de>
	<200808140949.59704.bernhard@intevation.de>
	<20080815064150.15837km92i9ik18o@devmail.pardus.de>
	<200808261238.12841.bernhard@intevation.de>
Message-ID: <20080930063411.15703wdf2uor6bsw@webmail.pardus.de>

Quoting Bernhard Reiter <bernhard at intevation.de>:

> On Friday 15 August 2008 06:41, Gunnar Wrobel wrote:
>> Quoting Bernhard Reiter <bernhard at intevation.de>:
>> > On Tuesday 29 July 2008 14:05, Gunnar Wrobel wrote:
>> >> Inventing a new Kolab user LDAP attribute for each and every service
>> >> of the Kolab server to support such splitting seems like an overhead
>> >> and people did not like the suggestion too much.
>> >>
>> >> So let me suggest an alternative by using the existing
>> >> "kolabHomeserver" attribute. Would it be okay to extend its syntax to
>> >> allow for several settings like:
>> >>
>> >>   "example.org"
>> >>   "MTA:smtp.example.org"
>> >>   "IMAP:imap.example.org"
>> >>   "FreeBusy:fb.example.org"
>> >>
>> >> The default would be the entry without "prefix:" but it would be
>> >> possible to provide redirects for specific services.
>> >
>> > This looks quite ugly to me. Somehow inventing more parsing within
>> > an LDAP attribute really feel wrong to me.
>> > So if we need the attributes, we can for sure come up with enough for
>> > them.
>>
>> Okay, I agree with the parsing thing.
>>
>> > I am not sure that we need it per user, though.
>>
>> p at rdus does :) If you have an array of IMAP servers behind an MTA
>> layer the MTA layer should actually know which IMAP server to deliver
>> to. And that is per user. I know this is not possible with
>> Kolab2/OpenPKG at the moment but such distributed setup are feasible
>> with Kolab.
>
> Ah, you also want to split up below one homeserver.
> Of course, if you want to do this, it needs to be saved somewhere.
> For most deployment I would normally recommend having one imap server (which
> can be a cluster) per homeserver. It does not hurt to have one MTA per IMAP
> server and might help in many situations. I guess this is why I did not get
> the idea.

Created a bug for the additional "kolab*Server" entries in the kolab schema:

https://www.intevation.de/roundup/kolab/issue3088

>
>> > For the user, most should be transparent (means: not visible).
>>
>> The admin sets this stuff in the web admin frontend. It should
>> obviously not be editable by the user as this concerns the server
>> infrastructure and is no user setting.
>>
>> > This is why I am also against putting anything server specific in the
>> > login information. This could change during the lifetime of an account.
>>
>> Login information? Sorry, didn't understand this comment. Can you clarify?
>
> I believe I've refered to the upcoming point where I saw "USER:PASS at SERVER"
> and I wanted to outrule this as part of an LDAP entry.
>>
>> >> If I consider the point Bernhard mentioned recently concerning
>> >> splitted IMAP storage per user it might also make sense to have a
>> >> syntax like
>> >>  "imap://USER:PASS at SERVER"
>> >
>> > For what in particular?
>> > The splitted IMAP storage will only be known the the user's client
>> > mostly.
>>
>> So the user would set the storage spaces in Kontact and in the Kolab
>> web client again?
>
> Yes.
> Even if we find a desired way of saving client configuration on one server
> somehow.
>
>> Storing that in LDAP would remove this redundancy or not?
>
> It would, but it would also defeat the security aspect of the idea.
> If you have server A and server B, you would not want admin of server
> A to be able to log into server B to have some separation. :)
> So putting credentials in the directory service of server A
> is not that helpful.
>
>
>
> --
> Managing Director - Owner: www.intevation.net       (Free Software Company)
> Germany Coordinator: fsfeurope.org. Coordinator: www.Kolab-Konsortium.com.
> Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998
> Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
>



-- 
______ http://kdab.com _______________ http://kolab-konsortium.com _

p at rdus Kolab work is funded in part by KDAB and the Kolab Konsortium

____ http://www.pardus.de _________________ http://gunnarwrobel.de _
E-mail : p at rdus.de                                 Dr. Gunnar Wrobel
Tel.   : +49 700 6245 0000                          Bundesstrasse 29
Fax    : +49 721 1513 52322                          D-20146 Hamburg
--------------------------------------------------------------------
    >> Mail at ease - Rent a kolab groupware server at p at rdus <<
--------------------------------------------------------------------


----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.


From kolab-issues at intevation.de  Tue Sep 30 06:47:15 2008
From: kolab-issues at intevation.de (Alverta Kira)
Date: Tue, 30 Sep 2008 04:47:15 +0000
Subject: [Kolab-devel] [issue3089] University Dip1ome/Degree based on Work
	Experience, No Exam/test ncqyp 7x
In-Reply-To: <b7d401c91e5d$40d587e9$5e26b1a6@207sru2>
Message-ID: <1222748393.0093@televar.com>


New submission from Alverta Kira <alverta.kira_pk at televar.com>:

Would you like to:      
Increase Your salary?   
Increase your desirability?  
Increase your Ability to find other work?      
Increase Your marketability?  

Call : 1-718-989-5740 (Inside USA)     
      +1-718-989-5740 (Outside USA)       

is an University Degree/Dip1oma holding You back?   
Call us to Inquire About our Degree programs.   

Whether You are Seeking a Bacheelors, M B A or P h D      
We can Provide you credentials to Get you better career   
No study, test, Exam or coursework required     

Call : 1-718-989-5740 (Inside USA)        
      +1-718-989-5740 (Outside USA)       

Leave us your "Name, country & Phone no. with Countrycode"     

We will get back To you real soon

----------
messages: 16860
nosy: alverta.kira_pk, great-er-list-bounces
status: unread
title: University Dip1ome/Degree based on Work Experience, No Exam/test ncqyp 7x
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3089>
___________________________________________________


From kolab-issues at intevation.de  Tue Sep 30 10:45:12 2008
From: kolab-issues at intevation.de (basysKom GmbH)
Date: Tue, 30 Sep 2008 08:45:12 +0000
Subject: [Kolab-devel] [issue3090] GMT-Time is not set correct for germany
	OL invitation
Message-ID: <1222764312.35.0.0849442132913.issue3090@intevation.de>


New submission from basysKom GmbH <kontactbugs at basyskom.de>:

If there is a Vcal-Invitation from an Outlook Account and it is added to the
calendar the meeting time is wrong because of GMT.

In Germany is GMT+2hours the set time. In the Vcal is the GMT-zone described.
Why is this not considered before add the meeting to the calendar?

----------
messages: 16861
nosy: basyskom
priority: bug
status: unread
title: GMT-Time is not set correct for germany OL invitation
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3090>
___________________________________________________


From kolab-issues at intevation.de  Tue Sep 30 10:51:52 2008
From: kolab-issues at intevation.de (basysKom GmbH)
Date: Tue, 30 Sep 2008 08:51:52 +0000
Subject: [Kolab-devel] [issue3091] cal.ics can't reopened after accepted
	meeting
Message-ID: <1222764712.6.0.537623605794.issue3091@intevation.de>


New submission from basysKom GmbH <kontactbugs at basyskom.de>:

The file cal.ics attached to the E-Mail can't be open again after accepting a
meeting.

----------
messages: 16863
nosy: basyskom
status: unread
title: cal.ics can't reopened after accepted meeting
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3091>
___________________________________________________


From kolab-issues at intevation.de  Tue Sep 30 14:45:46 2008
From: kolab-issues at intevation.de (Ludwig Reiter)
Date: Tue, 30 Sep 2008 12:45:46 +0000
Subject: [Kolab-devel] [issue3092] While kontact is creating a new local
	distribution list,
	it should store contacts from LDAP to distlist folder.
Message-ID: <1222778746.68.0.60026790071.issue3092@intevation.de>


New submission from Ludwig Reiter <ludwig at intevation.de>:

tested with enterprise4 Windows:
Kontact-Installer_20080923.exe (kdepimlibs: 863546, kdepim: 863546)

If a user has two contact resource folders and creates a new local distribution
list and he uses contacts from a LDAP server for the dist list, he is asked many
times, where to put the contacts from the LDAP server.

Imo, the contacts from a LDAP server should be put in the folder of the local
distribution list, if needed, so that only one resource choose dialog pops up.

----------
assignedto: till
messages: 16865
nosy: bh, jstaniek, ludwig, till
priority: bug
status: unread
title: While kontact is creating a new local distribution list, it should store contacts from LDAP to distlist folder.
topic: kde client, kowi
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3092>
___________________________________________________


From kolab-issues at intevation.de  Tue Sep 30 14:54:03 2008
From: kolab-issues at intevation.de (Ludwig Reiter)
Date: Tue, 30 Sep 2008 12:54:03 +0000
Subject: [Kolab-devel] [issue3093] Shortcuts for day names are not
	translated into German.
Message-ID: <1222779243.43.0.359825194493.issue3093@intevation.de>


New submission from Ludwig Reiter <ludwig at intevation.de>:

enterprise4 Windows
Kontact-Installer_20080923.exe (kdepimlibs: 863546, kdepim: 863546)

Shortcuts for day names in the calendar view are not translated into German.
(e.g. Tue (for Tuesday) should be Di (for Dienstag))

----------
assignedto: till
messages: 16866
nosy: bh, jstaniek, ludwig, till
priority: minor bug
status: unread
title: Shortcuts for day names are not translated into German.
topic: enterprise4, kde client, kowi
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3093>
___________________________________________________


From kolab-issues at intevation.de  Tue Sep 30 15:02:21 2008
From: kolab-issues at intevation.de (Ludwig Reiter)
Date: Tue, 30 Sep 2008 13:02:21 +0000
Subject: [Kolab-devel] [issue3094] Cannot accept a resource with double
	click in the resource chooser dialog
Message-ID: <1222779741.2.0.343324501053.issue3094@intevation.de>


New submission from Ludwig Reiter <ludwig at intevation.de>:

enterprise4 Windows
Kontact-Installer_20080923.exe (kdepimlibs: 863546, kdepim: 863546)

Double-click on a resource in the resource chooser dialog, doesn't accept this
resource and doesn't close the dialog.

Test:
Testaccount with two calendar resources.
1. Create a new event.
2. Doubleclick on a resource in the resource chooser dialog.

----------
assignedto: till
messages: 16867
nosy: bh, jstaniek, ludwig, till
priority: minor bug
status: unread
title: Cannot accept a resource with double click in the resource chooser dialog
topic: kde client, kowi
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3094>
___________________________________________________


From kolab-issues at intevation.de  Tue Sep 30 15:10:36 2008
From: kolab-issues at intevation.de (Ludwig Reiter)
Date: Tue, 30 Sep 2008 13:10:36 +0000
Subject: [Kolab-devel] [issue3095] After scrolling in the side-by-side view
	the different calendar lines don't fit anymore
Message-ID: <1222780235.93.0.305171960348.issue3095@intevation.de>


New submission from Ludwig Reiter <ludwig at intevation.de>:

enterprise4 Windows
Kontact-Installer_20080923.exe (kdepimlibs: 863546, kdepim: 863546)

Test:
( Two calendar ressources needed)
1. Switch to the calendar plugin
2. Activate sidebyside view.
3. Scroll to the botton.
Notice: The lines of calendar columns don't fit anymore.

----------
assignedto: till
messages: 16868
nosy: bh, jstaniek, ludwig, till
priority: minor bug
status: unread
title: After scrolling in the side-by-side view the different calendar lines don't fit anymore
topic: kde client, kowi
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3095>
___________________________________________________


From kolab-issues at intevation.de  Tue Sep 30 15:42:04 2008
From: kolab-issues at intevation.de (Diego M. Vadell)
Date: Tue, 30 Sep 2008 13:42:04 +0000
Subject: [Kolab-devel] [issue3096] Address book aliases shouldn't redirect
	outgoing mails
Message-ID: <1222782124.45.0.323999261761.issue3096@intevation.de>


New submission from Diego M. Vadell <dvadell at linuxclusters.com.ar>:

I added an (external) contact in the Addressbook. This guy has a mail 
address, pp at hotmail.com, and an alias, pp at yahoo.com. But when I send and email 
to pp at yahoo.com.ar, the email gets rewritten and goes to pp at hotmail.com.

    I expected the mail to go to the alias, because it is external (i.e. not in 
my Kolab installation). It confuses users (and me). It even makes 
troubleshooting a bit more difficult.

    Thanks.

 -- Diego

----------
messages: 16869
nosy: dvadell
priority: bug
status: unread
title: Address book aliases shouldn't redirect outgoing mails
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3096>
___________________________________________________


From kolab-issues at intevation.de  Tue Sep 30 21:30:10 2008
From: kolab-issues at intevation.de (Rhea Jean)
Date: Tue, 30 Sep 2008 19:30:10 +0000
Subject: [Kolab-devel] [issue3097] University Dip1ome/Degree based on Work
	Experience, No Exam/test vpj tw8
In-Reply-To: <beb701c9225b$dbd32dff$a7a90044@ry8v7ne>
Message-ID: <1222801585.4879@glassoc.com>


New submission from Rhea Jean <jean_dh at glassoc.com>:

Would you like to:     
Increase Your salary?    
Increase your desirability?       
Increase your Ability to find other work?     
Increase Your marketability?     

Call : 1-718-989-5740 (Inside USA)        
      +1-718-989-5740 (Outside USA)       

is an University Degree/Dip1oma holding You back?      
Call us to Inquire About our Degree programs.   

Whether You are Seeking a Bacheelors, M B A or P h D     
We can Provide you credentials to Get you better career        
No study, test, Exam or coursework required       

Call : 1-718-989-5740 (Inside USA)        
      +1-718-989-5740 (Outside USA)  

Leave us your "Name, country & Phone no. with Countrycode"     

We will get back To you real soon

----------
messages: 16875
nosy: emanuel, jean_dh
status: unread
title: University Dip1ome/Degree based on Work Experience, No Exam/test vpj tw8
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3097>
___________________________________________________


From bogus@does.not.exist.com  Fri Sep 26 23:08:02 2008
From: bogus@does.not.exist.com ()
Date: Fri, 26 Sep 2008 21:08:02 -0000
Subject: No subject
Message-ID: <mailman.1.1226076849.2132.kolab-devel@kolab.org>

Triggering on a calendar folder without admin rights with issue3074.patch
applied on a plain 2.2.0 server works fine (and breaks again if I revert th=
e patch).

But I have noticed that /kolab/var/kolab-freebusy/log/php-error.log logs th=
e
following error when the other user triggers:
PHP Notice:  Unknown: Permission denied (errflg=3D2) in Unknown on line 0

-----

Note by wrobel:

getACL() in Kolab_Storage/lib/Horde/Kolab/Storage/Folder.php calls
$acl =3D $imap->getACL($this->name) unconditionally. The call will fail if =
we
don't have admin rights on the folder. So we should probably always call
getMyRights instead and only follow with getACL if we really have admin rig=
hts.
This would mean two instead of one IMAP access. =


We could also try to suppress the error message in the getACL call.

----------
assignedto: wrobel
messages: 17477
nosy: bernhard, thomas, wilde, wrobel
priority: minor bug
status: unread
title: Accessing foreign folders elicits PHP Notice:  Unknown: Permission d=
enied
topic: web client
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3221>
___________________________________________________


From bogus@does.not.exist.com  Fri Sep 26 23:08:02 2008
From: bogus@does.not.exist.com ()
Date: Fri, 26 Sep 2008 21:08:02 -0000
Subject: No subject
Message-ID: <mailman.2.1226822351.2132.kolab-devel@kolab.org>

I have a strange problem. We had an mail-address with a forward to an =

other mail-address. Then we deleted the first mail-address and created a =

distribution list with the same name and several recipients. The strange =

thing is, that everytime a mail gets sent to the distribution list, only =

the recipient of the old mail address gets the mail. I also deleted the =

distribution list and made a slapcat. There was no name of the =

distribution list or old mail address anymore, but the old reciepient =

still got the mail. I checked the postfix-log for this behaviour. With the =

distribution list created the slapcat told me that this list all members =

it should have. I restarted all services and also rebooted the server at =

night, but it didn=C2=B4t help.

Short form of my descriptin:

name1 (address) -> recepient1
name1 gets deleted
name1 (as distribution list) is created: with recepeint1, reciepient2 and =

reciepient3
mail to name1 -> mail is only sent to reciepient1

Response by Alain Spineux:

The forward is done by cyrus imap at delivery, by a sieve script. (
look in lmtpd.log )
The sieve scrip is attached to a mailbox and probably not deleted at
deletion of the mailbox.

Kolabd could maybe delete such script at creation and/or deletion time
to prevent this kind of problem





I consider this a bug and believe kolabd should indeed also clear sieve scr=
ipts
on user deletion.

----------
assignedto: wrobel
messages: 17593
nosy: bernhard, martin, thomas, wilde, wrobel
priority: bug
status: unread
title: Kolabd does not clear sieve scripts on deletion of a user
topic: server
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3239>
___________________________________________________


From bogus@does.not.exist.com  Fri Sep 26 23:08:02 2008
From: bogus@does.not.exist.com ()
Date: Fri, 26 Sep 2008 21:08:02 -0000
Subject: No subject
Message-ID: <mailman.3.1227631636.2132.kolab-devel@kolab.org>

e
MAILER-DAEMON)):

php-kolab/Kolab_Filter/kolab-issue3260.patch should be merged before the re=
lease
of Kolab Server 2.2.1

----------
assignedto: wrobel
messages: 17760
nosy: thomas, wrobel
priority: important
status: unread
title: php-kolab/Kolab_Filter/kolab-issue3260.patch
upstream: Horde
_________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/merge85>
_________________________________________________


From bogus@does.not.exist.com  Fri Sep 26 23:08:02 2008
From: bogus@does.not.exist.com ()
Date: Fri, 26 Sep 2008 21:08:02 -0000
Subject: No subject
Message-ID: <mailman.4.1228294584.2132.kolab-devel@kolab.org>

It seems it's working without I lost mail from mailing lists. There must be
anything wrong in the assertion:
"Always reject the message. Note that enabling this setting will make the
server reject any mail with non-matching sender and From header if the send=
er
is an account on this server. This is known to cause trouble for example wi=
th
mailinglists. "

http://kolab.org/pipermail/kolab-users/2008-December/009112.html

I think I remember we had a bug about the Kolab_Filter policy though I didn=
't
find it now.

I think we should maybe clarify the inner workings of Kolab_Filter in the w=
iki
and link to that in the kolab webadmin.

----------
assignedto: bernhard
messages: 17887
nosy: bernhard, martin, thomas, wilde, wrobel
priority: minor bug
status: unread
title: Document the Kolab_Filter policies
topic: docs, filter
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3287>
___________________________________________________


From bogus@does.not.exist.com  Fri Sep 26 23:08:02 2008
From: bogus@does.not.exist.com ()
Date: Fri, 26 Sep 2008 21:08:02 -0000
Subject: No subject
Message-ID: <mailman.5.1229634736.2132.kolab-devel@kolab.org>

Retrieving an ics file via the subscription link does not work for shared
folders with a space in the name for me, though.  Using IE as a
troubleshooting tool to connect to the Debian 4.0 binary install of 2.2:

Shared folder name: mycal =

type: events
https://kolab.mydomain.com/horde/rpc.php/kronolith/shared.mycal.ics
This works fine and prompts me to download the ics file through IE

Shared folder name: my calendar     =

type: events
https://kolab.mydomain.com/horde/rpc.php/kronolith/shared.my%20calendar.ics
This gives a blank response with no file download prompt

I think I might have made the phantom folder during 2.2-rc3 and done an
upgrade from that to 2.2 which I could easily have done incorrectly to
prevent the issue (I might have marked it to delete then done the upgrade
before it ran the cleanup or something).  Since that is isolated to the one
phantom folder and I plan on doing a clean wipe and fresh install with 2.2.=
1
it probably doesn't need any more attention. =


Info for if you are just interested, though: folder appears in horde as:
[anonymous]shared.doc surgery

I cannot delete it while logged on to the horde as my only user account nor
as the manager logon, and it does not appear in shared folders in the
web-admin interface logged on as the default manager account.  I created a
maintainer account and administrator account, neither of which even has the
calendar show up as visible either in horde or the web-admin interface for
kolab.

----------
assignedto: wrobel
messages: 18138
nosy: bernhard, thomas, wilde, wrobel
priority: bug
status: unread
title: Ics files via Horde do not work for folders containing spaces in the=
 name
topic: server, web client
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3330>
___________________________________________________