Docker Image

[Starvirus]

Since OpenEFA is based on Ubuntu and also supports a minimal setup, a move to Docker wouldn't be a big leap. This is a feature I sorely missed in EFA, as it provides much more flexibility when it comes to deployment.

[Carl Brunning]

think it be a while before that can be done
not easy to do one that going to ask you to setup your ip then setup the domain and all the other setting that EFA need.
i may be wrong, but everytime i look at docker to learn to make my own i hate it lol

but am sure some one may do it a later date.
right now it be a while till OpenEFA is test and all bug removed

anyway one day it will happen not sure when

[johnjore]

Having an entire VM just for eFa is a bit of a pain, and having the ability to just spin up a new instance with existing configuration files if issues, or to upgrade, would be great, including the ability to point all the configuration files to git for easy roll-back and logging changes would be awesome.

I'm not a docker person, but I think the main issue with eFa and docker is that the config files are scattered all over the place. If it used links (or custom paths) for each config file to say

/config/servicename

and

/config

was mounted as a volume, it should be no different to spinning up a "normal" VM as the configuration would remain persistent, and no additional scripts etc needed to configure / setup the container.

Also, quite a few services use an

"include conf.d/"

folder for custom configurations that override the default setup. My eFA 5.x does not appear to use this, at least not the areas I probed, but if they did, it too should help the migration, by pointing each one to the /config/ folder and make changes there instead.

If this was done, one service at a time, over a few weeks / months, it wouldn't be that difficult to convert the current build script into a docker build script at the end.

I think? Or maybe I've over-simplified it?


Edit:
I "migrated" opendkim and opendmarc to use /config:

Code: Select all

ls -laFh /etc/opend*
lrwxrwxrwx. 1 root root   16 Nov 21 11:44 /etc/opendkim -> /config/opendkim/
lrwxrwxrwx. 1 root root   30 Nov 21 11:34 /etc/opendkim.conf -> /config/opendkim/opendkim.conf
-rw-r--r--. 1 root root 5.2K Jun 30  2024 /etc/opendkim.conf~
-rw-r--r--. 1 root root 5.2K Jun 28  2024 /etc/opendkim.conf.old
lrwxrwxrwx. 1 root root   18 Nov 21 11:49 /etc/opendmarc -> /config/opendmarc//
lrwxrwxrwx. 1 root root   32 Nov 21 11:34 /etc/opendmarc.conf -> /config/opendmarc/opendmarc.conf
-rw-r--r--. 1 root root  13K Jun 30  2024 /etc/opendmarc.conf~
-rw-r--r--. 1 root root  13K Jul  1  2024 /etc/opendmarc.conf.old

Services are still running after a reboot (I might have stuffed something up like permissions, but hopefully nothing major)

Code: Select all

 ps ax | grep opend
   1658 ?        Ssl    0:00 /usr/sbin/opendkim -f -x /etc/opendkim.conf
   1659 ?        Ssl    0:00 /usr/sbin/opendmarc -f -c /etc/opendmarc.conf

Next iteration could be to fiddle with /etc/sysconfig/opendkim:

Code: Select all

cat opendkim
# Set the necessary startup options
#OPTIONS="-x /etc/opendkim.conf"
OPTIONS="-x /config/opendkim/opendkim.conf"

# Set the default DKIM selector
DKIM_SELECTOR=default

# Set the default DKIM key location
#DKIM_KEYDIR=/etc/opendkim/keys
DKIM_KEYDIR=/config/opendkim/keys

Next step could then be to have each service running in different containers, but I think its better to do small incremental improvements, rather than a big-bang approach, especially when there isn't an abundance of resources to work on this.

None of this is cutting edge fancy stuff, just boring and a bit tedious. Happy to help out a little here, and a little there if PRs are accepted (in a timely fashion).