- Webinterface, gewöhnungsbedürftig, aber funktional - Kontact, läuft gut - Thunderbird/Lighting: Kolabsync, scheint auch alles wie erwartet zu machen.
Was noch fehlt: Test mit mehreren Kollegen und Outlookanbindung.
weiß jemand, wie es um die Integration in Distributionen und namentlich um jene in Debian steht? Wie ich gehört habe, muß man, um kolab zu benutzen, deren eigene Versionen von apache, mailserver, etc. pp. benutzen?
Das scheint manchem Admin, einschließlich meinem, aus einleuchtenden Gründen nicht zu gefallen und ich muß weiter ohne ordentliches Webfrontend für Kontact auskommen :-(
Das habe ich leider auch schon festgestellt. Versuche es auf einen Debian-ARM zu betreiben und dachte erst, dass dies nur daran liegt. Aber allgemein scheint es wohl bei den Debian-Paketen da ein wenig zu habbern... und leider auch schon länger. Weiß da jemand genaueres? Ist eigentlich sehr Schade.
Mein Test läuft auf einem Debian SID in einer VBox, ich habe aber, nachdem ich immer mit den Debian-Paketen zu irgendeinem Problem kam, jetzt die Dateien vom Projekt genommen.
... und was macht ein geneigter Fedora, Mandrake, Red Hat, SuSE, ... User der sich mit den kolab-eigenen Paketen nicht die ganze Distro verhunzen will ... wird wohl nicht bei mir zum Einsatz kommen können ... SCHADE!
So wie ich das sehe, installiert sich Kolab in ein einzigstes Verzeichnis (/kolab) und legt sonst nur ein paar zusätzliche Benutzer und ein Init-Skript an. So weit ist es also eigentlich harmlos. Habe es mir aber nicht ganz in der Tiefe angeschaut. Wenn es dennoch stören sollte stecke es halt in eine VM oder ein Chroot.
Von Thorsten Schnebeck am Di, 15. Juli 2008 um 21:49 #
Das "native" Kolab läuft mit Hilfe von Openpkg in einer quasi-abgeschlossenen Umgebung. Wenn man die Pakete zieht und installiert baut sich Openpkg komplett selbst inkl. Compiler, glibc und so weiter. Dann erst werden die für das Host-System gültigen Openpkg-bin-RPM erzeugt.
Die einzige Verbindung zum Host sind Eintrage im syslog, in /etc/user, /etc/groups und in /etc/init.d/kolab. Wenn die RPM gebaut sind, könnte man das Installationssystem löschen und nur mit den binären RPM-Paketen arbeiten, aber für das Einspielen von Hotfixes empfiehlt es sich, dieses zu behalten.
Openpkg ist zz. noch die erste Wahl, wenn das Host-System von Openpkg unterstützt wird. Allerdings wurden mit 2.2 die Strukturen für eine direkte Unterstützung durch die Distribution verbessert, vermutlich aufgrund der Arbeiten für die Gentoo-Distribution durch P@rdus ( http://wiki.kolab.org/index.php/Gentoo )
Man muss bei der Verwendung von Kolab darauf achten, dass die Kolab-Server-Dienste nicht mit den Diensten des Hostes kollidieren. Man kann natürlich den Kolab-Apachen auch als normalen Webserver verwenden - oder man schaut ins Wiki und bindet Kolab-Server an lokalhost und verwendet Proxis zum Zugriff. Mehr im Wiki und im Admin-Hanbuch http://wiki.kolab.org/index.php/Kolab2_Installation_-_Overview http://www.kolab.org/doc/ Allgemeine-Betriebsdokumentation-KolabServer22_20080103_1.0.pdf
> Das "native" Kolab läuft mit Hilfe von Openpkg in einer quasi-abgeschlossenen Umgebung.
Die Hinwendung zu Openpkg, anstatt die Aufnahme von Patches in Dritt-Software qua eigener Mithilfe zu forcieren und die nicht FHS-konforme, Installation einer eigenen "Distribution", die sicherheitstechnisch von den großen Distributoren nicht wartbar ist, dürfte der wesentliche Grund dafür sein, daß Kolab so ein Nischendasein fristet. Klassischer Fall von selbst in den Fuß geschossen.
Von Thorsten Schnebeck am Mi, 16. Juli 2008 um 00:24 #
Die Kolab-Gruppe ist zu klein, um selbst individuelle Abhängigkeiten zu dutzenden Distribution warten zu können. Openpkg bildet eine distributionsunabhängige gemeinsame Basis mit eigenem Sicherheitsmanagement. Kolab benötigte lange Zeit sehr spezielle Patches in Paketen wie Postfix und OpenLDAP. Nicht umsonst konnte eine Source-Code basierende Distribution wie Gentoo solche Spezialanforderung einfach per USE-Flag umsetzten und eher integrieren. Vermutlich wird es in Zukunft leichter sein, dass Distributionen selbst Kolab-Pakete anbieten werden, wenn sie es denn wollen.
Kolab führt meiner Meinung nach deswegen ein Nischendasein, weil es mit seiner Designentscheidung, Kalender und Kontakte als IMAP-Ordner zu integrieren, spezielle Clientunterstützung benötigt. Viele andere Systeme basieren ja auf SQL-Datenbanken, die Kolab nicht benötigt. Allein jetzt Horde als Webclient beizubringen, Kolab nativ zu unterstützen, hat (glaube ich) 2,5 Jahre gedauert.
Die Struktur des Kolab-Konsortiums finde ich aber recht interessant. Man bietet Firmen professionellen Support an, aber die Ergebnisse dieser Entwicklungen fließen wieder in das Kolab-Projekt frei zurück. Immerhin scheinen davon 4, 5 Firmen in Deutschland leben zu können. Somit ist ein gewisser Erfolg wohl da. :-)
Spannend wird es, ob Kontact für Windows auch ein Push für Kolab bedeuten wird. Ich bin das mir nicht so sicher, da ich weiß, wie sehr auch hier in der Firma die Kollegen an Outlook gewöhnt sind und alles, was anders funktioniert, als nicht funktionell betrachten. Und schon die "Outlook-Konnektoren" zeigen ein verdächtiges Andersverhalten. Dabei bilden Kolab/Kontakt ein vorzügliches Gespann.
> Die Kolab-Gruppe ist zu klein, um selbst individuelle Abhängigkeiten zu dutzenden Distribution warten zu können.
Da zäumst du den Esel bauchwärts zum Schwanz hin auf. Es ist Aufgabe der Distributoren, Kolab zu integrieren, nur waren die Leute von Kolab bisher nicht fähig, Kolab distribuierbar anzubieten.
> Openpkg bildet eine distributionsunabhängige gemeinsame Basis mit eigenem Sicherheitsmanagement.
Darauf läßt sich kein Distributor ein.
> Nicht umsonst konnte eine Source-Code basierende Distribution wie Gentoo solche Spezialanforderung einfach per USE-Flag umsetzten und eher integrieren.
Kolab ist bisher nicht im Gentoo-Repository. Es gibt gerade mal ein Overlay.
> Vermutlich wird es in Zukunft leichter sein, dass Distributionen selbst Kolab-Pakete anbieten werden, wenn sie es denn wollen.
Solange da keine massiven Nutzeranfragen kommen und die Kolab-Leute jeden "Scheiß" bis zur libpng paketieren, anstatt ausschließlich die "echten" Kolab"-Pakete anzubieten, so daß der Integrationsaufwand in die Distributionen einigermaßen tragbar ist, segelt Kolab unter ferner liefen.
> Die Struktur des Kolab-Konsortiums finde ich aber recht interessant. Man bietet Firmen professionellen Support an, aber die Ergebnisse dieser Entwicklungen fließen wieder in das Kolab-Projekt frei zurück. Immerhin scheinen davon 4, 5 Firmen in Deutschland leben zu können. Somit ist ein gewisser Erfolg wohl da.:-)
Welche Firmen nutzen den Support denn? Bisher hat da doch hauptsächlich Vater Staat reingebuttert, wenn ich mich nicht irre.
Das ist ja noch schlimmer als Packete oder Standart. ;-) Einzig kann man nicht weiter steigern, weils schon superlativ ist, und nicht nur das, es ist ein Absolutadjektiv und daher ist "einzigst" ein Hyperlativ den es nicht gibt. (Ich wollt eigentlich nur bei Wikipedia gucken ob superlativ das richtige Wort dafür ist, aber wo ich schonmal da war kann ich auch mit dem Wissen auf die Kacke hauen)
Von Gefahrensucher am Di, 15. Juli 2008 um 20:46 #
Mein Vorschlag: "Virtual Box" (wie oben schon vorgeschlagen) oder "Qemu" verwenden. dann kannst du praktisch jedes Programm ausprobieren, ohne irgendwas kaputt zu machen. Der einzige "Overhead" ist die Virtualisierungsumgebung zu installieren, virtualisierte Linux-Distributionen gibt es nicht nur für "VMware" sondern auch für "Virtual Box" mittlerweile zum Herunterladen oder mit etwas Glück läuft auch eine "VM" von "VMware". Oder du installierst dir einfach die Distro deiner Wahl in die "Virtuelle Maschine".
Grüße
Grüße
- Webinterface, gewöhnungsbedürftig, aber funktional
- Kontact, läuft gut
- Thunderbird/Lighting: Kolabsync, scheint auch alles wie erwartet zu machen.
Was noch fehlt:
Test mit mehreren Kollegen und Outlookanbindung.
Grüße
weiß jemand, wie es um die Integration in Distributionen und namentlich um jene in Debian steht? Wie ich gehört habe, muß man, um kolab zu benutzen, deren eigene Versionen von apache, mailserver, etc. pp. benutzen?
Das scheint manchem Admin, einschließlich meinem, aus einleuchtenden Gründen nicht zu gefallen und ich muß weiter ohne ordentliches Webfrontend für Kontact auskommen :-(
Grüße
Enrico
Damit ging das einrichten recht Problemlos,...
Grüße
Die einzige Verbindung zum Host sind Eintrage im syslog, in /etc/user, /etc/groups und in /etc/init.d/kolab. Wenn die RPM gebaut sind, könnte man das Installationssystem löschen und nur mit den binären RPM-Paketen arbeiten, aber für das Einspielen von Hotfixes empfiehlt es sich, dieses zu behalten.
Openpkg ist zz. noch die erste Wahl, wenn das Host-System von Openpkg unterstützt wird. Allerdings wurden mit 2.2 die Strukturen für eine direkte Unterstützung durch die Distribution verbessert, vermutlich aufgrund der Arbeiten für die Gentoo-Distribution durch P@rdus ( http://wiki.kolab.org/index.php/Gentoo )
Man muss bei der Verwendung von Kolab darauf achten, dass die Kolab-Server-Dienste nicht mit den Diensten des Hostes kollidieren. Man kann natürlich den Kolab-Apachen auch als normalen Webserver verwenden - oder man schaut ins Wiki und bindet Kolab-Server an lokalhost und verwendet Proxis zum Zugriff. Mehr im Wiki und im Admin-Hanbuch
http://wiki.kolab.org/index.php/Kolab2_Installation_-_Overview http://www.kolab.org/doc/ Allgemeine-Betriebsdokumentation-KolabServer22_20080103_1.0.pdf
Bye
Thorsten
Die Hinwendung zu Openpkg, anstatt die Aufnahme von Patches in Dritt-Software qua eigener Mithilfe zu forcieren und die nicht FHS-konforme, Installation einer eigenen "Distribution", die sicherheitstechnisch von den großen Distributoren nicht wartbar ist, dürfte der wesentliche Grund dafür sein, daß Kolab so ein Nischendasein fristet. Klassischer Fall von selbst in den Fuß geschossen.
Kolab führt meiner Meinung nach deswegen ein Nischendasein, weil es mit seiner Designentscheidung, Kalender und Kontakte als IMAP-Ordner zu integrieren, spezielle Clientunterstützung benötigt. Viele andere Systeme basieren ja auf SQL-Datenbanken, die Kolab nicht benötigt. Allein jetzt Horde als Webclient beizubringen, Kolab nativ zu unterstützen, hat (glaube ich) 2,5 Jahre gedauert.
Die Struktur des Kolab-Konsortiums finde ich aber recht interessant. Man bietet Firmen professionellen Support an, aber die Ergebnisse dieser Entwicklungen fließen wieder in das Kolab-Projekt frei zurück. Immerhin scheinen davon 4, 5 Firmen in Deutschland leben zu können. Somit ist ein gewisser Erfolg wohl da. :-)
Spannend wird es, ob Kontact für Windows auch ein Push für Kolab bedeuten wird. Ich bin das mir nicht so sicher, da ich weiß, wie sehr auch hier in der Firma die Kollegen an Outlook gewöhnt sind und alles, was anders funktioniert, als nicht funktionell betrachten. Und schon die "Outlook-Konnektoren" zeigen ein verdächtiges Andersverhalten. Dabei bilden Kolab/Kontakt ein vorzügliches Gespann.
Bye
Thorsten
Da zäumst du den Esel bauchwärts zum Schwanz hin auf. Es ist Aufgabe der Distributoren, Kolab zu integrieren, nur waren die Leute von Kolab bisher nicht fähig, Kolab distribuierbar anzubieten.
> Openpkg bildet eine distributionsunabhängige gemeinsame Basis mit eigenem Sicherheitsmanagement.
Darauf läßt sich kein Distributor ein.
> Nicht umsonst konnte eine Source-Code basierende Distribution wie Gentoo solche Spezialanforderung einfach per USE-Flag umsetzten und eher integrieren.
Kolab ist bisher nicht im Gentoo-Repository. Es gibt gerade mal ein Overlay.
> Vermutlich wird es in Zukunft leichter sein, dass Distributionen selbst Kolab-Pakete anbieten werden, wenn sie es denn wollen.
Solange da keine massiven Nutzeranfragen kommen und die Kolab-Leute jeden "Scheiß" bis zur libpng paketieren, anstatt ausschließlich die "echten" Kolab"-Pakete anzubieten, so daß der Integrationsaufwand in die Distributionen einigermaßen tragbar ist, segelt Kolab unter ferner liefen.
> Die Struktur des Kolab-Konsortiums finde ich aber recht interessant. Man bietet Firmen professionellen Support an, aber die Ergebnisse dieser Entwicklungen fließen wieder in das Kolab-Projekt frei zurück. Immerhin scheinen davon 4, 5 Firmen in Deutschland leben zu können. Somit ist ein gewisser Erfolg wohl da.:-)
Welche Firmen nutzen den Support denn? Bisher hat da doch hauptsächlich Vater Staat reingebuttert, wenn ich mich nicht irre.
Das ist ja noch schlimmer als Packete oder Standart. ;-)
Einzig kann man nicht weiter steigern, weils schon superlativ ist, und nicht nur das, es ist ein Absolutadjektiv und daher ist "einzigst" ein Hyperlativ den es nicht gibt. (Ich wollt eigentlich nur bei Wikipedia gucken ob superlativ das richtige Wort dafür ist, aber wo ich schonmal da war kann ich auch mit dem Wissen auf die Kacke hauen)
SCNR Vollhorst
"Virtual Box" (wie oben schon vorgeschlagen) oder "Qemu" verwenden. dann kannst du praktisch jedes Programm ausprobieren, ohne irgendwas kaputt zu machen. Der einzige "Overhead" ist die Virtualisierungsumgebung zu installieren, virtualisierte Linux-Distributionen gibt es nicht nur für "VMware" sondern auch für "Virtual Box" mittlerweile zum Herunterladen oder mit etwas Glück läuft auch eine "VM" von "VMware".
Oder du installierst dir einfach die Distro deiner Wahl in die "Virtuelle Maschine".
Virtualisierung ist schon was feines. 8-)
Gefahrensucher