Input Needed: Software version Tracking #11757

ryanmerolle · 2023-02-15T16:02:23Z

ryanmerolle
Feb 15, 2023

For some time the community and maintainers have kicked around the idea of software version tracking in addition to platform tracking.

Referenced leveraged for inspiration:

NetBox Plugin - Software Lifecycle Managment - unmaintained plugin
Netbox Plugin - Software Manager - plugin focused on mostly Cisco and the act of upgrading

Goals of new models(am I missing anything?):

Track software/version/variations per platform
Track software image files for software/version
Track software image files against devicetype (optionally track moduletype and inventory_items since software can be applied to those technically)

My draft on new model(s) (please critique):

class Software(NetBoxModel):
    """Software model."""
    platform = models.ForeignKey(to="dcim.Platform", on_delete=models.CASCADE, verbose_name="Platform")
    version = models.CharField(max_length=100)
    description = models.CharField(max_length=255, null=True, blank=True)
    release_notes_url = models.URLField(blank=True, verbose_name="Release Notes")
    long_term_support = models.BooleanField(verbose_name="Long Term Support", default=False)
    pre_release = models.BooleanField(verbose_name="Pre-Release", default=False)
    release_date = models.DateField(null=True, blank=True, verbose_name="Release Date")
    end_of_support = models.DateField(null=True, blank=True, verbose_name="End of Support")

class SoftwareImage(NetBoxModel):
    """SoftwareImage model."""
    filename = models.CharField(blank=False, max_length=100, verbose_name="File Name")
    software = models.ForeignKey(to="Software", on_delete=models.CASCADE, related_name="software_images", verbose_name="Software")
    description = models.CharField(max_length=255, null=True, blank=True)
    device_types = models.ManyToManyField(to="dcim.DeviceType", related_name="+", blank=True)
    inventory_items = models.ManyToManyField(to="dcim.InventoryItem", related_name="+", blank=True)
    url = models.URLField(blank=True, verbose_name="URL")
    file_checksum = models.CharField(blank=True, max_length=256, verbose_name="File Checksum")

Tagging @abhi1693 @alsigna @Hedde @fniessink @DanSheps @kkthxbye-code @jsenecal @jeremystretch since all have voiced input or have contributed to a plugin.

References #5272

jsenecal · 2023-02-15T16:33:54Z

jsenecal
Feb 15, 2023

How are we tracking which device uses which software version ? Through different platforms ? (this wouldn't work for me tbh)

6 replies

jsenecal Feb 15, 2023

I think it would be important to track the field installed version per device in order to properly use this feature. We have situations where the same device_type runs multiple different versions in the field. I.e, different markets or rollouts.

sthierolf Feb 15, 2023

I think the best way would be:

The type should be tracked by device type (i.e. IOS, IOS XE, ASA, FPR, AirEos, ...)
The version should be tracked by device (16.0.1, 12.5.0, etc)
For example, the same model (device type) might have different versions.
One switch running IOS is using version 12.2.2, another one (same model/type) is using 12.1.1.
In a grown network this type of version mismatch is "normal".

I think it's not only software, but also the hardware itself should be tracked. I.e. for Cisco (or any other hardware) I've created custom fields for End-of-Sale, End-of-Support, etc. dates.

A thought to: Track software image files against devicetype (optionally track moduletype and inventory_items since software can be applied to those technically)
A platform might support a specific IOS image or version, but technically the installation might fail due to "not enough flash" ;)
Eventually it makes sense to track in addition flash or disk capacity? (Thinking here what's provided by ansible gather_facts)

Looking forward for a plugin like this!

ryanmerolle Feb 16, 2023
Author

@jsenecal

I think it would be important to track the field installed version per device in order to properly use this feature. We have situations where the same device_type runs multiple different versions in the field. I.e, different markets or rollouts.

I totally get it, not everything can be as rigid as applying to a device type. Hence my comment of handling like config_context. Though I think its sort of complex and confusing for users to apply the whole weighted multi object association.

I think a flexibility is needed because some orgs will manage a software version by devicetype, some by the combination of a devicetype, devicerole, and region, and others will manage it by device. I am not sure of the approach yet.

ryanmerolle Feb 16, 2023
Author

@sthierolf

  The **version** should be tracked by **device** (16.0.1, 12.5.0, etc)
  For example, the same model (device type) might have different versions.
  One switch running IOS is using version 12.2.2, another one (same model/type) is using 12.1.1.
  In a grown network this type of version mismatch is "normal".

Sort of a tangent comment by me: I get that is common for most mature orgs, but I will say that this sort of variation hardware/software along with solution variation is something I look to shrink in order to better model and automate the network at every shop I have been at over the last 10 years.

I think it's not only software, but also the hardware itself should be tracked. I.e. for Cisco (or any other hardware) I've created custom fields for End-of-Sale, End-of-Support, etc. dates.
[...]
Looking forward for a plugin like this!

We were debating putting it in core, but you are basically saying we should port/mimic and improve upon nautobot's device lifecycle management plugin. I'd be happy to help coordinate and maintain longterm, I just do not know that I have the time to hammer something out on my own right now. But I would be more open if others wanted join me. ;)

ryanmerolle Feb 16, 2023
Author

Anyone want to just take a stab at porting nautobot's device lifecycle management plugin as is? We can then play with the models and tweak.

mtinberg · 2023-02-15T23:15:18Z

mtinberg
Feb 15, 2023

I'm currently using an Ansible playbook to upgrade IOS, IOS-XE and NXOS and am abusing the Platform field to store both the type and version, matching whats returned via SNMP, eg. - ios-12.2(58)SE2 - iosxe-Bengaluru 17.06.03 - nxos-7.3(7)D1(1) And for each Platform (and sometimes Device Type) there is a Config Context with the filename and hash of each firmware so the Ansible playbook knows what to template into commands, eg. { "ios_bin": "cat9k_iosxe.17.06.03.SPA.bin", "ios_md5": "4637c5c6767fee76c8b0cec1b7370cd3", "ios_version": "17.06.03" } { "nxos_bin": "n7000-s2-dk9.7.3.7.D1.1.bin", "nxos_epld_bin": "n7000-s2-epld.7.3.7.D1.1.img", "nxos_epld_md5": "6c39b0a1c56842a4cdaa8896ff29f3bc", "nxos_epld_version": "7.3(7)D1(1)", "nxos_kickstart_bin": "n7000-s2-kickstart.7.3.7.D1.1.bin", "nxos_kickstart_md5": "c575875091e15f026ba28c5824ccb2b3", "nxos_kickstart_version": "7.3(7)D1(1)", "nxos_md5": "f6bd985fe4f1a3c59ab2b3944537bd5f", "nxos_version": "7.3(7)D1(1)" } Changing the Platform on a Device will bring the desired state out of alignment with the current state and the Playbook can check the actual version against the intended version and see that it's eligible for firmware install. Having a desired default version associated with the Device Type makes sense, so you can audit which Devices have a non-default version and make them consistent and new devices get deployed with the current firmware if provisioning is automated. When planning a Software model I'd just like to be able to keep track of the install files for any version and be sensitive to the fact that the same version number might have different installers for different device types. eg. both ISR4200 and ISR4400 run IOS-XE 17.06.03a but still different files. { "ios_bin": "isr4200-universalk9_ias.17.06.03a.SPA.bin", "ios_md5": "f5e7774fc9c3674e2282ff92fadc9e92", "ios_version": "17.06.03a" } { "ios_bin": "isr4400-universalk9.17.06.03a.SPA.bin", "ios_md5": "fa99aa754c05cb9d3d3cd42729b025ef", "ios_version": "17.06.03a" } I don't think tracking at the level of flash free space is useful, a playbook doing upgrade work is going to need to check the acutals first, and Netbox is for storing config intent, I don't think there is an intent around the amount of free space, unless you are configuring an audit tool for free space and want to configure the thresholds in Netbox — Mark Tinberg ***@***.***> Division of Information Technology-Network Services University of Wisconsin-Madison

…

________________________________ From: KonsolentieR ***@***.***) ***@***.***> Sent: Wednesday, February 15, 2023 4:30 PM To: netbox-community/netbox ***@***.***> Cc: Subscribed ***@***.***> Subject: Re: [netbox-community/netbox] Input Needed: Software version Tracking (Discussion #11757) I think the best way would be: * The type should be tracked by device type (i.e. IOS, IOS XE, ASA, FPR, AirEos, ...) * The version should be tracked by device (16.0.1, 12.5.0, etc) For example, the same model (device type) might have different versions. One switch running IOS is using version 12.2.2, another one (same model/type) is using 12.1.1. In a grown network this type of version mismatch is "normal". I think it's not only software, but also the hardware itself should be tracked. I.e. for Cisco (or any other hardware) I've created custom fields for End-of-Sale, End-of-Support, etc. dates. A thought to: Track software image files against devicetype (optionally track moduletype and inventory_items since software can be applied to those technically) A platform might support a specific IOS image or version, but technically the installation might fail due to "not enough flash" ;) Eventually it makes sense to track in addition flash or disk capacity? (Thinking here what's provided by ansible gather_facts) Looking forward for a plugin like this! — Reply to this email directly, view it on GitHub<#11757 (reply in thread)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AAS7UM56BZ3N5GUIQSAPMALWXVKJFANCNFSM6AAAAAAU5BC6BA>. You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

1 reply

ryanmerolle Feb 16, 2023
Author

I mentioned in one of my replies above that I try to minimize variations of software to use some logic. I'll share just to promote the exchange of approaches (regardless of if it helps the larger discussion).

Right now I can say all my Arista EOS (same for other platforms) should run x version of EOS with this filename, and the file exists in https://net-images-{{ site_code }}.example.com/{{ manufacturer }}/{{ platform }}/{{ image_filename }}. I set this for all devices per platform using config_context as well.

I have a number of playbooks that are stitched together in a workflow/playbook that calls each step in order:

audit_firmware - generate reports per site based on each device/platform's set version
load_firmware - delete any firmware not set as the netbox standard OR not currently running, load fimrware from a https server located on site
install_firmware - set boot statement or run the platform install command, but not reload
pre_check - collect various show commands, parse output if platform does not provide rest/json, remove any counters or timestamp fields from output, store in a yaml within the pre_check directory
reload - reload all devices at a site based on a "resiliency group" (group A goes first)
post_check - collect various show commands, parse output if platform does not provide rest/json, remove any counters or timestamp fields from output, store in a yaml within the post_check directory
checkout - compare pre and post checkout and save to a report (uses jsondiff or the built in ansible module)

When done with a checkout for group A, I move forward with group B starting at reload.

Fortinet and Cisco are more challenging given the different files require for different models, but I use a config_context applied per devicetype for that.

mtinberg · 2023-02-16T16:25:09Z

mtinberg
Feb 16, 2023

We were debating putting it in core, but you are basically saying we should port/mimic and improve upon nautobot's device lifecycle management plugin<https://github.com/nautobot/nautobot-plugin-device-lifecycle-mgmt>.

While this is obviously Cisco-specific https://github.com/goebelmeier/netbox-cisco-support it's something I was planning to look into for lifecycle management of our most common device types. Separating out the vendor-specific bits might be a good start, an external script which can look up serial numbers using the vendors support API to update a generic schema for warranty info and a report to show which ones are nearing expiration, with some override (tags?, custom_field? on device_type or individual devices?) for when you know things are out of warranty and don't want to keep hearing about it 😉 — Mark Tinberg ***@***.***> Division of Information Technology-Network Services University of Wisconsin-Madison

…

________________________________ From: Ryan Merolle ***@***.***> Sent: Wednesday, February 15, 2023 8:32 PM To: netbox-community/netbox ***@***.***> Cc: Mark Tinberg ***@***.***>; Comment ***@***.***> Subject: Re: [netbox-community/netbox] Input Needed: Software version Tracking (Discussion #11757) @sthierolf<https://github.com/sthierolf> The **version** should be tracked by **device** (16.0.1, 12.5.0, etc) For example, the same model (device type) might have different versions. One switch running IOS is using version 12.2.2, another one (same model/type) is using 12.1.1. In a grown network this type of version mismatch is "normal". Sort of a tangent comment by me: I get that is common for most mature orgs, but I will say that this sort of variation hardware/software along with solution variation is something I look to shrink in order to better model and automate the network at every shop I have been at over the last 10 years. I think it's not only software, but also the hardware itself should be tracked. I.e. for Cisco (or any other hardware) I've created custom fields for End-of-Sale, End-of-Support, etc. dates. [...] Looking forward for a plugin like this! We were debating putting it in core, but you are basically saying we should port/mimic and improve upon nautobot's device lifecycle management plugin<https://github.com/nautobot/nautobot-plugin-device-lifecycle-mgmt>. I'd be happy to help coordinate and maintain longterm, I just do not know that I have the time to hammer something out on my own right now. But I would be more open if others wanted join me. ;) — Reply to this email directly, view it on GitHub<#11757 (reply in thread)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AAS7UM5IYYPA5JVRG65PD73WXWGVDANCNFSM6AAAAAAU5BC6BA>. You are receiving this because you commented.Message ID: ***@***.***>

0 replies

mtinberg · 2023-02-16T16:37:44Z

mtinberg
Feb 16, 2023

One thing our version audit tool does is that while the desired firmware version is configured per device type, it accepts a list of valid versions, because during a mass upgrade there is the old standard version and the new standard version and we don't want the audit to complain for _every_ device. At the end we remove the old standard version from the acceptable list and see the stragglers as audit failures. Migrations can take a while based on how many change windows need to be scheduled and how many devices you are comfortable rebooting in one batch, so the audit has to be flexible. We've had cases where some percentage of a production model starts failing on upgrade (maybe just needs to be power cycled, but sometimes they are RMAd) and there is a limit to how many cases we could handle without it being a major incident. — Mark Tinberg ***@***.***> Division of Information Technology-Network Services University of Wisconsin-Madison

…

________________________________ From: Ryan Merolle ***@***.***> Sent: Wednesday, February 15, 2023 8:26 PM To: netbox-community/netbox ***@***.***> Cc: Mark Tinberg ***@***.***>; Comment ***@***.***> Subject: Re: [netbox-community/netbox] Input Needed: Software version Tracking (Discussion #11757) @jsenecal<https://github.com/jsenecal> I think it would be important to track the field installed version per device in order to properly use this feature. We have situations where the same device_type runs multiple different versions in the field. I.e, different markets or rollouts. I totally get it, not everything can be as rigid as applying to a device type. Hence my comment of handling like config_context. Though I think its sort of complex and confusing for users to apply the whole weighted multi object association. I think a flexibility is needed because some orgs will manage a software version by devicetype, some by the combination of a devicetype, devicerole, and region, and others will manage it by device. I am not sure of the approach yet. — Reply to this email directly, view it on GitHub<#11757 (reply in thread)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AAS7UM2G7KMGNM3O5GX3VI3WXWF67ANCNFSM6AAAAAAU5BC6BA>. You are receiving this because you commented.Message ID: ***@***.***>

0 replies

mtinberg · 2023-02-16T16:41:00Z

mtinberg
Feb 16, 2023

This is very similar to how my Ansible playbook works, it's split into a staging and reload playbook, but staging does the load/install dance and the reload checks the installed version against the running version, with error checking along the way. I don't have pre-check/post-check reporting the same, but all the configs are checked into RCS at the end of a successful staging and again after successful reload so we can see any diffs to the device state. — Mark Tinberg ***@***.***> Division of Information Technology-Network Services University of Wisconsin-Madison

…

________________________________ From: Ryan Merolle ***@***.***> Sent: Wednesday, February 15, 2023 8:48 PM To: netbox-community/netbox ***@***.***> Cc: Mark Tinberg ***@***.***>; Comment ***@***.***> Subject: Re: [netbox-community/netbox] Input Needed: Software version Tracking (Discussion #11757) I mentioned in one of my replies above that I try to minimize variations of software to use some logic. I'll share just to promote the exchange of approaches (regardless of if it helps the larger discussion). Right now I can say all my Arista EOS (same for other platforms) should run x version of EOS with this filename, and the file exists in https://net-images-{{ site_code }}.example.com/{{ manufacturer }}/{{ platform }}/{{ image_filename }}. I set this for all devices per platform using config_context as well. I have a number of playbooks that are stitched together in a workflow/playbook that calls each step in order: * audit_firmware - generate reports per site based on each device/platform's set version * load_firmware - delete any firmware not set as the netbox standard OR not currently running, load fimrware from a https server located on site * install_firmware - set boot statement or run the platform install command, but not reload * pre_check - collect various show commands, parse output if platform does not provide rest/json, remove any counters or timestamp fields from output, store in a yaml within the pre_check directory * reload - reload all devices at a site based on a "resiliency group" (group A goes first) * post_check - collect various show commands, parse output if platform does not provide rest/json, remove any counters or timestamp fields from output, store in a yaml within the post_check directory * checkout - compare pre and post checkout and save to a report (uses jsondiff or the built in ansible module) When done with a checkout for group A, I move forward with group B starting at reload. Fortinet and Cisco are more challenging given the different files require for different models, but I use a config_context applied per devicetype for that. — Reply to this email directly, view it on GitHub<#11757 (reply in thread)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AAS7UM4HV4RUAMSMTLIOPJDWXWIRTANCNFSM6AAAAAAU5BC6BA>. You are receiving this because you commented.Message ID: ***@***.***>

0 replies

patrickpreuss · 2023-02-19T09:03:06Z

patrickpreuss
Feb 19, 2023

Maybe it is worth to foresee a definition of upgrade path(s) and dependencies between Versions and maybe also between Systems or the features in use.
The benefit would be not to hardcode this into update logic or collect this from a third source.

Some Vendors do have the requirement to update systems in a certain way:
Fortinet does require certain update paths from version 6.0.1 to 6.0.15 than you can update to 6.2.16 and than to final version.

Check Point sometimes require to install a certain Hotfix a certain Hotfix accumulator (HFA), but certain Hotfix not to be installed. Hotfixes
and HFAs are not Version in terms of Check Point versioning. Also Check Point does require to install a certain version of the deployment agent to be installed first.

Sometimes technically the gateway can be updated to a certain version but need to stay on a lower version to be managed / operable in its environment. With Fortinet Firewalls and Managers need to go along and the Firewall with the Lowest Version dictates the Version on this Manager. Or a certain type of feature you rely on, eg crypto ciphers removed.

1 reply

ryanmerolle Feb 19, 2023
Author

It’s not a bad idea, but I’d imagine it would be a day 2 feature

MalfuncEddie · 2024-01-11T08:10:27Z

MalfuncEddie
Jan 11, 2024

not sure I this is the right place

But could this be expanded to the services model or vm for tracking software versions?

Currently I am using netbox as a single source of truth and enriching it with ansible information

eg:
netbox gives me all vm's where a tomcat service is running --> enrichment to netbox where it fills in a custom field "installed version".
upgrades are as easy as mismatching custom fields "installed_version" and "wanted_version" -> run playbook

issue is that different services have different properties so now I have services with following custom fields:

tomcat_installed_version
tomcat_wanted_version
postgres_installed_version
postgres_wanted_version

So this explodes the custom fields ;(

I did think of just using a custom field service type and having the specific service information in a json custom field or using configuration context. but custom fields are so awesome because I can just point my boss to netbox -> here is an overview of all tomcat services and versions.

0 replies

mtinberg · 2024-01-11T17:55:12Z

mtinberg
Jan 11, 2024

I don't think thats a bad way to do it, the explosion of custom fields is something I would expect as you lean more into the database for storing this kind of data and I'm not sure there is any good way around that, you want to store something on a per-node/per-service basis so that complexity can't be factored out, but having a bunch of empty custom fields for hosts which don't have those services can look/feel cluttered and annoying but I think it's technically fine. There are grouping and display weight fields for custom_fields, so you have options to organize them to keep the clutter managed, and recent netbox has a toggle for custom_fields where the UI is only visible if the field is set, which may be a way to reduce some of the clutter for fields which arent relevant for the particular Device in question (not seeing the tomcat fiels for a postgresql server and vice versa) — Mark Tinberg ***@***.***> Division of Information Technology-Network Services University of Wisconsin-Madison

…

________________________________ From: MalfuncEddie ***@***.***> Sent: Thursday, January 11, 2024 2:10 AM To: netbox-community/netbox ***@***.***> Cc: Mark Tinberg ***@***.***>; Comment ***@***.***> Subject: Re: [netbox-community/netbox] Input Needed: Software version Tracking (Discussion #11757) not sure I this is the right place But could this be expanded to the services model or vm for tracking software versions? Currently I am using netbox as a single source of truth and enriching it with ansible information eg: netbox gives me all vm's where a tomcat service is running --> enrichment to netbox where it fills in a custom field "installed version". upgrades are as easy as mismatching custom fields "installed_version" and "wanted_version" -> run playbook issue is that different services have different properties so now I have services with following custom fields: tomcat_installed_version tomcat_wanted_version postgres_installed_version postgres_wanted_version So this explodes the custom fields ;( I did think of just using a custom field service type and having the specific service information in a json custom field or using configuration context. but custom fields are so awesome because I can just point my boss to netbox -> here is an overview of all tomcat services and versions. — Reply to this email directly, view it on GitHub<#11757 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AAS7UM3IGDDFZMVFY3NBYULYN6M77AVCNFSM6AAAAAAU5BC6BCVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM4DAOJRGM3TM>. You are receiving this because you commented.Message ID: ***@***.***>

0 replies

eronlloyd · 2024-01-21T03:40:11Z

eronlloyd
Jan 21, 2024

Wouldn't it make sense to build on the existing platform model? The intended use documented in the help system states

A platform defines the type of software running on a device or virtual machine. This can be helpful to model when it is necessary to distinguish between different versions or feature sets. Note that two devices of the same type may be assigned different platforms: For example, one Juniper MX240 might run Junos 14 while another runs Junos 15.

Perhaps we could implement a parent field and/or dependency field (for upgrade paths?), such that RouterOS 7.13 would have RouterOS 7 as the parent, and platforms with well-defined upgrade paths might reflect that within the hierarchy.

Or maybe just start out with a version field (and possibly a validator)?

4 replies

MalfuncEddie Jan 21, 2024

In my case this does not work since a vm can have multiple software packages installed.

How would you model

a vm following facts/attributes

OS:
Type
major version
minor version
kernel

Software:
database
version
port
setting C
....
application
version
config setting A
setting B
....

You could use services but I need specific fields per service and for automation it would also need to have a "wanted vs found" fields.

eronlloyd Jan 23, 2024

You could do the OS using platforms, as intended, with some custom fields to track things like kernel version, but you'd need to do more work for the rest. The simplest option might be to encode the software versioning and config. info into a JSON field on each device, since software versions could vary more that the OS from device to device.

I wouldn't use services in such case as not every application exposes a network service. To get more sophisticated would require a plug-in, as well as scripts that could automate package inventories for deb, rpm, flatpak, pip, npm, etc.

MalfuncEddie Jan 23, 2024

I agree I suggested this way back

#10569 (reply in thread)

a colum where you can put en jsmpath filter. Come to think of it I prolly can do this now with a custom report ....

eronlloyd Jan 24, 2024

The customization options are so much more powerful now. I started dusting off my netbox-optical plans to get that moving again with all the new enhancements.

mtinberg · 2024-01-23T16:28:43Z

mtinberg
Jan 23, 2024

I personally abuse the Platform model to encode version information for IOS/IOS-XE/NXOS to drive an Ansible playbook which handles version updates, that uses Config Contexts tied to the Platform and Device Type(s) to store the details (firmware file name(s), checksums, etc) and you could do something similar to store the output of say a pip freeze and reference Devices using a Tag or Platform, or using an Object Custom Field on Devices/VMs to reference a config context, if you can then lookup the contents in your config automation. I wouldn't generally automate detailed package inventories such as deb/rpm/pip/npm etc into Netbox as you aren't going to want to manage that level of detail in the Netbox database, however documenting your intent to run FooApp-1.1.2 and maintaining a list of pinned dependencies as JSON or text (if you choose to pin them) associated with it is something that Netbox can facilitate, but you may also manage the full detail in another tool which is built to config manage the target host (Ansible, Terraform, etc.), just keeping the roles and high-level intent in Netbox. It's ultimately a stylistic question with several opinions. — Mark Tinberg ***@***.***> Division of Information Technology-Network Services University of Wisconsin-Madison

…

________________________________ From: Eron Lloyd ***@***.***> Sent: Tuesday, January 23, 2024 5:50 AM To: netbox-community/netbox ***@***.***> Cc: Mark Tinberg ***@***.***>; Comment ***@***.***> Subject: Re: [netbox-community/netbox] Input Needed: Software version Tracking (Discussion #11757) You could do the OS using platforms, as intended, with some custom fields to track things like kernel version, but you'd need to do more work for the rest. The simplest option might be to encode the software versioning and config. info into a JSON field on each device, since software versions could vary more that the OS from device to device. I wouldn't use services in such case as not every application exposes a network service. To get more sophisticated would require a plug-in, as well as scripts that could automate package inventories for deb, rpm, flatpak, pip, npm, etc. — Reply to this email directly, view it on GitHub<#11757 (reply in thread)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AAS7UM5JSBRUKJHQMOAQGZ3YP6PZVAVCNFSM6AAAAAAU5BC6BCVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM4DEMJZGY3TO>. You are receiving this because you commented.Message ID: ***@***.***>

0 replies

atownson · 2024-01-23T21:54:08Z

atownson
Jan 23, 2024

FWIW, we have developed a plugin, which unfortunately we can't share publicly, to track software applications associated with devices and virtual machines.
Here is a brief synopsis of the models we use:

Application - high-level definition for each software (i.e. Splunk Enterprise)
Fields: description, status, manufacturer (FK), comments
Application Instance - A deployed instance of an Application
Fields: application (FK), description, status, environment, version, licensing, comments
Application Assignment - Essentially joins one or more devices and/or virtual machines to an Application Instance
Fields: application instance (FK), device (FK), virtual machine (FK), description, status, comments
Application URL - URLs associated to Application Instances and optionally additionally to Application Assignments. We use this to monitor URLS.
Fields: name, url, description, type, application instance (FK), application assignment (FK)

0 replies

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Input Needed: Software version Tracking #11757

{{title}}

{{editor}}'s edit

{{editor}}'s edit

Replies: 11 comments 12 replies

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{editor}}'s edit

{{editor}}'s edit

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

Select a reply

Input Needed: Software version Tracking #11757

Replies: 11 comments · 12 replies

ryanmerolle Feb 16, 2023 Author

ryanmerolle Feb 16, 2023 Author

ryanmerolle Feb 16, 2023 Author

ryanmerolle Feb 16, 2023 Author

ryanmerolle Feb 19, 2023 Author

Replies: 11 comments 12 replies

ryanmerolle Feb 16, 2023
Author

ryanmerolle Feb 16, 2023
Author

ryanmerolle Feb 16, 2023
Author

ryanmerolle Feb 16, 2023
Author

ryanmerolle Feb 19, 2023
Author