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

configuration.py is read by everybody following the instructions #9305

New Issue
Closed
opened 2025-12-29 20:48:09 +01:00 by adam · 6 comments
adam commented 2025-12-29 20:48:09 +01:00
Owner
Copy Link

Originally created by @MaKaNu on GitHub (Feb 28, 2024).

Change Type

Addition

Area

Installation/upgrade

Proposed Changes

Creating a copy of the configuration_example.py following the installation instructions leaves the configuration.py file in mode 644 instead it should be mode 600 since information like the database_pw are otherwise left in plaintext.

If readable by root is not sufficient the owner should be also changed to the netbox user.

Originally created by @MaKaNu on GitHub (Feb 28, 2024). ### Change Type Addition ### Area Installation/upgrade ### Proposed Changes Creating a copy of the configuration_example.py following the installation instructions leaves the configuration.py file in mode 644 instead it should be mode 600 since information like the database_pw are otherwise left in plaintext. If readable by root is not sufficient the owner should be also changed to the netbox user.
adam added the type: documentation label 2025-12-29 20:48:09 +01:00
adam closed this issue 2025-12-29 20:48:09 +01:00
adam commented 2025-12-29 20:48:09 +01:00
Author
Owner
Copy Link

@markkuleinio commented on GitHub (Feb 28, 2024):

My usual approach is

sudo chgrp netbox configuration.py
sudo chmod 0640 configuration.py

to remove the write access from NetBox and read+write accesses from anyone else.

@markkuleinio commented on GitHub (Feb 28, 2024): My usual approach is ``` sudo chgrp netbox configuration.py sudo chmod 0640 configuration.py ``` to remove the write access from NetBox and read+write accesses from anyone else.
adam commented 2025-12-29 20:48:10 +01:00
Author
Owner
Copy Link

@MaKaNu commented on GitHub (Feb 28, 2024):

seems also a valid approach. Something like this should be included in the installation documentation. Had similar discussion with snipe-it devs. They just say: An admin should now, where and when to set rights.

But if the documentation does not note it anywhere in the process it gets easily dropped.

@MaKaNu commented on GitHub (Feb 28, 2024): seems also a valid approach. Something like this should be included in the installation documentation. Had similar discussion with snipe-it devs. They just say: An admin should now, where and when to set rights. But if the documentation does not note it anywhere in the process it gets easily dropped.
adam commented 2025-12-29 20:48:10 +01:00
Author
Owner
Copy Link

@markkuleinio commented on GitHub (Feb 28, 2024):

To be honest, I think most deployments are so that all the local users on the NetBox server have possibility to use root (or similar) credentials anyway, so the actual risk is minimal. But, of course there are some cases where someone wants to install NetBox on a shared host with unprivileged users on them, they'll have probably some other aspects to consider as well.

@markkuleinio commented on GitHub (Feb 28, 2024): To be honest, I think most deployments are so that all the local users on the NetBox server have possibility to use root (or similar) credentials anyway, so the actual risk is minimal. But, of course there are some cases where someone wants to install NetBox on a shared host with unprivileged users on them, they'll have probably some other aspects to consider as well.
adam commented 2025-12-29 20:48:10 +01:00
Author
Owner
Copy Link

@MaKaNu commented on GitHub (Feb 28, 2024):

Absolutely right, but on the other hand it is just one line of code more for the documentation. I always do it to files with credentials, since it is good practice. You never know who changes in future the users who accesses the system. Since I hope most admins follow this structure, why not give it a notice in the documentation.

@MaKaNu commented on GitHub (Feb 28, 2024): Absolutely right, but on the other hand it is just one line of code more for the documentation. I always do it to files with credentials, since it is good practice. You never know who changes in future the users who accesses the system. Since I hope most admins follow this structure, why not give it a notice in the documentation.
adam commented 2025-12-29 20:48:10 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Feb 29, 2024):

While I appreciate the suggestion, this extends a bit beyond the intended scope of our documentation. The installation docs serve merely as a reference for getting up and running with NetBox: They are not meant to be all-inclusive (that would take an entire book). Just as we don't prescribe firewall rules or backup processes, we don't cover best practices concerning file permissions. It is assumed that the reader—someone ostensibly responsible for the server's operation—is competent enough to carry out such tasks independently.

@jeremystretch commented on GitHub (Feb 29, 2024): While I appreciate the suggestion, this extends a bit beyond the intended scope of our documentation. The installation docs serve merely as a reference for getting up and running with NetBox: They are not meant to be all-inclusive (that would take an entire book). Just as we don't prescribe firewall rules or backup processes, we don't cover best practices concerning file permissions. It is assumed that the reader—someone ostensibly responsible for the server's operation—is competent enough to carry out such tasks independently.
adam commented 2025-12-29 20:48:10 +01:00
Author
Owner
Copy Link

@MaKaNu commented on GitHub (Mar 4, 2024):

I totally understand the entire book analogy. But my point is not the missing explanation how to harden the complete server. The issue I see is in the step by step installation. Sure we read about how to configure redis or gunicorn, but also skipped it for our first installation, but we have red about more we could apply so we put it on our agenda.

I only stumbled over the file permissions while provisioning for ansible. And I did wrong in the first place and set it like described above to 600 which disabled the netbox user to access it. Sure It took me just 5 mins of reading. But on the other hand it costs the documentations one sentence and two lines of command prompt code, to remember the user about file permissions. At least a Notice would help to future admins at this point. At least I don't understand why it is so often not included in the documentation.

@MaKaNu commented on GitHub (Mar 4, 2024): I totally understand the entire book analogy. But my point is not the missing explanation how to harden the complete server. The issue I see is in the step by step installation. Sure we read about how to configure redis or gunicorn, but also skipped it for our first installation, but we have red about more we could apply so we put it on our agenda. I only stumbled over the file permissions while provisioning for ansible. And I did wrong in the first place and set it like described above to 600 which disabled the netbox user to access it. Sure It took me just 5 mins of reading. But on the other hand it costs the documentations one sentence and two lines of command prompt code, to remember the user about file permissions. At least a Notice would help to future admins at this point. At least I don't understand why it is so often not included in the documentation.
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 type: documentation
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#9305
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?