Port net-mgmt/netbox is a nice tool widely used for IPAM and DECIM maintenance, so I tried to use it for maintenance purposes at work. I never got past the setup, since the example shown in FreeBSD's wiki (https://wiki.freebsd.org/Ports/net-mgmt/netbox) only covers a setup as vhost, which doesn't apply to several setups we use.
I'm not very tight with Apache 2.4, so all my problem may result in a big misunderstanding of how to configure the webserver properly. Maybe with the given setup below someone might shed light on the problem.
Hosts are running recent 11.3-RELEASE-p6, 12-STABLE (FreeBSD 12.1-STABLE #41 r358153: Thu Feb 20 06:05:59 CET 2020 amd64) and recent CURRENT (FreeBSD 13.0-CURRENT #97 r358209: Fri Feb 21 06:43:05 CET 2020 amd64). Ports tree is up to date. On CURRENT and 12-STABLE, ports are compiled the traditional way, on 11.3-RELEASE-p6, we use packages built via poudriere. The problem is on all hosts the same.
On all hosts, REDIS server is running on localhost and is up. On all hosts, Apache 2.4 is installed with the appropriate modules enabled (taken from the above mentioned WIKI). A configuration file has been created in /usr/local/share/netbox/netbox and setup properly. A gunicorn_conf.py has been created in /usr/local/share/netbox as recommended, bind = localhost:8001. Service netbox is up and running.
(for netbox)
# sockstat -4
USER COMMAND PID FD PROTO LOCAL ADDRESS FOREIGN ADDRESS
www python3.7 75357 6 tcp4 127.0.0.1:8001 *:*
www python3.7 75356 6 tcp4 127.0.0.1:8001 *:*
www python3.7 75355 6 tcp4 127.0.0.1:8001 *:*
www python3.7 75353 6 tcp4 127.0.0.1:8001 *:*
[...]
redis redis-serv 11433 6 tcp4 127.0.0.1:6379 *:*
[...]
When starting the test instance of the netbox service via
python3 magage.py runserver IP:8000 --insecure
we can use netbox via port 8000 and everything is all right except the initial page, which is reported to be not found. Trying to use netbox via Apache 2.4 setup, results in a flat, not rendered initial page. Enabling
"LOGIN_REQUIRED = True"
in /usr/local/share/netbox/netbox/configuration.py results in a kind of recurively resolved login in the URL field of the Firefox browser, which quits with an internal error after two or three retries due to line lenth exceeding > 4096 characters.
The configuration for Apache 2.4 is like this, located in /usr/loca/etc/apache24/Includes/netbox.conf
[...]
Alias /netbox /usr/local/share/netbox
SSLPRoxyEngine on
<Directory /usr/local/share/netbox>
Options Indexes FollowSymLinks MultiViews
AllowOverride None
WSGIPassAuthorization on
RequestHeader set "X-Forwarded-Proto" expr=%{REQUEST_SCHEME}
<RequireAny>
Require ip 127.0.0.1/8
Require ip ::1/128
<RequireAll>
Require ssl
<RequireAny>
Require ip fd11:a773:2201::/64
Require ip 192.168.1.0/24
</RequireAny>
</RequireAll>
</RequireAny>
</Directory>
<Location /netbox/static>
ProxyPass !
</Location>
<Location /netbox>
ProxyPass http://localhost:8001/
ProxyPassReverse http://localhost:8001/
</Location>
[...]
On boxes with IPv6 enabled (dual stack systems), CURRENT and 12-STABLE, there is a nother issue wity netbox: According to the sockstat output shown above, there is NO(!)
[::1]:8001
entry showing up, so I assume there is no local Proxy running on any IPv6 address which could be addressed via localhost:8001, resulting in a forever non-responding web page once accessed.
I'm not very tight with Apache 2.4, so all my problem may result in a big misunderstanding of how to configure the webserver properly. Maybe with the given setup below someone might shed light on the problem.
Hosts are running recent 11.3-RELEASE-p6, 12-STABLE (FreeBSD 12.1-STABLE #41 r358153: Thu Feb 20 06:05:59 CET 2020 amd64) and recent CURRENT (FreeBSD 13.0-CURRENT #97 r358209: Fri Feb 21 06:43:05 CET 2020 amd64). Ports tree is up to date. On CURRENT and 12-STABLE, ports are compiled the traditional way, on 11.3-RELEASE-p6, we use packages built via poudriere. The problem is on all hosts the same.
On all hosts, REDIS server is running on localhost and is up. On all hosts, Apache 2.4 is installed with the appropriate modules enabled (taken from the above mentioned WIKI). A configuration file has been created in /usr/local/share/netbox/netbox and setup properly. A gunicorn_conf.py has been created in /usr/local/share/netbox as recommended, bind = localhost:8001. Service netbox is up and running.
(for netbox)
# sockstat -4
USER COMMAND PID FD PROTO LOCAL ADDRESS FOREIGN ADDRESS
www python3.7 75357 6 tcp4 127.0.0.1:8001 *:*
www python3.7 75356 6 tcp4 127.0.0.1:8001 *:*
www python3.7 75355 6 tcp4 127.0.0.1:8001 *:*
www python3.7 75353 6 tcp4 127.0.0.1:8001 *:*
[...]
redis redis-serv 11433 6 tcp4 127.0.0.1:6379 *:*
[...]
When starting the test instance of the netbox service via
python3 magage.py runserver IP:8000 --insecure
we can use netbox via port 8000 and everything is all right except the initial page, which is reported to be not found. Trying to use netbox via Apache 2.4 setup, results in a flat, not rendered initial page. Enabling
"LOGIN_REQUIRED = True"
in /usr/local/share/netbox/netbox/configuration.py results in a kind of recurively resolved login in the URL field of the Firefox browser, which quits with an internal error after two or three retries due to line lenth exceeding > 4096 characters.
The configuration for Apache 2.4 is like this, located in /usr/loca/etc/apache24/Includes/netbox.conf
[...]
Alias /netbox /usr/local/share/netbox
SSLPRoxyEngine on
<Directory /usr/local/share/netbox>
Options Indexes FollowSymLinks MultiViews
AllowOverride None
WSGIPassAuthorization on
RequestHeader set "X-Forwarded-Proto" expr=%{REQUEST_SCHEME}
<RequireAny>
Require ip 127.0.0.1/8
Require ip ::1/128
<RequireAll>
Require ssl
<RequireAny>
Require ip fd11:a773:2201::/64
Require ip 192.168.1.0/24
</RequireAny>
</RequireAll>
</RequireAny>
</Directory>
<Location /netbox/static>
ProxyPass !
</Location>
<Location /netbox>
ProxyPass http://localhost:8001/
ProxyPassReverse http://localhost:8001/
</Location>
[...]
On boxes with IPv6 enabled (dual stack systems), CURRENT and 12-STABLE, there is a nother issue wity netbox: According to the sockstat output shown above, there is NO(!)
[::1]:8001
entry showing up, so I assume there is no local Proxy running on any IPv6 address which could be addressed via localhost:8001, resulting in a forever non-responding web page once accessed.