[Debian-rtc-admin] prosody config, status update

[gustavo panizzo]

On Thu, Jun 13, 2019 at 02:50:25PM +0200, Jonas Smedegaard wrote:
>Quoting gustavo panizzo (2019-06-13 13:08:52)
>> I've been working on how to maintain and update the prosody config
>
>Great!
>
>
>> this is my current attempt using puppet and the module Victor
>> suggested
>[...]
>> My goal for the first iteration is to have the patch merged by DSA so
>> we can have a way to deploy changes in the service easily and
>> auditable,
>
>Your previous draft tracked plain configfiles, and you've [questioned]
>the need for us using Puppet.  What changed?  Did I miss some
>conversation?
>
>[questioned]: https://alioth-lists.debian.net/pipermail/debian-rtc-team/2019-May/000112.html
>

I thought more about it

we'll need more from DSA to administer the service, for example sudo to
prosody user to further troubleshoot issues when they arise, list users
(how to enable http_uploads without knowing that?)

DSA uses puppet and takes care of patching, takes care of ssl
certificates, backups, monitoring, etc.

Using puppet is a way (IMHO) to have a closer relationship with DSA, so
it should make easier the outgoing relationship/maintenance.

>
>> afterwards (help welcomed!) I'll add anti-spam measures and
>> http_uploads :)
>>
>> reviews of the MR are very much welcomed
>
>I am not familiar with Puppet so cannot help review that.
>
>It seems to me noone else in the team is familiar with it either -
>including Victor who wrote previously that he has "no idea how to test
>this and see what the result would be."
>

I tested the code in my prosody server, I can replicate the current
config, however is true that is not a 100% equal test.
I was expecting Victor the help with the review and then of course DSA
will review the patch.
After that, changing features of the service is just adding key =>
values in puppet code

>For urgent fixing the current setup it is enough that one person (you,
>Gustavo?) is capable of administrating the configuration, but it is
>quite relevant to understand if one specific approach is the only one
>available to us, or if we have choices then take into account how many
>of us are able to handle different approaches.
>

The current setup is not versioned, there is no way to audit if someone
made a change, there is no way to rollback changes.

Before doing anything else we need to put the configuration
under git and automate the deploy so there are no more manual changes

Regarding on how to drive the future changes, I'm open to ansible and I
can help with the ongoing maintenance of it but I won't make the initial
implementation as I'm not as confident with ansible as I'm with puppet ATM

TL;DR 

I feel comfortable with both approaches, Makefile and Puppet. I
personally think puppet is cleaner and more future-proof.
If as a team we choose one of them I'll stick to it, if someone else writes a
clean ansible deployment, and we agree to it, I'll help maintaining it in the future.

I'm pretty much open to any *proper* way to maintain the service we
agree as a team. I wrote something for the two I'm the most comfortable with 

-- 
IRC: gfa
GPG: 0x27263FA42553615F904A7EBE2A40A2ECB8DAD8D5
OLD GPG: 0x44BB1BA79F6C6333