Johnathan, Thanks for the reply. I appreciate where you're coming from on keeping prod as simple and stable as possible, I wasn't trying to kick off a debate. I asked because I genuinely wanted to understand your perspective. I'm with you on "no compilers on exposed prod boxes." Where containers have worked well for us is leaning on them in the build pipeline, then keeping the production image as minimal as we can: just the app (often just a binary) and whatever it needs to execute. Sometimes that's even FROM scratch, or something tiny like Alpine, rather than starting from a full Ubuntu base and carrying around things we don't need. That said, you're right that containers are another layer to operate, and it's worth treating that as real complexity. In this case, it looks like Chris already has a working example in the repo I cloned it yesterday to build one myself and found it there. One thing that stood out is the base image/deps. For reference: https://hub.docker.com/layers/library/php/8.2-apache/images/sha256-89ad17cca... It looks like some dependencies are outdated/vulnerable, so my inclination is to bump to the latest viable base and see what breaks, then work forward from there. Thanks, Steve Gilmore
________________________________
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.
I have a PR I'm working on to bump it up to version "8-apache". The container isn't in production.
On Wed, Feb 25, 2026, at 08:58, Gilmore, Steve wrote:
Johnathan, Thanks for the reply. I appreciate where you’re coming from on keeping prod as simple and stable as possible, I wasn’t trying to kick off a debate. I asked because I genuinely wanted to understand your perspective. I’m with you on “no compilers on exposed prod boxes.” Where containers have worked well for us is leaning on them in the build pipeline, then keeping the production image as minimal as we can: just the app (often just a binary) and whatever it needs to execute. Sometimes that’s even FROM scratch, or something tiny like Alpine, rather than starting from a full Ubuntu base and carrying around things we don’t need. That said, you’re right that containers are another layer to operate, and it’s worth treating that as real complexity. In this case, it looks like Chris already has a working example in the repo I cloned it yesterday to build one myself and found it there. One thing that stood out is the base image/deps. For reference: https://hub.docker.com/layers/library/php/8.2-apache/images/sha256-89ad17cca... It looks like some dependencies are outdated/vulnerable, so my inclination is to bump to the latest viable base and see what breaks, then work forward from there. Thanks, Steve Gilmore
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/
It would seem I ran over you a little on this one. I didn’t initially pick up on topic/Linting/ImageUpdate01https://codeberg.org/KCLUG/website/src/branch/topic/Linting/ImageUpdate01 was updating to the latest version of php and also moving to Trixie. You could likely merge feature/php-apache-updatehttps://codeberg.org/KCLUG/website/src/branch/feature/php-apache-update into your this branch and then when we’re ready open a PR to merge everything into main.
I was able to use a variety of linting tools to migrate the code base from 8.2 to 8.5. I think it’s likely in fairly good shape and the site seems to function without issue but someone who knows php well should take a look at it.
Thanks,
Steve Gilmore
From: Chris Bier chris.bier@cymor.com Sent: Wednesday, February 25, 2026 8:23 PM To: KCLUG kclug@kclug.org Subject: Re: Site requirements and Move
I have a PR I'm working on to bump it up to version "8-apache". The container isn't in production. On Wed, Feb 25, 2026, at 08: 58, Gilmore, Steve wrote: Johnathan, Thanks for the reply. I appreciate where you’re coming from on keeping prod as
I have a PR I'm working on to bump it up to version "8-apache". The container isn't in production.
On Wed, Feb 25, 2026, at 08:58, Gilmore, Steve wrote:
Johnathan,
Thanks for the reply. I appreciate where you’re coming from on keeping prod as simple and stable as possible, I wasn’t trying to kick off a debate. I asked because I genuinely wanted to understand your perspective.
I’m with you on “no compilers on exposed prod boxes.” Where containers have worked well for us is leaning on them in the build pipeline, then keeping the production image as minimal as we can: just the app (often just a binary) and whatever it needs to execute. Sometimes that’s even FROM scratch, or something tiny like Alpine, rather than starting from a full Ubuntu base and carrying around things we don’t need.
That said, you’re right that containers are another layer to operate, and it’s worth treating that as real complexity.
In this case, it looks like Chris already has a working example in the repo I cloned it yesterday to build one myself and found it there. One thing that stood out is the base image/deps.
For reference: https://hub.docker.com/layers/library/php/8.2-apache/images/sha256-89ad17cca...https://urldefense.com/v3/__https:/hub.docker.com/layers/library/php/8.2-apache/images/sha256-89ad17cca246e8a6ce742b5b89ce65b34ce6223204a282e45f72b4f758ff6401__;!!EJc4YC3iFmQ!W1sJAeICF-feQ3358ZsicUUKHp-ZjiL8DRtv10karXSGv-ULz6fRtJiHrcxmVg87uWibGd8Bf-kqaJJKhDygEg$
It looks like some dependencies are outdated/vulnerable, so my inclination is to bump to the latest viable base and see what breaks, then work forward from there.
Thanks, Steve Gilmore
________________________________
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.orgmailto:kclug@kclug.org To unsubscribe send an email to kclug-leave@kclug.orgmailto:kclug-leave@kclug.org https://kclug.org/mailman3/postorius/lists/kclug.kclug.org/https://urldefense.com/v3/__https:/kclug.org/mailman3/postorius/lists/kclug.kclug.org/__;!!EJc4YC3iFmQ!W1sJAeICF-feQ3358ZsicUUKHp-ZjiL8DRtv10karXSGv-ULz6fRtJiHrcxmVg87uWibGd8Bf-kqaJK--3S8sQ$
________________________________
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.
Thanks Steve! I appreciate your additions!
On Thu, Feb 26, 2026, at 09:28, Gilmore, Steve via KCLUG wrote:
It would seem I ran over you a little on this one. I didn’t initially pick up on topic/Linting/ImageUpdate01 https://codeberg.org/KCLUG/website/src/branch/topic/Linting/ImageUpdate01 was updating to the latest version of php and also moving to Trixie. You could likely merge feature/php-apache-update https://codeberg.org/KCLUG/website/src/branch/feature/php-apache-update into your this branch and then when we’re ready open a PR to merge everything into main.
I was able to use a variety of linting tools to migrate the code base from 8.2 to 8.5. I think it’s likely in fairly good shape and the site seems to function without issue but someone who knows php well should take a look at it.
Thanks,
Steve Gilmore
*From:* Chris Bier chris.bier@cymor.com *Sent:* Wednesday, February 25, 2026 8:23 PM *To:* KCLUG kclug@kclug.org *Subject:* Re: Site requirements and Move
I have a PR I'm working on to bump it up to version "8-apache". The container isn't in production. On Wed, Feb 25, 2026, at 08: 58, Gilmore, Steve wrote: Johnathan, Thanks for the reply. I appreciate where you’re coming from on keeping prod as
I have a PR I'm working on to bump it up to version "8-apache". The container isn't in production.
On Wed, Feb 25, 2026, at 08:58, Gilmore, Steve wrote:
Johnathan,
Thanks for the reply. I appreciate where you’re coming from on keeping prod as simple and stable as possible, I wasn’t trying to kick off a debate. I asked because I genuinely wanted to understand your perspective.
I’m with you on “no compilers on exposed prod boxes.” Where containers have worked well for us is leaning on them in the build pipeline, then keeping the production image as minimal as we can: just the app (often just a binary) and whatever it needs to execute. Sometimes that’s even FROM scratch, or something tiny like Alpine, rather than starting from a full Ubuntu base and carrying around things we don’t need.
That said, you’re right that containers are another layer to operate, and it’s worth treating that as real complexity.
In this case, it looks like Chris already has a working example in the repo I cloned it yesterday to build one myself and found it there. One thing that stood out is the base image/deps.
For reference: https://hub.docker.com/layers/library/php/8.2-apache/images/sha256-89ad17cca... https://urldefense.com/v3/__https:/hub.docker.com/layers/library/php/8.2-apache/images/sha256-89ad17cca246e8a6ce742b5b89ce65b34ce6223204a282e45f72b4f758ff6401__;!!EJc4YC3iFmQ!W1sJAeICF-feQ3358ZsicUUKHp-ZjiL8DRtv10karXSGv-ULz6fRtJiHrcxmVg87uWibGd8Bf-kqaJJKhDygEg$
It looks like some dependencies are outdated/vulnerable, so my inclination is to bump to the latest viable base and see what breaks, then work forward from there.
Thanks, Steve Gilmore
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/ https://urldefense.com/v3/__https:/kclug.org/mailman3/postorius/lists/kclug.kclug.org/__;!!EJc4YC3iFmQ!W1sJAeICF-feQ3358ZsicUUKHp-ZjiL8DRtv10karXSGv-ULz6fRtJiHrcxmVg87uWibGd8Bf-kqaJK--3S8sQ$
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 will be happy to throw $200 towards whatever VM & site & host & etc to however you'd like to use that. I can give cash to someone in the KC area, send a check (yes, I am old enough that I still have checks), or we can figure out credit card usage or whatever works. I'll consider it my "annual dues". haha
Feel free to message me directly: kclug.org@forge.name and i can provide my phone number to text/discuss.
--Jeff G
On 2026-02-26 13:10, Chris Bier wrote:
Thanks Steve! I appreciate your additions!
On Thu, Feb 26, 2026, at 09:28, Gilmore, Steve via KCLUG wrote:
It would seem I ran over you a little on this one. I didn’t initially pick up on topic/Linting/ImageUpdate01 [3] was updating to the latest version of php and also moving to Trixie. You could likely merge feature/php-apache-update [4] into your this branch and then when we’re ready open a PR to merge everything into main.
I was able to use a variety of linting tools to migrate the code base from 8.2 to 8.5. I think it’s likely in fairly good shape and the site seems to function without issue but someone who knows php well should take a look at it.
Thanks,
Steve Gilmore
From: Chris Bier chris.bier@cymor.com Sent: Wednesday, February 25, 2026 8:23 PM To: KCLUG kclug@kclug.org Subject: Re: Site requirements and Move
I have a PR I'm working on to bump it up to version "8-apache". The container isn't in production. On Wed, Feb 25, 2026, at 08: 58, Gilmore, Steve wrote: Johnathan, Thanks for the reply. I appreciate where you’re coming from on keeping prod as
I have a PR I'm working on to bump it up to version "8-apache". The container isn't in production.
On Wed, Feb 25, 2026, at 08:58, Gilmore, Steve wrote:
Johnathan,
Thanks for the reply. I appreciate where you’re coming from on keeping prod as simple and stable as possible, I wasn’t trying to kick off a debate. I asked because I genuinely wanted to understand your perspective.
I’m with you on “no compilers on exposed prod boxes.” Where containers have worked well for us is leaning on them in the build pipeline, then keeping the production image as minimal as we can: just the app (often just a binary) and whatever it needs to execute. Sometimes that’s even FROM scratch, or something tiny like Alpine, rather than starting from a full Ubuntu base and carrying around things we don’t need.
That said, you’re right that containers are another layer to operate, and it’s worth treating that as real complexity.
In this case, it looks like Chris already has a working example in the repo I cloned it yesterday to build one myself and found it there. One thing that stood out is the base image/deps.
For reference:
https://hub.docker.com/layers/library/php/8.2-apache/images/sha256-89ad17cca...
[1]
It looks like some dependencies are outdated/vulnerable, so my inclination is to bump to the latest viable base and see what breaks, then work forward from there.
Thanks, Steve Gilmore
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/ [2]
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/
Links:
[1] https://urldefense.com/v3/__https:/hub.docker.com/layers/library/php/8.2-apa... [2] https://urldefense.com/v3/__https:/kclug.org/mailman3/postorius/lists/kclug.... [3] https://codeberg.org/KCLUG/website/src/branch/topic/Linting/ImageUpdate01 [4] https://codeberg.org/KCLUG/website/src/branch/feature/php-apache-update _______________________________________________ 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/
On 03/07/2026 9:15 AM CST Jeff G kclug.org@forge.name wrote:
I will be happy to throw $200 towards whatever VM & site & host & etc to however you'd like to use that.
Thanks Steve, that's very generous.
KCLUG does not have an organizational structure; we do not have a treasurer or any means to accept or hold donations except in-kind (services or hardware). For now, any KCLUG member has the same authority as any other, so it's best if you just earmark the money and hang on to it for the rest of us.
-- Jonathan
-
Chris Bier -
Gilmore, Steve -
Jeff G -
Jonathan Hutchins