Rack half-units appear to be counted towards unit count when adding or editing a device

[wxnarwhal]

NetBox version

v3.4.5

Python version

3.10

Steps to Reproduce

1. Create new rack - rack shows available rack units.
2. Add new device from global menu (NOT by clicking on the rack diagram)
3. Available rack positions are half the real number, with half positions displayed.

Expected Behavior

Correct number of RU down to 1 should exist.

Observed Behavior

Example: Add 42U Rack. Add device. Select Rack Unit while adding device and options go from 42U, 41.5U, 41U ..... down to 21U. Nothing below 21U exists.

[kkthxbye-code]

Please revise your steps as I cannot replicate this on v3.4.5.

[wxnarwhal]

Thanks for your help. I have some additional info.

First, it's happening to my old racks too, so it's not just the new racks I added.

I verified it happens in Chrome and Firefox, so it's not just a display issue.

I appear to have the count wrong in my first report. Here are some examples I looked at:

• 45U rack cuts off at U21
• 44U rack cuts off at U20
• 42U rack cuts off at U18

So it appears to be limited to 25 units, or 50 half-units, no matter what the total count is.

This only affects me being able to add a new device if I don't select "add device" from the rack position, or if I try to move an existing device. I would have to delete it to add it to the correct position.

If I do select "add device", then that position will appear at the top of the list, and the other 50 half positions below. I've attached a screenshot where I did that with U6.

[kkthxbye-code]

Your browser is not loading the next page as the drop-down gets 50 at a time and loads the next page when scrolled to the bottom.

Test on the demo site, if it works there the issue is your netbox instance, if it doesn't work it's your browser/PC.

If the issue is with your instance you might have upgraded incorrectly and not run collectstatic (which is normally ran with the upgrade script).

[wxnarwhal]

Thanks for your help. It works fine on the demo site.

I ran upgrade.sh again. I still have the same problem. Among the output I see:

`Collecting static files (python3 netbox/manage.py collectstatic --no-input)...

497 static files copied to '/opt/netbox-3.4.5/netbox/static', 34 unmodified.
Removing stale content types (python3 netbox/manage.py remove_stale_contenttypes --no-input)...`

It seems to execute with no errors. Anything else I can try?

[kkthxbye-code]

You can check the console and the network tab in the chrome developer tools for any errors or failed requests.

[wxnarwhal]

Thanks for the tip. I really appreciate it when people take time to help. I think the issue is that I have my server to only allow https, and even though I have redirects in nginx to capture all http requests, it appears NetBox is trying to force some files to only load http. I didn't change anything on my server, I only did the NetBox upgrade, so I am wondering if it's a change in NetBox. I will see if I can fix it server-side though.

[candlerb]

it appears NetBox is trying to force some files to only load http

Netbox generates absolute URLs for some links. It needs to see the header "X-Forwarded-Proto: https" to know that you are accessing the site via HTTPS, and hence to generate https:// urls.

If you followed the sample nginx config then you should have a line like this:

        proxy_set_header X-Forwarded-Proto $scheme;

If you don't, then that's almost certainly the problem. If you do have it, then try hard-coding

        proxy_set_header X-Forwarded-Proto https;

Also, try using tcpdump on the traffic between nginx and Netbox to see if this header is being provided:

tcpdump -i lo -nn -s0 -A tcp port 8001

Another place where Netbox generates absolute links is in rack elevations. If you hover over a slot in a rack elevation, do you see a https:// or http:// link?

[kkthxbye-code]

so I am wondering if it's a change in NetBox.

NetBox has a very large userbase, so in all likelyhood we would have had way more reports if that was the case. The issue is very likely with your nginx configuration or something else specific to how you run your instance.

I'll convert this to a discussion as I don't believe there is anything to fix here. If it turns out I'm wrong, we'll just convert it back :)