Home / user-327331

TacoV's questions

Martin Hope
TacoV
Asked: 2021-01-02 08:22:22 +0800 CST
  • 1

On my production environment I have some apps in Docker that need to connect to backing services eg the database on the same host. I found I needed to make an exception in iptables to accept these connections.

However, the ip range of the docker network is varying between restarts. At first it was 172.18.0.0/24, later 172.17.0.0/24 and 172.20.0.0/24, now the ips are 192.168.172.2 and 192.168.192.3.

How can you accept Docker traffic from within a container to say mariadb reliably and safely?

EDIT: An answer seems to be specifying the IPAM configuration, but attaching to an interface seems more elegant

iptables docker docker-compose
Martin Hope
TacoV
Asked: 2020-11-26 11:57:50 +0800 CST
  • 1

Contaxt

I currently have an Apache installation with multiple sites via VirtualHosts. My goal is to slowly migrate towards a dockerized setup where one nginx reverse-proxy distributes the requests to dockerized apps.

To start the migration, I created a catch-all in the Apache setup; any request towards a site no longer known by Apache is reverse-proxied to the nginx-proxy docker container. Then, I can add one site to the docker solution, disable it in Apache, and the transition is seemless. This works well for http requests; I'm running into issues for the https requests.

Question

How can I setup apache to not interact with the https requests, but just pass the certificate and encrypted data from nginx? Just transparently pass the requests back and forth?

client <-- https (nginx signed) --> apache <-- https (nginx signed) --> nginx

Other scenarios would be:

Decrypt and re-sign: client <-- https (apache signed) --> apache <-- https (nginx signed) --> nginx

Decrypt in the background: client <-- https (apache signed) --> apache <-- http --> nginx

These seems possible but since nginx serves multiple domains, the apache signature does not match. Also, it does not help in migrating if Apache still needs to do the signing.

Current base config

<VirtualHost *:80>

    ServerName example.com

    ProxyPass / http://127.0.0.1:1001/
    ProxyPassReverse / http://127.0.0.1:1001/
    ProxyPreserveHost On

</VirtualHost>

<VirtualHost *:443>

    ServerName example.com

    ProxyPass / https://127.0.0.1:1002/
    ProxyPassReverse / https://127.0.0.1:1002/
    ProxyPreserveHost On

    # These three lines make Apache sign the requests. Without them I
    # generate SSL_ERROR_RX_RECORD_TOO_LONG errors, but with them the
    # response is always signed with the "example.com" certificate
    SSLCertificateFile /etc/letsencrypt/live/example.com/fullchain.pem
    SSLCertificateKeyFile /etc/letsencrypt/live/example.com/privkey.pem
    Include /etc/letsencrypt/options-ssl-apache.conf

    # This options seems to make sense but I'm unsure what it does
    SSLProxyEngine On

</VirtualHost>
ssl reverse-proxy apache-2.4
Martin Hope
TacoV
Asked: 2017-07-28 07:30:17 +0800 CST
  • 0

What's the difference between starting postfix directly (postfix start) and as a service (service postfix start)? What (if any) is the preferred way as a best practice, and is there any way to make service postfix status show the process as active no matter how it was started?

Some code to further clarify:

root@luke:/# postfix status; service --status-all | grep postfix
postfix/postfix-script: the Postfix mail system is running: PID: 17332
 [ - ]  postfix

root@luke:/# postfix stop; service postfix start
postfix/postfix-script: stopping the Postfix mail system

root@luke:/# postfix status; service --status-all | grep postfix
postfix/postfix-script: the Postfix mail system is running: PID: 18237
 [ + ]  postfix
postfix