Mass-setting the default view mode for cacti

Recently it came to my attention that many of BitFolk‘s customers were finding our Cacti install confusing. The main problem was that upon logging in they were confronted with the default graph view – the “Tree View” – and they didn’t understand where they might find the relevant graphs within this tree.

Experienced Cacti users will know that you can also click on the “List View” or “Preview View” to get a list or grid respectively of all graphs that they’re permitted to view, but most customers are not experienced Cacti users. For me personally, having permission to view some 1400 graphs I appreciate the tree view to enforce some order, but it’s not about me. Customers generally have 2-5 graphs to view.

I decided that I would set the default view for all users to be “Preview View”. Now I wasn’t going to click on every one of the hundreds of them in the web interface to set this, and I wasn’t going to send instructions to people on how to do it for themselves either. I decided to fiddle with the database directly. This turned out to be very simple, once you know how. Here’s how.

Danger, Will Robinson! ^

Firstly, don’t do this lightly. This worked with Cacti as present in Debian squeeze and I don’t believe the database schema has changed in ages, but maybe it has or maybe it will, so before you try this:

  • Take a backup of your cacti database. Just mysqldump it or whatever.
  • Check that the queries make sense. You might like to practice on just one user account before doing it on all.

Basically if you don’t understand what these queries do, don’t do them.

There are probably more elegant ways to do this, but it’s only going to be done once so I’m not going to try to optimise it.

Set “What to do when this user logs in” to “Show the default graph screen” ^

mysql> UPDATE user_auth SET login_opts=3;

Set “Which mode you want displayed when you visit ‘graph_view.php'” to “Preview View” for users who have graph settings already ^

If a user has changed their graph settings then they’ll have a row in the settings_graphs table for this particular setting already.

mysql> UPDATE settings_graphs SET value=3 WHERE name="default_view_mode";

Set “Which mode you want displayed when you visit ‘graph_view.php'” to “Preview View” for users with no graph settings ^

Most users won’t have changed their graph settings and so won’t have a row for this. We’ll need to insert one.

mysql> INSERT IGNORE INTO settings_graphs (user_id, name, value)
  SELECT id, "default_view_mode", 3 FROM user_auth;

The IGNORE is required because there will probably be some pre-existing rows from users who did have some graph settings.

You could probably combine the UPDATE and INSERT steps by using REPLACE instead.

That’s it ^

On next login, the user should be put directly at the “Preview View”. They can still change their settings to something different if they end up not liking that.

Too harsh on the recruiters?

I just rejected a recruiter’s job advert from the linuxjobs moderation queue because it had a useless subject line (“Job Posting”) and was in HTML. I requested that they repost with a useful subject line and in plain text.

They have just responded with:

Thanks for your email but apologies I don’t know what you mean by “plain text”!!

Their post wasn’t really against the rules of the list, so maybe I should have just approved it? Maybe them not being able to write a good ad is just their problem to work out between themselves and potential candidates?

Actually the only reason why I got the chance to moderate it was because they weren’t subscribed to the list. If they’d been subscribed then they would have been able to post with the useless subject and the HTML anyway. And I’d probably have just sighed at it and thought no more. So was it right to moderate it away?