From marc.schiffbauer at mightycare.de Thu Apr 2 01:57:13 2009 From: marc.schiffbauer at mightycare.de (Marc Schiffbauer) Date: Thu, 2 Apr 2009 01:57:13 +0200 Subject: Kalenderfreigabe per ics moeglich? Message-ID: <200904020157.13946.marc.schiffbauer@mightycare.de> Hallo! ich versuche auf unserer kolab 2.2.1rc1 Installation meinen Kalender über horde/kronolith per .ics-Datei für andere User freizugeben. Das scheint leider nicht zu gehen... bzw. nur mit den eigenen Zugangsdaten. Ziel ist es einfach nur, dass User auf unserem Exchange-Server meinen Kalender auf dem Kolab-Server lesen können... Frage: kennt jemand einen Weg, wie ich meinen Kalender sonstwie extern verfügbar machen kann? Mir ist dabei mittlerweile jedes Mittel recht. Eine Möglichkeit wäre, auf dem kolab server einen cron-job einzurichten, der jede Minute per wget mit meinen Benutzerdaten meinen Kalender als ics-Datei in ein Verzeichnis schreibt, welches ich dann wiederum per Apache verfügbar mache. Dieses Verzeichniss könnte/müsste ich dann per .htaccess sichern. Nachteile bei der Geschichte sind dann, dass mein PW im Klartext im cron-job steht, dass ich das PW im cron-job manuell synchron halten muss etc. Ausserdem kann das ein "normaler" User nicht mal eben selber einrichten. Gibt es vielleicht noch ne einfachere Möglichkeit? Bin für jeden Tipp dankbar. Gruß -Marc From bernhard at intevation.de Thu Apr 2 17:48:10 2009 From: bernhard at intevation.de (Bernhard Reiter) Date: Thu, 2 Apr 2009 17:48:10 +0200 Subject: Kalenderfreigabe per ics moeglich? In-Reply-To: <200904020157.13946.marc.schiffbauer@mightycare.de> References: <200904020157.13946.marc.schiffbauer@mightycare.de> Message-ID: <200904021748.10741.bernhard@intevation.de> Am Donnerstag, 2. April 2009 01:57:13 schrieb Marc Schiffbauer: > ch versuche auf unserer kolab 2.2.1rc1 Installation meinen Kalender über > horde/kronolith per .ics-Datei für andere User freizugeben. > > Das scheint leider nicht zu gehen... bzw. nur mit den eigenen Zugangsdaten. Das iCalender Format wird nur bei einem Export erzeugt im Kolab und wird den eigenen Kalender, z.B. mit mehreren Ordner oft nur unzureichend wiedergeben können. Eine bessere Idee ist vielleicht die Freibelegt Liste, welche z.B. Outlook direkt auch lesen könnte. > Ziel ist es einfach nur, dass User auf unserem Exchange-Server meinen > Kalender auf dem Kolab-Server lesen können... > > Frage: kennt jemand einen Weg, wie ich meinen Kalender sonstwie extern > verfügbar machen kann? * Freibelegt Listen * Der Kolab-Webklient * SyncML über den Kolab-Webklienten * Export über den KDE Kolab Klienten * Benutzung eins Kolab Plugins für Outlook > Mir ist dabei mittlerweile jedes Mittel recht. Eine Möglichkeit wäre, auf > dem kolab server einen cron-job einzurichten, der jede Minute per wget mit > meinen Benutzerdaten meinen Kalender als ics-Datei in ein Verzeichnis > schreibt, welches ich dann wiederum per Apache verfügbar mache. Dieses > Verzeichniss könnte/müsste ich dann per .htaccess sichern. > > Nachteile bei der Geschichte sind dann, dass mein PW im Klartext im > cron-job steht, dass ich das PW im cron-job manuell synchron halten muss > etc. Ausserdem kann das ein "normaler" User nicht mal eben selber > einrichten. > > Gibt es vielleicht noch ne einfachere Möglichkeit? -- 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 -------------- nächster Teil -------------- Ein Dateianhang mit Binärdaten wurde abgetrennt... Dateiname : nicht verfügbar Dateityp : application/pgp-signature Dateigröße : 198 bytes Beschreibung: This is a digitally signed message part. URL : http://lists.wald.intevation.org/pipermail/kolab-users-de/attachments/20090402/7653ce71/attachment.pgp From wrobel at pardus.de Fri Apr 3 17:49:49 2009 From: wrobel at pardus.de (Gunnar Wrobel) Date: Fri, 03 Apr 2009 17:49:49 +0200 Subject: Kalenderfreigabe per ics moeglich? In-Reply-To: <200904020157.13946.marc.schiffbauer@mightycare.de> References: <200904020157.13946.marc.schiffbauer@mightycare.de> Message-ID: <20090403174949.65243qvzlcgi70g0@webmail.pardus.de> Quoting Marc Schiffbauer : > Hallo! > > ich versuche auf unserer kolab 2.2.1rc1 Installation meinen Kalender über > horde/kronolith per .ics-Datei für andere User freizugeben. > > Das scheint leider nicht zu gehen... bzw. nur mit den eigenen Zugangsdaten. Korrekt. Derzeit können über den Kolab-Webklienten keine Daten anonym ausgegeben werden. Das hat zwei Gründe: Der Cyrus-IMAP erlaubt derzeit keinen anonymen Zugriff und selbst wenn er das tun würde unterstützen es die Kolab-Treiber derzeit nicht. Das Thema ist eigentlich ziemlich hoch auf meiner ToDo-Liste, aber auch nicht ganz so einfach. Das mit dem anonymen IMAP-Zugriff sollte zwar nicht ganz so kompliziert sein, aber ich bin von der Lösung eigentlich nicht überzeugt. In dem Fall wären nämlich die User in der Lage die Daten in den Kolab-Ordnern für die Außenwelt freizuschalten, indem sie "anyone" Leserechte geben. Wer das Risiko eingehen möchte sollte das tun können aber ich gehe eigentlich nicht davon aus, dass wir das standardmäßig unterstützen wollen. Vor allem auch, weil der Ansatz nicht gerade performant wäre. Trotzdem ist das Thema hoch auf meiner Liste, weil das ja gerade einer der zentralen Vorteile einer Webapplikation ist: Die Möglichkeit Daten nach außen verfügbar zu machen. Mein bevorzugter Ansatz wäre hier den mit dem Kolab_FreeBusy-Modul verfolgte Strategie auszuweiten: Ein Client triggert das Aktualisieren eines Caches nach Veränderungen an einem Kolab-Groupware Ordner. Die Cache-Daten werden dann im zweiten Schritt beim Zugriff von außen für den Export zusammengefasst. > > Ziel ist es einfach nur, dass User auf unserem Exchange-Server > meinen Kalender > auf dem Kolab-Server lesen können... > > Frage: kennt jemand einen Weg, wie ich meinen Kalender sonstwie extern > verfügbar machen kann? Da das oben beschriebene Verfahren sicherlich nicht vor nächstem Jahr zu erwarten ist, empfehle ich ebenfalls die von Bernhard beschriebenen Varianten. Gruß, Gunnar > > Mir ist dabei mittlerweile jedes Mittel recht. Eine Möglichkeit wäre, auf dem > kolab server einen cron-job einzurichten, der jede Minute per wget mit meinen > Benutzerdaten meinen Kalender als ics-Datei in ein Verzeichnis schreibt, > welches ich dann wiederum per Apache verfügbar mache. Dieses Verzeichniss > könnte/müsste ich dann per .htaccess sichern. > > Nachteile bei der Geschichte sind dann, dass mein PW im Klartext im cron-job > steht, dass ich das PW im cron-job manuell synchron halten muss etc. > Ausserdem kann das ein "normaler" User nicht mal eben selber einrichten. > > Gibt es vielleicht noch ne einfachere Möglichkeit? > > Bin für jeden Tipp dankbar. > > Gruß > -Marc > > _______________________________________________ > Kolab-users-de mailing list > Kolab-users-de at kolab.org > http://lists.wald.intevation.org/mailman/listinfo/kolab-users-de > -- ____ 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 JuFo-J-D-H at web.de Sat Apr 4 14:59:33 2009 From: JuFo-J-D-H at web.de (JuFo-J-D-H@web.de) Date: Sat, 04 Apr 2009 14:59:33 +0200 Subject: smbldap-populate endet mit Fehler Message-ID: <545837509@web.de> Hallo, nach reichlicher Überlegung habe ich mich nun auch dazu entschlossen Kolab als Groupware einzusetzen. Da ich aber auch einen Samba-Server betreibe und ich diesen "http://wiki.kolab.org/index.php/Kolab_2.2_and_Samba_on_Ubuntu_Hardy" super Wiki-Eintrag gefunden habe, lag es natürlich nahe beides zu kombinieren. Leider bin ich noch recht unerfahren was LDAP angeht, aber nun gut... Ich habe mich meines erachtens nach genau an die Wiki-Beschreibung gehalten und habe soeben das ganze ein zweites mal noch einmal von vorne begonnen mit dem seleben Resultat. Ich komme jedesmal soweit, dass ich den Befehl smbldap-populate ausführen soll. Dabei kommt es dann leider zu folgendem Fehler: root at ritex1:/etc# smbldap-populate -b guest -l 65534 -a winadmin Populating LDAP directory for domain RITEX (S-1-5-21-714896361-3384648754-3826556290) (using builtin directory structure) entry cn=internal,dc=ritex already exist. adding new entry: dc=ritex,cn=internal,dc=ritex failed to add entry: naming attribute 'dc' is not present in entry at /usr/sbin/smbldap-populate line 499, line 12. adding new entry: ou=SmbGroups,cn=internal,dc=ritex adding new entry: ou=SmbComputers,cn=internal,dc=ritex adding new entry: ou=SmbIdmap,cn=internal,dc=ritex adding new entry: uid=winadmin,dc=ritex,cn=internal,dc=ritex failed to add entry: No such object at /usr/sbin/smbldap-populate line 499, line 58. adding new entry: uid=guest,dc=ritex,cn=internal,dc=ritex failed to add entry: No such object at /usr/sbin/smbldap-populate line 499, line 89. adding new entry: cn=Domain Admins,ou=SmbGroups,cn=internal,dc=ritex adding new entry: cn=Domain Users,ou=SmbGroups,cn=internal,dc=ritex adding new entry: cn=Domain Guests,ou=SmbGroups,cn=internal,dc=ritex adding new entry: cn=Domain Computers,ou=SmbGroups,cn=internal,dc=ritex adding new entry: cn=Administrators,ou=SmbGroups,cn=internal,dc=ritex adding new entry: cn=Account Operators,ou=SmbGroups,cn=internal,dc=ritex adding new entry: cn=Print Operators,ou=SmbGroups,cn=internal,dc=ritex adding new entry: cn=Backup Operators,ou=SmbGroups,cn=internal,dc=ritex adding new entry: cn=Replicators,ou=SmbGroups,cn=internal,dc=ritex adding new entry: sambaDomainName=RITEX,cn=internal,dc=ritex Please provide a password for the domain winadmin: /usr/sbin/smbldap-passwd: user winadmin doesn't exist Meiner Meinung nach ist doch auch folgendes falsch: "adding new entry: dc=ritex,cn=internal,dc=ritex". Woher kommt denn da zweimal das "dc=ritex" ? Wahrscheinlcih wäre mir schon sehr geholfen wenn ihr mir verraten könntet aus welcher Konfig er sich das zieht. Ich habe schon alle Konfigs etwa 1000 mal mit dem Wiki-Artikel abgeglichen, finde aber leider keinen Fehler :( Also wäre ich euch wirklich sehr dankbar wenn ihr mir da mal auf die Sprünge helfen könntent. Ansonsten noch ein schönes Wochenenden, viele Grüße Holger ________________________________________________________________________ Neu bei WEB.DE: Kostenlose maxdome Movie-FLAT! https://register.maxdome.de/xml/order/LpWebDe?ac=OM.MD.MD008K15726T7073a From marc.schiffbauer at mightycare.de Tue Apr 7 23:42:04 2009 From: marc.schiffbauer at mightycare.de (Marc Schiffbauer) Date: Tue, 7 Apr 2009 23:42:04 +0200 Subject: Kalenderfreigabe per ics moeglich? In-Reply-To: <20090403174949.65243qvzlcgi70g0@webmail.pardus.de> References: <200904020157.13946.marc.schiffbauer@mightycare.de> <20090403174949.65243qvzlcgi70g0@webmail.pardus.de> Message-ID: <200904072342.05172.marc.schiffbauer@mightycare.de> Hallo Bernhard, Hallo Gunnar, danke für eure Antworten! Ich habe es jetzt über wget gemacht, da mir dies für die Outlook User das einfachste schien, da es jetzt auch nur für mich gehen muss. Es scheint unter Win gut zu funktionieren: Ein klick auf die URL und man kann den Kalender in Outlook einbinden. Funktioniert auch mit Zugangsschutz per .htaccess. Schön zu erfahren, dass es hoch auf der todo Liste steht. Gruß -Marc PS: TOFU ist sonst nicht mein Stil ;-) Am Freitag, 3. April 2009 17:49:49 schrieb Gunnar Wrobel: > Quoting Marc Schiffbauer : > > Hallo! > > > > ich versuche auf unserer kolab 2.2.1rc1 Installation meinen Kalender über > > horde/kronolith per .ics-Datei für andere User freizugeben. > > > > Das scheint leider nicht zu gehen... bzw. nur mit den eigenen > > Zugangsdaten. > > Korrekt. > > Derzeit können über den Kolab-Webklienten keine Daten anonym > ausgegeben werden. > > Das hat zwei Gründe: Der Cyrus-IMAP erlaubt derzeit keinen anonymen > Zugriff und selbst wenn er das tun würde unterstützen es die > Kolab-Treiber derzeit nicht. > > Das Thema ist eigentlich ziemlich hoch auf meiner ToDo-Liste, aber > auch nicht ganz so einfach. > > Das mit dem anonymen IMAP-Zugriff sollte zwar nicht ganz so > kompliziert sein, aber ich bin von der Lösung eigentlich nicht > überzeugt. In dem Fall wären nämlich die User in der Lage die Daten in > den Kolab-Ordnern für die Außenwelt freizuschalten, indem sie "anyone" > Leserechte geben. > > Wer das Risiko eingehen möchte sollte das tun können aber ich gehe > eigentlich nicht davon aus, dass wir das standardmäßig unterstützen > wollen. Vor allem auch, weil der Ansatz nicht gerade performant wäre. > > Trotzdem ist das Thema hoch auf meiner Liste, weil das ja gerade einer > der zentralen Vorteile einer Webapplikation ist: Die Möglichkeit Daten > nach außen verfügbar zu machen. > > Mein bevorzugter Ansatz wäre hier den mit dem Kolab_FreeBusy-Modul > verfolgte Strategie auszuweiten: Ein Client triggert das Aktualisieren > eines Caches nach Veränderungen an einem Kolab-Groupware Ordner. Die > Cache-Daten werden dann im zweiten Schritt beim Zugriff von außen für > den Export zusammengefasst. > > > Ziel ist es einfach nur, dass User auf unserem Exchange-Server > > meinen Kalender > > auf dem Kolab-Server lesen können... > > > > Frage: kennt jemand einen Weg, wie ich meinen Kalender sonstwie extern > > verfügbar machen kann? > > Da das oben beschriebene Verfahren sicherlich nicht vor nächstem Jahr > zu erwarten ist, empfehle ich ebenfalls die von Bernhard beschriebenen > Varianten. > > Gruß, > > Gunnar > > > Mir ist dabei mittlerweile jedes Mittel recht. Eine Möglichkeit wäre, auf > > dem kolab server einen cron-job einzurichten, der jede Minute per wget > > mit meinen Benutzerdaten meinen Kalender als ics-Datei in ein Verzeichnis > > schreibt, welches ich dann wiederum per Apache verfügbar mache. Dieses > > Verzeichniss könnte/müsste ich dann per .htaccess sichern. > > > > Nachteile bei der Geschichte sind dann, dass mein PW im Klartext im > > cron-job steht, dass ich das PW im cron-job manuell synchron halten muss > > etc. Ausserdem kann das ein "normaler" User nicht mal eben selber > > einrichten. > > > > Gibt es vielleicht noch ne einfachere Möglichkeit? > > > > Bin für jeden Tipp dankbar. > > > > Gruß > > -Marc > > > > _______________________________________________ > > Kolab-users-de mailing list > > Kolab-users-de at kolab.org > > http://lists.wald.intevation.org/mailman/listinfo/kolab-users-de -- Senior Consultant :: Solution Architect IT-Security :: Free Software :: GNU/Linux Mobile +49_151_16227402 :: Fon +49_6187_9058695 :: Fax +49_6187_900157 MightyCare Solutions GmbH http://www.mightycare.de Firmenangaben unter http://www.mightycare.de/#/de/impressum/ From thomas at intevation.de Wed Apr 8 13:06:16 2009 From: thomas at intevation.de (Thomas Arendsen Hein) Date: Wed, 8 Apr 2009 13:06:16 +0200 Subject: Kolab Server 2.2.1 =?iso-8859-15?Q?ver=F6f?= =?iso-8859-15?Q?fentlicht?= Message-ID: <20090408110616.GB8599.thomas@intevation.de> Hallo! Gestern Abend wurde Kolab Server 2.2.1 veröffentlicht. Vielen Dank an alle, die hieran beteiligt waren! Diese Version enthält den neuen Kolab-Webklienten, welcher zusätzlich zum traditionellen Modus jetzt auch einen minimalistischen und einen dynamischen Modus und SyncML-Unterstützung im Beta-Stadium bietet. Außerdem wurden im Vergleich zur letzten stabilen Version die Paketstruktur überarbeitet und viele wichtige Korrekturen vorgenommen. Da sich das LDAP-Schema geändert hat, muss die Anleitung im 1st.README für Aktualisierungen unbedingt befolgt werden. Dokumentation und OpenPKG-Pakete sind, wie auf der überarbeiteten Download-Seite http://kolab.org/download.html beschrieben, unter http://files.kolab.org/server/release/kolab-server-2.2.1/ und von den auf http://kolab.org/mirrors.html genannten Spiegelservern herunterzuladen. http://files.kolab.org/RSYNC.txt beschreibt, wie man die Dateien mit rsync herunterladen (oder spiegeln) kann. Die heruntergeladenen Dateien können folgendermaßen geprüft werden: $ gpg --keyserver hkp://subkeys.pgp.net --recv-key 5816791A oder importieren von https://www.intevation.de/~thomas/gpg_pub_key.asc (der gleiche Schlüssel, mit dem ich auch diese Mail signiert habe) $ gpg --verify SHA1SUMS.sig $ sha1sum -c SHA1SUMS Binärpakete für Debian GNU/Linux (etch/oldstable) auf x86-Systemen liegen im Verzeichnis ix86-debian4.0 neben dem sources-Verzeichnis. Anleitung zur Installation und weitere Informationen: http://files.kolab.org/server/release/kolab-server-2.2.1/sources/1st.README und http://files.kolab.org/server/release/kolab-server-2.2.1/sources/release-notes.txt Bei Problemen bitten wir um einen Eintrag auf https://issues.kolab.org/ Grüße, 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 -------------- nächster Teil -------------- Ein Dateianhang mit Binärdaten wurde abgetrennt... Dateiname : nicht verfügbar Dateityp : application/pgp-signature Dateigröße : 198 bytes Beschreibung: nicht verfügbar URL : http://lists.wald.intevation.org/pipermail/kolab-users-de/attachments/20090408/cc439d4b/attachment.pgp From glua at 4-mail.net Wed Apr 8 14:30:56 2009 From: glua at 4-mail.net (Julian Golderer) Date: Wed, 8 Apr 2009 14:30:56 +0200 Subject: Kolab Server 2.2.1 =?iso-8859-1?q?ver=F6ffentlicht?= In-Reply-To: <20090408110616.GB8599.thomas@intevation.de> References: <20090408110616.GB8599.thomas@intevation.de> Message-ID: <200904081430.56637.glua@4-mail.net> Hallo Thomas, Am Mittwoch 08 April 2009 13:06:16 schrieb Thomas Arendsen Hein: > Da sich das LDAP-Schema geändert hat, muss die Anleitung im 1st.README > für Aktualisierungen unbedingt befolgt werden. was genau hat sich am LDAP-Schema geändert? Gibt es Ansätze des LDAP- Adressbuch Multi-Domain-fähig zu machen? Derzeit ist dies ja nicht möglich, da standardmäßig der LDAP-Zugriff allen komplett offen steht. Grüße, Julian From bbuehler at bbm-bbmicro.ch Wed Apr 8 15:22:33 2009 From: bbuehler at bbm-bbmicro.ch (B. Buehler) Date: Wed, 8 Apr 2009 15:22:33 +0200 Subject: Kolab und CMS Message-ID: <200904081522.34585.bbuehler@bbm-bbmicro.ch> Hallo Liste gibt es Kolab-Installationen die mit einem CMS in Kombination betrieben werden? Ich habe ein solches Projekt zu lösen, mich aber noch nicht entschieden welches CMS dafür in Frage kommen könnte. Ich hoffe auf ein Feedback von der Gemeinde um nicht bei "Adam und Eva" beginnen zu müssen. Herzlichen Dank für alle Antworten. Grüsse -- Bernhard Bühler From glua at 4-mail.net Wed Apr 8 17:26:34 2009 From: glua at 4-mail.net (Julian Golderer) Date: Wed, 8 Apr 2009 17:26:34 +0200 Subject: Kritik an Kolab-Entwicklung Message-ID: <200904081726.34947.glua@4-mail.net> Hallo Liste, Hallo Entwickler. Seit etwa einem Jahr verwende ich nun Kolab produktiv auf einem Gentoo-System und verfolge die Entwicklung seit etwa 1,5 Jahren. Mir gefällt an Kolab besonders die Idee vorhandene Produkte zu nutzen (Apache, LDAP, usw. + IMAP für den Datenspeicher) und die Offenheit, wie diese im System installiert werden. Dadurch erhalten besonders Sysadmins guten Zugang zu den einzelnen Komponenten - als Negativbeispiel mag ich hier mal Zimbra nennen, dass als Blackbox mit "Irrer" Verzeichnisstruktur ausgeliefert wird. Jedoch hat sich einiges nicht geändert, seit ich das Projekt verfolge: * die Roadmap auf der Kolab-Homepage gibt keine Visionen vor * als Versionskontrolle kommt noch immer das unhandliche CVS zum Einsatz * es gibt keine integrierte Entwicklungsplattform wie Redmine oder zumindest Trac * es fehlt ein Entwickler-Blog, damit auch Außenstehende etwas vom Geschehen mitbekommen An die Developer: mir ist bewusst, dass eine Kritik an der Kolab-Entwicklung eigentlich auf eine *-devel-*-Liste gehört und nicht in eine *-users-*-Liste, doch interessiert es mich, ob dies nur mir in dieser Art auffällt oder allgemein so wahrgenommen wird. Bitte um Feedback. Grüße, Julian From thomas at intevation.de Thu Apr 9 10:09:30 2009 From: thomas at intevation.de (Thomas Arendsen Hein) Date: Thu, 9 Apr 2009 10:09:30 +0200 Subject: Kolab Server 2.2.1 =?iso-8859-15?Q?ver?= =?iso-8859-15?Q?=F6ffentlicht?= In-Reply-To: <200904081430.56637.glua@4-mail.net> References: <20090408110616.GB8599.thomas@intevation.de> <200904081430.56637.glua@4-mail.net> Message-ID: <20090409080930.GB5149.thomas@intevation.de> * Julian Golderer [20090408 14:31]: > Am Mittwoch 08 April 2009 13:06:16 schrieb Thomas Arendsen Hein: > > Da sich das LDAP-Schema geändert hat, muss die Anleitung im 1st.README > > für Aktualisierungen unbedingt befolgt werden. > > was genau hat sich am LDAP-Schema geändert? Die Webklient-Nutzerkonfigurationen befinden sich jetzt nicht mehr im LDAP und es wurden Tippfehler in den OID-Nummern korrigiert. Zusaetzlich wurden ein paar neue Attribute zur Serverkonfiguration eingefuehrt, aber das allein haette kein Export und Reimport der LDAP-Datenbank erfordert. > Gibt es Ansätze des LDAP- > Adressbuch Multi-Domain-fähig zu machen? Derzeit ist dies ja nicht möglich, da > standardmäßig der LDAP-Zugriff allen komplett offen steht. Bisher nicht. Hierfuer wuerde ich empfehlen, das ohnehin flexiblere IMAP-Adressbuch zu verwenden. Gruesse, Thomas -- 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 From thomas at intevation.de Thu Apr 9 10:29:22 2009 From: thomas at intevation.de (Thomas Arendsen Hein) Date: Thu, 9 Apr 2009 10:29:22 +0200 Subject: Kritik an Kolab-Entwicklung In-Reply-To: <200904081726.34947.glua@4-mail.net> References: <200904081726.34947.glua@4-mail.net> Message-ID: <20090409082922.GC5149.thomas@intevation.de> * Julian Golderer [20090408 17:26]: > * die Roadmap auf der Kolab-Homepage gibt keine Visionen vor Es gibt hier wahrscheinlich mehr Visionen als Entwicklungskapazitaeten :) Und ja, das Kolab-"Marketing" ist sicherlich zu verbessern. > * als Versionskontrolle kommt noch immer das unhandliche CVS zum Einsatz Fuer mich ist SVN noch unhandlicher. Was genau fehlt denn? Und ja, ich moechte auch auf Mercurial wechseln, aber hier gibt es noch ein paar Hindernisse, u.a.: > * es gibt keine integrierte Entwicklungsplattform wie Redmine oder zumindest > Trac Intevation betreibt einen GForge-Server auf wald.intevation.org, aber dort wollen wir kein CVS einfuehren und Mercurial ist noch nicht integriert. Auf eine andere Entwicklungsplattform zu wechseln kommt fuer uns aus Kapazitaetzgruenden derzeit nicht infrage. > * es fehlt ein Entwickler-Blog, damit auch Außenstehende etwas vom Geschehen > mitbekommen Die Entwickler sollen lieber entwickeln als Blogs schreiben :) Ansonsten versuchen wir nach Moeglichkeit, interessante Dinge auf der kolab-devel-Mailingliste zu schreiben. Vielleicht findet sich ja ein Community-Mitglied (z.B. Du?), welches die Entwicklung beobachtet und darueber berichtet und ggf. auch mal fragt, was denn da nun gerade im Hintergrund passiert :) > An die Developer: mir ist bewusst, dass eine Kritik an der Kolab-Entwicklung > eigentlich auf eine *-devel-*-Liste gehört und nicht in eine *-users-*-Liste, > doch interessiert es mich, ob dies nur mir in dieser Art auffällt oder > allgemein so wahrgenommen wird. Aehnliche Dinge werden auch von anderen wahrgenommen und einige Dinge haben sich daraus ja schon entwickelt, z.B. wiki.kolab.org, der neue Downloadserver files.kolab.org und die Oeffnung gegenueber neuen Entwicklern. Ansonsten Danke fuer das Lob und die Kritik. Wir wollen uns natuerlich verbessern, aber da wir nicht alles umsetzen koennen, muessen wir schauen, wo Verbesserungen den meisten Nutzen bringen. Gruesse, 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 -------------- nächster Teil -------------- Ein Dateianhang mit Binärdaten wurde abgetrennt... Dateiname : nicht verfügbar Dateityp : application/pgp-signature Dateigröße : 198 bytes Beschreibung: nicht verfügbar URL : http://lists.wald.intevation.org/pipermail/kolab-users-de/attachments/20090409/319d6657/attachment.pgp From marc.schiffbauer at mightycare.de Thu Apr 9 12:38:37 2009 From: marc.schiffbauer at mightycare.de (Marc Schiffbauer) Date: Thu, 9 Apr 2009 12:38:37 +0200 Subject: Kritik an Kolab-Entwicklung In-Reply-To: <20090409082922.GC5149.thomas@intevation.de> References: <200904081726.34947.glua@4-mail.net> <20090409082922.GC5149.thomas@intevation.de> Message-ID: <200904091238.37509.marc.schiffbauer@mightycare.de> Am Donnerstag, 9. April 2009 10:29:22 schrieb Thomas Arendsen Hein: > * Julian Golderer [20090408 17:26]: > > * die Roadmap auf der Kolab-Homepage gibt keine Visionen vor > > Es gibt hier wahrscheinlich mehr Visionen als > Entwicklungskapazitaeten :) > > Und ja, das Kolab-"Marketing" ist sicherlich zu verbessern. > > > * als Versionskontrolle kommt noch immer das unhandliche CVS zum > > Einsatz > > Fuer mich ist SVN noch unhandlicher. Was genau fehlt denn? > > Und ja, ich moechte auch auf Mercurial wechseln, Ich habe mal eine Zeit lang mit hg (Mercurial) gearbeitet, und bin dann auf git gewechselt. Deshalb kurze Frage: Habt ihr euch mal gut näher angesehn? Ich persönlich finde es noch besser als Mercurial... Gruß -Marc -- Senior Consultant :: Solution Architect IT-Security :: Free Software :: GNU/Linux Mobile +49_151_16227402 :: Fon +49_6187_9058695 :: Fax +49_6187_900157 MightyCare Solutions GmbH http://www.mightycare.de Firmenangaben unter http://www.mightycare.de/#/de/impressum/ From glua at 4-mail.net Thu Apr 9 14:58:09 2009 From: glua at 4-mail.net (Julian Golderer) Date: Thu, 9 Apr 2009 14:58:09 +0200 Subject: Kritik an Kolab-Entwicklung In-Reply-To: <20090409082922.GC5149.thomas@intevation.de> References: <200904081726.34947.glua@4-mail.net> <20090409082922.GC5149.thomas@intevation.de> Message-ID: <200904091458.09748.glua@4-mail.net> Hi Thomas, Am Donnerstag 09 April 2009 10:29:22 schrieb Thomas Arendsen Hein: > * Julian Golderer [20090408 17:26]: > > * die Roadmap auf der Kolab-Homepage gibt keine Visionen vor > > Es gibt hier wahrscheinlich mehr Visionen als > Entwicklungskapazitaeten :) Was ich damit meine, ist, dass es einen Plan braucht - z.b. meine Wunsch-Ziele für Kolab3: * neues LDAP-Schema (email-Adresse als CN, da diese wirklich einzigartig sind auf einem Email-Server, Namen können sich wiederholen, speziell bei Multi-Domain-Betrieb) * hierarchisches LDAP-Schema.. also Kolab-Server und danach Domain als Ebenen um die Einträge zu Gruppieren * Templates für Domain-Einstellungen (z.B. Mailboxen dürfen nur maximal 2 GB groß sein) * bessere Commandline-Tools oder Python-API > > * als Versionskontrolle kommt noch immer das unhandliche CVS zum > > Einsatz > > Fuer mich ist SVN noch unhandlicher. Was genau fehlt denn? > > Und ja, ich moechte auch auf Mercurial wechseln, aber hier gibt es > > noch ein paar Hindernisse, u.a.: Ich würde, wie Marc, git bevorzugen :) > > * es fehlt ein Entwickler-Blog, damit auch Außenstehende etwas vom > > Geschehen mitbekommen > > Die Entwickler sollen lieber entwickeln als Blogs schreiben :) Ein Beitrag die Woche würde genügen und es würde aus meiner Sicht den Einstieg für externe Entwickler erleichtern. Die dev-Liste hat relativ viel Traffic, weshalb ich als (noch) Außenstehender den Blog als Diskussionsplattform bevorzugen würde. > Ansonsten versuchen wir nach Moeglichkeit, interessante Dinge auf > der kolab-devel-Mailingliste zu schreiben. > > Vielleicht findet sich ja ein Community-Mitglied (z.B. Du?), welches > die Entwicklung beobachtet und darueber berichtet und ggf. auch mal > fragt, was denn da nun gerade im Hintergrund passiert :) Wäre eine machbare Möglichkeit :) Danke für die konstruktive Antwort! Beste Grüße, Julian From martin.konold at erfrakon.de Thu Apr 9 17:06:54 2009 From: martin.konold at erfrakon.de (Martin Konold) Date: Thu, 9 Apr 2009 17:06:54 +0200 Subject: Kritik an Kolab-Entwicklung In-Reply-To: <200904091238.37509.marc.schiffbauer@mightycare.de> References: <200904081726.34947.glua@4-mail.net> <20090409082922.GC5149.thomas@intevation.de> <200904091238.37509.marc.schiffbauer@mightycare.de> Message-ID: <200904091706.55055.martin.konold@erfrakon.de> Am Donnerstag, 9. April 2009 12:38:37 schrieb Marc Schiffbauer: Hi, > > Und ja, ich moechte auch auf Mercurial wechseln, > > Ich habe mal eine Zeit lang mit hg (Mercurial) gearbeitet, und bin dann auf > git gewechselt. Deshalb kurze Frage: Habt ihr euch mal gut näher angesehn? > Ich persönlich finde es noch besser als Mercurial... Ich finde auch, dass git derzeit das beste Werkzeug für die verteilte Entwicklung von Software ist. Genaugenommen müsste Mercurial schon sehr große Vorteile gegenüber git haben, sodass ich bereit wäre den Umgang mit noch einem Werkzeug zu lernen nachdem ich jahrelang CVS, SVN und nun auch git mache. Grüße, -- martin -- e r f r a k o n Erlewein, Frank, Konold & Partner - Beratende Ingenieure und Physiker Sitz: Adolfstraße 23, 70469 Stuttgart, Partnerschaftsregister Stuttgart PR 126 http://www.erfrakon.com/ From glua at 4-mail.net Thu Apr 9 17:32:06 2009 From: glua at 4-mail.net (Julian Golderer) Date: Thu, 9 Apr 2009 17:32:06 +0200 Subject: Kolab Server 2.2.1 =?iso-8859-1?q?ver=F6ffentlicht?= In-Reply-To: <20090409080930.GB5149.thomas@intevation.de> References: <20090408110616.GB8599.thomas@intevation.de> <200904081430.56637.glua@4-mail.net> <20090409080930.GB5149.thomas@intevation.de> Message-ID: <200904091732.06498.glua@4-mail.net> Hi Thomas, danke für die ausführliche Antwort. Am Donnerstag 09 April 2009 10:09:30 schrieb Thomas Arendsen Hein: > > Gibt es Ansätze des LDAP- > > Adressbuch Multi-Domain-fähig zu machen? Derzeit ist dies ja nicht > > möglich, da standardmäßig der LDAP-Zugriff allen komplett offen steht. > > Bisher nicht. Hierfuer wuerde ich empfehlen, das ohnehin flexiblere > IMAP-Adressbuch zu verwenden. Naja, da man im Webinterface auch externe Kontakte ins LDAP einpflegen kann, und der KDE Groupware Assisten LDAP-Einträge im KAddressbook macht, könnte er diese gleich mit den User-Credentials ergänzen (wie von KAddressbook unterstützt) und in der LDAP-Config könnte anhand der User-Domain eine Zugangsberechtigung für den entsprechenden LDAP-Domain-Baum erteilt werden. Ist aber nur so ne Idee von mir, keine Kritik :) Grüße, Julian From martin.konold at erfrakon.de Sun Apr 12 08:42:38 2009 From: martin.konold at erfrakon.de (Martin Konold) Date: Sun, 12 Apr 2009 08:42:38 +0200 Subject: Kolab Server 2.2.1 =?iso-8859-1?q?ver=F6ffentlicht?= In-Reply-To: <200904091732.06498.glua@4-mail.net> References: <20090408110616.GB8599.thomas@intevation.de> <20090409080930.GB5149.thomas@intevation.de> <200904091732.06498.glua@4-mail.net> Message-ID: <200904120842.40153.martin.konold@erfrakon.de> Am Donnerstag, 9. April 2009 17:32:06 schrieb Julian Golderer: Hi Julian, > Naja, da man im Webinterface auch externe Kontakte ins LDAP einpflegen > kann, und der KDE Groupware Assisten LDAP-Einträge im KAddressbook macht, > könnte er diese gleich mit den User-Credentials ergänzen (wie von > KAddressbook unterstützt) und in der LDAP-Config könnte anhand der > User-Domain eine Zugangsberechtigung für den entsprechenden > LDAP-Domain-Baum erteilt werden. > > Ist aber nur so ne Idee von mir, keine Kritik :) Ich möchte sowas in Zukunft einbauen. Bitte mache einen Feature Request via unsere Issue Tracker. Grüße, -- martin -- e r f r a k o n Erlewein, Frank, Konold & Partner - Beratende Ingenieure und Physiker Sitz: Adolfstraße 23, 70469 Stuttgart, Partnerschaftsregister Stuttgart PR 126 http://www.erfrakon.com/ From g.adamczyk at netkult.eu Sun Apr 12 20:18:53 2009 From: g.adamczyk at netkult.eu (Gregor Adamczyk) Date: Sun, 12 Apr 2009 20:18:53 +0200 Subject: Kolab Server 2.2.1 =?iso-8859-1?b?dmVy9mZmZW50bGljaHQ=?= In-Reply-To: <20090408110616.GB8599.thomas@intevation.de> References: <20090408110616.GB8599.thomas@intevation.de> Message-ID: <20090412201853.97575apehwlwhjgo@mail.netkult.eu> Herzlichen Dank für dieses Update... Habe meine bestehende Installation upgedated, läuft wunderbar. Kurze frage noch, wurde etwas an Postfix verändert dass die in Wiki beschriebene Spamhaus Spamabwähr nicht mehr funkioniert? Using SBL and XBL lists from Spamhaus http://wiki.kolab.org/index.php/Fighting_spam Eine Testmail mit Kolab 2.2 wurde noch geblockt... Siehe: http://www.spamhaus.org/faq/answers.lasso?section=Spamhaus%20SBL#207 nelson-sbl-test at crynwr.com Jemand eine Idee warum das nun nicht mehr geht? Danke MfG Gregor ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. From jphorst at sciencebridge.de Tue Apr 14 16:39:14 2009 From: jphorst at sciencebridge.de (JP Horst) Date: Tue, 14 Apr 2009 16:39:14 +0200 Subject: Kolab Server 2.2.1 =?utf-8?q?ver=C3=B6ffentlicht?= In-Reply-To: <20090408110616.GB8599.thomas@intevation.de> References: <20090408110616.GB8599.thomas@intevation.de> Message-ID: <200904141639.14793.jphorst@sciencebridge.de> Hallo! Ich habe heute zwei 2.2.0 Kolab Server exakt nach Vorschrift auf 2.2.1 upgegraded. In beiden Fällen klappt nun das Horde Login nicht mehr, was vorher ging. Nun erhält man nach erfolgreichem Login exakt die Login Maske wieder. Falsche Logins werden erkannt und moniert. Templates, die mit Horde etc. zu tun haben, habe ich nicht angefasst. Auffällig war lediglich folgende Fehlermeldung, die mir aber nichts sagt: /kolab/etc/kolab# /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 bdb_db_open: Warning - No DB_CONFIG file found in directory /kolab/var/openldap/openldap-data: (2) Expect poor performance for suffix dc=sciencebridge,dc=de. Hat jemand eine Idee, was zu tun ist? Besten Dank Jens-Peter Am Mittwoch, 8. April 2009 13:06:16 schrieb Thomas Arendsen Hein: > Hallo! > > Gestern Abend wurde Kolab Server 2.2.1 veröffentlicht. > Vielen Dank an alle, die hieran beteiligt waren! > > Diese Version enthält den neuen Kolab-Webklienten, welcher zusätzlich > zum traditionellen Modus jetzt auch einen minimalistischen und einen > dynamischen Modus und SyncML-Unterstützung im Beta-Stadium bietet. > Außerdem wurden im Vergleich zur letzten stabilen Version die > Paketstruktur überarbeitet und viele wichtige Korrekturen vorgenommen. > > Da sich das LDAP-Schema geändert hat, muss die Anleitung im 1st.README > für Aktualisierungen unbedingt befolgt werden. > > Dokumentation und OpenPKG-Pakete sind, wie auf der überarbeiteten > Download-Seite http://kolab.org/download.html beschrieben, unter > http://files.kolab.org/server/release/kolab-server-2.2.1/ > und von den auf http://kolab.org/mirrors.html genannten Spiegelservern > herunterzuladen. > > http://files.kolab.org/RSYNC.txt beschreibt, wie man die Dateien > mit rsync herunterladen (oder spiegeln) kann. > > Die heruntergeladenen Dateien können folgendermaßen geprüft werden: > > $ gpg --keyserver hkp://subkeys.pgp.net --recv-key 5816791A > oder importieren von https://www.intevation.de/~thomas/gpg_pub_key.asc > (der gleiche Schlüssel, mit dem ich auch diese Mail signiert habe) > $ gpg --verify SHA1SUMS.sig > $ sha1sum -c SHA1SUMS > > Binärpakete für Debian GNU/Linux (etch/oldstable) auf x86-Systemen > liegen im Verzeichnis ix86-debian4.0 neben dem sources-Verzeichnis. > > Anleitung zur Installation und weitere Informationen: > http://files.kolab.org/server/release/kolab-server-2.2.1/sources/1st.README > und > http://files.kolab.org/server/release/kolab-server-2.2.1/sources/release-no >tes.txt > > Bei Problemen bitten wir um einen Eintrag auf https://issues.kolab.org/ > > Grüße, > Thomas Arendsen Hein From marc.schiffbauer at mightycare.de Tue Apr 14 18:21:17 2009 From: marc.schiffbauer at mightycare.de (Marc Schiffbauer) Date: Tue, 14 Apr 2009 18:21:17 +0200 Subject: Kolab Server 2.2.1 =?iso-8859-1?q?ver=F6ffentlicht?= In-Reply-To: <200904141639.14793.jphorst@sciencebridge.de> References: <20090408110616.GB8599.thomas@intevation.de> <200904141639.14793.jphorst@sciencebridge.de> Message-ID: <200904141821.17495.marc.schiffbauer@mightycare.de> Am Dienstag, 14. April 2009 16:39:14 schrieb JP Horst: > Hallo! Hallo Jens-Peter, > > Ich habe heute zwei 2.2.0 Kolab Server exakt nach Vorschrift auf 2.2.1 > upgegraded. > In beiden Fällen klappt nun das Horde Login nicht mehr, was vorher ging. > Nun erhält man nach erfolgreichem Login exakt die Login Maske wieder. > Falsche Logins werden erkannt und moniert. > Templates, die mit Horde etc. zu tun haben, habe ich nicht angefasst. > > Auffällig war lediglich folgende Fehlermeldung, die mir aber nichts sagt: > > /kolab/etc/kolab# /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 > > bdb_db_open: Warning - No DB_CONFIG file found in > directory /kolab/var/openldap/openldap-data: (2) > Expect poor performance for suffix dc=sciencebridge,dc=de. > > Hat jemand eine Idee, was zu tun ist? > das Problem hatte ich auch. Bei mir lag es daran, dass die cookie-domain nicht stimmte. Ich habe vor dem kolab-server noch einen apache-proxy sitzen (== externes Mailgateway). Das Webinterface wurde so mit einem anderen Hostnamen als dem FQDN des kolab servers angesprochen. Hier hat sich scheinbar etwas verändert, dass dies jetzt nicht mehr funktioniert. Löung für mich war, in der Template-Datei /kolab/etc/kolab/templates/webclient-kolab-conf.template den Eintrag "$conf['cookie']['domain']" anzupassen. Hier musste bei mir dann der Externe-Hostname anstatt dem FQDN "@@@fqdnhostname@@@" wie in der kolab.conf gesetzt, eingetragen werden. Danach klappte der Login sofort wieder. (Aufruf von /kolab/sbin/kolabconf bzw. /kolab/sbin/kolabconf -n nicht vergessen!) Gruß -Marc -- Senior Consultant :: Solution Architect IT-Security :: Free Software :: GNU/Linux Mobile +49_151_16227402 :: Fon +49_6187_9058695 :: Fax +49_6187_900157 MightyCare Solutions GmbH http://www.mightycare.de Firmenangaben unter http://www.mightycare.de/#/de/impressum/ From jphorst at sciencebridge.de Wed Apr 15 11:12:33 2009 From: jphorst at sciencebridge.de (JP Horst) Date: Wed, 15 Apr 2009 11:12:33 +0200 Subject: Kolab Server 2.2.1 =?iso-8859-1?q?ver=F6ffentlicht?= In-Reply-To: <200904141821.17495.marc.schiffbauer@mightycare.de> References: <20090408110616.GB8599.thomas@intevation.de> <200904141639.14793.jphorst@sciencebridge.de> <200904141821.17495.marc.schiffbauer@mightycare.de> Message-ID: <200904151112.33344.jphorst@sciencebridge.de> Am Dienstag, 14. April 2009 18:21:17 schrieb Marc Schiffbauer: > Am Dienstag, 14. April 2009 16:39:14 schrieb JP Horst: > > Hallo! > > Hallo Jens-Peter, > > > Ich habe heute zwei 2.2.0 Kolab Server exakt nach Vorschrift auf 2.2.1 > > upgegraded. > > In beiden Fällen klappt nun das Horde Login nicht mehr, was vorher ging. > > Nun erhält man nach erfolgreichem Login exakt die Login Maske wieder. > > Falsche Logins werden erkannt und moniert. > > Templates, die mit Horde etc. zu tun haben, habe ich nicht angefasst. > > > > Auffällig war lediglich folgende Fehlermeldung, die mir aber nichts sagt: > > > > /kolab/etc/kolab# /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 > > > > bdb_db_open: Warning - No DB_CONFIG file found in > > directory /kolab/var/openldap/openldap-data: (2) > > Expect poor performance for suffix dc=sciencebridge,dc=de. > > > > Hat jemand eine Idee, was zu tun ist? > > das Problem hatte ich auch. Bei mir lag es daran, dass die cookie-domain > nicht stimmte. > > Ich habe vor dem kolab-server noch einen apache-proxy sitzen (== externes > Mailgateway). Das Webinterface wurde so mit einem anderen Hostnamen als dem > FQDN des kolab servers angesprochen. > Hier hat sich scheinbar etwas verändert, dass dies jetzt nicht mehr > funktioniert. > > Löung für mich war, in der Template-Datei > /kolab/etc/kolab/templates/webclient-kolab-conf.template > > den Eintrag "$conf['cookie']['domain']" anzupassen. Hier musste bei mir > dann der Externe-Hostname anstatt dem FQDN "@@@fqdnhostname@@@" wie in der > kolab.conf gesetzt, eingetragen werden. > > Danach klappte der Login sofort wieder. > > (Aufruf von /kolab/sbin/kolabconf bzw. /kolab/sbin/kolabconf -n nicht > vergessen!) > Hallo Marc, das hat das Problem in der Tat gelöst. Vielen Dank für die schnelle Hilfe! Jens-Peter > Gruß > -Marc From martin.konold at erfrakon.de Wed Apr 15 11:24:01 2009 From: martin.konold at erfrakon.de (Martin Konold) Date: Wed, 15 Apr 2009 11:24:01 +0200 Subject: Kolab Server 2.2.1 =?iso-8859-1?q?ver=F6ffentlicht?= In-Reply-To: <200904151112.33344.jphorst@sciencebridge.de> References: <20090408110616.GB8599.thomas@intevation.de> <200904141821.17495.marc.schiffbauer@mightycare.de> <200904151112.33344.jphorst@sciencebridge.de> Message-ID: <200904151124.02501.martin.konold@erfrakon.de> Am Mittwoch, 15. April 2009 11:12:33 schrieb JP Horst: Hi, > > das Problem hatte ich auch. Bei mir lag es daran, dass die cookie-domain > > nicht stimmte. > das hat das Problem in der Tat gelöst. Bitte mach einen entsprechenden Wiki Artikel. Danke, -- martin -- e r f r a k o n Erlewein, Frank, Konold & Partner - Beratende Ingenieure und Physiker Sitz: Adolfstraße 23, 70469 Stuttgart, Partnerschaftsregister Stuttgart PR 126 http://www.erfrakon.com/ From marc.schiffbauer at mightycare.de Wed Apr 15 14:33:42 2009 From: marc.schiffbauer at mightycare.de (Marc Schiffbauer) Date: Wed, 15 Apr 2009 14:33:42 +0200 Subject: Kolab Server 2.2.1 =?iso-8859-1?q?ver=F6ffentlicht?= In-Reply-To: <200904151124.02501.martin.konold@erfrakon.de> References: <20090408110616.GB8599.thomas@intevation.de> <200904151112.33344.jphorst@sciencebridge.de> <200904151124.02501.martin.konold@erfrakon.de> Message-ID: <200904151433.42343.marc.schiffbauer@mightycare.de> Am Mittwoch, 15. April 2009 11:24:01 schrieb Martin Konold: > Am Mittwoch, 15. April 2009 11:12:33 schrieb JP Horst: > > Hi, > > > > das Problem hatte ich auch. Bei mir lag es daran, dass die > > > cookie-domain nicht stimmte. > > > > das hat das Problem in der Tat gelöst. > > Bitte mach einen entsprechenden Wiki Artikel. Hallo Martin, habe mir gerade einen wiki-Account erstellt. Ich kann das auch gerne dokumentieren. Ich könnte mir allerdings vorstellen, dass dies ein häufig auftretendes Problem sein wird, deshalb die Frage: Wäre es nicht vielleicht besser, hier einen eigenen config-Parameter einzuführen, der dann die cookie-Domain einstellt? Weitere Probleme gibt es, wenn der Horde-Client mit verschiedenen Hostnamen im http-Header angesprochen werden können soll (z.B interne und externe Adresse). Was dann? Gruß -Marc -- Senior Consultant :: Solution Architect IT-Security :: Free Software :: GNU/Linux Mobile +49_151_16227402 :: Fon +49_6187_9058695 :: Fax +49_6187_900157 MightyCare Solutions GmbH http://www.mightycare.de Firmenangaben unter http://www.mightycare.de/#/de/impressum/ From hansjoerg.schwarz at stmartin-schwabach.de Wed Apr 15 14:52:45 2009 From: hansjoerg.schwarz at stmartin-schwabach.de (=?iso-8859-1?q?Hansj=F6rg_Schwarz?=) Date: Wed, 15 Apr 2009 14:52:45 +0200 Subject: Horde Performance / Apache Module Message-ID: <200904151452.45300.hansjoerg.schwarz@stmartin-schwabach.de> Hallo allerseits, ich habe beim neuen Kolab 2.2.1 (OpenPkg auf Debian) den Performance Grade von Horde mit Firefox/YSlow gemessen und komme dabei auf schlechte Werte je nach Modul und Inhalt von F40 bis F44. Daher würde ich gerne zumindest die einfachen Optimierungen Expires-Header und Komprimierung durchführen. Leider habe ich feststellen müssen, daß der Apache aus der OpenPkg-Installation kein mod_deflate und kein mod_expires mitbringt. Daher meine Frage: wie kann ich diese Module auf einfache Art und Weise nachrüsten? Vielen Dank im voraus Hansjörg Schwarz From martin.konold at erfrakon.de Wed Apr 15 18:56:57 2009 From: martin.konold at erfrakon.de (Martin Konold) Date: Wed, 15 Apr 2009 18:56:57 +0200 Subject: Kolab Server 2.2.1 =?iso-8859-1?q?ver=F6ffentlicht?= In-Reply-To: <200904151433.42343.marc.schiffbauer@mightycare.de> References: <20090408110616.GB8599.thomas@intevation.de> <200904151124.02501.martin.konold@erfrakon.de> <200904151433.42343.marc.schiffbauer@mightycare.de> Message-ID: <200904151856.58401.martin.konold@erfrakon.de> Am Mittwoch, 15. April 2009 14:33:42 schrieb Marc Schiffbauer: Hallo Marc, > habe mir gerade einen wiki-Account erstellt. > > Ich kann das auch gerne dokumentieren. Sehr gut! > Wäre es nicht vielleicht besser, hier einen eigenen config-Parameter > einzuführen, der dann die cookie-Domain einstellt? Dazu muss ich erst verstehen in welchen Zusammenhängen dieses Problem auftritt, ob das häufiger der Fall ist und ob wir die Default-Einstellung gut wählen können. > Weitere Probleme gibt es, wenn der Horde-Client mit verschiedenen Hostnamen > im http-Header angesprochen werden können soll (z.B interne und externe > Adresse). Was dann? Ich kenne mich mit Horde nicht so gut aus. Ich vermute Horde kann das nicht so out-of-the-box? Grüße, -- martin -- e r f r a k o n Erlewein, Frank, Konold & Partner - Beratende Ingenieure und Physiker Sitz: Adolfstraße 23, 70469 Stuttgart, Partnerschaftsregister Stuttgart PR 126 http://www.erfrakon.com/ From marc.schiffbauer at mightycare.de Thu Apr 16 09:45:09 2009 From: marc.schiffbauer at mightycare.de (Marc Schiffbauer) Date: Thu, 16 Apr 2009 09:45:09 +0200 Subject: Kolab Server 2.2.1 =?iso-8859-1?q?ver=F6ffentlicht?= In-Reply-To: <200904151856.58401.martin.konold@erfrakon.de> References: <20090408110616.GB8599.thomas@intevation.de> <200904151433.42343.marc.schiffbauer@mightycare.de> <200904151856.58401.martin.konold@erfrakon.de> Message-ID: <200904160945.10019.marc.schiffbauer@mightycare.de> Am Mittwoch, 15. April 2009 18:56:57 schrieb Martin Konold: > Am Mittwoch, 15. April 2009 14:33:42 schrieb Marc Schiffbauer: > > Hallo Marc, Hallo Martin, > > > Wäre es nicht vielleicht besser, hier einen eigenen config-Parameter > > einzuführen, der dann die cookie-Domain einstellt? > > Dazu muss ich erst verstehen in welchen Zusammenhängen dieses Problem > auftritt, ob das häufiger der Fall ist und ob wir die Default-Einstellung > gut wählen können. Ich denke, dass es fast immer dann auftreten wird, wenn man einen Proxy benutzt um auf das Kolab-Webinterface zuzugreifen und dabei der äußere Hostname nicht dem eigentlichen FQDN des Kolab-Servers entspricht. Saubere default Einstellung wäre dann, es auch einfach auf den FQDN zu setzen. Aus /kolab/etc/kolab/kolab.conf fqdnhostname : kolab.example.com Dazu käme dann vielleicht sowas: hordehostname : kolab.example.com Damit sollte dann eine Zeile in /kolab/etc/kolab/templates/webclient-kolab- conf.template ersetzt werden: -$conf['cookie']['domain'] = '@@@fqdnhostname@@@'; +$conf['cookie']['domain'] = '@@@hordehostname@@@'; > > > Weitere Probleme gibt es, wenn der Horde-Client mit verschiedenen > > Hostnamen im http-Header angesprochen werden können soll (z.B interne und > > externe Adresse). Was dann? > > Ich kenne mich mit Horde nicht so gut aus. Ich vermute Horde kann das nicht > so out-of-the-box? Ich bin da auch (noch) kein Spezi. Aber out-of-the-box funktioniert es ja eben nicht. Damit es jetzt funktioniert muss man auf jeden Fall das Template ändern. Ich weiss jetzt nicht ob es vielleicht auch eine andere EInstellung gibt, sodass die cookie-domain wieder nicht dem HTTP-Hostname entsprechen muss, so wie es vorher in kolab <= 2.2.0 war. Gruß -Marc -- Senior Consultant :: Solution Architect IT-Security :: Free Software :: GNU/Linux Mobile +49_151_16227402 :: Fon +49_6187_9058695 :: Fax +49_6187_900157 MightyCare Solutions GmbH http://www.mightycare.de Firmenangaben unter http://www.mightycare.de/#/de/impressum/ From jphorst at sciencebridge.de Thu Apr 16 10:24:26 2009 From: jphorst at sciencebridge.de (JP Horst) Date: Thu, 16 Apr 2009 10:24:26 +0200 Subject: Kolab Server 2.2.1 =?iso-8859-1?q?ver=F6ffentlicht?= In-Reply-To: <200904160945.10019.marc.schiffbauer@mightycare.de> References: <20090408110616.GB8599.thomas@intevation.de> <200904151856.58401.martin.konold@erfrakon.de> <200904160945.10019.marc.schiffbauer@mightycare.de> Message-ID: <200904161024.27081.jphorst@sciencebridge.de> Am Donnerstag, 16. April 2009 09:45:09 schrieb Marc Schiffbauer: > Am Mittwoch, 15. April 2009 18:56:57 schrieb Martin Konold: > > Am Mittwoch, 15. April 2009 14:33:42 schrieb Marc Schiffbauer: > > > > Hallo Marc, > > Hallo Martin, > > > > Wäre es nicht vielleicht besser, hier einen eigenen config-Parameter > > > einzuführen, der dann die cookie-Domain einstellt? > > > > Dazu muss ich erst verstehen in welchen Zusammenhängen dieses Problem > > auftritt, ob das häufiger der Fall ist und ob wir die Default-Einstellung > > gut wählen können. > > Ich denke, dass es fast immer dann auftreten wird, wenn man einen Proxy > benutzt um auf das Kolab-Webinterface zuzugreifen und dabei der äußere > Hostname nicht dem eigentlichen FQDN des Kolab-Servers entspricht. > Das Problem muß nicht immer ein Proxy sein. Bei uns befindet sich der Kolabserver in einem internen Netz, verwaltet aber emails unter unserer offiziellen Domäne. Da bisher in dem DNS der Firewall kein statischer Eintrag für den Kolabserver eingetragen war, wurde der unter seinem offiziellen Namen nicht gefunden. Wir haben daher bisher per IP Adresse auf die Weboberflächen zugegriffen. Zugegeben, unser Problem läßt sich auch auf der DNS Ebene lösen, wenn man es denn weiß. Bisher war das ja auch kein Problem. > Saubere default Einstellung wäre dann, es auch einfach auf den FQDN zu > setzen. > > Aus /kolab/etc/kolab/kolab.conf > > fqdnhostname : kolab.example.com > > Dazu käme dann vielleicht sowas: > > hordehostname : kolab.example.com > > Damit sollte dann eine Zeile in /kolab/etc/kolab/templates/webclient-kolab- > conf.template ersetzt werden: > > -$conf['cookie']['domain'] = '@@@fqdnhostname@@@'; > +$conf['cookie']['domain'] = '@@@hordehostname@@@'; > > > > Weitere Probleme gibt es, wenn der Horde-Client mit verschiedenen > > > Hostnamen im http-Header angesprochen werden können soll (z.B interne > > > und externe Adresse). Was dann? > > > > Ich kenne mich mit Horde nicht so gut aus. Ich vermute Horde kann das > > nicht so out-of-the-box? > > Ich bin da auch (noch) kein Spezi. Aber out-of-the-box funktioniert es ja > eben nicht. Damit es jetzt funktioniert muss man auf jeden Fall das > Template ändern. > > Ich weiss jetzt nicht ob es vielleicht auch eine andere EInstellung gibt, > sodass die cookie-domain wieder nicht dem HTTP-Hostname entsprechen muss, > so wie es vorher in kolab <= 2.2.0 war. > > Gruß > -Marc From thomas at intevation.de Thu Apr 16 17:44:00 2009 From: thomas at intevation.de (Thomas Arendsen Hein) Date: Thu, 16 Apr 2009 17:44:00 +0200 Subject: Kolab Server 2.2.1 =?iso-8859-15?Q?ver?= =?iso-8859-15?Q?=F6ffentlicht?= In-Reply-To: <200904151433.42343.marc.schiffbauer@mightycare.de> References: <20090408110616.GB8599.thomas@intevation.de> <200904151112.33344.jphorst@sciencebridge.de> <200904151124.02501.martin.konold@erfrakon.de> <200904151433.42343.marc.schiffbauer@mightycare.de> Message-ID: <20090416154359.GD9750.thomas@intevation.de> * Marc Schiffbauer [20090415 14:33]: > Wäre es nicht vielleicht besser, hier einen eigenen config-Parameter > einzuführen, der dann die cookie-Domain einstellt? > > Weitere Probleme gibt es, wenn der Horde-Client mit verschiedenen Hostnamen im > http-Header angesprochen werden können soll (z.B interne und externe Adresse). > Was dann? Bisher geht ein Kolab-Server immer davon aus, dass er immer unter dem gleichen (eigenen) Hostnamen angesprochen wird, z.B. auch bei Redirects und dem selbst-generierten SSL-Zertifikat. Fuer interne vs. externe Adresse empfehle ich ein entsprechendes DNS-Setup oder notfalls /etc/hosts auf dem Kolab-Server und Weiterleitung der externen IP auch fuer Rechner im LAN. Zusaetzlicher Vorteil: Laptops muessen nicht staendig umkonfiguriert werden, wenn sie mal im LAN und mal unterwegs auf den Kolab-Server zugreifen sollen. Gruesse, 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 From bernhard at intevation.de Thu Apr 16 17:51:29 2009 From: bernhard at intevation.de (Bernhard Reiter) Date: Thu, 16 Apr 2009 17:51:29 +0200 Subject: Verzeichnisdienst =?iso-8859-1?q?Multi-Domain-f=E4hig=3F?= (war: Kolab Server 2.2.1 =?iso-8859-1?q?ver=F6ffentlicht?=) In-Reply-To: <200904081430.56637.glua@4-mail.net> References: <20090408110616.GB8599.thomas@intevation.de> <200904081430.56637.glua@4-mail.net> Message-ID: <200904161751.34450.bernhard@intevation.de> On Wednesday 08 April 2009, Julian Golderer wrote: > Gibt es Ansätze des LDAP- > Adressbuch Multi-Domain-fähig zu machen? Es kann sein, dass bei der folgenden Erweiterung was dazu dabei ist https://www.intevation.de/roundup/kolab/issue3463 -- 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 -------------- nächster Teil -------------- Ein Dateianhang mit Binärdaten wurde abgetrennt... Dateiname : nicht verfügbar Dateityp : application/pgp-signature Dateigröße : 198 bytes Beschreibung: This is a digitally signed message part. URL : http://lists.wald.intevation.org/pipermail/kolab-users-de/attachments/20090416/814dd83d/attachment.pgp From bernhard at intevation.de Thu Apr 16 18:02:15 2009 From: bernhard at intevation.de (Bernhard Reiter) Date: Thu, 16 Apr 2009 18:02:15 +0200 Subject: Kritik an Kolab-Entwicklung In-Reply-To: <200904091458.09748.glua@4-mail.net> References: <200904081726.34947.glua@4-mail.net> <20090409082922.GC5149.thomas@intevation.de> <200904091458.09748.glua@4-mail.net> Message-ID: <200904161802.19947.bernhard@intevation.de> Hallo Julian, On Thursday 09 April 2009, Julian Golderer wrote: > Am Donnerstag 09 April 2009 10:29:22 schrieb Thomas Arendsen Hein: > > * Julian Golderer [20090408 17:26]: > Was ich damit meine, ist, dass es einen Plan braucht - z.b. meine > Wunsch-Ziele für Kolab3: Als nächstes gemacht wird, was die Entwickler und manche Kunden als nächstes möchten. Einen Plan anzukündigen, der dann nichts wird ist noch frustrierender als kein Plan. Weiterhin stehen in unserem Roundup ein Haufen interessanter Wünsche drin. > > > * als Versionskontrolle kommt noch immer das unhandliche CVS zum > > > Einsatz Die möglichen Vorteile eines anderen Systems sind für die momentane Kolab Server Entwicklung nicht entscheidend. Insofern ist ein Wechsel nicht hoch auf der Liste. Ähnliches gilt für eine "Entwicklungsplattform". Mit Allem haben wir durchaus Erfahrung. Die KDE Klientenentwicklung nutzt übrigens das KDE SVN. Horde (die Grundlage des Webklientens) zieht auf git um (was ich für ein Problem halte, da der Umzug gleichzeitig mit anderen wichtigeren Dingen einhergeht.) > > Fuer mich ist SVN noch unhandlicher. Was genau fehlt denn? > > Und ja, ich moechte auch auf Mercurial wechseln, aber hier gibt es > > noch ein paar Hindernisse, u.a.: > Ich würde, wie Marc, git bevorzugen :) Eine Diskussion der Vor- und Nachteile von git, bzr und hg fände ich hier nicht so spannend. Bei Intevation bevorzugen wir hg, aus ähnlichen Gründen wie vermutlich die Python Gemeinschaft. > > > * es fehlt ein Entwickler-Blog, damit auch Außenstehende etwas vom > > > Geschehen mitbekommen > > > > Die Entwickler sollen lieber entwickeln als Blogs schreiben :) > > Ein Beitrag die Woche würde genügen und es würde aus meiner Sicht den > Einstieg für externe Entwickler erleichtern. Die dev-Liste hat relativ viel > Traffic, weshalb ich als (noch) Außenstehender den Blog als > Diskussionsplattform bevorzugen würde. Wenn sich eine Gruppe von Leuten findet, welche einen Blog schreiben und die Software dazu pflegen möchten, dann machen wir halt einen. ;) > > Ansonsten versuchen wir nach Moeglichkeit, interessante Dinge auf > > der kolab-devel-Mailingliste zu schreiben. > > > > Vielleicht findet sich ja ein Community-Mitglied (z.B. Du?), welches > > die Entwicklung beobachtet und darueber berichtet und ggf. auch mal > > fragt, was denn da nun gerade im Hintergrund passiert :) > > Wäre eine machbare Möglichkeit :) Das wär super. :) 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 -------------- nächster Teil -------------- Ein Dateianhang mit Binärdaten wurde abgetrennt... Dateiname : nicht verfügbar Dateityp : application/pgp-signature Dateigröße : 198 bytes Beschreibung: This is a digitally signed message part. URL : http://lists.wald.intevation.org/pipermail/kolab-users-de/attachments/20090416/63dca5a6/attachment.pgp From marc.schiffbauer at mightycare.de Thu Apr 16 22:00:55 2009 From: marc.schiffbauer at mightycare.de (Marc Schiffbauer) Date: Thu, 16 Apr 2009 22:00:55 +0200 Subject: Kolab Server 2.2.1 =?iso-8859-1?q?ver=F6ffentlicht?= In-Reply-To: <20090416154359.GD9750.thomas@intevation.de> References: <20090408110616.GB8599.thomas@intevation.de> <200904151433.42343.marc.schiffbauer@mightycare.de> <20090416154359.GD9750.thomas@intevation.de> Message-ID: <200904162200.55283.marc.schiffbauer@mightycare.de> Am Donnerstag, 16. April 2009 17:44:00 schrieb Thomas Arendsen Hein: > * Marc Schiffbauer [20090415 14:33]: > > Wäre es nicht vielleicht besser, hier einen eigenen config-Parameter > > einzuführen, der dann die cookie-Domain einstellt? > > > > Weitere Probleme gibt es, wenn der Horde-Client mit verschiedenen > > Hostnamen im http-Header angesprochen werden können soll (z.B interne und > > externe Adresse). Was dann? > > Bisher geht ein Kolab-Server immer davon aus, dass er immer unter > dem gleichen (eigenen) Hostnamen angesprochen wird, z.B. auch bei > Redirects und dem selbst-generierten SSL-Zertifikat. Was hier - ausser bei Webzugriff - auch völlig ok ist. Ausserdem können ja zusätzlich zum eigenen FQDN noch zusätzliche Mail-Domains konfiguriert werden. > > Fuer interne vs. externe Adresse empfehle ich ein entsprechendes > DNS-Setup oder notfalls /etc/hosts auf dem Kolab-Server und > Weiterleitung der externen IP auch fuer Rechner im LAN. > Das ist nicht so einfach, da Mails zunächst auf dem Host angenommen werden der auch den Hostnamen für das Webmail stellt: Unser externes Mail-Gateway. Das Mailgateway liefert je nach Empfänger an den Kolab oder den anderen "Mailserver" aus. +----------+ | ext. MTA | +----+-----+ | +------+--------+ | | +---+---+ +-----+----+ | kolab |<--->| exchange | +-------+ +----------+ > Zusaetzlicher Vorteil: > Laptops muessen nicht staendig umkonfiguriert werden, wenn sie mal > im LAN und mal unterwegs auf den Kolab-Server zugreifen sollen. > Das Problem stellt sich hier nicht, da IMAP eh nur über VPN-Zugänglich ist und hier dann auch immer die internen Hostnamen verwendet werden können. Webmail hingegen ist auch ohne VPN zugänglich Gruß -Marc -- Senior Consultant :: Solution Architect IT-Security :: Free Software :: GNU/Linux Mobile +49_151_16227402 :: Fon +49_6187_9058695 :: Fax +49_6187_900157 MightyCare Solutions GmbH http://www.mightycare.de Firmenangaben unter http://www.mightycare.de/#/de/impressum/ From wrobel at pardus.de Fri Apr 17 05:36:10 2009 From: wrobel at pardus.de (Gunnar Wrobel) Date: Fri, 17 Apr 2009 05:36:10 +0200 Subject: Kolab und CMS In-Reply-To: <200904081522.34585.bbuehler@bbm-bbmicro.ch> References: <200904081522.34585.bbuehler@bbm-bbmicro.ch> Message-ID: <20090417053610.91314gmyuszwu9s0@webmail.pardus.de> Quoting "B. Buehler" : > Hallo Liste > > gibt es Kolab-Installationen die mit einem CMS in Kombination betrieben > werden? > > Ich habe ein solches Projekt zu lösen, mich aber noch nicht entschieden > welches CMS dafür in Frage kommen könnte. Ich hoffe auf ein Feedback von der > Gemeinde um nicht bei "Adam und Eva" beginnen zu müssen. Die meisten CMS setzen auf Apache/PHP mit einer MySQL-Datenbank im Hintergrund auf. Das sollte mit der Apache/PHP-Konfiguration auf dem Kolab-Server kein Problem sein. Die Datenbank sollte man dann vorzugsweise auf einem anderen Server betreiben. Aber ein CMS das besonders gut für den Kolab-Server geeignet gibt es meines Wissens nicht. Im Bereich CMS zählen doch eigentlich mehr die eigenen Wünsche an das CMS, oder? Schließlich gibt es tausende CMS die alle hier und da etwas unterschiedliche Bedürfnisse abdecken. Gruß, Gunnar > > Herzlichen Dank für alle Antworten. > > Grüsse > -- > Bernhard Bühler > > _______________________________________________ > Kolab-users-de mailing list > Kolab-users-de at kolab.org > http://lists.wald.intevation.org/mailman/listinfo/kolab-users-de > -- ______ 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 : http://lists.wald.intevation.org/pipermail/kolab-users-de/attachments/20090417/96dbdd7a/attachment.pgp From wrobel at pardus.de Fri Apr 17 05:42:36 2009 From: wrobel at pardus.de (Gunnar Wrobel) Date: Fri, 17 Apr 2009 05:42:36 +0200 Subject: Kolab Server 2.2.1 =?utf-8?b?dmVyw7ZmZmVudGxpY2h0?= In-Reply-To: <200904151124.02501.martin.konold@erfrakon.de> References: <20090408110616.GB8599.thomas@intevation.de> <200904141821.17495.marc.schiffbauer@mightycare.de> <200904151112.33344.jphorst@sciencebridge.de> <200904151124.02501.martin.konold@erfrakon.de> Message-ID: <20090417054236.199835aghcv0l8mc@webmail.pardus.de> Quoting Martin Konold : > Am Mittwoch, 15. April 2009 11:12:33 schrieb JP Horst: > > Hi, > >> > das Problem hatte ich auch. Bei mir lag es daran, dass die cookie-domain >> > nicht stimmte. > >> das hat das Problem in der Tat gelöst. > > Bitte mach einen entsprechenden Wiki Artikel. Die Sektion "Troubleshooting" listet das schon seit geraumer Zeit, weil das eines der Standard-Probleme mit Horde auf dem Kolab-Server ist: http://wiki.kolab.org/index.php/Kolab2_Server_Troubleshooting_-_Horde#On_login_I.27m_returned_to_the_login_screen_without_an_error_message Gruß, Gunnar > > Danke, > -- martin > > -- > e r f r a k o n > Erlewein, Frank, Konold & Partner - Beratende Ingenieure und Physiker > Sitz: Adolfstraße 23, 70469 Stuttgart, Partnerschaftsregister > Stuttgart PR 126 > http://www.erfrakon.com/ > _______________________________________________ > Kolab-users-de mailing list > Kolab-users-de at kolab.org > http://lists.wald.intevation.org/mailman/listinfo/kolab-users-de > -- ______ 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 : http://lists.wald.intevation.org/pipermail/kolab-users-de/attachments/20090417/70e89197/attachment-0001.pgp From wrobel at pardus.de Fri Apr 17 06:23:18 2009 From: wrobel at pardus.de (Gunnar Wrobel) Date: Fri, 17 Apr 2009 06:23:18 +0200 Subject: Horde Performance / Apache Module In-Reply-To: <200904151452.45300.hansjoerg.schwarz@stmartin-schwabach.de> References: <200904151452.45300.hansjoerg.schwarz@stmartin-schwabach.de> Message-ID: <20090417062318.20262xmxoviuf6g4@webmail.pardus.de> Quoting Hansjörg Schwarz : > Hallo allerseits, > ich habe beim neuen Kolab 2.2.1 (OpenPkg auf Debian) den Performance > Grade von > Horde mit Firefox/YSlow gemessen und komme dabei auf schlechte Werte je nach > Modul und Inhalt von F40 bis F44. > Daher würde ich gerne zumindest die einfachen Optimierungen > Expires-Header und > Komprimierung durchführen. Ich denke andere Stellen wären da vermutlich effizienter. Wir haben da in Punkto Kolab web client noch ein bisschen Optimierungsarbeit vor uns. > Leider habe ich feststellen müssen, daß der Apache > aus der OpenPkg-Installation kein mod_deflate und kein mod_expires mitbringt. > Daher meine Frage: wie kann ich diese Module auf einfache Art und Weise > nachrüsten? Ich würde mal gucken, ob OpenPKG da schon Pakete anbietet. Die ließen sich am schnellsten einbinden. Ansonsten bleibt wohl nur Kompilieren aus dem Quellcode. Gruß, Gunnar > Vielen Dank im voraus > Hansjörg Schwarz > > > > _______________________________________________ > Kolab-users-de mailing list > Kolab-users-de at kolab.org > http://lists.wald.intevation.org/mailman/listinfo/kolab-users-de > -- ______ 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 : http://lists.wald.intevation.org/pipermail/kolab-users-de/attachments/20090417/754aac82/attachment.pgp From marc.schiffbauer at mightycare.de Fri Apr 17 16:47:58 2009 From: marc.schiffbauer at mightycare.de (Marc Schiffbauer) Date: Fri, 17 Apr 2009 16:47:58 +0200 Subject: Kolab Server 2.2.1 =?iso-8859-1?q?ver=F6ffentlicht?= In-Reply-To: <20090417054236.199835aghcv0l8mc@webmail.pardus.de> References: <20090408110616.GB8599.thomas@intevation.de> <200904151124.02501.martin.konold@erfrakon.de> <20090417054236.199835aghcv0l8mc@webmail.pardus.de> Message-ID: <200904171647.59029.marc.schiffbauer@mightycare.de> Am Freitag, 17. April 2009 05:42:36 schrieb Gunnar Wrobel: > Quoting Martin Konold : > > Am Mittwoch, 15. April 2009 11:12:33 schrieb JP Horst: > > > > Hi, > > > >> > das Problem hatte ich auch. Bei mir lag es daran, dass die > >> > cookie-domain nicht stimmte. > >> > >> das hat das Problem in der Tat gelöst. > > > > Bitte mach einen entsprechenden Wiki Artikel. > > Die Sektion "Troubleshooting" listet das schon seit geraumer Zeit, > weil das eines der Standard-Probleme mit Horde auf dem Kolab-Server ist: > > http://wiki.kolab.org/index.php/Kolab2_Server_Troubleshooting_-_Horde#On_lo >gin_I.27m_returned_to_the_login_screen_without_an_error_message Ja, danke. Hatt ich auch schon gesehn. Allerdings wird dort aber noch nicht auf "unser" Problem hier eingegangen. Der Effekt ist zwar der gleiche, aber Ursache und Lösung sind anders. Gruß -Marc -- Senior Consultant :: Solution Architect IT-Security :: Free Software :: GNU/Linux Mobile +49_151_16227402 :: Fon +49_6187_9058695 :: Fax +49_6187_900157 MightyCare Solutions GmbH http://www.mightycare.de Firmenangaben unter http://www.mightycare.de/#/de/impressum/ From bbuehler at bbm-bbmicro.ch Sat Apr 18 11:22:17 2009 From: bbuehler at bbm-bbmicro.ch (B. Buehler) Date: Sat, 18 Apr 2009 11:22:17 +0200 Subject: Kolab und CMS In-Reply-To: <20090417053610.91314gmyuszwu9s0@webmail.pardus.de> References: <200904081522.34585.bbuehler@bbm-bbmicro.ch> <20090417053610.91314gmyuszwu9s0@webmail.pardus.de> Message-ID: <200904181122.18335.bbuehler@bbm-bbmicro.ch> Hallo Gunnar besten Dank für deine Antwort und deren Infos. Werde mich demzufolge mal auf den Inhalt der CMS konzentrieren und dann mal so umsetzen. Grüsse Bernhard Am Freitag, 17. April 2009 05.36:10 schrieb Gunnar Wrobel: > Quoting "B. Buehler" : > > Hallo Liste > > > > gibt es Kolab-Installationen die mit einem CMS in Kombination betrieben > > werden? > > > > Ich habe ein solches Projekt zu lösen, mich aber noch nicht entschieden > > welches CMS dafür in Frage kommen könnte. Ich hoffe auf ein Feedback von > > der Gemeinde um nicht bei "Adam und Eva" beginnen zu müssen. > > Die meisten CMS setzen auf Apache/PHP mit einer MySQL-Datenbank im > Hintergrund auf. Das sollte mit der Apache/PHP-Konfiguration auf dem > Kolab-Server kein Problem sein. Die Datenbank sollte man dann > vorzugsweise auf einem anderen Server betreiben. > > Aber ein CMS das besonders gut für den Kolab-Server geeignet gibt es > meines Wissens nicht. Im Bereich CMS zählen doch eigentlich mehr die > eigenen Wünsche an das CMS, oder? Schließlich gibt es tausende CMS die > alle hier und da etwas unterschiedliche Bedürfnisse abdecken. > > Gruß, > > Gunnar > > > Herzlichen Dank für alle Antworten. > > > > Grüsse > > -- > > Bernhard Bühler > > > > _______________________________________________ > > Kolab-users-de mailing list > > Kolab-users-de at kolab.org > > http://lists.wald.intevation.org/mailman/listinfo/kolab-users-de From wrobel at pardus.de Sun Apr 19 06:11:09 2009 From: wrobel at pardus.de (Gunnar Wrobel) Date: Sun, 19 Apr 2009 06:11:09 +0200 Subject: Kritik an Kolab-Entwicklung In-Reply-To: <200904161802.19947.bernhard@intevation.de> References: <200904081726.34947.glua@4-mail.net> <20090409082922.GC5149.thomas@intevation.de> <200904091458.09748.glua@4-mail.net> <200904161802.19947.bernhard@intevation.de> Message-ID: <20090419061109.16855f9c2pmcdisc@webmail.pardus.de> Quoting Bernhard Reiter : > Hallo Julian, > > On Thursday 09 April 2009, Julian Golderer wrote: >> Am Donnerstag 09 April 2009 10:29:22 schrieb Thomas Arendsen Hein: >>> * Julian Golderer [20090408 17:26]: > >> Was ich damit meine, ist, dass es einen Plan braucht - z.b. meine >> Wunsch-Ziele für Kolab3: > > Als nächstes gemacht wird, was die Entwickler und manche Kunden als nächstes > möchten. > Einen Plan anzukündigen, der dann nichts wird ist noch > frustrierender als kein > Plan. Weiterhin stehen in unserem Roundup ein Haufen interessanter Wünsche > drin. Hier möchte ich Bernhard absolut beipflichten. Nur mal als Beispiel: Seit ca. vier Jahren ist mir aus der Entwicklersicht der PHP Code des kolab-webadmin auf Grund seiner schlechten Qualität ein echter Dorn im Auge. Auf meiner internen Roadmap also sehr weit oben. Sogar einen Ansatz zum Recoding des Tools habe ich hinbekommen. Allerdings bin ich da aus Zeitgründen gescheitert. Und nun hat mich (bzw. uns) ein Auftrag dem neuen Webadmin näher gebracht als ich in den letzten Monaten hätte absehen können. Der Kolab-Server hat noch keine so dicke finanzielle Absicherung, dass wir Elemente auf Monate bzw. Jahre planen können. Wäre wünschenswert aber ich denke man kann schon froh sein, dass der Server als freie Software so gut voran kommt wie er das momentan tut. Wir alle haben sehr gut zu tun aber wir können uns nicht einfach so von den Kundenwünschen lösen. Und die Finanzierung von Seiten der Kunden sind ja letztlich auch etwas das der Community zu Gute kommt. Das lässt sich aus meiner Sicht problemlos gegen eine fehlende langfristige Roadmap eintauschen ;) > >>> > * als Versionskontrolle kommt noch immer das unhandliche CVS zum >>> > Einsatz > > Die möglichen Vorteile eines anderen Systems sind für die momentane Kolab > Server Entwicklung nicht entscheidend. Insofern ist ein Wechsel > nicht hoch auf > der Liste. Ähnliches gilt für eine "Entwicklungsplattform". > Mit Allem haben wir durchaus Erfahrung. > > Die KDE Klientenentwicklung nutzt übrigens das KDE SVN. > Horde (die Grundlage des Webklientens) zieht auf git um (was ich für ein > Problem halte, da der Umzug gleichzeitig mit anderen wichtigeren Dingen > einhergeht.) Ja, ja ;) - das ist weniger problematisch als Du annimmst. Grüße, Gunnar > >>> Fuer mich ist SVN noch unhandlicher. Was genau fehlt denn? >>> Und ja, ich moechte auch auf Mercurial wechseln, aber hier gibt es >>> noch ein paar Hindernisse, u.a.: >> Ich würde, wie Marc, git bevorzugen :) > > Eine Diskussion der Vor- und Nachteile von git, bzr und hg fände ich hier > nicht so spannend. Bei Intevation bevorzugen wir hg, aus ähnlichen > Gründen wie > vermutlich die Python Gemeinschaft. > >>> > * es fehlt ein Entwickler-Blog, damit auch Außenstehende etwas vom >>> > Geschehen mitbekommen >>> >>> Die Entwickler sollen lieber entwickeln als Blogs schreiben :) >> >> Ein Beitrag die Woche würde genügen und es würde aus meiner Sicht den >> Einstieg für externe Entwickler erleichtern. Die dev-Liste hat relativ viel >> Traffic, weshalb ich als (noch) Außenstehender den Blog als >> Diskussionsplattform bevorzugen würde. > > Wenn sich eine Gruppe von Leuten findet, welche einen Blog schreiben und die > Software dazu pflegen möchten, dann machen wir halt einen. ;) > >>> Ansonsten versuchen wir nach Moeglichkeit, interessante Dinge auf >>> der kolab-devel-Mailingliste zu schreiben. >>> >>> Vielleicht findet sich ja ein Community-Mitglied (z.B. Du?), welches >>> die Entwicklung beobachtet und darueber berichtet und ggf. auch mal >>> fragt, was denn da nun gerade im Hintergrund passiert :) >> >> Wäre eine machbare Möglichkeit :) > > Das wär super. :) > 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 > > -- ______ 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 : http://lists.wald.intevation.org/pipermail/kolab-users-de/attachments/20090419/37382d0d/attachment.pgp From schmidt at ix-tech.de Tue Apr 21 21:10:52 2009 From: schmidt at ix-tech.de (=?utf-8?q?J=C3=BCrgen_Schmidt?=) Date: Tue, 21 Apr 2009 21:10:52 +0200 Subject: Mailbox bei neuen Usern erscheint nicht Message-ID: <200904212110.53134.schmidt@ix-tech.de> Hallo, ich habe kolab server 2.2.1 auf einem debian lenny 64bit in einer VMware und in einem VServer installiert. Zweimal habe ich den gleichen Fehler. Sobald ich einen Benutzer anlege kann ich mich per imaps oder horde anmelden, allerdings - auf Grund des nicht angelegten Mailfolders - sonst nichts machen. Die Fehlermeldung lautet "Der Ordner "Gesendet" konnte nicht erstellt werden. Meldung des E-Mail-Servers: Permission denied" 'ls var/imapd/domain/s/test.de/user/' zeigt mir den Mailfolder des neu angelegten Users nicht an. Ein Neustarte des kolabd bringt hier abhilfe. ' /kolab/bin/openpkg rc kolabd restart' anschließend ist der Mailfolder da alles läuft wie gewohnt. Wo könnte denn hier der Hund begraben liegen? Gruß Jürgen From sseeberg at gisny.de Tue Apr 21 21:30:06 2009 From: sseeberg at gisny.de (Sven Seeberg) Date: Tue, 21 Apr 2009 21:30:06 +0200 Subject: Problem mit kolabconf nach Update auf 2.21 Message-ID: <49EE1EBE.5000604@gisny.de> Hallo Liste, beim Update von 2.2.1 (beta1) auf 2.2.1 tritt bei mir ein Fehler auf. Genauer gesagt beim anschließenden regenerieren der Konfigurationsdateien. Bei der Installation bin ich nach der Readme vorgegangen, dh 1. install-kolab.sh ausgeführt 2. die rpmsave Dateien gelöscht 3. kolabconf -n ausgeführt Bei 3. kommt dann der Fehler. LDAP server läuft. /kolab/sbin/kolabconf -n Use of uninitialized value in concatenation (.) or string at /kolab/lib/perl/vendor_perl/5.10.0/Kolab.pm line 174. Password verification failed. Use of uninitialized value $Kolab::config{"base_dn"} in concatenation (.) or string at /kolab/lib/perl/vendor_perl/5.10.0/Kolab.pm line 190. Use of uninitialized value $Kolab::config{"bind_dn"} in concatenation (.) or string at /kolab/lib/perl/vendor_perl/5.10.0/Kolab.pm line 204. Error loading configuration. Maybe the LDAP server is not running. Please check the system log for errors. Kann mir irgendwer ein Tipp geben, wie ich weitermachen kann? Ich bin momentan etwas ratlos. Ich weiß auch nicht welche log ich da konsultieren sollte. Vielen Dank und Grüße Sven Seeberg From sseeberg at gisny.de Tue Apr 21 22:16:43 2009 From: sseeberg at gisny.de (Sven Seeberg) Date: Tue, 21 Apr 2009 22:16:43 +0200 Subject: Problem mit kolabconf nach Update auf 2.21 In-Reply-To: <49EE1EBE.5000604@gisny.de> References: <49EE1EBE.5000604@gisny.de> Message-ID: <49EE29AB.1070006@gisny.de> Hallo Liste, das Problem ist gelöst. Ich bin von einer falschen Versionsnummer ausgegangen. Es war noch 2.2.0 ... das hat dann ohne Probleme nach der Readme funktioniert. Grüße Sven Seeberg schrieb: > Hallo Liste, > > beim Update von 2.2.1 (beta1) auf 2.2.1 tritt bei mir ein Fehler auf. > Genauer gesagt beim anschließenden regenerieren der Konfigurationsdateien. > Bei der Installation bin ich nach der Readme vorgegangen, dh > 1. install-kolab.sh ausgeführt > 2. die rpmsave Dateien gelöscht > 3. kolabconf -n ausgeführt > Bei 3. kommt dann der Fehler. LDAP server läuft. > > /kolab/sbin/kolabconf -n > Use of uninitialized value in concatenation (.) or string at > /kolab/lib/perl/vendor_perl/5.10.0/Kolab.pm line 174. > Password verification failed. > Use of uninitialized value $Kolab::config{"base_dn"} in concatenation > (.) or string at /kolab/lib/perl/vendor_perl/5.10.0/Kolab.pm line 190. > Use of uninitialized value $Kolab::config{"bind_dn"} in concatenation > (.) or string at /kolab/lib/perl/vendor_perl/5.10.0/Kolab.pm line 204. > Error loading configuration. Maybe the LDAP server is not running. > Please check the system log for errors. > > Kann mir irgendwer ein Tipp geben, wie ich weitermachen kann? Ich bin > momentan etwas ratlos. Ich weiß auch nicht welche log ich da > konsultieren sollte. > > Vielen Dank und Grüße > Sven Seeberg > > _______________________________________________ > Kolab-users-de mailing list > Kolab-users-de at kolab.org > http://lists.wald.intevation.org/mailman/listinfo/kolab-users-de > > From thomas at intevation.de Wed Apr 22 11:58:43 2009 From: thomas at intevation.de (Thomas Arendsen Hein) Date: Wed, 22 Apr 2009 11:58:43 +0200 Subject: Mailbox bei neuen Usern erscheint nicht In-Reply-To: <200904212110.53134.schmidt@ix-tech.de> References: <200904212110.53134.schmidt@ix-tech.de> Message-ID: <20090422095843.GB9093.thomas@intevation.de> * Jürgen Schmidt [20090421 21:11]: > 'ls var/imapd/domain/s/test.de/user/' zeigt mir den Mailfolder des neu > angelegten Users nicht an. Ein Neustarte des kolabd bringt hier abhilfe. > > ' /kolab/bin/openpkg rc kolabd restart' > > anschließend ist der Mailfolder da alles läuft wie gewohnt. Wo könnte denn > hier der Hund begraben liegen? Der kolabd erwartet auf Port 9999 von OpenLDAP-Server ueber aenderungen informiert zu werden, nur dann legt er neue Mailfolder an. Zur Analyse wuerde ich empfehlen, den kolabd anzuhalten, in /kolab/etc/kolab/kolab.conf die Zeile "debug : 1" anzuhaengen und danach als root den kolabd von Hand starten mit: # /kolab/sbin/kolabd Hier kommen viele Meldungen, also ggf. die Ausgaben umleiten: # /kolab/sbin/kolabd 2>&1 | tee /root/kolabd-debug.log Eine moegliche Fehlerquelle ist, wenn der angegebene Kolab-Hostname nicht der echte Hostname des Rechners ist. Gruesse, 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 From bbuehler at bbm-bbmicro.ch Sat Apr 25 15:00:37 2009 From: bbuehler at bbm-bbmicro.ch (B. Buehler) Date: Sat, 25 Apr 2009 15:00:37 +0200 Subject: Kolab MySQL Integration Message-ID: <200904251500.40095.bbuehler@bbm-bbmicro.ch> Hallo Liste ich möchte für ein CMS Kolab mit MySQL (und ev. xslt) ergänzen. Dazu habe ich von OpenPKG mysql-5.1.34-20090420.src.rpm runtergeladen. Gemäss Kolab-Wiki "HowTo extend the Kolab Server" habe ich: /kolab/bin/openpkg rpm --rebuild mysql-5.1.34-20090420.src.rpm ohne Fehler compiliert, dann: /kolab/bin/openpkg rpm -ihv /kolab/RPM/PKG/mysql-5.1.34-20090420.ix86- suse10.3-kolab.rpm installiert. Habe danach install.sh ergänzt mit "-D php::with_xslt -D php::with_mysql" PACKAGES="openpkg-tools openldap postfix kolabd kolab-webadmin kolab-fbview kolab-webclient" DEFINE="-D openldap::with_pth=no -D sasl::with_ldap -D sasl::with_login -D sasl::with_ntlm -D postfix::with_sasl -D postfix::with_ssl -D postfix::with_ldap -D imapd::with_kolab_nocaps -D php::with_xslt -D php::with_mysql" EXCLUDEPKGS="" Update mit: # sh install-kolab.sh 2>&1 | tee /root/kolab-update.log Changing to temporary working directory /tmp/install- kolab.29227.10457.28258.24075 ... Kolab installation tag (TAG): kolab Kolab installation prefix (PREFIX): /kolab Kolab version (KOLAB_VERSION): 2.2.1 Kolab user name (USER): kolab Kolab user base UID (KID): 19414 Kolab restricted UID (KID): 19415 Kolab non-priviledged UID (KID): 19416 Exclude following Kolab packages: Received no instructions. Trying to determine required action... Found an OpenPKG environment. Assuming upgrade... ----------- SETUP COMPLETED ----------- Now running: /kolab/bin/openpkg build -kKBuZ -r "/tmp/install- kolab.29227.10457.28258.24075" -p "ix86-suse10.3-kolab" -D openldap::with_pth=no -D sasl::with_ldap -D sasl::with_login -D sasl::with_ntlm -D postfix::with_sasl -D postfix::with_ssl -D postfix::with_ldap -D imapd::with_kolab_nocaps -D php::with_xslt -D php::with_mysql -Dkolabd::kolab_version=2.2.1 -Dkolab-webadmin::kolab_version=2.2.1 openpkg-tools openldap postfix kolabd kolab-webadmin kolab-fbview kolab-webclient | sh --------------------------------------- openpkg:build:FATAL: errors occured while building: php-5.2.8-20081209_kolab2: php searches a frood called 'mysql' Leider habe ich nicht herausgefunden was "FROOD" bedeutet. Habe dann ferner beide php5.. Pakte versucht mit den gewünschten Ergänzungen zu rebuilden: /kolab/bin/openpkg rpm --rebuild ./php-5.2.8-20081209_kolab2.src.rpm --with xslt --with mysql /kolab/bin/openpkg rpm --rebuild ./php-5.2.9-20090306.src.rpm --with xslt -- with mysql beide wurden ohne Fehler compiliert aber der Update (wie oben: sh install-kolab.sh ) bringt den identischen Fehler in Bezug auf mysql. Was habe ich falsch oder nicht verstanden? Kann es sein, dass ich noch ein Paket brauche wie zB. php-mysql? Woher? Herzlichen Dank für eure Hilfe. -- Grüsse Bernhard From Mike.Neuhaus at gmx.de Sun Apr 26 13:25:41 2009 From: Mike.Neuhaus at gmx.de (GMX) Date: Sun, 26 Apr 2009 13:25:41 +0200 Subject: domainname =?ISO-8859-1?Q?ge=E4ndert?= Message-ID: <1240745141.4921.5.camel@ubuntu.ubuntu-domain> Hallo, ...ich habe mir eine neue domain zugelegt und möchte meinen kolab jetzt mit allen accounts und natürlich auch horde auf die neue domain umstellen. Was muss ich machen? Ich nutze Version 2.2.1. Grüße Mike Neuhaus From marc.schiffbauer at mightycare.de Mon Apr 27 13:26:46 2009 From: marc.schiffbauer at mightycare.de (Marc Schiffbauer) Date: Mon, 27 Apr 2009 13:26:46 +0200 Subject: domainname =?iso-8859-1?q?ge=E4ndert?= In-Reply-To: <1240745141.4921.5.camel@ubuntu.ubuntu-domain> References: <1240745141.4921.5.camel@ubuntu.ubuntu-domain> Message-ID: <200904271326.46138.marc.schiffbauer@mightycare.de> Am Sonntag, 26. April 2009 13:25:41 schrieb GMX: > Hallo, > ...ich habe mir eine neue domain zugelegt und möchte meinen kolab jetzt > mit allen accounts und natürlich auch horde auf die neue domain > umstellen. Was muss ich machen? > > Ich nutze Version 2.2.1. > Ich weiss nicht ob kolab das direkt unterstützt, ich schätze eher nein. Allerdings kann der cyrus in neueren Versionen auch Root-Mailboxen umbenennen. Früher hatte ich mir da ein recht umfangreiches Script zu geschrieben, heute geht das per cyradm mit dem renamemailbox command recht komfortabel. So kannst du also schonmal den cyrus part ändern. Was den Rest angeht wirst du sicher im ldap einige Dinge anpassen müssen und auch in den kolab config files bzw templates. Gruß -Marc -- Senior Consultant :: Solution Architect IT-Security :: Free Software :: GNU/Linux Mobile +49_151_16227402 :: Fon +49_6187_9058695 :: Fax +49_6187_900157 MightyCare Solutions GmbH http://www.mightycare.de Firmenangaben unter http://www.mightycare.de/#/de/impressum/ From fermat at uni-paderborn.de Mon Apr 27 15:52:47 2009 From: fermat at uni-paderborn.de (Sascha Effert) Date: Mon, 27 Apr 2009 15:52:47 +0200 Subject: Fehlende =?utf-8?q?Kalendereintr=C3=A4ge_nach_update_von?= KDE Message-ID: <200904271552.48321.fermat@uni-paderborn.de> Hallo, ich meinen Rechner von kubuntu 8.10 auf 9.04 aktualisiert. Dabei wurde kde von 4.2.0 auf 4.2.2 hoch gezogen. Ich verwende kontact als Client für einen kolab- Server. Mit der aktualisierten Version von kontact kann ich einige Termine auf dem kolab-Server nicht mehr sehen, obwohl diese über die alte Version (habe ich noch parallel installier) und über das Webinterface sehen kann. Ich habe die gesamte KDE-Konfiguration gelöscht und kontact neu konfiguriert, so dass er alle Verzeichniss neu geholt hat, aber auch das hat nichts gebracht. Was kann ich tun? Hat hier jemand einen Plan? tschau Sascha Effert From marc.schiffbauer at mightycare.de Mon Apr 27 16:25:31 2009 From: marc.schiffbauer at mightycare.de (Marc Schiffbauer) Date: Mon, 27 Apr 2009 16:25:31 +0200 Subject: Fehlende =?iso-8859-1?q?Kalendereintr=E4ge_nach_update_von?= KDE In-Reply-To: <200904271552.48321.fermat@uni-paderborn.de> References: <200904271552.48321.fermat@uni-paderborn.de> Message-ID: <200904271625.31495.marc.schiffbauer@mightycare.de> Am Montag, 27. April 2009 15:52:47 schrieb Sascha Effert: > Hallo, Hi Sacha, > > ich meinen Rechner von kubuntu 8.10 auf 9.04 aktualisiert. Dabei wurde kde > von 4.2.0 auf 4.2.2 hoch gezogen. Ich verwende kontact als Client für einen > kolab- Server. Mit der aktualisierten Version von kontact kann ich einige > Termine auf dem kolab-Server nicht mehr sehen, obwohl diese über die alte > Version (habe ich noch parallel installier) und über das Webinterface sehen > kann. Ich habe die gesamte KDE-Konfiguration gelöscht und kontact neu > konfiguriert, so dass er alle Verzeichniss neu geholt hat, aber auch das > hat nichts gebracht. Was kann ich tun? Hat hier jemand einen Plan? > eine Lösung habe ich nicht, aber schonmal den Hinweis, dass ich hier auf meinem Laptop das Problem mit KDE 4.2.2 unter Gentoo nicht hatte/habe. Gruß -Marc -- Senior Consultant :: Solution Architect IT-Security :: Free Software :: GNU/Linux Mobile +49_151_16227402 :: Fon +49_6187_9058695 :: Fax +49_6187_900157 MightyCare Solutions GmbH http://www.mightycare.de Firmenangaben unter http://www.mightycare.de/#/de/impressum/ From thomas at intevation.de Mon Apr 27 16:28:01 2009 From: thomas at intevation.de (Thomas Arendsen Hein) Date: Mon, 27 Apr 2009 16:28:01 +0200 Subject: Kolab MySQL Integration In-Reply-To: <200904251500.40095.bbuehler@bbm-bbmicro.ch> References: <200904251500.40095.bbuehler@bbm-bbmicro.ch> Message-ID: <20090427142801.GF7905.thomas@intevation.de> * B. Buehler [20090425 15:00]: > php-5.2.8-20081209_kolab2: php searches a frood called 'mysql' > > Leider habe ich nicht herausgefunden was "FROOD" bedeutet. A frood is defined as "a really amazingly together guy." :) > Habe dann ferner beide php5.. Pakte versucht mit den gewünschten Ergänzungen > zu rebuilden: > > /kolab/bin/openpkg rpm --rebuild ./php-5.2.8-20081209_kolab2.src.rpm --with > xslt --with mysql > /kolab/bin/openpkg rpm --rebuild ./php-5.2.9-20090306.src.rpm --with xslt -- > with mysql > > beide wurden ohne Fehler compiliert > aber der Update (wie oben: sh install-kolab.sh ) bringt den identischen Fehler > in Bezug auf mysql. > > Was habe ich falsch oder nicht verstanden? Damit install-kolab.sh das mysql-Paket auch sieht, muss es in der 00INDEX.rdf stehen. Wie man diese generiert, steht in 1st.README. Gruesse, 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 From glua at 4-mail.net Mon Apr 27 19:46:30 2009 From: glua at 4-mail.net (Julian Golderer) Date: Mon, 27 Apr 2009 19:46:30 +0200 Subject: Fehlende =?iso-8859-1?q?Kalendereintr=E4ge_nach_update_von?= KDE In-Reply-To: <200904271625.31495.marc.schiffbauer@mightycare.de> References: <200904271552.48321.fermat@uni-paderborn.de> <200904271625.31495.marc.schiffbauer@mightycare.de> Message-ID: <200904271946.30328.glua@4-mail.net> Hi Sascha, es scheint, als hätte sich in KDE 4.2.0 ein Fehler im Kolab-Format bei Kontact eingeschlichen, dieser wurde mit KDE 4.2.1 behoben, was dazu führte, dass alle Kalender-Einträge verschwinden. Mit folgenden Befehl, ausgeführt im Kalender- Verzeichnis auf dem Kolab-Server, lässt sich das beheben: for i in `ls *.`; do sed -e 's/ZZ tmp-$i; mv tmp-$i $i; done Danach musst du den Cache in Kmail neu aufbauen: Groupware-Ordner in Kmail einblenden lassen, Rechtsklick auf den Kalender- Ordner -> Problembeseitigung im IMAP-Zwischenspeicher -> Zwischenspeicher neu aufbauen. Viel Glück und Grüße, Julian Am Montag 27 April 2009 16:25:31 schrieb Marc Schiffbauer: > Am Montag, 27. April 2009 15:52:47 schrieb Sascha Effert: > > Hallo, > > Hi Sacha, > > > ich meinen Rechner von kubuntu 8.10 auf 9.04 aktualisiert. Dabei wurde > > kde von 4.2.0 auf 4.2.2 hoch gezogen. Ich verwende kontact als Client für > > einen kolab- Server. Mit der aktualisierten Version von kontact kann ich > > einige Termine auf dem kolab-Server nicht mehr sehen, obwohl diese über > > die alte Version (habe ich noch parallel installier) und über das > > Webinterface sehen kann. Ich habe die gesamte KDE-Konfiguration gelöscht > > und kontact neu konfiguriert, so dass er alle Verzeichniss neu geholt > > hat, aber auch das hat nichts gebracht. Was kann ich tun? Hat hier jemand > > einen Plan? > > eine Lösung habe ich nicht, aber schonmal den Hinweis, dass ich hier auf > meinem Laptop das Problem mit KDE 4.2.2 unter Gentoo nicht hatte/habe. > > Gruß > -Marc From marc.schiffbauer at mightycare.de Tue Apr 28 10:16:52 2009 From: marc.schiffbauer at mightycare.de (Marc Schiffbauer) Date: Tue, 28 Apr 2009 10:16:52 +0200 Subject: Fehlende =?iso-8859-1?q?Kalendereintr=E4ge_nach_update_von?= KDE In-Reply-To: <200904271946.30328.glua@4-mail.net> References: <200904271552.48321.fermat@uni-paderborn.de> <200904271625.31495.marc.schiffbauer@mightycare.de> <200904271946.30328.glua@4-mail.net> Message-ID: <200904281016.52320.marc.schiffbauer@mightycare.de> Am Montag, 27. April 2009 19:46:30 schrieb Julian Golderer: > Hi Sascha, > > es scheint, als hätte sich in KDE 4.2.0 ein Fehler im Kolab-Format bei > Kontact eingeschlichen, dieser wurde mit KDE 4.2.1 behoben, was dazu > führte, dass alle Kalender-Einträge verschwinden. Interessant. Vielleicht ist mir das bisher nur nicht aufgefallen ?! > Mit folgenden Befehl, > ausgeführt im Kalender- Verzeichnis auf dem Kolab-Server, Welches Verzeichnis meinst du hier genau? > lässt sich das > beheben: > for i in `ls *.`; do sed -e 's/ZZ tmp-$i; mv tmp-$i $i; done > Kleine Vereinfachung: for i in *.; do sed -i 's/ZZ Danach musst du den Cache in Kmail neu aufbauen: > Groupware-Ordner in Kmail einblenden lassen, Rechtsklick auf den Kalender- > Ordner -> Problembeseitigung im IMAP-Zwischenspeicher -> Zwischenspeicher > neu aufbauen. > > Viel Glück und Grüße, > Julian > > Am Montag 27 April 2009 16:25:31 schrieb Marc Schiffbauer: > > Am Montag, 27. April 2009 15:52:47 schrieb Sascha Effert: > > > Hallo, > > > > Hi Sacha, > > > > > ich meinen Rechner von kubuntu 8.10 auf 9.04 aktualisiert. Dabei wurde > > > kde von 4.2.0 auf 4.2.2 hoch gezogen. Ich verwende kontact als Client > > > für einen kolab- Server. Mit der aktualisierten Version von kontact > > > kann ich einige Termine auf dem kolab-Server nicht mehr sehen, obwohl > > > diese über die alte Version (habe ich noch parallel installier) und > > > über das Webinterface sehen kann. Ich habe die gesamte > > > KDE-Konfiguration gelöscht und kontact neu konfiguriert, so dass er > > > alle Verzeichniss neu geholt hat, aber auch das hat nichts gebracht. > > > Was kann ich tun? Hat hier jemand einen Plan? > > > > eine Lösung habe ich nicht, aber schonmal den Hinweis, dass ich hier auf > > meinem Laptop das Problem mit KDE 4.2.2 unter Gentoo nicht hatte/habe. > > > > Gruß > > -Marc > > _______________________________________________ > Kolab-users-de mailing list > Kolab-users-de at kolab.org > http://lists.wald.intevation.org/mailman/listinfo/kolab-users-de -- Senior Consultant :: Solution Architect IT-Security :: Free Software :: GNU/Linux Mobile +49_151_16227402 :: Fon +49_6187_9058695 :: Fax +49_6187_900157 MightyCare Solutions GmbH http://www.mightycare.de Firmenangaben unter http://www.mightycare.de/#/de/impressum/ From glua at 4-mail.net Tue Apr 28 10:27:28 2009 From: glua at 4-mail.net (Julian Golderer) Date: Tue, 28 Apr 2009 10:27:28 +0200 Subject: Fehlende =?iso-8859-1?q?Kalendereintr=E4ge_nach_update_von?= KDE In-Reply-To: <200904281016.52320.marc.schiffbauer@mightycare.de> References: <200904271552.48321.fermat@uni-paderborn.de> <200904271946.30328.glua@4-mail.net> <200904281016.52320.marc.schiffbauer@mightycare.de> Message-ID: <200904281027.29117.glua@4-mail.net> Am Dienstag 28 April 2009 10:16:52 schrieb Marc Schiffbauer: > Interessant. Vielleicht ist mir das bisher nur nicht aufgefallen ?! Das Webmail ist davon z.b. irgendwie nicht betroffen. > > Mit folgenden Befehl, > > ausgeführt im Kalender- Verzeichnis auf dem Kolab-Server, > > Welches Verzeichnis meinst du hier genau? Bei mir (Gentoo) wärs z.B. /var/spool/imap/domain/q/4- mail.net/g/user/glua/Kalender/ > Kleine Vereinfachung: > > for i in *.; do sed -i 's/ZZ References: <200904271552.48321.fermat@uni-paderborn.de> <200904281016.52320.marc.schiffbauer@mightycare.de> <200904281027.29117.glua@4-mail.net> Message-ID: <200904281105.43952.marc.schiffbauer@mightycare.de> Am Dienstag, 28. April 2009 10:27:28 schrieb Julian Golderer: > Am Dienstag 28 April 2009 10:16:52 schrieb Marc Schiffbauer: > > Interessant. Vielleicht ist mir das bisher nur nicht aufgefallen ?! > > Das Webmail ist davon z.b. irgendwie nicht betroffen. > > > > Mit folgenden Befehl, > > > ausgeführt im Kalender- Verzeichnis auf dem Kolab-Server, > > > > Welches Verzeichnis meinst du hier genau? > > Bei mir (Gentoo) wärs z.B. /var/spool/imap/domain/q/4- > mail.net/g/user/glua/Kalender/ ok, danke! Ich hatte auch einige "ZZ"-Einträge dort drin. Hab aber leider jetzt nicht getestet, ob ich diese Einträge wirklich nicht gesehn hab. Allerdings waren es wirklich die meisten der Mailfiles, sodass mir das eigentlich hätte aufgefallen müssen... > > > Kleine Vereinfachung: > > > > for i in *.; do sed -i 's/ZZ > Danke :) Shell-Skripts sind nicht meine Stärke ;) Hier nochmal eine Verbesserung fürs Archiv, denn die obige Lösung wird nur bis zu einer bestimmten Anzahl Kalender-Einträge funktionieren (bis die maximale Command-Line Länge erreicht ist) Dies hier wird dann für eine beliebige Anzahl funktionieren: find . -name "*\." -type f | xargs sed -i 's/ZZ References: <200904271552.48321.fermat@uni-paderborn.de> <200904281016.52320.marc.schiffbauer@mightycare.de> <200904281027.29117.glua@4-mail.net> <200904281105.43952.marc.schiffbauer@mightycare.de> Message-ID: <20090428093218.GC7999.thomas@intevation.de> * Marc Schiffbauer [20090428 11:05]: > Am Dienstag, 28. April 2009 10:27:28 schrieb Julian Golderer: > > Am Dienstag 28 April 2009 10:16:52 schrieb Marc Schiffbauer: > > > Kleine Vereinfachung: > > > > > > for i in *.; do sed -i 's/ZZ > > > Danke :) Shell-Skripts sind nicht meine Stärke ;) > > Hier nochmal eine Verbesserung fürs Archiv, denn die obige Lösung wird nur bis > zu einer bestimmten Anzahl Kalender-Einträge funktionieren (bis die maximale > Command-Line Länge erreicht ist) > > Dies hier wird dann für eine beliebige Anzahl funktionieren: > > find . -name "*\." -type f | xargs sed -i 's/ZZ Hallo, mich würde interessieren, ob Kolab für folgendes Anwendungsszenario geeignet wäre. Angenommen, ein Mailserver ist bereits vorhanden, d.h. die Mitarbeiter sollen diesen vorhanden Emaildienst weiterhin zum Emails senden/empfangen verwenden. Kolab soll also "lediglich" für Termine und Kontakte verwendet werden. Ist das ein übliches Szenario und wäre somit Kolab hierfür geeignet? Also Clients kämen Outlook 2007 (mit Toltec Connector?) und unter Linux z.B. Kontact in Frage. Vielen Dank und Grüße Martin From bbuehler at bbm-bbmicro.ch Wed Apr 29 13:43:38 2009 From: bbuehler at bbm-bbmicro.ch (B. Buehler) Date: Wed, 29 Apr 2009 13:43:38 +0200 Subject: Kolab MySQL Integration In-Reply-To: <20090427142801.GF7905.thomas@intevation.de> References: <200904251500.40095.bbuehler@bbm-bbmicro.ch> <20090427142801.GF7905.thomas@intevation.de> Message-ID: <200904291343.39007.bbuehler@bbm-bbmicro.ch> Hallo Thomas herzlichen Dank für deine Antworten. Ich melde mich nochmals dazu. Grüsse Bernhard Am Montag, 27. April 2009 16.28:01 schrieb Thomas Arendsen Hein: > * B. Buehler [20090425 15:00]: > > php-5.2.8-20081209_kolab2: php searches a frood called 'mysql' > > > > Leider habe ich nicht herausgefunden was "FROOD" bedeutet. > > A frood is defined as "a really amazingly together guy." :) > > > Habe dann ferner beide php5.. Pakte versucht mit den gewünschten > > Ergänzungen zu rebuilden: > > > > /kolab/bin/openpkg rpm --rebuild ./php-5.2.8-20081209_kolab2.src.rpm > > --with xslt --with mysql > > /kolab/bin/openpkg rpm --rebuild ./php-5.2.9-20090306.src.rpm --with xslt > > -- with mysql > > > > beide wurden ohne Fehler compiliert > > aber der Update (wie oben: sh install-kolab.sh ) bringt den identischen > > Fehler in Bezug auf mysql. > > > > Was habe ich falsch oder nicht verstanden? > > Damit install-kolab.sh das mysql-Paket auch sieht, muss es in der > 00INDEX.rdf stehen. Wie man diese generiert, steht in 1st.README. From wrobel at pardus.de Wed Apr 29 16:51:40 2009 From: wrobel at pardus.de (Gunnar Wrobel) Date: Wed, 29 Apr 2009 16:51:40 +0200 Subject: Kolab nur =?utf-8?b?ZsO8cg==?= Termine und Kontakte verwenden - geht das? In-Reply-To: <200904291244.17652.martin@brodbeck-online.de> References: <200904291244.17652.martin@brodbeck-online.de> Message-ID: <20090429165140.73441jbcg9cuzmas@webmail.pardus.de> Hallo Martin, Quoting Martin Brodbeck : > Hallo, > > mich würde interessieren, ob Kolab für folgendes Anwendungsszenario geeignet > wäre. Angenommen, ein Mailserver ist bereits vorhanden, d.h. die Mitarbeiter > sollen diesen vorhanden Emaildienst weiterhin zum Emails senden/empfangen > verwenden. > > Kolab soll also "lediglich" für Termine und Kontakte verwendet > werden. Ist das > ein übliches Szenario und wäre somit Kolab hierfür geeignet? Also Clients > kämen Outlook 2007 (mit Toltec Connector?) und unter Linux z.B. Kontact in > Frage. Als "üblich" würde ich das Szenario nicht bezeichnen :) Aber es spricht auch nichts dagegen es so zu verwenden. Unter der Annahme, dass der ursprüngliche E-Maildienst ebenfall IMAP anbietet, sind halt zwei IMAP-Konten im Kontact definiert. Gruß, Gunnar > > Vielen Dank und Grüße > Martin > _______________________________________________ > Kolab-users-de mailing list > Kolab-users-de at kolab.org > http://lists.wald.intevation.org/mailman/listinfo/kolab-users-de > -- ____ 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 : http://lists.wald.intevation.org/pipermail/kolab-users-de/attachments/20090429/6b1462ad/attachment.pgp From martin.konold at erfrakon.de Wed Apr 29 17:43:28 2009 From: martin.konold at erfrakon.de (Martin Konold) Date: Wed, 29 Apr 2009 17:43:28 +0200 Subject: Kolab nur =?iso-8859-1?q?f=FCr_Termine_und_Kontakte_verwenden_-_geht?= das? In-Reply-To: <200904291244.17652.martin@brodbeck-online.de> References: <200904291244.17652.martin@brodbeck-online.de> Message-ID: <200904291743.29977.martin.konold@erfrakon.de> Am Mittwoch, 29. April 2009 12:44:17 schrieb Martin Brodbeck: Hallo Martin, > mich würde interessieren, ob Kolab für folgendes Anwendungsszenario > geeignet wäre. Angenommen, ein Mailserver ist bereits vorhanden, d.h. die > Mitarbeiter sollen diesen vorhanden Emaildienst weiterhin zum Emails > senden/empfangen verwenden. > > Kolab soll also "lediglich" für Termine und Kontakte verwendet werden. Ist > das ein übliches Szenario und wäre somit Kolab hierfür geeignet? Also > Clients kämen Outlook 2007 (mit Toltec Connector?) und unter Linux z.B. > Kontact in Frage. Ja, sowas wäre möglich allerdings evtl. unnötig komplex. Wenn du auf Einladungen und Ressourcenverwaltung verzichten kannst ist es wiederum trivial. (Du musst sonst die Einladungen zu Terminen, welche per SMTP verschickt werden nicht an den Kolabserver weiterleiten). Ich habe sowas bei einem Kunden zusammen mit dem KONSEC Konnektor am laufen. In diesem speziellen Fall will der Kunde normale Mails (viele GB pro Mailbox) nicht lokal auf den Outlook Clients cachen sondern auf diese nur via online IMAP zugreifen. Grüße, -- martin -- e r f r a k o n Erlewein, Frank, Konold & Partner - Beratende Ingenieure und Physiker Sitz: Adolfstraße 23, 70469 Stuttgart, Partnerschaftsregister Stuttgart PR 126 http://www.erfrakon.com/ From martin.konold at erfrakon.de Wed Apr 29 17:45:38 2009 From: martin.konold at erfrakon.de (Martin Konold) Date: Wed, 29 Apr 2009 17:45:38 +0200 Subject: Kolab nur =?iso-8859-15?q?f=FCr_Termine_und_Kontakte_verwenden_-_geht?= das? In-Reply-To: <20090429165140.73441jbcg9cuzmas@webmail.pardus.de> References: <200904291244.17652.martin@brodbeck-online.de> <20090429165140.73441jbcg9cuzmas@webmail.pardus.de> Message-ID: <200904291745.38589.martin.konold@erfrakon.de> Am Mittwoch, 29. April 2009 16:51:40 schrieb Gunnar Wrobel: Hallo Gunnar, > > kämen Outlook 2007 (mit Toltec Connector?) und unter Linux z.B. Kontact > > in Frage. > > Als "üblich" würde ich das Szenario nicht bezeichnen :) Aber es > spricht auch nichts dagegen es so zu verwenden. Unter der Annahme, > dass der ursprüngliche E-Maildienst ebenfall IMAP anbietet, sind halt > zwei IMAP-Konten im Kontact definiert. Er möchte nicht KDE Kontact, sondern Outlook verwenden. Desweiteren muss er dafür sorgen, dass z.B. Einladungen an eine Ressource (via SMTP) auch tatsächlich auf dem Kolabserver und nicht auf dem bestehenden IMAP Server landen. Grüße, -- martin -- e r f r a k o n Erlewein, Frank, Konold & Partner - Beratende Ingenieure und Physiker Sitz: Adolfstraße 23, 70469 Stuttgart, Partnerschaftsregister Stuttgart PR 126 http://www.erfrakon.com/ From lenz at eurosystems.lu Wed Apr 29 17:52:14 2009 From: lenz at eurosystems.lu (Alfons Lenz) Date: Wed, 29 Apr 2009 17:52:14 +0200 Subject: Kolab nur =?ISO-8859-15?Q?f=FCr_Termine_und_Kontakte_?= =?ISO-8859-15?Q?verwenden_-_geht_das=3F?= In-Reply-To: <20090429165140.73441jbcg9cuzmas@webmail.pardus.de> References: <200904291244.17652.martin@brodbeck-online.de> <20090429165140.73441jbcg9cuzmas@webmail.pardus.de> Message-ID: <49F877AE.9040301@eurosystems.lu> Hallo Martin, ein ähnliches Szenario wollen wir auch umsetzen. In Tests mit größeren Outlook .pst-Dateien (> 500 MB, angebunden an den vorhandenen Mail-Server) hatten wir mit dem Toltec Connector aber Probleme. Daher warten wir momentan auf die Fertigstellung des Bynari Connectors 4, um dann nochmal damit zu testen. Wenn der normale Mailverkehr über den vorhandenen Mailserver abgewickelt wird, muss irgendwie sichergestellt werden, dass Outlook-Nachrichten bzgl. Terminverwaltung auch den Kolab-Server erreichen. Sonst funktioniert z.B. die automatische Terminbestätigung bei Ressourcen nicht. Dazu habe ich auf dem Kolab-Server die gleichen Mail-Adressen nochmal angelegt (mit gleicher Domain). Auf dem vorhandenen Postfix-Mailserver hab ich ein Script eingebunden, dass alle Mails mit entsprechendem Betreff zusätzlich als Kopie an den Kolab-Server sendet. MfG Alfons Gunnar Wrobel schrieb: > Hallo Martin, > > Quoting Martin Brodbeck : > >> Hallo, >> >> mich würde interessieren, ob Kolab für folgendes Anwendungsszenario >> geeignet >> wäre. Angenommen, ein Mailserver ist bereits vorhanden, d.h. die >> Mitarbeiter >> sollen diesen vorhanden Emaildienst weiterhin zum Emails >> senden/empfangen >> verwenden. >> >> Kolab soll also "lediglich" für Termine und Kontakte verwendet >> werden. Ist das >> ein übliches Szenario und wäre somit Kolab hierfür geeignet? Also >> Clients >> kämen Outlook 2007 (mit Toltec Connector?) und unter Linux z.B. >> Kontact in >> Frage. > > Als "üblich" würde ich das Szenario nicht bezeichnen :) Aber es > spricht auch nichts dagegen es so zu verwenden. Unter der Annahme, > dass der ursprüngliche E-Maildienst ebenfall IMAP anbietet, sind halt > zwei IMAP-Konten im Kontact definiert. > > Gruß, > > Gunnar > >> >> Vielen Dank und Grüße >> Martin >> _______________________________________________ >> Kolab-users-de mailing list >> Kolab-users-de at kolab.org >> http://lists.wald.intevation.org/mailman/listinfo/kolab-users-de >> > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Kolab-users-de mailing list > Kolab-users-de at kolab.org > http://lists.wald.intevation.org/mailman/listinfo/kolab-users-de > -------------- nächster Teil -------------- Ein Dateianhang mit HTML-Daten wurde abgetrennt... URL: http://lists.wald.intevation.org/pipermail/kolab-users-de/attachments/20090429/323468ac/attachment-0001.html From martin at brodbeck-online.de Thu Apr 30 08:35:39 2009 From: martin at brodbeck-online.de (Martin Brodbeck) Date: Thu, 30 Apr 2009 08:35:39 +0200 Subject: Kolab nur =?iso-8859-1?q?f=FCr_Termine_und_Kontakte_verwenden_-_geht?= das? In-Reply-To: <200904291743.29977.martin.konold@erfrakon.de> References: <200904291244.17652.martin@brodbeck-online.de> <200904291743.29977.martin.konold@erfrakon.de> Message-ID: <200904300835.40463.martin@brodbeck-online.de> Hallo Martin, > Wenn du auf Einladungen und Ressourcenverwaltung verzichten kannst ist es > wiederum trivial. (Du musst sonst die Einladungen zu Terminen, welche per > SMTP verschickt werden nicht an den Kolabserver weiterleiten). Das habe ich jetzt nicht ganz verstanden, aber Einladungen/Ressourcenverwaltung wäre schon wünschenswert. > Ich habe sowas bei einem Kunden zusammen mit dem KONSEC Konnektor am > laufen. > > In diesem speziellen Fall will der Kunde normale Mails (viele GB pro > Mailbox) nicht lokal auf den Outlook Clients cachen sondern auf diese nur > via online IMAP zugreifen. Ja, das wäre ziemlich genau unser gewünschtes Setup. Emails über bestehenden IMAP Server verwalten. Senden über bestehenden Mailserver. Grund ist, dass unsere Abteilung darüber nicht die Hoheit hat (was auch gut so ist). Alles was mit Terminen, Kontakten etc. zu tun hat, soll über Kolab gehen. Bisher haben *nur* für Termine und Kontakte MS Exchange (wobei das mit dem "nur" nicht 100%ig so funktioniert). Daher die Idee, dies mit Kolab zu lösen, zumal mir hierbei die Integration mit anderen Clients unproblematischer erscheint. Wichtig wäre, dass die Outlook-Nutzer sich nicht wirklich umstellen brauchen. Ich nehme an, zu diesem speziellen Thema gibt es nicht irgendwo ein Online- HowTo o.ä.? Viele Grüße Martin From martin at brodbeck-online.de Thu Apr 30 08:39:07 2009 From: martin at brodbeck-online.de (Martin Brodbeck) Date: Thu, 30 Apr 2009 08:39:07 +0200 Subject: Kolab nur =?iso-8859-15?q?f=FCr_Termine_und_Kontakte_verwenden_-_geht?= das? In-Reply-To: <49F877AE.9040301@eurosystems.lu> References: <200904291244.17652.martin@brodbeck-online.de> <20090429165140.73441jbcg9cuzmas@webmail.pardus.de> <49F877AE.9040301@eurosystems.lu> Message-ID: <200904300839.08216.martin@brodbeck-online.de> Hallo Alfons, > ein ähnliches Szenario wollen wir auch umsetzen. In Tests mit größeren > Outlook .pst-Dateien (> 500 MB, angebunden an den vorhandenen > Mail-Server) hatten wir mit dem Toltec Connector aber Probleme. Daher > warten wir momentan auf die Fertigstellung des Bynari Connectors 4, um > dann nochmal damit zu testen. Von dem Problem mit großen Mailboxen habe ich im Mailinglist-Archiv auch schon gelesen. Das wäre natürlich ein K.O.-Kriterium. > Wenn der normale Mailverkehr über den vorhandenen Mailserver abgewickelt > wird, muss irgendwie sichergestellt werden, dass Outlook-Nachrichten > bzgl. Terminverwaltung auch den Kolab-Server erreichen. Sonst > funktioniert z.B. die automatische Terminbestätigung bei Ressourcen > nicht. Dazu habe ich auf dem Kolab-Server die gleichen Mail-Adressen > nochmal angelegt (mit gleicher Domain). Auf dem vorhandenen > Postfix-Mailserver hab ich ein Script eingebunden, dass alle Mails mit > entsprechendem Betreff zusätzlich als Kopie an den Kolab-Server sendet. Das ist interessant. Vielleicht kannst du mir hierzu näheres sagen, wenn es akut werden sollte...? Viele Grüße Martin From bbuehler at bbm-bbmicro.ch Thu Apr 30 17:24:54 2009 From: bbuehler at bbm-bbmicro.ch (B. Buehler) Date: Thu, 30 Apr 2009 17:24:54 +0200 Subject: Kolab MySQL Integration In-Reply-To: <20090427142801.GF7905.thomas@intevation.de> References: <200904251500.40095.bbuehler@bbm-bbmicro.ch> <20090427142801.GF7905.thomas@intevation.de> Message-ID: <200904301724.54907.bbuehler@bbm-bbmicro.ch> Hallo Thomas herzlichen Dank für deine Infos. Ich habe Kolab neu generiert (vorher Index neu erstellt) und beim Start wird auch mysql gestartet. Soweit sogut. Trotzdem scheint mir für die Integration von mysql mit php etwas zu fehlen. Wenn ich zB. phpMyAdmin starte wird die mysql-extension vermisst. Kannst du mir mitteilen was hier noch fehlt? Normalerweise (ohne Kolab) wird in der Regel (bei Suse) ein Paket php-mysql benötigt. Ein Solches finde ich aber bei OpenPkg nicht. Und wie steht es wenn ich noch xslt dazu benötigen würde? Danke für weitere Unterstützung. Grüsse Bernhard Am Montag, 27. April 2009 16.28:01 schrieb Thomas Arendsen Hein: > * B. Buehler [20090425 15:00]: > > php-5.2.8-20081209_kolab2: php searches a frood called 'mysql' > > > > Leider habe ich nicht herausgefunden was "FROOD" bedeutet. > > A frood is defined as "a really amazingly together guy." :) > > > Habe dann ferner beide php5.. Pakte versucht mit den gewünschten > > Ergänzungen zu rebuilden: > > > > /kolab/bin/openpkg rpm --rebuild ./php-5.2.8-20081209_kolab2.src.rpm > > --with xslt --with mysql > > /kolab/bin/openpkg rpm --rebuild ./php-5.2.9-20090306.src.rpm --with xslt > > -- with mysql > > > > beide wurden ohne Fehler compiliert > > aber der Update (wie oben: sh install-kolab.sh ) bringt den identischen > > Fehler in Bezug auf mysql. > > > > Was habe ich falsch oder nicht verstanden? > > Damit install-kolab.sh das mysql-Paket auch sieht, muss es in der > 00INDEX.rdf stehen. Wie man diese generiert, steht in 1st.README. > > Gruesse, > Thomas Arendsen Hein From Mike.Neuhaus at gmx.de Sun Apr 26 13:23:40 2009 From: Mike.Neuhaus at gmx.de (GMX) Date: Sun, 26 Apr 2009 13:23:40 +0200 Subject: domainname =?ISO-8859-1?Q?ge=E4ndert?= Message-ID: <1240745020.4921.4.camel@ubuntu.ubuntu-domain> Hallo, ...ich habe mir eine neue domain zugelegt und möchte meinen kolab jetzt mit allen accounts und natürlich auch horde auf die neue domain umstellen. Was muss ich machen? Ich nutze Version 2.2.1. Grüße Mike Neuhaus