[Kolab-devel] Cyrus didn't answer on port 993, SSL missing_

[Jeroen van Meeuwen (Kolab Systems)]

On 2013-05-11 23:25, Thomas Spuhler wrote:
> It may be easier when the distribution add the specifics.
> 

Considering consumers (community and customers alike) come to us (Kolab 
Systems and the Kolab community) with questions (either mailing list, 
bugzilla or support tickets), I don't think that's entirely accurate.

I think it is of crucial importance for the distributors to work with 
upstream in order to solve problems in ways that allow the product to 
grow in ways that will keep a somewhat consistent installation procedure 
across distributions, without having to patch, re-patch or provide one 
distribution's own version of the product.

> I would appreciate if you, or somebody else from kolab could help on
> some of the issues.
> 

We can, and we do - I think it is important to make a distinction 
between two types of problems;

1) software problems (feature $x no worky),

2) platform specific or packaging problems (no 
/etc/pki/tls/private/localhost.pem, missing/wrong dependencies),

> I think also of cleaning up some of the packages such as the
> /etc/roundcube/main.inc.php where we have some none-existent plugins 
> and some are called twice.
> 

It is really up to the community and the distributors to work with 
upstream on defining what plugins we should or should not enable by 
default.

The list of plugins currently enabled by default refers to the list of 
plugins shipped with the roundcubemail package to Enterprise Linux 6.

If these plugins are not available for other platforms, I suppose we 
have two options;

1) provide the plugins for these platforms, or
2) remove the plugins from the default configuration.

I reckon 1) is product enhancement (if the community agrees these 
plugins enhance the user experience), and 2) is the easiest to do (even 
on a distributor level, patching 
pykolab.git/share/templates/roundcubemail/main.inc.php.tpl).

Alternatively, we could choose to make the templating engine currently 
used a little more intelligent, checking whether the plugins actually 
exist on the system and only enabling those that are.

> Doing the automatic start of dirsrv at instance.sevice
> 

I'm not sure I fully understand what the problem is with 
dirsrv@$instance.service.

Running the 389 Directory Server setup (whether manually or through 
setup-kolab) gives me a .service entry in 
/etc/systemd/system/dirsrv.target.wants/dirsrv@$instance.service.

Executing "systemctl show dirsrv.target" gives me the desired output.

If there's something that does not work, I would like to get more 
information about how it is supposed to work, and what unexpected 
results you are getting (rather than just "$x does not work").

> We the packagers in return help on finding bugs to compensate for 
> kolab's help.
> 

Please do note that I myself am included in "We the packagers".

> For example, I can provide the above file that has been cleaned.
> 

See the aforementioned - setup-kolab does not write out this file, and 
I'm not sure what cleaning is required.

Kind regards,

Jeroen van Meeuwen

-- 
Systems Architect, Kolab Systems AG

e: vanmeeuwen at kolabsys.com
m: +44 74 2516 3817
w: http://www.kolabsys.com

pgp: 9342 BF08