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:

#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


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:

#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")


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.