In certain cloud deployment scenarios, all of the environment is set on the hosting site (e.g. Azure App Service) so that the .env is empty / not needed. The following unfortunately relies on .env existing and being used.

Optimally the correct precedence should be used (i.e. what phpdotenv also uses). Maybe check if environment variable exists and use it if it does, if not check if .env exists and source it, if it does.

Docker's build context in this example should be placed in a sub directory, lets say ./.docker/ to reduce context size for building custom images, unless you want to copy all your files in webroot folder to your build context.

Including too many assets in the build context can become a performance drain.

Affected Docker Images

beta-8.1-fpm-nginx

Current Behavior

When I attempt to bring up my containers, and APP_ENV = production, I receive the following error message:

s6-rc: fatal: timed out
s6-svlisten1: fatal: timed out
/run/s6/basedir/scripts/rc.init: warning: s6-rc failed to properly bring all the services up! Check your logs (in /run/uncaught-logs/current if you have in-container logging) for more information.
prog: fatal: stopping the container.
[04-Oct-2022 14:25:03] NOTICE: Terminating ...
[04-Oct-2022 14:25:03] NOTICE: exiting, bye-bye!

Expected Behavior

The containers should spin up without any errors.

Steps To Reproduce

1. Set APP_ENV=production in a laravel app
2. Bring up containers.

Host Operating System

Mac OS 11.6.8

Docker Version

Client:
 Cloud integration: v1.0.29
 Version:           20.10.17
 API version:       1.41
 Go version:        go1.17.11
 Git commit:        100c701
 Built:             Mon Jun  6 23:04:45 2022
 OS/Arch:           darwin/amd64
 Context:           default
 Experimental:      true

Server: Docker Desktop 4.12.0 (85629)
 Engine:
  Version:          20.10.17
  API version:      1.41 (minimum version 1.12)
  Go version:       go1.17.11
  Git commit:       a89b842
  Built:            Mon Jun  6 23:01:23 2022
  OS/Arch:          linux/amd64
  Experimental:     false
 containerd:
  Version:          1.6.8
  GitCommit:        9cd3357b7fd7218e4aec3eae239db1f68a5a6ec6
 runc:
  Version:          1.1.4
  GitCommit:        v1.1.4-0-g5fd4c4d
 docker-init:
  Version:          0.19.0
  GitCommit:        de40ad0

### Anything else?

This could possibly be related to the Laravel automation script not exiting correctly.

Why this is needed

• We need a method to distribute the images to everyone

Affected Docker Images

• 8.2*

Current Behavior

php8.2-redis had to be removed in order to build the 8.2 images.

More detail

#60 (comment)

Expected Behavior

PHP-Redis should be supported by default in our 8.2 images

Steps To Reproduce

1. Add php8.2-redis to the packages file (https://github.com/serversideup/docker-php/blob/dev/src/cli/php-version-packages/8.2.txt)
2. Attempt to build the image

Host Operating System

Ubuntu 22.04

Docker Version

N/A

Anything else?

No response

Seeing

You may be interested in https://github.com/szepeviktor/debian-server-tools/blob/master/webserver/apache-conf-available/wordpress.inc.conf

I couldn't find info on how fpm containers will read .php files.

Problem

I'm getting Bash warnings after I set the Locale.

bash: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8)

More detail

Current Behavior

Accessing the service over exposed port from host results in 404 file not found error, regardless of files present in the docker containers /var/www/html/ directory.

Expected Behavior

Accessing the service over exposed port from host should serve files present in the docker containers /var/www/html/ directory.

Steps To Reproduce

1. Host environment: Windows 10+ . Testing access without valid SSL certificate.
2. The following compose

version: '3.7'
services:
  php:
    image: serversideup/php:7.4-fpm-nginx
    restart: always
    ports:
      - "8023:80"
      - "8448:443"
    volumes:
      - ./public/:/var/www/html/

3. Run docker compose up --build
4. Place index.php [phpinfo()] in container volume ./public/:/var/www/html/ and access via https://localhost:8448

Expected result = 200 phpinfo() output
Actual result = 404 file not found

Screenshot of 404 response served by container:

Screenshot of file present in the container /var/www/html/ directory

Host Operating System

Windows 10

Docker Version

Client:
 Cloud integration: v1.0.22
 Version:           20.10.12
 API version:       1.41
 Go version:        go1.16.12
 Git commit:        e91ed57
 Built:             Mon Dec 13 11:44:07 2021
 OS/Arch:           windows/amd64
 Context:           default
 Experimental:      true

Server: Docker Desktop 4.5.1 (74721)
 Engine:
  Version:          20.10.12
  API version:      1.41 (minimum version 1.12)
  Go version:       go1.16.12
  Git commit:       459d0df
  Built:            Mon Dec 13 11:43:56 2021
  OS/Arch:          linux/amd64
  Experimental:     false
 containerd:
  Version:          1.4.12
  GitCommit:        7b11cfaabd73bb80907dd23182b9347b4245eb5d
 runc:
  Version:          1.0.2
  GitCommit:        v1.0.2-0-g52b36a2
 docker-init:
  Version:          0.19.0
  GitCommit:        de40ad0

### Anything else?

_No response_

Background

• PHP-FPM + NGINX as a workaround to avoid PHP Apache sucks

Solution

• Using PHP Swoole looks very promising https://developpaper.com/php-fpm-vs-swoole/

An average WordPress installation will see 3× - 10× speedup with OPcache.validate_timestamps = 0 and Redis object cache.

Reasons

1. No disk access on PHP execution
2. (almost) No Database access on PHP execution

Please consider adding Redis as default. (I do that)

Current Behavior

Right now, SSL is automatically generated: https://github.com/serversideup/docker-php/blob/main/templates/fpm-nginx/etc/cont-init.d/10-generate-ssl

Expected Behavior

There should be an option to disable the SSL auto-generation.

Apply to:

• Apache (All PHP Versions)
• NGINX (All PHP Versions)

Steps To Reproduce

1. Pull the container
2. Start the container

Host Operating System

All

Docker Version

All

Anything else?

No response

Background

• We need to determine which packages are absolutely needed

What we have now

Here are the packages that we are currently using:

php7.4-cli
php7.4-common
php7.4-curl
php7.4-fpm
php7.4-gd
php7.4-json
php7.4-mbstring
php7.4-mysql
php7.4-soap
php7.4-sqlite3
php7.4-xml
php7.4-zip

These are very different from what PHPDocker.io are using:

php7.4-apcu
php7.4-apcu-bc
php7.4-cli
php7.4-curl
php7.4-json
php7.4-mbstring
php7.4-opcache
php7.4-readline
php7.4-xml
php7.4-zip

Here's a diff (ours left, theirs right)

Next Steps

• @danpastori do you have any thoughts on what is needed?

Goal

I would like to make these images as small as possible.

Please see https://httpd.apache.org/docs/2.4/howto/access.html

Affected Docker Images

*-fpm-nginx

Current Behavior

When an OPTIONS request is made to a URL NOT ending in .php, a "405 Method Not Allowed" is returned.

Expected Behavior

When making an OPTIONS request, it should return a "200".

Steps To Reproduce

1. Use the cores-issue branch for latest code: https://github.com/jaydrogers/docker-php-test-app/tree/cors-issue
2. Use docker compose up to bring up the containers
3. Test with Insomnia

Request to http://localhost

Result is 405.

Request to http://localhost/index.php

Result is 200.

Host Operating System

N/A

Docker Version

N/A

Anything else?

This issue was originally reported by @zigazajc007 via Discord.

Possible causes

• It could be related to these lines? https://github.com/serversideup/docker-php/blob/main/src/fpm-nginx/etc/nginx/site-opts.d/http.conf#L29:L38

Possible solutions

• http://invalidlogic.com/2011/04/12/serving-static-content-via-post-from-nginx/
• https://stackoverflow.com/questions/24415376/post-request-not-allowed-405-not-allowed-nginx-even-with-headers-included

Hesitations on solutions

It seems these might be quite "hacky". Would love to open this up to the community for further discussion on a stable solution.

• scheduled jobs (cron)
• queues

Problem

• The https://github.com/serversideup/docker-php/blob/dev/php/7.4/fpm/etc/cont-init.d/50-laravel-automations are working, but if they run into an error, they should kill the entire container

Steps to reproduce

• Compile a Laravel app
• Run it locally without a database

Expected result

• The container should die

Resources

This could potentially be a resource: just-containers/s6-overlay#87

Problem

• Everything is latest

Solution

• I should tag things as latest as well as version numbers (so people have more control)

References

Here is a good example: https://github.com/jauderho/dockerfiles/blob/main/.github/workflows/cloudflared.yml

Background

• We need to figure out how to organize each PHP image

Structure

For each PHP version, I am thinking of having 3 versions:

1. cli (for quick PHP CLI interactions)
2. fpm (for apps that need fpm separate from the web server)
3. fpm-nginx (for apps that include NGINX + FPM in all in one container)

Each image will depend on eachother, just like phpdocker-io (Dependency looks like: CLI < FPM < FPM-NGINX)

Where this adds some challenges

I'll need to update Github actions to:

1. Pull Ubuntu base image
2. Check caches
3. Build CLI images
4. Push CLI images
5. Build FPM images
6. Push CLI images
7. Build FPM-NGINX images
8. Push FPM-NGINX images
9. Automatically tag the latest PHP version as latest

Hopefully I can do this without having a mile long Github actions file 😅

FPM-NGINX

There will probably be a lot of people who will totally disagree with this methodology, but I really do like having the entire app in one container for exact reference points for the app (see this https://www.reddit.com/r/kubernetes/comments/f68s3z/what_is_the_best_way_to_deploy_laravel_in/fi3lsuq)

This methodology was also used in @fideloper's Shipping Docker course, which I really liked.

Offering the other images in this dependency structure should still give people the option to use what they need.

Next Steps

I will start organizing this and am open to any other comments/feedback.

Affected Docker Images

serversideup/php:-

Current Behavior

When using the current images (like serversideup/php:8.1-fpm-nginx) and you release a major upgrade with breaking changes, I will automatically be upgraded and my own images will stop working.

Expected Behavior

For the current images there should be the option to specify the image version, e.g. serversideup/php:8.1-fpm-nginx-v2.0.

So if you release a version 3.0 with breaking changes, my automatic build pipeline will not produce broken images. :-)

Steps To Reproduce

see above

Host Operating System

any

Docker Version

any

Anything else?

Thank you so much for your beautiful images.

Background

• I need to figure out how to fill in the data
• Adding this information will add more legitimacy and clarity to the images on DockerHub

Expected Results

• PHPDocker.io has a great example

Where I left off

• I did some quick searching how to find this, but immediate results were unsuccessful. Will try this again later

Hey @szepeviktor,

Thanks again for all of your help and feedback on these images. I really like learning from developers who are much smarter than me 🤓

If you have the time or interest, I would love to hear your feedback on what you think of these images.

What I am looking for

• Are there any massive security issues? If so where?
• Anything that makes you cringe?
• How would you do things differently?
• What are the highest priorities that should be fixed first?

Let us compensate you

If you have a PayPal (or whatever you use), we'd love to send a few bucks for your help. Just to be clear, it would probably be in the $50 to $100 USD ballpark, so don't spend hundreds of hours on this 😁

Organizing things

If we can keep your feedback in this single thread, then I can create issues for each item you come up with.

Thoughts?

If you're too busy... no problem! We totally get it. You had a lot of great feedback earlier, so I wanted to just let you know that I am in a good spot to actually make changes now that things are working.

Hope you are doing well!

I scanned the php:8.1-fpm-apache version and it said that there is a HIGH level vulnerability found.

Package: cryptsetup:2:2.2.2-3ubuntu2.3
Level: HIGH
Description: [disable encryption via header rewrite]

https://ubuntu.com/security/CVE-2021-4122

Why this is needed

• Before diving in too deep, let's make sure the automatons work

This depends on:

• #1
• #2

Please consider avoiding root (UID 0) and system users (UID 1-999) e.g. www-data.
Least privileges come with normal users.

Background

• @szepeviktor was gracious and contributed caching
• I temporarily commented this out in the actions file to solidify the build before

Caching will be helpful because:

1. Saves time in CI
2. We are good internet citizens by not draining @oerdnj's bandwidth resources

Scenarios to consider

✅ When we want a build

• There is an update to the base_image (ubuntu:20.04)
• There is an update in @oerdnj's repository

🛑 DO NOT build when

• There are no updates for @oerdnj's repo

(notice we still need to build even if there are not updates for the base_image)

Possible solutions

1. Check hash of @oerdnj's repo (http://ppa.launchpad.net/ondrej/php/ubuntu/dists/focal/Release)
2. Something like docker run ... /bin/bash -c "dpkg -l|shasum"

Related comment: 26723e7#r48044607

Next steps

• Finish the structuring (#9) first, then loop back to this

Problem

• Good problem: This project got a lot of attention quickly 😅
• Bad problem: I need to pay more attention to ensuring I am delivering quality deployments to the main images

Solution

• I might extend the Github actions so a dev branch deploys a serversideup/php-beta image
• This will allow me to run tests on my own apps before merging them into main

Current Behavior

When i start container with command "su - webuser -c "php artisan queue:work --tries=3"" its not processing queue from redis with no errors.
Also it not processing when i run this command inside container.
But when i run command from root (without su - webuser -c) all work.

Expected Behavior

Laravel queue work with webuser

Steps To Reproduce

bitnami/redis:latest
serversideup/php:8.1-fpm-nginx
Laravel 9.5.1
predis: 1.1.9

Host Operating System

Ubuntu-20.04-amd64

Docker Version

20.10.7

Anything else?

No response

Are there any plans to add PHP 8.2 support?
Thanks in advance!

Originally posted by @nsaliu in #59 (comment)

Current Behavior

As the title says, we're getting the screen filled up with this error in console when building a container with serversideup/php:8.1-fpm:

Host machine is a clean CentOS 7.6.1810 installation. We have Ubuntu based machines and we cannot reproduce it since it works properly.

s6-supervise php-fpm: warning: can't happen: timeout while the service is up!

This log is enormous and ends up weighing GBs.

This is the upper section of the log generated when building the container:

{"log":"[s6-init] making user provided files available at /var/run/s6/etc...exited 0.\n","stream":"stdout","time":"2022-09-21T09:22:54.234077611Z"}
{"log":"[s6-init] ensuring user provided files have correct perms...exited 0.\n","stream":"stdout","time":"2022-09-21T09:23:13.981158229Z"}
{"log":"[fix-attrs.d] applying ownership \u0026 permissions fixes...\n","stream":"stdout","time":"2022-09-21T09:23:14.515080141Z"}
{"log":"[fix-attrs.d] done.\n","stream":"stdout","time":"2022-09-21T09:23:15.016074619Z"}
{"log":"[cont-init.d] executing container initialization scripts...\n","stream":"stdout","time":"2022-09-21T09:23:15.709092034Z"}
{"log":"[cont-init.d] 10-generate-ssl: executing... \n","stream":"stdout","time":"2022-09-21T09:23:16.231078977Z"}
{"log":":candado_cerrado_con_llave: Generating a self-signed SSL certificate because one was not provided...\n","stream":"stdout","time":"2022-09-21T09:23:16.783900205Z"}
{"log":"Generating a RSA private key\n","stream":"stderr","time":"2022-09-21T09:23:16.909891846Z"}
{"log":"...............................................................................................................................................................................+++++\n","stream":"s
tderr","time":"2022-09-21T09:23:17.071584305Z"}
{"log":"........................................................................+++++\n","stream":"stderr","time":"2022-09-21T09:23:17.138873144Z"}
{"log":"writing new private key to '/etc/ssl/web/ssl.key'\n","stream":"stderr","time":"2022-09-21T09:23:17.139844063Z"}
{"log":"-----\n","stream":"stderr","time":"2022-09-21T09:23:17.139857295Z"}
{"log":"[cont-init.d] 10-generate-ssl: exited 0.\n","stream":"stdout","time":"2022-09-21T09:23:17.643062091Z"}
{"log":"[cont-init.d] 11-msmtp: executing... \n","stream":"stdout","time":"2022-09-21T09:23:18.228070886Z"}
{"log":"[cont-init.d] 11-msmtp: exited 0.\n","stream":"stdout","time":"2022-09-21T09:23:19.206105222Z"}
{"log":"[cont-init.d] 21-debug-apache2.j2: executing... \n","stream":"stdout","time":"2022-09-21T09:23:19.623105062Z"}
{"log":"[cont-init.d] 21-debug-apache2.j2: exited 0.\n","stream":"stdout","time":"2022-09-21T09:23:20.646149531Z"}
{"log":"[cont-init.d] 5-runas-user: executing... \n","stream":"stdout","time":"2022-09-21T09:23:21.225084191Z"}
{"log":"\n","stream":"stdout","time":"2022-09-21T09:23:21.93716779Z"}
{"log":"--------------------------------------------------------------------\n","stream":"stdout","time":"2022-09-21T09:23:21.937194013Z"}
{"log":" ____                             ____  _     _        _   _\n","stream":"stdout","time":"2022-09-21T09:23:21.937197153Z"}
{"log":"/ ___|  ___ _ ____   _____ _ __  / ___|(_) __| | ___  | | | |_ __\n","stream":"stdout","time":"2022-09-21T09:23:21.937199487Z"}
{"log":"\\___ \\ / _ \\  __\\ \\ / / _ \\  __| \\___ \\| |/ _` |/ _ \\ | | | |  _ \\\n","stream":"stdout","time":"2022-09-21T09:23:21.937201797Z"}
{"log":" ___) |  __/ |   \\ V /  __/ |     ___) | | (_| |  __/ | |_| | |_) |\n","stream":"stdout","time":"2022-09-21T09:23:21.937204411Z"}
{"log":"|____/ \\___|_|    \\_/ \\___|_|    |____/|_|\\__,_|\\___|  \\___/| .__/\n","stream":"stdout","time":"2022-09-21T09:23:21.93720658Z"}
{"log":"                                                            |_|\n","stream":"stdout","time":"2022-09-21T09:23:21.937208919Z"}
{"log":"\n","stream":"stdout","time":"2022-09-21T09:23:21.937211125Z"}
{"log":"Brought to you by [serversideup.net](http://serversideup.net/)\n","stream":"stdout","time":"2022-09-21T09:23:21.937213043Z"}
{"log":"--------------------------------------------------------------------\n","stream":"stdout","time":"2022-09-21T09:23:21.937215042Z"}
{"log":"\n","stream":"stdout","time":"2022-09-21T09:23:21.937217086Z"}
{"log":"To support Server Side Up projects visit:\n","stream":"stdout","time":"2022-09-21T09:23:21.937219063Z"}
{"log":"https://serversideup.net/sponsor\n","stream":"stdout","time":"2022-09-21T09:23:21.937221395Z"}
{"log":"-------------------------------------\n","stream":"stdout","time":"2022-09-21T09:23:21.937223521Z"}
{"log":"GID/UID\n","stream":"stdout","time":"2022-09-21T09:23:21.93722552Z"}
{"log":"-------------------------------------\n","stream":"stdout","time":"2022-09-21T09:23:21.937227478Z"}
{"log":"\n","stream":"stdout","time":"2022-09-21T09:23:22.012490726Z"}
{"log":"User uid:    1000\n","stream":"stdout","time":"2022-09-21T09:23:22.012518251Z"}
{"log":"User gid:    9999\n","stream":"stdout","time":"2022-09-21T09:23:22.012520889Z"}
{"log":"-------------------------------------\n","stream":"stdout","time":"2022-09-21T09:23:22.012523196Z"}
{"log":"\n","stream":"stdout","time":"2022-09-21T09:23:22.012525479Z"}
{"log":"[cont-init.d] 5-runas-user: exited 0.\n","stream":"stdout","time":"2022-09-21T09:23:22.167058385Z"}
{"log":"[cont-init.d] 50-laravel-automations: executing... \n","stream":"stdout","time":"2022-09-21T09:23:22.65208468Z"}
{"log":":hombre_corriendo: Checking for Laravel automations...\n","stream":"stdout","time":"2022-09-21T09:23:23.410353582Z"}
{"log":":candado_cerrado_con_llave: Linking the storage...\n","stream":"stdout","time":"2022-09-21T09:23:23.410388868Z"}
{"log":"\n","stream":"stdout","time":"2022-09-21T09:23:24.286664555Z"}
{"log":"   ERROR  The [public/storage] link already exists.  \n","stream":"stdout","time":"2022-09-21T09:23:24.286686122Z"}
{"log":"\n","stream":"stdout","time":"2022-09-21T09:23:24.286688967Z"}
{"log":"[cont-init.d] 50-laravel-automations: exited 0.\n","stream":"stdout","time":"2022-09-21T09:23:24.490162105Z"}
{"log":"[cont-init.d] done.\n","stream":"stdout","time":"2022-09-21T09:23:24.718093531Z"}
{"log":"[services.d] starting services\n","stream":"stdout","time":"2022-09-21T09:23:25.837054617Z"}
{"log":"s6-supervise apache2: warning: can't happen: timeout while the service is up!\n","stream":"stderr","time":"2022-09-21T09:23:26.506945651Z"}
{"log":"s6-supervise apache2: warning: can't happen: timeout while the service is up!\n","stream":"stderr","time":"2022-09-21T09:23:26.506963661Z"}
{"log":"s6-supervise apache2: warning: can't happen: timeout while the service is up!\n","stream":"stderr","time":"2022-09-21T09:23:26.506966296Z"}

And after that, the s6-supervise apache2: warning: can't happen: timeout while the service is up! is repeated beyond infinite.

We want to wake up a project based on Laravel 9.

Is there anything we're missing? Thank you in advance.

Expected Behavior

Just wake up the container normally, as we do in Ubuntu based host machines.

Steps To Reproduce

CentOS 7.6.1810 host machine, just trying to run docker-composer up --build, the error shows up on console

Host Operating System

CentOS 7.6.1810

Docker Version

Docker 20.10
Docker-compose 1.29

Anything else?

Thank you very much for your time and help!

Background

• I will eventually add PHP 8.0 support
• Right now I am going to focus on converting what we have first, then loop back to adding this later

The order in which nginx location directives are evaluated leads to this

being evaluated before this

This makes it impossible to define Laravel routes like livewire/livewire.js because they will always be seen as static assets. Same problem if the Laravel app servers other assets through its own routing.

Summary

• It would be helpful to add tests

Order

It would be nice to have each image go through these steps:

1. Setup (Pull base images & login to Docker)
2. Build
3. Test
4. Push

What needs to be figured out yet

• What is the best way to "test" that PHP is working?
• Will it change on each deployment type (CLI, FPM, FPM-NGINX)

Helpful resources

Here's some code that was provided by Github for reference:

  # Run tests.
  # See also https://docs.docker.com/docker-hub/builds/automated-testing/
  test:
    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v2

      - name: Run tests
        run: |
          if [ -f docker-compose.test.yml ]; then
            docker-compose --file docker-compose.test.yml build
            docker-compose --file docker-compose.test.yml run sut
          else
            docker build . --file Dockerfile
          fi

  Push image to GitHub Packages.
  See also https://docs.docker.com/docker-hub/builds/

https://hub.docker.com/r/serversideup/php 😲

Please consider adding a readme and show how images are built from each other. Ubuntu > cli > fpm > fpm-*

Affected Docker Images

All

Current Behavior

When there is a PHP error, they are not displaying.

Expected Behavior

PHP errors should display when the settings are configured to do so.

Steps To Reproduce

Follow reproduction steps here: https://github.com/jaydrogers/docker-php-test-app

Host Operating System

All

Docker Version

N/A

Anything else?

See the discussion from Discord by @zigazajc007:

Giving advises gives Jay the false sense of security and robust operations.
In this tiny slice of running a web application any advise is misleading!

Digest: sha256:b4f9e18267eb98998f6130342baacaeb9553f136142d40959a1b46d6401f0f2b

Please consider caching the image digest and skip pushing if it matches.

Why this is needed

• Github Actions will automate the heavy lifting for everything

I must say, I'm a heavy RaspberryPi user myself, and last time I checked, the Ubuntu images did not play well with ARM based system... Is it something that changed lately, multi arch images for ubuntu? If not, is there any reason why you don't use Alpine here?

Thanks to /u/Tontonsb on Reddit for this. See our discussion why this issue was created.

Problem

• XXS filtering is enabled, but it actually creates more harm than good

Solution

• Remove these lines from the Nginx security policy:

  docker-php/php/8.0/fpm-nginx/etc/nginx/server-opts.d/security.conf

  Lines 8 to 9 in 7223a37

  	# Enable XSS filtering
  	add_header X-XSS-Protection "1; mode=block" always;

Further reading

• Here's a list of browsers that don't implement it: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-XSS-Protection
• Here's the OWASP decision on removing it from suggestions: OWASP/CheatSheetSeries#376 (comment)

From /u/Tontonsb:
Now, why did the browsers remove the feature and why it was (and is) considered a vulnerability? Because it "protects" in a manner that the attacker can observe. Here's one of the attacks abusing it: https://portswigger.net/research/abusing-chromes-xss-auditor-to-steal-tokens

Current Behavior

There is not a field on the GitHub issue template to specify what image the user is having issues with

Expected Behavior

Allow the user to enter the Docker Image they are having issues with.

• Support multiple images
• Maybe even ask for Docker configurations to reproduce
• Ensure the issues are auto-tagged

Steps To Reproduce

Open an issue

Host Operating System

N/A

Docker Version

N/A

Anything else?

No response

Many people think that Cloudflare will protect their web application.
Many people are happy that Cloudflare pays for their CDN bandwidth.
I think Cloudflare is a monster. Especially in their free plan. You loose control of many things.

I conclude Cloudflare is not for business. You should protect your web application, pay for a CDN, purchase an SSL certificate etc.

business meaning you have at least 1 employee in full-time job

Sub 1 employee "businesses" are actually fantasies: none of the above applies!

As users will not run anything but certain popular PHP stuff we could consider telling them how to deal with

• Laravel
• WordPress/WooCommerce
• Magento

Background

• Currently the fpm-apache and fpm-nginx images use Supervisor to bring things up
• According to some reading online, supervisor is not the best for this because it could lead to zombie processes or not properly handling errors

Possible Solution

• Use S6 Overlay
• @brianlmoon also recommended this: https://github.com/jwilder/dockerize

More details

• This is a process supervisor specifically built for Docker
• S6 is used in many LinuxServer.io images

Hesitations

• I might want to look into Swoole more (#14) because this could be where we just leave FPM all together (🥳)
• The only thing I would need to understand is how can Wordpress run with Apache + Swoole
• If I can get things to work, I might be able to skip S6 all together

Issue

• I have a scheduled instance that runs the build of the beta images, but it is running it from main (not dev)

Detailed info

See this example: https://github.com/serversideup/docker-php/runs/2762400574?check_suite_focus=true#step:2:40

Notes

• Need to look at Github actions and make sure that its pulling dev only

Docker suggests you to run 1 service per container.

- SSL termination - web server - PHP-FPM
\ SMTP server

If you want to run a monolith why not do it in an operating system and keep it as clean as a container?

Why is this important

• We want the images to run every night to get the latest builds

Depends on

• #3

Issue description

As the title, ini_set() doesn't seem to work with php-fpm.
I tried confirming it with the following images:

• serversideup/php:7.3-fpm-apache
• serversideup/php:7.4-fpm-apache
• serversideup/php:8.0-fpm-apache
• serversideup/php:8.1-fpm-apache

Environment

• Opertaing System Version: macOS 12
• Docker Version: Docker version 20.10.12, build e91ed57

Steps to reproduce the issue

1. Create a index.php
2. Use below code:

<?php
echo ini_get('display_errors');

if (ini_get('display_errors')) {
    ini_set('display_errors', '0');
} else {
    ini_set('display_errors', '1');
}

echo ini_get('display_errors');

3. ini_set returns false, display_errors value unchanged.

What is expected?

Value of display_errors will change.

Additional details / screenshots

I have not changed any settings from your Docker images.

See https://ssl-config.mozilla.org/