sed command in Dockerfile wont be executed or is overwritten

Question

I want it to run apache in a docker container as the same user as the one I'm using on my host system. Thus I own the files on my host to edit them and apache (PHP) can create folders etc..

EDIT: I got the sed command to work with by changing it a little:

RUN sed -rie 's|export APACHE_RUN_USER=.*|export APACHE_RUN_USER=wipster|g' /etc/apache2/envvars
RUN sed -rie 's|export APACHE_RUN_GROUP=.*|export APACHE_RUN_GROUP=wipster|g' /etc/apache2/envvars

But when checking by using top, apache is still running as www-data.

My Dockerfile:

FROM php:7.2-apache

RUN adduser wipster --disabled-password --disabled-login --gecos ""

ENV APACHE_RUN_USER wipster
ENV APACHE_RUN_GROUP wipster

RUN sed -i "s#APACHE_RUN_USER:=.*#APACHE_RUN_USER:=wipster}#" /etc/apache2/envvars \
    && sed -i "s#APACHE_RUN_GROUP:=.*#APACHE_RUN_GROUP:=wipster}#" /etc/apache2/envvars

RUN    apt-get -qqy update \
    && apt-get install -y libjpeg-dev libpng-dev re2c libmcrypt-dev zlib1g-dev libssl-dev libc-client2007e-dev libkrb5-dev libcurl4-gnutls-dev libxml2-dev libxslt-dev libldap2-dev libssl-dev vim strace unzip g++

RUN touch /var/www/html/php-error.log
RUN chown wipster:wipster /var/www/html/php-error.log

RUN    docker-php-ext-install bcmath mbstring mysqli pdo_mysql zip curl pcntl \
    && docker-php-ext-configure gd --with-jpeg-dir=/usr/lib \
    && docker-php-ext-install gd \
    && docker-php-ext-configure imap --with-imap-ssl --with-kerberos \
    && docker-php-ext-install imap \
    && docker-php-ext-configure ldap --with-libdir=lib/x86_64-linux-gnu/ \
    && docker-php-ext-install ldap

# Install xhprof from tideways.
RUN curl -L https://github.com/tideways/php-xhprof-extension/archive/v5.0-beta2.tar.gz | tar xz && \
    cd php-xhprof-extension-5.0-beta2/ && \
    phpize && \
    ./configure && \
    make && \
    make install

RUN yes | pecl install xdebug-2.7.2 \
    && pecl install redis \
    && docker-php-ext-enable redis xdebug opcache tideways_xhprof

# /usr/local/etc/php
ADD config/crm.php.ini /usr/local/etc/php/conf.d/
ADD config/xdebug.ini /usr/local/etc/php/conf.d/
ADD config/opcache.ini /usr/local/etc/php/conf.d/
ADD config/opcache-blacklist /usr/local/etc/php/
ADD config/xhprof.ini /usr/local/etc/php/conf.d/

RUN a2enmod headers expires deflate rewrite

# xdebug cli debugging
RUN export XDEBUG_CONFIG="remote_enable=1 remote_mode=req remote_port=9000 remote_host=192.168.1.144 remote_connect_back=0"
RUN export PHP_IDE_CONFIG="serverName=wipster-dckr"

EXPOSE 80

VOLUME ["/var/www"]

The problem is when I connect to the container via ssh and check /etc/apache2/envvars it still has www-data as the run user. I used the same Dockerfile on an Alpine Linux with the php:7.1-apache and it worked just fine. When I execute the sed command manually it does also work. Now I'm on an elementary os Juno with a slightly different image and the docker version is 18.09.7.

My docker-compose.yml:

version: "3"

networks:
    webnet:
services:
    web:
        image: wipster/relaunch:1
        depends_on:
            - db
        deploy:
            replicas: 1
            resources:
                limits:
                    cpus: '3.0'
                    memory: 2000M
                reservations:
                    cpus: '1.0'
                    memory: 1000M
        volumes:
            - ../relaunch:/var/www/html:delegated
        ports:
            - 8000:80
        networks:
            - webnet
    db:
        image: mysql:5.7
        deploy:
            replicas: 1
            resources:
                limits:
                    cpus: '2.0'
                    memory: 1000M
                reservations:
                    cpus: '1.0'
                    memory: 500M
        volumes:
            - db_data_wipster:/var/lib/mysql:delegated
        environment:
            MYSQL_ROOT_PASSWORD: root
            MYSQL_DATABASE: wipster
            MYSQL_USER: root
            MYSQL_PASSWORD: root
        ports:
            - 3306:3306
        networks:
            - webnet
        command: mysqld --sql_mode="NO_ENGINE_SUBSTITUTION" --innodb-buffer-pool-size=536870912 --innodb-flush-method=O_DIRECT --innodb-flush-log-at-trx-commit=0
volumes:
    db_data_wipster:

Am I missing anything? Do I need to run the sed command later? That doesn't work either.

Answer 1

You can verify the file is modified correctly by doing a grep:

FROM php:7.2-apache

RUN adduser wipster --disabled-password --disabled-login --gecos ""

ENV APACHE_RUN_USER wipster
ENV APACHE_RUN_GROUP wipster

RUN cat /etc/apache2/envvars | grep -B 2 -A 2 APACHE_RUN_USER

RUN sed -i "s#APACHE_RUN_USER:=.*#APACHE_RUN_USER:=wipster}#" /etc/apache2/envvars \
    && sed -i "s#APACHE_RUN_GROUP:=.*#APACHE_RUN_GROUP:=wipster}#" /etc/apache2/envvars

RUN cat /etc/apache2/envvars | grep -B 2 -A 2 APACHE_RUN_USER

And it indeed seems to make the change you intend:

Step 5/7 : RUN cat /etc/apache2/envvars | grep -B 2 -A 2 APACHE_RUN_USER
 ---> Running in 76aad84738a1
# settings are defined via environment variables and then used in apache2ctl,
# /etc/init.d/apache2, /etc/logrotate.d/apache2, etc.
: ${APACHE_RUN_USER:=www-data}
export APACHE_RUN_USER
: ${APACHE_RUN_GROUP:=www-data}
export APACHE_RUN_GROUP
Removing intermediate container 76aad84738a1
 ---> 1be6e6068d73
Step 6/7 : RUN sed -i "s#APACHE_RUN_USER:=.*#APACHE_RUN_USER:=wipster}#" /etc/apache2/envvars     && sed -i "s#APACHE_RUN_GROUP:=.*#APACHE_RUN_GROUP:=wipster}#" /etc/apache2/envvars
 ---> Running in 75a741dadb34
Removing intermediate container 75a741dadb34
 ---> 6b2d9b0dfdac
Step 7/7 : RUN cat /etc/apache2/envvars | grep -B 2 -A 2 APACHE_RUN_USER
 ---> Running in 2555c019ab43
# settings are defined via environment variables and then used in apache2ctl,
# /etc/init.d/apache2, /etc/logrotate.d/apache2, etc.
: ${APACHE_RUN_USER:=wipster}
export APACHE_RUN_USER
: ${APACHE_RUN_GROUP:=wipster}

Answer 2

Just for a local development environment which will not be used elsewhere I just use a workaround. I add my user, in this case "wipster", to the group www-data and change the file rights of the group. The problem might occur because the user and group is hard coded in this particular image.