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

Allow a service to have multiple ports #1798

New Issue
Closed
opened 2025-12-29 17:19:13 +01:00 by adam · 6 comments
adam commented 2025-12-29 17:19:13 +01:00
Owner
Copy Link

Originally created by @dfsocha on GitHub (Jun 18, 2018).

Originally assigned to: @jeremystretch on GitHub.

Issue type
[x] Feature request
[ ] Bug report
[ ] Documentation

Environment
Server: Ubuntu 16.04.01 LTS
Python version: 2.7.12
NetBox version: 2.3.3

Description

Feature request for the modification of how ports for services are displayed on devices. The request would be to have the ports for the relevant service display similar to how IP addresses are displayed under interfaces.

In addition, it would be useful to be able to add port ranges to a service (e.g. TCP Port 35200-35220), as opposed to adding each port individually. This could be displayed similar to how IP addresses are displayed in the network interfaces section for a device. This would also clean up the display for services if a service has a wide range of ports that it uses.

This is similar to what was completed for IP addresses under ticket 878.

The primary value in this request would be to clean up the display of services on devices, which should in turn improve the readability and usability of that section.

I would expect that one or two additional tables would need to be created, to track the linkage between a service on a device, and the ports that that service uses.

I do not believe that any additional libraries would be needed.

Sample of Proposed Layout of Screen

image

Originally created by @dfsocha on GitHub (Jun 18, 2018). Originally assigned to: @jeremystretch on GitHub. Issue type [x] Feature request [ ] Bug report [ ] Documentation Environment Server: Ubuntu 16.04.01 LTS Python version: 2.7.12 NetBox version: 2.3.3 <!-- FEATURE REQUESTS must include: * A detailed description of the proposed functionality * A use case for the new feature * A rough description of any necessary changes to the database schema * Any relevant third-party libraries which would be needed --> ### Description Feature request for the modification of how ports for services are displayed on devices. The request would be to have the ports for the relevant service display similar to how IP addresses are displayed under interfaces. In addition, it would be useful to be able to add port ranges to a service (e.g. TCP Port 35200-35220), as opposed to adding each port individually. This could be displayed similar to how IP addresses are displayed in the network interfaces section for a device. This would also clean up the display for services if a service has a wide range of ports that it uses. This is similar to what was completed for IP addresses under ticket 878. The primary value in this request would be to clean up the display of services on devices, which should in turn improve the readability and usability of that section. I would expect that one or two additional tables would need to be created, to track the linkage between a service on a device, and the ports that that service uses. I do not believe that any additional libraries would be needed. Sample of Proposed Layout of Screen ![image](https://user-images.githubusercontent.com/1839893/41551400-52bfee10-72f1-11e8-9337-155e16bd6a77.png)
adam added the status: acceptedtype: feature labels 2025-12-29 17:19:13 +01:00
adam closed this issue 2025-12-29 17:19:13 +01:00
adam commented 2025-12-29 17:19:13 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Jul 18, 2018):

The purpose of the service model in NetBox is to document specific services running a host that might be of interest for management purposes. This feels like it's extending the scope of the model to serve other functions. For example, why would you need to document the ports used for "communication from Altaro Hyper-V Host Agents for Boot From Backup" in NetBox?

@jeremystretch commented on GitHub (Jul 18, 2018): The purpose of the service model in NetBox is to document specific services running a host that might be of interest for management purposes. This feels like it's extending the scope of the model to serve other functions. For example, why would you need to document the ports used for "communication from Altaro Hyper-V Host Agents for Boot From Backup" in NetBox?
adam commented 2025-12-29 17:19:14 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Aug 7, 2018):

Closing due to lack of activity.

@jeremystretch commented on GitHub (Aug 7, 2018): Closing due to lack of activity.
adam commented 2025-12-29 17:19:14 +01:00
Author
Owner
Copy Link

@dfsocha commented on GitHub (Dec 13, 2018):

Jeremy,

I apologize for my horrific delay on this one. I was away on military training for an extended period of time this summer and did not see the responses till it was to late.

I am finally able to get back into finalizing our NetBox implementation at my work. I was hoping that we could reopen this issue.

My thinking on this is being able to use NetBox as our source of truth for configuration data and setup. I understand that this will probably result in having to employ custom fields heavily. For services specifically, It is nice to be able to view them at the device level, and it would reduce the data entry and display by having a parent / child relationship between services, and the ports that they run on.

An example would be the image I posted in the initial feature request. In that image, it takes up 4 lines to represent the services on that hypervisor. currently, it is taking up 40 lines or so.

Thank you,

David

@dfsocha commented on GitHub (Dec 13, 2018): Jeremy, I apologize for my horrific delay on this one. I was away on military training for an extended period of time this summer and did not see the responses till it was to late. I am finally able to get back into finalizing our NetBox implementation at my work. I was hoping that we could reopen this issue. My thinking on this is being able to use NetBox as our source of truth for configuration data and setup. I understand that this will probably result in having to employ custom fields heavily. For services specifically, It is nice to be able to view them at the device level, and it would reduce the data entry and display by having a parent / child relationship between services, and the ports that they run on. An example would be the image I posted in the initial feature request. In that image, it takes up 4 lines to represent the services on that hypervisor. currently, it is taking up 40 lines or so. Thank you, David
adam commented 2025-12-29 17:19:14 +01:00
Author
Owner
Copy Link

@DanSheps commented on GitHub (Sep 17, 2019):

What is the thought of using DJango's model inheritance to provision "services".

Base Model: Service
Extended Models: ServicePort, ServicePortRange, ServicePortGroup

Alternatively, using content types and then break out Port, Port range, and Service Group into separate models. Thoughts?

I am actually leaning towards CT's and Generic relations right now.

@DanSheps commented on GitHub (Sep 17, 2019): What is the thought of using DJango's model inheritance to provision "services". Base Model: Service Extended Models: ServicePort, ServicePortRange, ServicePortGroup Alternatively, using content types and then break out Port, Port range, and Service Group into separate models. Thoughts? I am actually leaning towards CT's and Generic relations right now.
adam commented 2025-12-29 17:19:14 +01:00
Author
Owner
Copy Link

@dfsocha commented on GitHub (Sep 17, 2019):

Dan,

I am not sure if the comment was intended for me or Jeremy. If for me, I am not sure if I can be much help on the backend of this, as I know nothing about python. I would love to see this implemented, and will give whatever help that I can. I just know that we aren't really using the services portion of netbox at this time due to services that might span a wide variety of port ranges. The way that it seems implemented currently probably works great if you have one or two services on a machine that each use one port, but becomes more cumbersome when you have multiple ports to one service.

Thanks,

David

@dfsocha commented on GitHub (Sep 17, 2019): Dan, I am not sure if the comment was intended for me or Jeremy. If for me, I am not sure if I can be much help on the backend of this, as I know nothing about python. I would love to see this implemented, and will give whatever help that I can. I just know that we aren't really using the services portion of netbox at this time due to services that might span a wide variety of port ranges. The way that it seems implemented currently probably works great if you have one or two services on a machine that each use one port, but becomes more cumbersome when you have multiple ports to one service. Thanks, David
adam commented 2025-12-29 17:19:15 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Oct 15, 2019):

The most efficient way to approach this is probably to convert the current port IntegerField to an ArrayField capable of holding multiple integer values. We can enable range expansion within the UI form so that e.g. 100-104 expands to the array [100, 101, 102, 103, 104].

@jeremystretch commented on GitHub (Oct 15, 2019): The most efficient way to approach this is probably to convert the current `port` IntegerField to an ArrayField capable of holding multiple integer values. We can enable range expansion within the UI form so that e.g. `100-104` expands to the array `[100, 101, 102, 103, 104]`.
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#1798
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?