Nick Howitt wrote:

You can't really disable the firewall. It is too integrated in ClearOS. You may be able to hack the start up file, /usr/lib/systemd/system/firewall.service, but the file will get updated every time the firewall updates. Alternatively you could override the file by creating an overriding file somewhere in /etc/systemd/system, but you'll have to google it.

I have done something else:
In the files /usr/libexec/firewall/exec-stop.sh and exec-start.sh I commented out the lines with firewall_stop and firewall_start.

So the command does nothing when systemctl restart firewall is called...

For me that is fine, as I just have to remember to execute that commands when the server restart...

Thanks Nick.

I'll give it a try next week-end...

You can't really disable the firewall. It is too integrated in ClearOS. You may be able to hack the start up file, /usr/lib/systemd/system/firewall.service, but the file will get updated every time the firewall updates. Alternatively you could override the file by creating an overriding file somewhere in /etc/systemd/system, but you'll have to google it.

I have a question: I have the Firewall disabled in my ClearOS because I don't need it, my ClearOS Server is in a safe environment and the firewall is provided by a dedicated hardware firewall.
I've installed docker and everything is running fine until iptables are reloaded somehow and all the docker rules are cleared. I then have to restart docker to let it create all the rules.

But why? How can I disable the reload and the clearing of the iptable rules by ClearOS?

Docker and ClearOS7 with a firewall do not play well together. For your container you need to start docker at the command line then snapshot the firewall (both the filter and nat tables). Then flip "DOCKER_NETWORK_OPTIONS='--iptables=false'" to true and start your container. Then snapshot the firewall again. Then do a diff of the firewall snapshots. All the extra rules you need to add by hand, but I take a short cut and done add a bunch of individual port rules if I can do it for a whole IP. then edit the following to make your required rules work permanently:

#!/bin/bash



function get_firewall_rules()

{

    ${IPTABLES} -nv --line-numbers -t $1 -L $2 | grep $ClearglassIF | awk '{ print $1 }' | sort -rn

}



function delete_firewall_rules()

{

    for chain in $2; do

        RULE_IDS=$(get_firewall_rules $1 $2)

        [ -z "$RULE_IDS" ] && continue



        for rule_id in $RULE_IDS; do

            ${IPTABLES} -t $1 -D $2 ${rule_id}

        done

    done

}



function clear_stale_rules()

{

    # filter table



    table='filter'

    CHAINS="INPUT FORWARD OUTPUT DOCKER DOCKER-ISOLATION"

    for chain in $CHAINS; do

        delete_firewall_rules ${table} ${chain}

    done        



    # nat table



    table='nat'

    CHAINS="POSTROUTING DOCKER"

    for chain in $CHAINS; do

        delete_firewall_rules ${table} ${chain}

    done

}



# Check firewall flag

#--------------------



RUN_HOOK='yes'



if [ -e /etc/clearos/docker.conf ]; then

    CHECK=$(grep -i '^enable_firewall[[:space:]]*=[[:space:]]*no' /etc/clearos/docker.conf 2>/dev/null)

    if [ -n "$CHECK" ]; then

        RUN_HOOK='no'

    fi

fi



# Firewall hook

#--------------



if [ "$RUN_HOOK" == 'yes' ]; then



    # Check the state file exists; if not, initialise the file/parameter

    CHECK=$(grep '^clearglass_interface' /var/clearos/clearglass_community/clearglass.state 2>/dev/null)

    if [ -z "$CHECK" ]; then

        echo 'clearglass_interface = ' >> /var/clearos/clearglass_community/clearglass.state

    fi



    # Check if $IPTABLES is set. This allows the program to run outside control of the firewall.

    # i.e on Clearglass start. If running under firewall control, rules would already be cleared

    #-------------------------------------------------------------------------------------------

    if [ -z "$IPTABLES" ] ; then

        IPTABLES='/usr/sbin/iptables -w'

        FW_PROTO='ipv4'

        ClearglassIF=$(grep '^clearglass_interface' /var/clearos/clearglass_community/clearglass.state | awk '{ print $3 }')

        if [ -n "$ClearglassIF" ]; then

            clear_stale_rules

        fi

    fi



    # This will bail if the script runs as part of the firewall restart and is not ipv4

    if [ "$FW_PROTO" != 'ipv4' ]; then

        return 0

    fi



    sed -i -e 's/^clearglass_interface.*/clearglass_interface = /g' /var/clearos/clearglass_community/clearglass.state

	

    # Now only run if Clearglass is running

    #--------------------------------------

    ps aux | grep clearglass | grep python > /dev/null

    if [ $? -eq 0 ]; then

        # Loop for MaxAttempts retries at 1s interval waiting for the interface to appear

        #--------------------------------------------------------------------------------

        MaxAttempts=60

        counter=1

        while [ $counter -le $MaxAttempts ]; do

            ClearglassNetworkID=$(/usr/bin/docker inspect 'clearglass_ui_1' --format '{{ .NetworkSettings.Networks.clearglass_default.NetworkID }}' 2>/dev/null)

            NewClearglassIF=$(echo 'br-'${ClearglassNetworkID:0:12})

            if [ ${#NewClearglassIF} -ne 15 ]; then    

                ((counter++))

                sleep 1

            else

                # Interface is up. Now add firewall rules

                #----------------------------------------

                ClearglassNetwork=$(ip route | grep $NewClearglassIF | awk '{ print $1 }')

                ${IPTABLES} -A INPUT -i $NewClearglassIF -j ACCEPT

                ${IPTABLES} -A FORWARD -o $NewClearglassIF -j DOCKER

                ${IPTABLES} -A FORWARD -i $NewClearglassIF -j ACCEPT

                ${IPTABLES} -A OUTPUT -o $NewClearglassIF -j ACCEPT

                ${IPTABLES} -A DOCKER-ISOLATION -i $NewClearglassIF -o docker0 -j DROP

                ${IPTABLES} -A DOCKER-ISOLATION -i docker0 -o $NewClearglassIF -j DROP

                ${IPTABLES} -A POSTROUTING -t nat ! -o $NewClearglassIF -s $ClearglassNetwork -j MASQUERADE

                ${IPTABLES} -A DOCKER -t nat -i $NewClearglassIF -j RETURN

                sed -i -e "s/^clearglass_interface.*/clearglass_interface = $NewClearglassIF/g" /var/clearos/clearglass_community/clearglass.state

                logger -t ClearGLASS "Interface came up in $counter seconds."

                break

            fi

        done

        if [ ${#NewClearglassIF} -ne 15 ]; then    

            logger -t ClearGLASS "Interface not up in $MaxAttempts seconds. Consider raising MaxAttempts in /etc/clearos/firewall.d/20-clearglass"

        fi

        

    fi

fi

This is the clearglass firewall script. It can be massively simplified as in section 13 here if you're happy to accept some approximations. Save the file in /etc/clearos/firewall.d with name starting with a number > 10. Remember to flip back the earlier preference you changed.

PiHole may be an issue because of how dnsmasq is integrated into ClearOS. I don't think it is easy to make pihole bind to a different port as it would be simple to make dnsmasq then use pihole. As an alternative you could force dnsmasq to bind to a different port allowing pihole to bind to 53.

Hi,

I just found this post as I was trying to set up a pyhole container under Clearos 7 (my gateway) to save a raspberry for some other testing.
I changed the dnsmasq 53 port to another one as I do not intend to use Clearos dns.
I faced the iptables 'refreshing' rules that wipout totally the docker rules.
I tried to create a service for docker to start after all CLerOS services but with no luck.

What is the latest on docker support for Clearos?
Is the only workaround still to disable iptable under docker and then build the rules manually? Do you do that in the iptable-local file manually or via the GUI interface?

Thanks

Reading this post, still running in a issue with network bridges. All tips from Nick and Marcel are in place except additional routing.

My situation: Base host is ClearOs 7 up-to-date which also runs virtualbox 6. Within Virtualbox I have multiple ClearOS images running, all for a different purpose. This way I can experiment and backup each individual machine. Very Handy in my opinion.

Currently experimenting with docker in a ClearOS guest (via Virtualbox) which is hosted on Clearos. Everything in the guest is working as desired and the docker app (home-assistant) is running without clear problems but without a bridge to the guest machine (and therefor not accessable in house via the local network).

Goal is to access a service via 192.168.1.60:8123 which runs inside the docker

My current output

[root@HomeAssistant ~]# ifconfig
docker0: flags=4099<UP,BROADCAST,MULTICAST> mtu 1500
inet 172.17.0.1 netmask 255.255.0.0 broadcast 0.0.0.0
inet6 fe80::42:c6ff:fe13:a913 prefixlen 64 scopeid 0x20<link>
ether 02:42:c6:13:a9:13 txqueuelen 0 (Ethernet)
RX packets 1 bytes 76 (76.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 3 bytes 266 (266.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

enp0s3: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.1.60 netmask 255.255.255.0 broadcast 192.168.1.255
inet6 fe80::a00:27ff:fe38:23b5 prefixlen 64 scopeid 0x20<link>
ether 08:00:27:38:23:b5 txqueuelen 1000 (Ethernet)
RX packets 464269 bytes 53550456 (51.0 MiB)
RX errors 0 dropped 64688 overruns 0 frame 0
TX packets 1824 bytes 218623 (213.4 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536
inet 127.0.0.1 netmask 255.0.0.0
inet6 ::1 prefixlen 128 scopeid 0x10<host>
loop txqueuelen 1000 (Local Loopback)
RX packets 0 bytes 0 (0.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 0 bytes 0 (0.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

/etc/sysconfig/network-scripts/ifcfg-docker0

DEVICE=docker0
TYPE="Bridge"
ONBOOT="yes"
USERCTL="no"
BOOTPROTO="none"


#/etc/sysconfig/docker-network
# DOCKER_NETWORK_OPTIONS=

[root@homeassistant ~]# docker network list
NETWORK ID NAME DRIVER SCOPE
6ffb64e7a8f5 bridge bridge local
7fd540cf9587 host host local
c2b714bc3985 none null local

[root@homeassistant ~]# docker inspect 6ffb64e7a8f5 7fd540cf9587 c2b714bc3985
[
{
"Name": "bridge",
"Id": "6ffb64e7a8f50f7a07609cae340a0d5637de46b7e63ed3b9aaf5d16ebe93feaa",
"Created": "2019-09-05T09:21:35.492594968-04:00",
"Scope": "local",
"Driver": "bridge",
"EnableIPv6": false,
"IPAM": {
"Driver": "default",
"Options": null,
"Config": [
{
"Subnet": "172.17.0.0/16",
"Gateway": "172.17.0.1"
}
]
},
"Internal": false,
"Attachable": false,
"Containers": {},
"Options": {
"com.docker.network.bridge.default_bridge": "true",
"com.docker.network.bridge.enable_icc": "true",
"com.docker.network.bridge.enable_ip_masquerade": "true",
"com.docker.network.bridge.host_binding_ipv4": "0.0.0.0",
"com.docker.network.bridge.name": "docker0",
"com.docker.network.driver.mtu": "1500"
},
"Labels": {}
},
{
"Name": "host",
"Id": "7fd540cf95871450915b183027f6a19cc536eb2389f55519657798a18b8ab0e2",
"Created": "2019-09-05T07:50:55.669692505-04:00",
"Scope": "local",
"Driver": "host",
"EnableIPv6": false,
"IPAM": {
"Driver": "default",
"Options": null,
"Config": []
},
"Internal": false,
"Attachable": false,
"Containers": {
"8f1baedbf1dfb865bb66b9f63b99da049c936681fdf9bc7ad288778257e40668": {
"Name": "home-assistant",
"EndpointID": "d506bed287d16ac981b68adfff57a9d768f6dccb56bd46f089db71ceeb117047",
"MacAddress": "",
"IPv4Address": "",
"IPv6Address": ""
}
},
"Options": {},
"Labels": {}
},
{
"Name": "none",
"Id": "c2b714bc3985468e254dd07f36d65fbb54a486265004bdd3cf22a50adc8025a1",
"Created": "2019-09-05T07:50:55.645840665-04:00",
"Scope": "local",
"Driver": "null",
"EnableIPv6": false,
"IPAM": {
"Driver": "default",
"Options": null,
"Config": []
},
"Internal": false,
"Attachable": false,
"Containers": {},
"Options": {},
"Labels": {}
}
]

Any idea what is causing this ?

To find docker container IP's, try section 11 in this post. For a permanent firewall see section 12 in the same post. Don't be tempted to Use a custom firewall rule for a couple of reasons:
1 - Custom rules are run before 10-docker so the DOCKER chain will not exist when your custom rule is added causing it to fail.
2 - The Custom Firewall rules do not allow a "!" for the moment. There is a patch just going through at the moment to allow it, but see 1 which is the most important.

The containers can communicate with each other!

What I did is what nick suggested, and I made snapshots of the different states. I did this with:

iptables -nvL

iptables -nvL -t nat

So I'll found the ip addresses of the containers.

172.17.0.2

172.17.0.3

I made a rule:

 

ptables -A DOCKER -t nat ! -i docker0 -d 172.17.0.2 -j DNAT --to-destination 172.17.0.3

So container with ip address 172.17.0.2 can now communicate with the container with ip address 172.17.0.3. if I use ip address 172.17.0.3 to connect to in the webapp everything works.

I'm not finished yet I still have to make it permanent so the rules survive a reboot.

For the firewall:

iptables -nvL

iptables -nvL -t nat

I'd be particularly curious with the DOCKER-ISOLATION chain.

I'd suggest:
rebooting (with the docker0 interface)
snapshot the firewall
start docker with iptables enabled
snapshot the firewall
start your containers, each time snapshotting the firewall
look for the differences in the firewalls between each stage.

I'm not going to be able to do much for a few days now, I'm afraid.

You mean commenting out "DOCKER_NETWORK_OPTIONS='--iptables=false'"? The "iptables='false' part was missing in my "docker-network"file. So that was already the case. If I add "DOCKER_NETWORK_OPTIONS='--iptables=false' then I can't connect to the Docker containers via the web browser anymore. I tried different options also rebuilding and restarting my containers. Also rebooted the server to be sure.

Can you give me a hint how to check the firewall rules? Not a expert here.

Try commenting out the line, stopping any containers you have running, restarting the firewall, restart docker then your containers and then, if the containers are communicating, have a look at what firewall rules you have, including in the nat table.

Mine is:

# /etc/sysconfig/docker-network

DOCKER_NETWORK_OPTIONS='--iptables=false'

Commenting it out then starting docker meant I got the iptables rules which I could then emulate manually.

I'm afraid I don't have a lot of knowledge of docker. Just what I've learned from playing with the samba container and what I've heard about the ClearGLASS set up.

Nick Howitt wrote:

OK. Some misinformation there. I've found my notes and have pointed you in the wrong direction. Try instead /etc/sysconfig/docker-network. Just comment out the line to enable auto-generation of the rules.

Setting up docker0 only helps a boot condition. If you restart the firewall after starting docker the effect is the same but not so clean.

Oke, this are the two line I have in "docker-nertwork".

#/etc/sysconfig/docker-network

DOCKER_NETWORK_OPTIONS=

If I do a Docker inspect of a container I see it uses the Docker interface:

 "SandboxKey": "/var/run/docker/netns/1eca0661c6e7",

            "SecondaryIPAddresses": null,

            "SecondaryIPv6Addresses": null,

            "EndpointID": "f0b77db9e738adf9477f3e2246a40bb7f03cf73b1ac4d3ffa97f1767f7c146cf",

            "Gateway": "172.17.0.1",

            "GlobalIPv6Address": "",

            "GlobalIPv6PrefixLen": 0,

            "IPAddress": "172.17.0.2",

            "IPPrefixLen": 16,

            "IPv6Gateway": "",

            "MacAddress": "xx:xx:xx:xx:xx:xx",

            "Networks": {

                "bridge": {

                    "IPAMConfig": null,

                    "Links": null,

                    "Aliases": null,

                    "NetworkID": "eb526cd22646bc270899ffb9797e05d27f6e9425a14b53b71682aa8863e0667f",

                    "EndpointID": "f0b77db9e738adf9477f3e2246a40bb7f03cf73b1ac4d3ffa97f1767f7c146cf",

                    "Gateway": "172.17.0.1",

                    "IPAddress": "172.17.0.2",

                    "IPPrefixLen": 16,

                    "IPv6Gateway": "",

                    "GlobalIPv6Address": "",

                    "GlobalIPv6PrefixLen": 0,

                    "MacAddress": "xx:xx:xx:xx:xx:xx"

OK. Some misinformation there. I've found my notes and have pointed you in the wrong direction. Try instead /etc/sysconfig/docker-network. Just comment out the line to enable auto-generation of the rules.

Setting up docker0 only helps a boot condition. If you restart the firewall after starting docker the effect is the same but not so clean.

but I believe iptables is disabled for docker in the ClearOS installation

What do you mean? ClearOS servers with Docker installations have no iptables active? Let's hope not. I expect that I do misunderstand you.

see /etc/clearos/docker.conf

I don't have that file.

Also, until you start docker, there is no docker0 interface. There is a bug request for this which you can do yourself.

I tried this, but Docker containers still can't communicate with each other. The interface is created though:

4: docker0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000

link/ether 0a:be:e4:b2:60:14 brd ff:ff:ff:ff:ff:ff

inet 172.17.0.1/16 scope global docker0

valid_lft forever preferred_lft forever

inet6 fe80::f4c0:90ff:fe6e:6a2d/64 scope link

valid_lft forever preferred_lft forever

Iptables is a big issue with docker. I'd need to do a fresh installation to check, but I believe iptables is disabled for docker in the ClearOS installation - see /etc/clearos/docker.conf. Also, until you start docker, there is no docker0 interface. There is a bug request for this which you can do yourself. Just create a file /etc/sysconfig/network-scripts/ifcfg-docker0 and in it put:

DEVICE=docker0

TYPE="Bridge"

ONBOOT="yes"

USERCTL="no"

BOOTPROTO="none"

Then the interface is there at boot and docker will take control of it when it starts.

The problem with iptables is more serious. ClearOS, when it restarts the firewall wipes iptables and it does not recreate the docker container rules. If iptables is turned on in docker, docker containers will do that only if restarted and this is not optimal.

As docker is only on ClearOS for ClearGLASS, there is a /etc/clearos/firewall-d/10-docker file (from app-docker) which runs on firewall restart which creates all the firewall rules needed by docker and the ClearGLASS containers. Really this needs to be split into docker rules and ClearGLASS rules.

What I did for Samba in Docker (see this post was to flip the /etc/clearos/docker.conf parameter and observe the firewall rules the samba container set up, then emulate them in my own /etc/clearos/firewall.d/11-docker-samba file, so they would be recreated every time the firewall reloaded. Then I flipped the /etc/clearos/docker.conf parameter off again.

As a slight shortcut, the samba container rules were very detailed with lots of rules for individual ports. I just combined them into a single rule for the docker internal IP.

It is also worth reading the thread I linked to, as docker tries to choose a free /16 subnet to work with, but does not always get it right and you can get IP clashes.

[edit]
You may also want to check the DOCKER-ISOLATION rules set up by /etc/clearos/firewall-d/10-docker as they could be working against you if you've got any br-* interfaces from your containers.
[/edit]

What I notice is that Docker containers can't communicate with each other. I think the reason is that we are using Docker on a gateway distro. So the problem iptables???? Is there a way to check if iptables is the problem. I'm not a iptables expert..





I strongly advice everyone to use Docker from the ClearOS repo!

yum install docker

Nick Howitt wrote:

Docker is now in the ClearOS repos so a simple:

yum install docker

should work. The only thing is that this is version 1.13.1-53.git774336d and is the latest official version for RHEL/Centos. If it gets hung up on installation for the same reason, libcgroup is available from clearos-centos or centos-verified so perhaps add:

--enable-repo=clearos-centos

to your yum command. If you permanently enable clearos-centos (which is OK), you should also permanently enable clearos-centos-updates.

You've cut you command line, but it looks like you are trying to install DockerCE which should also work (Peter Baldwin has it installed). Apply the same fix for libcgroup.

Thanks! It was actually totally my fault in the end. I thought I'd finished the installation, but had neglected to finish the setup by logging into the web interface and registering. Doh!

Docker is now in the ClearOS repos so a simple:

yum install docker

should work. The only thing is that this is version 1.13.1-53.git774336d and is the latest official version for RHEL/Centos. If it gets hung up on installation for the same reason, libcgroup is available from clearos-centos or centos-verified so perhaps add:

--enable-repo=clearos-centos

to your yum command. If you permanently enable clearos-centos (which is OK), you should also permanently enable clearos-centos-updates.

You've cut you command line, but it looks like you are trying to install DockerCE which should also work (Peter Baldwin has it installed). Apply the same fix for libcgroup.

Hi. I've followed this guide successfully a couple of times, but came to do so again yesterday and it failed with the following output:

Loaded plugins: clearcenter-marketplace, fastestmirror
ClearCenter Marketplace: fetching repositories...
ClearCenter Marketplace: System not registered. Code: 3
Loading mirror speeds from cached hostfile
* clearos: mirror1-newyork.clearos.com
* clearos-centos-sclo-rh: download1.clearsdn.com
* clearos-contribs: mirror1-newyork.clearos.com
* clearos-fast-updates: download1.clearsdn.com
* clearos-infra: mirror1-newyork.clearos.com
* clearos-updates: mirror1-newyork.clearos.com
dockerrepo | 2.9 kB 00:00
Package docker-engine is obsoleted by docker-ce, trying to install docker-ce-18.06.0.ce-3.el7.x86_64 instead
Resolving Dependencies
--> Running transaction check
---> Package docker-ce.x86_64 0:18.06.0.ce-3.el7 will be installed
--> Processing Dependency: container-selinux >= 2.9 for package: docker-ce-18.06.0.ce-3.el7.x86_64
--> Processing Dependency: libcgroup for package: docker-ce-18.06.0.ce-3.el7.x86_64
--> Processing Dependency: libltdl.so.7()(64bit) for package: docker-ce-18.06.0.ce-3.el7.x86_64
--> Running transaction check
---> Package container-selinux.noarch 2:2.42-1.gitad8f0f7.el7 will be installed
--> Processing Dependency: policycoreutils-python for package: 2:container-selinux-2.42-1.gitad8f0f7.el7.noarch
---> Package docker-ce.x86_64 0:18.06.0.ce-3.el7 will be installed
--> Processing Dependency: libcgroup for package: docker-ce-18.06.0.ce-3.el7.x86_64
--> Processing Dependency: libltdl.so.7()(64bit) for package: docker-ce-18.06.0.ce-3.el7.x86_64
--> Finished Dependency Resolution
Error: Package: docker-ce-18.06.0.ce-3.el7.x86_64 (docker-ce-stable)
Requires: libltdl.so.7()(64bit)
Error: Package: docker-ce-18.06.0.ce-3.el7.x86_64 (docker-ce-stable)
Requires: libcgroup
Error: Package: 2:container-selinux-2.42-1.gitad8f0f7.el7.noarch (clearos-updates)
Requires: policycoreutils-python
You could try using --skip-broken to work around the problem
You could try running: rpm -Va --nofiles --nodigest

Any idea what the problem might be? Thanks

Thanks Nick!

Also added a link in the first post.

Link to HowTo post

Jonathan Dumont wrote:

Hi everyone;

I try to find the HowTo Docker on ClearOS
and everything point here
but I just see a thread of discussion about how it will be great
and nothing look like a how to
such as
yum install docker ...

so Docker on ClearOS is working or not ?
which kind of issue is the most common ?
...

Regards!

Jonathan

Hi,

When you to bottom of the page you see a "Load more replies" button. Tick this and you can scroll down to the how-to.

Hi everyone;

I try to find the HowTo Docker on ClearOS
and everything point here
but I just see a thread of discussion about how it will be great
and nothing look like a how to
such as
yum install docker ...

so Docker on ClearOS is working or not ?
which kind of issue is the most common ?
...

Regards!

Jonathan

Hi,

If you go to the bottom of this thread you see a bar with the text "load more replies" tick that bar and you will see the how-to. It's the second post of this thread, but the newest post are displayed first. So that why it's at the bottom.

Marcel van Leeuwen wrote:

This thread also has a how-to guide how to install Docker on ClearOS 7.x. Please scroll down for the how-to.

Hi, please excuse me if I overlooked it it's very late here in California and I'm probably sleep typing but where is the 'how-to guide how to install Docker on ClearOS'? I've read this post and your other post about Docker many MANY times tonight looking for that guide/link and I can't seem to find it. I want to install ClearOS but I must have Docker comparability also. As interesting as ClearOS seems no Docker is an instant deal breaker for me as pretty much all my work/hobby stuff is exclusively Docker images and Containers. Since it appears that Docker engine has been solved by the fine folks here are there any plans for Docker Compose and Docker Swarm or any other Docker container orchestration?

Sorry to bother you with such a silly question about the link to the guide, any help/replies would be a huge help.

What is the status at the moment of the Docker app? At least I'm hoping it's coming.

T wrote:

systemd-nspawn is a major part of the future of systemd and I'd love to see a comparison between system resource usage of Docker vs nspawn. This is relevant as ClearOS will often be deployed as a router or a server on a LAN, and routers / servers don't want to be wasting what little grunt they've got on a containerisation system: all that grunt should be available to the services (containers) themselves.

It looks like I have more research to do!

Peter Baldwin wrote:

T wrote:Using a Container for a process has security advantages (as previously mentioned) but also it makes dependencies much cleaner. Rather than filling up your bare-metal installation with libraries only used by one or two processes, you can set up your bare-metal installation to only run the Containerisation system. Then each container can have the specific libraries it needs to run its process. This way you never have to try to resolve conflicts where Tool A requires Library v0.11 and Tool B requires Library v0.12 and you can't have both installed at the same time. Just put them in separate containers and they won't even know the other exists.

Though not relevant with Plex or Transmission, a lot of LAMP-based apps have different MySQL/PHP/Python requirements, and we're seeing more "nginx vs Apache" conflicts as well. Containers solve that versioning/conflict problem.

Fantastic - thanks for providing concrete examples of what I'd mentioned - that makes it easier for people to see real-world advantages and also provides test cases to show progress accomplished by containerisation.

Marcel van Leeuwen wrote:One thing I have to mention of LXC is that you can give containers a ip address...

That's the bare necessity for a container, no matter what system is implementing it. It allows the container's firewall to have only the port(s) relevant to its service open, simplifying maintenance.

systemd-networkd provides host-only, inter-container, and/or LAN-accessible IP address(es) for systemd-nspawn containers.

systemd-networkd is documented here: https://wiki.archlinux.org/index.php/systemd-networkd

systemd-nspawn is documented here: https://wiki.archlinux.org/index.php/Systemd-nspawn

systemd-nspawn is ready to go in RHEL/CentOS/etc. -like systems; here's an example on the latest Fedora 24: https://fedoramagazine.org/container-technologies-fedora-systemd-nspawn/

systemd-nspawn is also able to run converted Docker containers - something that's important because Docker doesn't like working with systemd particularly when a service relies on starting up multiple containers (eg mySQL and Apache):

the root cause of the conflict is that the Docker daemon is designed to take over a lot of the functions that systemd also performs for Linux.

Where this breaks down, however, is when services running as containers depend on other containerized services.

Systemd allows defining cgroup limits in the initialization files, so that you can define resource profiles for services when they start. With Docker, though, this runs afoul of the client-server model again. The systemd cgroup settings affect only the client; they do not affect the daemon process, where the container is actually running. Instead, each one inherits the cgroup settings of the Docker daemon.

Docker logs also didn't work with systemd's journald. Logging of container output was local to each container, which would cause all logs to be automatically erased whenever a container was deleted. This was a major failing in the eyes of security auditors.

Nspawn continues to be something the systemd team are actively growing and improving: systemd-importd "can download container images in tar, raw, qcow2 or dkr formats, and make them available locally in /var/lib/machines, so that they can run as nspawn containers"; can run in user namespace and overlay filesystems; management of CPU shares and other rescources; machinectl pull-tar for downloading prepackaged containers; additional and arbitrarily-named virtual Ethernet links between the host and the container; container-specific private UID/GID range for security and on-demand inter-container networks; mkosi generates a new raw OS image of a fresh distribution installation; GPT/EFI representation improved and containers inherit /etc/resolv.conf; etc. etc.

systemd-nspawn is a major part of the future of systemd and I'd love to see a comparison between system resource usage of Docker vs nspawn. This is relevant as ClearOS will often be deployed as a router or a server on a LAN, and routers / servers don't want to be wasting what little grunt they've got on a containerisation system: all that grunt should be available to the services (containers) themselves.

Hi Marcel,

Marcel van Leeuwen wrote:

I've searched the Docker site and found some documentation on how to build a Docker container. Also found a how-to on Digital Ocean. Which how-to do you use?

I'm still in the reading and learning stage... wild stuff. A developer over at Tiki Wiki did a proof of concept with Docker and ClearOS. He went as far as creating:

- A ClearOS Docker app
- Two apps via Docker containers: Openfire and MariaDB

The fact the Openfire and MariaDB are running in containers is seamless! I think I'll take a crack at creating a Docker image along with integrating an "official" docker image of some kind.

I've searched the Docker site and found some documentation on how to build a Docker container. Also found a how-to on Digital Ocean. Which how-to do you use?

Marcel van Leeuwen wrote:

I'm thinking of apps like SABnzbd, NZBGet, Plex, Autosub, Sonarr, Transmission.

I'll take a look at SABnzbd and NZBGet.

Hey Nick,

Nick Howitt wrote:

I have not read up on it, but what are the advantages of running Plex or Transmission in Docker compared to natively (like now)?

Though not relevant with Plex or Transmission, a lot of LAMP-based apps have different MySQL/PHP/Python requirements, and we're seeing more "nginx vs Apache" conflicts as well. Containers solve that versioning/conflict problem.

One thing I have to mention of LXC is that you can give containers a ip address...

Michael Proper wrote:

Would recommend we take a hard look at all of these before locking a default direction:

1) Kubernetes - https://kubernetes.io/

2) Google Container Engine - https://cloud.google.com/container-engine/

3) Docker - https://www.docker.com/

Feel free to add to the Tech Talk Agenda if needed.

Thank you all in advance!

I'm only a bit familiar with Docker and LXC. I tested Proxmox for a while and Proxmox uses LXC for containerisation. unRAID uses Docker. I will checkout the sites you linked.

Michael Proper wrote:Would recommend we take a hard look at all of these before locking a default direction:

Well this thread is specifically about Docker which is why I think the majority of the focus is (rightly) on Docker here. Using a Container for a process has security advantages (as previously mentioned) but also it makes dependencies much cleaner. Rather than filling up your bare-metal installation with libraries only used by one or two processes, you can set up your bare-metal installation to only run the Containerisation system. Then each container can have the specific libraries it needs to run its process. This way you never have to try to resolve conflicts where Tool A requires Library v0.11 and Tool B requires Library v0.12 and you can't have both installed at the same time. Just put them in separate containers and they won't even know the other exists.

But if you're willing to consider other (superior) Containerisation technologies, you can't go wrong with systemd-nspawn. It's baked into systemd so is migratable between CentOS, Ubuntu, etc. etc. everything that uses systemd. If /var/lib/machines is ZFS or BTRFS it's trivial to make filesystem snapshots of container states, etc. It's much more mature than Docker and far less complex to set up and use. "Rocket" (or "rkt") is a small, recent tool for interfacing with it, but don't judge nspawn by Rocket: nspawn is the way forward for as long as systemd will reign.

Would recommend we take a hard look at all of these before locking a default direction:

1) Kubernetes - https://kubernetes.io/

2) Google Container Engine - https://cloud.google.com/container-engine/

3) Docker - https://www.docker.com/

Feel free to add to the Tech Talk Agenda if needed.

Thank you all in advance!

Nick Howitt wrote:

I have not read up on it, but what are the advantages of running Plex or Transmission in Docker compared to natively (like now)?

Hi Nick,

Isolation of the app so a vulnerability in your app while not expose your whole server.