Horde

From delonly at gmail.com Sun Mar 1 13:16:43 2009 From: delonly at gmail.com (Del) Date: Sun, 01 Mar 2009 13:16:43 +0100 Subject: Kontact for MacOS experience (continued) In-Reply-To: <200902281021.20835.michael@pasdziernik.net> References: <27599d0a.1c99919.bc6a312.6741@bynari.net> <200902281021.20835.michael@pasdziernik.net> Message-ID: <1235909803.19884.30.camel@black> Finally had some more time to test Kontact for Mac, and I am in dire need of some basic input. First a little re-cap. Initial testing can be found here: http://kolab.org/pipermail/kolab-users/2009-February/009449.html Wiki-page for the client can be found here: https://wiki.kolab.org/index.php/Kontact_for_MacOS_(beta-huge-debug) One note, I only had a Kolab 2.2 server install to test on this time around, while I had a CVS updated 2.2.1 beta available last time. Should also note that I feel like Bambi on ice with Macs, so bear with me if some stupidities appear. It is however the same MacBook as last time. What works: -Mail and calender works as expected. -LDAP look-up also works nicely. -kolabwizard (as long as mail address and login name are identical) Critical issues: -I was totally uncapable of un-installing Kontact properly (removing the /opt folder entirely and the .kde folder in the users directory was not sufficient for removing user information (and the Bambi factor kicked in hard when I found no | on the keyboard to do piping with, handcuffing my attemps to chase down file locations). This needs to be documented on the wiki, as one wrong key-stroke running kolabwizard is enough to put people in a need-to-reinstall-the-whole-system mode. -kolabwizard only add new users when ran repeatedly, no option to remove the existing (which makes for a messy testing environment when combined with the point above). -I could not get free/busy working, i.e. I could not see others busy infromation when scheduling a meeting (but I will need to resolve the uninstall above to come any further on that one now). Non-critical (but still important) -Kontact tray process sometimes does not start, I have not seen a pattern yet (another Bambi issue is that I have no right button on the mouse, so trying to close the tray process results in kmail+korganizer windows popping up again). -I did see some artifacts with Norwegian letters ?, ? and ?, but that may actually be tributed to Horde, it actually seemed OK for what was sent from Kontact on the Mac. I have on general question regarding Kontact, which may be illposted here. Do we have functionality in Kontact to view others calendar in the calendar view? Cheers, Del From i.bin at dah.am Sun Mar 1 21:10:57 2009 From: i.bin at dah.am (Franz Skale) Date: Sun, 01 Mar 2009 21:10:57 +0100 Subject: Segfault on webclient ! Message-ID: <49AAEBD1.6070208@dah.am> Hi all, now i am really out of options and so i consult you a state of the last resort. I really tried all debugging but things don't start to work. Now after running 2 years without any probs (Updates of the machine a distribution MADE ID NECESSARY TO UPGRADE KOLAB), but after 2 days of work i give up. I had severe troubles to get beta1 working (segfaults in postfix smtp etc.) but now all in working except the webclient. Apache segfaults before reaching the login screen. I also tried with external apache+php and got a little bit further but didn't succeed anyway. Current OS: Debian Lenny amd64 (Host has 4 GB RAM and multigigE network connection). Apache2 Debian Lenny: On external client in can login but after the login succeeded the Browser windows is blank. The source rerfers to: (Get error 500 without a segfault of apache2 (lenny)) Horde Horde Log: Last messages in horde log: (Merged Source from kolab. Wrong perms checked with set_perms.sh) Mar 01 20:11:17 HORDE [debug] [imp] Max memory usage: 4980736 bytes [pid 12474 on line 339 of "/var/www/horde/lib/Horde/Registry.php"] Mar 01 20:11:18 HORDE [debug] [kronolith] Hook _horde_hook_share_init in application horde not called. [pid 11623 on line 1683 of "/var/www/horde/lib/Horde.php"] Mar 01 20:11:18 HORDE [debug] [kronolith] Max memory usage: 5767168 bytes [pid 11623 on line 339 of "/var/www/horde/lib/Horde/Registry.php"] Max Mem is set from 64 to 512 M without any changes. On kolab the apache segfaults bevor anything is loaded: open("/kolab/lib/libdb-4.6.so", O_RDONLY) = -1 ENOENT (No such file or directory) open("/kolab/lib/libdb-4.6.so", O_RDONLY) = -1 ENOENT (No such file or directory) open("/kolab/local/lib/libdb-4.6.so", O_RDONLY) = -1 ENOENT (No such file or directory) open("tls/x86_64/libdb-4.6.so", O_RDONLY) = -1 ENOENT (No such file or directory) open("tls/libdb-4.6.so", O_RDONLY) = -1 ENOENT (No such file or directory) open("x86_64/libdb-4.6.so", O_RDONLY) = -1 ENOENT (No such file or directory) open("libdb-4.6.so", O_RDONLY) = -1 ENOENT (No such file or directory) open("/lib/libdb-4.6.so", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/lib/libdb-4.6.so", O_RDONLY) = 16 read(16, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\200\240\2\0\0\0\0\0@"..., 832) = 832 fstat(16, {st_mode=S_IFREG|0644, st_size=1348776, ...}) = 0 mmap(NULL, 3444864, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 16, 0) = 0x7f457dced000 mprotect(0x7f457de31000, 2097152, PROT_NONE) = 0 mmap(0x7f457e031000, 20480, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 16, 0x144000) = 0x7f457e031000 mmap(0x7f457e036000, 128, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7f457e036000 close(16) = 0 fcntl(0, F_GETFD) = 0 fcntl(0, F_SETFD, FD_CLOEXEC) = 0 --- SIGSEGV (Segmentation fault) @ 0 (0) --- +++ killed by SIGSEGV +++ Object strings of mod_php.so: dba_open_db4 dba_close_db4 dba_fetch_db4 dba_update_db4 dba_exists_db4 dba_delete_db4 dba_firstkey_db4 dba_nextkey_db4 dba_optimize_db4 dba_sync_db4 dba_info_db4 Configure string provided by kolab installer: './configure' '--prefix=/kolab' '--sysconfdir=/kolab/etc/apache' '--with-config-file-path=/kolab/etc/apache' '--libdir=/kolab/lib/php' '--disable-all' '--enable-pdo' '--with-pdo-sqlite' '--with-sqlite=/kolab' '--without-mysql' '--without-pgsql' '--with-gd=/kolab' '--with-jpeg-dir=/kolab' '--with-png-dir=/kolab' '--disable-fastcgi' '--with-db4=/kolab' '--disable-debug' '--with-zlib=/kolab' '--with-zlib-dir=/kolab' '--with-openssl=/kolab' '--with-ldap=/kolab' '--enable-session' '--with-mm=/kolab' '--with-pcre-regex=/kolab' '--with-gettext=/kolab' '--with-imap=/kolab' '--with-imap-ssl=/kolab' '--disable-json' '--enable-xml' '--enable-libxml' '--with-libxml-dir=/kolab' '--without-xsl' '--enable-dom' '--with-mhash=/kolab' '--with-mcrypt=/kolab' '--enable-ctype' '--with-pear=/kolab/lib/php' '--disable-simplexml' '--enable-mbregex' '--enable-mbstring' '--with-iconv=/kolab' '--disable-spl' '--without-tidy' '--with-apxs2=/kolab/sbin/apxs' '--disable-cli' '--disable-cgi' '--enable-force-cgi-redirect' '--enable-discard-path' So i think, that --with-db4=/kolab should take the statically linked libdb.a and should not open the wrong version from debian which is 4.6. Kolab uses 4.5 so could that be the problem ? Linker Problem of apache-php ? Any help would be very appreciated. Kind regards Franz P.S.:Now i know what it means: Never change a running system:-< From wrobel at pardus.de Sun Mar 1 22:07:17 2009 From: wrobel at pardus.de (Gunnar Wrobel) Date: Sun, 01 Mar 2009 22:07:17 +0100 Subject: Can't delete users In-Reply-To: References: <4994592E.3070505@yugm.org> <200902130905.30828.bernhard@intevation.de> Message-ID: <20090301220717.13795m8ozux4goow@webmail.pardus.de> Quoting Enrico Zaffaroni : > I had to delete awaiting users with more than one KolabDeleteFlag by > hand with ldapdelete. But users deleted with the correct > configuration are then removed correctly. I guess this would be a bug then. @bernhard: I didn't analyze this in detail now but it did not meet your expectation right? If that's correct I'd open a bug. Cheers, Gunnar > > 2009/2/13 Bernhard Reiter dir=\"ltr\"> > 0pt 0.8ex; padding-left: 1ex;\" class=\"gmail_quote\"> class=\"im\">On Donnerstag, 12. Februar 2009, Paul Douglas Franklin > wrote: > > After deleting the Kolab hostnames, did you have to take any > further > > steps to get it to delete those which had been sitting > awaiting cleanup? > It should not be neccessary. > The kolabd on the kolabHomeServer will delete itself when it is > last. > At maximum a kolabd restart would be indicated. > > > Enrico Zaffaroni wrote: > > > Hi Bernhard, sorry for the delay. I have been able to > solve the > > > problem today. My client, that has manager account on the > admin > > > interface, added some more "Kolab hostnames" > under the services page, > > > probably thinking to simply add more names to a single > host. So the > > > system marked the record to be deleted from more than a > single host, > > > and deletion obviously failed. > > > I deleted the redundants name and now deletion works > properly. > > > Anyway thank you for the help, it has been your answers > that indicated > > > to me to look at the KolabDeleteFlag field, where I > discovered more > > > hosts than expected. > > -- > Managing Director - > Owner: href=\"http://www.intevation.net\">www.intevation.net (Free > Software Company) > Germany Coordinator: href=\"http://fsfeurope.org\">fsfeurope.org. Coordinator: target=\"_blank\" > href=\"http://www.Kolab-Konsortium.com\">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 > _______________________________________________ > Kolab-users mailing list > Kolab-users at kolab.org[2] > href=\"https://kolab.org/mailman/listinfo/kolab-users\">https://kolab.org/mailman/listinfo/kolab-users -- ------------- Enrico Zaffaroni ezaffa at gmail.com[3] -- ____ 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 << -------------------------------------------------------------------- Links: ------ [1] mailto:bernhard at intevation.de [2] mailto:Kolab-users at kolab.org [3] mailto:ezaffa at gmail.com ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. From i.bin at dah.am Mon Mar 2 01:26:59 2009 From: i.bin at dah.am (Franz Skale) Date: Mon, 02 Mar 2009 01:26:59 +0100 Subject: Segfault on webclient ! (Solved) In-Reply-To: <49AAEBD1.6070208@dah.am> References: <49AAEBD1.6070208@dah.am> Message-ID: <49AB27D3.3050607@dah.am> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Now i finally solved it on my own. The problem was , as mentioned above, that the libdb-4.5 version of kolab doesn't work without threads on apache2 threaded. This is the same problem as mentioned in my fist post 2006 ! So, i build a statically linked debian version of db-4.5 and changed the --with-db4=/kolab to the statically linked target. Now ot works but how to migrate old (incompatible) syncKolab adresses ?!? Perhaps anyone can give a hint on it. kind regards Franz Franz Skale schrieb: > Hi all, now i am really out of options and so i consult you a state > of the last resort. I really tried all debugging but things don't > start to work. Now after running 2 years without any probs (Updates > of the machine a distribution MADE ID NECESSARY TO UPGRADE KOLAB), > but after 2 days of work i give up. I had severe troubles to get > beta1 working (segfaults in postfix smtp etc.) but now all in > working except the webclient. Apache segfaults before reaching the > login screen. I also tried with external apache+php and got a > little bit further but didn't succeed anyway. Current OS: Debian > Lenny amd64 (Host has 4 GB RAM and multigigE network connection). > > Apache2 Debian Lenny: On external client in can login but after the > login succeeded the Browser windows is blank. The source rerfers > to: (Get error 500 without a segfault of apache2 (lenny)) html PUBLIC "-//W3C//DTD XHTML 1.0 Frameset//EN" > "DTD/xhtml1-frameset.dtd"> href="/horde/themes/silver/graphics/favicon.ico" /> > Horde > > > scrolling="auto" noresize="noresize" /> src="https://dah.am/horde/?frameset_loaded=1" scrolling="auto" > noresize="noresize" /> > > Horde Log: Last messages in horde log: (Merged Source from > kolab. Wrong perms checked with set_perms.sh) Mar 01 20:11:17 HORDE > [debug] [imp] Max memory usage: 4980736 bytes [pid 12474 on line > 339 of "/var/www/horde/lib/Horde/Registry.php"] Mar 01 20:11:18 > HORDE [debug] [kronolith] Hook _horde_hook_share_init in > application horde not called. [pid 11623 on line 1683 of > "/var/www/horde/lib/Horde.php"] Mar 01 20:11:18 HORDE [debug] > [kronolith] Max memory usage: 5767168 bytes [pid 11623 on line 339 > of "/var/www/horde/lib/Horde/Registry.php"] > > Max Mem is set from 64 to 512 M without any changes. > > On kolab the apache segfaults bevor anything is loaded: > open("/kolab/lib/libdb-4.6.so", O_RDONLY) = -1 ENOENT (No such file > or directory) open("/kolab/lib/libdb-4.6.so", O_RDONLY) = -1 ENOENT > (No such file or directory) open("/kolab/local/lib/libdb-4.6.so", > O_RDONLY) = -1 ENOENT (No such file or directory) > open("tls/x86_64/libdb-4.6.so", O_RDONLY) = -1 ENOENT (No such file > or directory) open("tls/libdb-4.6.so", O_RDONLY) = -1 ENOENT > (No such file or directory) open("x86_64/libdb-4.6.so", O_RDONLY) > = -1 ENOENT (No such file or directory) open("libdb-4.6.so", > O_RDONLY) = -1 ENOENT (No such file or directory) > open("/lib/libdb-4.6.so", O_RDONLY) = -1 ENOENT (No such file > or directory) open("/usr/lib/libdb-4.6.so", O_RDONLY) = 16 read(16, > > "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\200\240\2\0\0\0\0\0@"..., > 832) = 832 fstat(16, {st_mode=S_IFREG|0644, st_size=1348776, ...}) > = 0 mmap(NULL, 3444864, PROT_READ|PROT_EXEC, > MAP_PRIVATE|MAP_DENYWRITE, 16, 0) = 0x7f457dced000 > mprotect(0x7f457de31000, 2097152, PROT_NONE) = 0 > mmap(0x7f457e031000, 20480, PROT_READ|PROT_WRITE, > MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 16, 0x144000) = 0x7f457e031000 > mmap(0x7f457e036000, 128, PROT_READ|PROT_WRITE, > MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7f457e036000 > close(16) = 0 fcntl(0, F_GETFD) > = 0 fcntl(0, F_SETFD, FD_CLOEXEC) = 0 --- SIGSEGV > (Segmentation fault) @ 0 (0) --- +++ killed by SIGSEGV +++ > > > Object strings of mod_php.so: dba_open_db4 dba_close_db4 > dba_fetch_db4 dba_update_db4 dba_exists_db4 dba_delete_db4 > dba_firstkey_db4 dba_nextkey_db4 dba_optimize_db4 dba_sync_db4 > dba_info_db4 > > Configure string provided by kolab installer: './configure' > '--prefix=/kolab' '--sysconfdir=/kolab/etc/apache' > '--with-config-file-path=/kolab/etc/apache' > '--libdir=/kolab/lib/php' '--disable-all' '--enable-pdo' > '--with-pdo-sqlite' '--with-sqlite=/kolab' '--without-mysql' > '--without-pgsql' '--with-gd=/kolab' '--with-jpeg-dir=/kolab' > '--with-png-dir=/kolab' '--disable-fastcgi' '--with-db4=/kolab' > '--disable-debug' '--with-zlib=/kolab' '--with-zlib-dir=/kolab' > '--with-openssl=/kolab' '--with-ldap=/kolab' '--enable-session' > '--with-mm=/kolab' '--with-pcre-regex=/kolab' > '--with-gettext=/kolab' '--with-imap=/kolab' > '--with-imap-ssl=/kolab' '--disable-json' '--enable-xml' > '--enable-libxml' '--with-libxml-dir=/kolab' '--without-xsl' > '--enable-dom' '--with-mhash=/kolab' '--with-mcrypt=/kolab' > '--enable-ctype' '--with-pear=/kolab/lib/php' '--disable-simplexml' > '--enable-mbregex' '--enable-mbstring' '--with-iconv=/kolab' > '--disable-spl' '--without-tidy' '--with-apxs2=/kolab/sbin/apxs' > '--disable-cli' '--disable-cgi' '--enable-force-cgi-redirect' > '--enable-discard-path' > > > So i think, that --with-db4=/kolab should take the statically > linked libdb.a and should not open the wrong version from debian > which is 4.6. Kolab uses 4.5 so could that be the problem ? Linker > Problem of apache-php ? Any help would be very appreciated. > > Kind regards > > Franz > > P.S.:Now i know what it means: Never change a running system:-< > > > > > > _______________________________________________ Kolab-users mailing > list Kolab-users at kolab.org > https://kolab.org/mailman/listinfo/kolab-users -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkmrJ9IACgkQwXH75yyXWZupQQCgswvoMFVOb69qcQFKuqOt1nkv jjUAn0lMQEicCPf5oiZZzQfw1Nb6uw2B =PUdH -----END PGP SIGNATURE----- From itsef-admin at brightsight.com Mon Mar 2 13:31:41 2009 From: itsef-admin at brightsight.com (ITSEF Admin) Date: Mon, 2 Mar 2009 13:31:41 +0100 Subject: Mail and spam statistics on Kolab server? Message-ID: <200903021331.41819.itsef-admin@brightsight.com> Hi all, I've been wondering about something: Is anybody out there creating/monitoring their mail/spam/etc. statistics on their Kolab server? If so, what are you using to do so? I've been through the archive but only found one thread from 2007 about mailgraph (and the fact that it isn't working out-of-the-box), but not much else. Also, I have not seen anything related in the Wiki. I had a look at mailgraph myself, as I would like to have some graphical representation of mail traffic, bounces, indentified spam and so on, but mailgraph would take some major changes to make it work with the default Kolab (2.2.0) set-up. One of the biggest problem is the fact that all logs are separated into different files, which is something that mailgraph cannot deal with in its current form. Hence, I'm open to suggestions about what else is out there that fits the bill (i.e. produce some statistics - preferably graphical - about the mail server's performance) and works well with Kolab without having to change the Kolab configuration (or at least not too much). Any ideas? Regards, Thomas -- ------------------------------------------------------------------------------ Thomas Ribbrock, IT-Team brightsight From bernhard at intevation.de Mon Mar 2 15:06:31 2009 From: bernhard at intevation.de (Bernhard Reiter) Date: Mon, 2 Mar 2009 15:06:31 +0100 Subject: Can't delete users In-Reply-To: <20090301220717.13795m8ozux4goow@webmail.pardus.de> References: <20090301220717.13795m8ozux4goow@webmail.pardus.de> Message-ID: <200903021506.32438.bernhard@intevation.de> Am Sonntag, 1. M?rz 2009 22:07:17 schrieb Gunnar Wrobel: > Quoting Enrico Zaffaroni : > > I had to delete awaiting users with more than one KolabDeleteFlag > > by > > hand with ldapdelete. But users deleted with the correct > > configuration are then removed correctly. > > I guess this would be a bug then. It does not sound like a defect to me. If you accidentially added more kolabDeleteFlag (s) you just need to delete those extra ones and it should work again. > @bernhard: I didn't analyze this in detail now but it did not meet ? > your expectation right? If that's correct I'd open a bug. -- 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: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From bernhard at intevation.de Mon Mar 2 15:10:47 2009 From: bernhard at intevation.de (Bernhard Reiter) Date: Mon, 2 Mar 2009 15:10:47 +0100 Subject: Segfault on webclient ! (Solved) In-Reply-To: <49AB27D3.3050607@dah.am> References: <49AAEBD1.6070208@dah.am> <49AB27D3.3050607@dah.am> Message-ID: <200903021510.47952.bernhard@intevation.de> Am Montag, 2. M?rz 2009 01:26:59 schrieb Franz Skale: > Now i finally solved it on my own. > The problem was , as mentioned above, that the libdb-4.5 version of > kolab doesn't work without threads on apache2 threaded. > This is the same problem as mentioned in my fist post 2006 ! > So, i build a statically linked debian version of db-4.5 and changed > the --with-db4=/kolab to the statically linked target. > Now ot works Good that you got it to work. Maybe you can add a hint to the wiki or so to help other users with this problem. > but how to migrate old (incompatible) syncKolab adresses ?!? Did you describe the problem already in full detail somewhere? This single line is not a lot to understand the issue and give advice. 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: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From i.bin at dah.am Mon Mar 2 15:37:28 2009 From: i.bin at dah.am (Franz Skale) Date: Mon, 02 Mar 2009 15:37:28 +0100 Subject: Segfault on webclient ! (Solved) In-Reply-To: <200903021510.47952.bernhard@intevation.de> References: <49AAEBD1.6070208@dah.am> <49AB27D3.3050607@dah.am> <200903021510.47952.bernhard@intevation.de> Message-ID: <49ABEF28.7060300@dah.am> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Bernhard. Sorry for the misleading lines. I don't know why ld wants to include the debian libdb-4.6 since apache-php will be build with db-4.5. So in my strace the last line was /usr/lib/libdb-4.6.so which is the debian lib and then came the sagfault. So i did this temporary workaround (32Bit seems not to have this problem, anybody out there with the same problem on debian lenny /32/64 bit ?) What i have done: (Not to interfere debian deps to libdb3-dev on lenny i build it from source) 1.) cd /usr/src apt-get source libdb4-5 2.) cd /usr/src/db4.5-4.5.20 3.) commented out java things from debian/rules. (Are not relevant to kolab). 4.) debian/rules build 5.) After build complete: cd dist/ DESTDIR=/tmp/db-4.5 make install 6.) mkdir /kolab/RPM/SRC/apache-php 7.) cd /kolab/RPM/SRC/apache-php 8.) rpm2cpio /kolab/RPM/PKG/rpm2cpio /kolab.new/RPM/PKG/apache-php-5.2.8-20081209_kolab.src.rpm |cpio -id 9.) chown root.root * 10) edited the php.spec Changed the db-4.5 line to: --with-db4=/tmp/db-4.5/usr 11.) rpmbuild -ba php.spec 12.) Installed the ned package: rpm -Uhv --force /kolab/RPM/PKG/apache-php-5.2.9-20090228.amd64-kolab.rpm 13.) apache will be restarted. Config Options for apache-php: # package options %option with_bdb yes %option with_ctype yes %option with_dom yes %option with_gd yes %option with_gettext yes %option with_iconv yes %option with_imap yes %option with_imap_annotate yes %option with_imap_myrights yes %option with_mbregex yes %option with_mbstring yes %option with_mcrypt yes %option with_mhash yes %option with_mm yes %option with_openldap yes %option with_pear yes %option with_sqlite yes %option with_ssl yes %option with_xml yes %option with_zlib yes The debian version on db-4.5 does have some x86_64 patches. The kolab source version for db-4.5 seems to lack from thread support. The Linker SEARCH_DIR was right but why the linker wanted to include db-4.6 seems to be a miracle. There is a open thread on the debian list that apt-listchanges is requesting db4-.5 but 4-6 is debian default. I think problem could lead to the kolab build problem. Anyway, now it is working and anyone have troubles with it, can contact me via the maillinlist. Please revise my temp solution and then i could post it in the wiki as you told me. Kind regards Franz Changes: Bernhard Reiter schrieb: > Am Montag, 2. M?rz 2009 01:26:59 schrieb Franz Skale: >> Now i finally solved it on my own. The problem was , as mentioned >> above, that the libdb-4.5 version of kolab doesn't work without >> threads on apache2 threaded. This is the same problem as >> mentioned in my fist post 2006 ! So, i build a statically linked >> debian version of db-4.5 and changed the --with-db4=/kolab to the >> statically linked target. Now ot works > > Good that you got it to work. Maybe you can add a hint to the wiki > or so to help other users with this problem. > >> but how to migrate old (incompatible) syncKolab adresses ?!? > > Did you describe the problem already in full detail somewhere? This > single line is not a lot to understand the issue and give advice. > > Bernhard > > > > ---------------------------------------------------------------------- > > > _______________________________________________ Kolab-users mailing > list Kolab-users at kolab.org > https://kolab.org/mailman/listinfo/kolab-users -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkmr7ygACgkQwXH75yyXWZvrZwCg2SZUDZA7PZCdu/DE2JmlCFKb bVQAn3Ih9yhkoDRo96tB6gq9XQgmfLcs =SSnX -----END PGP SIGNATURE----- From Marcel.Gsteiger at milprog.ch Mon Mar 2 18:08:07 2009 From: Marcel.Gsteiger at milprog.ch (Marcel Gsteiger) Date: Mon, 02 Mar 2009 18:08:07 +0100 Subject: source install fails on Freetype installation Message-ID: <49AC2084.DB9C.0010.0@milprog.ch> Hi all I try to build kolab 2.2.0 from source on a vanilla CentOS 5.2 (=RHEL) - i386 host. The build process starts as expected, but after about 90 minutes I get the error -- make: *** No rule to make target `install'. Stop. -- while compiling freetype. Further logfile information see below. The same error occurs with 2.2.1 beta. Any help on how to fix this would much be appreciated. Regards --Marcel (snip) FreeType build system -- automatic system detection The following settings are used: platform ansi compiler /kolab/bin/cc configuration directory ./builds/ansi configuration rules ./builds/ansi/ansi.mk If this does not correspond to your system or settings please remove the file `config.mk' from this directory then read the INSTALL file for help. Otherwise, simply type `/kolab/bin/make' again to build the library, or `/kolab/bin/make refdoc' to build the API reference (the latter needs python). Generating modules list in ./objs/ftmodule.h... * module: truetype (Windows/Mac font files with extension *.ttf or *.ttc) * module: type1 (Postscript font files with extension *.pfa or *.pfb) * module: cff (OpenType fonts with extension *.otf) * module: cid (Postscript CID-keyed fonts, no known extension) * module: pfr (PFR/TrueDoc font files with extension *.pfr) * module: type42 (Type 42 font files with no known extension) * module: winfnt (Windows bitmap fonts with extension *.fnt or *.fon) * module: pcf (pcf bitmap fonts) * module: bdf (bdf bitmap fonts) * module: sfnt (helper module for TrueType & OpenType formats) * module: autofit (automatic hinting module) * module: pshinter (Postscript hinter module) * module: raster (monochrome bitmap renderer) * module: smooth (anti-aliased bitmap renderer) * module: smooth (anti-aliased bitmap renderer for LCDs) * module: smooth (anti-aliased bitmap renderer for vertical LCDs) * module: psaux (Postscript Type 1 & Type 2 helper module) * module: psnames (Postscript & Unicode Glyph name handling) done. + /kolab/bin/make --no-print-directory cc -I./objs -I./builds/ansi -I./include -c -DFT2_BUILD_LIBRARY -DFT_CONFIG_MODULES_H="" -o objs/ftsystem.o src/base/ftsystem.c cc -I./objs -I./builds/ansi -I./include -c -DFT2_BUILD_LIBRARY -DFT_CONFIG_MODULES_H="" -o objs/ftdebug.o src/base/ftdebug.c cc -I./objs -I./builds/ansi -I./include -c -DFT2_BUILD_LIBRARY -DFT_CONFIG_MODULES_H="" -o objs/ftinit.o src/base/ftinit.c cc -I./objs -I./builds/ansi -I./include -c -DFT2_BUILD_LIBRARY -DFT_CONFIG_MODULES_H="" -I./src/base -o objs/ftbase.o ./src/base/ftbase.c cc -I./objs -I./builds/ansi -I./include -c -DFT2_BUILD_LIBRARY -DFT_CONFIG_MODULES_H="" -I./src/base -o objs/ftbbox.o src/base/ftbbox.c cc -I./objs -I./builds/ansi -I./include -c -DFT2_BUILD_LIBRARY -DFT_CONFIG_MODULES_H="" -I./src/base -o objs/ftbdf.o src/base/ftbdf.c cc -I./objs -I./builds/ansi -I./include -c -DFT2_BUILD_LIBRARY -DFT_CONFIG_MODULES_H="" -I./src/base -o objs/ftbitmap.o src/base/ftbitmap.c cc -I./objs -I./builds/ansi -I./include -c -DFT2_BUILD_LIBRARY -DFT_CONFIG_MODULES_H="" -I./src/base -o objs/ftglyph.o src/base/ftglyph.c cc -I./objs -I./builds/ansi -I./include -c -DFT2_BUILD_LIBRARY -DFT_CONFIG_MODULES_H="" -I./src/base -o objs/ftgxval.o src/base/ftgxval.c cc -I./objs -I./builds/ansi -I./include -c -DFT2_BUILD_LIBRARY -DFT_CONFIG_MODULES_H="" -I./src/base -o objs/ftmm.o src/base/ftmm.c cc -I./objs -I./builds/ansi -I./include -c -DFT2_BUILD_LIBRARY -DFT_CONFIG_MODULES_H="" -I./src/base -o objs/ftotval.o src/base/ftotval.c cc -I./objs -I./builds/ansi -I./include -c -DFT2_BUILD_LIBRARY -DFT_CONFIG_MODULES_H="" -I./src/base -o objs/ftpfr.o src/base/ftpfr.c cc -I./objs -I./builds/ansi -I./include -c -DFT2_BUILD_LIBRARY -DFT_CONFIG_MODULES_H="" -I./src/base -o objs/ftstroke.o src/base/ftstroke.c cc -I./objs -I./builds/ansi -I./include -c -DFT2_BUILD_LIBRARY -DFT_CONFIG_MODULES_H="" -I./src/base -o objs/ftsynth.o src/base/ftsynth.c cc -I./objs -I./builds/ansi -I./include -c -DFT2_BUILD_LIBRARY -DFT_CONFIG_MODULES_H="" -I./src/base -o objs/fttype1.o src/base/fttype1.c cc -I./objs -I./builds/ansi -I./include -c -DFT2_BUILD_LIBRARY -DFT_CONFIG_MODULES_H="" -I./src/base -o objs/ftwinfnt.o src/base/ftwinfnt.c cc -I./objs -I./builds/ansi -I./include -c -DFT2_BUILD_LIBRARY -DFT_CONFIG_MODULES_H="" -I./src/base -o objs/ftxf86.o src/base/ftxf86.c cc -I./objs -I./builds/ansi -I./include -c -DFT2_BUILD_LIBRARY -DFT_CONFIG_MODULES_H="" -I./src/base -o objs/ftlcdfil.o src/base/ftlcdfil.c cc -I./objs -I./builds/ansi -I./include -c -DFT2_BUILD_LIBRARY -DFT_CONFIG_MODULES_H="" -I./src/base -o objs/ftgasp.o src/base/ftgasp.c cc -I./objs -I./builds/ansi -I./include -c -DFT2_BUILD_LIBRARY -DFT_CONFIG_MODULES_H="" -I./src/base -o objs/ftpatent.o src/base/ftpatent.c cc -I./objs -I./builds/ansi -I./include -c -DFT2_BUILD_LIBRARY -DFT_CONFIG_MODULES_H="" -I./src/truetype -o objs/truetype.o ./src/truetype/truetype.c cc -I./objs -I./builds/ansi -I./include -c -DFT2_BUILD_LIBRARY -DFT_CONFIG_MODULES_H="" -I./src/type1 -o objs/type1.o ./src/type1/type1.c cc -I./objs -I./builds/ansi -I./include -c -DFT2_BUILD_LIBRARY -DFT_CONFIG_MODULES_H="" -I./src/cff -o objs/cff.o ./src/cff/cff.c cc -I./objs -I./builds/ansi -I./include -c -DFT2_BUILD_LIBRARY -DFT_CONFIG_MODULES_H="" -I./src/cid -o objs/type1cid.o ./src/cid/type1cid.c cc -I./objs -I./builds/ansi -I./include -c -DFT2_BUILD_LIBRARY -DFT_CONFIG_MODULES_H="" -I./src/pfr -o objs/pfr.o ./src/pfr/pfr.c cc -I./objs -I./builds/ansi -I./include -c -DFT2_BUILD_LIBRARY -DFT_CONFIG_MODULES_H="" -I./src/type42 -o objs/type42.o ./src/type42/type42.c cc -I./objs -I./builds/ansi -I./include -c -DFT2_BUILD_LIBRARY -DFT_CONFIG_MODULES_H="" -I./src/winfonts -o objs/winfnt.o ./src/winfonts/winfnt.c cc -I./objs -I./builds/ansi -I./include -c -DFT2_BUILD_LIBRARY -DFT_CONFIG_MODULES_H="" -I./src/pcf -o objs/pcf.o ./src/pcf/pcf.c cc -I./objs -I./builds/ansi -I./include -c -DFT2_BUILD_LIBRARY -DFT_CONFIG_MODULES_H="" -I./src/bdf -o objs/bdf.o ./src/bdf/bdf.c cc -I./objs -I./builds/ansi -I./include -c -DFT2_BUILD_LIBRARY -DFT_CONFIG_MODULES_H="" -I./src/sfnt -o objs/sfnt.o ./src/sfnt/sfnt.c cc -I./objs -I./builds/ansi -I./include -c -DFT2_BUILD_LIBRARY -DFT_CONFIG_MODULES_H="" -I./src/autofit -o objs/autofit.o ./src/autofit/autofit.c cc -I./objs -I./builds/ansi -I./include -c -DFT2_BUILD_LIBRARY -DFT_CONFIG_MODULES_H="" -I./src/pshinter -o objs/pshinter.o ./src/pshinter/pshinter.c cc -I./objs -I./builds/ansi -I./include -c -DFT2_BUILD_LIBRARY -DFT_CONFIG_MODULES_H="" -I./src/raster -o objs/raster.o ./src/raster/raster.c cc -I./objs -I./builds/ansi -I./include -c -DFT2_BUILD_LIBRARY -DFT_CONFIG_MODULES_H="" -I./src/smooth -o objs/smooth.o ./src/smooth/smooth.c cc -I./objs -I./builds/ansi -I./include -c -DFT2_BUILD_LIBRARY -DFT_CONFIG_MODULES_H="" -I./src/cache -o objs/ftcache.o ./src/cache/ftcache.c cc -I./objs -I./builds/ansi -I./include -c -DFT2_BUILD_LIBRARY -DFT_CONFIG_MODULES_H="" -I./src/gzip -o objs/ftgzip.o ./src/gzip/ftgzip.c cc -I./objs -I./builds/ansi -I./include -c -DFT2_BUILD_LIBRARY -DFT_CONFIG_MODULES_H="" -I./src/lzw -o objs/ftlzw.o ./src/lzw/ftlzw.c cc -I./objs -I./builds/ansi -I./include -c -DFT2_BUILD_LIBRARY -DFT_CONFIG_MODULES_H="" -I./src/psaux -o objs/psaux.o ./src/psaux/psaux.c cc -I./objs -I./builds/ansi -I./include -c -DFT2_BUILD_LIBRARY -DFT_CONFIG_MODULES_H="" -I./src/psnames -o objs/psnames.o ./src/psnames/psmodule.c rm -f ./objs/libfreetype.a ar -r objs/libfreetype.a ./objs/ftsystem.o ./objs/ftdebug.o ./objs/ftinit.o ./objs/ftbase.o ./objs/ftbbox.o ./objs/ftbdf.o ./objs/ftbitmap.o ./objs/ftglyph.o ./objs/ftgxval.o ./objs/ftmm.o ./objs/ftotval.o ./objs/ftpfr.o ./objs/ftstroke.o ./objs/ftsynth.o ./objs/fttype1.o ./objs/ftwinfnt.o ./objs/ftxf86.o ./objs/ftlcdfil.o ./objs/ftgasp.o ./objs/ftpatent.o ./objs/truetype.o ./objs/type1.o ./objs/cff.o ./objs/type1cid.o ./objs/pfr.o ./objs/type42.o ./objs/winfnt.o ./objs/pcf.o ./objs/bdf.o ./objs/sfnt.o ./objs/autofit.o ./objs/pshinter.o ./objs/raster.o ./objs/smooth.o ./objs/ftcache.o ./objs/ftgzip.o ./objs/ftlzw.o ./objs/psaux.o ./objs/psnames.o ar: creating objs/libfreetype.a + exit 0 Executing(%install): env -i /kolab/lib/openpkg/bash --norc --noprofile --posix -e /kolab/RPM/TMP/rpm-tmp.20811 + cd /kolab/RPM/TMP + cd freetype-2.3.5 + rm -rf /kolab/RPM/TMP/freetype-2.3.5-root + /kolab/bin/make --no-print-directory install DESTDIR=/kolab/RPM/TMP/freetype-2.3.5-root make: *** No rule to make target `install'. Stop. error: Bad exit status from /kolab/RPM/TMP/rpm-tmp.20811 (%install) RPM build errors: Bad exit status from /kolab/RPM/TMP/rpm-tmp.20811 (%install) From schmerold1 at gmail.com Tue Mar 3 00:16:45 2009 From: schmerold1 at gmail.com (schmerold1 at gmail.com) Date: Mon, 02 Mar 2009 17:16:45 -0600 Subject: Bynari v Toltec Message-ID: <49AC68DD.7090406@gmail.com> Toltec is 1/3 the cost of Bynari. Anyone care to comment what makes Bynari worth the upcharge? From NPrice at gibb.co.za Tue Mar 3 08:24:59 2009 From: NPrice at gibb.co.za (Price,Neil) Date: Tue, 3 Mar 2009 09:24:59 +0200 Subject: Bynari v Toltec Message-ID: <7B91BBC61758DD1183BE000C296D2CA70DC1B1@ct-exchange.wins.lawco.com> On 03 March 2009 01:17 AM schmerold1 at gmail.com wrote > Toltec is 1/3 the cost of Bynari. > > Anyone care to comment what makes Bynari worth the upcharge? I tested the previous version of Bynari and preferred it to Toltec. I liked the "headers only" option. Apparently you can source Bynari in Europe (from Univention) for pretty much the same price as Toltec. From bernhard at intevation.de Tue Mar 3 09:11:43 2009 From: bernhard at intevation.de (Bernhard Reiter) Date: Tue, 3 Mar 2009 09:11:43 +0100 Subject: Segfault on webclient ! (Solved) In-Reply-To: <49ABEF28.7060300@dah.am> References: <49AAEBD1.6070208@dah.am> <200903021510.47952.bernhard@intevation.de> <49ABEF28.7060300@dah.am> Message-ID: <200903030911.46996.bernhard@intevation.de> Franz, Am Montag, 2. M?rz 2009 15:37:28 schrieb Franz Skale: > Sorry for the misleading lines. no problem, I thought you were having another question about "syncKolab addresses" which I was trying to answer. Now back to your problem on Debian 64bit: > I don't know why ld wants to include the debian libdb-4.6 since > apache-php will be build with db-4.5. > So in my strace the last line was /usr/lib/libdb-4.6.so which is the > debian lib and then came the sagfault. > So i did this temporary workaround (32Bit seems not to have this > problem, anybody out there with the same problem on debian lenny > /32/64 bit ?) I've tried to replicate kolab/issue2982 (OpenLDAP segmentation fault on 64bit) for two weeks and did not see the crash. It might not be related. > What i have done: (Not to interfere debian deps to libdb3-dev on lenny > i build it from source) > 1.) cd /usr/src > apt-get source libdb4-5 > 2.) cd /usr/src/db4.5-4.5.20 > 3.) commented out java things from debian/rules. (Are not relevant to > kolab). > 4.) debian/rules build > 5.) After build complete: > cd dist/ > DESTDIR=/tmp/db-4.5 make install > 6.) mkdir /kolab/RPM/SRC/apache-php > 7.) cd /kolab/RPM/SRC/apache-php > 8.) rpm2cpio /kolab/RPM/PKG/rpm2cpio > /kolab.new/RPM/PKG/apache-php-5.2.8-20081209_kolab.src.rpm |cpio -id > 9.) chown root.root * > 10) edited the php.spec > Changed the db-4.5 line to: > ? ? ?--with-db4=/tmp/db-4.5/usr > 11.) rpmbuild -ba php.spec > 12.) Installed the ned package: > rpm -Uhv --force /kolab/RPM/PKG/apache-php-5.2.9-20090228.amd64-kolab.rpm > 13.) apache will be restarted. > > Config Options for apache-php: > > # ? package options > %option ? ? ? ? with_bdb ? ? ? ? ? ? ? ?yes > %option ? ? ? ? with_ctype ? ? ? ? ? ? ?yes > %option ? ? ? ? with_dom ? ? ? ? ? ? ? ?yes > %option ? ? ? ? with_gd ? ? ? ? ? ? ? ? yes > %option ? ? ? ? with_gettext ? ? ? ? ? ?yes > %option ? ? ? ? with_iconv ? ? ? ? ? ? ?yes > %option ? ? ? ? with_imap ? ? ? ? ? ? ? yes > %option ? ? ? ? with_imap_annotate ? ? ?yes > %option ? ? ? ? with_imap_myrights ? ? ?yes > %option ? ? ? ? with_mbregex ? ? ? ? ? ?yes > %option ? ? ? ? with_mbstring ? ? ? ? ? yes > %option ? ? ? ? with_mcrypt ? ? ? ? ? ? yes > %option ? ? ? ? with_mhash ? ? ? ? ? ? ?yes > %option ? ? ? ? with_mm ? ? ? ? ? ? ? ? yes > %option ? ? ? ? with_openldap ? ? ? ? ? yes > %option ? ? ? ? with_pear ? ? ? ? ? ? ? yes > %option ? ? ? ? with_sqlite ? ? ? ? ? ? yes > %option ? ? ? ? with_ssl ? ? ? ? ? ? ? ?yes > %option ? ? ? ? with_xml ? ? ? ? ? ? ? ?yes > %option ? ? ? ? with_zlib ? ? ? ? ? ? ? yes > > The debian version on db-4.5 does have some x86_64 patches. > The kolab source version for db-4.5 seems to lack from thread support. Hmm, this would be an issue for the OpenPKG guys I guess, but I also think we should explore along these lines. > The Linker SEARCH_DIR was right but why the linker wanted to include > db-4.6 seems to be a miracle. > There is a open thread on the debian list that apt-listchanges is > requesting db4-.5 but 4-6 is debian default. > I think problem could lead to the kolab build problem. > Anyway, now it is working and anyone have troubles with it, can > contact me via the maillinlist. > Please revise my temp solution and then i could post it in the wiki as > you told me. Your descriptions looks nice to me, I'd say you should put a link to your archived post in the wiki right now. ;) Thanks, 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: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From bernhard at intevation.de Tue Mar 3 11:24:08 2009 From: bernhard at intevation.de (Bernhard Reiter) Date: Tue, 3 Mar 2009 11:24:08 +0100 Subject: Kontact for MacOS experience (continued) In-Reply-To: <1235909803.19884.30.camel@black> References: <27599d0a.1c99919.bc6a312.6741@bynari.net> <200902281021.20835.michael@pasdziernik.net> <1235909803.19884.30.camel@black> Message-ID: <200903031124.12444.bernhard@intevation.de> Am Sonntag, 1. M?rz 2009 13:16:43 schrieb Del: > What works: > -Mail and calender works as expected. > -LDAP look-up also works nicely. Cool, thanks for the report. > -kolabwizard (as long as mail address and login name are identical) The primary email address in Kolab Server must always work as login. It is possible to have other email addresses and possibly you can also log in with a different uid, but this is the reason that Kolabwizard only needs the primary email address. And we wanted to keep stuff simple. > -kolabwizard only add new users when ran repeatedly, no option to remove > the existing (which makes for a messy testing environment when combined > with the point above). This is intentional because we cannot securely detect which accounts should be removed. Therefore kolabwizard only adds account data which works best if the user is new. From the theoretical point of view it should be possible to just create new users for testing purposes. > -I could not get free/busy working, i.e. I could not see others busy > infromation when scheduling a meeting (but I will need to resolve the > uninstall above to come any further on that one now). Are your settings okay in the client, then you can see .ifb requests in the apache log. > Non-critical (but still important) > -Kontact tray process sometimes does not start, I have not seen a > pattern yet (another Bambi issue is that I have no right button on the > mouse, so trying to close the tray process results in kmail+korganizer > windows popping up again). Try the apple key and mouse button. > -I did see some artifacts with Norwegian letters ?, ? and ?, but that > may actually be tributed to Horde, it actually seemed OK for what was > sent from Kontact on the Mac. Yes, for a problem report on this particular item we would need to get detailed data. > Do we have functionality in Kontact to view others calendar in the > calendar view? Sure, if the other person gives you permissions to see one or more of their calender folders, it will just be shown in the calendar view. (You can choose all four views: a) combined, b) side by side c) horizontal d) monthly.) 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: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From hjkim at bynari.net Tue Mar 3 15:08:00 2009 From: hjkim at bynari.net (Hyun Kim) Date: Tue, 03 Mar 2009 08:08:00 -0600 Subject: Bynari v Toltec Message-ID: <7ed0735e.1c99c09.1f092eeb.5bb@bynari.net> You can get the same price through our partner, Univention. Also, feel free to contact us directly, and we will provide you with Univention's price. Thanks, Hyun Mrs. Hyun Kim President Bynari, Inc. 2639 Electronic Lane, Suite 110 Dallas, Tx 75220 www.bynari.net (214) 350-5772 X59 (214) 789-8674 cell (214) 352-3530 fax "Success is on the far side of failure." T. J. Watson -----Original Message----- From: kolab-users-bounces at kolab.org [mailto:kolab-users-bounces at kolab.org] On Behalf Of Price,Neil Sent: Tuesday, March 03, 2009 1:25 AM To: 'kolab-users at kolab.org' Subject: RE: Bynari v Toltec On 03 March 2009 01:17 AM schmerold1 at gmail.com wrote > Toltec is 1/3 the cost of Bynari. > > Anyone care to comment what makes Bynari worth the upcharge? I tested the previous version of Bynari and preferred it to Toltec. I liked the "headers only" option. Apparently you can source Bynari in Europe (from Univention) for pretty much the same price as Toltec. _______________________________________________ Kolab-users mailing list Kolab-users at kolab.org https://kolab.org/mailman/listinfo/kolab-users From albrecht.dress at lios-tech.com Tue Mar 3 16:03:26 2009 From: albrecht.dress at lios-tech.com (Albrecht =?iso-8859-1?b?RHJl3w==?=) Date: Tue, 03 Mar 2009 16:03:26 +0100 Subject: Bynari v Toltec In-Reply-To: <49AC68DD.7090406@gmail.com> (from schmerold1@gmail.com on Tue Mar 3 00:16:45 2009) References: <49AC68DD.7090406@gmail.com> Message-ID: <1236092606.23260.2@pc-adr2> Am 03.03.2009 00:16:45 schrieb(en) schmerold1 at gmail.com: > Anyone care to comment what makes Bynari worth the upcharge? Before choosing a connector, you should carefully evaluate if the different products available work properly for your requirements. We are currently using Toltec, but it has some issues which emerged in "daily use" only (e.g. [1] is really a blocker for us), so I'm also in the process of checking alternatives again. I know that there are some entries about Toltec issues in the tracker, but I don't know if the other products are also tracked there. You may also want to search the wiki or the mail archives, iirc there was a comparison somewhere. Best, Albrecht. [1] From joon at radleys.co.za Tue Mar 3 16:10:14 2009 From: joon at radleys.co.za (Joon Radley) Date: Tue, 3 Mar 2009 17:10:14 +0200 Subject: Bynari v Toltec In-Reply-To: <7B91BBC61758DD1183BE000C296D2CA70DC1B1@ct-exchange.wins.lawco.com> References: <7B91BBC61758DD1183BE000C296D2CA70DC1B1@ct-exchange.wins.lawco.com> Message-ID: <000301c99c12$2a1fa0b0$7e5ee210$@co.za> Hi Neil, > Apparently you can source Bynari in Europe (from Univention) for pretty much > the same price as Toltec. So have the moved away from the yearly renewal fee as well? Best Regards Joon Radley Radley Network Technologies CC Cell: +27 (0)83 368 8557 Fax: +27 (0)12 998 4346 E-mail: joon at radleys.co.za Web: www.toltec.co.za From hjkim at bynari.net Tue Mar 3 16:30:00 2009 From: hjkim at bynari.net (Hyun Kim) Date: Tue, 03 Mar 2009 09:30:00 -0600 Subject: Bynari v Toltec Message-ID: The price includes one year of support and maintenance. Please feel free to contact us for any questions. Thanks, Hyun Mrs. Hyun Kim President Bynari, Inc. 2639 Electronic Lane, Suite 110 Dallas, Tx 75220 www.bynari.net (214) 350-5772 X59 (214) 789-8674 cell (214) 352-3530 fax "Success is on the far side of failure." T. J. Watson -----Original Message----- From: kolab-users-bounces at kolab.org [mailto:kolab-users-bounces at kolab.org] On Behalf Of Joon Radley Sent: Tuesday, March 03, 2009 9:10 AM To: 'Price,Neil'; kolab-users at kolab.org Subject: RE: Bynari v Toltec Hi Neil, > Apparently you can source Bynari in Europe (from Univention) for pretty much > the same price as Toltec. So have the moved away from the yearly renewal fee as well? Best Regards Joon Radley Radley Network Technologies CC Cell: +27 (0)83 368 8557 Fax: +27 (0)12 998 4346 E-mail: joon at radleys.co.za Web: www.toltec.co.za _______________________________________________ Kolab-users mailing list Kolab-users at kolab.org https://kolab.org/mailman/listinfo/kolab-users From johnm at advocap.org Tue Mar 3 23:16:44 2009 From: johnm at advocap.org (John McMonagle) Date: Tue, 03 Mar 2009 16:16:44 -0600 Subject: Kolab native debian lenny install? Message-ID: <49ADAC4C.5000800@advocap.org> Is it feasible to do a native debian lenny install of Kolab? I prefer a native install but it's also important that it works :-) It looks like some of the needed parts are not in lenny but are in testing and unstable. kolabd, kolabadmin , kolab-webadmin and others are only in testing and unstable Are all the needed packages available? I'm Ok with building from source packages. How about horde? Thanks John - John McMonagle IT Manager Advocap Inc. From schmerold1 at gmail.com Tue Mar 3 23:55:51 2009 From: schmerold1 at gmail.com (schmerold1 at gmail.com) Date: Tue, 03 Mar 2009 16:55:51 -0600 Subject: Bynari v Toltec In-Reply-To: <000301c99c12$2a1fa0b0$7e5ee210$@co.za> References: <7B91BBC61758DD1183BE000C296D2CA70DC1B1@ct-exchange.wins.lawco.com> <000301c99c12$2a1fa0b0$7e5ee210$@co.za> Message-ID: <49ADB577.50008@gmail.com> Outside the scope of this list, but an item of interest to many is Bynari's compatibility with alternative IMAP servers, such as Dovecot. We have never tested this, so I have no idea how effective and reliable Bynari is when used with Dovecot. Joon Radley wrote: > Hi Neil, > > >> Apparently you can source Bynari in Europe (from Univention) for pretty >> > much > >> the same price as Toltec. >> > > So have the moved away from the yearly renewal fee as well? > > Best Regards > > Joon Radley > Radley Network Technologies CC > Cell: +27 (0)83 368 8557 > Fax: +27 (0)12 998 4346 > E-mail: joon at radleys.co.za > Web: www.toltec.co.za > > _______________________________________________ > Kolab-users mailing list > Kolab-users at kolab.org > https://kolab.org/mailman/listinfo/kolab-users > From martial at paupe.name Tue Mar 3 23:59:26 2009 From: martial at paupe.name (Martial Paupe) Date: Wed, 4 Mar 2009 11:59:26 +1300 Subject: Kolab native debian lenny install? In-Reply-To: <49ADAC4C.5000800@advocap.org> References: <49ADAC4C.5000800@advocap.org> Message-ID: <200903041159.26714.martial@paupe.name> Hi, here is the pkg-kolab-devel's mailinglist address where you will get a clear answer about native kolab install process and maybe a status. pkg-kolab-devel at lists.alioth.debian.org Cheers, -- Martial Paupe On Wed, 04 Mar 2009 11:16:44 John McMonagle wrote: > Is it feasible to do a native debian lenny install of Kolab? > > I prefer a native install but it's also important that it works :-) > > It looks like some of the needed parts are not in lenny but are in > testing and unstable. > kolabd, kolabadmin , kolab-webadmin and others are only in testing and > unstable > > Are all the needed packages available? > I'm Ok with building from source packages. > > How about horde? > > Thanks > > John > > - > > John McMonagle > IT Manager > Advocap Inc. > > > _______________________________________________ > Kolab-users mailing list > Kolab-users at kolab.org > https://kolab.org/mailman/listinfo/kolab-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From j.hylkema at intronics.nl Wed Mar 4 09:45:36 2009 From: j.hylkema at intronics.nl (Jacques Hylkema) Date: Wed, 04 Mar 2009 09:45:36 +0100 Subject: Restore folder from backup (kolab 2.04) Message-ID: <49AE3FB0.1050604@intronics.nl> Hello, I have problems restoring a folder of one of my users, which he accidentally deleted. I tried the following: - Restored the folder from a backup using scp - The folder in question is: /kolab/var/imapd/spool/domain/intronics.nl/user/j^m^dekker/Leveranciers/R--S - Changed the owner and group of the folder and all subfolders and files to kolab-r / kolab-r - su - kolab-r - /kolab/bin/cyrreconstruct -r -f user/j^m^dekker/Leveranciers/*@intronics.nl The output of this displayed all folders within Leveranciers, except the R--S folder. I did not see any "discover" line and the folder could not be seen in Thunderbird Then I deleted all cyrus.* files from the R--S folder, including sub-folders, and ran the cyrreconstruct again, with the same result. I have the following configuration: Kolab2 Groupware Server Version 2.0.4 Kolab2 Groupware Server Component Versions perl-kolab-5.8.7-2.0_20060430 kolabd-1.9.4-20060707 kolab-resource-handlers-0.3.9-20060811 kolab-webadmin-0.4.0-20060810 Kolab2 Patched OpenPKG Package Versions apache-1.3.33-2.4.5_kolab2 imap-2004d-2.4.0_kolab imapd-2.2.12-2.4.0_kolab3 openldap-2.2.27-2.4.1_kolab php-4.3.11-2.4.2_kolab postfix-2.2.3-2.4.1_kolab OpenPKG Version openpkg-2.4.3-2.4.3 Any suggestions are welcome. Thank you for your time. -- Met vriendelijke groet, Kind regards, Jacques Hylkema ICT Manager Tel +31 (0)342 - 407095 e-mail j.hylkema at intronics.nl *P * Please consider the environment before printing this email. Intronics Intronics B.V. Postbus 123 3770 AC Barneveld Tel. Solutions +31 (0)342-407040 Fax +31 (0)342-412114 www.intronics.nl Tel. Connections +31 (0)342-407080 Fax +31 (0)342-412114 sales at intronics.nl *Disclaimer:* This message (including any attachments) is confidential and may be privileged. If you have received it by mistake please notify the sender by return e-mail and delete this message from your system. Any unauthorised use or dissemination of this message in whole or in part is strictly prohibited. Please note that e-mails are susceptible to change. Intronics B.V. shall not be liable for the improper or incomplete transmission of the information contained in this communication nor for any delay in its receipt or damage to your system. Intronics B.V. does not guarantee that the integrity of this communication has been maintained nor that this communication is free of viruses, interceptions or interference. ______________________________________________________________________________________ This outbound message from Intronics B.V. has been checked for all known viruses by KPN MailScan (IV-Scan), powered by MessageLabs. ______________________________________________________________________________________ -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: intronics.jpg Type: image/jpeg Size: 10259 bytes Desc: not available URL: From aspineux at gmail.com Wed Mar 4 10:11:17 2009 From: aspineux at gmail.com (Alain Spineux) Date: Wed, 4 Mar 2009 10:11:17 +0100 Subject: Restore folder from backup (kolab 2.04) In-Reply-To: <49AE3FB0.1050604@intronics.nl> References: <49AE3FB0.1050604@intronics.nl> Message-ID: <71fe4e760903040111j748846adv9b18c1cd30f15fcb@mail.gmail.com> On Wed, Mar 4, 2009 at 9:45 AM, Jacques Hylkema wrote: > Hello, > > I have problems restoring a folder of one of my users, which he accidentally > deleted. > > I tried the following: > - Restored the folder from a backup using scp > - The folder in question is: > /kolab/var/imapd/spool/domain/intronics.nl/user/j^m^dekker/Leveranciers/R--S > - Changed the owner and group of the folder and all subfolders and files to > kolab-r / kolab-r > - su - kolab-r > - /kolab/bin/cyrreconstruct -r -f > user/j^m^dekker/Leveranciers/*@intronics.nl looks good > > The output of this displayed all folders within Leveranciers, except the > R--S folder. I did not see any "discover" line and the folder could not be > seen in Thunderbird Their is no discover because all the folder are already in the mailbox.db can you try a # /kolab/bin/cyrreconstruct -r -f user/j^m^dekker/Leveranciers/R--S at intronics.nl > Then I deleted all cyrus.* files from the R--S folder, including > sub-folders, and ran the cyrreconstruct again, with the same result. Then you have lost some info, maybe the seen flag > > I have the following configuration: > > Kolab2 Groupware Server Version > 2.0.4 > > Kolab2 Groupware Server Component Versions > perl-kolab-5.8.7-2.0_20060430 > kolabd-1.9.4-20060707 > kolab-resource-handlers-0.3.9-20060811 > kolab-webadmin-0.4.0-20060810 > > Kolab2 Patched OpenPKG Package Versions > apache-1.3.33-2.4.5_kolab2 > imap-2004d-2.4.0_kolab > imapd-2.2.12-2.4.0_kolab3 > openldap-2.2.27-2.4.1_kolab > php-4.3.11-2.4.2_kolab > postfix-2.2.3-2.4.1_kolab > > OpenPKG Version > openpkg-2.4.3-2.4.3 > > Any suggestions are welcome. > Thank you for your time. > -- > Met vriendelijke groet, > Kind regards, > > Jacques Hylkema > ICT Manager > Tel +31 (0)342 - 407095 > e-mail j.hylkema at intronics.nl > P? Please consider the environment before printing this email. > > Intronics B.V. > Postbus 123 3770 AC Barneveld > Tel. Solutions +31 (0)342-407040 Fax???+31 (0)342-412114 www.intronics.nl > Tel. Connections +31 (0)342-407080 Fax???+31 (0)342-412114 > sales at intronics.nl > Disclaimer: > This message (including any attachments) is confidential and may be > privileged. If you have received it by mistake please notify the sender by > return e-mail and delete this message from your system. Any unauthorised use > or dissemination of this message in whole or in part is strictly prohibited. > Please note that e-mails are susceptible to change. Intronics B.V. shall not > be liable for the improper or incomplete transmission of the information > contained in this communication nor for any delay in its receipt or damage > to your system. Intronics B.V. does not guarantee that the integrity of this > communication has been maintained nor that this communication is free of > viruses, interceptions or interference. > _______________________________________________ > Kolab-users mailing list > Kolab-users at kolab.org > https://kolab.org/mailman/listinfo/kolab-users > > -- Alain Spineux aspineux gmail com May the sources be with you From itsef-admin at brightsight.com Wed Mar 4 10:16:39 2009 From: itsef-admin at brightsight.com (ITSEF Admin) Date: Wed, 4 Mar 2009 10:16:39 +0100 Subject: Restore folder from backup (kolab 2.04) In-Reply-To: <49AE3FB0.1050604@intronics.nl> References: <49AE3FB0.1050604@intronics.nl> Message-ID: <200903041016.40118.itsef-admin@brightsight.com> On Wednesday 4 March 2009 09:45:36 Jacques Hylkema wrote: > I have problems restoring a folder of one of my users, which he > accidentally deleted. > > I tried the following: > - Restored the folder from a backup using scp > - The folder in question is: > /kolab/var/imapd/spool/domain/intronics.nl/user/j^m^dekker/Leveranciers/R-- >S - Changed the owner and group of the folder and all subfolders and files > to kolab-r / kolab-r > - su - kolab-r > - /kolab/bin/cyrreconstruct -r -f user/j^m^dekker/Leveranciers/*@intronics.nl Have you tried reconstructing the top level folder? I.e.: /kolab/bin/cyrreconstruct -r -f user/j^m^dekker/Leveranciers at intronics.nl As far as I remember this is necessary to tell Cyrus about the new folder - it will not recognise it automatically. Also, I strongly recommend to re-calculate your quotas after you have restored your folders, otherwise they can get quite out of whack. Cyrus does not do this for you if you add/delete mail "manually" to/from the spool. The command is: su - kolab-r -c "/kolab/bin/cyrquota -f" A word of caution: This will recalculate *all* quotas - there seems to be no easy way to recalculate the quota for only one user. Also, if you already have restored/deleted manually in the spool in the past, your quotas may already be wrong. If this is the case, the recalculation can produce very strange results. Running it more than once can help, or, if that does not help, reconstruct the complete mailbox of any user whose quota is off, then re-run the quota command. Regards, Thomas -- ------------------------------------------------------------------------------ Thomas Ribbrock, IT-Team brightsight From j.hylkema at intronics.nl Wed Mar 4 10:22:43 2009 From: j.hylkema at intronics.nl (Jacques Hylkema) Date: Wed, 04 Mar 2009 10:22:43 +0100 Subject: Restore folder from backup (kolab 2.04) In-Reply-To: <71fe4e760903040111j748846adv9b18c1cd30f15fcb@mail.gmail.com> References: <49AE3FB0.1050604@intronics.nl> <71fe4e760903040111j748846adv9b18c1cd30f15fcb@mail.gmail.com> Message-ID: <49AE4863.6070300@intronics.nl> Hi Alain, Thanks for your quick response. Answers to your suggestion on this below. Alain Spineux schreef: > On Wed, Mar 4, 2009 at 9:45 AM, Jacques Hylkema wrote: > >> Hello, >> >> I have problems restoring a folder of one of my users, which he accidentally >> deleted. >> >> I tried the following: >> - Restored the folder from a backup using scp >> - The folder in question is: >> /kolab/var/imapd/spool/domain/intronics.nl/user/j^m^dekker/Leveranciers/R--S >> - Changed the owner and group of the folder and all subfolders and files to >> kolab-r / kolab-r >> - su - kolab-r >> - /kolab/bin/cyrreconstruct -r -f >> user/j^m^dekker/Leveranciers/*@intronics.nl >> > > looks good > > >> The output of this displayed all folders within Leveranciers, except the >> R--S folder. I did not see any "discover" line and the folder could not be >> seen in Thunderbird >> > > Their is no discover because all the folder are already in the mailbox.db > > can you try a > > # /kolab/bin/cyrreconstruct -r -f > user/j^m^dekker/Leveranciers/R--S at intronics.nl > > Done. It returned without any output, and in Thunderbird the folder was still not found. >> Then I deleted all cyrus.* files from the R--S folder, including >> sub-folders, and ran the cyrreconstruct again, with the same result. >> > > Then you have lost some info, maybe the seen flag > > Ok, thanks for that. I can restore it again whith these files. >> I have the following configuration: >> >> Kolab2 Groupware Server Version >> 2.0.4 >> >> Kolab2 Groupware Server Component Versions >> perl-kolab-5.8.7-2.0_20060430 >> kolabd-1.9.4-20060707 >> kolab-resource-handlers-0.3.9-20060811 >> kolab-webadmin-0.4.0-20060810 >> >> Kolab2 Patched OpenPKG Package Versions >> apache-1.3.33-2.4.5_kolab2 >> imap-2004d-2.4.0_kolab >> imapd-2.2.12-2.4.0_kolab3 >> openldap-2.2.27-2.4.1_kolab >> php-4.3.11-2.4.2_kolab >> postfix-2.2.3-2.4.1_kolab >> >> OpenPKG Version >> openpkg-2.4.3-2.4.3 >> >> Any suggestions are welcome. >> Thank you for your time. >> -- >> Met vriendelijke groet, >> Kind regards, >> >> Jacques Hylkema >> >> Thanks again for your so-operation. Jacques ______________________________________________________________________________________ This outbound message from Intronics B.V. has been checked for all known viruses by KPN MailScan (IV-Scan), powered by MessageLabs. ______________________________________________________________________________________ -------------- next part -------------- An HTML attachment was scrubbed... URL: From j.hylkema at intronics.nl Wed Mar 4 12:46:07 2009 From: j.hylkema at intronics.nl (Jacques Hylkema) Date: Wed, 04 Mar 2009 12:46:07 +0100 Subject: Restore folder from backup (kolab 2.04) In-Reply-To: <200903041016.40118.itsef-admin@brightsight.com> References: <49AE3FB0.1050604@intronics.nl> <200903041016.40118.itsef-admin@brightsight.com> Message-ID: <49AE69FF.8050000@intronics.nl> Hi Thomas, Thanks for your response. ITSEF Admin schreef: > On Wednesday 4 March 2009 09:45:36 Jacques Hylkema wrote: > >> I have problems restoring a folder of one of my users, which he >> accidentally deleted. >> >> I tried the following: >> - Restored the folder from a backup using scp >> - The folder in question is: >> /kolab/var/imapd/spool/domain/intronics.nl/user/j^m^dekker/Leveranciers/R-- >> S - Changed the owner and group of the folder and all subfolders and files >> to kolab-r / kolab-r >> - su - kolab-r >> - /kolab/bin/cyrreconstruct -r -f >> > user/j^m^dekker/Leveranciers/*@intronics.nl > > Have you tried reconstructing the top level folder? I.e.: > > /kolab/bin/cyrreconstruct -r -f user/j^m^dekker/Leveranciers at intronics.nl > This gives the following result: user/j.m.dekker/Leveranciers at intronics.nl If I use: /kolab/bin/cyrreconstruct -r -f user/j^m^dekker/Leveranciers/*@intronics.nl then I see all folders and subfolders below Leveranciers in the result. (not Leveranciers itself) so I tried: /kolab/bin/cyrreconstruct -r -f user/j^m^dekker/Leveranciers*@intronics.nl which does the same as above, but does include the Leveranciers folder itself. However, still no sign of the R--S folder... > As far as I remember this is necessary to tell Cyrus about the new folder - it > will not recognise it automatically. > > Also, I strongly recommend to re-calculate your quotas after you have restored > your folders, otherwise they can get quite out of whack. Cyrus does not do > this for you if you add/delete mail "manually" to/from the spool. The command > is: su - kolab-r -c "/kolab/bin/cyrquota -f" > A word of caution: This will recalculate *all* quotas - there seems to be no > easy way to recalculate the quota for only one user. Also, if you already > have restored/deleted manually in the spool in the past, your quotas may > already be wrong. If this is the case, the recalculation can produce very > strange results. Running it more than once can help, or, if that does not > help, reconstruct the complete mailbox of any user whose quota is off, then > re-run the quota command. > OK, That's good to know. In this case, the user in question has no quota set, because his mailbox is about 6GB. I have found that setting a quota larger than 3GB gives problems on Kolab 2.0.4. > Regards, > > Thomas > I think I have to follow another procedure: Create a (temporary) kolab mailserver with the latest version of kolab. Create the user in kolab, and restore the folder to that mailserver. reconstruct the folder on that mailserver. Add a new account to Thunderbird for the temporary mailserver Drag and drop the folder from the new temporary account to the original account Does this seem to be a good workaround to you? Thanks for your co-operation. Jacques ______________________________________________________________________________________ This outbound message from Intronics B.V. has been checked for all known viruses by KPN MailScan (IV-Scan), powered by MessageLabs. ______________________________________________________________________________________ -------------- next part -------------- An HTML attachment was scrubbed... URL: From liste at gelpi.it Wed Mar 4 13:14:37 2009 From: liste at gelpi.it (Gelpi Andrea) Date: Wed, 04 Mar 2009 13:14:37 +0100 Subject: Restore folder from backup (kolab 2.04) In-Reply-To: <49AE69FF.8050000@intronics.nl> References: <49AE3FB0.1050604@intronics.nl> <200903041016.40118.itsef-admin@brightsight.com> <49AE69FF.8050000@intronics.nl> Message-ID: <49AE70AD.1050105@gelpi.it> Jacques Hylkema wrote: . . . > If I use: > > /kolab/bin/cyrreconstruct -r -f user/j^m^dekker/Leveranciers/*@intronics.nl > > then I see all folders and subfolders below Leveranciers in the result. > (not Leveranciers itself) so I tried: > > /kolab/bin/cyrreconstruct -r -f > user/j^m^dekker/Leveranciers*@intronics.nl > > > which does the same as above, but does include the Leveranciers folder > itself. > However, still no sign of the R--S folder... I think the folder name could be the problem. >> As far as I remember this is necessary to tell Cyrus about the new folder - it >> will not recognise it automatically. >> >> Also, I strongly recommend to re-calculate your quotas after you have restored >> your folders, otherwise they can get quite out of whack. Cyrus does not do >> this for you if you add/delete mail "manually" to/from the spool. The command >> is: su - kolab-r -c "/kolab/bin/cyrquota -f" >> A word of caution: This will recalculate *all* quotas - there seems to be no >> easy way to recalculate the quota for only one user. Also, if you already >> have restored/deleted manually in the spool in the past, your quotas may >> already be wrong. If this is the case, the recalculation can produce very >> strange results. Running it more than once can help, or, if that does not >> help, reconstruct the complete mailbox of any user whose quota is off, then >> re-run the quota command. >> > OK, That's good to know. In this case, the user in question has no quota > set, because his mailbox is about 6GB. I have found that setting a quota > larger than 3GB gives problems on Kolab 2.0.4. > >> Regards, >> >> Thomas >> > I think I have to follow another procedure: > > Create a (temporary) kolab mailserver with the latest version of kolab. > Create the user in kolab, and restore the folder to that mailserver. > reconstruct the folder on that mailserver. OK. > Add a new account to Thunderbird for the temporary mailserver > Drag and drop the folder from the new temporary account to the original > account There is a more simple solution, imapsync. It is included in debian installation. You need just to type: aptitude -i imapsync I used it to migrate succesfully from kolab 2.0 to kolab 2.1 -- 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 itsef-admin at brightsight.com Wed Mar 4 13:26:29 2009 From: itsef-admin at brightsight.com (ITSEF Admin) Date: Wed, 4 Mar 2009 13:26:29 +0100 Subject: Restore folder from backup (kolab 2.04) In-Reply-To: <49AE69FF.8050000@intronics.nl> References: <49AE3FB0.1050604@intronics.nl> <200903041016.40118.itsef-admin@brightsight.com> <49AE69FF.8050000@intronics.nl> Message-ID: <200903041326.30051.itsef-admin@brightsight.com> On Wednesday 4 March 2009 12:46:07 Jacques Hylkema wrote: > ITSEF Admin schreef: [...] > > Have you tried reconstructing the top level folder? I.e.: > > > > /kolab/bin/cyrreconstruct -r -f user/j^m^dekker/Leveranciers at intronics.nl > > This gives the following result: > user/j.m.dekker/Leveranciers at intronics.nl i.e. it did some work on the folder (otherwise cyrreconstruct does not return anything). [...] > However, still no sign of the R--S folder... Ok, in that case I would try a complete reconstruct of the user's mailbox: su - kolab-r -c "cyrreconstruct -r -f user/j^m^dekker/*@intronics.nl" followed by su - kolab-r -c "cyrreconstruct -r -f user/j^m^dekker at intronics.nl" We have had problems with this in the past, but at least under 2.1.0, most of these reconstructions were successful. BTW: Maybe this is a stupid question, but: You *DID* check that the folder in question has not become unsubscribed in the mail client and is therefore not visible? [...] > I think I have to follow another procedure: > > Create a (temporary) kolab mailserver with the latest version of kolab. > Create the user in kolab, and restore the folder to that mailserver. > reconstruct the folder on that mailserver. > Add a new account to Thunderbird for the temporary mailserver > Drag and drop the folder from the new temporary account to the original > account > > Does this seem to be a good workaround to you? Far too much work. Our standard procedure in case the straightforward reconstruction of a previously existing folder does not work is this: - Create a NEW folder in /kolab/var/imapd/spool/...../USER (i.e. in the top level - Copy all of the mails you want to restore into that folder - chown -R kolab-r.kolab-r FOLDER (i.e. make certain FOLDER and all contents belong to kolab-r) - Restore that new folder: su - kolab-r -c "cyrreconstruct -r -f user/USER/FOLDER at intronics.nl" - Ask the user to subscribe to this folder, then fetch mail and transfer the mails to wherever (s)he wants to have them. This has always worked for us. Regards, Thomas -- ------------------------------------------------------------------------------ Thomas Ribbrock, IT-Team brightsight From funke at hiskp.uni-bonn.de Wed Mar 4 13:42:19 2009 From: funke at hiskp.uni-bonn.de (Christian Funke) Date: Wed, 4 Mar 2009 13:42:19 +0100 Subject: Restore folder from backup (kolab 2.04) In-Reply-To: <49AE3FB0.1050604@intronics.nl> References: <49AE3FB0.1050604@intronics.nl> Message-ID: <200903041342.20127.funke@hiskp.uni-bonn.de> Am Mittwoch, 4. M?rz 2009 09:45:36 schrieb Jacques Hylkema: > Hello, > > I have problems restoring a folder of one of my users, which he > accidentally deleted. > > I tried the following: > - Restored the folder from a backup using scp > - The folder in question is: > /kolab/var/imapd/spool/domain/intronics.nl/user/j^m^dekker/Leveranciers/R-- >S - Changed the owner and group of the folder and all subfolders and files > to kolab-r / kolab-r > - su - kolab-r > - /kolab/bin/cyrreconstruct -r -f > user/j^m^dekker/Leveranciers/*@intronics.nl > > The output of this displayed all folders within Leveranciers, except the > R--S folder. I did not see any "discover" line and the folder could not > be seen in Thunderbird > Then I deleted all cyrus.* files from the R--S folder, including > sub-folders, and ran the cyrreconstruct again, with the same result. > > I have the following configuration: > > Kolab2 Groupware Server Version > 2.0.4 > Hi, I ran into the same problems a while ago, I solved it by copying the file cyrus.header from a working folder (i. e. the Inbox) to the folder in question, then cyrreconstruct found the folder all mail was available again, albeit marked as unread, but i guess this is only a minor nuisance. Greets Christian From hjkim at bynari.net Wed Mar 4 14:58:00 2009 From: hjkim at bynari.net (Hyun Kim) Date: Wed, 04 Mar 2009 07:58:00 -0600 Subject: Bynari v Toltec Message-ID: <3c9efbff.1c99cd1.24262528.7e2a@bynari.net> You can do some folder sharing with Dovecot. We have some Dovecot users who posted a KDB article about this. If you are interested in Dovecot, just email me, and we will be happy to assist you. Currently, we support Cyrus, Courier, Citadel, and Kolab. We are planning to add Dovecot as our next open source IMAP server to support. Thanks, Hyun Mrs. Hyun Kim President Bynari, Inc. 2639 Electronic Lane, Suite 110 Dallas, Tx 75220 www.bynari.net (214) 350-5772 X59 (214) 789-8674 cell (214) 352-3530 fax -----Original Message----- From: kolab-users-bounces at kolab.org [mailto:kolab-users-bounces at kolab.org] On Behalf Of schmerold1 at gmail.com Sent: Tuesday, March 03, 2009 4:56 PM To: Joon Radley Cc: 'Price,Neil'; kolab-users at kolab.org Subject: Re: Bynari v Toltec Outside the scope of this list, but an item of interest to many is Bynari's compatibility with alternative IMAP servers, such as Dovecot. We have never tested this, so I have no idea how effective and reliable Bynari is when used with Dovecot. Joon Radley wrote: > Hi Neil, > > >> Apparently you can source Bynari in Europe (from Univention) for pretty >> > much > >> the same price as Toltec. >> > > So have the moved away from the yearly renewal fee as well? > > Best Regards > > Joon Radley > Radley Network Technologies CC > Cell: +27 (0)83 368 8557 > Fax: +27 (0)12 998 4346 > E-mail: joon at radleys.co.za > Web: www.toltec.co.za > > _______________________________________________ > Kolab-users mailing list > Kolab-users at kolab.org > https://kolab.org/mailman/listinfo/kolab-users > _______________________________________________ Kolab-users mailing list Kolab-users at kolab.org https://kolab.org/mailman/listinfo/kolab-users From j.hylkema at intronics.nl Wed Mar 4 15:58:15 2009 From: j.hylkema at intronics.nl (Jacques Hylkema) Date: Wed, 04 Mar 2009 15:58:15 +0100 Subject: Restore folder from backup (kolab 2.04) In-Reply-To: <200903041326.30051.itsef-admin@brightsight.com> References: <49AE3FB0.1050604@intronics.nl> <200903041016.40118.itsef-admin@brightsight.com> <49AE69FF.8050000@intronics.nl> <200903041326.30051.itsef-admin@brightsight.com> Message-ID: <49AE9707.3050702@intronics.nl> ITSEF Admin schreef: > On Wednesday 4 March 2009 12:46:07 Jacques Hylkema wrote: > >> ITSEF Admin schreef: >> > [...] > >>> Have you tried reconstructing the top level folder? I.e.: >>> >>> /kolab/bin/cyrreconstruct -r -f user/j^m^dekker/Leveranciers at intronics.nl >>> >> This gives the following result: >> user/j.m.dekker/Leveranciers at intronics.nl >> > > i.e. it did some work on the folder (otherwise cyrreconstruct does not return > anything). > > > [...] > >> However, still no sign of the R--S folder... >> > > Ok, in that case I would try a complete reconstruct of the user's mailbox: > > su - kolab-r -c "cyrreconstruct -r -f user/j^m^dekker/*@intronics.nl" > > followed by > > su - kolab-r -c "cyrreconstruct -r -f user/j^m^dekker at intronics.nl" > Done that. Did not work. For some debugging, I tried the following: su - kolab-r in the mailbox, I created an empty folder backup: mkdir backup chmod -R 700 backup ls -l drwx------ 2 kolab-r kolab-r 4096 2009-03-04 15:31 backup -rw------- 1 kolab-r kolab-r 4 2009-03-04 15:32 cyrus.cache -rw------- 1 kolab-r kolab-r 173 2009-03-04 15:32 cyrus.header -rw------- 1 kolab-r kolab-r 96 2009-03-04 15:32 cyrus.index drwx------ 2 kolab-r kolab-r 4096 2009-03-04 15:32 Trash bash-3.2$ /kolab/bin/cyrreconstruct -r -f user/j^m^dekker/*@intronics.nl user/j.m.dekker/Trash at intronics.nl bash-3.2$ /kolab/bin/cyrreconstruct -r -f user/j^m^dekker at intronics.nl user/j.m.dekker at intronics.nl bash-3.2$ /kolab/bin/cyrreconstruct -r -f user/j^m^dekker*@intronics.nl user/j.m.dekker at intronics.nl user/j.m.dekker/Trash at intronics.nl As you can see, the backupfolder never appears. > We have had problems with this in the past, but at least under 2.1.0, most of > these reconstructions were successful. > > BTW: Maybe this is a stupid question, but: You *DID* check that the folder in > question has not become unsubscribed in the mail client and is therefore not > visible? > Yes, I did. > [...] > >> I think I have to follow another procedure: >> >> Create a (temporary) kolab mailserver with the latest version of kolab. >> Create the user in kolab, and restore the folder to that mailserver. >> reconstruct the folder on that mailserver. >> Add a new account to Thunderbird for the temporary mailserver >> Drag and drop the folder from the new temporary account to the original >> account >> >> Does this seem to be a good workaround to you? >> > > Far too much work. Our standard procedure in case the straightforward > reconstruction of a previously existing folder does not work is this: > > - Create a NEW folder in /kolab/var/imapd/spool/...../USER (i.e. in the top > level > - Copy all of the mails you want to restore into that folder > - chown -R kolab-r.kolab-r FOLDER (i.e. make certain FOLDER and all contents > belong to kolab-r) > - Restore that new folder: > su - kolab-r -c "cyrreconstruct -r -f user/USER/FOLDER at intronics.nl" > - Ask the user to subscribe to this folder, then fetch mail and transfer the > mails to wherever (s)he wants to have them. > > This has always worked for us. > > Regards, > > Thomas > Thanks for your time, Jacques ______________________________________________________________________________________ This outbound message from Intronics B.V. has been checked for all known viruses by KPN MailScan (IV-Scan), powered by MessageLabs. ______________________________________________________________________________________ -------------- next part -------------- An HTML attachment was scrubbed... URL: From liste at gelpi.it Wed Mar 4 19:34:58 2009 From: liste at gelpi.it (Gelpi Andrea) Date: Wed, 04 Mar 2009 19:34:58 +0100 Subject: Restore folder from backup (kolab 2.04) In-Reply-To: <49AE9707.3050702@intronics.nl> References: <49AE3FB0.1050604@intronics.nl> <200903041016.40118.itsef-admin@brightsight.com> <49AE69FF.8050000@intronics.nl> <200903041326.30051.itsef-admin@brightsight.com> <49AE9707.3050702@intronics.nl> Message-ID: <49AEC9D2.6080902@gelpi.it> Jacques Hylkema wrote: . . . > > For some debugging, I tried the following: > su - kolab-r > in the mailbox, I created an empty folder backup: > mkdir backup > chmod -R 700 backup > ls -l > drwx------ 2 kolab-r kolab-r 4096 2009-03-04 15:31 backup > -rw------- 1 kolab-r kolab-r 4 2009-03-04 15:32 cyrus.cache > -rw------- 1 kolab-r kolab-r 173 2009-03-04 15:32 cyrus.header > -rw------- 1 kolab-r kolab-r 96 2009-03-04 15:32 cyrus.index > drwx------ 2 kolab-r kolab-r 4096 2009-03-04 15:32 Trash > > bash-3.2$ /kolab/bin/cyrreconstruct -r -f user/j^m^dekker/*@intronics.nl > > user/j.m.dekker/Trash at intronics.nl > > > bash-3.2$ /kolab/bin/cyrreconstruct -r -f user/j^m^dekker at intronics.nl > > user/j.m.dekker at intronics.nl > > bash-3.2$ /kolab/bin/cyrreconstruct -r -f user/j^m^dekker*@intronics.nl > > user/j.m.dekker at intronics.nl > user/j.m.dekker/Trash at intronics.nl > > > As you can see, the backupfolder never appears. > If the folder is empty it doesn't appear. I confirm. I found a solution, use cyradm and create the folder before reconstruct it. as user kolab-r cyradm --user manager localhost > cm user/j^m^dekker/R--S at intronics.nl > quit su - kolab-r -c "cyrreconstruct -r -f user/j^m^dekker/R--S at intronics.nl" Let me know if it works. -- 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 johnm at advocap.org Wed Mar 4 23:09:15 2009 From: johnm at advocap.org (John McMonagle) Date: Wed, 04 Mar 2009 16:09:15 -0600 Subject: Kolab native debian lenny install? In-Reply-To: <200903041159.26714.martial@paupe.name> References: <49ADAC4C.5000800@advocap.org> <200903041159.26714.martial@paupe.name> Message-ID: <49AEFC0B.3060008@advocap.org> I have looked through the debian kolab develpers list and there is a little info. http://www.kolab.org/pipermail/kolab-devel/2009-February/010054.html Was hoping to avoid bothering the developers with other than bug reports. Figure this is the user list and the proper place for vague dumb questions :-) I do understand that any answer is subjective. My guess is that everything is in pretty good shape other than possibly kolab-webclient. It will likely take a couple months to be ready to go online so have some time to test. Will need to do a lot of tweaking anyway and would rather do it in a environment I know. Suppose I can do a test install and see what happens. John Martial Paupe wrote: > Hi, > > > here is the pkg-kolab-devel's mailinglist address where you will get a > clear > answer about native kolab install process and maybe a status. > > > pkg-kolab-devel at lists.alioth.debian.org > > > Cheers, > -- > Martial Paupe > > > > On Wed, 04 Mar 2009 11:16:44 John McMonagle wrote: > > Is it feasible to do a native debian lenny install of Kolab? > > > > I prefer a native install but it's also important that it works :-) > > > > It looks like some of the needed parts are not in lenny but are in > > testing and unstable. > > kolabd, kolabadmin , kolab-webadmin and others are only in testing and > > unstable > > > > Are all the needed packages available? > > I'm Ok with building from source packages. > > > > How about horde? > > > > Thanks > > > > John > > > > - > > > > John McMonagle > > IT Manager > > Advocap Inc. > > > > > > _______________________________________________ > > Kolab-users mailing list > > Kolab-users at kolab.org > > https://kolab.org/mailman/listinfo/kolab-users > > > ------------------------------------------------------------------------ > > _______________________________________________ > Kolab-users mailing list > Kolab-users at kolab.org > https://kolab.org/mailman/listinfo/kolab-users > From pdf at yugm.org Thu Mar 5 00:20:27 2009 From: pdf at yugm.org (Paul Douglas Franklin) Date: Wed, 04 Mar 2009 15:20:27 -0800 Subject: Certificate doesn't verify Message-ID: <49AF0CBB.10301@yugm.org> I have a user who connects from on or off site using Outlook 2003. He keeps getting the following message: "The server you are connected to is using a security certificate that could not be verified. The certificate chain processed but terminated in a root certificate which is not trusted by the trust provider. Do you want to continue using this server?" When my Thunderbird complained, I simply told it to accept the certificate, and it did so. But Outlook doesn't seem to want to remember that. I believe that it has to do with the name of the server vs the name on the certificate. Would this be a likely cause? If so, it's my error: I was deciding between two different names and just didn't enter the correct one when I created the certificate. How do I ascertain the name on the certificate? And can I create a new certificate, or do I need to change the name of my server? I can think of three places where I figure the name should match: DNS, host name, and certificate. Is this correct? If the non-matching names are not the problem, what would it be? --Paul -- Paul Douglas Franklin Computer Manager, Union Gospel Mission of Yakima, Washington Husband of Danette Father of Laurene, Miriam, Tycko, Timothy, Sarabeth, Marie, Dawnita, Anna Leah, Alexander, and Caleb From akopciuch at bddf.ca Thu Mar 5 05:43:49 2009 From: akopciuch at bddf.ca (Andrew J. Kopciuch) Date: Wed, 4 Mar 2009 21:43:49 -0700 Subject: Certificate doesn't verify In-Reply-To: <49AF0CBB.10301@yugm.org> References: <49AF0CBB.10301@yugm.org> Message-ID: <200903042143.53770.akopciuch@bddf.ca> On March 4, 2009, Paul Douglas Franklin wrote: > I have a user who connects from on or off site using Outlook 2003. He > keeps getting the following message: > "The server you are connected to is using a security certificate that > could not be verified. The certificate chain processed but terminated > in a root certificate which is not trusted by the trust provider. Do > you want to continue using this server?" An installation contains a self signed SSL certificate. If you read that message carefully, it means exactly what it says. In a dumbed down version : when Outlook is checking the certificate, it sees it is signed, but can't tell who signed it. If you want to get rid of this error, you need to get your certificate actually signed by someone trusted. (Big names like verisign, and thawte are examples). There are many other smaller recognized providers like comodo, or godaddy and hundreds of others really. Those are just 2 I have used in the past. > When my Thunderbird complained, I simply told it to accept the > certificate, and it did so. But Outlook doesn't seem to want to > remember that. Yes. Outllook does not seem to have this capability like many other email clients. I think there is a way you can import the "untrusted" root certificate into windows, and this message would go away ... but you should really get your certificates signed by someone trusted anyways. > I believe that it has to do with the name of the server vs the name on > the certificate. Would this be a likely cause? No. You would get an error talking about the name of the server not matching the common name on the certificate in that case. > If so, it's my error: I was deciding between two different names and > just didn't enter the correct one when I created the certificate. How > do I ascertain the name on the certificate? And can I create a new openssl x509 -noout -text -in cert.pem > certificate, or do I need to change the name of my server? I can think > of three places where I figure the name should match: DNS, host name, > and certificate. Is this correct? > If the non-matching names are not the problem, what would it be? /kolab/etc/kolab/kolab_sslcert.sh will recreate the self signed certificate that you can use, but it is still untrusted. You should get a real SSL certificate and use that. Andy -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. URL: From wrobel at pardus.de Thu Mar 5 05:56:25 2009 From: wrobel at pardus.de (Gunnar Wrobel) Date: Thu, 05 Mar 2009 05:56:25 +0100 Subject: source install fails on Freetype installation In-Reply-To: <49AC2084.DB9C.0010.0@milprog.ch> References: <49AC2084.DB9C.0010.0@milprog.ch> Message-ID: <20090305055625.13401pyw0a9lsjok@webmail.pardus.de> Quoting Marcel Gsteiger : > Hi all > > I try to build kolab 2.2.0 from source on a vanilla CentOS 5.2 > (=RHEL) - i386 host. The build process starts as expected, but after > about 90 minutes I get the error > -- > make: *** No rule to make target `install'. Stop. > -- > while compiling freetype. Further logfile information see below. The > same error occurs with 2.2.1 beta. > > Any help on how to fix this would much be appreciated. Sound pretty much like this report: http://www.mail-archive.com/openpkg-users at openpkg.org/msg03490.html So it would be an OpenPKG specific problem. I do not understand why one does not get it on every machine though. The fix should probably be to exchange the 'make setup' call in the specfile with './configure'. But contrary to the message thread linked above the spec file in the OpenPKG repository has not been changed (http://cvs.openpkg.org/fileview?f=openpkg-src/freetype/freetype.spec&v=1.74) You should open a bug report about this. Cheers, Gunnar > > Regards > --Marcel > > (snip) > > FreeType build system -- automatic system detection > > The following settings are used: > > platform ansi > compiler /kolab/bin/cc > configuration directory ./builds/ansi > configuration rules ./builds/ansi/ansi.mk > > If this does not correspond to your system or settings please remove the file > `config.mk' from this directory then read the INSTALL file for help. > > Otherwise, simply type `/kolab/bin/make' again to build the library, > or `/kolab/bin/make refdoc' to build the API reference (the latter > needs python). > > Generating modules list in ./objs/ftmodule.h... > * module: truetype (Windows/Mac font files with extension *.ttf or *.ttc) > * module: type1 (Postscript font files with extension *.pfa or *.pfb) > * module: cff (OpenType fonts with extension *.otf) > * module: cid (Postscript CID-keyed fonts, no known extension) > * module: pfr (PFR/TrueDoc font files with extension *.pfr) > * module: type42 (Type 42 font files with no known extension) > * module: winfnt (Windows bitmap fonts with extension *.fnt or *.fon) > * module: pcf (pcf bitmap fonts) > * module: bdf (bdf bitmap fonts) > * module: sfnt (helper module for TrueType & OpenType formats) > * module: autofit (automatic hinting module) > * module: pshinter (Postscript hinter module) > * module: raster (monochrome bitmap renderer) > * module: smooth (anti-aliased bitmap renderer) > * module: smooth (anti-aliased bitmap renderer for LCDs) > * module: smooth (anti-aliased bitmap renderer for vertical LCDs) > * module: psaux (Postscript Type 1 & Type 2 helper module) > * module: psnames (Postscript & Unicode Glyph name handling) > done. > + /kolab/bin/make --no-print-directory > cc -I./objs -I./builds/ansi -I./include -c -DFT2_BUILD_LIBRARY > -DFT_CONFIG_MODULES_H="" -o objs/ftsystem.o > src/base/ftsystem.c > cc -I./objs -I./builds/ansi -I./include -c -DFT2_BUILD_LIBRARY > -DFT_CONFIG_MODULES_H="" -o objs/ftdebug.o > src/base/ftdebug.c > cc -I./objs -I./builds/ansi -I./include -c -DFT2_BUILD_LIBRARY > -DFT_CONFIG_MODULES_H="" -o objs/ftinit.o > src/base/ftinit.c > cc -I./objs -I./builds/ansi -I./include -c -DFT2_BUILD_LIBRARY > -DFT_CONFIG_MODULES_H="" -I./src/base -o objs/ftbase.o > ./src/base/ftbase.c > cc -I./objs -I./builds/ansi -I./include -c -DFT2_BUILD_LIBRARY > -DFT_CONFIG_MODULES_H="" -I./src/base -o objs/ftbbox.o > src/base/ftbbox.c > cc -I./objs -I./builds/ansi -I./include -c -DFT2_BUILD_LIBRARY > -DFT_CONFIG_MODULES_H="" -I./src/base -o objs/ftbdf.o > src/base/ftbdf.c > cc -I./objs -I./builds/ansi -I./include -c -DFT2_BUILD_LIBRARY > -DFT_CONFIG_MODULES_H="" -I./src/base -o > objs/ftbitmap.o src/base/ftbitmap.c > cc -I./objs -I./builds/ansi -I./include -c -DFT2_BUILD_LIBRARY > -DFT_CONFIG_MODULES_H="" -I./src/base -o objs/ftglyph.o > src/base/ftglyph.c > cc -I./objs -I./builds/ansi -I./include -c -DFT2_BUILD_LIBRARY > -DFT_CONFIG_MODULES_H="" -I./src/base -o objs/ftgxval.o > src/base/ftgxval.c > cc -I./objs -I./builds/ansi -I./include -c -DFT2_BUILD_LIBRARY > -DFT_CONFIG_MODULES_H="" -I./src/base -o objs/ftmm.o > src/base/ftmm.c > cc -I./objs -I./builds/ansi -I./include -c -DFT2_BUILD_LIBRARY > -DFT_CONFIG_MODULES_H="" -I./src/base -o objs/ftotval.o > src/base/ftotval.c > cc -I./objs -I./builds/ansi -I./include -c -DFT2_BUILD_LIBRARY > -DFT_CONFIG_MODULES_H="" -I./src/base -o objs/ftpfr.o > src/base/ftpfr.c > cc -I./objs -I./builds/ansi -I./include -c -DFT2_BUILD_LIBRARY > -DFT_CONFIG_MODULES_H="" -I./src/base -o > objs/ftstroke.o src/base/ftstroke.c > cc -I./objs -I./builds/ansi -I./include -c -DFT2_BUILD_LIBRARY > -DFT_CONFIG_MODULES_H="" -I./src/base -o objs/ftsynth.o > src/base/ftsynth.c > cc -I./objs -I./builds/ansi -I./include -c -DFT2_BUILD_LIBRARY > -DFT_CONFIG_MODULES_H="" -I./src/base -o objs/fttype1.o > src/base/fttype1.c > cc -I./objs -I./builds/ansi -I./include -c -DFT2_BUILD_LIBRARY > -DFT_CONFIG_MODULES_H="" -I./src/base -o > objs/ftwinfnt.o src/base/ftwinfnt.c > cc -I./objs -I./builds/ansi -I./include -c -DFT2_BUILD_LIBRARY > -DFT_CONFIG_MODULES_H="" -I./src/base -o objs/ftxf86.o > src/base/ftxf86.c > cc -I./objs -I./builds/ansi -I./include -c -DFT2_BUILD_LIBRARY > -DFT_CONFIG_MODULES_H="" -I./src/base -o > objs/ftlcdfil.o src/base/ftlcdfil.c > cc -I./objs -I./builds/ansi -I./include -c -DFT2_BUILD_LIBRARY > -DFT_CONFIG_MODULES_H="" -I./src/base -o objs/ftgasp.o > src/base/ftgasp.c > cc -I./objs -I./builds/ansi -I./include -c -DFT2_BUILD_LIBRARY > -DFT_CONFIG_MODULES_H="" -I./src/base -o > objs/ftpatent.o src/base/ftpatent.c > cc -I./objs -I./builds/ansi -I./include -c -DFT2_BUILD_LIBRARY > -DFT_CONFIG_MODULES_H="" -I./src/truetype -o > objs/truetype.o ./src/truetype/truetype.c > cc -I./objs -I./builds/ansi -I./include -c -DFT2_BUILD_LIBRARY > -DFT_CONFIG_MODULES_H="" -I./src/type1 -o objs/type1.o > ./src/type1/type1.c > cc -I./objs -I./builds/ansi -I./include -c -DFT2_BUILD_LIBRARY > -DFT_CONFIG_MODULES_H="" -I./src/cff -o objs/cff.o > ./src/cff/cff.c > cc -I./objs -I./builds/ansi -I./include -c -DFT2_BUILD_LIBRARY > -DFT_CONFIG_MODULES_H="" -I./src/cid -o objs/type1cid.o > ./src/cid/type1cid.c > cc -I./objs -I./builds/ansi -I./include -c -DFT2_BUILD_LIBRARY > -DFT_CONFIG_MODULES_H="" -I./src/pfr -o objs/pfr.o > ./src/pfr/pfr.c > cc -I./objs -I./builds/ansi -I./include -c -DFT2_BUILD_LIBRARY > -DFT_CONFIG_MODULES_H="" -I./src/type42 -o > objs/type42.o ./src/type42/type42.c > cc -I./objs -I./builds/ansi -I./include -c -DFT2_BUILD_LIBRARY > -DFT_CONFIG_MODULES_H="" -I./src/winfonts -o > objs/winfnt.o ./src/winfonts/winfnt.c > cc -I./objs -I./builds/ansi -I./include -c -DFT2_BUILD_LIBRARY > -DFT_CONFIG_MODULES_H="" -I./src/pcf -o objs/pcf.o > ./src/pcf/pcf.c > cc -I./objs -I./builds/ansi -I./include -c -DFT2_BUILD_LIBRARY > -DFT_CONFIG_MODULES_H="" -I./src/bdf -o objs/bdf.o > ./src/bdf/bdf.c > cc -I./objs -I./builds/ansi -I./include -c -DFT2_BUILD_LIBRARY > -DFT_CONFIG_MODULES_H="" -I./src/sfnt -o objs/sfnt.o > ./src/sfnt/sfnt.c > cc -I./objs -I./builds/ansi -I./include -c -DFT2_BUILD_LIBRARY > -DFT_CONFIG_MODULES_H="" -I./src/autofit -o > objs/autofit.o ./src/autofit/autofit.c > cc -I./objs -I./builds/ansi -I./include -c -DFT2_BUILD_LIBRARY > -DFT_CONFIG_MODULES_H="" -I./src/pshinter -o > objs/pshinter.o ./src/pshinter/pshinter.c > cc -I./objs -I./builds/ansi -I./include -c -DFT2_BUILD_LIBRARY > -DFT_CONFIG_MODULES_H="" -I./src/raster -o > objs/raster.o ./src/raster/raster.c > cc -I./objs -I./builds/ansi -I./include -c -DFT2_BUILD_LIBRARY > -DFT_CONFIG_MODULES_H="" -I./src/smooth -o > objs/smooth.o ./src/smooth/smooth.c > cc -I./objs -I./builds/ansi -I./include -c -DFT2_BUILD_LIBRARY > -DFT_CONFIG_MODULES_H="" -I./src/cache -o > objs/ftcache.o ./src/cache/ftcache.c > cc -I./objs -I./builds/ansi -I./include -c -DFT2_BUILD_LIBRARY > -DFT_CONFIG_MODULES_H="" -I./src/gzip -o objs/ftgzip.o > ./src/gzip/ftgzip.c > cc -I./objs -I./builds/ansi -I./include -c -DFT2_BUILD_LIBRARY > -DFT_CONFIG_MODULES_H="" -I./src/lzw -o objs/ftlzw.o > ./src/lzw/ftlzw.c > cc -I./objs -I./builds/ansi -I./include -c -DFT2_BUILD_LIBRARY > -DFT_CONFIG_MODULES_H="" -I./src/psaux -o objs/psaux.o > ./src/psaux/psaux.c > cc -I./objs -I./builds/ansi -I./include -c -DFT2_BUILD_LIBRARY > -DFT_CONFIG_MODULES_H="" -I./src/psnames -o > objs/psnames.o ./src/psnames/psmodule.c > rm -f ./objs/libfreetype.a > ar -r objs/libfreetype.a ./objs/ftsystem.o ./objs/ftdebug.o > ./objs/ftinit.o ./objs/ftbase.o ./objs/ftbbox.o ./objs/ftbdf.o > ./objs/ftbitmap.o ./objs/ftglyph.o ./objs/ftgxval.o ./objs/ftmm.o > ./objs/ftotval.o ./objs/ftpfr.o ./objs/ftstroke.o ./objs/ftsynth.o > ./objs/fttype1.o ./objs/ftwinfnt.o ./objs/ftxf86.o ./objs/ftlcdfil.o > ./objs/ftgasp.o ./objs/ftpatent.o ./objs/truetype.o ./objs/type1.o > ./objs/cff.o ./objs/type1cid.o ./objs/pfr.o ./objs/type42.o > ./objs/winfnt.o ./objs/pcf.o ./objs/bdf.o ./objs/sfnt.o > ./objs/autofit.o ./objs/pshinter.o ./objs/raster.o ./objs/smooth.o > ./objs/ftcache.o ./objs/ftgzip.o ./objs/ftlzw.o ./objs/psaux.o > ./objs/psnames.o > ar: creating objs/libfreetype.a > + exit 0 > Executing(%install): env -i /kolab/lib/openpkg/bash --norc > --noprofile --posix -e /kolab/RPM/TMP/rpm-tmp.20811 > + cd /kolab/RPM/TMP > + cd freetype-2.3.5 > + rm -rf /kolab/RPM/TMP/freetype-2.3.5-root > + /kolab/bin/make --no-print-directory install > DESTDIR=/kolab/RPM/TMP/freetype-2.3.5-root > make: *** No rule to make target `install'. Stop. > error: Bad exit status from /kolab/RPM/TMP/rpm-tmp.20811 (%install) > > > RPM build errors: > Bad exit status from /kolab/RPM/TMP/rpm-tmp.20811 (%install) > > _______________________________________________ > Kolab-users mailing list > Kolab-users at kolab.org > https://kolab.org/mailman/listinfo/kolab-users > -- ______ 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. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: Digitale PGP-Unterschrift URL: From wrobel at pardus.de Thu Mar 5 06:31:56 2009 From: wrobel at pardus.de (Gunnar Wrobel) Date: Thu, 05 Mar 2009 06:31:56 +0100 Subject: Bynari v Toltec In-Reply-To: <1236092606.23260.2@pc-adr2> References: <49AC68DD.7090406@gmail.com> <1236092606.23260.2@pc-adr2> Message-ID: <20090305063156.21442jqlmq6mt9kw@webmail.pardus.de> Quoting Albrecht Dre? : > Am 03.03.2009 00:16:45 schrieb(en) schmerold1 at gmail.com: >> Anyone care to comment what makes Bynari worth the upcharge? > > Before choosing a connector, you should carefully evaluate if the > different products available work properly for your requirements. We > are currently using Toltec, but it has some issues which emerged in > "daily use" only (e.g. [1] is really a blocker for us), so I'm also in > the process of checking alternatives again. > > I know that there are some entries about Toltec issues in the tracker, > but I don't know if the other products are also tracked there. They are not. At least not in general. The fact that Toltec is present in there has historical reasons. Cheers, Gunnar > You may > also want to search the wiki or the mail archives, iirc there was a > comparison somewhere. > > Best, Albrecht. > > [1] > > _______________________________________________ > Kolab-users mailing list > Kolab-users at kolab.org > https://kolab.org/mailman/listinfo/kolab-users > -- ____ 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 Thu Mar 5 07:53:54 2009 From: wrobel at pardus.de (Gunnar Wrobel) Date: Thu, 05 Mar 2009 07:53:54 +0100 Subject: Kolab native debian lenny install? In-Reply-To: <49ADAC4C.5000800@advocap.org> References: <49ADAC4C.5000800@advocap.org> Message-ID: <20090305075354.97242cpoclahi2o0@webmail.pardus.de> Quoting John McMonagle : > Is it feasible to do a native debian lenny install of Kolab? > > I prefer a native install but it's also important that it works :-) The Kolab Konsortium still recommends using the OpenPKG for any productive system. This is not meant to discredit the native installations. But you have to take into account that the Kolab Server is a very complex beast. Every release needs extensive testing and the OpenPKG variant is the only version that currently gets this (as far as I know). For a productive system you also want to have a clean upgrade path which is again something you will probably only get with the OpenPKG variant. I'm no fan of OpenPKG either and I consider the native variants as very important to the progress of Kolab in general. But for productive systems I still discourage from using them. Cheers, Gunnar > > It looks like some of the needed parts are not in lenny but are in > testing and unstable. > kolabd, kolabadmin , kolab-webadmin and others are only in testing and > unstable > > Are all the needed packages available? > I'm Ok with building from source packages. > > How about horde? > > Thanks > > John > > - > > John McMonagle > IT Manager > Advocap Inc. > > > _______________________________________________ > Kolab-users mailing list > Kolab-users at kolab.org > https://kolab.org/mailman/listinfo/kolab-users > -- ______ 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. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: Digitale PGP-Unterschrift URL: From j.hylkema at intronics.nl Thu Mar 5 07:56:13 2009 From: j.hylkema at intronics.nl (Jacques Hylkema) Date: Thu, 05 Mar 2009 07:56:13 +0100 Subject: Restore folder from backup (kolab 2.04) SOLVED In-Reply-To: <49AEC9D2.6080902@gelpi.it> References: <49AE3FB0.1050604@intronics.nl> <200903041016.40118.itsef-admin@brightsight.com> <49AE69FF.8050000@intronics.nl> <200903041326.30051.itsef-admin@brightsight.com> <49AE9707.3050702@intronics.nl> <49AEC9D2.6080902@gelpi.it> Message-ID: <49AF778D.0@intronics.nl> Gelpi Andrea schreef: > Jacques Hylkema wrote: > > . . . > > >> For some debugging, I tried the following: >> su - kolab-r >> in the mailbox, I created an empty folder backup: >> mkdir backup >> chmod -R 700 backup >> ls -l >> drwx------ 2 kolab-r kolab-r 4096 2009-03-04 15:31 backup >> -rw------- 1 kolab-r kolab-r 4 2009-03-04 15:32 cyrus.cache >> -rw------- 1 kolab-r kolab-r 173 2009-03-04 15:32 cyrus.header >> -rw------- 1 kolab-r kolab-r 96 2009-03-04 15:32 cyrus.index >> drwx------ 2 kolab-r kolab-r 4096 2009-03-04 15:32 Trash >> >> bash-3.2$ /kolab/bin/cyrreconstruct -r -f user/j^m^dekker/*@intronics.nl >> >> user/j.m.dekker/Trash at intronics.nl >> >> >> bash-3.2$ /kolab/bin/cyrreconstruct -r -f user/j^m^dekker at intronics.nl >> >> user/j.m.dekker at intronics.nl >> >> bash-3.2$ /kolab/bin/cyrreconstruct -r -f user/j^m^dekker*@intronics.nl >> >> user/j.m.dekker at intronics.nl >> user/j.m.dekker/Trash at intronics.nl >> >> >> As you can see, the backupfolder never appears. >> >> > > If the folder is empty it doesn't appear. I confirm. > > I found a solution, use cyradm and create the folder before reconstruct it. > > as user kolab-r > > cyradm --user manager localhost > >> cm user/j^m^dekker/R--S at intronics.nl >> quit >> > > su - kolab-r -c "cyrreconstruct -r -f user/j^m^dekker/R--S at intronics.nl" > > Let me know if it works. > > Yes! You're the greatest! When I created the directory using cyradm, and restored the directories/files below from backup, and ran cyrreconstruct, it worked perfectly. I would like to thank everyone for their help and time. Jacques ______________________________________________________________________________________ This outbound message from Intronics B.V. has been checked for all known viruses by KPN MailScan (IV-Scan), powered by MessageLabs. ______________________________________________________________________________________ -------------- next part -------------- An HTML attachment was scrubbed... URL: From ml at radoeka.nl Thu Mar 5 08:15:08 2009 From: ml at radoeka.nl (Richard Bos) Date: Thu, 5 Mar 2009 08:15:08 +0100 Subject: Restore folder from backup (kolab 2.04) SOLVED In-Reply-To: <49AF778D.0@intronics.nl> References: <49AE3FB0.1050604@intronics.nl> <200903041016.40118.itsef-admin@brightsight.com> <49AE69FF.8050000@intronics.nl> <200903041326.30051.itsef-admin@brightsight.com> <49AE9707.3050702@intronics.nl> <49AEC9D2.6080902@gelpi.it> <49AF778D.0@intronics.nl> Message-ID: <20090305071508.GA77711@xs4all.nl> Hallo Jacques, On Thu, Mar 05, 2009 at 07:56:13AM +0100, Jacques Hylkema wrote: > Yes! You're the greatest! > When I created the directory using cyradm, and restored the > directories/files below from backup, and ran cyrreconstruct, it worked > perfectly. > > I would like to thank everyone for their help and time. it would be nice if you could add the solution to the wiki. People will be thankful for you, if you would do that :) The right spot to add the procedure could be: http://wiki.kolab.org/index.php/Backups_for_kolab2 -- Richard From j.hylkema at intronics.nl Thu Mar 5 09:11:28 2009 From: j.hylkema at intronics.nl (Jacques Hylkema) Date: Thu, 05 Mar 2009 09:11:28 +0100 Subject: Restore folder from backup (kolab 2.04) SOLVED In-Reply-To: <20090305071508.GA77711@xs4all.nl> References: <49AE3FB0.1050604@intronics.nl> <200903041016.40118.itsef-admin@brightsight.com> <49AE69FF.8050000@intronics.nl> <200903041326.30051.itsef-admin@brightsight.com> <49AE9707.3050702@intronics.nl> <49AEC9D2.6080902@gelpi.it> <49AF778D.0@intronics.nl> <20090305071508.GA77711@xs4all.nl> Message-ID: <49AF8930.6050409@intronics.nl> Richard Bos schreef: > Hallo Jacques, > > On Thu, Mar 05, 2009 at 07:56:13AM +0100, Jacques Hylkema wrote: > >> Yes! You're the greatest! >> When I created the directory using cyradm, and restored the >> directories/files below from backup, and ran cyrreconstruct, it worked >> perfectly. >> >> I would like to thank everyone for their help and time. >> > > it would be nice if you could add the solution to the wiki. > People will be thankful for you, if you would do that :) > > The right spot to add the procedure could be: > http://wiki.kolab.org/index.php/Backups_for_kolab2 > > Hi Richard, I have added the solution to the wiki: http://wiki.kolab.org/index.php/Backups_for_kolab2#IMAP_folder_recovery_from_backup_.28cyrus.29 Jacques ______________________________________________________________________________________ This outbound message from Intronics B.V. has been checked for all known viruses by KPN MailScan (IV-Scan), powered by MessageLabs. ______________________________________________________________________________________ -------------- next part -------------- An HTML attachment was scrubbed... URL: From itsef-admin at brightsight.com Thu Mar 5 09:33:42 2009 From: itsef-admin at brightsight.com (ITSEF Admin) Date: Thu, 5 Mar 2009 09:33:42 +0100 Subject: Restore folder from backup (kolab 2.04) In-Reply-To: <49AEC9D2.6080902@gelpi.it> References: <49AE3FB0.1050604@intronics.nl> <49AE9707.3050702@intronics.nl> <49AEC9D2.6080902@gelpi.it> Message-ID: <200903050933.42619.itsef-admin@brightsight.com> On Wednesday 4 March 2009 19:34:58 Gelpi Andrea wrote: [...] > I found a solution, use cyradm and create the folder before reconstruct it. > > as user kolab-r > > cyradm --user manager localhost > > > cm user/j^m^dekker/R--S at intronics.nl > > quit [...] Duh - silly me, I clearly was not fully awake when writing my previous mail - yes, you're absolutely right, you need to use cyadm to create the folder, not just mkdir. We even have that written down in our own internal procedures and I still completely forgot about that... :-/ Regards, Thomas -- ------------------------------------------------------------------------------ Thomas Ribbrock, IT-Team brightsight From itsef-admin at brightsight.com Thu Mar 5 09:39:30 2009 From: itsef-admin at brightsight.com (ITSEF Admin) Date: Thu, 5 Mar 2009 09:39:30 +0100 Subject: Restore folder from backup (kolab 2.04) SOLVED In-Reply-To: <49AF8930.6050409@intronics.nl> References: <49AE3FB0.1050604@intronics.nl> <20090305071508.GA77711@xs4all.nl> <49AF8930.6050409@intronics.nl> Message-ID: <200903050939.30130.itsef-admin@brightsight.com> On Thursday 5 March 2009 09:11:28 Jacques Hylkema wrote: > I have added the solution to the wiki: > http://wiki.kolab.org/index.php/Backups_for_kolab2#IMAP_folder_recovery_from_backup_.28cyrus.29 Thanks Jacques - and I've added my remark about the quotas to that as well. Cheerio, Thomas -- ------------------------------------------------------------------------------ Thomas Ribbrock, IT-Team brightsight From bernhard at intevation.de Thu Mar 5 12:03:35 2009 From: bernhard at intevation.de (Bernhard Reiter) Date: Thu, 5 Mar 2009 12:03:35 +0100 Subject: IMAP Servers (was: Bynari v Toltec) In-Reply-To: <49ADB577.50008@gmail.com> References: <7B91BBC61758DD1183BE000C296D2CA70DC1B1@ct-exchange.wins.lawco.com> <000301c99c12$2a1fa0b0$7e5ee210$@co.za> <49ADB577.50008@gmail.com> Message-ID: <200903051203.38742.bernhard@intevation.de> Am Dienstag, 3. M?rz 2009 23:55:51 schrieb schmerold1 at gmail.com: > Outside the scope of this list, but an item of interest to many is > Bynari's compatibility with alternative IMAP servers, such as Dovecot. Note that Kolab Server is much more than just an IMAP server, it needs a few more scripts for a greater groupware experience. Especially freebusy list generation, automatic invitation handling, folder sharing and so on. I think all Outlook connectors can just connect to an IMAP server, but they will lack some groupware features. Cyrus IMAP leads in features when we constructed Kolab Server so we took it as base and added some more scripts to the whole setup. In the last half year we tried experimentally to also use dovecot as IMAP server, and we did some developments so Dovecot comes closer in features, e.g. the necessary folder sharing. It is not quite there yet and not fully integrated. Development help is - as always appreciated - ask on kolab-devel@ for 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: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From bernhard at intevation.de Thu Mar 5 12:09:20 2009 From: bernhard at intevation.de (Bernhard Reiter) Date: Thu, 5 Mar 2009 12:09:20 +0100 Subject: Certificate doesn't verify In-Reply-To: <200903042143.53770.akopciuch@bddf.ca> References: <49AF0CBB.10301@yugm.org> <200903042143.53770.akopciuch@bddf.ca> Message-ID: <200903051209.20672.bernhard@intevation.de> Am Donnerstag, 5. M?rz 2009 05:43:49 schrieb Andrew J. Kopciuch: > On March 4, 2009, Paul Douglas Franklin wrote: > > I have a user who connects from on or off site using Outlook 2003. ?He > > keeps getting the following message: > > "The server you are connected to is using a security certificate that > > could not be verified. ?The certificate chain processed but terminated > > in a root certificate which is not trusted by the trust provider. ?Do > > you want to continue using this server?" > > An installation contains a self signed SSL certificate. ?If you read that > message carefully, it means exactly what it says. ?In a dumbed down version > : when Outlook is checking the certificate, it sees it is signed, but can't > tell who signed it. You can try to import the certificate and possibly the root certificate into the certificate story of your client. One way to do this is to use IE and see if you can make it issue no warning anymore after the import. > > If you want to get rid of this error, you need to get your certificate > actually signed by someone trusted. ? -- 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: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From j.hylkema at intronics.nl Thu Mar 5 15:03:53 2009 From: j.hylkema at intronics.nl (Jacques Hylkema) Date: Thu, 05 Mar 2009 15:03:53 +0100 Subject: Restore folder from backup (kolab 2.04) SOLVED In-Reply-To: <200903050939.30130.itsef-admin@brightsight.com> References: <49AE3FB0.1050604@intronics.nl> <20090305071508.GA77711@xs4all.nl> <49AF8930.6050409@intronics.nl> <200903050939.30130.itsef-admin@brightsight.com> Message-ID: <49AFDBC9.2040405@intronics.nl> ITSEF Admin schreef: > On Thursday 5 March 2009 09:11:28 Jacques Hylkema wrote: > >> I have added the solution to the wiki: >> >> > http://wiki.kolab.org/index.php/Backups_for_kolab2#IMAP_folder_recovery_from_backup_.28cyrus.29 > > Thanks Jacques - and I've added my remark about the quotas to that as well. > > Cheerio, > > Thomas > Good point! I forgot about that. Regards, Jacques ______________________________________________________________________________________ This outbound message from Intronics B.V. has been checked for all known viruses by KPN MailScan (IV-Scan), powered by MessageLabs. ______________________________________________________________________________________ -------------- next part -------------- An HTML attachment was scrubbed... URL: From martial.paupe at metservice.com Tue Mar 3 23:25:13 2009 From: martial.paupe at metservice.com (Martial Paupe) Date: Wed, 4 Mar 2009 11:25:13 +1300 Subject: Kolab native debian lenny install? In-Reply-To: <49ADAC4C.5000800@advocap.org> References: <49ADAC4C.5000800@advocap.org> Message-ID: <200903041125.13207.martial.paupe@metservice.com> Hi, here is the pkg-kolab-devel's mailinglist address where you will get a clear answer about native kolab install process and maybe a status. pkg-kolab-devel at lists.alioth.debian.org Cheers, -- Martial Paupe On Wed, 04 Mar 2009 11:16:44 John McMonagle wrote: > Is it feasible to do a native debian lenny install of Kolab? > > I prefer a native install but it's also important that it works :-) > > It looks like some of the needed parts are not in lenny but are in > testing and unstable. > kolabd, kolabadmin , kolab-webadmin and others are only in testing and > unstable > > Are all the needed packages available? > I'm Ok with building from source packages. > > How about horde? > > Thanks > > John > > - > > John McMonagle > IT Manager > Advocap Inc. > > > _______________________________________________ > Kolab-users mailing list > Kolab-users at kolab.org > https://kolab.org/mailman/listinfo/kolab-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomas at intevation.de Thu Mar 5 17:26:47 2009 From: thomas at intevation.de (Thomas Arendsen Hein) Date: Thu, 5 Mar 2009 17:26:47 +0100 Subject: Kolab Server 2.2.1 Release Candidate 1 Message-ID: <20090305162647.GA1490.thomas@intevation.de> Hi! I just uploaded Kolab Server 2.2.1-rc1 which contains about 60 enhancements and fixes compared to beta1. Please make sure to follow the upgrade instructions in 1st.README, especially if upgrading from server 2.2.0 or older. Again many thanks to all the people who helped with this! Documentation and OpenPKG source packages will soon be available in the directory server/beta/kolab-server-2.2.1-rc-1/ of the mirrors listed on http://kolab.org/mirrors.html for example: http://ftp.gwdg.de/pub/linux/kolab/server/beta/kolab-server-2.2.1-rc-1/ ftp://ftp.gwdg.de/pub/linux/kolab/server/beta/kolab-server-2.2.1-rc-1/ rsync://rsync.kolab.org/kolab/RSYNC.txt explains how to get (or mirror) the files via rsync. All files updated since 2.2.1-beta1 are available in the directory server/development-2.2/20090305-since-20081212/ You can check the integrity of the downloaded files with: $ gpg --keyserver hkp://subkeys.pgp.net --recv-key 5816791A or import the key from https://www.intevation.de/~thomas/gpg_pub_key.asc (the same key that I used to sign this email) $ gpg --verify SHA1SUMS.sig $ sha1sum -c SHA1SUMS Binary packages for Debian GNU/Linux (etch/stable) on x86 platforms can be found in the ix86-debian4.0 directory next to the sources. Please look at 1st.README and release-notes.txt (attached for your convenience) for install instructions and more information about this release. Please report any problems you encounter in our issue tracker: https://issues.kolab.org/ Regards, Thomas Arendsen Hein -- thomas at intevation.de - http://intevation.de/~thomas/ - OpenPGP key: 0x5816791A Intevation GmbH, Neuer Graben 17, 49074 Osnabrueck - AG Osnabrueck, HR B 18998 Geschaeftsfuehrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- Kolab Server 2.2 Install and Upgrade Information ================================================ (Version 20090305, Kolab Server 2.2.1-rc1 See http://kolab.org/ for general information about Kolab, or look at http://wiki.kolab.org/ for specific topics. It is recommended to subscribe to the announcement mailing list at http://kolab.org/mailman/listinfo/kolab-announce to receive security advisories and release announcements. Quick install instructions -------------------------- Kolab server and the Kolab web client (based on Horde) will use about 1GB of disk space for the initial install. By default the directory /kolab will be used, which should be an empty directory or a symbolic link to an empty directory. If this directory does not yet exist, it will be automatically created. For production use it is recommended to create a separate partition for /kolab (2GB to have some spare) and partitions for /kolab/var (at least 2GB for log files, virus filtering and caches) and /kolab/var/imapd/spool (with enough space for your users' mails). For evaluation you could start with the 2GB partition for /kolab (or 2GB free space on / if you only have one big partition for your test system) and create the other partitions when needed. Do _not_ use an NFS mounted drive! Make sure that the following names are not in /etc/passwd or /etc/groups, as OpenPKG will want to create them: "kolab" "kolab-r" "kolab-n" To install the Kolab server, you need to download the files from the directory containing this file (1st.README) to some local directory. You can check the integrity of the downloaded files with: $ gpg --keyserver hkp://subkeys.pgp.net --recv-key 5816791A or import the key from https://www.intevation.de/~thomas/gpg_pub_key.asc $ gpg --verify SHA1SUMS.sig $ sha1sum -c SHA1SUMS Then as root, cd into that local directory and run # sh install-kolab.sh 2>&1 | tee /root/kolab-install.log to build and install packages in /kolab. The command output will be logged to install-kolab.log so that you have a reference in case an error occurs during installation. The install script needs to store some files and creates a subdirectory below /tmp (or $TMPDIR if set) for this purpose. The web client might create much load on your server if there are many concurrent users, so you can choose to not install it by adding the option "-x kolab-webclient" to the call to install-kolab.sh. Installing the web client on a separate host is possible, but not discussed here. If you do not want to install the free/busy view tool, add the option "-x kolab-fbview". The binary packages distributed via kolab.org are compiled with the web client and the free/busy view tool. Currently you need to compile from the source packages to install without these features, see kolab/issue2440 for details. By default, the Kolab server will now be started at boottime, so you have to bootstrap the server configuration now to prevent unconfigured components from being started, see kolab/issue1745 for details. Please run: # /kolab/sbin/kolab_bootstrap -b and follow the instructions. Check http://www.openpkg.org/documentation/ for additional documentation about the OpenPKG packaging system. General update instructions --------------------------- Generally an update of the Kolab server works as described in this section, but often you will need to deviate from these instructions as described in the sections below. Please read the release specific update instructions for all releases newer than the one you already have before you start the update, e.g. for upgrading from 2.2.0 to 2.2.1-rc1 you have to follow the instructions for upgrading from 2.2.0 to 2.2.1-beta1, too. In any case you should completely read *all* relevant update instructions *before* starting the upgrade procedure. Always make sure you have a recent backup of your /kolab directory before you attempt the upgrade. The installation of the new packages works just as for the initial installation. Download the files as described above and run # sh install-kolab.sh 2>&1 | tee /root/kolab-update.log If you installed without kolab-webclient or kolab-fbview you need to add the corresponding -x options again. install-kolab.sh will usually automatically determine which packages need to be built. If you have made changes to configuration files or an updated package includes configuration files which are usually regenerated from files in /kolab/etc/kolab/templates/ the old configuration file will be saved with the extension .rpmsave. For files generated from templates you just have to remove the rpmsave file, because services will refuse to start if there still is an rpmsave file, e.g.: # rm /kolab/etc/clamav/*.conf.rpmsave For other changed files (e.g. the template files themselves) you may want to transfer your changes from the .rpmsave backup to the new files. Then regenerate the configuration and restart all Kolab services with: # /kolab/sbin/kolabconf -n # /kolab/bin/openpkg rc all restart Or alternatively if the Kolab server was stopped before the upgrade: # /kolab/bin/openpkg rc openldap start # /kolab/sbin/kolabconf -n # /kolab/bin/openpkg rc all start Upgrade from 2.2.1-beta1 to 2.2.1-rc1 ------------------------------------- Nothing special has to be done for this upgrade. Upgrade from 2.2.0 to 2.2.1-beta1 --------------------------------- 0. Make a backup of your installation and data stored inside /kolab 1. The Kolab server must be stopped: # /kolab/bin/openpkg rc all stop 2. Save the current LDAP data: Copy the contents of the openldap database, use a different output filename if you want. You should make sure that no other users can read the sensitive data contained in the ldif file, e.g. with umask (limited to the slapcat call by using parentheses): # (umask 077 && # /kolab/sbin/slapcat > ~/kolab-2.2.0.ldif) 3. Start the standard upgrade: (as described in the General update instructions) # sh install-kolab.sh 2>&1 | tee /root/kolab-update.log 4. /kolab/etc/kolab/kolab.conf will be saved as kolab.conf.rpmsave, please move it back to the original name: # cd /kolab/etc/kolab && mv kolab.conf.rpmsave kolab.conf 5. Look at *.conf.rpmsave files in the subdirectories of /kolab/etc/, transfer your changes and remove these files. (as described in the General update instructions) 6. Before starting the LDAP server the database must be restored from the ldif (with Horde preferences filtered out, since these are now stored in files): # rm /kolab/var/openldap/openldap-data/* # /kolab/bin/awk '!/^ / {ok=1;} /^objectClass: horde(Person|Group)$/ {ok=0;} /^([a-z]*Prefs|turba(Contact|Members|PGPPublicKey|Type)):/ {ok=0;} {if(ok) print;}' ~/kolab-2.2.0.ldif | /kolab/sbin/slapadd 7. Start the OpenLDAP, generate the configuration files and start the Kolab server: # /kolab/bin/openpkg rc openldap start # /kolab/sbin/kolabconf -n # /kolab/bin/openpkg rc all start Upgrade from 2.2-rc3 to 2.2.0 ----------------------------- Nothing special has to be done for this upgrade. Upgrade from 2.2-rc2 to 2.2-rc3 ------------------------------- You should regenerated the free/busy cache again, as described in the upgrading instructions from 2.2-rc1 to 2.2-rc2. The IMAP annotation /vendor/kolab/xfb-readable (introduced in 2.2-beta3) was renamed to /vendor/kolab/pxfb-readable-for to reflect the actual meaning. After the upgrade the old annotations are still readable, but unused by the server. If you still need to write this annotation for some reason, you have to add it to imapd.annotation_definitions.template and run kolabconf. Upgrade from 2.2-rc1 to 2.2-rc2 ------------------------------- You have to regenerated the free/busy cache, which now can be done automatically. First (optional, but recommended) step is to remove the current cache below /kolab/var/kolab-freebusy/cache: # su - kolab-n $ rm -r /kolab/var/kolab-freebusy/cache/* Now you can use the following command (still as user kolab-n): $ PHP_AUTH_USER=manager PHP_AUTH_PW='managerpassword' /kolab/bin/php \ -c /kolab/etc/apache/php.ini /kolab/var/kolab/www/freebusy/regenerate.php As this will show the manager's password on the command line, you can alternatively open https://yourserver.example.com/freebusy/regenerate.php in a web browser and login as "manager". This needs "Allow unauthenticated downloading of Free/Busy information" to be disabled, which is the default. Upgrade from 2.2-beta3 to 2.2-rc1 --------------------------------- Updating the free/busy cache has to be triggered for all calendar folders of all accounts: - Users need to create or update an appointment in their folders. - Resources can be invited to a new appointment or send them an update to an existing appointment. Upgrade from 2.2-beta2 to 2.2-beta3 ----------------------------------- After upgrading, you should remove the package "kolab-horde-framework", which is no longer needed: # /kolab/bin/openpkg rpm -e kolab-horde-framework Upgrade from 2.2-beta1 to 2.2-beta2 ----------------------------------- Before running install-kolab.sh, you should stop the running Kolab server and remove some packages which got renamed or will no longer be needed by running this command: # /kolab/bin/openpkg rc all stop # /kolab/bin/openpkg rpm -e --nodeps apache2 apache2-php getopt proftpd \ pth sharutils kolab-horde-fbview kolab-resource-handlers Ignore errors about pth or sharutils not being installed, these were included in the beta1 release but not installed by default. Upgrade from Kolab server 2.1 or before --------------------------------------- Instructions for upgrading from Kolab server 2.0 will be added in a future version of this document. These instructions are for upgrading from Kolab server 2.1.0 to 2.2.1: 0. Make a backup of your installation and data stored inside /kolab 1. Before upgrading the Kolab server must be stopped: # /kolab/bin/openpkg rc all stop 2. Save the current LDAP data: Copy the contents of the openldap database, use a different output filename if you want. You should make sure that no other users can read the sensitive data contained in the ldif file, e.g. with umask (limited to the slapcat call by using parentheses): # (umask 077 && /kolab/sbin/slapcat > ~/kolab-2.1.ldif) 3. Some of the old Kolab packages must be removed to avoid conflicts during the upgrade process: # /kolab/bin/openpkg rpm -e --nodeps \ kolabd kolab-webadmin kolab-horde-fbview kolab-horde-framework \ kolab-resource-handlers getopt patch proftpd sharutils 4. New versions of openpkg and openpkg-tools are needed for the upgrade, so you have to install them manually beforehand. As root, cd into the directory of kolab server 2.2 binary packages and run: # /kolab/bin/openpkg rpm -Uvh \ ./openpkg-20071227-20071227.--kolab.rpm # /kolab/bin/openpkg rpm -Uvh \ ./openpkg-tools-1.4.6-20071231.--kolab.rpm If you do not have binary packages for you platform, you have to build them from source first. As root, cd into the Kolab server 2.2 source directory and run: # /kolab/bin/openpkg rpm --rebuild ./openpkg-20071227-20071227.src.rpm # /kolab/bin/openpkg rpm -Uvh \ /kolab/RPM/PKG/openpkg-20071227-20071227.--kolab.rpm # /kolab/bin/openpkg rpm --rebuild ./openpkg-tools-1.4.6-20071231.src.rpm # /kolab/bin/openpkg rpm -Uvh \ /kolab/RPM/PKG/openpkg-tools-1.4.6-20071231.--kolab.rpm ( and must be replaced by the correct values for your system). 5. Start the standard upgrade (as described above): # sh install-kolab.sh 2>&1 | tee /root/kolab-update.log 6. Before starting the LDAP server the database must be restored from the ldif: # rm /kolab/var/openldap/openldap-data/* # /kolab/sbin/slapadd -l ~/kolab-2.1.ldif 7. The format of the TLS session cache changed, therefore you have to truncate it to zero length: # > /kolab/var/imapd/tls_sessions.db 8. /kolab/etc/kolab/kolab.conf will be saved as kolab.conf.rpmsave, please move it back to the original name. # cd /kolab/etc/kolab && mv kolab.conf.rpmsave kolab.conf 9. Remove all *.conf.rpmsave files in the subdirectories of /kolab/etc/ as described above. 10. Start the OpenLDAP, generate the configuration files and start the Kolab server: # /kolab/bin/openpkg rc openldap start # /kolab/sbin/kolabconf -n # /kolab/bin/openpkg rc all start 11. After the successful upgrade some cleanup can be done, by removing obsolete files/directories: # rm -r /kolab/etc/resmgr # rm -r /kolab/etc/proftpd # rm -r /kolab/var/kolab/www/freebusy/cache/* 12. The free/busy cache has to be regenerated for all calendar folders of all accounts, see "Upgrade from 2.2-rc1 to 2.2-rc2" in this file. Additional hints may be available in the Kolab wiki: http://wiki.kolab.org/index.php/Kolab2_Upgrading Direct upgrade from Kolab1 is not supported. We suggest that you back up your IMAP store, install Kolab2 and manually recreate user accounts and then restore the IMAP data from the backup. Known regressions compared to Kolab Server 2.2.0 ------------------------------------------------ The following issues affect the current prerelease, but are expected to be fixed for the final release: kolab/issue3438 (kolabFreeBusyPast is not used) Generating your own 00INDEX.rdf for installations or upgrades ------------------------------------------------------------- The source and binary downloads contain the 00INDEX.rdf file needed by the "openpkg build" command used by install-kolab.sh to install or upgrade a Kolab server. If you already have your own set of binary packages from a previous build, you can use these to create a full binary installer (e.g. to install the packages on a second machine) or or a partial binary installer (for upgrades where you only want to compile the new .src.rpm files instead of everything). To generate this file, you always need all .src.rpm files, so link or copy them in a new directory (needs to be writable by the kolab user of your installation). After this you can link/copy the install-kolab.sh file and your binary rpm files (e.g. from /kolab/RPM/PKG/) into this directory and run the following command as user kolab or root to create the new 00INDEX.rdf file: $ sh install-kolab.sh -X If you want a pure binary installer, you can remove the .src.rpm files now. To be able to use this directory for fresh installations (i.e. not only for upgrades), you need to put the OpenPKG bootstrap file (openpkg-*.src.sh or openpkg---kolab.rpm) into this directory, too. Index generation tries to cache information about source RPMs in the file /kolab/RPM/DB/00INDEX-cache.db, you might want to remove it to save some disk space or restore it after new installations to save some time. Known problems and workarounds ------------------------------ - Compiling openpkg-20071227-20071227 does not work with gcc 4.3, e.g. on Debian/lenny. As a workaround you can install the gcc-4.2 package, but you have to make sure that OpenPKG calls this version by passing the --use_cc option to it via the -O flag of install-kolab.sh, e.g.: # sh install-kolab.sh -O --use_cc=gcc-4.2 ... See kolab/issue2871 (openpkg-20071227-20071227 does not compile with gcc 4.3) for details. - Your system (C library) has to support all languages you want to have available in the web admin interface, the web client and fbview. For most languages you have to use the non-UTF-8 and non-euro locales, i.e. de_DE, fr_FR, it_IT, nl_NL instead of e.g. de_DE at euro. For fbview some languages need a UTF-8 locale, e.g. ja_JP.UTF-8 for Japanese. The web client needs UTF-8 locale in addition to the non-UTF-8 ones in some situations. So it's best to install all variants for every language which shall be supported. See kolab/issue2732 (Horde and Web Admin Interface Language Selection depends on OS locale support) for details. - If login on https://yourserver.example.com/fbview and triggering free/busy regeneration does not work, try as user kolab: /kolab/bin/php -r 'imap_open("{localhost:143/notls}", "" ,"");' If it yields "Segmentation fault (core dumped)", then there probably is a conflict between a dynamically loaded libdb3 from your system and a statically linked libdb4 from the OpenpPKG php package. If it yields a "PHP Warning: ...", this part of the system works correctly. One reason for such a conflict could be the mere presence of /lib/libnss_db.so.*, which is installed on some distributions by default. On Debian systems it is contained in the package "libnss-db". If you really need this library, you could work around the loading of libdb3 by placing a symbolic link with the correct name in /kolab/lib, e.g.: ldd /lib/libnss_db.so.2 libnss_files.so.2 => /lib/tls/libnss_files.so.2 (0xb7f16000) ---> libdb3.so.3 => /usr/lib/libdb3.so.3 (0xb7e6b000) libc.so.6 => /lib/tls/libc.so.6 (0xb7d36000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x80000000) ln -s /dev/null /kolab/lib/libdb3.so.3 See kolab/issue1607 (need to replace gdbm for pfbcache, because of license clash gdbm vs php) for details. - /kolab/sbin/kolab_bootstrap -b fails to start the temporary slapd on Linux 2.4 kernels if binaries compiled on Linux 2.6 (as provided on kolab.org) are used. See kolab/issue1795 for details. - Under some circumstance the Kolab server may not create or delete users or update the configuration after changes have been made in the web interface. This happens most often immediately after the bootstrap. In that case restart the kolabd: /kolab/bin/openpkg rc kolabd restart If user accounts are still not created or deleted, you can try removing the file /kolab/var/kolab/mailbox-uidcache.db and restarting kolabd. See kolab/issue1068 (Mailboxes are not created until kolabd restart) and kolab/issue1098 (Changes in the service tab are not accepted after bootstrap) for details. - If modifying or deleting of address book entries doesn't work, restarting openldap can help, see kolab/issue854 for details. - There is a report that the manager can only see users in the primary domain, see kolab/issue1485. We can't reproduce this problem, please tell us if you can. - Calendar folders for group/resource accounts can't be created for domains which were added after bootstrap, i.e. via the web admin interface. See kolab/issue1313 for details. - When deleting domains via the web admin interface, the corresponding LDAP data and IMAP spool stay on the server and have to be deleted manually. See kolab/issue1571 and kolab/issue1576 for details. - A domain maintainer can not always edit the email aliases for a user, even if the user and the alias is in domains the domain maintainer has access to. See kolab/issue2825 for details. $Id: README.1st,v 1.109 2009/03/05 14:46:04 thomas Exp $ -------------- next part -------------- Kolab Server 2.2 Release Notes ============================== (Version 20090305, Kolab Server 2.2.1-rc1 For upgrading and installation instructions, please refer to the 1st.README file in the package directory. Differences between Kolab 2.1 and 2.2: - Upgrade of central Kolab server components The Apache server shipped with the Kolab server has been upgraded to Apache-2.2.*. At the same time the system was switched to PHP5. Postfix got upgraded to 2.4.* which removes the need for special Kolab patches which were integrated upstream. The Cyrus IMAP server was updated to 2.3.* also removing the need for some, though not all, Kolab specific patches. - Inclusion of the web based Horde Groupware client The Kolab server now provides a web client that supports all the groupware features known from Outlook and Kontact. Thus users are less dependent on their local client and can access their groupware data from anywhere in the world provided they have a standard browser available. - Structural improvements Several components of the Kolab server got restructured so that porting the Kolab server to distributions other than OpenPKG got easier. This also improves the development model in general. - Improvements, bugfixes and upgraded software components The 2.2 release received many improvements and bugfixes for issues found in earlier versions. Additionally all software components have been upgraded to new upstream versions. The specifics are described below. Changes between 2.2.1-beta-1 and 2.2.1-rc-1 - apache-php-5.2.8-20081209_kolab2 Updated Kolab server patches. - imapd-2.3.13-20081020_kolab1 kolab/issue3175 (Cyrus IMAPd 2.3.13 Released) - install-kolab.sh Fixed two problems reported by martin.schulte at guug.de: Repair option -E to not require an argument. Abort cleanly on -c or -X if no OpenPKG environment is found. Cache source RPM information in $PREFIX/RPM/DB/00INDEX-cache.db when generating 00INDEX.rdf - Horde_Notification-0.0.2-20090223 New package needed for running unit tests of Kolab PHP packages. - Horde_Prefs-0.0.3-20090223 New package needed for running unit tests of Kolab PHP packages. - Kolab_Filter-0.1.4-20090303 kolab/issue3192 (Forwarding an invitation with Outlook failed) kolab/issue3299 (Kolab_Filter: big.eml is too big) kolab/issue3364 (manpages for kolabfilter and kolabmailboxfilter) kolab/issue3426 (php error when sending mail with enabled mail filter checking) kolab/issue3441 (Resources with policy "always accept" do not work if domain != kolabhost) kolab/issue3435 (Delivery of invitations fails with no "kolabInvitationPolicy" in ldap) - Kolab_FreeBusy-0.1.2-20090226 kolab/issue3313 (free/busy regeneration as manager broken in 2.2.1-beta1) - Kolab_Server-0.4.0-20090224 New upstream release. Fixed objectClass evaluation to respect case-insensitivity (Horde bug: #7694) Fixed initialization of parameters retrieved from LDAP. Fixed addrsForIdOrMail to return only lowercased mail addresses (as mentioned in kolab/issue3426) Fixed notices when retrieving LDAP attributes. kolab/issue2207 (Make it possible to enable and disable users to be able to use the webclient) kolab/issue2546 (Horde should use name and email from ldap as defaults) - Kolab_Storage-0.4.0-20090224 New upstream release. Fixed list driver to prevent overwriting folder data when authenticating twice (relevant for testing). Allow to supress triggering (relevant for testing). - kolabd-2.2.1-20090304 Add a redirection for the newer horde install location. Add LDAP attribute postfix-message-size-limit and adjust main.cf.template to allow central configuration of the postfix parameter "message_size_limit". Add user attribute kolabHomeServerOnly to create user mailbox on the kolabHomeServer only. Add ldapserver_statedir to kolab.globals to fix kolab_bootstrap on slave servers. Add kolab_cafile to kolab.globals to specify filename for kolab_bootstrap to copy the generated CA certificate. Allow to configure resmgr and freebusy logging via dist_conf Updated doc/README.outlook for Kolab Server 2.2.1. kolab/issue1001 (/kolab/etc/kolab/workaround.sh expects manager password on command line) kolab/issue3331 (kolabfilter uses incorrect delivery backend) kolab/issue3322 (freebusy.conf.template: ldap server can be on another machine) kolab/issue3387 (dist_conf configuration in kolab webclient templates) kolab/issue3408 (Template for inclusion in shell scripts) kolab/issue3447 (Heavy information leak from webclient directories) - kolab-fbview-1.2.0-20081227 kolab/issue3318 (kolab-fbview-1.2.0-20081212 fails to compile on solaris 10) - kolab-webadmin-2.2.1-20090304 Improved Dutch translation. kolab/issue3404 (Present the options in "Action to take for messages that fail the check" nicer) - kolab-webclient-1.2.0-20090226 Fixed a potential IE XSS issue. Fixed handling of folder "owner" for shared user folders with Dovecot. Correct iTip option handling for dimp. kolab/issue2207 (Make it possible to enable and disable users to be able to use the webclient) kolab/issue2546 (Horde should use name and email from ldap as defaults) kolab/issue2738 (horde should allow a setting to suppress groupware folders) kolab/issue3309 (Can not login directly in to dimp) kolab/issue3318 (kolab-fbview-1.2.0-20081212 fails to compile on solaris 10) kolab/issue3328 ([Webclient] DIMP groupware folder names display bug) kolab/issue3329 ([WebClient] Can not accept/deny invitations in Dimp) kolab/issue3387 (dist_conf configuration in kolab webclient templates) kolab/issue3439 (FreeBusy display in web client and fbview depends on kolabHomeServer in LDAP) - PEAR-Horde-Channel-1.0-20090119 kolab/issue2441 (/kolab/RPM/TMP/pear/temp created owned by root) kolab/issue3315 (PEAR-Horde-Channel-1.0 fails to compile on solaris 10) - PEAR-PHPUnit-Channel-1.0-20090119 kolab/issue2441 (/kolab/RPM/TMP/pear/temp created owned by root) kolab/issue3315 (PEAR-Horde-Channel-1.0 fails to compile on solaris 10) - perl-kolab-2.2.1-20090304 Create user mailbox on the kolabHomeServer only, if attribute kolabHomeServerOnly is true. Continue sync if connecting the IMAP server fails, just skip actions that would need it. Improved the ssh handling for slave setups in kolab_bootstrap. Add retry (every minute for 10 times, then every five minutes until successful) to syncrepl configuration. kolab/issue3225 (Remove unused kolab_upgrade script) kolab/issue3321 (slapd.replicas.template and slapd.access.template can be absent) kolab/issue3355 (POD manpages for perl-kolab) kolab/issue3407 (kolab_bootstrap: improve message about importing the CA certificate) - perl-ldap-5.10.0-20081028_kolab1 New upstream version (perl-ldap 0.39) and two patches for syncrepl support, see kolab/issue1755 (syncrepl support (for OpenLDAP >=2.4.6)) - php-5.2.8-20081209_kolab2 Updated Kolab server patches. Packages in the OpenPKG based Kolab server release: - Kolab packages: Added: Horde_Notification-0.0.2-20090223 Horde_Prefs-0.0.3-20090223 Updated: Kolab_Filter-0.1.4-20090303 Kolab_FreeBusy-0.1.2-20090226 Kolab_Server-0.4.0-20090224 Kolab_Storage-0.4.0-20090224 PEAR-Horde-Channel-1.0-20090119 PEAR-PHPUnit-Channel-1.0-20090119 kolab-fbview-1.2.0-20081227 kolab-webadmin-2.2.1-20090304 kolab-webclient-1.2.0-20090226 kolabd-2.2.1-20090304 perl-kolab-2.2.1-20090304 perl-ldap-5.10.0-20081028_kolab1 Unchanged: Horde_Argv-0.1.0-20081209 Horde_Auth-0.1.1-20081209 Horde_Browser-0.0.2-20081209 Horde_CLI-0.0.2-20081209 Horde_Cache-0.0.2-20081209 Horde_Cipher-0.0.2-20081209 Horde_DOM-0.1.0-20081209 Horde_DataTree-0.0.3-20081209 Horde_Date-0.1.0-20081209 Horde_Framework-0.0.2-20081209 Horde_Group-0.1.0-20081209 Horde_History-0.0.2-20081209 Horde_LDAP-0.0.2-20081209 Horde_MIME-0.0.2-20081209 Horde_NLS-0.0.2-20081209 Horde_Perms-0.1.0-20081209 Horde_Secret-0.0.2-20081209 Horde_Serialize-0.0.2-20081209 Horde_SessionObjects-0.0.2-20081209 Horde_Util-0.1.0-20081209 Horde_iCalendar-0.1.0-20081209 Kolab_Format-1.0.0-20081212 PEAR-Auth_SASL-1.0.2-1 PEAR-Date-1.4.7-1 PEAR-HTTP_Request-1.4.3-1 PEAR-Log-1.11.2-1 PEAR-Mail-1.1.14-1 PEAR-Mail_mimeDecode-1.5.0-20081209 PEAR-Net_LMTP-1.0.1-1 PEAR-Net_SMTP-1.3.1-1 PEAR-Net_Socket-1.0.9-1 PEAR-Net_URL-1.0.15-1 PHPUnit-3.3.3-1 clamav-0.94.2-20081212 openldap-2.3.43-20081212 php-smarty-2.6.20-20081212 sqlite-3.6.4-20081212 - OpenPKG packages: Updated: apache-php-5.2.8-20081209_kolab2 imapd-2.3.13-20081020_kolab1 php-5.2.8-20081209_kolab2 Unchanged: amavisd-2.5.3-20080101 apache-2.2.10-20081111 apr-1.2.12-20080101 autoconf-2.61-20080101 automake-1.10-20080101 bc-1.06-20080101 binutils-2.18-20080101 bison-2.3-20080101 bzip2-1.0.5-20080318 config-20060923-20080101 curl-7.17.1-20080101 db-4.5.20.2-20070628 diffutils-2.8.7-20080101 expat-2.0.1-20080101 file-4.23-20080101 flex-2.5.34-20080101 freetype-2.3.5-20080101 fsl-1.7.0-20080101 gawk-3.1.6-20080101 gcc-4.2.2-20080101 gd-2.0.35-20080101 gettext-0.17-20080101 gmp-4.2.2-20080101_kolab grep-2.5.3-20080101 groff-1.19.2-20080101 gzip-1.3.12-20080101 imap-2006k-20080101 jpeg-6b-20080101 libiconv-1.12-20080101 libmcrypt-2.5.8-20080101 libxml-2.6.31-20080111 libxslt-1.1.22-20080101 lzo-2.02-20080101 m4-1.4.9-20080101 make-3.81-20080101 mhash-0.9.9-20080101 mm-1.4.2-20080101 ncurses-5.6.20080112-20080113 openpkg-20071227-20071227 openpkg-tools-1.4.6-20071231 openssl-0.9.8g-20080101 pcre-7.5-20080110 perl-5.10.0-20080103 perl-comp-5.10.0-20080110 perl-conv-5.10.0-20080101 perl-crypto-5.10.0-20080101 perl-db-5.10.0-20080118 perl-dns-5.10.0-20080101 perl-ds-5.10.0-20080104 perl-locale-5.10.0-20080112 perl-mail-5.10.0-20080117 perl-module-5.10.0-20080101 perl-net-5.10.0-20080101 perl-openpkg-5.10.0-20080109 perl-parse-5.10.0-20080117 perl-ssl-5.10.0-20080101 perl-stats-5.10.0-20080101 perl-sys-5.10.0-20080101 perl-term-5.10.0-20080116 perl-text-5.10.0-20080101 perl-time-5.10.0-20080101 perl-util-5.10.0-20080116 perl-www-5.10.0-20080103 perl-xml-5.10.0-20080101 pkgconfig-0.23-20080117 png-1.2.24-20080101 postfix-2.4.6-20080101_kolab procmail-3.22-20080101 readline-5.2.12-20080101 sasl-2.1.22-20080101 sed-4.1.5-20080101 spamassassin-3.2.4-20080107 texinfo-4.11-20080101 zlib-1.2.3-20080101 Changes between 2.2.0 and 2.2.1-beta-1 - apache-2.2.10-20081111 New upstream version, fixes various security issues. - apache-php-5.2.8-20081209_kolab New upstream version, fixes various security issues. Added sqlite2 support for SyncML support in kolab-webclient. - bzip2-1.0.5-20080318 New upstream version, fixes CVE-2008-1372 (denial of service) - clamav-0.94.2-20081212 New upstream version, fixes various security issues. kolab/issue765 (openpkg "junk" warnings) - gawk-3.1.6-20080101 New package, build (not runtime) dependency of sqlite. - gmp-4.2.2-20080101_kolab kolab/issue2928 (gmp-4.2.2-20080101 does not compile on Debian lenny/amd64) - Horde_iCalendar-0.1.0-20081209 kolab/issue3284 (Webclient or resmgr might send invitations that Outlook 2003 does not understand (unquoted CN with Umlauts)) - Kolab_Filter-0.1.3-20081212 A new package replacing kolab-filter (from http://pear.horde.org/index.php?package=Kolab_Filter) Added LDA (dovecot) backend. kolab/issue839 (problem when kolabHomeServer is missing) kolab/issue3074 (Freebusy trigger fails for other users's calenders.) kolab/issue3208 (Free/Busy list is always empty) kolab/issue3256 (resmgr responses should reflect server revision in PRODID) kolab/issue3260 (kolabfilter does not allow empty sender (and therefore MAILER-DAEMON)) kolab/issue3289 (resmgr dies when it should accept, but has not Calender folder access) - only partial fix - Kolab_Format-1.0.0-20081212 New package (from http://pear.horde.org/index.php?package=Kolab_Format) - Kolab_FreeBusy-0.1.2-20081212 A new package replacing kolab-freebusy (from http://pear.horde.org/index.php?package=Kolab_FreeBusy) Fixed handling of extended free/busy information. Fixed identification of the corresponding free/busy server. kolab/issue3208 (Free/Busy list is always empty) kolab/issue3256 (resmgr responses should reflect server revision in PRODID) - Kolab_Server-0.2.0.20081114-20081114 New package (from http://pear.horde.org/index.php?package=Kolab_Server) - Kolab_Storage-0.3.0-20081205 New package (from http://pear.horde.org/index.php?package=Kolab_Storage) - kolabd-2.2.1-20081212 Added configuration option in resmgr.conf for local delivery backend. (Makes it possible to activate the new LDA backend) Activated sqlite support in PHP. Updated the configuration for the newer Kolab_Filter package. kolab/issue765 (openpkg "junk" warnings) kolab/issue936 (kolabquotawarn: system cron used, and firing when server stopped) kolab/issue1310 (kolabquotawarn runs via cron before server was bootstrapped) kolab/issue1755 (syncrepl support (for OpenLDAP >=2.4.6)) kolab/issue2351 (horde doesn't present attachment stuff while compose a message) kolab/issue2440 (Installing binary packages of 2.2 fails without Horde) kolab/issue2446 (Make the used syslog facility configureable (kolabd, kolabconf)) kolab/issue2550 (kolabconf should make some others postfix maps) kolab/issue2910 (obsolete definition of schemacheck in slapd.conf) kolab/issue2911 (Change comments around the idletimeout definiton in the file templates/slapd.conf.template.in) kolab/issue2961 (added smtpd_sasl_authenticated_header = yes for simpler authorization) kolab/issue2994 (Duplicated kolab.conf files in cvs, one should be removed) kolab/issue3005 (Remove specific TLSCertificate code by using new bootstrap_config conditional in slapd.conf.template) kolab/issue3006 (Surround the horde schema include in slapd.conf.template with @@@ conditionals) Remark: this actually added only the code that allows to use @@@if exists(=2.4.6)) kolab/issue2981 (kolab_bootstrap: re-use kolabconf code to read the config file) kolab/issue3006 (Surround the horde schema include in slapd.conf.template with @@@ conditionals) Remark: this actually added only the code that allows to use @@@if exists( for forms in webadmin) kolab/issue1615 (Use also for login page) kolab/issue1618 (Add missing headings) kolab/issue1619 (Add CSS file for printing) kolab/issue1620 (fix invalid XHTML in form.class.php) kolab/issue1742 (Do not modify the objectclasses of an existing object) kolab/issue1744 (No "User Deleted, awaiting cleanup" for admins and domain maintainers) ------------------------------------------------------------------------------- Differences between Kolab 2.0 and 2.1: - Simple multi-domain support The Kolab server can now accept mail for multiple email domains. There is also a new class of maintainers which are only allowed to manage settings for a subset of the mail domains of the kolab server. - Hashed IMAP spool The default imapd configuration has been changed to enable the hashimapspool option, which allows the Cyrus IMAP server to run more efficiently especially when you have many mailboxes. - Improvements, bugfixes and upgraded software components The 2.1 release received many improvements and bugfixes for issues found in the 2.0 versions and during the long beta and rc phase. Additionally many software components have been upgraded to new upstream versions. Changes between 2.1-rc-2 and 2.1.0: - Documentation Documented workaround for libdb3 conflict in README.1st Added instructions for automatically upgrading the free/busy cache. - amavisd-2.3.3-2.5.0_kolab kolab/issue1447 (Virus Scanning: Inserted note when partially scanned ugly) - kolabd-2.1.0-20070510 kolab/issue974 (Localize the text for rewritten From: headers) kolab/issue1560 (postfix modifies message/rfc822 MIME parts) kolab/issue1608 (A patch for kolabd to include the horde LDAP schema) - kolab-resource-handlers-2.1.0-20070510 Generate a single To: header listing all recipients when forwarding encapsulated iCal messages. kolab/issue974 (Localize the text for rewritten From: headers) kolab/issue1422 (Dummy freebusy info) - kolab-webadmin-2.1.0-20070510 kolab/issue1616 (Use different cursor for tags) kolab/issue1617 (fix small inconsistency in german translation) Changes between 2.1-rc-1 and 2.1-rc-2: - apache-1.3.33-2.5.6_kolab2 kolab/issue1607 (need to replace gdbm for pfbcache, because of license clash gdbm vs php) - clamav-0.90.2-20070413_kolab New upstream version, fixes various security issues. - file-4.15-2.5.0_kolab2 Fix for security issue described in CVE-2007-1536: buffer overflow, remotely exploitable due to the usage of file in amavisd-new - fsl-1.7.0-20070303 New upstream version. kolab/issue1172 (Cyrus Imapd dies when logfile exceeds 2 GiB) - php-4.4.0-2.5.2_kolab2 kolab/issue1607 (need to replace gdbm for pfbcache, because of license clash gdbm vs php) - spamassassin-3.1.0-2.5.1_kolab Fix for security issue described in CVE-2007-0451: possible DoS due to incredibly long URIs found in the message content Disabled external DNS and URI blacklists, because some of these services require payment if used for many mailboxes. Ignore headers inserted on the receiving side for bayes filtering. - perl-kolab-5.8.7-20070420 Added debug option for verbose logging to stderr. - kolabd-2.1.0-20070420 Fix the path to the freebusy directory for non-OpenPKG installations. Fix usage of tar and modification of rc.conf during slave setup for non-OpenPKG installations. Don't pass notifications and quarantined mails through amavisd-new. Updated configuration templates for ClamAV 0.90 Updated openldap monitor configuration. Updated cyrus imapd configuration to use cyr_expire. kolab/issue954 (kolab server rejects mails that should be marked untrusted) kolab/issue1538 (outlook invitation forwarding broken in Kolab server 2.1) kolab/issue1607 (need to replace gdbm for pfbcache, because of license clash gdbm vs php) kolab/issue1609 ("kolab --help" tries to execute *all* commands) kolab/issue1638 (kolabconf generates broken resmgr.conf) kolab/issue1680 (/kolab/bin/kolab fix) - kolab-horde-fbview-2.1.0-20070420 Updated version number, no other changes since 2.1rc1 - kolab-resource-handlers-2.1.0-20070420 Improved logging for opening pfbcache.db kolab/issue954 (kolab server rejects mails that should be marked untrusted) kolab/issue1538 (outlook invitation forwarding broken in Kolab server 2.1) kolab/issue1607 (need to replace gdbm for pfbcache, because of license clash gdbm vs php) kolab/issue1659 (Freebusy assumes that all day events last exactly one day) - kolab-webadmin-2.1.0-20070420 Updated Dutch and German translations. kolab/issue1457 (updated French translation) kolab/issue1612 (modify user ignores account type) kolab/issue1614 (ldap_add() - Constraint violation on change user account type) kolab/issue1630 (Domain maintainer can see distribution lists from other domains) kolab/issue1652 (Import users from ldif and LDAP Constraint violation) kolab/issue1654 (New LDAP overlay prevents modification of distribution lists) kolab/issue1663 (It is possible to create domain maintainers without domains) kolab/issue1670 (Renaming a domain maintainer twice within the same form fails) Changes between 2.1-beta-4 and 2.1-rc-1: - kolabd-2.0.99-20070205 kolab/issue1335 (pfbcache.db locking problems) kolab/issue1507 (Public viewable phpinfo() and more in Server default installation) kolab/issue1550 (Masquerade problem, corrected template) kolab/issue1563 (freebusy.conf template doesn't match freebusy.conf from package) kolab/issue1575 (Openldap enhanced data integrity) - kolab-webadmin-2.0.99-20070205 Disabled Spanish language selection from web admin interface, because of missing translation. kolab/issue1479 ("Type" of shared folder can only be modified in 2nd try) kolab/issue1486 ("About Kolab" in Webinterface needs work over) kolab/issue1539 (extension to the opening text, when the manager logs in for the 1st time) kolab/issue1559 (Domain Maintainer cannot delete "his" users) kolab/issue1586 ("Required field" not translated to German in web admin) kolab/issue1592 (LANGUAGE variable overrides web admin language selection) Changes between 2.1-beta-3 and 2.1-beta-4: - clamav-0.88.7-20061211 bypass virus detection (CVE-2006-6406), denial of service, remotely exploitable (CVE-2006-6481) (http://kolab.org/security/kolab-vendor-notice-14.txt) - kolabd-2.0.99-20070117 Updated proftpd.conf template: LDAPHomedirOnDemand(Prefix) is now named LDAPGenerateHomedir(Prefix). Set imapidlepoll to 5 seconds in imapd.conf.template.in. kolab/issue1433 (Some files in /kolab/etc/postfix have wrong ownership) kolab/issue1484 (Warnings using openldap = 2.3.27-2.20061018_kolab) kolab/issue1487 (amavisd.conf mynetworks incomplete) kolab/issue1531 (amavisd.conf local_domains only contains primary domain) kolab/issue1532 (Set "duplicatesuppression: 0" in imapd.conf.template?) - kolab-horde-fbview-2.0.99-20070112 Improvements to the week view (part of kolab/issue666) Removed dangerous php scripts (part of kolab/issue1507) - kolab-resource-handlers-2.0.99-20070117 kolab/issue1490 (freebusy cache written to /kolab/kolab/...) kolab/issue1512 (No FB information for resource accounts) kolab/issue1558 (kolab-webadmin and php 5.2.0) - kolab-webadmin-2.0.99-20070117 kolab/issue1013 (user passwords sha1 encoded without salt) kolab/issue1262 (Setting quota to 4096+ MB breaks message delivery) kolab/issue1418 (fields visible even when attribute_access is "hidden" in session_vars.php) kolab/issue1540 (Typo on kolab/admin/service page) kolab/issue1555 (Login screen shows error msg for no good reason) - openldap-2.3.29-2.20061110_kolab New upstream version, fixes CVE-2006-5779 (Bugtraq ID 20939) - perl-kolab-5.8.7-20070117 Only print warning about missing configuration variable if relevant. kolab/issue1550 (Masquerade problem) Changes between 2.1-beta-2 and 2.1-beta-3: - openpkg-2.5.4-2.5.4 New upstream version. - apache-1.3.33-2.5.6 denial of service and possibly arbitrary code execution via crafted URLs that are not properly handled using certain rewrite rules. http://www.openpkg.org/security/advisories/OpenPKG-SA-2006.015-apache.html - gzip-1.3.5-2.5.1 denial of service, arbitrary code execution http://www.openpkg.org/security/advisories/OpenPKG-SA-2006.020-gzip.html - curl-7.15.0-2.5.2 buffer overflow http://www.openpkg.org/security/advisories/OpenPKG-SA-2006.012-curl.html - openssl-0.9.8a-2.5.4 denial of service, may allow execution of arbitrary code (http://kolab.org/security/kolab-vendor-notice-12.txt) - clamav-0.88.5-2.20061018 buffer overflow, remotely exploitable (CVE-2006-4018) (http://kolab.org/security/kolab-vendor-notice-10.txt) heap overflow, remotely exploitable (CVE-2006-4182), denial of service, remotely exploitable (CVE-2006-5295) (http://kolab.org/security/kolab-vendor-notice-13.txt) - file-4.15-2.5.0_kolab kolab/issue1458 (Password protected .sxw files can be banned by amavisd, as a result of the file command) - openldap-2.3.27-2.20061018_kolab New upstream version, fixes CVE-2006-4600 (Bugtraq ID 19832) and other problems. kolab/issue1229 (Master openldap's slurpd fails to start after adding slave) kolab/issue1431 (Slave cannot access master ldap server via SSL) - imapd-2.2.12-2.5.0_kolab2 Fix folder structure for foldernames with non-alphanumeric characters, when using skiplist as the database backend for mailboxes.db. - perl-kolab-5.8.7-20061110 kolab/issue1194 (serious performance problem on high number of users) - kolabd-2.0.99-20061110 Added missing relay service for postfix. Changed main.cf masquerading defaults so email to user at machine.example.org is actually delivered. Use mailbox_transport instead of local_transport for kolabmailboxfilter to work around issue825. Removed doubled attribute cyrus-autocreatequota. Added indexes for delegate and delete. Updated freebusy.conf template for freebusy IMAP caching. Changed imapd.conf template to use berkeley db instead of skiplist for annotations.db and mailboxes.db as a workaround for kolab/issue840 (Annotations needs to be more robust). kolab/issue824 (kolabmailboxfilter run once for each recipient) kolab/issue1264 (Add support for sieve based notifications) kolab/issue1273 (Sending as delegate broken in Kolab server 2.1) kolab/issue1428 (Fixed locking issue) kolab/issue1433 (Some files in /kolab/etc/postfix have wrong ownership) - kolab-webadmin-2.0.99-20061110 Fixes for setting folder type of shared folders. Guard against large number of users. kolab/issue1457 (updated French translation) - kolab-resource-handlers-2.0.99-20061110 Improvements and fixes for freebusy IMAP caching. kolab/issue815 (invitation replies vanish in resmgr) kolab/issue957 (All-day events from Outlook don't show up in freebusy) kolab/issue974 (Localize the text for rewritten From: headers) kolab/issue1042 (empty lines at the end of mails delivered via LMTP) kolab/issue1352 (resmgr can create wrong range dates) kolab/issue1387 (resmgr replies to replies creating mail loop) kolab/issue1422 (Dummy freebusy info) Changes between 2.1-beta-1 and 2.1-beta-2: OpenPKG updates: openpkg-2.5.2-2.5.2 openpkg-registry-0.2.7-20060223 libxslt-1.1.15-2.5.1 php-smarty-2.6.10-20051003 clamav-0.88.2-20060524 binutils-2.16.1-2.5.1 http://www.openpkg.org/security/advisories/OpenPKG-SA-2006.009-binutils.html openldap-2.3.11-2.5.1 http://www.openpkg.org/security/advisories/OpenPKG-SA-2006.008-openldap.html Kolab updates: More distconf changes by Richard Bos and Markus Huewe. - perl-kolab-5.8.7-20060619 kolab/issue1194 (kolabd quota performance) kolab/issue1220 (postfix permissions) kolab/issue1237 (Handling of @@@var@@@ in Conf.pm (Gunnar Wrobel)) - kolabd-2.0.99-20060619 * The default imapd configuration has been changed to enable the hashimapspool option. This affects the upgrade procedure. See 1st.README for upgrade instructions. * amavis now logs to /kolab/var/amavisd/amavisd.log. This is part of the fix for Issue1015 kolab/issue1015 (fixing logging and logrotate for amavisd) kolab/issue1089 (enable hashimapspool for imapd to cope with many users) kolab/issue1101 (allowapop: no; disable apop access to imapd by default) kolab/issue1105 (fix compilation of kolabd on FreeBSD) kolab/issue1257 (wrong attribute name for imap quota) - kolab-webadmin-2.0.99-20060619 * patch from Tobias Koenig in order to support setting of foldertype for public folders kolab/issue848 (Modifying address book entry may break distribution list) kolab/issue1106 (email validation in webgui) kolab/issue1214 (number of days for vacation messages on webinterface) kolab/issue1263 (Bug in the shared folders folder-type code) [Wrobel] - kolab-resource-handlers-2.0.99-20060619 * create empty pfbcache.db if missing kolab/issue973 (quoting and rewriting From header) kolab/issue966 (Wrong CN for resource accounts) kolab/issue1042 (server modifies email content) kolab/issue1195 (error message in bounce) kolab/issue1243 (rewriting fails when "From:" contains quoted printable) kolab/issue1245 (rewriting problems on folded Header "From:"-line) $Id: release-notes.txt,v 1.398 2009/03/05 15:48:56 thomas Exp $ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 206 bytes Desc: not available URL: From ml at radoeka.nl Thu Mar 5 21:15:48 2009 From: ml at radoeka.nl (Richard Bos) Date: Thu, 5 Mar 2009 21:15:48 +0100 Subject: Restore folder from backup (kolab 2.04) SOLVED In-Reply-To: <200903050939.30130.itsef-admin@brightsight.com> References: <49AE3FB0.1050604@intronics.nl> <49AF8930.6050409@intronics.nl> <200903050939.30130.itsef-admin@brightsight.com> Message-ID: <200903052115.48608.ml@radoeka.nl> Op donderdag 05 maart 2009 09:39:30 schreef ITSEF Admin: > > I have added the solution to the wiki: > > http://wiki.kolab.org/index.php/Backups_for_kolab2#IMAP_folder_recovery_fro >m_backup_.28cyrus.29 > > Thanks Jacques - and I've added my remark about the quotas to that as well Thank you! -- Richard From delonly at gmail.com Sat Mar 7 17:44:07 2009 From: delonly at gmail.com (Del) Date: Sat, 07 Mar 2009 17:44:07 +0100 Subject: Kolab Server 2.2.1 Release Candidate 1 In-Reply-To: <20090305162647.GA1490.thomas@intevation.de> References: <20090305162647.GA1490.thomas@intevation.de> Message-ID: <1236444247.13379.22.camel@black> Thank you! Just gave it a try on one of my machines to test, and have an issue that maybe somebody can give a quick answer too. It may simply be related to my test set-up being on an Ubuntu 8.04 x86-64 box. I used the packages for Etch i386 with OpenPKG. The issue is that mail is somehow not set-up. Logging into Horde, and using calendar works fine, but any attempt at clicking anything related to mail results in forced log-out. I am happy if anybody can confirm that this is not the case on a base Etch install. I do not mean to chase down issues related to other OS versions, setting up an Etch environment is quite OK if that will do the trick. Cheers, Del On Thu, 2009-03-05 at 17:26 +0100, Thomas Arendsen Hein wrote: > Hi! > > I just uploaded Kolab Server 2.2.1-rc1 which contains about 60 > enhancements and fixes compared to beta1. > > Please make sure to follow the upgrade instructions in 1st.README, > especially if upgrading from server 2.2.0 or older. > > Again many thanks to all the people who helped with this! > > Documentation and OpenPKG source packages will soon be available in > the directory server/beta/kolab-server-2.2.1-rc-1/ of the mirrors > listed on http://kolab.org/mirrors.html > for example: > http://ftp.gwdg.de/pub/linux/kolab/server/beta/kolab-server-2.2.1-rc-1/ > ftp://ftp.gwdg.de/pub/linux/kolab/server/beta/kolab-server-2.2.1-rc-1/ > > rsync://rsync.kolab.org/kolab/RSYNC.txt explains how to get (or > mirror) the files via rsync. > > All files updated since 2.2.1-beta1 are available in the directory > server/development-2.2/20090305-since-20081212/ > > You can check the integrity of the downloaded files with: > > $ gpg --keyserver hkp://subkeys.pgp.net --recv-key 5816791A > or import the key from https://www.intevation.de/~thomas/gpg_pub_key.asc > (the same key that I used to sign this email) > $ gpg --verify SHA1SUMS.sig > $ sha1sum -c SHA1SUMS > > Binary packages for Debian GNU/Linux (etch/stable) on x86 platforms > can be found in the ix86-debian4.0 directory next to the sources. > > Please look at 1st.README and release-notes.txt (attached for your > convenience) for install instructions and more information about > this release. > > Please report any problems you encounter in our issue tracker: > https://issues.kolab.org/ > > Regards, > Thomas Arendsen Hein > > _______________________________________________ > Kolab-users mailing list > Kolab-users at kolab.org > https://kolab.org/mailman/listinfo/kolab-users From wrobel at pardus.de Sat Mar 7 20:44:03 2009 From: wrobel at pardus.de (Gunnar Wrobel) Date: Sat, 07 Mar 2009 20:44:03 +0100 Subject: Kolab Server 2.2.1 Release Candidate 1 In-Reply-To: <1236444247.13379.22.camel@black> References: <20090305162647.GA1490.thomas@intevation.de> <1236444247.13379.22.camel@black> Message-ID: <20090307204403.18487cjwsth8v04c@webmail.pardus.de> Quoting Del : > Thank you! Just gave it a try on one of my machines to test, and have an > issue that maybe somebody can give a quick answer too. It may simply be > related to my test set-up being on an Ubuntu 8.04 x86-64 box. I used the > packages for Etch i386 with OpenPKG. > > The issue is that mail is somehow not set-up. Logging into Horde, and > using calendar works fine, but any attempt at clicking anything related > to mail results in forced log-out. I am happy if anybody can confirm > that this is not the case on a base Etch install. I do not mean to chase > down issues related to other OS versions, setting up an Etch environment > is quite OK if that will do the trick. I can only confirm that this works fine in a source based installation. I'd try Etch ;) Cheers, Gunnar > > Cheers, > Del > > On Thu, 2009-03-05 at 17:26 +0100, Thomas Arendsen Hein wrote: >> Hi! >> >> I just uploaded Kolab Server 2.2.1-rc1 which contains about 60 >> enhancements and fixes compared to beta1. >> >> Please make sure to follow the upgrade instructions in 1st.README, >> especially if upgrading from server 2.2.0 or older. >> >> Again many thanks to all the people who helped with this! >> >> Documentation and OpenPKG source packages will soon be available in >> the directory server/beta/kolab-server-2.2.1-rc-1/ of the mirrors >> listed on http://kolab.org/mirrors.html >> for example: >> http://ftp.gwdg.de/pub/linux/kolab/server/beta/kolab-server-2.2.1-rc-1/ >> ftp://ftp.gwdg.de/pub/linux/kolab/server/beta/kolab-server-2.2.1-rc-1/ >> >> rsync://rsync.kolab.org/kolab/RSYNC.txt explains how to get (or >> mirror) the files via rsync. >> >> All files updated since 2.2.1-beta1 are available in the directory >> server/development-2.2/20090305-since-20081212/ >> >> You can check the integrity of the downloaded files with: >> >> $ gpg --keyserver hkp://subkeys.pgp.net --recv-key 5816791A >> or import the key from https://www.intevation.de/~thomas/gpg_pub_key.asc >> (the same key that I used to sign this email) >> $ gpg --verify SHA1SUMS.sig >> $ sha1sum -c SHA1SUMS >> >> Binary packages for Debian GNU/Linux (etch/stable) on x86 platforms >> can be found in the ix86-debian4.0 directory next to the sources. >> >> Please look at 1st.README and release-notes.txt (attached for your >> convenience) for install instructions and more information about >> this release. >> >> Please report any problems you encounter in our issue tracker: >> https://issues.kolab.org/ >> >> Regards, >> Thomas Arendsen Hein >> >> _______________________________________________ >> Kolab-users mailing list >> Kolab-users at kolab.org >> https://kolab.org/mailman/listinfo/kolab-users > > _______________________________________________ > Kolab-users mailing list > Kolab-users at kolab.org > https://kolab.org/mailman/listinfo/kolab-users > -- ______ 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. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: Digitale PGP-Unterschrift URL: From delonly at gmail.com Sun Mar 8 13:26:42 2009 From: delonly at gmail.com (Del) Date: Sun, 08 Mar 2009 13:26:42 +0100 Subject: Kolab Server 2.2.1 Release Candidate 1 In-Reply-To: <20090307204403.18487cjwsth8v04c@webmail.pardus.de> References: <20090305162647.GA1490.thomas@intevation.de> <1236444247.13379.22.camel@black> <20090307204403.18487cjwsth8v04c@webmail.pardus.de> Message-ID: <1236515202.22384.15.camel@black> Indeed, thanks! A couple of comments on the installation: -The siging certificate dialougue (when bootstrapping) does not specify a default to [y/n], but defaults to "no" resulting in Apache not working. I think iot would make sense to warn the user of the consequences when just pressing enter, and of course to inform about the default choice. -DNS needs to be set up somehow for Apache to start, I think it makes sense to include information on the options here on the wiki, since a test-environment can be put up pretty easily. Unless there is some objections, I can put information on this on the wiki. For the Horde environment I have three comments. The first being important (at least in my mind): -The LDAP users are found in the "Global address book", which must be set explicitely in Horde to be used. Moreover it must me moved on top of "Contacts" to autocomplete in "Edit Attendees" view. I think this is not very intuitive for new admins, so at least we should have it documented and easily accessible on the wiki. -Norwegian letters messed up in Horde when scheduling meetings, but not for mail (but this I assume is a Horde issue). -Free/busy for users not available in Horde until after first log-in (I minor one, which I am not sure should be given any attention). Cheers, Del On Sat, 2009-03-07 at 20:44 +0100, Gunnar Wrobel wrote: > Quoting Del : > > > Thank you! Just gave it a try on one of my machines to test, and have an > > issue that maybe somebody can give a quick answer too. It may simply be > > related to my test set-up being on an Ubuntu 8.04 x86-64 box. I used the > > packages for Etch i386 with OpenPKG. > > > > The issue is that mail is somehow not set-up. Logging into Horde, and > > using calendar works fine, but any attempt at clicking anything related > > to mail results in forced log-out. I am happy if anybody can confirm > > that this is not the case on a base Etch install. I do not mean to chase > > down issues related to other OS versions, setting up an Etch environment > > is quite OK if that will do the trick. > > I can only confirm that this works fine in a source based > installation. I'd try Etch ;) > > Cheers, > > Gunnar > > > > > Cheers, > > Del > > > > On Thu, 2009-03-05 at 17:26 +0100, Thomas Arendsen Hein wrote: > >> Hi! > >> > >> I just uploaded Kolab Server 2.2.1-rc1 which contains about 60 > >> enhancements and fixes compared to beta1. > >> > >> Please make sure to follow the upgrade instructions in 1st.README, > >> especially if upgrading from server 2.2.0 or older. > >> > >> Again many thanks to all the people who helped with this! > >> > >> Documentation and OpenPKG source packages will soon be available in > >> the directory server/beta/kolab-server-2.2.1-rc-1/ of the mirrors > >> listed on http://kolab.org/mirrors.html > >> for example: > >> http://ftp.gwdg.de/pub/linux/kolab/server/beta/kolab-server-2.2.1-rc-1/ > >> ftp://ftp.gwdg.de/pub/linux/kolab/server/beta/kolab-server-2.2.1-rc-1/ > >> > >> rsync://rsync.kolab.org/kolab/RSYNC.txt explains how to get (or > >> mirror) the files via rsync. > >> > >> All files updated since 2.2.1-beta1 are available in the directory > >> server/development-2.2/20090305-since-20081212/ > >> > >> You can check the integrity of the downloaded files with: > >> > >> $ gpg --keyserver hkp://subkeys.pgp.net --recv-key 5816791A > >> or import the key from https://www.intevation.de/~thomas/gpg_pub_key.asc > >> (the same key that I used to sign this email) > >> $ gpg --verify SHA1SUMS.sig > >> $ sha1sum -c SHA1SUMS > >> > >> Binary packages for Debian GNU/Linux (etch/stable) on x86 platforms > >> can be found in the ix86-debian4.0 directory next to the sources. > >> > >> Please look at 1st.README and release-notes.txt (attached for your > >> convenience) for install instructions and more information about > >> this release. > >> > >> Please report any problems you encounter in our issue tracker: > >> https://issues.kolab.org/ > >> > >> Regards, > >> Thomas Arendsen Hein > >> > >> _______________________________________________ > >> Kolab-users mailing list > >> Kolab-users at kolab.org > >> https://kolab.org/mailman/listinfo/kolab-users > > > > _______________________________________________ > > Kolab-users mailing list > > Kolab-users at kolab.org > > https://kolab.org/mailman/listinfo/kolab-users > > > > > > _______________________________________________ > Kolab-users mailing list > Kolab-users at kolab.org > https://kolab.org/mailman/listinfo/kolab-users From delonly at gmail.com Sun Mar 8 15:34:35 2009 From: delonly at gmail.com (Del) Date: Sun, 08 Mar 2009 15:34:35 +0100 Subject: Kontact for MacOS experience (continued) Message-ID: <1236522875.23650.24.camel@black> Another week-end, another chance to acquint myself with Macs :) On the uninstall issue, it turns out that Macs actually do not have uninstall functonality, and there is a number of third party apps supposed to remedy that. Tested one of them without being able to find any trace of Kontact with it. However, settings and configuration files for Kontact is put exactly where they are supposed to on Macs, namely in the ~/Library/Preferences/KDE folder, so removing that folder and /opt leaves you with clean sheets. Moreover, we find the familiar structure of KDE config files in the KDE folder. I took the opportunity to test drive the new 2.2.1 RC1, which so far works beautifully. This time around I was able to start with clean sheets, and can add the following: -Free/Busy works as expected :) Found another bug: -When KMail runs in separate window, and you choose Mail in Kontact, KMail fails to rise over the Kontact window. Hence users not paying attention on the message at the bottom of Kontact, will not realize that mail is already open when Kontact covers the mail window. Found a possible bug (not sure if it is reproducible yet) -Reminder daemon did not remind me 15 minutes prior to meeting. It may be triggered by the time settings being shifted one hour between server and client. >Try the apple key and mouse button. Nope, beats me, maybe Steve Jobs has put in an ifdef on me. >Yes, for a problem report on this particular item >we would need to get detailed data. Indeed, it seems to be a Horde issue, and not even consitent there. Norwegian letters seems to work nicely in Kontact. >Sure, if the other person gives you permissions to see one or more of their >calender folders, it will just be shown in the calendar view. >(You can choose all four views: a) combined, b) side by side c) horizontal d) >monthly.) Thanks, found it. Probably a stupid question, but how does one set permission on the calendar? Cheers, Del From wrobel at pardus.de Sun Mar 8 18:32:09 2009 From: wrobel at pardus.de (Gunnar Wrobel) Date: Sun, 08 Mar 2009 18:32:09 +0100 Subject: Kolab Server 2.2.1 Release Candidate 1 In-Reply-To: <1236515202.22384.15.camel@black> References: <20090305162647.GA1490.thomas@intevation.de> <1236444247.13379.22.camel@black> <20090307204403.18487cjwsth8v04c@webmail.pardus.de> <1236515202.22384.15.camel@black> Message-ID: <20090308183209.61634tzydpsn0bgg@webmail.pardus.de> Hi Del, thanks for the feedback. Quoting Del : > Indeed, thanks! A couple of comments on the installation: > > -The siging certificate dialougue (when bootstrapping) does not specify > a default to [y/n], but defaults to "no" resulting in Apache not > working. I think iot would make sense to warn the user of the > consequences when just pressing enter, and of course to inform about the > default choice. Sounds reasonable. Please open an issue about it. > > -DNS needs to be set up somehow for Apache to start, I think it makes > sense to include information on the options here on the wiki, since a > test-environment can be put up pretty easily. Unless there is some > objections, I can put information on this on the wiki. Would be great. Thanks! > > For the Horde environment I have three comments. The first being > important (at least in my mind): > > -The LDAP users are found in the "Global address book", which must be > set explicitely in Horde to be used. Moreover it must me moved on top of > "Contacts" to autocomplete in "Edit Attendees" view. I think this is not > very intuitive for new admins, so at least we should have it documented > and easily accessible on the wiki. I just opened an issue about this as others were also complaining. Should be easy to fix. https://www.intevation.de/roundup/kolab/issue3459 > > -Norwegian letters messed up in Horde when scheduling meetings, but not > for mail (but this I assume is a Horde issue). Might be related to https://www.intevation.de/roundup/kolab/issue3285 > > -Free/busy for users not available in Horde until after first log-in (I > minor one, which I am not sure should be given any attention). I'm not 100% certain I understand what you mean but it sounds like something we should give attention to so please open an issue with a detailed description. Thanks! Gunnar > > Cheers, > Del > > > On Sat, 2009-03-07 at 20:44 +0100, Gunnar Wrobel wrote: >> Quoting Del : >> >> > Thank you! Just gave it a try on one of my machines to test, and have an >> > issue that maybe somebody can give a quick answer too. It may simply be >> > related to my test set-up being on an Ubuntu 8.04 x86-64 box. I used the >> > packages for Etch i386 with OpenPKG. >> > >> > The issue is that mail is somehow not set-up. Logging into Horde, and >> > using calendar works fine, but any attempt at clicking anything related >> > to mail results in forced log-out. I am happy if anybody can confirm >> > that this is not the case on a base Etch install. I do not mean to chase >> > down issues related to other OS versions, setting up an Etch environment >> > is quite OK if that will do the trick. >> >> I can only confirm that this works fine in a source based >> installation. I'd try Etch ;) >> >> Cheers, >> >> Gunnar >> >> > >> > Cheers, >> > Del >> > >> > On Thu, 2009-03-05 at 17:26 +0100, Thomas Arendsen Hein wrote: >> >> Hi! >> >> >> >> I just uploaded Kolab Server 2.2.1-rc1 which contains about 60 >> >> enhancements and fixes compared to beta1. >> >> >> >> Please make sure to follow the upgrade instructions in 1st.README, >> >> especially if upgrading from server 2.2.0 or older. >> >> >> >> Again many thanks to all the people who helped with this! >> >> >> >> Documentation and OpenPKG source packages will soon be available in >> >> the directory server/beta/kolab-server-2.2.1-rc-1/ of the mirrors >> >> listed on http://kolab.org/mirrors.html >> >> for example: >> >> http://ftp.gwdg.de/pub/linux/kolab/server/beta/kolab-server-2.2.1-rc-1/ >> >> ftp://ftp.gwdg.de/pub/linux/kolab/server/beta/kolab-server-2.2.1-rc-1/ >> >> >> >> rsync://rsync.kolab.org/kolab/RSYNC.txt explains how to get (or >> >> mirror) the files via rsync. >> >> >> >> All files updated since 2.2.1-beta1 are available in the directory >> >> server/development-2.2/20090305-since-20081212/ >> >> >> >> You can check the integrity of the downloaded files with: >> >> >> >> $ gpg --keyserver hkp://subkeys.pgp.net --recv-key 5816791A >> >> or import the key from >> https://www.intevation.de/~thomas/gpg_pub_key.asc >> >> (the same key that I used to sign this email) >> >> $ gpg --verify SHA1SUMS.sig >> >> $ sha1sum -c SHA1SUMS >> >> >> >> Binary packages for Debian GNU/Linux (etch/stable) on x86 platforms >> >> can be found in the ix86-debian4.0 directory next to the sources. >> >> >> >> Please look at 1st.README and release-notes.txt (attached for your >> >> convenience) for install instructions and more information about >> >> this release. >> >> >> >> Please report any problems you encounter in our issue tracker: >> >> https://issues.kolab.org/ >> >> >> >> Regards, >> >> Thomas Arendsen Hein >> >> >> >> _______________________________________________ >> >> Kolab-users mailing list >> >> Kolab-users at kolab.org >> >> https://kolab.org/mailman/listinfo/kolab-users >> > >> > _______________________________________________ >> > Kolab-users mailing list >> > Kolab-users at kolab.org >> > https://kolab.org/mailman/listinfo/kolab-users >> > >> >> >> >> _______________________________________________ >> Kolab-users mailing list >> Kolab-users at kolab.org >> https://kolab.org/mailman/listinfo/kolab-users > > _______________________________________________ > Kolab-users mailing list > Kolab-users at kolab.org > https://kolab.org/mailman/listinfo/kolab-users > -- ______ 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. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: Digitale PGP-Unterschrift URL: From delonly at gmail.com Sun Mar 8 22:32:23 2009 From: delonly at gmail.com (Del) Date: Sun, 8 Mar 2009 22:32:23 +0100 Subject: Kolab Server 2.2.1 Release Candidate 1 In-Reply-To: <20090308183209.61634tzydpsn0bgg@webmail.pardus.de> References: <20090305162647.GA1490.thomas@intevation.de> <1236515202.22384.15.camel@black> <20090308183209.61634tzydpsn0bgg@webmail.pardus.de> Message-ID: <200903082232.24107.delonly@gmail.com> > Sounds reasonable. Please open an issue about it. Done: https://www.intevation.de/roundup/kolab/issue3460 > I just opened an issue about this as others were also complaining. > Should be easy to fix. Thanks. > > -Norwegian letters messed up in Horde when scheduling meetings, but not > > for mail (but this I assume is a Horde issue). > > Might be related to > > https://www.intevation.de/roundup/kolab/issue3285 Indeed, it is the same issue. Cheers, Del From thomas at btspuhler.com Mon Mar 9 02:02:57 2009 From: thomas at btspuhler.com (Thomas Spuhler) Date: Sun, 8 Mar 2009 18:02:57 -0700 Subject: kolab on openSUSE natively is a little bit back In-Reply-To: <200902161944.37779.ml@radoeka.nl> References: <200902142107.48113.ml@radoeka.nl> <20090216110832.47834nh2hm2zt8g0@www.inovox.de> <200902161944.37779.ml@radoeka.nl> Message-ID: <200903081802.57794.thomas@btspuhler.com> On Monday 16 February 2009, Richard Bos wrote: > Op maandag 16 februari 2009 11:08:32 schreef Carsten Burghardt: > > > Anyway, I just wanted to let you know that progress is made and it > > > would be great if others start testing the current packages. ?Find more > > > information about kolab on openSUSE at: > > > http://wiki.kolab.org/index.php/OpenSUSE_-_natively > > > and > > > http://en.opensuse.org/Kolab > > > > This is great! I am running version 2.2.0 on Suse 10.3 and I wonder ? > > what the proposed way for an upgrade is. Can I simply update the ? > > packages? As it is a productive system I can not really uninstall the ? > > previous packages. > > I have kolab 2.2.0 running on an openSUSE 10.3 system as well, so we're in > the same boat. I'm not thinking about a upgrade yet, as a lot of > functionality is still to be tested. I would say get another openSUSE 10.3 > system up and running with kolab 2.2.0 in e.g. virtual box. Use that image > to exercise the upgrade. > > The big difference between kolab on openSUSE 10.3 and 11.1 will be the > openldap replication mode. This must change from slurpd to syncrepl. This > is working nicely. The data does not need to change I believe, so as long > as all data is backed up you should be fine. Can you please provide the slapd.conf.template file for the Syncrepl implementation? -- Thomas From bernhard at intevation.de Mon Mar 9 09:55:36 2009 From: bernhard at intevation.de (Bernhard Reiter) Date: Mon, 9 Mar 2009 09:55:36 +0100 Subject: Kolab Server 2.2.1 Release Candidate 1 In-Reply-To: <1236444247.13379.22.camel@black> References: <20090305162647.GA1490.thomas@intevation.de> <1236444247.13379.22.camel@black> Message-ID: <200903090955.36743.bernhard@intevation.de> Am Samstag, 7. M?rz 2009 17:44:07 schrieb Del: > Thank you! Just gave it a try on one of my machines to test, and have an > issue that maybe somebody can give a quick answer too. It may simply be > related to my test set-up being on an Ubuntu 8.04 x86-64 box. I used the > packages for Etch i386 with OpenPKG. > > The issue is that mail is somehow not set-up. Logging into Horde, and > using calendar works fine, but any attempt at clicking anything related > to mail results in forced log-out. Forced log-out with the webclient usually means a fatal php error, if this happens you should checkout the logs and report. -- 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: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From bernhard at intevation.de Mon Mar 9 09:59:11 2009 From: bernhard at intevation.de (Bernhard Reiter) Date: Mon, 9 Mar 2009 09:59:11 +0100 Subject: Kontact for MacOS experience (continued) In-Reply-To: <1236522875.23650.24.camel@black> References: <1236522875.23650.24.camel@black> Message-ID: <200903090959.12127.bernhard@intevation.de> Am Sonntag, 8. M?rz 2009 15:34:35 schrieb Del: > Found another bug: > -When KMail runs in separate window, and you choose Mail in Kontact, > KMail fails to rise over the Kontact window. Hence users not paying > attention on the message at the bottom of Kontact, will not realize that > mail is already open when Kontact covers the mail window. Do not run KMail separately if you intend to you the Kolab Server (dimap) Resource with Kontact for calender data. > Found a possible bug (not sure if it is reproducible yet) > -Reminder daemon did not remind me 15 minutes prior to meeting. It may > be triggered by the time settings being shifted one hour between server > and client. We had a few known issues with the reminders which will be fixed with a more recent version, I do not know if this is one of them. "Korgac" must be running for reminders to work. Do you get any reminders at all? > >Sure, if the other person gives you permissions to see one or more of > > their calender folders, it will just be shown in the calendar view. > >(You can choose all four views: a) combined, b) side by side c) horizontal > > d) monthly.) > > Thanks, found it. Probably a stupid question, but how does one set > permission on the calendar? In the properties dialog of a calender folder (if the folder is on a Kolab Server). 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: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From ludwig.reiter at intevation.de Mon Mar 9 12:45:32 2009 From: ludwig.reiter at intevation.de (Ludwig Reiter) Date: Mon, 9 Mar 2009 12:45:32 +0100 Subject: New native Windows Client: Kontact Enterprise4 Message-ID: <200903091245.37875.ludwig.reiter@intevation.de> Hello, on files.kolab.org is a new 'beta-huge-debug' version of the Kontact Enterprise4 Windows Client: Version 20090220. It contains a lot of bugfixes (see the attachment NewsLog-20090220.txt), but is still a beta. So read the README before use. It is not recommended for productive use. You can download the installer from: http://files.kolab.org/clients/kontact-enterprise4/windows/beta-huge-debug/20090220/Kontact-Installer_20090220.exe Best Regards, Ludwig -- Intevation GmbH, Osnabr?ck Firmensitz: Neuer Graben 17, 49074 Osnabr?ck Registereintrag: Amtsgericht Osnabr?ck, HR B 18998 Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- Friday, February 20th 2009 Problems addressed ------------------ * Fix crash of reminder daemon on Windows. * Fix serious memory leak on Windows that would crash KMail in minutes. * Make the message box that appears when quitting Kleopatra work correctly again. * Fix column resizing in Kleopatra. * Fix incorrect word-wrapping in Kleopatra. * Remove unused Akonadi, to save some space in the snapshots. * Add icon usage log to Kleopatra, to help finding out which icons are needed. Merges ------ * Merges from KDE 4.2 branch: - Load missing translation catalogs in KOrganizer and KAddressbook - Fix Kontact needing a refresh to show the incidences at startup - Fix network connection bug in KNode - Fix endless recursion in KOrganizer - Make sure to not execute executables when clicking a link, in KMail - In KMail, convert a non-breaking space to normal spaces in the plain text version, to fix the encoding. - Load resources only once in the summary - Remove duplicated code in KOrganizer, this should fix multi-day/recurrence logic - Further layout fixes for the summary - Fix memory leak in KOrganizer - Remove the unused "default color for events" configuration setting - When creating a journal, use today as the default date - When moving a recurring event, if it was dropped to it's original place, don't show the "Changing Recurring Item" dialog, don't even count this as a modification * merges from enterprise35 branch: - Disable various buttons if they have no effect, in KOrganizer, KNotes, KAddressbook and KMail - Fix memory leak in KMail Friday, February 13th 2009 Problems addressed ------------------ * Disable the broken "Details" link for signed S/MIME messages Merges ------ * Merges from KDE 4.2 branch: - Correctly display broken S/MIME messages without protocol paramter in the header - Hide the "msg.asc" attachment for encrypted messages - Don't add POP3 and local accounts to the manage sieve script dialog - Fix icons in Kleopatra's audit log - Performance improvement in agendaview and support for multi-day recurring events in KOrganizer - Fix crash in KOrganizer's agenda view - Some changes to the look of the Kontact summary - Honor the font setting in KNode's composer - Attempt to fix the paint event crash in KOrganizer - Improvments in the color chooser of KOrganizer's setting dialog * Merges from KDE trunk: - Show nice status bar text for the attachment quicklilst button * merges from enterprise35 branch: - kolab/issue3385: Reminder of an event doesn't work - kolab/issue3374: Window behaviour of Kontact is undesirable sometimes if a message box comes up - Add the distribution list updater - Add search and move messages to trash to context menu of favorite folders - Fix a crash when deleting a note - Fix memory leak in KNotes Friday, February 6th 2009 Problems addressed ------------------- * kolab/issue2782: timezones missing in Korganizer Settings for Time/Date on Windows * kolab/issue3386: Disable the check for hostname matching when retrieving fb information by default. Merges ------- * Merges from 4.2 branch: - blocked fixes from KPilot - spelling fixes - fixes to the dk and import of an sk holiday file - fix for d'n'd of events crossing canvas limits - Add support for resizing all day multi-day events that don't have a visible start. - fix for a regression introduced by a performance optimization in multiday event handling Friday, January 30th 2009 Problems addressed ------------------- * kolab/issue2444(partial) kontact sends base64 encoded password when sieve server does not advertise STARTTLS * kolab/issue2677 Misleading german translation "Die Terminordner geh?ren zur Identit?t" * kolab/issue3160 (Progress dialogs don't go away: probably operations don't complete.) Friday, December 12th 2008 Problems Addressed ------------------ * kolab/issue3305 Double click on a distribution list in the distribution list editor should open an edit dialog. * kolab/issue3306 "No attendees" behind the title of a new event or task not translated into German. * kolab/issue2048 Distribution list: couldn't delete a contact from a dist list with pressing on "delete". * kolab/issue3281 Kontact does not quote CNs in iCalendar mails, which Outlook 2003 (OL 2K3) then fails to recognise. * KDE BUGS #175594,169563,88781,149309,145163,174332,170030,175045,173964,140032,174707,174707,160600,175100,175623, 174992,169140,175590, * kolab/issue3249 Strange crash while replying to an SMIME mail. ( forward port from e3 ) * kolab/issue3143 s/mime invalid keys are accepted by KMail and shown green in kleo (certmanager/lib/ui/keyselectiondialog.cpp) ( forward port from e3 ) * kolab/issue3137 (While creating a new mail with SMTP auth, kwallet is not asked to get the password) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 206 bytes Desc: This is a digitally signed message part. URL: From delonly at gmail.com Mon Mar 9 13:26:31 2009 From: delonly at gmail.com (Del) Date: Mon, 9 Mar 2009 13:26:31 +0100 Subject: Kontact for MacOS experience (continued) In-Reply-To: <200903090959.12127.bernhard@intevation.de> References: <1236522875.23650.24.camel@black> <200903090959.12127.bernhard@intevation.de> Message-ID: <2d303b680903090526k2dbaee8fh8b77e8ff5e46c552@mail.gmail.com> On Mon, Mar 9, 2009 at 9:59 AM, Bernhard Reiter wrote: > Do not run KMail separately if you intend to you the Kolab Server (dimap) > Resource with Kontact for calender data. That is a good point that I didn't even consider. The KMail window must have been opened separately when I clicked the tray icon, since I only use the kontact.app file to open Kontact. Sounds to me like the actions from clicking the tray icon should ideally be adjusted. We had a few known issues with the reminders which will be fixed with a more > recent version, I do not know if this is one of them. "Korgac" must be > running for reminders to work. Do you get any reminders at all? No, I didn't get any reminders, but be aware that I only tested this issue briefly as it was towards the end of my week-end period with Steve Jobs. In the properties dialog of a calender folder (if the folder is on a Kolab > Server). Thanks again, Del -------------- next part -------------- An HTML attachment was scrubbed... URL: From tomas.andersson at heatex.com Mon Mar 9 14:45:32 2009 From: tomas.andersson at heatex.com (Tomas Andersson) Date: Mon, 9 Mar 2009 14:45:32 +0100 Subject: APT-GET and kolab Message-ID: <00d101c9a0bd$50dcf1d0$f296d570$@andersson@heatex.com> Can I and how do I get kolab to stay up to date with the latest stable version using apt-get Is there a repository address? Is it safe to use apt-get to update kolab or is there risk of braking the installation. Mvh / Meilleures salutations / Best regards / MFG, Tomas Andersson IT Administrator Heatex AB Tel.: + 46 410 710 554 Fax : + 46 410 710 529 Mob : + 46 702 772 597 Email : tomas.andersson at heatex.com Internet: www.heatex.com DISCLAIMER: 'The information contained in this email and any attachment is confidential. It is intended only for the named addressee(s). If you are not the named addressee please notify the sender immediately and do not disclose, copy or distribute the contents to any other person other than the intended addressee(s).' -------------- next part -------------- An HTML attachment was scrubbed... URL: From bernhard at intevation.de Mon Mar 9 17:40:36 2009 From: bernhard at intevation.de (Bernhard Reiter) Date: Mon, 9 Mar 2009 17:40:36 +0100 Subject: Kontact for MacOS experience (continued) In-Reply-To: <2d303b680903090526k2dbaee8fh8b77e8ff5e46c552@mail.gmail.com> References: <1236522875.23650.24.camel@black> <200903090959.12127.bernhard@intevation.de> <2d303b680903090526k2dbaee8fh8b77e8ff5e46c552@mail.gmail.com> Message-ID: <200903091740.37142.bernhard@intevation.de> Am Montag, 9. M?rz 2009 13:26:31 schrieb Del: > On Mon, Mar 9, 2009 at 9:59 AM, Bernhard Reiter wrote: > > Do not run KMail separately if you intend to you the Kolab Server (dimap) > > Resource with Kontact for calender data. > > That is a good point that I didn't even consider. The KMail window must > have been opened separately when I clicked the tray icon, since I only use > the kontact.app file to open Kontact. Sounds to me like the actions from > clicking the tray icon should ideally be adjusted. There is a slight temporary problem that kmail gets started when you use the wizard, you have to close it and restart kontact to continue. -- 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: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From bernhard at intevation.de Mon Mar 9 17:43:16 2009 From: bernhard at intevation.de (Bernhard Reiter) Date: Mon, 9 Mar 2009 17:43:16 +0100 Subject: APT-GET and kolab In-Reply-To: <00d101c9a0bd$50dcf1d0$f296d570$@andersson@heatex.com> References: <00d101c9a0bd$50dcf1d0$f296d570$@andersson@heatex.com> Message-ID: <200903091743.16772.bernhard@intevation.de> Am Montag, 9. M?rz 2009 14:45:32 schrieb Tomas Andersson: > Can I and how do I get kolab to stay up to date with the latest stable > version using apt-get Depends on your definition of "kolab". For the KDE Kolab Client, apt-get is the recommended way, if you get the packages from the Kolab Konsortium or your upstream distribution. For Kolab Server the recommended way is to use Kolab Server/OpenPKG and updates from from OpenPKG or the Kolab developers. You do not use apt-get for those. The Kolab Server/Debian variant is under development. You should use it with apt-get if you like to help testing 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: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From kolab-marc at fieldinternet.com Mon Mar 9 19:18:25 2009 From: kolab-marc at fieldinternet.com (kolab-marc at fieldinternet.com) Date: Mon, 9 Mar 2009 11:18:25 -0700 Subject: Kontact Windows 2009-02-20 IMAP issue Message-ID: <20090309181825.GB21274@sonic.net> Hi, I am writing to report an issue with the most recent Kontact for Windows build (as well as the previous one): I have two IMAP servers configured for mail, and for both servers, Kmail shows only one message in each folder, even though there are many messages in most folders. This is true for both servers. Is this a known bug? Are there any known workarounds or fixes? If I can provide additional info that would be helpful in figuring this out, please let me know. Thanks! Marc From ml at radoeka.nl Mon Mar 9 21:21:19 2009 From: ml at radoeka.nl (Richard Bos) Date: Mon, 9 Mar 2009 21:21:19 +0100 Subject: kolab on openSUSE natively is a little bit back In-Reply-To: <200903081802.57794.thomas@btspuhler.com> References: <200902142107.48113.ml@radoeka.nl> <200902161944.37779.ml@radoeka.nl> <200903081802.57794.thomas@btspuhler.com> Message-ID: <200903092121.20031.ml@radoeka.nl> Op maandag 09 maart 2009 02:02:57 schreef Thomas Spuhler: > > The big difference between kolab on openSUSE 10.3 and 11.1 will be the > > openldap replication mode. This must change from slurpd to syncrepl. > > This is working nicely. The data does not need to change I believe, so > > as long as all data is backed up you should be fine. > > Can you please provide the slapd.conf.template file for the Syncrepl > implementation? You can get it from cvs: http://kolab.org/cgi-bin/viewcvs-kolab.cgi/server/kolabd/kolabd/templates/slapd.conf.template.in?rev=1.25&content-type=text/vnd.viewcvs-markup -- Richard From thomas at btspuhler.com Mon Mar 9 23:55:25 2009 From: thomas at btspuhler.com (Thomas Spuhler) Date: Mon, 9 Mar 2009 15:55:25 -0700 Subject: kolab on openSUSE natively is a little bit back In-Reply-To: <200903092121.20031.ml@radoeka.nl> References: <200902142107.48113.ml@radoeka.nl> <200903081802.57794.thomas@btspuhler.com> <200903092121.20031.ml@radoeka.nl> Message-ID: <200903091555.25790.thomas@btspuhler.com> On Monday 09 March 2009, Richard Bos wrote: > Op maandag 09 maart 2009 02:02:57 schreef Thomas Spuhler: > > > The big difference between kolab on openSUSE 10.3 and 11.1 will be the > > > openldap replication mode. This must change from slurpd to syncrepl. > > > This is working nicely. The data does not need to change I believe, > > > so as long as all data is backed up you should be fine. > > > > Can you please provide the slapd.conf.template file for the Syncrepl > > implementation? > > You can get it from cvs: > http://kolab.org/cgi-bin/viewcvs-kolab.cgi/server/kolabd/kolabd/templates/s >lapd.conf.template.in?rev=1.25&content-type=text/vnd.viewcvs-markup Thanks a lot. Thomas From thomas at btspuhler.com Tue Mar 10 03:35:50 2009 From: thomas at btspuhler.com (Thomas Spuhler) Date: Mon, 9 Mar 2009 19:35:50 -0700 Subject: kolab on openSUSE natively is a little bit back In-Reply-To: <200903092121.20031.ml@radoeka.nl> References: <200902142107.48113.ml@radoeka.nl> <200903081802.57794.thomas@btspuhler.com> <200903092121.20031.ml@radoeka.nl> Message-ID: <200903091935.51225.thomas@btspuhler.com> On Monday 09 March 2009, Richard Bos wrote: > Op maandag 09 maart 2009 02:02:57 schreef Thomas Spuhler: > > > The big difference between kolab on openSUSE 10.3 and 11.1 will be the > > > openldap replication mode. This must change from slurpd to syncrepl. > > > This is working nicely. The data does not need to change I believe, > > > so as long as all data is backed up you should be fine. > > > > Can you please provide the slapd.conf.template file for the Syncrepl > > implementation? > > You can get it from cvs: > http://kolab.org/cgi-bin/viewcvs-kolab.cgi/server/kolabd/kolabd/templates/s >lapd.conf.template.in?rev=1.25&content-type=text/vnd.viewcvs-markup What do the @@@ mean in @@@else@@@ They are not being take resp. are move to the slapd.conf as they are and report a failure. -- Thomas From bernhard at intevation.de Tue Mar 10 08:47:56 2009 From: bernhard at intevation.de (Bernhard Reiter) Date: Tue, 10 Mar 2009 08:47:56 +0100 Subject: Kontact Windows 2009-02-20 IMAP issue In-Reply-To: <20090309181825.GB21274@sonic.net> References: <20090309181825.GB21274@sonic.net> Message-ID: <200903100847.56977.bernhard@intevation.de> Marc, Am Montag, 9. M?rz 2009 19:18:25 schrieb kolab-marc at fieldinternet.com: > I am writing to report an issue with the most recent Kontact for Windows > build (as well as the previous one): (Best is to always use the version line from the README for reporting.) > I have two IMAP servers configured > for mail, and for both servers, Kmail shows only one message in each > folder, even though there are many messages in most folders. ?This is true > for both servers. > > Is this a known bug? ? This would be a new defect. Which "resource" are you using? "dimap" or "online imap"? If you are using online imap, try the other resource. Thanks for the feedback! 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: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From tomas.andersson at heatex.com Tue Mar 10 09:09:16 2009 From: tomas.andersson at heatex.com (Tomas Andersson) Date: Tue, 10 Mar 2009 09:09:16 +0100 Subject: SV: APT-GET and kolab In-Reply-To: <200903091743.16772.bernhard@intevation.de> References: <00d101c9a0bd$50dcf1d0$f296d570$@andersson@heatex.com> <200903091743.16772.bernhard@intevation.de> Message-ID: <001e01c9a157$818789e0$84969da0$@andersson@heatex.com> This is our info under version in the webadmin Any pointers on how to keep the system up to date would be nice This is a production server so I can't afford to have a lot of downtime Kolab2 Groupware Server Version 2.0.3 Kolab2 Groupware Server Component Versions perl-kolab-5.8.7-2.0_20051219 kolabd-1.9.4-20060111 kolab-resource-handlers-0.3.9-20060111 kolab-webadmin-0.4.0-20060111 Kolab2 Patched OpenPKG Package Versions amavisd-2.3.1-2.4.0 apache-1.3.33-2.4.5_kolab imapd-2.2.12-2.4.0_kolab3 postfix-2.2.3-2.4.1_kolab OpenPKG Version openpkg-2.4.3-2.4.3 -----Ursprungligt meddelande----- Fr?n: kolab-users-bounces at kolab.org [mailto:kolab-users-bounces at kolab.org] F?r Bernhard Reiter Skickat: den 9 mars 2009 17:43 Till: kolab-users at kolab.org ?mne: Re: APT-GET and kolab Am Montag, 9. M?rz 2009 14:45:32 schrieb Tomas Andersson: > Can I and how do I get kolab to stay up to date with the latest stable > version using apt-get Depends on your definition of "kolab". For the KDE Kolab Client, apt-get is the recommended way, if you get the packages from the Kolab Konsortium or your upstream distribution. For Kolab Server the recommended way is to use Kolab Server/OpenPKG and updates from from OpenPKG or the Kolab developers. You do not use apt-get for those. The Kolab Server/Debian variant is under development. You should use it with apt-get if you like to help testing 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 From bernhard at intevation.de Tue Mar 10 13:01:06 2009 From: bernhard at intevation.de (Bernhard Reiter) Date: Tue, 10 Mar 2009 13:01:06 +0100 Subject: SV: APT-GET and kolab In-Reply-To: <001e01c9a157$818789e0$84969da0$@andersson@heatex.com> References: <00d101c9a0bd$50dcf1d0$f296d570$@andersson@heatex.com> <200903091743.16772.bernhard@intevation.de> <001e01c9a157$818789e0$84969da0$@andersson@heatex.com> Message-ID: <200903101301.07321.bernhard@intevation.de> Am Dienstag, 10. M?rz 2009 09:09:16 schrieb Tomas Andersson: > This is our info under version in the webadmin > Any pointers on how to keep the system up to date would be nice > This is a production server so I can't afford to have a lot of downtime > > Kolab2 Groupware Server Version > 2.0.3 Migrate to 2.2.0 or wait for the 2.2.1. There are upgrade instructions in the 1st.README. -- 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: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From kolab-marc at fieldinternet.com Tue Mar 10 17:54:27 2009 From: kolab-marc at fieldinternet.com (kolab-marc at fieldinternet.com) Date: Tue, 10 Mar 2009 09:54:27 -0700 Subject: Kontact Windows 2009-02-20 IMAP issue In-Reply-To: <200903100847.56977.bernhard@intevation.de> References: <20090309181825.GB21274@sonic.net> <200903100847.56977.bernhard@intevation.de> Message-ID: <20090310165424.GA22635@sonic.net> On Tue, Mar 10, 2009 at 08:47:56AM +0100, Bernhard Reiter wrote: > > I have two IMAP servers configured > > for mail, and for both servers, Kmail shows only one message in each > > folder, even though there are many messages in most folders. ?This is true > > for both servers. > > > > Is this a known bug? ? > > This would be a new defect. > Which "resource" are you using? > "dimap" or "online imap"? If you are using online imap, try the other > resource. > Hi Bernhard, I was using the online imap resource. I deleted the servers and re-created them using dimap as you suggested, and now it works perfectly. Thanks, Marc From delonly at gmail.com Tue Mar 10 18:19:55 2009 From: delonly at gmail.com (Del) Date: Tue, 10 Mar 2009 18:19:55 +0100 Subject: Kontact for MacOS experience (continued) In-Reply-To: <200903091740.37142.bernhard@intevation.de> References: <1236522875.23650.24.camel@black> <2d303b680903090526k2dbaee8fh8b77e8ff5e46c552@mail.gmail.com> <200903091740.37142.bernhard@intevation.de> Message-ID: <200903101819.55215.delonly@gmail.com> On Monday 09 March 2009 17:40:36 Bernhard Reiter wrote: > There is a slight temporary problem that kmail gets started when you use > the wizard, you have to close it and restart kontact to continue. I am pretty sure it was when trying to close the tray process that KMail opened in a separate window, but I don't have the machine to cross-check with now. However, I have encountered some more serious problems with another MacBook. This Mac is running OSX 10.4.11 (the other was running 10.5.5). I am not sure if that can explain any of the behaviour I am seeing. These are the issues: -It prompts for certificate whenever I send a mail (yes, tried to accept it forever, but it doesn't help). -I am not able to store any calender entries, I am just told to configure KMail because no resources is found. Cheers, Del From ml at radoeka.nl Tue Mar 10 21:42:03 2009 From: ml at radoeka.nl (Richard Bos) Date: Tue, 10 Mar 2009 21:42:03 +0100 Subject: kolab on openSUSE natively is a little bit back In-Reply-To: <200903091935.51225.thomas@btspuhler.com> References: <200902142107.48113.ml@radoeka.nl> <200903092121.20031.ml@radoeka.nl> <200903091935.51225.thomas@btspuhler.com> Message-ID: <200903102142.04276.ml@radoeka.nl> Op dinsdag 10 maart 2009 03:35:50 schreef Thomas Spuhler: > > You can get it from cvs: > > http://kolab.org/cgi-bin/viewcvs-kolab.cgi/server/kolabd/kolabd/templates > >/s lapd.conf.template.in?rev=1.25&content-type=text/vnd.viewcvs-markup > > What do the @@@ mean in > @@@else@@@ This is processed / parsed by kolabconf. After processing with kolabconf those @@@ tags are no longer part of the configuration file. > They are not being take resp. are move to the slapd.conf as they are and > report a failure. If you process the config file manually, you need to interpret the @@@ tags and have related section removed / replaced. Hope this helps. -- Richard From bernhard at intevation.de Wed Mar 11 09:25:21 2009 From: bernhard at intevation.de (Bernhard Reiter) Date: Wed, 11 Mar 2009 09:25:21 +0100 Subject: Kontact for MacOS experience (continued) In-Reply-To: <200903101819.55215.delonly@gmail.com> References: <1236522875.23650.24.camel@black> <200903091740.37142.bernhard@intevation.de> <200903101819.55215.delonly@gmail.com> Message-ID: <200903110925.22179.bernhard@intevation.de> On Tuesday 10 March 2009, Del wrote: > However, I have encountered some more serious problems with another > MacBook. This Mac is running OSX 10.4.11 (the other was running 10.5.5). I > am not sure if that can explain any of the behaviour I am seeing. These are > the issues: -It prompts for certificate whenever I send a mail (yes, tried > to accept it forever, but it doesn't help). > -I am not able to store any calender entries, I am just told to configure > KMail because no resources is found. So far our main target it the current OSX, which is 10.5. The results with other versions might vary. -- Managing Director - Owner: www.intevation.net (Free Software Company) Germany Coordinator: fsfeurope.org. Coordinator: www.Kolab-Konsortium.com. Intevation GmbH, Neuer Graben 17, Osnabr?ck, DE; AG Osnabr?ck, HRB 18998 Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part. URL: From kolab-marc at fieldinternet.com Thu Mar 12 21:39:34 2009 From: kolab-marc at fieldinternet.com (kolab-marc at fieldinternet.com) Date: Thu, 12 Mar 2009 13:39:34 -0700 Subject: Kontact Windows client - questions (url handler; spelling) Message-ID: <20090312203931.GA553@sonic.net> Hi, I am using Kontact Version 1.3 (enterprise4 0.20090220.928360) Windows. I have two questions: 1. How do I set kmail to use a Windows web browser to open URLs clicked in an email? Currently it opens the kde "Transferring" window, which does not actually open any browser. I searched the share/config directories but did not recognize the correct file to edit. By the way, I do not have KDE for Windows installed out of fear that it will conflict with Kontact. 2. How to I set up spell checking for kmail? When I use Tools:Spelling in the compose window, it does not actually check anything. Also, I do not see the spelling settings that (I think) are present in kmail on Linux in the composer settings. Thanks, Marc From johnm at advocap.org Sun Mar 15 00:25:36 2009 From: johnm at advocap.org (John McMonagle) Date: Sat, 14 Mar 2009 18:25:36 -0500 Subject: Openpkg install on debian lenny Message-ID: <200903141825.36821.johnm@advocap.org> I'm about to install Kolab for real. For my test install I used the binary Kolab packages on a debian lenny system. My test installation seems just fine but is that OK or should I build from source? John From wrobel at pardus.de Sun Mar 15 10:55:49 2009 From: wrobel at pardus.de (Gunnar Wrobel) Date: Sun, 15 Mar 2009 10:55:49 +0100 Subject: Openpkg install on debian lenny In-Reply-To: <200903141825.36821.johnm@advocap.org> References: <200903141825.36821.johnm@advocap.org> Message-ID: <20090315105549.92071cbsc44lt4fc@webmail.pardus.de> Quoting John McMonagle : > I'm about to install Kolab for real. > > For my test install I used the binary Kolab packages on a debian > lenny system. > > My test installation seems just fine but is that OK or should I build from > source? That is of course okay. The source installation is only marked as default because many people run it on something else than Debian. If the binary version works fine you should continue to use it. Cheers, Gunnar > > John > > _______________________________________________ > Kolab-users mailing list > Kolab-users at kolab.org > https://kolab.org/mailman/listinfo/kolab-users > -- ______ 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. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: Digitale PGP-Unterschrift URL: From christian.tardif at servinfo.ca Mon Mar 16 05:44:43 2009 From: christian.tardif at servinfo.ca (Christian Tardif) Date: Mon, 16 Mar 2009 00:44:43 -0400 Subject: Kolab2 Integration with another running apache server Message-ID: <49BDD93B.2010300@servinfo.ca> Hi, I followed the instructions in order to make kolab (2.2.1b) running with another apache server. I'm almost done, but there's a little something missing in my config. When I try to access my kolab site, I get this: ---------------------------------------- Content Encoding Error The page you are trying to view cannot be shown because it uses an invalid or unsupported form of compression. ---------------------------------------- Anyone got this before? I don't have deflate module loaded in my apache configuration. Thanks, -- Christian.... -------------- next part -------------- An HTML attachment was scrubbed... URL: From itsef-admin at brightsight.com Mon Mar 16 12:27:45 2009 From: itsef-admin at brightsight.com (ITSEF Admin) Date: Mon, 16 Mar 2009 12:27:45 +0100 Subject: opensync/kitchensync and Kontact/Kolab? Message-ID: <200903161227.45982.itsef-admin@brightsight.com> Hi all, Is anybody out there using opensync/kitchensync to sync a mobile device with Kontact? I've started experimenting with it (Symbian S60 phone via bluetooth) and I am having mixed experiences (among other things timezones seem to be a problem) and would be curious if other people have already played with this... Cheerio, Thomas From devgioiatech at gmail.com Mon Mar 16 13:00:32 2009 From: devgioiatech at gmail.com (Antonio Straziota) Date: Mon, 16 Mar 2009 13:00:32 +0100 Subject: change maildomain on a kolab installation Message-ID: Hi all, i want to modify maildomain of a kolab installation keeping my ldap structure. I explain: I've kolab installation with and a fileserver. These two servers are integrated by samba. My server fqdn is "kolab.demo.tst" and my mail domain is "demo.tst". i need to change only maildomain to something like "everything.net". I don't want to make new bootstrap because the samba integration Is it possible? If yes, Do you have an idea? Thanks. From christian.tardif at servinfo.ca Tue Mar 17 03:10:04 2009 From: christian.tardif at servinfo.ca (Christian Tardif) Date: Mon, 16 Mar 2009 21:10:04 -0500 Subject: Kolab2 Integration with another running apache server In-Reply-To: <49BDD93B.2010300@servinfo.ca> References: <49BDD93B.2010300@servinfo.ca> Message-ID: <49BF067C.3020903@servinfo.ca> Christian Tardif wrote: > Hi, > > I followed the instructions in order to make kolab (2.2.1b) running > with another apache server. I'm almost done, but there's a little > something missing in my config. > > When I try to access my kolab site, I get this: > > ---------------------------------------- > Content Encoding Error > > The page you are trying to view cannot be shown because it uses an > invalid or unsupported form of compression. > ---------------------------------------- > > Anyone got this before? I don't have deflate module loaded in my > apache configuration. I finally found out. What I needed to do is changing, in /kolab/var/kolab/www/client/config/conf.php: $conf['compress_pages'] = true; to $conf['compress_pages'] = false; It now works perfectly. Now, I suppose that if I want to use compression, I will need to add support in the main apache server, as descriped in the wiki. -- Christian... -------------- next part -------------- An HTML attachment was scrubbed... URL: From aspineux at gmail.com Tue Mar 17 08:43:13 2009 From: aspineux at gmail.com (Alain Spineux) Date: Tue, 17 Mar 2009 08:43:13 +0100 Subject: change maildomain on a kolab installation In-Reply-To: References: Message-ID: <71fe4e760903170043t170038edrb242de936cb547ab@mail.gmail.com> On Mon, Mar 16, 2009 at 1:00 PM, Antonio Straziota wrote: > Hi all, > i want to modify maildomain of a kolab installation keeping my ldap structure. > I explain: > I've kolab installation with and a fileserver. These two servers are > integrated by samba. > My server fqdn is "kolab.demo.tst" and my mail domain is "demo.tst". > i need to change only maildomain to something like "everything.net". I > don't want to make new bootstrap because the samba integration > Is it possible? > If yes, Do you have an idea? Add the domain "everything.net" to your kolab server and create an alias in the new domain for all of your existing users in the old domain! I thing you will have to recreate distribution list ! Regards > > Thanks. > > _______________________________________________ > Kolab-users mailing list > Kolab-users at kolab.org > https://kolab.org/mailman/listinfo/kolab-users > -- Alain Spineux aspineux gmail com May the sources be with you From johnm at advocap.org Tue Mar 17 21:50:00 2009 From: johnm at advocap.org (John McMonagle) Date: Tue, 17 Mar 2009 15:50:00 -0500 Subject: gosa Message-ID: <49C00CF8.7070708@advocap.org> Any opinions on gosa and kolab? https://oss.gonicus.de/labs/gosa/wiki/PluginInstallationConnectivityKolab Gosa looks nicer than the lam I'm using but I'm concerned that gosa wants to use there own kolab schema. I can imagine some nasty possibilities. John -------------- next part -------------- A non-text attachment was scrubbed... Name: johnm.vcf Type: text/x-vcard Size: 250 bytes Desc: not available URL: From benoit.mortier at opensides.be Wed Mar 18 11:36:57 2009 From: benoit.mortier at opensides.be (Benoit Mortier) Date: Wed, 18 Mar 2009 11:36:57 +0100 Subject: gosa In-Reply-To: <49C00CF8.7070708@advocap.org> References: <49C00CF8.7070708@advocap.org> Message-ID: <200903181136.57542.benoit.mortier@opensides.be> Le Tuesday 17 March 2009 21:50:00 John McMonagle, vous avez ?crit?: > Any opinions on gosa and kolab? > > https://oss.gonicus.de/labs/gosa/wiki/PluginInstallationConnectivityKol >ab Gosa looks nicer than the lam I'm using but I'm concerned that gosa > wants to use there own kolab schema. I can imagine some nasty > possibilities. Gosa works fine with Kolab, the change in kolab2.schema is only because of problem in Kolab2.schema see kolab/issue3343 Cheers -- Benoit Mortier CEO OpenSides "logiciels libres pour entreprises" : http://www.opensides.be/ Contributor to Gosa Project : http://gosa-project.org/ From albrecht.dress at lios-tech.com Thu Mar 19 12:15:47 2009 From: albrecht.dress at lios-tech.com (Albrecht =?iso-8859-1?b?RHJl3w==?=) Date: Thu, 19 Mar 2009 12:15:47 +0100 Subject: Compile of 2.2.0 on FC9 fails Message-ID: <1237461347.6554.2@pc-adr2> Well, the subject says it all - when running "sh install-kolab.sh" I get if /usr/bin/gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I. -I.. -I../lib -I../ -I../lib -g -O2 -MT utf8.o -MD -MP -MF ".deps/utf8.Tpo" -c -o utf8.o utf8.c; \ then mv -f ".deps/utf8.Tpo" ".deps/utf8.Po"; else rm -f ".deps/utf8.Tpo"; exit 1; fi utf8.c:26:1: Warnung: >>iconv_t<< redefiniert In Datei, eingef?gt von ../lib/system.h:21, von utf8.c:19: ../config.h:1084:1: Warnung: dies ist die Stelle der vorherigen Definition /usr/bin/gcc -std=gnu99 -g -O2 -o tar buffer.o compare.o create.o delete.o extract.o xheader.o incremen.o list.o misc.o names.o sparse.o system.o tar.o transform.o update.o utf8.o ../lib/libtar.a -lrt../lib/libtar.a(argp-fmtstream.o): In function `argp_fmtstream_putc': /tmp/openpkg-20071227/tar-1.19/lib/argp-fmtstream.h:233: multiple definition of `argp_fmtstream_putc' tar.o:/tmp/openpkg-20071227/tar-1.19/src/../lib/argp-fmtstream.h:233: first defined here [more similar messages] collect2: ld gab 1 als Ende-Status zur?ck gmake[2]: *** [tar] Fehler 1 gmake[2]: Leaving directory `/tmp/openpkg-20071227/tar-1.19/src' gmake[1]: *** [all-recursive] Fehler 1 gmake[1]: Leaving directory `/tmp/openpkg-20071227/tar-1.19' gmake: *** [all] Fehler 2 Any ideas what goes wrong? TIA, Albrecht. From albrecht.dress at lios-tech.com Thu Mar 19 12:34:29 2009 From: albrecht.dress at lios-tech.com (Albrecht =?iso-8859-1?b?RHJl3w==?=) Date: Thu, 19 Mar 2009 12:34:29 +0100 Subject: Q: Using a stock OpenLDAP install as replica? Message-ID: <1237462469.6554.3@pc-adr2> Hi all, I have a dumb question whether it is possible to use a "stock" OpenLDAP installation as replica for the Kolab OpenLDAP data base. The background: Running Kolab on a 64-bit box, I am hit by issue #2982, which in turn makes (as I also use OpenLDAP for Linux/Samba Logins and for DHCP) my whole installation inoperative. My idea is to have an other box which "only" runs OpenLDAP (of course with the correct schema files) and holds a copy of the LDAP data (but nothing else). All involved instances (DHCP, Samba, maybe also Kolab) would get this installation as secondary servers which are used as fallback in case the primary fails. The secondary box could be an old (32-bit ;-) box as it wouldn't see much traffic in the normal case. Any idea if this would be feasible? Any pointer/howto? TIA, Albrecht. From ml at radoeka.nl Thu Mar 19 13:11:28 2009 From: ml at radoeka.nl (Richard Bos) Date: Thu, 19 Mar 2009 13:11:28 +0100 Subject: Compile of 2.2.0 on FC9 fails In-Reply-To: <1237461347.6554.2@pc-adr2> References: <1237461347.6554.2@pc-adr2> Message-ID: <20090319121128.GA2561@xs4all.nl> On Thu, Mar 19, 2009 at 12:15:47PM +0100, Albrecht Dre? wrote: > Well, the subject says it all - when running "sh install-kolab.sh" I get > > > if /usr/bin/gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I. -I.. -I../lib -I../ > -I../lib -g -O2 -MT utf8.o -MD -MP -MF ".deps/utf8.Tpo" -c -o utf8.o > utf8.c; \ > then mv -f ".deps/utf8.Tpo" ".deps/utf8.Po"; else rm -f > ".deps/utf8.Tpo"; exit 1; fi > utf8.c:26:1: Warnung: >>iconv_t<< redefiniert > In Datei, eingef?gt von ../lib/system.h:21, > von utf8.c:19: > ../config.h:1084:1: Warnung: dies ist die Stelle der vorherigen > Definition > /usr/bin/gcc -std=gnu99 -g -O2 -o tar buffer.o compare.o create.o > delete.o extract.o xheader.o incremen.o list.o misc.o names.o sparse.o > system.o tar.o transform.o update.o utf8.o ../lib/libtar.a > -lrt../lib/libtar.a(argp-fmtstream.o): In function > `argp_fmtstream_putc': > /tmp/openpkg-20071227/tar-1.19/lib/argp-fmtstream.h:233: multiple > definition of `argp_fmtstream_putc' > tar.o:/tmp/openpkg-20071227/tar-1.19/src/../lib/argp-fmtstream.h:233: > first defined here > [more similar messages] > collect2: ld gab 1 als Ende-Status zur?ck > gmake[2]: *** [tar] Fehler 1 > gmake[2]: Leaving directory `/tmp/openpkg-20071227/tar-1.19/src' > gmake[1]: *** [all-recursive] Fehler 1 > gmake[1]: Leaving directory `/tmp/openpkg-20071227/tar-1.19' > gmake: *** [all] Fehler 2 > > > Any ideas what goes wrong? You're using a gcc 4.3 or newer. Install an older gcc version and that will do it. This is also mentioned in the trouble shooting section of the release notes. You have to link gcc and cc to the "older gcc" executable. -- Richard From alex at swiftnetcomputers.biz Thu Mar 19 13:49:10 2009 From: alex at swiftnetcomputers.biz (Alex Chejlyk) Date: Thu, 19 Mar 2009 08:49:10 -0400 Subject: Q: Using a stock OpenLDAP install as replica? In-Reply-To: <1237462469.6554.3@pc-adr2> References: <1237462469.6554.3@pc-adr2> Message-ID: <49C23F46.7010506@swiftnetcomputers.biz> Albrecht Dre? wrote: > Hi all, > > I have a dumb question whether it is possible to use a "stock" OpenLDAP > installation as replica for the Kolab OpenLDAP data base. The > background: Running Kolab on a 64-bit box, I am hit by issue #2982, > which in turn makes (as I also use OpenLDAP for Linux/Samba Logins and > for DHCP) my whole installation inoperative. > > My idea is to have an other box which "only" runs OpenLDAP (of course > with the correct schema files) and holds a copy of the LDAP data (but > nothing else). All involved instances (DHCP, Samba, maybe also Kolab) > would get this installation as secondary servers which are used as > fallback in case the primary fails. The secondary box could be an old > (32-bit ;-) box as it wouldn't see much traffic in the normal case. > > Any idea if this would be feasible? Any pointer/howto? > > TIA, Albrecht. > > _______________________________________________ > Kolab-users mailing list > Kolab-users at kolab.org > https://kolab.org/mailman/listinfo/kolab-users > This is not an answer to your question. I was wondering if you thought about running Kolab in a KVM guest? That is how I deploy Kolab for all of my clients. Before KVM I used VMware. This would allow you to run Kolab on the same iron you are currently using...just a thought. Cheers, Alex C. From albrecht.dress at lios-tech.com Thu Mar 19 14:09:49 2009 From: albrecht.dress at lios-tech.com (Albrecht =?iso-8859-1?b?RHJl3w==?=) Date: Thu, 19 Mar 2009 14:09:49 +0100 Subject: Compile of 2.2.0 on FC9 fails In-Reply-To: <20090319121128.GA2561@xs4all.nl> (from ml@radoeka.nl on Thu Mar 19 13:11:28 2009) References: <1237461347.6554.2@pc-adr2> <20090319121128.GA2561@xs4all.nl> Message-ID: <1237468189.6554.4@pc-adr2> Am 19.03.2009 13:11:28 schrieb(en) Richard Bos: > You're using a gcc 4.3 or newer. Install an older gcc version and > that will do it. Ah! Yes, FC9 comes with gcc 4.3.0... > This is also mentioned in the trouble shooting section of the release > notes. Unfortunately *not* in the readme.1st of 2.2.0, only in the one of 2.2.1rc1... ;-) Maybe it's still worth to add it to the 2.2.0 file, even if 2.2.1 will be released soon (I hope)? Thanks, Albrecht. From tomas.andersson at heatex.com Thu Mar 19 14:41:43 2009 From: tomas.andersson at heatex.com (Tomas Andersson) Date: Thu, 19 Mar 2009 14:41:43 +0100 Subject: FreeBusy Message-ID: <003a01c9a898$70d89fb0$5289df10$@andersson@heatex.com> Is there a way to use the FreeBusy function in outlook 2003,2007 without using connectors? Mvh / Meilleures salutations / Best regards / MFG, Tomas Andersson IT Administrator Heatex AB Tel.: + 46 410 710 554 Fax : + 46 410 710 529 Mob : + 46 702 772 597 Email : tomas.andersson at heatex.com Internet: www.heatex.com DISCLAIMER: 'The information contained in this email and any attachment is confidential. It is intended only for the named addressee(s). If you are not the named addressee please notify the sender immediately and do not disclose, copy or distribute the contents to any other person other than the intended addressee(s).' -------------- next part -------------- An HTML attachment was scrubbed... URL: From tomas.andersson at heatex.com Thu Mar 19 14:50:48 2009 From: tomas.andersson at heatex.com (Tomas Andersson) Date: Thu, 19 Mar 2009 14:50:48 +0100 Subject: new accounts Message-ID: <005c01c9a899$b5b1f090$2115d1b0$@andersson@heatex.com> Is there a way to script the creation of new emailaccounts? Mvh / Meilleures salutations / Best regards / MFG, Tomas Andersson IT Administrator Heatex AB Tel.: + 46 410 710 554 Fax : + 46 410 710 529 Mob : + 46 702 772 597 Email : tomas.andersson at heatex.com Internet: www.heatex.com DISCLAIMER: 'The information contained in this email and any attachment is confidential. It is intended only for the named addressee(s). If you are not the named addressee please notify the sender immediately and do not disclose, copy or distribute the contents to any other person other than the intended addressee(s).' -------------- next part -------------- An HTML attachment was scrubbed... URL: From tomas.andersson at heatex.com Thu Mar 19 16:02:08 2009 From: tomas.andersson at heatex.com (Tomas Andersson) Date: Thu, 19 Mar 2009 16:02:08 +0100 Subject: freebusy Message-ID: <000001c9a8a3$acbec990$063c5cb0$@andersson@heatex.com> Freebusy.log says Whats wrong March 19 16:00:31 freebusy[11364]: Debug: ---FreeBusy Script starting (/freebusy/tomas.andersson at heatex.com.xfb)--- March 19 16:00:31 freebusy[11364]: Debug: user=tomas.andersson at heatex.com, imapuser=tomas.andersson at heatex.com, req_cache=, req_extended=1 March 19 16:00:31 freebusy[11364]: Debug: FreeBusyLDAP::distlists( cn=Tomas Andersson,dc=heatex,dc=com ) found 2 entries March 19 16:00:31 freebusy[11364]: Error: Mvh / Meilleures salutations / Best regards / MFG, Tomas Andersson IT Administrator Heatex AB Tel.: + 46 410 710 554 Fax : + 46 410 710 529 Mob : + 46 702 772 597 Email : tomas.andersson at heatex.com Internet: www.heatex.com DISCLAIMER: 'The information contained in this email and any attachment is confidential. It is intended only for the named addressee(s). If you are not the named addressee please notify the sender immediately and do not disclose, copy or distribute the contents to any other person other than the intended addressee(s).' -------------- next part -------------- An HTML attachment was scrubbed... URL: From wrobel at pardus.de Fri Mar 20 05:23:40 2009 From: wrobel at pardus.de (Gunnar Wrobel) Date: Fri, 20 Mar 2009 05:23:40 +0100 Subject: freebusy In-Reply-To: <000001c9a8a3$acbec990$063c5cb0$@andersson@heatex.com> References: <000001c9a8a3$acbec990$063c5cb0$@andersson@heatex.com> Message-ID: <20090320052340.14557akm2w02krk0@webmail.pardus.de> Hi Tomas, Quoting Tomas Andersson : > > > Freebusy.log says > > Whats wrong Could you provide details on what type of log you provided? Where does it originate from? Which client (+ version) did you use? Which server (+version)? http://wiki.kolab.org/index.php/Problem_reporting#Using_the_mailing_lists Cheers, Gunnar > > March 19 16:00:31 freebusy[11364]: Debug: > ---FreeBusy Script starting > (/freebusy/tomas.andersson at heatex.com.xfb)--- > > March 19 16:00:31 freebusy[11364]: Debug: > user=tomas.andersson at heatex.com, > imapuser=tomas.andersson at heatex.com, req_cache=, > req_extended=1 > > March 19 16:00:31 freebusy[11364]: Debug: > FreeBusyLDAP::distlists( cn=Tomas Andersson,dc=heatex,dc=com ) found > 2 entries > > March 19 16:00:31 freebusy[11364]: Error: > > Mvh / Meilleures salutations / Best regards / MFG, > > > Tomas Andersson > > IT Administrator > > Heatex AB > > Tel.: + 46 410 710 554 > > Fax : + 46 410 710 529 > > Mob : + 46 702 772 597 > > Email : style='color:blue'>tomas.andersson at heatex.com[1] > > Internet: style='color:blue'>www.heatex.com[2] DISCLAIMER: 'The > information contained in this > email and any attachment is confidential. It is intended only for > the named addressee(s). If you are not the named addressee please > notify the sender immediately and do not disclose, copy or > distribute the contents to any other person other than the intended > addressee(s).' > > -- ____ http://www.pardus.de[3] _________________ http://gunnarwrobel.de[4] _ 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 << -------------------------------------------------------------------- Links: ------ [1] mailto:tomas.andersson at heatex.com [2] http://www.heatex.com [3] http://www.pardus.de [4] http://gunnarwrobel.de ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. From wrobel at pardus.de Fri Mar 20 05:27:43 2009 From: wrobel at pardus.de (Gunnar Wrobel) Date: Fri, 20 Mar 2009 05:27:43 +0100 Subject: new accounts In-Reply-To: <005c01c9a899$b5b1f090$2115d1b0$@andersson@heatex.com> References: <005c01c9a899$b5b1f090$2115d1b0$@andersson@heatex.com> Message-ID: <20090320052743.18861ppxfu1e2f6s@webmail.pardus.de> Quoting Tomas Andersson : > Is there a way to script the creation of new > emailaccounts? See /kolab/bin/kolab --help Cheers, Gunnar > > Mvh / Meilleures salutations / Best regards / > MFG, Tomas Andersson IT Administrator Heatex AB Tel.: + 46 410 > 710 554 Fax : + 46 410 710 529 Mob : + 46 702 772 597 Email : > blue;\\">tomas.andersson at heatex.com[1] Internet: > blue;\\">www.heatex.com[2] DISCLAIMER: 'The information contained > in this > email and any attachment is confidential. It is intended only for > the named addressee(s). If you are not the named addressee please > notify the sender immediately and do not disclose, copy or > distribute the contents to any other person other than the intended > addressee(s).' -- ______ 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 << -------------------------------------------------------------------- Links: ------ [1] mailto:tomas.andersson at heatex.com [2] http://www.heatex.com ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: Digitale PGP-Unterschrift URL: From wrobel at pardus.de Fri Mar 20 05:32:04 2009 From: wrobel at pardus.de (Gunnar Wrobel) Date: Fri, 20 Mar 2009 05:32:04 +0100 Subject: Q: Using a stock OpenLDAP install as replica? In-Reply-To: <1237462469.6554.3@pc-adr2> References: <1237462469.6554.3@pc-adr2> Message-ID: <20090320053204.55387dzg2mavb6f4@webmail.pardus.de> Quoting Albrecht Dre? : > Hi all, > > I have a dumb question whether it is possible to use a "stock" OpenLDAP > installation as replica for the Kolab OpenLDAP data base. The > background: Running Kolab on a 64-bit box, I am hit by issue #2982, > which in turn makes (as I also use OpenLDAP for Linux/Samba Logins and > for DHCP) my whole installation inoperative. > > My idea is to have an other box which "only" runs OpenLDAP (of course > with the correct schema files) and holds a copy of the LDAP data (but > nothing else). All involved instances (DHCP, Samba, maybe also Kolab) > would get this installation as secondary servers which are used as > fallback in case the primary fails. The secondary box could be an old > (32-bit ;-) box as it wouldn't see much traffic in the normal case. > > Any idea if this would be feasible? Any pointer/howto? As we don't patch/modify the OpenLDAP on the Kolab Server in any way I think this should be no problem. Did you wish to install the 32-bit machine as full Kolab server? If so, you might just adapt the LDAP server location in kolab.conf in the main 64-bit host. This might already work. Cheers, Gunnar > > TIA, Albrecht. > > _______________________________________________ > Kolab-users mailing list > Kolab-users at kolab.org > https://kolab.org/mailman/listinfo/kolab-users > -- ______ 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. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: Digitale PGP-Unterschrift URL: From wrobel at pardus.de Fri Mar 20 05:42:46 2009 From: wrobel at pardus.de (Gunnar Wrobel) Date: Fri, 20 Mar 2009 05:42:46 +0100 Subject: gosa In-Reply-To: <49C00CF8.7070708@advocap.org> References: <49C00CF8.7070708@advocap.org> Message-ID: <20090320054246.786122ozqs7entgk@webmail.pardus.de> Quoting John McMonagle : > Any opinions on gosa and kolab? > > https://oss.gonicus.de/labs/gosa/wiki/PluginInstallationConnectivityKolab > Gosa looks nicer than the lam I'm using but I'm concerned that gosa > wants to use there own kolab schema. I can imagine some nasty > possibilities. I know that some people are using gosa successfully but I believe you need to be pretty familiar with the Kolab server to get around some of the quirks. Of course the Kolab Konsortium does not recommend it for production servers. Cheers, Gunnar > > John > > > -- ____ 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 christian.tardif at servinfo.ca Fri Mar 20 05:59:12 2009 From: christian.tardif at servinfo.ca (Christian Tardif) Date: Fri, 20 Mar 2009 00:59:12 -0400 Subject: Syncml (Kolab 2.2.1 rc1) Message-ID: <49C322A0.2000107@servinfo.ca> Hello, I noticed one thing. Syncml refuses to sync at all when Kolab sits behind an apache webserver (using redirection and proxy as described in the wiki). But it works if I point syncml directly to port 81. Any idea why and how to solve it (it's not a big problem, since it can work anyway). The problem would be different if the Kolab server sits in a protected zone, unaccessible directly from the Net, though. OK, so I can sync. But what, exactly? The server path, for addressbook, is set to contacts. It syncs back and forth. Nice. But I can't seem to make the calendar sync (using calendar as serverpath, as described in http://wiki.horde.org/SyncHowTo. No error. It just not syncs. Oh! The only 30 days before..... thing has been unchecked. Any cue on this one? Thanks, -- Christian... -------------- next part -------------- An HTML attachment was scrubbed... URL: From j.hylkema at intronics.nl Fri Mar 20 08:36:59 2009 From: j.hylkema at intronics.nl (Jacques Hylkema) Date: Fri, 20 Mar 2009 08:36:59 +0100 Subject: Kolab + EGroupware integration Message-ID: <49C3479B.1050304@intronics.nl> Hi, I'm trying to integrate EGroupware with kolab's LDAP, but I can't get it right. Is there anyone on this list who has successfully integrated EGroupware with Kolab, and willing to share some details? One (maybe important) detail: EGroupware is installed on a separate server (not the Kolab server) Versions: EGroupware 1.6.001 Kolab: Kolab2 Groupware Server Version 2.2.0 Kolab2 Groupware Server Component Versions amavisd: 2.5.3-20080101 apache: 2.2.8-20080118 clamav: 0.93.3-20080708 imapd: 2.3.11-20080101_kolab4 kolab-filter: 2.2.0-20080709 kolab-freebusy: 2.2.0-20080709 kolab-webadmin: 2.2.0-20080709 kolabconf: 2.2.0-20080709 kolabd: 2.2.0-20080709 openldap: 2.3.41-20080424 perl-kolab: 2.2.0-20080709 php-kolab: 2.2.0-20080711 postfix: 2.4.6-20080101_kolab spamassassin: 3.2.4-20080107 ______________________________________________________________________________________ This outbound message from Intronics B.V. has been checked for all known viruses by KPN MailScan (IV-Scan), powered by MessageLabs. ______________________________________________________________________________________ From albrecht.dress at lios-tech.com Fri Mar 20 09:18:07 2009 From: albrecht.dress at lios-tech.com (Albrecht =?iso-8859-1?b?RHJl3w==?=) Date: Fri, 20 Mar 2009 09:18:07 +0100 Subject: Q: Using a stock OpenLDAP install as replica? In-Reply-To: <20090320053204.55387dzg2mavb6f4@webmail.pardus.de> (from wrobel@pardus.de on Fri Mar 20 05:32:04 2009) Message-ID: <1237537087.7381.0@pc-adr2> Am 20.03.2009 05:32:04 schrieb(en) Gunnar Wrobel: > As we don't patch/modify the OpenLDAP on the Kolab Server in any way > I think this should be no problem. Ah, that's good! > Did you wish to install the 32-bit machine as full Kolab server? If > so, you might just adapt the LDAP server location in kolab.conf in > the main 64-bit host. This might already work. I would actually prefer not to install the whole Kolab (as describen in the manual), as we currently only serve ~35 accounts. My intention is just to have a fallback if OpenLDAP from Kolab 2.2.0 on the 64-bit Hardy box goes wild. The smallest possible effort would of course to just install the openldap server coming with the (Ubuntu, FC, whatever) disto, tweak the slapd.conf from kolab, and go ahead. However, apparently all up-to-date distos come with OpenLDAP 2.4 these days, and there the replication mechanism has changed from slurpd to syncrepl. I couldn't figure out yet if and how they are compatible... So maybe I should actually have a full Kolab slave install unless I figure that out. Anyway, if anyone has more insight into that, any pointer would be really appreciated! Thanks, Albrecht. From wrobel at pardus.de Fri Mar 20 09:46:41 2009 From: wrobel at pardus.de (Gunnar Wrobel) Date: Fri, 20 Mar 2009 09:46:41 +0100 Subject: Q: Using a stock OpenLDAP install as replica? In-Reply-To: <1237537087.7381.0@pc-adr2> References: <1237537087.7381.0@pc-adr2> Message-ID: <20090320094641.14392a3mg52jlxj4@webmail.pardus.de> Quoting Albrecht Dre? : > Am 20.03.2009 05:32:04 schrieb(en) Gunnar Wrobel: >> As we don't patch/modify the OpenLDAP on the Kolab Server in any way >> I think this should be no problem. > > Ah, that's good! > >> Did you wish to install the 32-bit machine as full Kolab server? If >> so, you might just adapt the LDAP server location in kolab.conf in >> the main 64-bit host. This might already work. > > I would actually prefer not to install the whole Kolab (as describen in > the manual), as we currently only serve ~35 accounts. My intention is > just to have a fallback if OpenLDAP from Kolab 2.2.0 on the 64-bit > Hardy box goes wild. The smallest possible effort would of course to > just install the openldap server coming with the (Ubuntu, FC, whatever) > disto, tweak the slapd.conf from kolab, and go ahead. > > However, apparently all up-to-date distos come with OpenLDAP 2.4 these > days, and there the replication mechanism has changed from slurpd to > syncrepl. I couldn't figure out yet if and how they are compatible... Not at all. You use either 2.3 or 2.4. We'll probably switch to OpenLDAP-2.4 with Kolab-Server-2.2.2. > So maybe I should actually have a full Kolab slave install unless I > figure that out. I believe it is the quickest way as you do not have any hassle with the configuration. Cheers, Gunnar > Anyway, if anyone has more insight into that, any > pointer would be really appreciated! > > Thanks, Albrecht. > > _______________________________________________ > Kolab-users mailing list > Kolab-users at kolab.org > https://kolab.org/mailman/listinfo/kolab-users > -- ______ 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 Mar 20 09:55:45 2009 From: wrobel at pardus.de (Gunnar Wrobel) Date: Fri, 20 Mar 2009 09:55:45 +0100 Subject: Kolab + EGroupware integration In-Reply-To: <49C3479B.1050304@intronics.nl> References: <49C3479B.1050304@intronics.nl> Message-ID: <20090320095545.30776oif7ec2fl0k@webmail.pardus.de> Quoting Jacques Hylkema : > Hi, > > I'm trying to integrate EGroupware with kolab's LDAP, but I can't get it > right. > Is there anyone on this list who has successfully integrated EGroupware > with Kolab, and willing to share some details? I don't know if anybody tried that yet. But you might wish to give us some additional details about the configuration you are trying to use to access the Kolab LDAP database. While there are probably not many people using EGroupware with Kolab we might be able to spot problems in the LDAP configuration. In general I don't think it makes much sense to use EGroupware with Kolab at the moment. You can of course use the mail (IMAP) and addressbook (LDAP) capabilities of the EGroupware suite with Kolab. But as far as I know - I did not check the Egroupware sources lately though - EGroupware does not support the Kolab format for groupware objects. This means you can't access your personal addressbook, calendar, notepad and task list on the Kolab server. Of course you have your SQL based data but this means you won't have the possibility to access the groupware data with any other Kolab client such as Kontact or Outlook with a connector. EGroupware could of course grab the Horde/Kolab packages and adapt them to their storage needs. They already did so with some other Horde packages. Cheers, Gunnar > One (maybe important) detail: EGroupware is installed on a separate > server (not the Kolab server) > > Versions: > > EGroupware 1.6.001 > > Kolab: > Kolab2 Groupware Server Version > 2.2.0 > Kolab2 Groupware Server Component Versions > amavisd: 2.5.3-20080101 > apache: 2.2.8-20080118 > clamav: 0.93.3-20080708 > imapd: 2.3.11-20080101_kolab4 > kolab-filter: 2.2.0-20080709 > kolab-freebusy: 2.2.0-20080709 > kolab-webadmin: 2.2.0-20080709 > kolabconf: 2.2.0-20080709 > kolabd: 2.2.0-20080709 > openldap: 2.3.41-20080424 > perl-kolab: 2.2.0-20080709 > php-kolab: 2.2.0-20080711 > postfix: 2.4.6-20080101_kolab > spamassassin: 3.2.4-20080107 > > > > ______________________________________________________________________________________ > This outbound message from Intronics B.V. has been checked for all known > viruses by KPN MailScan (IV-Scan), powered by MessageLabs. > ______________________________________________________________________________________ > > _______________________________________________ > Kolab-users mailing list > Kolab-users at kolab.org > https://kolab.org/mailman/listinfo/kolab-users > -- ______ 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. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: Digitale PGP-Unterschrift URL: From mario at hummy.org Fri Mar 20 10:47:28 2009 From: mario at hummy.org (Mario Ramos) Date: Fri, 20 Mar 2009 10:47:28 +0100 Subject: Kolab + EGroupware integration In-Reply-To: <49C3479B.1050304@intronics.nl> References: <49C3479B.1050304@intronics.nl> Message-ID: Hi. Gettting the LDAP authentication to work is not difficult, but as far as I remember, it's not possible to integrate the addressbook or calendar. Maybe someone else has more experience with this. Regards. Mario. 2009/3/20 Jacques Hylkema > Hi, > > I'm trying to integrate EGroupware with kolab's LDAP, but I can't get it > right. > Is there anyone on this list who has successfully integrated EGroupware > with Kolab, and willing to share some details? > One (maybe important) detail: EGroupware is installed on a separate > server (not the Kolab server) > > Versions: > > EGroupware 1.6.001 > > Kolab: > Kolab2 Groupware Server Version > 2.2.0 > Kolab2 Groupware Server Component Versions > amavisd: 2.5.3-20080101 > apache: 2.2.8-20080118 > clamav: 0.93.3-20080708 > imapd: 2.3.11-20080101_kolab4 > kolab-filter: 2.2.0-20080709 > kolab-freebusy: 2.2.0-20080709 > kolab-webadmin: 2.2.0-20080709 > kolabconf: 2.2.0-20080709 > kolabd: 2.2.0-20080709 > openldap: 2.3.41-20080424 > perl-kolab: 2.2.0-20080709 > php-kolab: 2.2.0-20080711 > postfix: 2.4.6-20080101_kolab > spamassassin: 3.2.4-20080107 > > > > > ______________________________________________________________________________________ > This outbound message from Intronics B.V. has been checked for all known > viruses by KPN MailScan (IV-Scan), powered by MessageLabs. > > ______________________________________________________________________________________ > > _______________________________________________ > Kolab-users mailing list > Kolab-users at kolab.org > https://kolab.org/mailman/listinfo/kolab-users > -- PS ? Please help preserve the environment, don?t print this email unless you have to. -------------- next part -------------- An HTML attachment was scrubbed... URL: From benoit.mortier at opensides.be Fri Mar 20 11:06:39 2009 From: benoit.mortier at opensides.be (Benoit Mortier) Date: Fri, 20 Mar 2009 11:06:39 +0100 Subject: gosa In-Reply-To: <20090320054246.786122ozqs7entgk@webmail.pardus.de> References: <49C00CF8.7070708@advocap.org> <20090320054246.786122ozqs7entgk@webmail.pardus.de> Message-ID: <200903201106.39783.benoit.mortier@opensides.be> Le Friday 20 March 2009 05:42:46 Gunnar Wrobel, vous avez ?crit?: > Quoting John McMonagle : > > Any opinions on gosa and kolab? > > > > https://oss.gonicus.de/labs/gosa/wiki/PluginInstallationConnectivityK > >olab Gosa looks nicer than the lam I'm using but I'm concerned that > > gosa wants to use there own kolab schema. I can imagine some nasty > > possibilities. > > I know that some people are using gosa successfully but I believe you > need to be pretty familiar with the Kolab server to get around some of > the quirks. Of course the Kolab Konsortium does not recommend it for > production servers. Sorry Gunar, but i can not let you said that, the integration works well but the quirks are on kolab side ... And i work well in production server with the benefit of giving you a decent web interface to manage users Have a nice day -- Benoit Mortier CEO OpenSides "logiciels libres pour entreprises" : http://www.opensides.be/ Contributor to Gosa Project : http://gosa-project.org/ From j.hylkema at intronics.nl Fri Mar 20 13:27:58 2009 From: j.hylkema at intronics.nl (Jacques Hylkema) Date: Fri, 20 Mar 2009 13:27:58 +0100 Subject: Kolab + EGroupware integration In-Reply-To: <20090320095545.30776oif7ec2fl0k@webmail.pardus.de> References: <49C3479B.1050304@intronics.nl> <20090320095545.30776oif7ec2fl0k@webmail.pardus.de> Message-ID: <49C38BCE.2050605@intronics.nl> Gunnar Wrobel schreef: > Quoting Jacques Hylkema : > >> Hi, >> >> I'm trying to integrate EGroupware with kolab's LDAP, but I can't get it >> right. >> Is there anyone on this list who has successfully integrated EGroupware >> with Kolab, and willing to share some details? > > I don't know if anybody tried that yet. But you might wish to give us > some additional details about the configuration you are trying to use > to access the Kolab LDAP database. While there are probably not many > people using EGroupware with Kolab we might be able to spot problems > in the LDAP configuration. > > In general I don't think it makes much sense to use EGroupware with > Kolab at the moment. You can of course use the mail (IMAP) and > addressbook (LDAP) capabilities of the EGroupware suite with Kolab. > But as far as I know - I did not check the Egroupware sources lately > though - EGroupware does not support the Kolab format for groupware > objects. This means you can't access your personal addressbook, > calendar, notepad and task list on the Kolab server. Of course you > have your SQL based data but this means you won't have the possibility > to access the groupware data with any other Kolab client such as > Kontact or Outlook with a connector. > > EGroupware could of course grab the Horde/Kolab packages and adapt > them to their storage needs. They already did so with some other Horde > packages. > > Cheers, > > Gunnar > Hi Gunnar, Thanks for your response. I'm using Kolab mainly for email. Client is Mozilla Thunderbird. We want to use EGroupware for group calendars, project management, wiki etc. Offcourse I can create a completely stand-alone version based on SQL, which means I have to manage separate user accounts (about 50) for email (Kolab) and EGroupware. I would like to prevent that. As far as the LDAP configuration of EGroupware, I don't have any idea what I have to use. Best regards, Jacques ______________________________________________________________________________________ This outbound message from Intronics B.V. has been checked for all known viruses by KPN MailScan (IV-Scan), powered by MessageLabs. ______________________________________________________________________________________ From j.hylkema at intronics.nl Fri Mar 20 13:31:47 2009 From: j.hylkema at intronics.nl (Jacques Hylkema) Date: Fri, 20 Mar 2009 13:31:47 +0100 Subject: Kolab + EGroupware integration In-Reply-To: References: <49C3479B.1050304@intronics.nl> Message-ID: <49C38CB3.5000301@intronics.nl> Mario Ramos schreef: > Hi. > > Gettting the LDAP authentication to work is not difficult, but as far > as I remember, it's not possible to integrate the addressbook or calendar. > Do you have a howto I could follow? I searched google, and could not find any regarding EGroupware / Kolab integration. Thanks, Jacques > Maybe someone else has more experience with this. > > Regards. > Mario. > > 2009/3/20 Jacques Hylkema > > > Hi, > > I'm trying to integrate EGroupware with kolab's LDAP, but I can't > get it > right. > Is there anyone on this list who has successfully integrated > EGroupware > with Kolab, and willing to share some details? > One (maybe important) detail: EGroupware is installed on a separate > server (not the Kolab server) > > Versions: > > EGroupware 1.6.001 > > Kolab: > Kolab2 Groupware Server Version > 2.2.0 > > ______________________________________________________________________________________ This outbound message from Intronics B.V. has been checked for all known viruses by KPN MailScan (IV-Scan), powered by MessageLabs. ______________________________________________________________________________________ -------------- next part -------------- An HTML attachment was scrubbed... URL: From johnm at advocap.org Fri Mar 20 19:18:27 2009 From: johnm at advocap.org (John McMonagle) Date: Fri, 20 Mar 2009 13:18:27 -0500 Subject: gosa In-Reply-To: <200903201106.39783.benoit.mortier@opensides.be> References: <49C00CF8.7070708@advocap.org> <20090320054246.786122ozqs7entgk@webmail.pardus.de> <200903201106.39783.benoit.mortier@opensides.be> Message-ID: <200903201318.27840.johnm@advocap.org> On Friday 20 March 2009 05:06:39 am Benoit Mortier wrote: > Le Friday 20 March 2009 05:42:46 Gunnar Wrobel, vous avez ?crit?: > > Quoting John McMonagle : > > > Any opinions on gosa and kolab? > > > > > > https://oss.gonicus.de/labs/gosa/wiki/PluginInstallationConnectivityK > > >olab Gosa looks nicer than the lam I'm using but I'm concerned that > > > gosa wants to use there own kolab schema. I can imagine some nasty > > > possibilities. > > > > I know that some people are using gosa successfully but I believe you > > need to be pretty familiar with the Kolab server to get around some of > > the quirks. Of course the Kolab Konsortium does not recommend it for > > production servers. > > Sorry Gunar, but i can not let you said that, the integration works well > but the quirks are on kolab side ... > > And i work well in production server with the benefit of giving you a > decent web interface to manage users > > Have a nice day Benoit Is there anything you need to do other then adding the needed gosa schemas and using the kolab schema from gosa? I'll need to to a lot of tweeking to ldap anyway. At the moment working on my ldap conversion strategy. Have 6 ldap servers not counting kolab. At the moment breaking kolab is the least of my concerns :-) John From benoit.mortier at opensides.be Fri Mar 20 19:41:40 2009 From: benoit.mortier at opensides.be (Benoit Mortier) Date: Fri, 20 Mar 2009 19:41:40 +0100 Subject: gosa In-Reply-To: <200903201318.27840.johnm@advocap.org> References: <49C00CF8.7070708@advocap.org> <200903201106.39783.benoit.mortier@opensides.be> <200903201318.27840.johnm@advocap.org> Message-ID: <200903201941.41126.benoit.mortier@opensides.be> Le Friday 20 March 2009 19:18:27 John McMonagle, vous avez ?crit?: > On Friday 20 March 2009 05:06:39 am Benoit Mortier wrote: > > Le Friday 20 March 2009 05:42:46 Gunnar Wrobel, vous avez ?crit?: > > > Quoting John McMonagle : > > > > Any opinions on gosa and kolab? > > > > > > > > https://oss.gonicus.de/labs/gosa/wiki/PluginInstallationConnectiv > > > >ityK olab Gosa looks nicer than the lam I'm using but I'm > > > > concerned that gosa wants to use there own kolab schema. I can > > > > imagine some nasty possibilities. > > > > > > I know that some people are using gosa successfully but I believe > > > you need to be pretty familiar with the Kolab server to get around > > > some of the quirks. Of course the Kolab Konsortium does not > > > recommend it for production servers. > > > > Sorry Gunar, but i can not let you said that, the integration works > > well but the quirks are on kolab side ... > > > > And i work well in production server with the benefit of giving you a > > decent web interface to manage users > > > > Have a nice day > > Benoit > > Is there anything you need to do other then adding the needed gosa > schemas and using the kolab schema from gosa? - some import of specific objects from kolab ldap to the your ldap if you don't use the ldap server from kolab, mainly the manager and other special users. - some change to the template and / or files to tell him where the ldap reside if not using kolab ldap. other than that it should roll I have to make a new install start of april will try to put some explanations in the wiki. > I'll need to to a lot of tweeking to ldap anyway. > At the moment working on my ldap conversion strategy. > Have 6 ldap servers not counting kolab. > At the moment breaking kolab is the least of my concerns :-) Sure Have a nice evening -- Benoit Mortier CEO OpenSides "logiciels libres pour entreprises" : http://www.opensides.be/ Contributor to Gosa Project : http://gosa-project.org/ From johnm at advocap.org Fri Mar 20 21:17:47 2009 From: johnm at advocap.org (John McMonagle) Date: Fri, 20 Mar 2009 15:17:47 -0500 Subject: gosa In-Reply-To: <200903201941.41126.benoit.mortier@opensides.be> References: <49C00CF8.7070708@advocap.org> <200903201318.27840.johnm@advocap.org> <200903201941.41126.benoit.mortier@opensides.be> Message-ID: <200903201517.47792.johnm@advocap.org> On Friday 20 March 2009 01:41:40 pm Benoit Mortier wrote: > Le Friday 20 March 2009 19:18:27 John McMonagle, vous avez ?crit?: > > On Friday 20 March 2009 05:06:39 am Benoit Mortier wrote: > > > Le Friday 20 March 2009 05:42:46 Gunnar Wrobel, vous avez ?crit?: > > > > Quoting John McMonagle : > > > > > Any opinions on gosa and kolab? > > > > > > > - some import of specific objects from kolab ldap to the your ldap if you > don't use the ldap server from kolab, mainly the manager and other > special users. >> - some change to the template and / or files to tell him where the ldap > reside if not using kolab ldap. > > other than that it should roll > Thanks Not really gosa issues but brings up a couple more issues. I wonder what kind of issues there will be with upgrades if the kolab server is not the ldap master? Some of my sites have poor network connections and slurpd replication doesn't work well. Don't want to consider using slurpd again. I can think of 4 possible ways to do the ldap for kolab. 1 Use kolab openpkg ldap as master adding sync replication. 2 Use kolab openpkg ldap as sync replication slave. 3 Use openldap install on kolab host as sync replication slave. Disable openpkg ldap. 4 Use openldap server on the local network. Disable openpkg ldap. At the moment my preference is 3,4,2,1. What problems are there going to be during upgrades? The biggest thing I can see is any schema and acl changes may need to be manually made through the system first. As schemacheck is on could be an issue on a pure openpkg system with multiple kolab servers. John > I have to make a new install start of april will try to put some > explanations in the wiki. > > > I'll need to to a lot of tweeking to ldap anyway. > > At the moment working on my ldap conversion strategy. > > Have 6 ldap servers not counting kolab. > > At the moment breaking kolab is the least of my concerns :-) > > Sure > > Have a nice evening From thomas at btspuhler.com Sun Mar 22 05:42:59 2009 From: thomas at btspuhler.com (Thomas Spuhler) Date: Sat, 21 Mar 2009 21:42:59 -0700 Subject: kolab on openSUSE natively is a little bit back In-Reply-To: <200903092121.20031.ml@radoeka.nl> References: <200902142107.48113.ml@radoeka.nl> <200903081802.57794.thomas@btspuhler.com> <200903092121.20031.ml@radoeka.nl> Message-ID: <200903212142.59682.thomas@btspuhler.com> On Monday 09 March 2009, Richard Bos wrote: > Op maandag 09 maart 2009 02:02:57 schreef Thomas Spuhler: > > > The big difference between kolab on openSUSE 10.3 and 11.1 will be the > > > openldap replication mode. This must change from slurpd to syncrepl. > > > This is working nicely. The data does not need to change I believe, > > > so as long as all data is backed up you should be fine. > > > > Can you please provide the slapd.conf.template file for the Syncrepl > > implementation? > > You can get it from cvs: > http://kolab.org/cgi-bin/viewcvs-kolab.cgi/server/kolabd/kolabd/templates/s >lapd.conf.template.in?rev=1.25&content-type=text/vnd.viewcvs-markup I guess I need to change directory_mode : slurpd in kolab.globals since openldap2.4 doesn't support slurp anymore -- Thomas From ml at radoeka.nl Sun Mar 22 09:43:11 2009 From: ml at radoeka.nl (Richard Bos) Date: Sun, 22 Mar 2009 09:43:11 +0100 Subject: kolab on openSUSE natively is a little bit back In-Reply-To: <200903212142.59682.thomas@btspuhler.com> References: <200902142107.48113.ml@radoeka.nl> <200903092121.20031.ml@radoeka.nl> <200903212142.59682.thomas@btspuhler.com> Message-ID: <200903220943.12542.ml@radoeka.nl> Op zondag 22 maart 2009 05:42:59 schreef Thomas Spuhler: > I guess I need to change directory_mode : slurpd in kolab.globals since > openldap2.4 doesn't support slurp anymore Yes, that is correct. Change it to: directory_mode : syncrepl -- Richard From thomas at btspuhler.com Sun Mar 22 17:13:17 2009 From: thomas at btspuhler.com (Thomas Spuhler) Date: Sun, 22 Mar 2009 09:13:17 -0700 Subject: kolab on openSUSE natively is a little bit back In-Reply-To: <200903220943.12542.ml@radoeka.nl> References: <200902142107.48113.ml@radoeka.nl> <200903212142.59682.thomas@btspuhler.com> <200903220943.12542.ml@radoeka.nl> Message-ID: <200903220913.17722.thomas@btspuhler.com> On Sunday 22 March 2009, Richard Bos wrote: > Op zondag 22 maart 2009 05:42:59 schreef Thomas Spuhler: > > I guess I need to change directory_mode : slurpd in kolab.globals since > > openldap2.4 doesn't support slurp anymore > > Yes, that is correct. Change it to: > directory_mode : syncrepl Thanks. I am working on the "Mandriva nativly" but 2.1 -- Thomas From ml at radoeka.nl Sun Mar 22 21:01:30 2009 From: ml at radoeka.nl (Richard Bos) Date: Sun, 22 Mar 2009 21:01:30 +0100 Subject: kolab on openSUSE natively is a little bit back In-Reply-To: <200903220913.17722.thomas@btspuhler.com> References: <200902142107.48113.ml@radoeka.nl> <200903220943.12542.ml@radoeka.nl> <200903220913.17722.thomas@btspuhler.com> Message-ID: <200903222101.30242.ml@radoeka.nl> Op zondag 22 maart 2009 17:13:17 schreef Thomas Spuhler: > I am working on the "Mandriva nativly" but 2.1 That's nice to hear. When will a native Mandrake kolab version be ready? -- Richard From benoit.mortier at opensides.be Mon Mar 23 09:36:40 2009 From: benoit.mortier at opensides.be (Benoit Mortier) Date: Mon, 23 Mar 2009 09:36:40 +0100 Subject: gosa In-Reply-To: <200903201517.47792.johnm@advocap.org> References: <49C00CF8.7070708@advocap.org> <200903201941.41126.benoit.mortier@opensides.be> <200903201517.47792.johnm@advocap.org> Message-ID: <200903230936.41058.benoit.mortier@opensides.be> Le Friday 20 March 2009 21:17:47 John McMonagle, vous avez ?crit?: > On Friday 20 March 2009 01:41:40 pm Benoit Mortier wrote: > > Le Friday 20 March 2009 19:18:27 John McMonagle, vous avez ?crit?: > > > On Friday 20 March 2009 05:06:39 am Benoit Mortier wrote: > > > > Le Friday 20 March 2009 05:42:46 Gunnar Wrobel, vous avez ?crit?: > > > > > Quoting John McMonagle : > > > > > > Any opinions on gosa and kolab? > > > > - some import of specific objects from kolab ldap to the your ldap if > > you don't use the ldap server from kolab, mainly the manager and > > other special users. > > > >> - some change to the template and / or files to tell him where the > >> ldap > > > > reside if not using kolab ldap. > > > > other than that it should roll > > Thanks > > Not really gosa issues but brings up a couple more issues. > I wonder what kind of issues there will be with upgrades if the kolab > server is not the ldap master? > > Some of my sites have poor network connections and slurpd replication > doesn't work well. Don't want to consider using slurpd again. > > I can think of 4 possible ways to do the ldap for kolab. > > 1 Use kolab openpkg ldap as master adding sync replication. > 2 Use kolab openpkg ldap as sync replication slave. > 3 Use openldap install on kolab host as sync replication slave. Disable > openpkg ldap. > 4 Use openldap server on the local network. Disable openpkg ldap. > > At the moment my preference is 3,4,2,1. My preference is 4,3,2,1 > What problems are there going to be during upgrades? i desactive the openldap from kolab completely and use a real openldap instance with my GOsa setup. If you use the openpkg stuff you have to be carefull that i doesn't change the template you modified to use another ldap serveur. If you are running on debian just use the package made by mathieu parent they are really good and integrate very well on debian > The biggest thing I can see is any schema and acl changes may need to > be manually made through the system first. As schemacheck is on could > be an issue on a pure openpkg system with multiple kolab servers. In openldap 2.4 you can store schema inside openldap so that way you just replicate schema like everything else... Cheers -- Benoit Mortier CEO OpenSides "logiciels libres pour entreprises" : http://www.opensides.be/ Contributor to Gosa Project : http://gosa-project.org/ From johnm at advocap.org Mon Mar 23 16:47:08 2009 From: johnm at advocap.org (John McMonagle) Date: Mon, 23 Mar 2009 10:47:08 -0500 Subject: gosa In-Reply-To: <200903230936.41058.benoit.mortier@opensides.be> References: <49C00CF8.7070708@advocap.org> <200903201941.41126.benoit.mortier@opensides.be> <200903201517.47792.johnm@advocap.org> <200903230936.41058.benoit.mortier@opensides.be> Message-ID: <49C7AEFC.9030601@advocap.org> Benoit Mortier wrote: >>> >>> reside if not using kolab ldap. >>> >>> other than that it should roll >>> >> Thanks >> >> Not really gosa issues but brings up a couple more issues. >> I wonder what kind of issues there will be with upgrades if the kolab >> server is not the ldap master? >> >> Some of my sites have poor network connections and slurpd replication >> doesn't work well. Don't want to consider using slurpd again. >> >> I can think of 4 possible ways to do the ldap for kolab. >> >> 1 Use kolab openpkg ldap as master adding sync replication. >> 2 Use kolab openpkg ldap as sync replication slave. >> 3 Use openldap install on kolab host as sync replication slave. Disable >> openpkg ldap. >> 4 Use openldap server on the local network. Disable openpkg ldap. >> >> At the moment my preference is 3,4,2,1. >> > > My preference is 4,3,2,1 > > Just peeked at my current production mail server ( not kolab). saslauthd.conf points to local ldap slave and 2 external servers. Guess I'm into overkill :-) I use always use at least 2 ldap servers if it's allowed. > If you are running on debian just use the package made by mathieu parent > they are really good and integrate very well on debian > I'll load it on a test server and test it out. Using snapshots for production does make me a bit concerned but if it's close to being ready I can wait a bit. > > >> The biggest thing I can see is any schema and acl changes may need to >> be manually made through the system first. As schemacheck is on could >> be an issue on a pure openpkg system with multiple kolab servers. >> > > In openldap 2.4 you can store schema inside openldap so that way you just > replicate schema like everything else... > That I do need to look into. At the moment all my ldap servers are at 2.3 but I'll work it into my planning. Thanks John -------------- next part -------------- A non-text attachment was scrubbed... Name: johnm.vcf Type: text/x-vcard Size: 262 bytes Desc: not available URL: From LHendricks at austinent.com Mon Mar 23 18:16:40 2009 From: LHendricks at austinent.com (Lucas Hendricks) Date: Mon, 23 Mar 2009 12:16:40 -0500 Subject: kontact for windows Message-ID: <7907AE10BB50DD4F840E76527D27EF19028F3D76@entmail.domain.austinent.com> Hey, I was just curious about the status of the kontact/win project and if it is going to reach a production-usable form any time soon. I am looking forward to pointing the proverbial blowtorch at my exchange 5.5 server. Thanks, Lucas From thomas at btspuhler.com Tue Mar 24 05:53:14 2009 From: thomas at btspuhler.com (Thomas Spuhler) Date: Mon, 23 Mar 2009 21:53:14 -0700 Subject: kolab on openSUSE natively is a little bit back In-Reply-To: <200903222101.30242.ml@radoeka.nl> References: <200902142107.48113.ml@radoeka.nl> <200903220913.17722.thomas@btspuhler.com> <200903222101.30242.ml@radoeka.nl> Message-ID: <200903232153.14940.thomas@btspuhler.com> On Sunday 22 March 2009, Richard Bos wrote: > Op zondag 22 maart 2009 17:13:17 schreef Thomas Spuhler: > > I am working on the "Mandriva nativly" but 2.1 > > That's nice to hear. When will a native Mandrake kolab version be ready? My ldap server doesn't like the word "overlay unique" in slapd.conf -- Thomas From albrecht.dress at lios-tech.com Tue Mar 24 14:25:31 2009 From: albrecht.dress at lios-tech.com (Albrecht =?iso-8859-1?b?RHJl3w==?=) Date: Tue, 24 Mar 2009 14:25:31 +0100 Subject: Spam messages garbled and delivered to Inbox Message-ID: <1237901131.26388.1@pc-adr2> Hi all, I have a question about "weird" messages being delivered through Kolab. They are spam messages which have been detected as such (by MailScanner/spamassassin) on a box which is sitting between the Kolab server and the internet, on a different machine. The message header somehow gets "mixed up" which as a result will drop the message in the Inbox instead of the junk box. The headers of such a message contain (non-printable chars included): Date: Mon, 23 Mar 2009 18:37:44 +0100 (CET)\r To: undisclosed-recipients:;\r X-Kolab-Scheduling-Message: FALSE\r \r " \r Reply-To: "=?ISO-2022-JP?B?GyRCMkZMXDZNMlYbKEIK?=\r " \r To: albrecht.dress at xxx.yyy\r Subject: \203n\203b\203L\203\212\214\276\202\301\202\304\202\242\202\253\202\310\202\350\211\357\202\244\202\314\202\306\202\251\226\263\227\235\202\305\202\267\201B\r Date: Mon, 23 Mar 2009 15:29:48 -0200\r MIME-Version: 1.0\r [...more headers...] X-my-org-MailScanner-SpamCheck: spam, SpamAssassin (Wertung=22.83,\r \tbenoetigt 4, autolearn=spam, BAYES_99 8.00, MISSING_MIMEOLE 0.00,\r \tRCVD_HELO_IP_MISMATCH 2.84, RCVD_IN_PBL 0.91, RCVD_NUMERIC_HELO 2.07,\r \tRDNS_NONE 0.10, SUBJECT_NEEDS_ENCODING 0.00, SUBJ_ILLEGAL_CHARS 1.59,\r \tTVD_RCVD_IP 1.93, TVD_RCVD_IP4 3.18, TVD_SPACE_RATIO 2.22)\r X-my-org-MailScanner-SpamScore: ssssssssssssssssssssss\r Note the extra newline after the "X-Kolab-Scheduling-Message:" header. I *think* that this newline has not been there when the message has been received on the first server (the one between the Internet and Kolab) as the Postfix/Mailscanner on that box adds the "X-my-org-MailScanner*" headers. So, where does it come from? Any ideas? Thanks, Albrecht. From bernhard at intevation.de Tue Mar 24 23:30:34 2009 From: bernhard at intevation.de (Bernhard Reiter) Date: Tue, 24 Mar 2009 23:30:34 +0100 Subject: Kolab (openpkg) and gcc In-Reply-To: <4949E367.9050709@servinfo.ca> References: <4949E367.9050709@servinfo.ca> Message-ID: <200903242330.35024.bernhard@intevation.de> On Thursday 18 December 2008, Christian Tardif wrote: > I tried the new Kolab beta tonight on a brand new Mandriva server > 2009.0. Does not compile. I tried latest kolab release. Does not > compile. But I found out. Mandriva 2009.0 comes with gcc 4.3.2..... > openpkg does not compile with gcc 4.3..... :-( See https://www.intevation.de/roundup/kolab/issue2871 for a new openpkg bootstrap package that (shall) build with gcc 4.3. Successfull build reports are much appreciated so we can see if we put this into Kolab Server/OpenPKG 2.2.1. Thanks, Bernhard -- Managing Director - Owner: www.intevation.net (Free Software Company) Germany Coordinator: fsfeurope.org. Coordinator: www.Kolab-Konsortium.com. Intevation GmbH, Neuer Graben 17, Osnabr?ck, DE; AG Osnabr?ck, HRB 18998 Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From bernhard at intevation.de Tue Mar 24 23:44:37 2009 From: bernhard at intevation.de (Bernhard Reiter) Date: Tue, 24 Mar 2009 23:44:37 +0100 Subject: Compile of 2.2.0 on FC9 fails In-Reply-To: <1237468189.6554.4@pc-adr2> References: <1237461347.6554.2@pc-adr2> <20090319121128.GA2561@xs4all.nl> <1237468189.6554.4@pc-adr2> Message-ID: <200903242344.38655.bernhard@intevation.de> On Thursday 19 March 2009, Albrecht Dre? wrote: > Am 19.03.2009 13:11:28 schrieb(en) Richard Bos: > > You're using a gcc 4.3 or newer. Install an older gcc version and > > that will do it. > > Ah! Yes, FC9 comes with gcc 4.3.0... Or test the new OpenPKG-bootstrap package freshly linked from https://www.intevation.de/roundup/kolab/issue2871 (Should also work on Kolab Server 2.2.0). -- Managing Director - Owner: www.intevation.net (Free Software Company) Germany Coordinator: fsfeurope.org. Coordinator: www.Kolab-Konsortium.com. Intevation GmbH, Neuer Graben 17, Osnabr?ck, DE; AG Osnabr?ck, HRB 18998 Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From bernhard at intevation.de Tue Mar 24 23:47:57 2009 From: bernhard at intevation.de (Bernhard Reiter) Date: Tue, 24 Mar 2009 23:47:57 +0100 Subject: kontact for windows In-Reply-To: <7907AE10BB50DD4F840E76527D27EF19028F3D76@entmail.domain.austinent.com> References: <7907AE10BB50DD4F840E76527D27EF19028F3D76@entmail.domain.austinent.com> Message-ID: <200903242347.58712.bernhard@intevation.de> On Monday 23 March 2009, Lucas Hendricks wrote: > I was just curious about the status of the kontact/win project and if it is > going to reach a production-usable form any time soon. http://www.kolab.org/roadmap.html Kontact for Windows (enterprise4 | beta) A first beta was published December 2008. We expect it to be production ready within Q2 2009. -- Managing Director - Owner: www.intevation.net (Free Software Company) Germany Coordinator: fsfeurope.org. Coordinator: www.Kolab-Konsortium.com. Intevation GmbH, Neuer Graben 17, Osnabr?ck, DE; AG Osnabr?ck, HRB 18998 Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From bernhard at intevation.de Tue Mar 24 23:50:52 2009 From: bernhard at intevation.de (Bernhard Reiter) Date: Tue, 24 Mar 2009 23:50:52 +0100 Subject: Spam messages garbled and delivered to Inbox In-Reply-To: <1237901131.26388.1@pc-adr2> References: <1237901131.26388.1@pc-adr2> Message-ID: <200903242350.53279.bernhard@intevation.de> On Tuesday 24 March 2009, Albrecht Dre? wrote: > Note the extra newline after the "X-Kolab-Scheduling-Message:" header. > I *think* that this newline has not been there when the message has > been received on the first server (the one between the Internet and > Kolab) as the Postfix/Mailscanner on that box adds the > "X-my-org-MailScanner*" headers. So, where does it come from? Any > ideas? You first need to find out, which server manipulates the message. Try to submit the message manually yourself if necessary or sniff the network. Once done and you know it is Kolab Server, please contruct a test script that we can use to reproduce the behaviour. (I once a few years ago had Exchange manipulate a message in a similiar way, garbled headers. I could sniff the network before postfix got it an prove the point.) Bernhard -- Managing Director - Owner: www.intevation.net (Free Software Company) Germany Coordinator: fsfeurope.org. Coordinator: www.Kolab-Konsortium.com. Intevation GmbH, Neuer Graben 17, Osnabr?ck, DE; AG Osnabr?ck, HRB 18998 Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From bernhard at intevation.de Thu Mar 26 10:22:39 2009 From: bernhard at intevation.de (Bernhard Reiter) Date: Thu, 26 Mar 2009 10:22:39 +0100 Subject: FreeBusy In-Reply-To: <003a01c9a898$70d89fb0$5289df10$@andersson@heatex.com> References: <003a01c9a898$70d89fb0$5289df10$@andersson@heatex.com> Message-ID: <200903261022.54565.bernhard@intevation.de> On Thursday 19 March 2009, Tomas Andersson wrote: > Is there a way to use the FreeBusy function in outlook 2003,2007 without > using connectors? Sure, you can display Freebusy lists just fine, you only have to configure the fetch location correctly. Something like https://demo.kolab.org/freebusy/%NAME%.demo.kolab.org.ifb (And make sure this works without https question in IE.) -- Managing Director - Owner: www.intevation.net (Free Software Company) Germany Coordinator: fsfeurope.org. Coordinator: www.Kolab-Konsortium.com. Intevation GmbH, Neuer Graben 17, Osnabr?ck, DE; AG Osnabr?ck, HRB 18998 Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From thomas at btspuhler.com Sun Mar 29 03:01:21 2009 From: thomas at btspuhler.com (Thomas Spuhler) Date: Sat, 28 Mar 2009 18:01:21 -0700 Subject: kolab on openSUSE natively is a little bit back In-Reply-To: <200903102142.04276.ml@radoeka.nl> References: <200902142107.48113.ml@radoeka.nl> <200903091935.51225.thomas@btspuhler.com> <200903102142.04276.ml@radoeka.nl> Message-ID: <200903281801.21610.thomas@btspuhler.com> On Tuesday 10 March 2009, Richard Bos wrote: > Op dinsdag 10 maart 2009 03:35:50 schreef Thomas Spuhler: > > > You can get it from cvs: > > > http://kolab.org/cgi-bin/viewcvs-kolab.cgi/server/kolabd/kolabd/templat > > >es /s > > > lapd.conf.template.in?rev=1.25&content-type=text/vnd.viewcvs-markup > > > > What do the @@@ mean in > > @@@else@@@ > > This is processed / parsed by kolabconf. After processing with kolabconf > those @@@ tags are no longer part of the configuration file. > > > They are not being take resp. are move to the slapd.conf as they are and > > report a failure. > > If you process the config file manually, you need to interpret the @@@ tags > and have related section removed / replaced. > > Hope this helps. Hmmm, @@@if@@@ and @@@else@@@ If the @@@ are part of a command they seem to be interpreded. Seem to remain as such -- Thomas From thomas at btspuhler.com Mon Mar 30 02:55:18 2009 From: thomas at btspuhler.com (Thomas Spuhler) Date: Sun, 29 Mar 2009 17:55:18 -0700 Subject: kolab on openSUSE natively is a little bit back In-Reply-To: <200903222101.30242.ml@radoeka.nl> References: <200902142107.48113.ml@radoeka.nl> <200903220913.17722.thomas@btspuhler.com> <200903222101.30242.ml@radoeka.nl> Message-ID: <200903291755.18537.thomas@btspuhler.com> On Sunday 22 March 2009, Richard Bos wrote: > Op zondag 22 maart 2009 17:13:17 schreef Thomas Spuhler: > > I am working on the "Mandriva nativly" but 2.1 > > That's nice to hear. When will a native Mandrake kolab version be ready? I am getting there (I think) I still have a little problem and I had this on Kolab 1 too: If I delete a user, the user then shows up as deleted, waiting for clean up, but the clean-up never completes. I can't see much in the logs. Also slapd in debug mode doesn't show anything suspicious. -- Thomas From davidb at panix.com Tue Mar 31 01:02:15 2009 From: davidb at panix.com (David M. Besonen) Date: Mon, 30 Mar 2009 15:02:15 -0800 Subject: Kontact Windows 2009-02-20 - libkemoticons not found Message-ID: <49D14F77.2030003@panix.com> after installing, running, and switching the latest Kontact release for Windows to English, the application refused to restart with the following error message: --- kontact.exe - Unable To Locate Component - This application has failed to start because libkemoticons.dll was not found. Re-installing the application may fix this problem. --- has anyone seen this problem? also, is this the best mailing list to which to post Kontact for Windows issues? thanks, david From bernhard at intevation.de Tue Mar 31 10:02:51 2009 From: bernhard at intevation.de (Bernhard Reiter) Date: Tue, 31 Mar 2009 10:02:51 +0200 Subject: Kontact Windows 2009-02-20 - libkemoticons not found In-Reply-To: <49D14F77.2030003@panix.com> References: <49D14F77.2030003@panix.com> Message-ID: <200903311002.55671.bernhard@intevation.de> Am Dienstag, 31. M?rz 2009 01:02:15 schrieb David M. Besonen: > also, is this the best mailing list to which to post Kontact > for Windows issues? Yes, this is a good place to ask for Kontact on Windows especially if this is with our packages which package the enterprise4 branch which usually is more stable. There is also https://mail.kde.org/mailman/listinfo/kde-windows for more general issues about KDE on windows. 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: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From alar.sing at err.ee Tue Mar 31 11:54:33 2009 From: alar.sing at err.ee (Alar Sing) Date: Tue, 31 Mar 2009 12:54:33 +0300 Subject: kolab on openSUSE natively is a little bit back In-Reply-To: <200902142107.48113.ml@radoeka.nl> References: <200902142107.48113.ml@radoeka.nl> Message-ID: <49D1E859.9000202@err.ee> Richard Bos wrote: > Hi, > > this is a message for those interested in having kolab available on openSUSE > natively. The last months I have been working on the many many packages that > are required for kolab and they are now available on openSUSE's build service. > I have updated the wiki page about how to install kolab on openSUSE. > > The packages are available for openSUSE_10.3, 11.0 and 11.1. I have tested > the packages only on 11.1. So far the rpms install nicely, and I have the web > interface up and running. However, configured users are not created in the > directory /var/spool/imap This is to be investigated why this happens. A > message in /var/log/messages might give clue: > DBERROR db4: /var/lib/imap/mailboxes.db: unexpected file type or format > > Anyway, I just wanted to let you know that progress is made and it would be > great if others start testing the current packages. Find more information > about kolab on openSUSE at: > http://wiki.kolab.org/index.php/OpenSUSE_-_natively > and > http://en.opensuse.org/Kolab > > Hello Today I tested kolab on opensuse natively Added repositoris http://download.opensuse.org/repositories/server:/Kolab/openSUSE_11.0 http://download.opensuse.org/repositories/server:/php:/applications/openSUSE_11.1 http://download.opensuse.org/repositories/server:/Kolab:/UNSTABLE/openSUSE_11.1 Installed kolab and firstly there is no /usr/share/kolab/scripts/kolab_opensuse_bootstrap Second error was with /etc/init.d/kolab script ERROR /etc/init.d/slurpd NOT found - abort And kolab_bootstarp -b did not work got error: Enter fully qualified hostname of slave kolab server e.g. thishost.domain.tld [empty when done]: prepare LDAP database... temporarily starting slapd chown: cannot access `/var/lib/ldap/*': No such file or directory Could not start temporary slapd: at /usr/share/kolab/scripts/kolab_bootstrap line 469. And in /var/log/messages there was Mar 31 12:47:27 linux-ohjb slapd[8834]: daemon: shutdown requested and initiated. Mar 31 12:47:27 linux-ohjb slapd[8834]: slapd shutdown: waiting for 0 operations/tasks to finish Mar 31 12:47:27 linux-ohjb slapd[8834]: slapd stopped. Mar 31 12:48:01 linux-ohjb slapd[8865]: @(#) $OpenLDAP: slapd 2.4.12 (Dec 3 2008 12:15:42) $ abuild at build13:/usr/src/packages/BUILD/openldap-2.4.12/servers/slapd Mar 31 12:48:01 linux-ohjb slapd[8865]: /etc/openldap/slapd.conf: line 22: keyword is obsolete (ignored) Mar 31 12:48:01 linux-ohjb slapd[8865]: /etc/openldap/slapd.conf: line 24: keyword is obsolete (ignored) Mar 31 12:48:01 linux-ohjb slapd[8865]: /etc/openldap/slapd.conf: line 25: keyword is obsolete (ignored) Mar 31 12:48:01 linux-ohjb slapd[8865]: /etc/openldap/slapd.conf: line 27: unknown directive outside backend info and database definitions. Mar 31 12:48:01 linux-ohjb slapd[8865]: slapd stopped. Mar 31 12:48:01 linux-ohjb slapd[8865]: connections_destroy: nothing to destroy. From lists at oak-wood.co.uk Tue Mar 31 14:12:08 2009 From: lists at oak-wood.co.uk (Chris Hastie) Date: Tue, 31 Mar 2009 13:12:08 +0100 Subject: Free/busy - what triggers it? Message-ID: <20090331131208.tp5a3tx268www8os@imp.oak-wood.co.uk> I'm having some trouble understanding how the free/busy system works. I've run through the troubleshooting guide and I can grab free busy data if it has been generated. I can also trigger the generation of free busy data by hitting the trigger url in a browser, but only for the user I log in as (even if that user has read/write permissions on another users calendar). What I don't understand is how this is supposed to get triggered? I've had a several users using the system for a couple of months, both through Horde and Outlook + toltec, and none appears to ever have triggered generation of fb data. Do they have to trigger generation manually? Is there a configuration option I've missed somewhere? I also notice that in Horde's options for Kronolith, a different fb url is given, which seems to always return an empty page. Thanks -- Chris Hastie From thomas at btspuhler.com Tue Mar 31 16:47:02 2009 From: thomas at btspuhler.com (Thomas Spuhler) Date: Tue, 31 Mar 2009 07:47:02 -0700 Subject: kolab on openSUSE natively is a little bit back In-Reply-To: <49D1E859.9000202@err.ee> References: <200902142107.48113.ml@radoeka.nl> <49D1E859.9000202@err.ee> Message-ID: <200903310747.02548.thomas@btspuhler.com> On Tuesday 31 March 2009, Alar Sing wrote: > Richard Bos wrote: > > Hi, > > > > this is a message for those interested in having kolab available on > > openSUSE natively. The last months I have been working on the many many > > packages that are required for kolab and they are now available on > > openSUSE's build service. I have updated the wiki page about how to > > install kolab on openSUSE. > > > > The packages are available for openSUSE_10.3, 11.0 and 11.1. I have > > tested the packages only on 11.1. So far the rpms install nicely, and I > > have the web interface up and running. However, configured users are not > > created in the directory /var/spool/imap This is to be investigated why > > this happens. A message in /var/log/messages might give clue: > > DBERROR db4: /var/lib/imap/mailboxes.db: unexpected file type or format > > > > Anyway, I just wanted to let you know that progress is made and it would > > be great if others start testing the current packages. Find more > > information about kolab on openSUSE at: > > http://wiki.kolab.org/index.php/OpenSUSE_-_natively > > and > > http://en.opensuse.org/Kolab > > Hello > > Today I tested kolab on opensuse natively > > Added repositoris > http://download.opensuse.org/repositories/server:/Kolab/openSUSE_11.0 > > http://download.opensuse.org/repositories/server:/php:/applications/openSUS >E_11.1 > http://download.opensuse.org/repositories/server:/Kolab:/UNSTABLE/openSUSE_ >11.1 > > > > Installed kolab and firstly there is no > > /usr/share/kolab/scripts/kolab_opensuse_bootstrap > > Second error was with /etc/init.d/kolab script > > ERROR /etc/init.d/slurpd NOT found - abort > > And kolab_bootstarp -b did not work > > got error: > Enter fully qualified hostname of slave kolab server e.g. > thishost.domain.tld [empty when done]: prepare LDAP database... > temporarily starting slapd > chown: cannot access `/var/lib/ldap/*': No such file or directory > Could not start temporary slapd: at > /usr/share/kolab/scripts/kolab_bootstrap line 469. > > And in /var/log/messages there was > > Mar 31 12:47:27 linux-ohjb slapd[8834]: daemon: shutdown requested and > initiated. Mar 31 12:47:27 linux-ohjb slapd[8834]: slapd shutdown: waiting > for 0 operations/tasks to finish Mar 31 12:47:27 linux-ohjb slapd[8834]: > slapd stopped. > Mar 31 12:48:01 linux-ohjb slapd[8865]: @(#) $OpenLDAP: slapd 2.4.12 (Dec > 3 2008 12:15:42) $ > abuild at build13:/usr/src/packages/BUILD/openldap-2.4.12/servers/slapd Mar 31 > 12:48:01 linux-ohjb slapd[8865]: /etc/openldap/slapd.conf: line 22: > keyword is obsolete (ignored) Mar 31 12:48:01 linux-ohjb > slapd[8865]: /etc/openldap/slapd.conf: line 24: keyword is > obsolete (ignored) Mar 31 12:48:01 linux-ohjb slapd[8865]: > /etc/openldap/slapd.conf: line 25: keyword is > obsolete (ignored) Mar 31 12:48:01 linux-ohjb slapd[8865]: > /etc/openldap/slapd.conf: line 27: unknown directive outside > backend info and database definitions. Mar 31 12:48:01 linux-ohjb > slapd[8865]: slapd stopped. > Mar 31 12:48:01 linux-ohjb slapd[8865]: connections_destroy: nothing to > destroy. > > > > > _______________________________________________ > Kolab-users mailing list > Kolab-users at kolab.org > https://kolab.org/mailman/listinfo/kolab-users I am working on the Mandariva. /var/lib/ldap/* is wrong. Probably need to change the path in /etc/kolab/templates/slapd.conf.template to /var/ldap/* and /var/lib/ldap-kolab to /var/kolab-ldap -- Thomas From ml at radoeka.nl Tue Mar 31 20:28:30 2009 From: ml at radoeka.nl (Richard Bos) Date: Tue, 31 Mar 2009 20:28:30 +0200 Subject: kolab on openSUSE natively is a little bit back In-Reply-To: <49D1E859.9000202@err.ee> References: <200902142107.48113.ml@radoeka.nl> <49D1E859.9000202@err.ee> Message-ID: <200903312028.32605.ml@radoeka.nl> Op dinsdag 31 maart 2009 11:54:33 schreef Alar Sing: > Today I tested kolab on opensuse natively > > Added repositoris > http://download.opensuse.org/repositories/server:/Kolab/openSUSE_11.0 That was an error in the wiki page :( sorry for that. I have corrected the wiki page. That url should of course point to the 11.1 repository.... > http://download.opensuse.org/repositories/server:/php:/applications/openSUS >E_11.1 > http://download.opensuse.org/repositories/server:/Kolab:/UNSTABLE/openSUSE_ >11.1 > > > > Installed kolab and firstly there is no > > /usr/share/kolab/scripts/kolab_opensuse_bootstrap Which kolab rpm version do you have installed (rpm -q kolab)? I have: # rpm -q kolab kolab-2.2.0.99_cvs20090304-2.1 Which delivers: # rpm -ql kolab | grep bootstrap /usr/share/kolab/scripts/kolab_opensuse_bootstrap > Second error was with /etc/init.d/kolab script > > ERROR /etc/init.d/slurpd NOT found - abort That is expected, as slurpd is no longer part op openldap (with release 2.4 and up). This is probably because of the wrong kolab package that is installed. > And kolab_bootstarp -b did not work > > got error: > Enter fully qualified hostname of slave kolab server e.g. > thishost.domain.tld [empty when done]: prepare LDAP database... > temporarily starting slapd > chown: cannot access `/var/lib/ldap/*': No such file or directory That is an expected error, that can be neglected. > Could not start temporary slapd: at > /usr/share/kolab/scripts/kolab_bootstrap line 469. It makes no sense to continue debugging after this point. You first need to have the correct packages installed. Thanks for reporting the errors. Hopefully you can re-install kolab and have a better result this time....? -- Richard From ml at radoeka.nl Tue Mar 31 20:31:56 2009 From: ml at radoeka.nl (Richard Bos) Date: Tue, 31 Mar 2009 20:31:56 +0200 Subject: kolab on openSUSE natively is a little bit back In-Reply-To: <200903310747.02548.thomas@btspuhler.com> References: <200902142107.48113.ml@radoeka.nl> <49D1E859.9000202@err.ee> <200903310747.02548.thomas@btspuhler.com> Message-ID: <200903312031.59079.ml@radoeka.nl> Hello Thomas, Op dinsdag 31 maart 2009 16:47:02 schreef Thomas Spuhler: > I am working on the Mandariva. /var/lib/ldap/* is wrong. Probably need to > change the path in /etc/kolab/templates/slapd.conf.template to /var/ldap/* > and /var/lib/ldap-kolab to /var/kolab-ldap For opensuse /var/lib/ldap is correct. That error "chown: cannot access `/var/lib/ldap/" is always reported. A bit confusing, but after some installations one get used to it ;) Alar's problem is most likely caused by a incorrect kolab package. -- Richard