February 06, 2012, 12:00:58 AM *
Welcome, Guest. Please login or register.

Login with username, password and session length
News: Work on Kolab2/Gentoo-2.2 has stopped. The project has been deprecated (see board Kolab2/Gentoo).
 
   Home   Help Search Login Register  
Pages: [1]
  Print  
Author Topic: Gentoo/Kolab vs. official OpenPKG  (Read 2440 times)
timpoluk
Newbie
*

Karma: 0
Posts: 9


View Profile
« on: December 12, 2007, 12:34:13 PM »

Some general questions:

After initial problems emerging Gentoo/Kolab I tried several
OpenPKG versions (including latest betas) and experienced a
strange effect: It didn't compile to the end but already installed some compiled stuff into /kolab, added kolab* users
to the system and changed other files in /etc. But, of course,
the installation was incomplete and not working at all.

After this Gentoo/Kolab compiled for me but I forgot to remove
the stuff from the previous OpenPKG install. bootstrapping seemingly worked and I even was able to login with the webadmin interface and could create a new user.

When I looked in more detail at the system I saw the kolab users
in passwd with openpkg shell and was wondering how it was working.
Then I realized that kolabd was not running and started it but
it came up running as root (I changed the openpkg shell to bash).

Are the kolab users not neccessary on Gentoo/Kolab? I didn't saw
any warnings/errors in the logs.

What is the preferred way to change directories for apache (/var/www) and imap without symlinking? I guess it has to be done somehow in the templates!?

How do I get Horde and WebDAV emerged, i.e. where do I place
the USE flags? Can I emerge it without doing any bootstrapping?
In general, can I upgrade kolabd just by emerging?

Kolab is for collaboration and what I know for now is, that on
a working Kolab installation, all users can lookup other users.
Is there a way for the admin to prevent this. I.e. the admin should
be able to restrict the users in a way that they can only lookup
other users in the LDAP address book for whose they have been authorized.

Best Regards,

 Werner
Logged
Gunnar Wrobel
Administrator
Sr. Member
*****

Karma: 2
Posts: 331


275141552 gunnarwrobel@yahoo.de gunnarwrobel
View Profile WWW Email
« Reply #1 on: December 12, 2007, 01:12:42 PM »

Hi Walter,

Some general questions:

After initial problems emerging Gentoo/Kolab I tried several
OpenPKG versions (including latest betas) and experienced a
strange effect: It didn't compile to the end but already installed some compiled stuff into /kolab, added kolab* users
to the system and changed other files in /etc. But, of course,
the installation was incomplete and not working at all.

Sad to hear that the OpenPKG versions did not compile. I'd wish OpenPKG would be a little bit more robust. At least as long as the Gentoo version still has that many problems of its own.

After this Gentoo/Kolab compiled for me but I forgot to remove
the stuff from the previous OpenPKG install. bootstrapping seemingly worked and I even was able to login with the webadmin interface and could create a new user.

When I looked in more detail at the system I saw the kolab users
in passwd with openpkg shell and was wondering how it was working.
Then I realized that kolabd was not running and started it but
it came up running as root (I changed the openpkg shell to bash).

Are the kolab users not neccessary on Gentoo/Kolab? I didn't saw
any warnings/errors in the logs.

I never did a full and thorough analysis of the user/group state for Kolab2/Gentoo. The kolab users are currently only used in a very few places and probably incorrectly. With the additional knowledge of the different packages I have now, it should be possible to correct that.

This will happen for Kolab2/Gentoo-2.2 since I introduced many upstream changes so that we get cleaner packages with a saner installation process.

What is the preferred way to change directories for apache (/var/www) and imap without symlinking? I guess it has to be done somehow in the templates!?

The imap spools is something you can configure in the cyrus specific templates. The webroot location is somewhat more difficult because the packages from the 2.1 version still use a fixed web root of /var/www. This will change with 2.2 and the packages will be real webapps in the sense of a Gentoo webapp.

How do I get Horde and WebDAV emerged, i.e. where do I place
the USE flags? Can I emerge it without doing any bootstrapping?

I consider the Horde installation still experimental. Mainly since I did not describe it very well yet. WebDAV relies on the apache configuration. You have to enable the use flags on the kolabd ebuild. For horde you will have to emerge the corresponding horde-*-kolab packages.

In general, can I upgrade kolabd just by emerging?

Yes, though there is not yet a clean upgrade path for Kolab2/Gentoo. At the current state of affairs I just cannot safely provide that. The problem here is that the original Kolab2/OpenPKG variant is an extremely controlled environment where the developers know exactly what the surrounding conditions are and the user choices are extremeley limited. This has also strongly tainted development of the Kolab specific source code.

Gentoo on the other hand has the motto "It's all about choice" which to me sometimes represents the exact opposite of OpenPKG. Thus porting Kolab to Gentoo and running it safely on that platform took and still takes a lot of fixes.

Kolab2/Gentoo will cease to be experimental and provide a clean upgrade path once all upstream packages have been corrected for clean packaging (currently kolabd and kolab-webadmin left) and the configuration machinery has been completely rewritten. This will take about another year.

Kolab is for collaboration and what I know for now is, that on
a working Kolab installation, all users can lookup other users.
Is there a way for the admin to prevent this. I.e. the admin should
be able to restrict the users in a way that they can only lookup
other users in the LDAP address book for whose they have been authorized.

If you don't want an LDAP entry to be publicly visible, make it an internal account. This option is available when creating a new user.

And sorry for being that slow on your autoconf issue. I sometimes tend to be too busy with all the different project that it takes too much time to respond to questions.

Cheers,

Gunnar
Logged
Pages: [1]
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.11 | SMF © 2006-2009, Simple Machines LLC Valid XHTML 1.0! Valid CSS!