Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Check into possibility of eFa Container #40

Open
shawniverson opened this issue Jan 6, 2018 · 19 comments
Open

Check into possibility of eFa Container #40

shawniverson opened this issue Jan 6, 2018 · 19 comments

Comments

@shawniverson
Copy link
Member

E-F-A/v3#280

@Don-Swanson
Copy link

I just wanted to see if there has been any progress on this and if there is anything I can do to help? IE Testing, etc.

@shawniverson
Copy link
Member Author

eFa4 itself is not containerized yet, but it will run it its entirety inside an LXC container currently.

@jasgggit
Copy link
Contributor

eFa4 itself is not containerized yet, but it will run it its entirety inside an LXC container currently.
Hi Shawn,
I'm running it on a Hyper-V VM right now, but; i also want to explore some other options.
Care to explain how you are running it on a LXC container? , I assume that LXC is some how equivalent to Docker on Ubuntu platforms. I haven't read much about it, just some newsletters crossed my inbox and read the big letters.
So, time to spare, me of course, and if you the time to 'pseudo-code' it...
Appreciate all of your work.
Cheers.
JG

@shawniverson
Copy link
Member Author

LXC's are Linux Containers. If you know Docker, LXCs are similar. An easy way to use LXCs is to use something like Proxmox.

@Don-Swanson
Copy link

Problem is, I want to use this in a docker container so I can run it from inside one of my VPS Servers. I cannot spin up a sub-VM or LXC Container on my VPS

@Don-Swanson
Copy link

What are the file paths for data that needs to remain persistent?
If I have those, I might be able to cobble together a Docker Container for EFA.

@shawniverson
Copy link
Member Author

Give me a few I can help determine that. Mostly /var/spool/mailscanner/quarantine and the /etc/ configurations...

@Don-Swanson
Copy link

Sounds good, I appreciate it.

@Don-Swanson
Copy link

Just a friendly check in to see if you've had a chance yet to list out what needs persistence.

Thanks!

@shawniverson
Copy link
Member Author

Locations that may need persistence:

/var/spool/MailScanner (except incoming)
/var/spool/postfix
/var/lib/mysql
/var/eFa/backup
/var/www/html/mailscanner/temp
/var/log
/var/lib/spamassassin
/var/lib/clamav
/var/dcc

@Don-Swanson
Copy link

Thank you, I'll try and start working on that this weekend.
I'm also seeing some references in the config scripts to /etc locations, do any of those need to be persistent?

@shawniverson
Copy link
Member Author

/etc is pretty static and doesn't change much, so I guess it would depend on whether the container spawns the same config from the image or not. If not, then these would need to be persistent...

/etc/eFa
/etc/postfix
/etc/MailScanner
/etc/sysconfig/network-scripts
/etc/mail/spamassassin
/etc/opendkim
/etc/hosts
/etc/resolv.conf
/etc/passwd
/etc/shadow
/etc/opendmarc

There's probably others...I'll keep adding....

@Don-Swanson
Copy link

Anything that would be changed by the initial login config scripts and need to persist would be things I need to map to make persistent

@johnjore
Copy link
Contributor

Anything that would be changed by the initial login config scripts and need to persist would be things I need to map to make persistent

Hi! Did you get anywhere with this?

John

@Don-Swanson
Copy link

I have not had a chance to yet. The initial configuration script changes a lot of things that aren't applicable to containers (and sometimes breaks in a container) and I haven't had time with the new job to actually comb through it.

@johnjore
Copy link
Contributor

I've started the process with my initial PR. This only creates the container itself. Re-used existing build script. While it has commands that are not required, they cause no harm either. No volume redirect and startup script run inside the container. These are next steps...

@Don-Swanson
Copy link

One of the things I found (before life got in the way) was that some of the IP configuration part of the scrips fail inside the container, and the script claims to fail.

@johnjore
Copy link
Contributor

johnjore commented Aug 26, 2020

Well, my "start.sh" script makes "appropriate" changes to /usr/sbin/eFa-Commit so all the main configuration items now take place without crashing. Long term it would be good to move a few of the tweaks to the eFa-Commit script for a more "native" build, in the same way as LXC and various hypervisors have build exceptions, but this is better than nothing.

Edit: Improvements made
Versions

Even SSH loads up with eFa menu:
SSH

@johnjore
Copy link
Contributor

2nd PR submitted. As it launches, multiple people can concurrently submit PR's to fix the various bugs, there are a few.

Container is ready when it gets to this:

++++++++++++++++++++++++++++++++++++++++++++++++
+ Your E-F-A v4 container is now ready to use! +
++++++++++++++++++++++++++++++++++++++++++++++++

When stopping and starting the container, just issue start command multiple times, until the message above is displayed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants