[Kolab-devel] Kolab3.0beta/Debian: Sending mail from Roundcube fails

[Jeroen van Meeuwen (Kolab Systems)]

On 2012-12-06 07:46, Administrators ITSEF wrote:
> Quoting "Jeroen van Meeuwen (Kolab Systems)" 
> <vanmeeuwen at kolabsys.com>:
> 
>> A later version of pykolab (0.5.8-6 iirc) includes a setup-kolab that
>> fixes this, by providing / writing out /etc/postfix/sasl/smtpd.conf
> [...]
> 
> Thanks - I'll try that! That's issue1398, if I'm not mistaken? I saw
> that, but apparently didn't connect the dots... Also, you've
> indirectly answered my question from another mail ("How to deal
> correctly with updates?") - apparently, at this moment in time updates
> to packages like pykolab do nothing to actually implement such updates
> on an existing system, which means one still has to make all relevant
> changes (like the one you're describing in this mail) oneself - even
> if the upgraded package has been installed.
> 
> (...snip...)
> 

You're entirely correct and we should find a way to communicate any 
changes a deployment would need in order to get up to par, especially if 
the changes are not applied automatically and require some sort of 
manual intervention.

I had spent some time (some time ago) on our Release Notes:

   
http://docs.kolab.org/en-US/Kolab_Groupware/3.0/html/Release_Notes/index.html

Seeing as how we would need to release update instructions to a 
multitude of platforms.

Regrettably, that doesn't seem to scale either - my time is stretched 
thin (as you can see we were at issue #782 and we are now at #1436) and 
many issues apply only to a certain package version for a certain target 
platform.

Originally, the thought was to not push out updates (to the updates 
repository stage) until the release notes had been fixed, and so we 
would increment from "Kolab 3.0.0" to "Kolab 3.0.1", if you will, and 
release all the updates (to the stable updates repository stage) in one 
go, together with the new release notes (maybe monthly, or something 
like that).

People that needed fixes earlier would then use the updates-testing 
(quality assurance is working on this), or even development (eats babies 
for breakfast / may break your installation) repository stages.

Right now, as you are well aware, things are still moving quite fast 
and are only available through the development repository.

My ultimate target is to be able to apply a level of configuration 
management[1], preferably in a networked fashion, and *not* LDAP - so 
multiple systems *and* the web admin panel can interact with it. I opted 
for a SQL database, and I have a little play area on my workstation that 
sort of works but in no way completely exhausts all of the option value 
included with a Kolab Groupware deployment.

Supposedly, if all is well and dandy, this will lead to the 
availability of what we at Kolab Systems lovingly call "kolab 
act-accordingly".

Perhaps you're interested in giving it a spin (on a throw-away test 
system)? If you are, let me know, and I'll push something out to a 
development branch in pykolab.

Kind regards,

Jeroen van Meeuwen

[1] 
http://www.intevation.de/pipermail/kolab-devel/2012-March/013333.html

-- 
Systems Architect, Kolab Systems AG

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

pgp: 9342 BF08