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

Ability to add pictures/images/photos of racks/devices #115

New Issue
Closed
opened 2025-12-29 15:33:39 +01:00 by adam · 16 comments
adam commented 2025-12-29 15:33:39 +01:00
Owner
Copy Link

Originally created by @Amfy on GitHub (Jun 30, 2016).

Add the ability to upload pictures and link this to racks and devices to assist during remote sessions. Racktables has this and it helps a lot during the daily operating duty

Originally created by @Amfy on GitHub (Jun 30, 2016). Add the ability to upload pictures and link this to racks and devices to assist during remote sessions. Racktables has this and it helps a lot during the daily operating duty
adam closed this issue 2025-12-29 15:33:39 +01:00
adam commented 2025-12-29 15:33:39 +01:00
Author
Owner
Copy Link

@afenioux commented on GitHub (Jul 8, 2016):

More generally, it would be practical to be able to attach any type of file to any object.
Some may need to link pdf contract (or bills) to device or somewhere else

@afenioux commented on GitHub (Jul 8, 2016): More generally, it would be practical to be able to attach any type of file to any object. Some may need to link pdf contract (or bills) to device or somewhere else
adam commented 2025-12-29 15:33:40 +01:00
Author
Owner
Copy Link

@rekeds commented on GitHub (Jul 8, 2016):

yes, sounds good.
currently we use wiki for this.

@rekeds commented on GitHub (Jul 8, 2016): yes, sounds good. currently we use wiki for this.
adam commented 2025-12-29 15:33:41 +01:00
Author
Owner
Copy Link

@kefoster commented on GitHub (Jul 8, 2016):

I like the idea of being able to upload pictures of the racks. However for other pieces like contracts/docs etc it would be nice to just be able to attach a URL/UNC that points to the location of the documents.

@kefoster commented on GitHub (Jul 8, 2016): I like the idea of being able to upload pictures of the racks. However for other pieces like contracts/docs etc it would be nice to just be able to attach a URL/UNC that points to the location of the documents.
adam commented 2025-12-29 15:33:41 +01:00
Author
Owner
Copy Link

@JNR8 commented on GitHub (Jul 15, 2016):

a vote from me on this.
Being able to upload images of whole racks to Rack object, builds to location objects and device images to specific devices would be very helpful. Device Templates could also hold a generic image of that type of device.

@JNR8 commented on GitHub (Jul 15, 2016): a vote from me on this. Being able to upload images of whole racks to Rack object, builds to location objects and device images to specific devices would be very helpful. Device Templates could also hold a generic image of that type of device.
adam commented 2025-12-29 15:33:42 +01:00
Author
Owner
Copy Link

@martink2 commented on GitHub (Aug 29, 2016):

I would also cast my vote for device images, it would help visibility a lot compared to just the colored boxes in the rack view. Given our day to day operations i would suggest the following
three to be added to a device/device type:

  • Front view of the device (also used in the rack view)
  • Rear view of the device (also used in the rack view)
  • Port Description, technical drawing with detailed port descriptions (maybe shown on mouse over or a details page)

In our current solution we have the first two but missing the last which
often leads to cables ending up in the wrong physical port (no matter how detailed you
describe ge-0/0/0 on the device .. there is always room for interpretation)

@martink2 commented on GitHub (Aug 29, 2016): I would also cast my vote for device images, it would help visibility a lot compared to just the colored boxes in the rack view. Given our day to day operations i would suggest the following three to be added to a device/device type: - Front view of the device (also used in the rack view) - Rear view of the device (also used in the rack view) - Port Description, technical drawing with detailed port descriptions (maybe shown on mouse over or a details page) In our current solution we have the first two but missing the last which often leads to cables ending up in the wrong physical port (no matter how detailed you describe ge-0/0/0 on the device .. there is always room for interpretation)
adam commented 2025-12-29 15:33:42 +01:00
Author
Owner
Copy Link

@fltchr commented on GitHub (Aug 29, 2016):

@martink2, curious, are the images of your actual devices, or stock images? Just wondering if they accurately represent installed modules and options. If the former, it seems like it would be a pain to collect images the correct size and quality needed to plug into the rack views.

@fltchr commented on GitHub (Aug 29, 2016): @martink2, curious, are the images of your actual devices, or stock images? Just wondering if they accurately represent installed modules and options. If the former, it seems like it would be a pain to collect images the correct size and quality needed to plug into the rack views.
adam commented 2025-12-29 15:33:42 +01:00
Author
Owner
Copy Link

@martink2 commented on GitHub (Aug 29, 2016):

Usually it's stock images, we rarely have to photograph something. Having the modules in would be a definite bonus but i would gladly settle for devices only.

@martink2 commented on GitHub (Aug 29, 2016): Usually it's stock images, we rarely have to photograph something. Having the modules in would be a definite bonus but i would gladly settle for devices only.
adam commented 2025-12-29 15:33:42 +01:00
Author
Owner
Copy Link

@farewelldave commented on GitHub (Aug 30, 2016):

I don't know the feasibility of this, but most vendors have a decent set of visio stencils, and I wonder if there would/could be a way too import a stencil file, which would generally be an entire product line/category, and skim the image from that stencil?

That may be too lofty or too hard to implement, so starting with a per device field for picture data for front/rear images would be nice. The technical drawing would be really nice on servers. i.e., multiple NICs on add-in cards that aren't necessarily ge0/1, ge0/2, etc.

@farewelldave commented on GitHub (Aug 30, 2016): I don't know the feasibility of this, but most vendors have a decent set of visio stencils, and I wonder if there would/could be a way too import a stencil file, which would generally be an entire product line/category, and skim the image from that stencil? That may be too lofty or too hard to implement, so starting with a per device field for picture data for front/rear images would be nice. The technical drawing would be really nice on servers. i.e., multiple NICs on add-in cards that aren't necessarily ge0/1, ge0/2, etc.
adam commented 2025-12-29 15:33:43 +01:00
Author
Owner
Copy Link

@cstueckrath commented on GitHub (Aug 30, 2016):

stencil support (or something similar) would be awesome, especially if the interfaces were usable as interactive objects

@cstueckrath commented on GitHub (Aug 30, 2016): stencil support (or something similar) would be awesome, especially if the interfaces were usable as interactive objects
adam commented 2025-12-29 15:33:43 +01:00
Author
Owner
Copy Link

@zevlag commented on GitHub (Jan 5, 2017):

@jeremystretch Do you have ideas on how you'd like to see this implemented if someone were to begin work on code to contribute this feature?

@zevlag commented on GitHub (Jan 5, 2017): @jeremystretch Do you have ideas on how you'd like to see this implemented if someone were to begin work on code to contribute this feature?
adam commented 2025-12-29 15:33:43 +01:00
Author
Owner
Copy Link

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

@zevlag I was just pondering this yesterday, trying to determine how best to store the media files. Saving them to disk will require some additional configuration on the web server side and particular attention to filesystem permissions. This shouldn't be too complicated but will extend data outside of the database, so users will need to modify their backup and replication schemes to account for this.

Alternatively, we could store the files directly in the database. This isn't something I'd normally consider, but NetBox is typically a very low-traffic application, so I'm not too worried about the performance hit. Though it does, of course, greatly increase the size of the database. I'm open to suggestions.

@jeremystretch commented on GitHub (Jan 5, 2017): @zevlag I was just pondering this yesterday, trying to determine how best to store the media files. Saving them to disk will require some additional configuration on the web server side and particular attention to filesystem permissions. This shouldn't be too complicated but will extend data outside of the database, so users will need to modify their backup and replication schemes to account for this. Alternatively, we could store the files directly in the database. This isn't something I'd normally consider, but NetBox is typically a very low-traffic application, so I'm not too worried about the performance hit. Though it does, of course, greatly increase the size of the database. I'm open to suggestions.
adam commented 2025-12-29 15:33:44 +01:00
Author
Owner
Copy Link

@LukeDRussell commented on GitHub (Jan 24, 2017):

I'd prefer it be in the database - ultimately the images are going to take up disk space somewhere and a simple backup procedure is nice. Also plus one for this feature.

@LukeDRussell commented on GitHub (Jan 24, 2017): I'd prefer it be in the database - ultimately the images are going to take up disk space somewhere and a simple backup procedure is nice. Also plus one for this feature.
adam commented 2025-12-29 15:33:44 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Jan 25, 2017):

Security is another consideration: We want to ensure that photos and other potentially sensitive media are not inadvertently exposed directly through the web frontend without the request being authenticated. This can be accomplished with either approach, but database storage removes the possibility of leakage due to web server misconfiguration.

@jeremystretch commented on GitHub (Jan 25, 2017): Security is another consideration: We want to ensure that photos and other potentially sensitive media are not inadvertently exposed directly through the web frontend without the request being authenticated. This can be accomplished with either approach, but database storage removes the possibility of leakage due to web server misconfiguration.
adam commented 2025-12-29 15:33:44 +01:00
Author
Owner
Copy Link

@mkx32083 commented on GitHub (Feb 6, 2017):

I'm for the DB solution too.

@mkx32083 commented on GitHub (Feb 6, 2017): I'm for the DB solution too.
adam commented 2025-12-29 15:33:52 +01:00
Author
Owner
Copy Link

@puck commented on GitHub (Feb 7, 2017):

There are some projects (such as Request Tracker) which had stored assets in the database, but run into scaling issues. If possible then an abstraction layer would be preferable. This could allow storing in a DB, S3, files, whatever.

And if files are used, then you probably don't want them stored under the doc root for the web server. ;)

@puck commented on GitHub (Feb 7, 2017): There are some projects (such as Request Tracker) which had stored assets in the database, but run into scaling issues. If possible then an abstraction layer would be preferable. This could allow storing in a DB, S3, files, whatever. And if files are used, then you probably don't want them stored under the doc root for the web server. ;)
adam commented 2025-12-29 15:33:52 +01:00
Author
Owner
Copy Link

@martink2 commented on GitHub (Feb 7, 2017):

I have to agree with @puck, we did blob store inside a Postgres once and
it became a mess pretty quickly. I would suggest to have the db store a
url reference to the file. For convenience an upload / download / browse
function for locally stored images in a directory would be very much appreciated.

@martink2 commented on GitHub (Feb 7, 2017): I have to agree with @puck, we did blob store inside a Postgres once and it became a mess pretty quickly. I would suggest to have the db store a url reference to the file. For convenience an upload / download / browse function for locally stored images in a directory would be very much appreciated.
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
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#115
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?