Enable use of repository for local WordPress development

Add orchestration for docker or virtual machine WordPress development pod to maximize parity between production, staging, and development environments.

Known Hurdles

• SaltStack errors on git-crypt locked pillar files

Description

misc_prod_us-east-2 EC2 instance and volumes tags include:

Also see AWS Guidelines page on the CC Internal Wiki.

Additional context

• #4
• #5
• #110

Problem Description

Chapters need a way to import WordPress data

Solution Description

Add WordPress Importer – WordPress plugin | WordPress.org

Deploy initial dev/staging environment for creativecommons/cc-licenses develop branch:

• Set up a web host EC2 instance
• Set up a small PostgreSQL 10+ RDS instance
  • Use Security Group to limit connections to only those that originate from web host
• Configure DNS (cclicdev.creativecommons.org)
• Configure web host with Let's Encrypt and NGINX
  • use HTTP Basic Auth to prevent anonymous use
• Configure web host with Gunicorn and Django using Caktus' provisioning instructions
• Allow emails to caktusgroup.com
  • (normally staging servers only allow emails to creativecommons.org and discard email to any other domain)
• Verify basic functionality: https://cclicdev.creativecommons.org/
• Configure Caktus access and permissions on web host
  • add Caktus users as admins
    • include Caktus SSH keys
  • strip passwords from all admin users (!)
  • support direct connections to SSH (instead of requiring a bastion/jump-host)
  • sudo NOPASSWD
• Distribute connection information to Caktus

This is meant to give Caktus a venue for sharing their progress with us and performing usability testing; configuration automation can be dealt with later.

Description

Update OS of licbuttons__prod__us-east-2 to Debian 11 Bullseye by upgrade

This process involves less downtime than the replacement method (ex. #115). It also maintains configuration data (ex. Let's Encrypt certificates) that can cause order of operation issues. However it requires more manual action and unidentified cruft/detritus may cause future issues.

Process

All shell commands should be run on the host (licbuttons__prod__us-east-2), unless otherwise stated:

1. Verify operating system

   lsb_release -a

2. Pause uptime monitoring
3. Disable and update SaltStack apt source

   sudo sed -e's|^|#|' -e's|/debian/10/|/debian/11/|' -e's|buster|bullseye|' -i /etc/apt/sources.list.d/saltstack.list

4. Remove SaltStack packages

   sudo DEBIAN_FRONTEND=noninteractive apt-get remove salt-common salt-minion -yq

5. Remove Debian packages that were automatically installed and are no longer required

   sudo DEBIAN_FRONTEND=noninteractive apt autoremove -yq

6. Ensure existing OS (Debian 10 Buster) is up-to-date
   1. Update Apt/Dpkg (and only show errors):

      sudo apt-get update >/dev/null

   2. Download Debian package updates and review changes:

      sudo apt-get dist-upgrade -yqd | sed -e"/Get:[0-9]/d"

   3. Install Debian package updates:

      sudo DEBIAN_FRONTEND=noninteractive apt-get dist-upgrade -yq

   4. Determine if a reboot is required:

      test -f /run/reboot-required && echo REBOOT REQUIRED

   5. (optionally, if a reboot is required) reboot immediately:

      sudo reboot

   6. (optionally) Clean-up Debian packages:

      sudo DEBIAN_FRONTEND=noninteractive apt-get autoremove -yq

      sudo DEBIAN_FRONTEND=noninteractive apt-get autoclean -yq

7. Clean up leftover configuration files

   sudo find /etc \( -name '*.dpkg-*' -o -name '*.ucf-*' -o -name '*.merge-error' \) -exec rm -v {} +

8. Check Debian package status

   sudo dpkg --audit

9. Reconfigure APT source-list file

   sudo sed -e's|buster|bullseye|g' -e's|debian-security bullseye/updates|debian-security bullseye-security|' -i /etc/apt/sources.list

10. Upgrade OS
    1. Update Apt/Dpkg (and only show errors):

       sudo apt-get update >/dev/null

    2. Perform full-upgrade:

       sudo apt-get full-upgrade

       • Postfix Configuration: No Configuration (leave the current configuration unchanged)
       • Configuring libc6:amd64: Restart services during package upgrades without asking: Yes
       • Configuration file /etc/nginx/nginx.conf: N (keep your currently-installed version)
       • Modified configuration file /usr/share/chrony/chrony.conf: keep the local version currently installed
       • Configuring openssh-server /etc/ssh/sshd_config: keep the local version currently installed
    3. Reboot immediately:

       sudo reboot

11. Verify operating system

    lsb_release -a

12. Enable SaltStack apt source and reinstall minion

    sudo sed -e's|^#||' -i /etc/apt/sources.list.d/saltstack.list

    sudo apt-get update >/dev/null

    sudo DEBIAN_FRONTEND=noninteractive apt-get install -yq salt-minion

13. On salt-prime: Verify minion is connected to master

    sudo salt licbuttons\* test.ping

14. Clean-up Debian packages
    1. Purge removed packages

       sudo DEBIAN_FRONTEND=noninteractive apt-get purge -q $(dpkg -l | awk '/^rc/ { print $2 }')

    2. Clean-up Debian packages:

       sudo DEBIAN_FRONTEND=noninteractive apt-get autoremove -yq

       sudo DEBIAN_FRONTEND=noninteractive apt-get autoclean -yq

15. Remove old certbot virtual environment

    sudo rm -rf /opt/certbot_virtualenv/

16. On salt-prime: Run highstate for minion

    sudo salt licbuttons\* state.highstate saltenv=${USER} test=True

    sudo salt licbuttons\* state.highstate saltenv=${USER}

17. Verify services
    • https://licensebuttons.net/
18. Unpause uptime monitoring

Additional context

• Chapter 4. Upgrades from Debian 10 (buster)

Description

Index Apache2 config (states/apache2/files/index.conf) CC Legal Tools section is missing the language-redirects include:

language-redirects include: creativecommons/cc-legal-tools-data: config/language-redirects

Reproduction

Go to a legacy URL (ex. https://creativecommons.org/licenses/by/4.0/legalcode.zh)

Expectation

For example, /licenses/by/4.0/legalcode.zh should redirect to /licenses/by/4.0/legalcode.zh-hans.

Resolution

• I would be interested in resolving this bug.

Describe the bug

The states/pillars assume specific NVMe block devices instead of querying AWS. I thought this would be a rare, but I was wrong.

To Reproduce

Create an instance, guess at NVMe block device in pillar configuration.

Expected behavior

Only minimal manual configuration should be necessary.

Additional context

• AWS Documentation
  • Amazon EBS and NVMe on Linux Instances - Amazon Elastic Compute Cloud
• Related PRs:
  • Add label to filesystem and use it for mount by TimidRobot · Pull Request #27
  • creativecommons.org v2019 dispatch and ccengine by TimidRobot · Pull Request #20

Overview

The work in Implement AWS tags for all resources · Issue #4. It did not include EBS volumes.

Automation should be doable--SaltStack should have all of the information needed to automate the tagging of EBS volumes.

Resources:

• Two solutions for tagging elusive AWS EBS volumes

Problem

[#78119] Machine readable licenses are not machine readable : Creative Commons Freshdesk ticket contains:

From JavaScript, I cannot execute an XMLHttpRequest for either the HTML URL (needed to find HTTP link element) or the RDF URL. The request is denied as a cross-origin request.

I don't know, but to make the license available to machines that want to check the license details, then both the license HTML and the RDF should be served with the HTTP response header:

Access-Control-Allow-Origin: *

Cross-origin resource sharing - Wikipedia:

A wildcard same-origin policy is appropriate when a page or API response is considered completely public content and it is intended to be accessible to everyone, including any code on any site.

Description

1. Enable headers apache2 module
2. Set header in states/apache2/files/index.conf:

   index 9088170..d2871c3 100644
   --- states/apache2/files/index.conf
   +++ states/apache2/files/index.conf
   @@ -30,28 +30,30 @@
        <Directory /var/www/git/cc-legal-tools-data/docs>
            # Disable .htaccess (for security and performance)
            AllowOverride None
            # Also serve HTML files without .html extension
            RewriteCond %{REQUEST_FILENAME}.html -f
            RewriteRule !.*\.html$ %{REQUEST_FILENAME}.html [L]
            # Redirect .../index.php to .../
            RewriteCond %{REQUEST_FILENAME} "index\.php$" [NC]
            RewriteCond %{REQUEST_FILENAME} !-f
            RewriteRule (.*/)index\.php$ $1 [L,NC,R=301]
            # Deny access to PHP files (content should be only static files)
            RewriteRule .*\.php$ "-" [F,L]
            # Correct mimetype for .../rdf files
            RewriteRule (.*/rdf$) $1 [T=application/rdf+xml]
   +        # Enable CORS (cross-origin resource sharing)
   +        Header set Access-Control-Allow-Origin "*"
        </Directory>
        Include /var/www/git/cc-legal-tools-data/config/language-redirects
        RedirectPermanent  /licenses/mark/1.0  /publicdomain/mark/1.0
        RedirectPermanent  /licences           /licenses
    
        ###########################################################################
        # Chooser
    #    Alias /choose /var/www/git/chooser/docs
    #    <Directory /var/www/git/chooser/docs>
    #        # Disable .htaccess (for security and performance)
    #        AllowOverride None
    #        # Redirect .../index.php to .../
    #        RewriteCond %{REQUEST_FILENAME} "index\.php$" [NC]
    #        RewriteCond %{REQUEST_FILENAME} !-f

Alternatives

🤷🏻

Additional context

• Cross-origin resource sharing - Wikipedia
• Cross-Origin Resource Sharing (CORS) - HTTP | MDN
  • Access-Control-Allow-Origin - HTTP | MDN
• mod_headers - Apache HTTP Server Version 2.4

Implementation

• I would be interested in implementing this feature.

Bug

Description

Currently, all servers within the salt-prime infrastructure are configured to utilize port 587 for the postfix service. Going forward, it is imperative to address this configuration by transitioning to the utilization of port 465.

Expectation

• Email transport should be encrypted

Problem Description

A new version of SaltStack was released.

Solution Description

Update SaltStack to 3000.3+ds-1 (or current/latest):

• update states/salt/init.sls to use latest instead of 2019.2
• update pillars/salt/init.sls
• update and verify all hosts
• update README.md

Additional context

• Salt 3000 Release Notes - Codename Neon
  • Salt 3000.1 Release Notes
  • Salt 3000.2 Release Notes
  • Salt 3000.3 Release Notes
• https://repo.saltstack.com/py3/debian/10/amd64/latest/
• https://repo.saltstack.com/apt/debian/9/amd64/latest

Add support for multiple instances in a role

The current Hosts Classification scheme assumes a single instance for each role.

Consider:

• Expanding host classification to included INC (increment)
• Assuming all multiple instances in a role will be part of an Amazon EC2 Auto Scaling group using AMIs without a Salt Minion

Description

Remove deprecated/unused hosts and any configurations that are no longer needed:

• discourse__dev__us-east-2
  • averages $19.31/month per AWS Cost Management: Cost Explorer

Rationale

• Absence of activity since 2019
• Maintenance costs
• 2022-06-02: Removal approved by @cameralibre via email

Description

• Delete creativecommons.ru configuration from /pillars/5_HST__POD/redirects__core.sls pillars file
  • related to Unable to renew creativecommons.ru (private repo)
  • #223

Problem Description

Update NGINX configuration for the dispatch host to support long term logging. The goal of the log format is to allow simple log term log analysis without compromising users privacy or increasing Creative Commons liability. The log format should:

1. ISO date format
2. Anonymized real client IP (not CDN IP)
3. Truncate or exclude User Agent

The solution should include:

1. NGINX log configuration
2. logrotate configuration
3. EBS mount configuration

Additional context

• NGINX Docs | Configuring Logging
• Anonymize IP logging in nginx? - Stack Overflow

Host Classification needs improvement

Overview

This builds on Host Classification - README.md.

Like Apache2, SaltStack pillar data uses a last declared wins model. This repo uses (from least specific to most specific):

1. LOC: location
2. POD: pod (a synonym of group that is helpfully three characters long)
3. HST: host

The current systems is ok. I like that it driven by the salt primary. I think it could be better articulated so that pillars fully use increasing specificity.

It should be easy, for instance to configure a production cluster and a staging cluster by using different values for POD.

I think the first step will be to decouple networking from POD so that each POD can declare which network it uses.

I also suspect that the way I've done lookups in states/orch/aws/jinja2.sls is too inflexible/fragile.

Actionables

• Create helper script to easily illustrate what files are loaded for a given minion id or HST/POD/LOC combination.
• Use addition of WordPress staging environment as an engine to drive refactoring/improvements
• Maybe also add 2nd bastion as an engine to drive refactoring/improvements

Description

During active development, the staging host will be active (with Django app). Once production is deployed, I expect we'll remove Django and PostgreSQL.

• Document anticipated costs
  • https://github.com/creativecommons/tech-support/issues/764 (private repo)
• Create CC Licenses and New Chooser staging host (ex. licenses__stage__us-east-2)
  • backend of dispatch__stage__us-east-2
  • creativecommons/cc-licenses
  • creativecommons/cc-licenses-data
  • creativecommons/chooser
  • creativecommons/primary-site-includes
  • RDS for PostgeSQL
• Copy missing static resources to creativecommons/cc-licenses-data
  • Moved to issue: Add legacy data: legalcode, plaintext, RDF · Issue #11 · creativecommons/cc-licenses-data

Additional context

• Development host is cclicdev__stage__us-east-2
  • (which is not a backend of a URL dispatch host)
  • Deploy dev/staging environment for cc-licenses · Issue #92
    • Deploy initial dev/staging environment for creativecommons/cc-licenses develop branch by TimidRobot · Pull Request #98
  • Update cclicdev host config to include changes made during CC Licenses development · Issue #121
    • cclicdev host configuration update by TimidRobot · Pull Request #131

Description

Remove summit__prod__us-east-2 and related resources (these do not include production services)

Removal Rationale

• Resources were created in preparation for WordPress development that never happened
• Future development will happen on Pantheon's managed WordPress hosting.
• Vendor cost savings (averages $93.85USD/month per AWS Cost Management: Cost Explorer)
• Maintenance cost savings

Problem

We released the version 0.2.0 of wp-plugin-creativecommons-website.

Description

Since composer.json is included in the new release, we can update the ccorg-compser.json to include the new version.

Description

Update OS of openglam__prod__us-east-2 to Debian 11 Bullseye by replacement (data preserved in EBS volume)

This process is simpler than the upgrade method (ex. #186). However it may cause order of operation issues (ex. due to missing Let's Encrypt certificates).

Process

All shell commands should be run on the host (openglam__prod__us-east-2), unless otherwise stated:

1. Ensure AMI is latest
   • ex. #183
2. Verify operating system

   lsb_release -a

3. rename EC2 instance so that name ends in _TERMINATED
4. terminate EC2 instance
5. On salt-prime: run SaltStack orchestration for host (recreates EC2 instance)
   • sre-salt-prime/Orchestration.md at main · creativecommons/sre-salt-prime

     sudo salt-run state.orchestrate orch.wordpress_pod pillar='{"tgt_hst":"openglam", "tgt_pod":"prod", "tgt_loc":"us-east-2"}' saltenv=${USER}
     

6. On salt-prime: run SaltStack highstate for host (configures EC2 instance)
   1. Run highstate as a test to preview changes:

      sudo salt openglam\* state.highstate saltenv=${USER} test=True

   2. Run highstate:

      sudo salt openglam\* state.highstate saltenv=${USER}

7. Perform OS updates and reboot host
   1. Update Apt/Dpkg (and only show errors):

      sudo apt-get update >/dev/null

   2. Download updates and review changes:

      sudo apt-get dist-upgrade -yqd | sed -e"/Get:[0-9]/d"

   3. Install updates:

      sudo DEBIAN_FRONTEND=noninteractive apt-get dist-upgrade -yq

   4. Determine if a reboot is required:

      test -f /run/reboot-required && echo REBOOT REQUIRED

   5. (optionally, if a reboot is required) reboot immediately:

      sudo reboot

   6. (optionally) Clean-up packages:

      sudo apt-get autoremove -y && sudo apt-get autoclean

8. Verify operating system

   lsb_release -a

9. Verify services

Description

Update cclicdev host configuration to include changes made during CC Licenses development

Also update project for compatability: Update .gitignore by TimidRobot · Pull Request #84 · creativecommons/cc-licenses

Additional context

CC Licenses repositories:

• creativecommons/cc-licenses
• creativecommons/cc-licenses-data

Description

Update OS of opencovid__prod__us-east-2 to Debian 11 Bullseye by upgrade.

Process

1. Modify process outlined in #186
   • On salt-prime: Run highstate for minion

     sudo salt opencovid\* state.highstate saltenv=${USER} test=True

     sudo salt opencovid\* state.highstate saltenv=${USER}

   • Verify services
     • https://opencovidpledge.org/

Additional context

• Chapter 4. Upgrades from Debian 10 (buster)

Problem Description

The existing ccstatic.org host has the following issues:

• hosting provider support for infrastructure as code is inadquate
• OS is not current
• less than optimal security settings
• less than optimal web hosting (Apache2 does too much slowing work by default)
• log configuration does not support long term retention
  • (long term retention must have strong privacy protections)

Solution Description

Configure and deploy new ccstatic.org host that resolves the issues listed above.

Description

Remove duplicate files from the repository to ensure alignment with organizational defaults as outlined in GitHub Repo Guidelines.

Related to:

• creativecommons/.github#38

Resolution

• I would be interested in resolving this bug.

Expected Behavior

Sending an Accept header with the desired content-type (e.g., RDF) should result in CC returning the RDF for a license, rather than the HTML:

curl -iL -H 'Accept: application/rdf+xml' https://creativecommons.org/licenses/by-nc/4.0/

Actual Behavior

The server ignores the Accept header and returns HTML.

This is a separate issue from creativecommons/creativecommons.org#542; in that case it was a separate URL that was down.

@robmyers @little-wow

Description

Replace stage.creativecommons.org with new hosting model based on creativecommons/project_creativecommons.org

Improved Data Path

The new hosting model greatly simplifies the hosting environment and data path compared to the current legacy site. It features a roughly 85% decrease in complexity (from 7 dedicated services to 1 dedicated service).

Proposed Data Path

1. Site host Apache2
   • CC Legal Tools content
   • Chooser content
   • Misc content (may be removed and included in WordPress instead)
   • WordPress content (default data path)

Legacy Data Path

1. Dispatch host NGINX
2. ccEngine host Apache2 (ccEngine content)
3. Misc host NGINX (Misc content)
4. Loadbalancer host HAProxy (WordPress/default content)
5. WordPress host Varnish (WordPress/default content)
6. WordPress host Apache2 (WordPress/default content)
7. WordPress host PHP+FPM (WordPress/default content)

Example of issue caused by legacy data path: https://github.com/creativecommons/tech-support/issues/838 (private repo)

Additional context

• Host removal
  • #150

Description

Remove deprecated/unused hosts and any configurations that are no longer needed:

• sotc__prod__us-east-2
  • averages $81.10/month per AWS Cost Management: Cost Explorer

Rationale

• Legacy SotC reports moved to GitHub pages: creativecommons/stateof
• Recent SotC reports have been PDFs (not websites)
• 2022-06-02: Removal approved in #comms channel on Internal Slack

Problem Description

AWS EC2 instances do not report disk or memory usage to CloudWatch

Solution Description

Install CloudWatch Agent

Additional context

• Monitoring Memory and Disk Metrics for Amazon EC2 Linux Instances - Amazon Elastic Compute Cloud
• Collecting Metrics and Logs from Amazon EC2 Instances and On-Premises Servers with the CloudWatch Agent - Amazon CloudWatch

Description

See Amazon SNS > Topics > Personal-Health-Dashboard_to_PagerDuty

Also see AWS Guidelines page on the CC Internal Wiki.

Additional context

• #4
• #5
• #109

Problem Description

When staging WordPress servers import production data, it increases the chance that operational emails (ex. password resets) are sent to end-users from the staging server.

Solution Description

Add Postfix configuration to discard non-Creative-Commons email on staging servers so that they are less likely to cause problems or confusion.

Alternatives

• Anonymize data

Description

Remove deprecated/unused hosts and any configurations that are no longer needed:

• ccorgwp__stagelegacy__us-east-2
• cclicdev__stage__us-east-2
• dispatch__stagelegacy__us-east-2

These hosts are no longer used and have been offline. Fully removing them and their configurations will make future development and management easier.

Additional Context

• cclicdev
  • #123
• Host removal
  • https://github.com/creativecommons/tech-support/issues/762 (private repo)

Problem

Reviewing pull requests (PRs) from forks is more difficult without the

Description

The GitHub CLI (command line interface, gh) makes it easy to review PRs from forked repos

Additional context

• https://github.com/cli/cli?tab=readme-ov-file#linux--bsd

Problem

A new stable major version of Composer is available (2.0.13), run "composer self-update --2" to update to it. See also https://getcomposer.org/2

Description

Need to verify existing WordPress sites work without issue using Composer 2

Additional context

• Should be completed ASAP: Deprecating Packagist.org support for Composer 1.x
• States
  • php_cc.composer in states/php_cc/composer.sls
  • php.composer in saltstack-formulas/php-formula: Formula to set up and configure php

Description

The domain creativecommons.dk and www.creativecommons.dk, currently hosted on puntum.dk, is no longer managed by Creative Commons. To streamline operations and avoid unnecessary alerts, we are removing it from creativecommons/sre-salt-prime repository. If we manage it in the future, we will use our domain provider’s web forwarding

• related to - Let's Encrypt certificate expiration notice for domain "creativecommons.dk" and "www.creativecommons.dk" | PagerDuty Incident(private)
• similar to Unable to renew creativecommons.ru #1030

Future Insights:

Post-approval for the domain transfer, proceed with the transfer following the Gandi domain transfer steps. This will include setting up necessary redirects and configuring pagerduty alerts to reflect the changes.

Recommended Steps:

On redirects__core_us-east-2 server

• Disable Nginx Site Configuration

  sudo rm /etc/nginx/sites-enabled/creativecommons.dk
  sudo rm /etc/nginx/sites-enabled/www.creativecommons.dk

• Remove Nginx Configuration Files

  sudo rm /etc/nginx/sites-available/creativecommons.dk
  sudo rm /etc/nginx/sites-available/www.creativecommons.dk

• Update Let's Encrypt Configuration

  sudo certbot delete --cert-name creativecommons.dk

• Update Domain Sets Configuration

  sudo nano /etc/letsencrypt/domainsets.yaml

• Reload Nginx Configuration

  sudo systemctl reload nginx

On salt-prime server

• Remove the domain entries from pillars/5_HST__POD/redirects__core.sls.
• Execute highstate to apply these changes.
• Verify that the domain has been removed from the domainset.yaml on redirects__core__us-east-2 servers.

Related Links:

• creativecommons/sre-salt-prime
• Gandi.net vendor | Internal Wiki(private)
• Redirects | Internal Wiki(private)
• AWS us-east-2 Hosts | Internal Wiki(private)

Tags are defined on the CC Staff internal wiki here: https://wikijs.creativecommons.org/tech/sre/aws-guidelines

Task

Update repository to support both Debian 9 "stretch" and Debian 10 "buster" to allow for a gradual transition to the new stable Debian release

Debian Buster Released

• 2019-09-09: Debian 10 "buster" AMIs for Amazon EC2 AMI released (Cloud/AmazonEC2Image/Buster - Debian Wiki)
• 2019-09-07: Updated Debian 10: 10.1 released
• 2019-07-06: Debian 10 "buster" released

Debian 10 "buster" includes numerous updated software packages (over 62%
of all packages in the previous release), such as:

• Apache 2.4.38
• BIND DNS Server 9.11
• Chromium 73.0
• Emacs 26.1
• Firefox 60.7 (in the firefox-esr package)
• GIMP 2.10.8
• GNU Compiler Collection 7.4 and 8.3
• GnuPG 2.2
• Golang 1.11
• Inkscape 0.92.4
• LibreOffice 6.1
• Linux 4.19 series
• MariaDB 10.3
• OpenJDK 11
• Perl 5.28
• PHP 7.3
• PostgreSQL 11
• Python 3 3.7.2
• Ruby 2.5.1
• Rustc 1.34
• Samba 4.9
• systemd 241
• Thunderbird 60.7.2
• Vim 8.1
• more than 59,000 other ready-to-use software packages, built from
  nearly 29,000 source packages.

Description

Remove ccorg_stage_us-east-2 and related provisioned services (leave SaltStack configuration--state and pillar information--intact)

(approved by @xolotl and @possumbilities in internal Slack)

Removal Rationale

• Creation of a staging environment was premature
  • additional local development is required before we will be ready for a staging environment: creativecommons/project_creativecommons.org
  • reduce confusion
• Vendor cost savings
• Maintenance cost savings

Problem

Current NGINX static hosting configurations do not take advantage of:

• add header Cache-Control
• sendfile
• tcp_nopush
• tcp_nodelay
• etc.

Description

Optimize static file hosting using documented best practices.

Alternatives

Do nothing 🤷🏻

Additional context

• Serving Static Content | NGINX Plus
• Origin Cache Control · Cloudflare Cache (CDN) docs

Describe the bug

Default Debian Apache2 configuration assumes too many resources.

For example, MaxRequestWorkers defaults to 150, which assumes either very small processes (ex. static files) or larger EC2 instances with more memory.

Expected behavior

SaltStack should manage files and configure resources based on EC2 instance type with a more conservative default.

Additional context

You can, and should, control the MaxRequestWorkers setting so that your server does not spawn so many children that it starts swapping.

(Hardware and Operating System Issues - Apache Performance Tuning - Apache HTTP Server Version 2.4)

Problem Description

The existing licensebuttons.net host has the following issues:

• hosting provider support for infrastructure as code is inadquate
• OS is not current
• less than optimal security settings
• less than optimal web hosting (Apache2 does too much slowing work by default)
• log configuration does not support long term retention
  • (long term retention must have strong privacy protections)

Solution Description

Configure and deploy new licensebuttons.net host that resolves the issues listed above.

Additional context

• Get licensebuttons.net to a maintainable state · Issue #4 · creativecommons/licensebuttons

Problem

Description

Create ccengine__stagelegacy__us-east-2 by renaming/re-repurposing ccengine__stage__us-east-2

Additional context