starred/netbox
1
0
Fork 0
mirror of https://github.com/netbox-community/netbox.git synced 2026-01-11 21:10:29 +01:00
Code Issues 273 Packages Projects Releases 10 Wiki Activity

Maintenance mode prevents login #8800

New Issue
Closed
opened 2025-12-29 20:41:19 +01:00 by adam · 2 comments
adam commented 2025-12-29 20:41:19 +01:00
Owner
Copy Link

Originally created by @cpmills1975 on GitHub (Nov 1, 2023).

Originally assigned to: @abhi1693 on GitHub.

NetBox version

v3.6.4

Python version

3.9

Steps to Reproduce

This issue occurred this morning while I was attempting to upgrade my NetBox database from v3.2.8 to v3.6.4. Having fixed the issue, I'm reluctant to try and reproduce it but believe the following set of conditions led to an inability for ANY user, even super users, to log in.

As part of my upgrade plan, I needed to upgrade the underlying OS so I built a whole new VM and installed NetBox v3.6.4.

  • I enabled MAINTENANCE_MODE on the existing v3.2.8 instance using a config revision.
  • I dumped the database using pg_dump and moved it to the new box via scp (I actually wrote a bash script to do this).
  • I dropped the existing v3.6.4 database and imported the old data using psql and then ran the upgrade.sh process.
  • After starting the netbox and netbox-rq services, I visited the site and attempted to log in using my LDAP backed user account.
  • The login didn't fail, but I was immediately redirected back to the login page!
  • I've followed this process repeatedly over the last couple of weeks while updating and testing plugins and scripts etc - netbox v3.6.4 has been running on this VM for some weeks, automatically synced to the v3.2.8 instance using the above process every night and it has always worked. The only difference this morning was that the old instance was in maintenance mode prior to migrating the data.
  • Thinking that perhaps something was wrong with my LDAP auth, I created a local super user account (python netbox/manage.py createsuperuser). I was unable to log in with that account either.
  • Thinking that perhaps nginx was causing the redirect, I stopped nginx and ran the NetBox server directly (python netbox/manage.py runserver 0.0.0.0:8000). This did exactly the same, but I was able to see log messages saying that the last login date wasn't updated due to the application being in maintenance mode.
  • Because I couldn't log in, I couldn't change the config revision to disable MAINTENANCE_MODE so I added the option to the configuration.py file to override the contents of the config revision.
  • Having then restarted the application (systemctl restart netbox netbox-rq), I was then able to log in successfully using my LDAP account and delete the config revision from the database.

It appears that enabling maintenance mode in the config revision, prevented any user from logging in.

Expected Behavior

Users should be able to log in even when maintenance mode is enabled.

Observed Behavior

With maintenance mode enabled via a config revision, I was unable to log in at all.

Originally created by @cpmills1975 on GitHub (Nov 1, 2023). Originally assigned to: @abhi1693 on GitHub. ### NetBox version v3.6.4 ### Python version 3.9 ### Steps to Reproduce This issue occurred this morning while I was attempting to upgrade my NetBox database from v3.2.8 to v3.6.4. Having fixed the issue, I'm reluctant to try and reproduce it but believe the following set of conditions led to an inability for ANY user, even super users, to log in. As part of my upgrade plan, I needed to upgrade the underlying OS so I built a whole new VM and installed NetBox v3.6.4. * I enabled MAINTENANCE_MODE on the existing v3.2.8 instance using a config revision. * I dumped the database using pg_dump and moved it to the new box via scp (I actually wrote a bash script to do this). * I dropped the existing v3.6.4 database and imported the old data using psql and then ran the upgrade.sh process. * After starting the netbox and netbox-rq services, I visited the site and attempted to log in using my LDAP backed user account. * The login didn't fail, but I was immediately redirected back to the login page! * I've followed this process repeatedly over the last couple of weeks while updating and testing plugins and scripts etc - netbox v3.6.4 has been running on this VM for some weeks, automatically synced to the v3.2.8 instance using the above process every night and it has always worked. The only difference this morning was that the old instance was in maintenance mode prior to migrating the data. * Thinking that perhaps something was wrong with my LDAP auth, I created a local super user account (python netbox/manage.py createsuperuser). I was unable to log in with that account either. * Thinking that perhaps nginx was causing the redirect, I stopped nginx and ran the NetBox server directly (python netbox/manage.py runserver 0.0.0.0:8000). This did exactly the same, but I was able to see log messages saying that the last login date wasn't updated due to the application being in maintenance mode. * Because I couldn't log in, I couldn't change the config revision to disable MAINTENANCE_MODE so I added the option to the configuration.py file to override the contents of the config revision. * Having then restarted the application (systemctl restart netbox netbox-rq), I was then able to log in successfully using my LDAP account and delete the config revision from the database. It appears that enabling maintenance mode in the config revision, prevented any user from logging in. ### Expected Behavior Users should be able to log in even when maintenance mode is enabled. ### Observed Behavior With maintenance mode enabled via a config revision, I was unable to log in at all.
adam added the type: bugstatus: acceptedseverity: medium labels 2025-12-29 20:41:19 +01:00
adam closed this issue 2025-12-29 20:41:19 +01:00
adam commented 2025-12-29 20:41:20 +01:00
Author
Owner
Copy Link

@abhi1693 commented on GitHub (Nov 9, 2023):

New logins are not allowed while in maintenance mode because all transactions on the DB level are set to READ-ONLY mode. We can set the login path in MAINTENANCE_EXEMPT_PATHS to allow users to login which will let them go to config revision to disable the maintenance mode.

@abhi1693 commented on GitHub (Nov 9, 2023): New logins are not allowed while in maintenance mode because all transactions on the DB level are set to READ-ONLY mode. We can set the login path in `MAINTENANCE_EXEMPT_PATHS` to allow users to login which will let them go to config revision to disable the maintenance mode.
adam commented 2025-12-29 20:41:20 +01:00
Author
Owner
Copy Link

@cpmills1975 commented on GitHub (Nov 9, 2023):

That makes some sense, but it a) sort of defeats the purpose of maintenance mode showing a banner if login is forced and b) becomes impossible to turn it off again without a whole lot of faff if maintenance mode was enabled through a config revision which is stored in the database!

Can I put forward the following thinking for discussion and an agreement on the right way to solve this:

A) Maintenance mode does not prevent login - it's helpful for users to have RO access during periods of maintenance (ie while admins are migrating the DB to another VM prior to switching over as I was)

-or-

B) The option to enable maintenance mode is removed from the config revision code so it can only be enabled/disabled via configuration.py and a server restart.

-or-

C1) If login remains blocked, then this is reflected on the login page with a suitable message. That didn't happen and I just got redirected back to the login page every time I tried to login.

C2) Super users remain able to log in so they can disable maintenance mode by deleting the config revision (assuming this isn't RO). Perhaps super users in this context be limited to locally defined super users and not LDAP defined users i.e true low down admins?

As it stands, it's too easy (as I've found) to lock yourself out of NetBox and leave yourself no clue as to why you can't log in. It's difficult to solve without observing a subtle error message while running NetBox in its own (not supposed to be used) development server. Most users, I'd suggest, won't ever use the built in server and I only did as I thought it might be nginx redirecting me. I was preparing myself to rollback the upgrade and even that may not have worked because I'd moved the maintenance mode option from a really old configuration.py to a config revision. I'd have ended up trying to restore the VM from backup!

There's definitely an issue here that needs fixing somehow.

@cpmills1975 commented on GitHub (Nov 9, 2023): That makes some sense, but it a) sort of defeats the purpose of maintenance mode showing a banner if login is forced and b) becomes impossible to turn it off again without a whole lot of faff if maintenance mode was enabled through a config revision which is stored in the database! Can I put forward the following thinking for discussion and an agreement on the right way to solve this: A) Maintenance mode does not prevent login - it's helpful for users to have RO access during periods of maintenance (ie while admins are migrating the DB to another VM prior to switching over as I was) -or- B) The option to enable maintenance mode is removed from the config revision code so it can only be enabled/disabled via configuration.py and a server restart. -or- C1) If login remains blocked, then this is reflected on the login page with a suitable message. That didn't happen and I just got redirected back to the login page every time I tried to login. C2) Super users remain able to log in so they can disable maintenance mode by deleting the config revision (assuming this isn't RO). Perhaps super users in this context be limited to locally defined super users and not LDAP defined users i.e true low down admins? As it stands, it's too easy (as I've found) to lock yourself out of NetBox and leave yourself no clue as to why you can't log in. It's difficult to solve without observing a subtle error message while running NetBox in its own (not supposed to be used) development server. Most users, I'd suggest, won't ever use the built in server and I only did as I thought it might be nginx redirecting me. I was preparing myself to rollback the upgrade and even that may not have worked because I'd moved the maintenance mode option from a really old configuration.py to a config revision. I'd have ended up trying to restore the VM from backup! There's definitely an issue here that needs fixing somehow.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
beta
breaking change
complexity: high
complexity: low
complexity: medium
needs milestone
netbox
pending closure
plugin candidate
pull-request
Mirrored from GitHub Pull Request
 severity: high
severity: low
severity: medium
status: accepted
status: backlog
status: blocked
status: duplicate
status: needs owner
status: needs triage
status: revisions needed
status: under review
topic: GraphQL
topic: Internationalization
topic: OpenAPI
topic: UI/UX
topic: cabling
topic: event rules
topic: htmx navigation
topic: industrialization
topic: migrations
topic: plugins
topic: scripts
topic: templating
topic: testing
type: bug
type: deprecation
type: documentation
type: feature
type: housekeeping
type: translation
No Label severity: medium status: accepted type: bug
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
adam
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/netbox#8800
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?