Docker containers cannot access source files on Fedora 30

[pboyd04]

The docker containers return 403 for all pages on Fedora 30

profiles.burningflipside.local | 192.168.86.34 - - [22/Jun/2020:14:13:58 +0000] "GET / HTTP/1.1" 403 763 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/83.0.4103.97 Safari/537.36"
profiles.burningflipside.local | [Mon Jun 22 14:13:58.513403 2020] [core:crit] [pid 19] (13)Permission denied: [client 192.168.86.34:5721] AH00529: /var/www/html/.htaccess pcfg_openfile: unable to check htaccess file, ensure it is readable and that '/var/www/html/' is executable
profiles.burningflipside.local | 192.168.86.34 - - [22/Jun/2020:14:13:58 +0000] "GET /favicon.ico HTTP/1.1" 403 636 "https://192.168.86.2:3300/" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/83.0.4103.97 Safari/537.36"
profiles.burningflipside.local | [Mon Jun 22 14:13:58.609672 2020] [core:crit] [pid 19] (13)Permission denied: [client 192.168.86.34:5721] AH00529: /var/www/html/.htaccess pcfg_openfile: unable to check htaccess file, ensure it is readable and that '/var/www/html/' is executable, referer: https://192.168.86.2:3300/

[russelltsherman]

the log suggests the web server cannot read source files
are the source repos checked out to devsandbox/src ?
are the source directories being properly mounted into the application containers?

[pboyd04]

Yes they are checked out. I'm fairly certain they are mounted correctly as I get 403's for things that exist and 401s for things I don't if I nuke the .htaccess file. It doesn't have permission for the .htaccess file either and therefore returns 403 to everything. NOTE: I nuked the checkouts, reran the ./bin/repos file as a normal user and still have the same issue.

[russelltsherman]

i have successfully reproduced the issue that you have reported..
services launched through docker compose using sudo do not appear to create volume mounts within the containers which are usable.. i don't have the kind of time required to dig deep enough to identify the root cause of this..

if you fix the docker role issue on your local machine and destroy and recreate your clone of this repo your experience should be much better, however it will still not be 100% functional as the setup script assumes a debian based distro and uses apt-get to fetch required software (see bin/composer) that script would need changed to support fedora or performed manually..

you might consider setting up the project in a debian based virtual machine.. this path has been well tested.. and it will remove the additional complications of conflicting requirements or duplicate services running on your host machine..

[pboyd04]

2 steps forward, 1 step back. After switching to the ce version of docker I'm able to compose without sudo. However, now I can't even hit the webservers at all:

[pboyd@route1 ~]$ curl -k https://localhost:3100/
curl: (35) OpenSSL SSL_connect: SSL_ERROR_SYSCALL in connection to localhost:3100

0bb5064e7841 burnerdev/php-appserver:7.1-apache "docker-php-entrypoi…" 5 minutes ago Up 5 minutes 80/tcp, 0.0.0.0:3300->443/tcp profiles.burningflipside.local
b1d37d5e866a burnerdev/php-appserver:7.1-apache "docker-php-entrypoi…" 5 minutes ago Up 5 minutes 80/tcp, 0.0.0.0:3200->443/tcp wiki.burningflipside.local
6a1bfc34881e burnerdev/php-appserver:7.1-apache "docker-php-entrypoi…" 5 minutes ago Up 5 minutes 80/tcp, 0.0.0.0:3100->443/tcp www.burningflipside.local
5a7c7b26629f burnerdev/php-appserver:7.1-apache "docker-php-entrypoi…" 5 minutes ago Up 5 minutes 80/tcp, 0.0.0.0:3400->443/tcp secure.burningflipside.local
7dcd356a5b46 burnerdev/openldap:1.1.8 "/container/tool/run" 5 minutes ago Up 5 minutes 0.0.0.0:389->389/tcp, 0.0.0.0:636->636/tcp ldap.burningflipside.local

[pboyd04]

Looks like the cypher suites aren't set on the containers?
[pboyd@route1 ~]$ openssl s_client -connect localhost:3100
CONNECTED(00000003)
write:errno=104

no peer certificate available

No client certificate CA names sent

SSL handshake has read 0 bytes and written 303 bytes
Verification: OK

New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 0 (ok)

[russelltsherman]

i believe these containers are using apache default/dummy certificates which work for the browser once you tell it to allow insecure.. i was not aware that curl would not accept them even with the insecure flag.. that's interesting..

[russelltsherman]

curiously curl doesn't seem to take issue with the certificates from where i sit..

[pboyd04]

From the openssl output it looks like the apache handshake is indicating it doesn't support any ciphers... This is really screwy. I can't replicate that with a simple docker container running apache on the same server. I'm really not sure what is causing it.

[russelltsherman]

in your simple docker container running apache what certificates were used and how were they applied?

[pboyd04]

All I did was docker pull ubuntu, run bash in it, update it, install apache, and add the following to /etc/apache2/sites-enabled/000-default.conf:

<VirtualHost *:443>
                ServerAdmin webmaster@localhost
                DocumentRoot /var/www/html
                ErrorLog ${APACHE_LOG_DIR}/error.log
                CustomLog ${APACHE_LOG_DIR}/access.log combined
                SSLEngine on
                SSLCertificateFile /etc/apache2/ssl/ca.crt
                SSLCertificateKeyFile /etc/apache2/ssl/ca.key
</VirtualHost>

[russelltsherman]

these containers use the default ssl apache conf file which while similar points to snake oil certs (whatever that means)
as far as i know these are garden variety self signed certificates...

the files referenced exist within the container and appear to be otherwise valid

for simplicity I used an apache default example conf file unmodified and mounted the application source into the default /var/www/html directory..

[pboyd04]

If I run openssl s_client -connect from inside the container everything is fine. If I run it outside the container then I get an error... I'm not sure why. This docker 19.03.12 and I followed the instructions on the site to install it.

[pboyd04]

And port mapping works find for other docker containers that I pull... I'm not sure what is wrong with this setup.

[pboyd04]

And if I just do "docker run -p 4000:443 burnerdev/php-appserver:7.1-apache" then port 4000 works fine. It's just the copies installed as part of the setup.sh and compose scripts...

[russelltsherman]

the certificate issue you report i cannot reproduce.. i have checked this using my local install on OSX, an install in a debian based virtual machine as well as the fedora based virtual machine.. in all three of those cases the snakeoil cert does not appear to be a problem.. curl -k requests to local ports are successful in all cases..

i'm seeing no issues with port mapping.. can you be more specific about what you are experiencing?

[pboyd04]

Ok, here it is as well as I can break it down.

Talking to the webserver from inside the container works fine.
Talking to a container based on the same image on a mapped port works fine. good.log
Talking to the container spun up by setup.sh and bin/compose fails the SSL handshake. bad.log

Commands to spin up a working container:

1. docker run -p 4000:443 burnerdev/php-appserver:7.1-apache

Commands to spin up non-working containers:

1. ./setup.sh
2. edit docker-compose.yaml to comment out mysql and mongo
3. ./bin/compose up

[russelltsherman]

what command do you execute that results in good.log/bad.log

[pboyd04]

openssl s_client -connect localhost:3300 for bad.log
openssl s_client -connect localhost:4000 for good.log

[pboyd04]

Ok, I've manged to work around this by pulling the container off the flipside_dev network and onto the default bridge:
docker network disconnect flipside_dev 0bb5064e7841
docker network connect bridge 0bb5064e7841

[russelltsherman]

openssl s_client -connect localhost:3300 produces the following for me (fedora30 VM)
https://gist.github.com/russelltsherman/3e3a5656ef5de49aca383ad78c2e4a48

output of both commands appears identical for me