[Labs-l] role::mail::(sender|mx) conflict

Thu Oct 9 17:13:16 UTC 2014

Short term the only way forward seemed to be to make deployment-mx its own 
puppetmaster. So I did that, modified local site.pp to leave out 
role::mail::sender, and added beta::puppetmaster::sync so it should stay 
in sync otherwise. Once I generate some labs-use DKIM keys we should be in 
business.

Long term it sounds like heira is the way to go.

On Wed, 8 Oct 2014, Tony Thomas wrote:

> The way I made an mx in my labs instance was :
>  1. made the instance a self::puppetmaster
>  2. remove 'include role::mail::sender' from class standard ( manifests/site.pp )
>  3. add 'include role::mail::mx' under node default( manifests/site.pp )
>  4. remove 'include role::mail::sender' from role/labs.pp
> That one did a successful puppet apply - and I got the mx configuration alright. A minor issues is there -
>  '/etc/exim4/wikimedia_domains' is not found for the exim to start - but upon creating that file - exim ran and started listening
> on port 25.
> 
> This would necessarily need the labs machine becoming a self::puppetmaster, but the better outcome - as per JGreen is:-
>       9:07 PM Jeff_Green> what I would like to see is a checkbox for each role::mail::* class on the instance config page,
>       with [x] role::mail::sender by default and you'd have the option to uncheck that, and instead select [x] role::mail::mx
>       or in the future, other role::mail::* classes.
> 
> 
> That would require a lot of dev works though, but the best way out.
> 
> Thanks,
> Tony Thomas
> FOSS at Amrita
> 
> "where there is a wifi, there is a way"
> 
> -----BEGIN PGP PUBLIC KEY BLOCK-----
> Version: GnuPG v1.4.12 (GNU/Linux)
> 
> mQENBFQqXKkBCACxZX3/IsdT1ONRA/RTDrn3/9QrGHfo2sXt2o9x3K7TTrsdACOO
> MwifMU7NuWGDw0k4vYxrXylJ0Xli8ukL9EK1ZXLYoKqEexk+ZGB9hibDBbc2TRX+
> hOL3hCjVmsHXB4zA5ZRMActX0XmT//VOBPqNJlVrWNBe4qXrrgm5Oeo23JkuVpxd
> AhukLdFHs1we+dCy0a1a1FHNbvshFvmDByOzctNMfg0OMmh0+PNKRmC1YhBn0Tpf
> aVCjTO64sP86dwv80AQRMZ3CMys8LOiD5d7nyf3cQkS3Y5Si4T8F2PQXPaEJO78q
> uEKeA3JAjGPkVqcwhz8NowcLTDLVYuTgu61rABEBAAG0SlRvbnkgVGhvbWFzIChN
> eSBFbGVjdHJvbmljIENvbW11bmljYXRpb24gR1BHIEtleSkgPDAxdG9ueXRob21h
> c0BnbWFpbC5jb20+iQE4BBMBAgAiBQJUKlypAhsDBgsJCAcDAgYVCAIJCgsEFgID
> AQIeAQIXgAAKCRC5LTf83q1l3pLQCACkfkrUvLucgA9CP22sRGnFNDAB0zCI/vlE
> Ku/SlNfVgihgxeT2gU48HhcXC1p88QQkXOLAgK2suKh93kD7d0swwWBk0+ECyk+q
> WbN/9MuY6ZBR7CsDyahpvo170oV7Ndr9QctAkVi/H6qrD0ptIHIhgk9/KPZntCtb
> Xe2Tv7ig62KCFgOLSDk4FYMWe+CQaMkIiiSxrUoBXV+6KkUpa42y/lTNK2Lpti5P
> 4K2s1HaoLrS1tNTEXorppFsJ/wCHDrVoLlQdkUDYiVCKxTFCXIhR0JNml7qT5o+N
> +MHDD68Ag4NaUW3eQvzWDl5an7+rWBn4tUKAcIJPI7esREEr6zXsuQENBFQqXKkB
> CADiklo5t+wzgifTGRDyNCKpe5RnES8dWXp02kyaqlO8yZwBO1UaZq7+LJjdzUtH
> FAQrqnSm38WOrb8iqE+5lwghx3tdsjzvgriuoDqAkVx4tB6ZkftjvWQULiE2jzni
> z0171tvLrXNRiRut88+ZMD/XfqnDej8/JoBQnM+qYDFDDnLUCUPqv9vvoRDX1nmJ
> guhRak4NmWS3gyLvdbc81p/HU2IX87UnlozDl1aO5cJ4xDkYRED84eLhCrYLjYMy
> acEJ7gcwTRLwlmAUTVOfLEJUexwlwDnu7Hsi8dFsgNL3AMPmk7NmoG+Ii2veW7Kl
> 4BjjjobrVFX00lvc9GoX5XDHABEBAAGJAR8EGAECAAkFAlQqXKkCGwwACgkQuS03
> /N6tZd7uBgf8CtmNsLogc06f0z25PI+12uco7lFat2WKS/gmRjbMw1E6qlQryDPo
> FTTwQNm7lPcB9AwebfQPOia/agLngGnODzU3jHcP7VYyRz/UD2Vl3B3aAP6zdONf
> 0i+qYiZYyGELM6nAd/c7j7HMWx/ExK+V55SP7kEauacU23lAR6ZNq3ByLuNCy7Je
> RkE3tRrBkKsMeOefenDAg1towXb5rLKTuUrxMabY+hN4CmbcQOHpGYvc6UCegetv
> eoBFgXC37HCZCE7Oh2CybIQ7h4/9eNA2c0Liy2pEfPkM0SCcrKR5sdZWeUp6fi/G
> 8yer4k4CeY31ksrR7CaWs25hboLNF7eIvg==
> =2EAw
> -----END PGP PUBLIC KEY BLOCK-----
> 
> On Tue, Oct 7, 2014 at 10:58 PM, Marc A. Pelletier <marc at uberbox.org> wrote:
>       On 10/07/2014 01:26 PM, Marc A. Pelletier wrote:
>       > I'm thinking hiera might be a better solution here;
>
>       Ignore that bit, it's leftover from before I realized that a puppet
>       variable is a simpler solution.  :-)
>
>       -- Marc
> 
>
>       _______________________________________________
>       Labs-l mailing list
>       Labs-l at lists.wikimedia.org
>       https://lists.wikimedia.org/mailman/listinfo/labs-l
> 
> 
> 
>