introduction
In a CloudForms or ManageIQ cluster, you can manage any of the server roles through any of the clustered appliances that have the UI role enabled. In 4.2, this is done by selecting the username|servername icon in the top right, selecting "configuration", selecting the appropriate server, and selecting the various roles in the "Server Control" section. Occasionally, however, you will run into a situation where there is no UI enabled. Generally this happens in a standalone server where someone has inadvertently deselected the "User Interface" role. It is, of course, possible to add an additional appliance to the cluster and manage the other appliances through that UI, but there is also a simple, if not immediately intuitive, method of achieving this via the command line. This was a little bit tricky to sort out, so first and foremost I'd like to thank Jason Frey, Joe Rafaniello, Martin Hradil, and Deric Crago for their contributions to this.
what we're after
We have a standalone appliance that has the UI role disabled, and we want to turn it back on from the command line. If you try to access the UI on such an appliance, you might be greeted with something like this:
the code
First let's start a session in the rails console. SSH into the appliance and execute the following:
#vmdb
#rails c
If you don't know about the vmdb alias, check out the post on aliases in CloudForms and ManageIQ.
The commands above navigate to the vmdb directory and start a session in the rails console respectively.
Now, let's find out which roles on the appliance are persistently enabled.
irb(main):001:0> MiqServer.my_server.assigned_role_names
This will return something like:
=> ["automate", "database_operations", "database_owner", "event", "reporting", "web_services", "websocket"]
Notice of course, that the UI role is conspicuously absent. The MiqServer.my_server object has a method named "set_config", and that's what we are going to use here. There are a couple ways to do this, but the easiest is to utilize the ability of .set_config to accept a sparse hash as an argument. The format looks like this:
irb(main):001:0> MiqServer.my_server.set_config(:server => {:role => "full,set,of,roles"})
So in our particular case, we take the list of roles that we got from the .assigned_role_names method and add the one we want, user_interface. Remember that the format is different, the .assigned_role_names returns a value in the ["value1", "value2", "value3"] format, and the role list in our hash argument is simply comma delimited. The exact syntax we want for our example is this:
irb(main):001:0> MiqServer.my_server.set_config(:server => {:role => "user_interface,automate,database_operations,database_owner,event,reporting,web_services,websocket"})
After a reasonable amount of testing, it doesn't appear that the order the roles are listed in the hash has any bearing on the result. If you execute the command correctly, you'll get a response containing the MiqServer id, guid, status, start time, etc. You may be tempted to check your work by executing .assigned_role_names again, but remember, this returns the persistent, active, roles, and your change won't take effect until a restart, so it won't show up yet in .assigned_role_names.
It's time to exit the rails console. You can do that by executing the following:
irb(main):001:0> quit
or
irb(main):001:0> exit
To implement the change, we need to bounce the service. We can do that two ways. The first is via systemd
#systemctl restart evmserverd
We could also do this via rake:
#vmdb
#rake evm:restart
Once the restart is complete, the most obvious way to check your work is to navigate to the appliance URL, which you will no doubt be eager to do so you can continue your adventures in datacenter management. Just to be thorough, however, we can also double check that the change was persistent in the rails console. You can do this by following the process above: start a session in the rails console and execute the .assigned_role_names method. You'll see your user_interface back in the game:
=> ["automate", "database_operations", "database_owner", "event", "reporting", "user_interface", "web_services", "websocket"]
some other things
While the most obvious use case for this is to enable the UI, you may want to enable other roles from the command line, and if that's the case, you need to know the values expected. Here is a list, in order, of the roles and the associated variables you would use in the set_config method:
Server Role |
Hash Value |
|---|---|
| Automation Engine | automate |
| Capacity & Utilization Coordinator | ems_metrics_coordinator |
| Capacity & Utilization Data Collector | ems_metrics_collector |
| Capacity & Utilization Data Processor | ems_metrics_processor |
| Database Operations | database_operations |
| Event Monitor | event |
| Git Repositories Owner | git_owner |
| Notifier | notifier |
| Provider Inventory | ems_inventory |
| Provider Operations | ems_operations |
| RHN Mirror | rhn_mirror |
| Reporting | reporting |
| Scheduler | scheduler |
| SmartProxy | smartproxy |
| SmartState Analysis | smartstate |
| User Interface | user_interface |
| Web Services | web_services |
| Websocket | websocket |
When I first started to address this task, my thoughts were to use something like the following:
irb(main):001:0> MiqServer.my_server.update_attributes(:role => "automate,database_operations,database_owner,event,reporting,scheduler,user_interface,web_services,websocket")
irb(main):002:0> MiqServer.my_server.save
But that didn't have the result I was hoping for, and the changes never took effect. If you're interesting in the conversation around this, you can follow it here. There's also a bugzilla on this topic you can read here.
If you're interested in playing around a little more with the rails console and seeing some other ways it is useful, you can always check out this chapter in Sir Peter McGowan's highly recommended book.