appliance_console should be aware when running in a container

[bazulay]

the appliance_console cli is not fitted to a container,
basically it does all sorts of system administration operations and part of those are not relevant in a container, there for it needs to be container aware, and not to show the none relevant options.

The overview displayed initially

(taken from my env ... removed some details from my env )

Hostname: 43b6d5b76b4f
IP Address: 172.17.0.2
Netmask: 255.255.0.0
Gateway: 172.17.0.1
Primary DNS: -- removed --
Secondary DNS: -- removed ---
Search Order: -- removed --
MAC Address: -- removed --
Timezone: America/New_York
Local Database: running
CFME Database: postgres @ localhost
Database/Region: vmdb_production / 0
External Auth: not configured
CFME Version: 5.6.0.7-beta2.6
CFME Console: https://172.17.0.2

while displaying this data is o.k although some of the information is not relevant (e.g. the ip is internal), changing some of them may be a risk (to the host) or impossible (as the appliance_console crashes when trying to do so). keep in mind that we are still running a --privileged container which might have permissions to mess the host the container is running on

The appliance_console menu

1. Set DHCP Network Configuration
2. Set Static Network Configuration
3. Test Network Configuration
4. Set Hostname
5. Set Timezone
6. Set Date and Time
7. Restore Database From Backup
8. Configure Database
9. Extend Temporary Storage
10. Configure External Authentication (httpd)
11. Generate Custom Encryption Key
12. Harden Appliance Using SCAP Configuration
13. Stop EVM Server Processes
14. Start EVM Server Processes
15. Restart Appliance
16. Shut Down Appliance
17. Summary Information
18. Quit

1, 2, 3 should not appear in a container - as network is controlled externally to the container by the infrastructure (and the IP addresses shown are internal)
4 should be hidden - when changing it the appliance_console crashes (but succeeds changing the hostname for the container .. on next execution)
6 should be hidden - as it changes the host time as well
9 should be hidden - as it crashes the appliance_console , and parted is not installed at all (it is very risky to install it in a privileged container)
15 should be hidden - it only causes the container to stop and can't start it again (as this is controlled externally)
I'm not sure about #12

[fbladilo]

@bazulay @simaishi Agreed on options 1,2,3,4,6,9,15 to be hidden on the container appliance, I would like to test and ensure we have proper httpd mods for option 10.
I think it makes sense to include 12 , also have to check oscap-scanner is actually being pulled.

[gtanzillo]

@bazulay @fbladilo Is there an easy way to detect whether we're running inside a container?

[fbladilo]

@gtanzillo I've never found an official answer but I've seen these approaches:

Check existance of /.dockerenv or /.dockerinit files
Cgroup check "grep docker /proc/self/cgroup"

Probably a combination of them would be safer. I hope this helps.

[bazulay]

@gtanzillo @fbladilo

we can simply add a config value (in container build time) to any chosen config file something like "containerized=true/false" and the appliance console should pick it up on runtime.
This should be good enough + it will ease up testing for the developer , he can simply add this config manually and test the console.

about which config file to use, Greg just let us know where you want it , and we'll make it happen

[gtanzillo]

Would you be able to define an env variable at build time? Something like CONTAINERIZED_MIQ? That would be the easiest for us. But, if not, the file would work too.

[fbladilo]

@gtanzillo @bazulay we already set one on the current build

https://github.com/ManageIQ/manageiq/blob/master/Dockerfile#L2

Please keep in mind that we add this ourselves, my comment above referred to other options that are automatically provided by docker (not set by the image author).

[bazulay]

@gtanzillo @fbladilo

Franco keep me honest here, but IIRC "ENV container docker" is only available on build time ?

[fbladilo]

@gtanzillo @bazulay
Barak, ENV is available during build-time and persist in run-time. Different case for ARGs which are only available at build-time.

[fbladilo]

@gtanzillo @bazulay @simaishi @Fryguy

As I suspected, option 9 "Configure External Authentication (httpd)" is missing packages, will create a small PR to pull them in and refer to this issue. Take a look below :

Configure External Authentication (httpd)

ipa-client RPM is not installed
sssd-dbus RPM is not installed

Appliance Installation is not valid for enabling External Authentication

External Authentication configuration failed!

EDIT : These two RPMs bring a lot of deps with them, 82MB of packages added to the image 😞

[simaishi]

@fbladilo FYI, there are two dozens or so packages not included in Dockerfile, but included in kickstart. We'll need to go through others and identify what else is needed.. #8561

[fbladilo]

@simaishi good call, I'll start a review and post in #8561 for discussion.

[fbladilo]

@gtanzillo @bazulay @kbrock I believe in the container environment detection options are :

1. Author supplied environmental variable (already in place)
2. Author created config file
3. Docker supplied .dockerenv or .dockerinit
4. Cgroup check for docker

I'm inclined for 1,2 because we can ensure they are there, 3 and 4 are in Docker area and subject to change (although I hardly see 4 changing) . Thoughts?

[bazulay]

@fbladilo @kbrock @gtanzillo

I agree that either 1 or 2 are the best for this case.
kbrock - if you prefer #2 above than please let us know so we'll submit a PR to cover that (and which file do you prefer using for this purpose). in case you prefer #1 than you are good to go.

[kbrock]

I lean towards 1, but we do tend to have all env variables defined in /etc/defaults/evm
Not sure if that scheme is relevant in the Docker world.

Is the env lowercase "container" a standard out there for docker?
Kinda wish it were a little more bash env friendly like "DOCKER_CONTAINER" or something.
But I guess it is what it is.

[jvlcek]

I agree option 1, "Author supplied env variable (already in place)"

I'd also like to confirm what options should be exposed for now on a container.
We can change this as functionality changes, e.g. add 10 back once supported.

Do we want to allow the user to set the timezone?

1) Set DHCP Network Configuration
2) Set Static Network Configuration
3) Test Network Configuration
4) Set Hostname
5) Set Timezone
6) Set Date and Time
7) Restore Database From Backup
8) Configure Database
9) Extend Temporary Storage
10) Configure External Authentication (httpd)
11) Generate Custom Encryption Key
12) Harden Appliance Using SCAP Configuration
13) Stop EVM Server Processes
14) Start EVM Server Processes
15) Restart Appliance
16) Shut Down Appliance
17) Summary Information
18) Quit

[bazulay]

@fbladilo @kbrock @Fryguy
We can do whatever you think fit (both functionality & project wise),
We can do boath - add DOCKER_CONTAINER as environment variable & to /etc/defaults/evm.
But if the console loads the /etc/defaults/evm anyway than it seem that the env variable is redundant.
Your call.

[kbrock]

@jvlcek I like your list. Think Timezone: no but @bazulay would be better reference for that

[bazulay]

Timezone can stay as it does not effect the host the container is running on.

[simaishi]

Please note:

8. Configure Database -> 1) Create Internal Database will cause appliance_console to crash (Missing 'parted' package causes appliance_console to crash in Docker container #8587).

So for the top menus we want to keep for the container, the sub-menus will need to be looked at.

[fbladilo]

@bazulay @kbrock @jvlcek

I'm seeing a slightly different list for appliance_console in manageiq:latest DH image, was your list from the CFME build?

Advanced Setting

1. Set DHCP Network Configuration
2. Set Static Network Configuration
3. Test Network Configuration
4. Set Hostname
5. Set Timezone
6. Set Date and Time
7. Restore Database From Backup
8. Configure Database
9. Configure External Authentication (httpd)
10. Update External Authentication Options
11. Generate Custom Encryption Key
12. Stop EVM Server Processes
13. Start EVM Server Processes
14. Restart Appliance
15. Shut Down Appliance
16. Summary Information
17. Quit

Choose the advanced setting:

Option "extend temporary storage" is not there but there is an extra "update external auth options".

[fbladilo]

@kbrock @bazulay @jvlcek

I like the idea of having all MIQ env variables consistently contained in /etc/default/evm, instead of using docker ENV. I can submit a small PR that injects CONTAINER=true via Dockerfile just like we have others such as APPLIANCE=true. Thoughts?

[jvlcek]

@fbladilo That's fine with me too.

[jvlcek]

@fbladilo The menu upstream (MiQ) and downstream (CFME) are different.

[jvlcek]

@bazulay Should this be closed now that #9136 has been merged?

[bazulay]

@jvlcek @fbladilo
As far as I'm concerned this issue is handled and can be closed,
In case an issue comes up with one of the sub menus than a separate issue should be opened.

[jvlcek]

@fbladilo @bazulay @gtanzillo Seem I don't have the privs to close this. Can one of you please close it?

[gtanzillo]

Closing since this is addressed by #9136