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.