[Calendarserver-discuss] Free Software calendaring and groupware (in and beyond Debian)

Sat Apr 9 09:10:10 UTC 2016

Quoting Paul Boddie (2016-04-09 01:23:25)
> On Saturday 9. April 2016 00.21.49 Jonas Smedegaard wrote:
>> Quoting Paul Boddie (2016-04-08 22:43:57)
>>> The basic installation (tools/install.sh) involves only the program 
>>> files plus filesystem resources, which is a common Debian phenomenon 
>>> in my experience. It does put things in /etc/imip-agent, which might 
>>> not be done in the best way because something should be checking for 
>>> changes (maybe a debhelper thing).
>>
>> Right - I intend to leave your configfiles as dpkg conffiles at 
>> first.
>
> I guess that's probably good enough for now, if I pretend to 
> understand what that really means from having seen it in use. ;-)

Paul: Please make a formal tarball release of your project.  If you feel 
it is very imperfect yet, then make it a version 0.0.1 or even 
0.0.1alpha00001 - just please make a release, as that is far easier to 
work with than me doing an unofficial snapshot from git from Mercurial.

>>> How the software plugs into the mail configuration does involve 
>>> decisions, but even then it should be possible to install some files 
>>> somewhere and have the mail system reference them if configured to 
>>> do so, deferring that configuration to a later time.
>>
>> Apache can handle that, but MTAs? I am only familiar with postfix 
>> myself, not exim, but am surprised if any of them support hooks 
>> reliably.
>
> I was more or less thinking that one would copy files into somewhere 
> neutral - I don't know if /usr/share/imip-agent is sensible or 
> strictly forbidden, but really somewhere that isn't, say, /etc/postfix 
> (or /etc/apache2/sites- available, for that matter) - and then the 
> administrator could reference this from within the other package's 
> configuration, typically by using a file that does some kind of 
> include, if supported, or just copying it into a suitable place 
> otherwise.

I believe that for for moving towards a (possibly future) situation of 
automating, the location for not-enabled-by-default snippets should be 
tied to the consuming daemon - like done with apache in recent time.

> I guess stuff like this is done for FreedomBox, so perhaps I should 
> take a look at that. You appear to be an expert there as well. :-)

Honestly I don't know how FreedomBox works - I am still devoted to the 
idea of it and help out with eagerly promoting the use of OSHW for it, 
but stopped following the implementation of it when it became clear that 
it was so blatantly tied to a web-based non-debconf admin interface: I 
strongly believe that the right approach is to a) internally hook into 
debconf (so that we extend existing Debian packaging structure instead 
of inventing a new interface specifically for FreedomBox), and b) not 
expose any admin interface to the user at all - because the very vision 
of Freedombox (compared to a NAS or other boxes) is removal of the admin 
from the box (not turning users into admins!).

>>> Again, I've seen various Debian packages do that. Nothing actually 
>>> gets installed into the configuration of other software: that's an 
>>> administrator decision.
>>
>> Hmm - which software does smart integration like that?
>
> I was probably referring to the installation of sample files that the 
> administrator then needs to edit and enable, rather than anything 
> particularly exotic. I can think of many happy hours configuring 
> things like Dovecot where there are lots of configuration files 
> referencing other packages and systems that may or may not be 
> installed, but where the maintainers presumably thought that such 
> files would nevertheless be useful.

Fair enough, I misunderstood you then: I thought you were talking about 
_Debian_ automation (not only potential for _admin_ automation e.g. 
using chef or puppet or CFengine).

What I will do is ship all your configfiles as example files, and 
additionally (patch and) ship the eventual subset where a 
not-enabled-by-default consuming infrastructure exist (which includes 
apache2 and uwsgi and possibly no other for now).

>> What I expect to do is file a bug (with a patch) against postfix to 
>> include in its default master.cf your snippet for a generic lmtp 
>> handler - that seems a clever approach to me, and sensible to 
>> support.
>
> I don't even dare to file such bugs/patches, partly because I'm no 
> expert with MTAs, partly because the MTA people don't always seem that 
> approachable, and partly because even that patch to master.cf might be 
> regarded as too specific to a particular configuration choice.

If you look at the "Other external delivery methods" section of postfix 
master.cf - how it contains support for mailman.  Search its changelog 
file for "mailman" and you'll find bug#297869.  That's how to approach 
it - and our suggesting support for a generic lmtp transport is far more 
sensible than that package-specific transport.

>> Then I would simply leave the rest as example scripts and accept 
>> patches for more integration from others actually understanding those 
>> parts (I am not very familiar with ldap, and as mentioned not 
>> familiar at all with exim).
>
> Exim uses a special update script that lets the administrator maintain 
> fragments in separate directories that then get concatenated and given to 
> Exim. This means that it can be configured in a flexible way.

Sounds like you know about that part: Would be helpful if you could 
provide me a concrete suggestion for a layout for that which I could 
package - or point me to a concrete package doing similar hooking that I 
could model from.

> The whole "LDAP versus something else" choice starts to move quite far 
> outside mere configuration and into the realm of policy. In the 
> conf/exim and conf/postfix directories, I've separated the 
> policy-related stuff into "simple" and "ldap" directories, and these 
> lie at the outermost reaches of the basic configuration activity.
>
> With regard to configuring LDAP itself, it's really outside the scope 
> of all this altogether: I just included some examples to help other 
> people like me get started, given that my LDAP expertise was minimal 
> not that long ago (and maybe still is).

From my limited understanding of LDAP, most packages does it wrong: 
Impose a specific hardcoded model instead of (correctly) hook into a 
sysadmin model of the organisation.

I don't expect to do more in the foreseeably future than provide example 
files regarding LDAP!

>>> Although there is a degree of integration required for the software 
>>> to be useful, at least we're not aiming to configure everything 
>>> related to it as well. (That was the challenge with the Kolab 
>>> packaging and trying to replace the notorious setup-kolab script.)
>>
>> Attempting to configure other parts than the package itself is a 
>> no-go. See bug#311188 for a long-standing instance of that.
>
> That's an interesting discussion! I see things got so serious that it 
> was about to end up in court. ;-)

Where?!? I don't recall that bit.

 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: signature
URL: <http://lists.alioth.debian.org/pipermail/calendarserver-discuss/attachments/20160409/f5afb7fd/attachment-0001.sig>