block users during maintenance

[John Simonson]

How can I block users from accessing JIRA during maintenance, and still have administrative access?

[Wojciech Seliga · Accepted solution]

well, I would use e.g. Apache as a fronting web server. Then you could configure rules on Apache or even network interfaces (firewall) levels which allow only given IPs (that's the admin computers) to access it.

You could also have JIRA exposed on a few interfaces (Tomcat connectors) and make one known (and even physically accessible with network rules) just to admins.

With Apache you could probably easily configure an additional password protection for whole realm which only when given would let in traffic to fronted JIRA instance.

Finally you could termporarily deprive jira-users from logging in to JIRA by modyfing Global Permissions ("JIRA Users"). But then rememember to leave to yourself such rights. That would not prevent anonymous access though.

[John Simonson]

Thank you. I choose to follow your last suggestion, as it is the easiest to implement quickly.

For others needing a quick guide to this, go to "Administration > Users > Global Permissions", to the line "JIRA Users", and [Delete] all groups (first making a note of them all, so as to restore the permission after the maintenance is completed).

Any users or groups with the "JIRA System Administrators" and/or "JIRA Administrators" permission (on this same page) will still be able to login. I am assuming that I will coordinate the maintenance period with any other users in these groups to avoid any conflicts.

After maintenance is completed, [Add] the Permission "JIRA Users" to the groups you noted earlier.

ciao - John.

[JamieA]

The Apache way might not be the easiest to implement but it's by far the best. Removing global permissions will lead to permission denied error messages and disconcerted users.

[Gregory Sudderth]

I like the Apache way too because you can give folks a pacifier page.

[JamieA]

Exactly. And the other way, you do stuff with jira down, while explaining to people what's going on and when they can expect it back.

[John Simonson]

Thanks to all -

JIRA is used internally, and I can shut it down without impacting users too much (I just need to time it correctly)

• I send users a timely message ("in 1 hour JIRA will be down")
• disable "JIRA Users" permission
• stop the JIRA service (to force all users out of the system)
  BTW: is there a monitor function somewhere to see if anyone is still using JIRA??
• after a cooling-down period, restart JIRA
• perform maintenance
• enable "JIRA Users"
• send a message that it's up and running

This is off topic, but just to clarify my situation:

I'm going through all this because we are changing all usernames from one LDAP domain to another, and each user is changing credentials from "personnel-number" to "firstname-lastname", and there is no supported JIRA method to change usernames (IDs). So I will backup to XML, edit the XML, and restore the data.

This is primarily due to JIRA not conforming to normalized relational database. JIRA is not using the primary key [ID] of the Users table as foreign key into other tables, but using the [username], thus making it incredibly difficult to change the username without having to change umpteen other links. What happens when someone gets married and changes their name?

If I do need to do this in the future, however, I will definitely look into "port change and pacifier page".

Thanks again for all your feedback.

ciao - John

[Jerome Bleichenbacher]

We have AD-sync and I've just disabled the directory. Normal users but the admin have no access anymore. Bevor maintain your system make sure there is no open session (system - security - user sessions).

[Leirbag Assuab]

We have Jira Software and Service Desk. Just system administrators are in Jira internal directory. Agents, customers and "normal" software users are defined with AD-sync. So disabling synced directories stops access for everyone except Jira administrators.
I think is a quite good approach if you meet this sceneario, because you don't have to involve other administrators (servers, networking, ...) of your organization. It's also quick and simple.

[Gregory Sudderth]

Here's a country simple recipe from out in Oklahoma for maintenance:

• Shutdown
• Snapshot VM
• Backup DB / Home dir
• Change port and Base URL
• Do maintenance
• Shutdown/change port-n-URL back/startup

I do it this way because of multiple, overlapping goals of "fall back" and "might be extended maintenance", etc. Also, in the Apache example (Confluence/JIRA running on non-80 port) where the Apache is proxying, just shutdown the Apache. :) G.

[Jo-Anne MacLeod]

This is very similar to the method that I use as well, although I don't usually have a need to change the base url, just the port number.