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

Webfrontend with database in readonly mode #7381

New Issue
Closed
opened 2025-12-29 20:22:40 +01:00 by adam · 9 comments
adam commented 2025-12-29 20:22:40 +01:00
Owner
Copy Link

Originally created by @PieterL75 on GitHub (Dec 19, 2022).

Originally assigned to: @abhi1693 on GitHub.

NetBox version

v3.3.9

Feature type

Change to existing functionality

Proposed functionality

The current 'Maintenance mode' ensures that no writes are done to the database. It also displays a banner that the instance is in maintenance mode.

I would like to have a 'ReadOnly' mode that

  • like maintenance mode, prevents updates by logins.
  • don't display a banner (custom banner can be set with the BANNER_TOP)
  • don't do any database updates with the upgrade.sh script
  • optionally: provide a message to the user if he tries to do a write operation, with info to the read/write
  • optionally: use a separate database for session logs

Use case

We use postgres WAL to create a almost-realtime readonly copy of our production database.
This can be used to poll data from with API calls and the GUI.

In order to maintain this node, we need to patch the upgrade.sh (remove database operation), but that breaks the git pull.
Also, that banner that is show is not relevant to the state of our instance. It is not in maintenance, it is in readonly.
The sessionpath is an option, but I would rather like to send that to a separate database (different postgresql server) to maintain the session state across webfrontends

Database changes

No response

External dependencies

No response

Originally created by @PieterL75 on GitHub (Dec 19, 2022). Originally assigned to: @abhi1693 on GitHub. ### NetBox version v3.3.9 ### Feature type Change to existing functionality ### Proposed functionality The current 'Maintenance mode' ensures that no writes are done to the database. It also displays a banner that the instance is in maintenance mode. I would like to have a 'ReadOnly' mode that - like maintenance mode, prevents updates by logins. - don't display a banner (custom banner can be set with the BANNER_TOP) - don't do any database updates with the upgrade.sh script - optionally: provide a message to the user if he tries to do a write operation, with info to the read/write - optionally: use a separate database for session logs ### Use case We use postgres WAL to create a almost-realtime readonly copy of our production database. This can be used to poll data from with API calls and the GUI. In order to maintain this node, we need to patch the upgrade.sh (remove database operation), but that breaks the git pull. Also, that banner that is show is not relevant to the state of our instance. It is not in maintenance, it is in readonly. The sessionpath is an option, but I would rather like to send that to a separate database (different postgresql server) to maintain the session state across webfrontends ### Database changes _No response_ ### External dependencies _No response_
adam added the status: acceptedtype: feature labels 2025-12-29 20:22:40 +01:00
adam closed this issue 2025-12-29 20:22:40 +01:00
adam commented 2025-12-29 20:22:40 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Jan 5, 2023):

I'd really like to see this as well, however I'm not sure if we can elegantly hook into the database connection to catch and prevent write operations cleanly. Anyone have any ideas?

@jeremystretch commented on GitHub (Jan 5, 2023): I'd really like to see this as well, however I'm not sure if we can elegantly hook into the database connection to catch and prevent write operations cleanly. Anyone have any ideas?
adam commented 2025-12-29 20:22:41 +01:00
Author
Owner
Copy Link

@talha700 commented on GitHub (Jan 10, 2023):

Same case here, we are using postgres streaming replication and setup up 2 instances of Netbox, It would be cool if user can login (we are using LDAP for remote auth) to replica instance of Netbox as read-only.

I'm still seeing logs after turning MAINTENANCE_MODE=True, is it not supposed to update the last login etc... ? v3.3.7
Screenshot 2023-01-10 123633

@talha700 commented on GitHub (Jan 10, 2023): Same case here, we are using postgres streaming replication and setup up 2 instances of Netbox, It would be cool if user can login (we are using LDAP for remote auth) to replica instance of Netbox as read-only. I'm still seeing logs after turning MAINTENANCE_MODE=True, is it not supposed to update the last login etc... ? v3.3.7 ![Screenshot 2023-01-10 123633](https://user-images.githubusercontent.com/40869474/211490839-813ca562-3841-4519-9b76-6d963fbb9276.png)
adam commented 2025-12-29 20:22:41 +01:00
Author
Owner
Copy Link

@kkthxbye-code commented on GitHub (Jan 10, 2023):

@talha700 - https://django-auth-ldap.readthedocs.io/en/latest/reference.html#auth-ldap-always-update-user

@kkthxbye-code commented on GitHub (Jan 10, 2023): @talha700 - https://django-auth-ldap.readthedocs.io/en/latest/reference.html#auth-ldap-always-update-user
adam commented 2025-12-29 20:22:41 +01:00
Author
Owner
Copy Link

@abhi1693 commented on GitHub (Jan 14, 2023):

@jeremystretch Can I take a try at this? I have a solution which involves overriding CursorWrapper to raise exception in maintenance mode which in turn disallows write operations and gracefully informs the user via django message framework.

image
image
image

@abhi1693 commented on GitHub (Jan 14, 2023): @jeremystretch Can I take a try at this? I have a solution which involves overriding `CursorWrapper` to raise exception in maintenance mode which in turn disallows write operations and gracefully informs the user via django message framework. ![image](https://user-images.githubusercontent.com/5083532/212469501-691cf4d4-ccb4-4a88-9348-bf975680abd9.png) ![image](https://user-images.githubusercontent.com/5083532/212469552-e5194bd1-f92d-4e77-a206-686950011b11.png) ![image](https://user-images.githubusercontent.com/5083532/212470087-a948f910-7c18-4157-87dd-46a7d61f185c.png)
adam commented 2025-12-29 20:22:42 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Jan 16, 2023):

@abhi1693 sure! Put a PR in against the develop branch for now, although we may end up needing to defer this until the v3.5 release depending on how involved the implementation ends up being. Thanks!

@jeremystretch commented on GitHub (Jan 16, 2023): @abhi1693 sure! Put a PR in against the `develop` branch for now, although we may end up needing to defer this until the v3.5 release depending on how involved the implementation ends up being. Thanks!
adam commented 2025-12-29 20:22:42 +01:00
Author
Owner
Copy Link

@PieterL75 commented on GitHub (Jan 16, 2023):

There are also plugins (like ldap, okta saml) that write to the database when a user logs in
Is there a way to tackle that too?

@PieterL75 commented on GitHub (Jan 16, 2023): There are also plugins (like ldap, okta saml) that write to the database when a user logs in Is there a way to tackle that too?
adam commented 2025-12-29 20:22:42 +01:00
Author
Owner
Copy Link

@abhi1693 commented on GitHub (Jan 16, 2023):

I don't have a setup for that yet so I cannot say

@abhi1693 commented on GitHub (Jan 16, 2023): I don't have a setup for that yet so I cannot say
adam commented 2025-12-29 20:22:42 +01:00
Author
Owner
Copy Link

@pycolas commented on GitHub (Mar 5, 2023):

I am also interested with this feature.
A primary netbox instance where read/write operations are possible on sensitive network, and some read only instances reachable from less sensitive networks in the company (or in remote offices with huge latency with central).

Django as a database router functionnality. Maybe it can help in order to separate R/W operations for frontend user experience, and read operations for models storage ?
Or maybe in my usecase I can simply declare users with no write privileges at all.

@pycolas commented on GitHub (Mar 5, 2023): I am also interested with this feature. A primary netbox instance where read/write operations are possible on sensitive network, and some read only instances reachable from less sensitive networks in the company (or in remote offices with huge latency with central). Django as a database router functionnality. Maybe it can help in order to separate R/W operations for frontend user experience, and read operations for models storage ? Or maybe in my usecase I can simply declare users with no write privileges at all.
adam commented 2025-12-29 20:22:42 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (May 12, 2023):

don't display a banner (custom banner can be set with the BANNER_TOP)

This has been spun out into a separate FR, #12554.

don't do any database updates with the upgrade.sh script

This is an administrative concern that will need to be controlled outside of NetBox.

provide a message to the user if he tries to do a write operation, with info to the read/write

This is achieved by PR #12490, which sets each transaction to be read-only and cleanly reports an error in the event of an attempted write operation.

@jeremystretch commented on GitHub (May 12, 2023): > don't display a banner (custom banner can be set with the BANNER_TOP) This has been spun out into a separate FR, #12554. > don't do any database updates with the upgrade.sh script This is an administrative concern that will need to be controlled outside of NetBox. > provide a message to the user if he tries to do a write operation, with info to the read/write This is achieved by PR #12490, which sets each transaction to be read-only and cleanly reports an error in the event of an attempted write operation.
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 status: accepted type: feature
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#7381
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?