Re: [GTALUG] At the GTALUG AGM: How we handle Internet services
On 01/12/2022 02.30, ac via talk wrote:
When "directors" or "boards" or "leaders" make decisions on policy it affects operations. Always. and many times it is "politics" and ...
Note that in our case, GTALUG directors are very close to the users. Generally, the services we have are the ones the users were interested in. I've been on the board twice, I've seen all the little cogwheels turning ...
... then you need more automation/scripts - seriously, it cannot take that much of your time
Part of the problem is that a whole bunch of GTALUG services are held together by legacy scripts. Which the maintainer has moved on from. Which the new operator may not understand, or even know they are there. We may have lost the documentation (though it's probably in the GTALUG github, somewhere - most likely last edited by Chris). So more automations will solve some problems and create new ones too. You also can't automate moderation in any useful way There are no 'clock' problems: everything here is a 'cloud' (to appropriate Karl Popper's concept of defined, soluble problems vs indeterminate, insoluble ones). The board is burned out. It's good that folks are stepping up, but it might not be enough. Thanks, Evan, for your thoughtful answers. Whatever system we end up using must have public, web-accessible archives, as anything locked behind a user login is not a useful resource. Stewart
On Thu, 1 Dec 2022 23:20:09 -0500 "Stewart C. Russell via talk" <talk@gtalug.org> wrote:
On 01/12/2022 02.30, ac via talk wrote:
When "directors" or "boards" or "leaders" make decisions on policy it affects operations. Always. and many times it is "politics" and ...
Note that in our case, GTALUG directors are very close to the users. Generally, the services we have are the ones the users were interested in. I've been on the board twice, I've seen all the little cogwheels turning ...
this is good news, nut it seems that, as a group, we do not have actual policy rules regarding incoming email relay? I am willing to work with any other admins or by myself to harden and configure or re-configure any of the scripts any other admin has added to the vps linode@penguin.gtalug.org - and I can setup rules for the smtp server - so that it could function the way the group/board specifies. I could also setup wordpress, harden etc - but again - rules will be needed - plugins/theme additions etc. etc. and add any of the other services the group requires. At the AGM may someone also discuss the option that the services could be split? - it does not have to be all @google, we can re-configure the gandi zone to utilise the best of everything? Regarding even mailing lists @google - I do not see any technical issues, but I do see rules/policy issues/problems - @google there will be other issues, for example for myself @ a dot me domain name, which relay frequently either disappears or ends up in spam boxes, and other issues for people with no main @gmail.com accounts, etc. So the policy or user group rules should deal with the actual issues for example if any user relays from @google (or any hacked/abusive smtp server) and that server is listed as drop on abc/xyz/what? rbl as DROP, then what are the rules? Should our server simply whitelist the affected smtp server? or should the server bounce the email (as it is probably setup to do now) (or should the email simply be deleted and disappear (which our server could also be setup to do...)
... then you need more automation/scripts - seriously, it cannot take that much of your time
Part of the problem is that a whole bunch of GTALUG services are held together by legacy scripts. Which the maintainer has moved on from.
Uhm, okay, but we all (all system admins) have our own scripts that also work on mailman... soo, I am still not getting the issue(s)? (and we can all read conf files, and read any scripts/code and either edit/replace/whatever as required)
Which the new operator may not understand, or even know they are there. We may have lost the documentation (though it's probably in the GTALUG github, somewhere - most likely last edited by Chris). So more automations will solve some problems and create new ones too.
unless the scripts are compiled and there is no source, (in which case the new/other/any admin will just add their own) I do not understand how an admin would not know/find/edit any of these legacy scripts?
You also can't automate moderation in any useful way
on the smtp side additional scripts could reduce incoming trash, which will reduce high end admin load, there are also some additional changes that could be made to reduce/automate some of the admin. and there is no shortage of additional high level admin volunteers, as Erica has demonstrated? Just a thought about docs though, maybe we can make another rule that everything must be documented, exactly so that anyone can easily do whatever they need to do, so if there are/were/is no current proper doc, this itself can also easily be fixed) - in fact this should probably be done anyway, no matter if we end up at @linode or @google or at a mix of both
There are no 'clock' problems: everything here is a 'cloud' (to appropriate Karl Popper's concept of defined, soluble problems vs indeterminate, insoluble ones). The board is burned out. It's good that folks are stepping up, but it might not be enough.
email spam @google or @microsoft or @most_places have been mostly stopped and in 2022 there is still some spam, but it is not a problem at most providers. Sure, something still leaks through when trusted users own accounts are compromised, but in general, there are no more real issues with spam... and there are so many reasonably accurate real time services - so filtering incoming relay is not an insoluble problem, it does just need rules though. so, advice for a burned out board: Improve settings by adding, following and accepting rules, then, get/involve more high level admins and add more software to reduce high end admin load I guess ymmv but with a little tolerance - if your @google server does not seem to be able to deliver to @gtalug - and/or correctly asking/blaming your @google provider, OR making user group rules stating that @google (or anyone) is to be whitelisted if their servers are abusive and they also expect to relay email or/and a whitelisting web interface (10 minutes) to whitelist the abusive @google server so that your emergent post to the list can be immediately accepted, etc. of course if the wolf now does watches the sheep and the lists move to @google - the @google problem goes away anyway but there will arise other problems.
Thanks, Evan, for your thoughtful answers. Whatever system we end up using must have public, web-accessible archives, as anything locked behind a user login is not a useful resource.
+1 Andre
participants (2)
-
ac -
Stewart C. Russell