Hi All,
Here are my thoughts on a site move:
We don't have to keep the Website and Mailing list on the same server, but here are the requirements: - 21GB of storage for everything including the OS - 1 CPU or better - 2GB RAM or better
We're looking into containerizing the site and building it with a Static Site Generator, which would make hosting it easier.
The mail server needs to have: - A good Reverse DNS - A non-residential IP with a good reputation (to help keep it off black lists) - Postfix (preferred) - Mailman3 - Optional: IPv6 would be cool
For any of these, I think we'd want at least 3 people with access.
So far, I've heard 2 offers to host us. (Please reply with what you could provide) I don't see why we couldn't have multiple people host the website. Our DNS provider (NameCheap) doesn't seem to support Round-Robin DNS, but I'm sure we could come up with something.
I think the Mailing list would have to be in just once place. We could have a rsynced backup, though.
What does everyone think?
On 02/21/2026 4:42 PM CST Chris Bier chris.bier@cymor.com wrote:
This sounds pretty good to me, but I don't like the idea of containers on a VM. One or the other.
I think that traffic management (round robin) is a bit ambitious. We really don't need it for a site with a few dozen users at best. It gives us fallback if a node goes down, but it also increases maintenance and points-of-failure. I have seen distributed/fallback systems fail more often than they work.
If some kind of Linux bomb drops and suddenly end users are overflowing the system we can easily expand.
-- Jonathan
Johnathan,
Might I ask why you might be opposed to containerization on VMs?
From my understanding, while both technologies provide isolation, they’re really solving different problems. VMs give you a hard boundary and a clean unit for patching and lifecycle management, while containers are mainly about packaging the application and its dependencies, so it runs the same everywhere. In my world that split has been useful: the OS team can maintain and secure the underlying VM baseline whatever that might be without breaking the applications, and dev teams can ship what they need without the usual “it works on my machine” friction.
Thanks,
Steve Gilmore
From: Jonathan Hutchins hutchins@tarcanfel.org Sent: Saturday, February 21, 2026 5:22 PM To: KCLUG mailing list kclug@kclug.org Subject: Re: Site requirements and Move
On 02/21/2026 4: 42 PM CST Chris Bier <chris. bier@ cymor. com> wrote: This sounds pretty good to me, but I don't like the idea of containers on a VM. One or the other. I think that traffic management (round robin) is a bit ambitious. We really
On 02/21/2026 4:42 PM CST Chris Bier <chris.bier@cymor.commailto:chris.bier@cymor.com> wrote: This sounds pretty good to me, but I don't like the idea of containers on a VM. One or the other.
I think that traffic management (round robin) is a bit ambitious. We really don't need it for a site with a few dozen users at best. It gives us fallback if a node goes down, but it also increases maintenance and points-of-failure. I have seen distributed/fallback systems fail more often than they work.
If some kind of Linux bomb drops and suddenly end users are overflowing the system we can easily expand.
-- Jonathan
________________________________
CONFIDENTIALITY NOTICE: This email and any attachments are for the sole use of the intended recipient(s) and contain information that may be Garmin confidential and/or Garmin legally privileged. If you have received this email in error, please notify the sender by reply email and delete the message. Any disclosure, copying, distribution or use of this communication (including attachments) by someone other than the intended recipient is prohibited. Thank you.
It's definitely a great combo! We frequently have that situation. I dockerized one of our Terraform Continuous Delivery systems, and it freed us from having to keep in sync with the VM owners and the versions of Terraform they were using.
On Tue, Feb 24, 2026, at 10:05, Gilmore, Steve wrote:
Johnathan,
Might I ask why you might be opposed to containerization on VMs?
From my understanding, while both technologies provide isolation, they’re really solving different problems. VMs give you a hard boundary and a clean unit for patching and lifecycle management, while containers are mainly about packaging the application and its dependencies, so it runs the same everywhere. In my world that split has been useful: the OS team can maintain and secure the underlying VM baseline whatever that might be without breaking the applications, and dev teams can ship what they need without the usual “it works on my machine” friction.
Thanks,
Steve Gilmore
*From:* Jonathan Hutchins hutchins@tarcanfel.org *Sent:* Saturday, February 21, 2026 5:22 PM *To:* KCLUG mailing list kclug@kclug.org *Subject:* Re: Site requirements and Move
On 02/21/2026 4: 42 PM CST Chris Bier <chris. bier@ cymor. com> wrote: This sounds pretty good to me, but I don't like the idea of containers on a VM. One or the other. I think that traffic management (round robin) is a bit ambitious. We really
On 02/21/2026 4:42 PM CST Chris Bier chris.bier@cymor.com wrote:
This sounds pretty good to me, but I don't like the idea of containers on a VM. One or the other.
I think that traffic management (round robin) is a bit ambitious. We really don't need it for a site with a few dozen users at best. It gives us fallback if a node goes down, but it also increases maintenance and points-of-failure. I have seen distributed/fallback systems fail more often than they work.
If some kind of Linux bomb drops and suddenly end users are overflowing the system we can easily expand.
-- Jonathan
CONFIDENTIALITY NOTICE: This email and any attachments are for the sole use of the intended recipient(s) and contain information that may be Garmin confidential and/or Garmin legally privileged. If you have received this email in error, please notify the sender by reply email and delete the message. Any disclosure, copying, distribution or use of this communication (including attachments) by someone other than the intended recipient is prohibited. Thank you. _______________________________________________ KCLUG mailing list -- kclug@kclug.org To unsubscribe send an email to kclug-leave@kclug.org https://kclug.org/mailman3/postorius/lists/kclug.kclug.org/
(I did not receive the original message with your question. JRH)
Might I ask why you might be opposed to containerization on VMs?
There are a number of reasons, none of which is a show stopper, and I don't want to hash out the whole discussion at the disk right now. My primary argument is simplicity. I think containers are a great feature in a development environment, where the developer has complete control of the platform, and has the ability to re-spin the machine if something breaks. For a production system where constancy and reliability are higher priority than agility I think it's another layer of performance, an additional attack target, and an additional point of failure.
As a sysadmin, I am NOT popular with developers.
Both containers and VMs have a number of overlapping features, and no matter how tiny, anything that consumes resources and duplicates efforts can be a hit at scale. (See my other posts for the argument that scale is hardly a factor for this project.)
I'm not mortally opposed to it. It doesn't match my goals for a production system of building the absolute minimum system that will support the code, with NO other features that do not serve that purpose. Any versatility, agility, and ease of modification belongs on the dev and test systems. Among other "rules" is that there should never be a compiler on an exposed production server.
I really don't want to argue it out on this project, if the guys doing the work don't agree it won't hurt my feelings if they go ahead and follow their own standards.
On 02/21/2026 4: 42 PM CST Chris Bier <chris. bier@ cymor. com> wrote: This sounds pretty good to me, but I don't like the idea of containers on a VM. One or the other. I think that traffic management (round robin) is a bit ambitious. We really
On 02/21/2026 4:42 PM CST Chris Bier <chris.bier@cymor.com mailto:chris.bier@cymor.com> wrote:
This sounds pretty good to me, but I don't like the idea of containers on a VM. One or the other.
I think that traffic management (round robin) is a bit ambitious. We really don't need it for a site with a few dozen users at best. It gives us fallback if a node goes down, but it also increases maintenance and points-of-failure. I have seen distributed/fallback systems fail more often than they work.
If some kind of Linux bomb drops and suddenly end users are overflowing the system we can easily expand.
--
Jonathan
CONFIDENTIALITY NOTICE: This email and any attachments are for the sole use of the intended recipient(s) and contain information that may be Garmin confidential and/or Garmin legally privileged. If you have received this email in error, please notify the sender by reply email and delete the message. Any disclosure, copying, distribution or use of this communication (including attachments) by someone other than the intended recipient is prohibited. Thank you. _______________________________________________ KCLUG mailing list -- kclug@kclug.org mailto:kclug@kclug.org To unsubscribe send an email to kclug-leave@kclug.org mailto:kclug-leave@kclug.org https://kclug.org/mailman3/postorius/lists/kclug.kclug.org/
KCLUG mailing list -- kclug@kclug.org To unsubscribe send an email to kclug-leave@kclug.org https://kclug.org/mailman3/postorius/lists/kclug.kclug.org/
-- Jonathan
-
Chris Bier -
Gilmore, Steve -
Jonathan Hutchins