Console to Prompt


#1

Hi,

I am sure there are a number of key stroke combinations to get there, but in a RDP session to viClient, that has a console open to the MIQ Appliance its very difficult to get to the bash prompt of the appliance. I managed to by editing the boot parameters into single mode, then renaming the /var/www/miq/lib/appliance_console.rb so that when it reboots I get the prompt.

The issue was that I cloned the appliance in VMware, but for some reason the ETH0 would not come up, so needed to get into the OS to re-jig it.

Can we add to the appliance console menu and option to exit to prompt, obviously this should be the login prompt to get to bash shell?

thanks


#2

cc @kbrock Thought you might want to chime in here. Note this is a classic example of things that can go wrong and where having that appliance console virtual terminal access really shines.


#3

Hello Mr. @jhardy,

We would like to go away from our current login mechanism to using the standard linux username/password prompt. Our current prompt leverages the database password, which is cached on each machine in case the database is not available.

From here, we are trying to decide between 2 options:

  1. A “root” login for bash, an “admin” login for console.
  2. A “root” login into bash. Let the user type “appliance_console” to get the console.

We have made great technical strides and have a bunch of solutions, but we are faced with a number of questions.

Knowns:

  1. We do need a bash login.
  2. We do want the user to access the appliance_console.
  3. We can add a bash prompt in the console

Unknowns:

  1. Does the user tend to like the appliance console, or prefer a cli script?
  2. We were thinking about moving much of the computer setup functionality (create a database, edit database.yml files, …) into a separate webapp. What would need to be kept in the appliance console and command line.
  3. We like having network configuration in there, but we need to rewrite it for RHEL7. How much of the OS can we leverage here rather than reinventing their wheel?
  4. Do that many customers need static ip?

Concerns:

  1. Don’t want to sync admin’s password (stored in the database) with the linux password (stored in /etc/passed).
  2. Don’t want the user to have to remember yet another password. (So would prefer they be able to leverage the admin password)
  3. Don’t want the user to log into bash and unintentionally break the system.
  4. Don’t want to force the user into a bash prompt if that intimidates them.
  5. Don’t want to prevent the user from accessing the bash prompt when they need that power.
  6. Don’t want to force the users into leveraging IdM/IPA for syncing passwords.
  7. Don’t want to rewrite IdM.

Any thoughts to help us remove or reduce some of our concerns?

Thanks,
Keenan