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

[Paul Boddie]

On Saturday 9. April 2016 11.10.10 Jonas Smedegaard wrote:
> 
> 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.

OK. I'll do that shortly.

[...]

> 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.

Alright. Having read that bug report you mentioned, as well as considering the 
need for people to coordinate configuration across packages (which I imagine 
is what Debian-Edu and FreebomBox want to do), I suppose that some kind of 
mechanism will eventually be developed in Debian to allow this in a way that 
doesn't surprise or confuse administrators. (I suppose this is where all those 
cloud-related deployment tools come in, but I've kept somewhat away from them 
for now.)

[FreedomBox]

> 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!).

Ah, OK. I remember you promoting it at FSCONS a few years ago, and I thought 
you might still be involved. I agree that it should "just work" and that 
making users take decisions that they aren't necessarily capable of doing 
isn't fair to those users. (The "Internet of Things" will make all this even 
more critical, of course.)

[...]

> 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).

I think I have realised that there might not be the support for coordination 
(or maybe they call it "orchestration" in things like chef or puppet) in 
Debian as such, which is what I was hinting at, hoping that there might be 
some answers in all that policy documentation.

> 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).

Great! I think we both understand what each other is doing or wanting to do 
now. :-)

[...]

> 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.

OK. I defer to your greater experience in such matters. I was merely concerned 
that the maintainers might object on the grounds that everybody might start 
asking to add random transports and thus "bloat" the configuration. Then 
again, it might encourage people to develop a better mechanism for managing 
the configuration (some kind of master.cf.d, perhaps).

Actually, this reminds me of the lmtp and Cyrus bug report that I believe I 
mention in the documentation:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=494746

Here, people just want stuff to "just work", but one gets the impression that 
the maintainers aren't interested in letting that happen. The result is that 
people will then make mistakes only to be told that they did it wrong, of 
course.

Mailbox integration (as I call it) is also mostly peripheral to imip-agent: a 
mechanism must exist to allow the software to deliver messages to recipients, 
but this can be done using "local SMTP" rather than LMTP. Indeed, when I 
figured out how to route mail locally via SMTP, I was rather pleased with 
myself, particularly in light of complications like the above.

[Exim]

> 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.

I'll take a look for Exim-related configuration in other packages.

[...]

> 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!

Yes, this is where Kolab is quite rigid in the default configuration, and 
although the sky is the limit with regard to what one actually sets up, I 
think it is more appropriate to minimise the actual dependencies on a schema 
in the software itself and let people decide what their organisation's policy 
should be. I doubt that a lot of organisations want to have to decorate their 
existing schema with extra stuff just to make a system work, but I might be 
mistaken there (because maybe they readily revamp their schema out of 
enthusiasm/desperation).

Indeed, I've even confined LDAP integration to the mail system in order to 
make my software oblivious to it, and I've tried to find generic object 
classes for the appropriate concepts rather than making new ones.

(Before I forget, and given that this is a "groupware weekend", I will also 
try and dig up my Thunderbird/Lightning extension for reading Web-based 
free/busy information and consulting the LDAP FBURL attribute in order to know 
where to read such information from. It may be of interest to the 
Icedove/Iceowl participants.)

[...]

> >> 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.

It's the "court notice" near the end (and there's also some "delivery" spams, 
too):

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=311188#394

I've reported the spam using the link provided at the bottom of the page, so I 
imagine it will disappear at some point.

As for the discussion about debconf and configuration files, which is a whole 
new area of discussion, I looked into this a bit when working with the Kolab 
packaging, and I even wrote some simple Python libraries to inspect and modify 
various different kinds of files. But aside from the policy implications, it's 
really not a nice thing to do anyway. That's when I really appreciate the 
"whatever.d" approach where you can isolate each fragment of a package or 
system's configuration.

Now, if there were a way of saying at a system level, "integrate Postfix with 
Cyrus using LMTP" with the necessary recipe being run that copies files into 
place, enables things, maybe verifies users and groups (thinking of the above 
bug report about Cyrus and LMTP), and does all this in a Debian-approved way, 
that would eliminate a lot of the "how to" following that otherwise has to be 
done manually. But I suppose that the mechanisms need to evolve to make this a 
possibility.

Sorry for the long response and clumsy humour!

Paul