Archive for February, 2025

How to Deploy a Docker Container with Apache on Debian Linux and assign container static IP address

Friday, February 14th, 2025

deploy-docker-container-with-static-ip-on-debian-linux-howto-logo

Deploying a Docker container with Apache on Debian Linux is an efficient way to manage web servers in isolated environments. Docker provides a convenient way to package and run applications, and when combined with Apache, it can be used for hosting websites or web applications. In this guide, we’ll walk through the necessary steps to set up and run an Apache web server inside a Docker container on a Debian Linux machine.

Prerequisites

Before starting, ensure that you have the following prerequisites in place:

  • A Debian-based Linux system (e.g., Debian 10, Debian 11).
  • Docker installed on your system. If you don’t have Docker installed, follow the installation steps below.
  • Basic knowledge of Linux commands and Docker concepts.

Step 1: Install Docker on Debian

First, you need to install Docker if it is not already installed on your Debian machine. Here’s how to install Docker on Debian:

  1. Update the package database:
     

    # apt update

  2. Install the required dependencies:

    apt install apt-transport-https ca-certificates curl gnupg lsb-release

  3. Add Docker’s official GPG key:

    # curl -fsSL https://download.docker.com/linux/debian/gpg | sudo gpg --dearmor -o /usr/share/keyrings/docker-archive-keyring.gpg

  4. Set up the stable Docker repository:
     

    # echo "deb [arch=amd64 signed-by=/usr/share/keyrings/docker-archive-keyring.gpg] \
    https://download.docker.com/linux/debian $(lsb_release -cs) stable" \
    | tee /etc/apt/sources.list.d/docker.list > /dev/null 
    

     

  5. Install Docker Engine:
     

    # apt update sudo apt install docker-ce docker-ce-cli containerd.io

     

  6. Start Docker and enable it to run on boot:
     

    systemctl start docker
    # systemctl enable docker

  7. Verify Docker installation:
     

    # docker --version

    This should display the installed Docker version, confirming that Docker is installed successfully.
     

Step 2: Pull Apache Docker Image or whatever docker image you want to have installed

Now that Docker is set up, you need to pull the official Apache image from Docker Hub. The Apache image is maintained by the Docker team and comes pre-configured for running Apache in a container.
 

  1. Pull the Apache HTTP Server image:

    # docker pull httpd

    This will download the official Apache HTTP server image ( httpd ) from Docker Hub.

Step 3: Run Apache Container

Once the Apache image is pulled, you can start a Docker container running Apache.

  1. Run the Docker container:

    # docker run -d --name apache-container -p 80:80 httpd

    Here’s what the options mean:

    • -d : Runs the container in detached mode (in the background).
    • --name apache-container : Names the container apache-container .
    • -p 80:80 : Maps port 80 on the host to port 80 in the container (so you can access the Apache web server through port 80).
    • httpd : The name of the image you want to run (the Apache HTTP server).
  2. Verify the container is running:

    # docker ps

    This will show a list of running containers. You should see the apache-container running.

  3. Test the Apache server:

    Open a web browser and go to http://<your-server-ip> . You should see the default Apache welcome page, indicating that Apache is running successfully in the Docker container.

Step 4: Customize Apache Configuration (Optional)

You may want to customize the Apache configuration or serve your own website inside the container. Here’s how to do it:

 

. Run the Apache Docker Container with a Specific IP Address

To bind the container to a specific IP address, use the --add-host or --publish flag while running the container.

  • If you want to bind Apache to a specific IP address on the host (for example, 192.168.1.100 ), use the --publish option:

# docker run -d --name apache-container -p 192.168.1.100:80:80 apache-container


This command tells Docker to bind port 80 in the container to port 80 on the host's IP address 192.168.1.100 . Replace 192.168.1.100 with the desired IP address of your system.

  1. Create a directory for your custom website:

    # mkdir -p /home/user/my-website

  2. Add an index.html file or whatever PHP / Perl whatever files will be served:

    Create a simple HTML file in the directory:
     

    # echo '<html><body><h1>Hello, Apache on Docker!</h1></body></html>' > /home/user/my-website/index.html

  3. Stop the running Apache container:

    # docker stop apache-container

  4. Remove the stopped container:

    # docker rm apache-container

  5. Run a new container with your custom website:

    Now, you can mount your custom directory into the container as a volume:

    # docker run -d --name apache-container -p 80:80 -v /home/user/my-website:/usr/local/apache2/htdocs/ httpd

    The -v option mounts the local directory /home/user/my-website to the Apache server’s default document root directory ( /usr/local/apache2/htdocs/ ).

  6. Verify the custom website:

    Reload the web page in your browser. Now, you should see the "Hello, Apache on Docker!" message, confirming that your custom website is being served from the Docker container.

Step 5: Manage Docker Containers

You can manage the running Apache container with the following commands:

  • Stop the container:

    # docker stop apache-container

  • Start the container:

    # docker start apache-container

  • Remove the container (if needed):

    # docker rm apache-container

  • View logs for troubleshooting:

    # docker logs apache-container

Step 6: Automating Docker Container Deployment (Optional step)

If you want the Apache container to restart automatically after a system reboot, you can add the --restart flag to the docker run command.

For example, to make the container restart automatically unless it is manually stopped, use:
 

# docker run -d --name apache-container -p 80:80 --restart unless-stopped \
-v /home/user/my-website:/usr/local/apache2/htdocs/ httpd 

Conclusion

By following these steps, you can easily deploy Apache inside a Docker container on a Debian Linux machine. Docker allows you to run your Apache web server or whatever docker app you need to have in a lightweight and isolated environment, which is useful development, testing, and production environments. You can further customize this setup by adding additional configurations, integrating with databases, or automating deployments with Docker Compose or Kubernetes.

Enjoy your new Dockerized Apache setup!

How to prevent /etc/resolv.conf to overwrite on every Linux boot. Make /etc/resolv.conf DNS records permanent forever

Tuesday, February 4th, 2025

how-to-make-prevent-etc-resolv.conf-to-ovewrite-on-every-linux-boot-make-etc-resolv-conf-permanent-forever

Have you recently been seriously bothered, after one of the updates from older to newer Debian / Ubuntu / CentOS or other Linux distributions by the fact /etc/resolv.conf has become a dynamic file that pretty much in the spirit of cloud technologies is being regenerated and ovewritten on each and every system (server) OS update /  reboot and due to that you start getting some wrong inappropriate DNS records /etc/resolv.conf causing you harm to the server infrastructure?

During my set of server infra i have faced that odditty for some years now and i guess every system administrator out there has suffered at a point by having to migrate an older Linux release to a newer one, where something gets messed up with DNS resolving due to that Linux OS new feature of /etc/resolv.conf not being really static any more.

The Dynamic resolv.conf file for glibc resolver is often generated used to be regenerated by resolvconf command and consequentially can be tampered by dhcpd resolved systemd service as well perhaps other mechanism depending on how the different Linux distribution architects make it to behave …

There are more than one ways to stop the annoying /etc/resolv.conf ovewritten behavior

1. Using dhcpd to stop /etc/resolv.conf being overwritten

Using dhcpd either a small null up script can be used or a separate hook script.

The null script would look like this

root@pcfreak:/root# vim /etc/dhcp/dhclient-enter-hooks.d/nodnsupdate

#!/bin/sh
make_resolv_conf() {
    :
}

root@pcfreak:/root# chmod +x /etc/dhcp/dhclient-enter-hooks.d/nodnsupdate

 

This script overrides an internal function called make_resolv_conf() that would normally overwrite resolv.conf and instead does nothing.

On old Ubuntu s and Debian versions this should work.


Alternative method is to use a small hook dhcp script like this:

root@pcfreak:/root# echo 'make_resolv_conf() { :; }' > /etc/dhcp/dhclient-enter-hooks.d/leave_my_resolv_conf_alone
chmod 755 /etc/dhcp/dhclient-enter-hooks.d/leave_my_resolv_conf_alone


Next boot when dhclient runs onreboot or when you manually run sudo ifdown -a ; sudo ifup -a , 
it loads this script nodnsupdate or the hook script and hopefully your manually configured values of /etc/resolv.conf would not mess up your file anymore.

2. Use a chattr and set immutable flag attribute to /etc/resolv.conf to prevent re-boot to ovewrite it

Anyways the universal and simple way "hack" to prevent /etc/resolv.conf many prefer to use instead of dhcp (especially as not everyone is running a dhcp on a server) , to overwrite is to delete the file and make it immutable with chattr (assuming chattr is supported by the filesystem i.e. EXT3 / EXT4 / XFS , you use on the Linux.).

You might need to check the filesystem type, before using chattr.

root@pcfreak:/root# blkid  | awk '{print $1 ,$3, $4}'
/dev/xvda1: TYPE="xfs"
/dev/xvda2: TYPE="LVM2_member"
/dev/mapper/centos-root: TYPE="xfs"
/dev/mapper/centos-swap: TYPE="swap"
/dev/loop0:
/dev/loop1:
/dev/loop2:

 

Normally EXT fs and XFS support it, note that this is not going to be the case with a network filesystem like NFS.

If you have some weird Filesystem type and you try to chattr you will get error like:

chattr: Inappropriate ioctl for device while reading flags on /etc/resolv.conf

To make /etc/resolv.conf file unchangeable on next boot by dhcpd or systemd-resolved

 a systemd service that provides network name resolution to local applications via a D-Bus interface, the resolve NSS service (nss-resolve)
 

root@pcfreak:/root# rm -f /etc/resolv.conf  
{ echo "nameserver 1.1.1.1";
echo "nameserver 1.0.0.1;
echo "search mydomain.com"; } >  /etc/resolv.conf
chattr +i  /etc/resolv.conf
reboot  


Also it is a good think if you don't plan after some update to have unexpected results caused by systemd-resolved doing something strange is to rename to /etc/systemd/resolved.conf.dpkg-bak or completely remove file

/etc/systemd/resolved.conf

To prevent dhcpd to overwrite the server /etc/resolv.conf from something automatically taken from preconfigured central DNS inside the network configurations made from /etc/network/interfaces configurations such as:

        dns-nameservers 127.0.0.1 8.8.8.8 8.8.4.4 207.67.222.222 208.67.220.220


You need to change the DHCP configuration file named dhclient.conf and use the supersede option. 
To so Edit /etc/dhcp/dhclient.conf.

Look for lines like these:

#supersede domain-name "fugue.com home.vix.com";
#prepend domain-name-servers 127.0.0.1;

Remove the preceding “#” comment and use the domain-name and/or domain-name-servers which you want (your DNS FQDN). Save and hopefully the DNS related ovewrite to /etc/resolv.conf would be stopped, e.g. changes inside /etc/resolv.conf mnually done should stay permanent.

Also it is a good practice to disable ddns-update-style direcive inside /etc/dhcp/dhcpd.conf

root@pcfreak:/root# vim /etc/dhcp/dhcpd.conf
##ddns-update-style none;

However on many newer Debian Linux as of 2025 and its .deb based derivative distros, you have to consider the /etc/resolv.conf is a symlink to another file /etc/resolvconf/run/resolv.conf

If that is the case with you then you'll have to set the immutable chattr attribute flag like so

root@pcfreak:~# chattr -V +i /etc/resolvconf/run/resolv.conf
chattr 1.47.0 (5-Feb-2023)
Flags of /etc/resolvconf/run/resolv.conf set as —-i—————–

root@pcfreak:/root# lsattr /etc/resolvconf/run/resolv.conf
—-i—————– /etc/resolvconf/run/resolv.conf

3.  Make /etc/resolv.conf permanent with simple custom a rc.local boot triggered resolv.conf ovewrite from a resolv.conf_actual template file

Consider that due to the increasing complexity of how Linux based OS-es behaves and the fact the Linux is more and more written to fit integration into the Cloud and be as easy as possible to containerize or orchestrate (with lets say docker or some cloud PODs) and other multitude of OS virtualiozation stuff modernities  /etc/resolv.conf might still continue to ovewrite ! 🙂

Thus I've come up with my very own unique and KISS (Keep it Simple Stupid) method to make sure /etc/resolv.conf is kept permanent and ovewritten on every boot for that "hack" trick you only need to have the good old /etc/rc.local enabled – i have written a short article how it can be enabled on newer debian / ubuntu / fedora / centos Linux here.

Prepare your permanent and static /etc/resolv.conf file containing your preferred server DNSes under a file /etc/resolv.conf_actual

Here is an example of one of my /etc/resolv.conf template files that gets ovweritten on each boot.

root@pcfreak:/root# cat /etc/resolv.conf_actual
domain pc-freak.net
search pc-freak.net
#nameserver 192.168.0.1

nameserver 127.0.0.1
nameserver 8.8.8.8
nameserver 8.8.4.4
nameserver 212.39.90.42
nameserver 212.39.90.43
nameserver 208.67.222.222
nameserver 208.67.220.220
options timeout:2 rotate


And in /etc/rc.local place before the exit directive inside the file simple copy over the original /etc/resolv.conf file real location.

Before proceeding to add it to execute /etc/rc.local assure yourself file is being venerated by OS.
 

root@pcfreak:/etc/dhcp# systemctl status rc-local
● rc-local.service – /etc/rc.local Compatibility
     Loaded: loaded (/etc/systemd/system/rc-local.service; enabled; preset: enabled)
    Drop-In: /usr/lib/systemd/system/rc-local.service.d
             └─debian.conf
     Active: active (exited) since Sun 2024-12-08 21:59:01 EET; 1 month 27 days ago
       Docs: man:systemd-rc-local-generator(8)
    Process: 1417 ExecStart=/etc/rc.local start (code=exited, status=0/SUCCESS)
        CPU: 302ms

Notice: journal has been rotated since unit was started, output may be incomplete.

root@pcfreak:/root# vim /etc/rc.local

 

cp -rpf /etc/resolv.conf_actual /etc/resolvconf/run/resolv.conf


NB ! Make sure those line is placed before any exit 0 command in /etc/rc.local otherwise that won''t work

That's it folks 🙂 
Using this simple trick you should be no longer bothered by a mysterious /etc/resolv.conf overwritten on next server reboot or system update (via a puppet / ansible or some other centralized update automation stuff) causing you a service or infrastructure outage.

Enjoy !

How to log multiple haproxy server instance processes on single server in seperate files with rsyslog filters

Monday, February 3rd, 2025

haproxy-log-frontend-backend-and-transferred-connections-in-separate-log-files-on-linux-server-logo

Lets say you want to have 2 separates instances of haproxy and log the output to separate files, how this can be achived?

In this article, i'll tell in few easy steps how to enable multiple haproxy server instances created on the same Linux server / VPS or docker container to run and log its served content in separate log files without using separate file logging handlers "local"s.
The task might be helpful for people who are involved with DevOps and has to route separate proxy traffic on same linux machine.
 

Lets say you have the following haproxy process instances running with separate haproxy configs:
 

1. haproxy
2. haproxy_worker2
3. haproxy_worker3

 

List of processes on the Linux host would looks like that.

[root@linux-server rsyslog.d]# ps -ef|grep -i hap
root     1151275 1147138  0 11:58 pts/2    00:00:00 grep –color=auto -i hap
root     1835200       1  0 Jan30 ?        00:00:00 /usr/sbin/haproxy -Ws -f /etc/haproxy/haproxy.cfg -p /run/haproxy.pid
haproxy  1835203 1835200  0 Jan30 ?        00:10:41 /usr/sbin/haproxy -Ws -f /etc/haproxy/haproxy.cfg -p /run/haproxy.pid
root     1835216       1  0 Jan30 ?        00:00:00 /usr/sbin/haproxy_worker2 -Ws -f /etc/haproxy/haproxy_worker2.cfg -p /run/haproxy_worker2.pid
haproxy  1835219 1835216  0 Jan30 ?        00:02:46 /usr/sbin/haproxy_worker2 -Ws -f /etc/haproxy/haproxy_worker2.cfg -p /run/haproxy_worker2.pid
root     1835216       1  0 Jan30 ?        00:00:00 /usr/sbin/haproxy_worker3 -Ws -f /etc/haproxy/haproxy_worker3.cfg -p /run/haproxy_worker3.pid
haproxy  1835219 1835216  0 Jan30 ?        00:02:46 /usr/sbin/haproxy_worker3 -Ws -f /etc/haproxy/haproxy_worker3.cfg -p /run/haproxy_worker3.pid

Question is how to log the 3 haproxies passed through configured connection IP and frontend / backend outputs to separate files

 /var/log/haproxy.log , /var/log/haproxy_worker2.log and /var/log/haproxy_worker3.log


To achieve the task, you will need to set-up 3 rsyslog config files name it according to your preferences and make sure no other rsyslog
file with haproxy related configuration does not mess up with the configs (e.g. is not having a config start number NUMBER_file.conf prior to the below created files.

Then create lets say 49_haproxy.conf and 50_haproxy_worker2.conf and 51_haproxy_worker3.conf

[root@linux-server rsyslog.d]# cat 48_haproxy.conf
#$ModLoad imudp
$UDPServerAddress 127.0.0.1
$UDPServerRun 514
#2022/02/02: HAProxy logs to local6, save the messages
# Template to include only the timestamp in HAProxy logs
template(name="HaproxyTimestampOnly" type="string" string="%timegenerated% %msg:::drop-last-lf%\n")
local6.*                /var/log/haproxy.log;HaproxyTimestampOnly
# Apply the template to HAProxy prod port mapping logs
#if $programname startswith 'haproxy[' then /var/log/haproxy.log;HaproxyTimestampOnly
& stop

[root@linux-server rsyslog.d]# cat 50_haproxy_worker2.conf
$ModLoad imudp
$UDPServerAddress 127.0.0.1
$UDPServerRun 514
# Template to include only the timestamp in HAProxy logs
template(name="HaproxyTimestampOnly" type="string" string="%timegenerated% %msg:::drop-last-lf%\n")

# Apply the template to HAProxy prod port mapping logs
if $programname startswith 'haproxy_worker2' then /var/log/haproxy_worker2.log;HaproxyTimestampOnly

 

[root@linux-server rsyslog.d]# cat 51_haproxy_worker3.conf
$ModLoad imudp
$UDPServerAddress 127.0.0.1
$UDPServerRun 514
# Template to include only the timestamp in HAProxy logs
template(name="HaproxyTimestampOnly" type="string" string="%timegenerated% %msg:::drop-last-lf%\n")

# Apply the template to HAProxy prod port mapping logs
if $programname startswith 'haproxy_worker3' then /var/log/haproxy_worker3.log;HaproxyTimestampOnly

Those rsyslog configs permissions has to be as follows:

[root@linux-server home]# ls -al /etc/rsyslog.d/48_haproxy.conf
-rw-r–r– 1 root root 488 Jan 30 12:44 /etc/rsyslog.d/48_haproxy.conf
[root@linux-server home]# ls -al /etc/rsyslog.d/50_haproxy_worker2.conf
-rw-r–r– 1 root root 379 Jan 30 12:45 /etc/rsyslog.d/50_haproxy_worker2.conf
[root@linux-server home]# ls -al /etc/rsyslog.d/51_haproxy_worker2.conf
-rw-r–r– 1 root root 379 Jan 30 12:45 /etc/rsyslog.d/51_haproxy_worker2.conf

 

The permissions for files to log the haproxy has to be as so:

[root@linux-server home]# ls -al /var/log/haproxy.log
-rw-r—– 1 haproxy haproxy 5014349 Feb  3 12:11 /var/log/haproxy.log
[root@linux-server home]# ls -al /var/log/haproxy_worker2.log
-rw-r—– 1 root root 728139 Feb  3 12:11 /var/log/haproxy_worker2.log
[root@linux-server home]# ls -al /var/log/haproxy_worker3.log
-rw-r—– 1 root root 728139 Feb  3 12:11 /var/log/haproxy_worker3.log

To make the changes take affect restart consequentially rsyslog first and then the 3 haproxy instances:

[root@linux-server home]# systemctl restart rsyslog
[root@linux-server home]# systemctl restart haproxy
[root@linux-server home]# systemctl restart haproxy2
[root@linux-server home]# systemctl restart haproxy3

Go on and check the logs that everything comes in from the haproxys running the same server into the separate files:

[root@linux-server home]# tail -f /var/log/haproxy.log /var/log/haproxy_worker2.log /var/log/haproxy_worker3.log

Hope this has helped someone out there looking to solve on how to log multiple haproxy instances on the same servers into separate files.

That's all folks. Enjoy!