Permissions on netbox_home directory

[lae]

Permissions on netbox_home directory

[lae]

Is this just an issue with nginx accessing static assets? I don't recall stumbling into this issue at my last job, but we were using Debian (which seems to use 0755 for homedirs). I'll try to repro this sometime.

If this is just a RHEL issue, setting perms on the netbox homedir to 0711 might be fine, but I think it might be necessary to consider that folks may be using selinux on these systems and overriding default perms might get in the way.

[kdhlab]

Is this just an issue with nginx accessing static assets?

Basically, yeah. I imagine you would run into a similar problem with any reverse proxy where you tried to split the static assets out from the uwsgi socket for efficiency. I'm guessing this is an edge case where most people are either happy running uwsgi direct to a TCP port or where they are just fine with sending everything down the socket. Here is an example config where I ran into this just for an example:

server {
    listen 80 default_server;
    server_name _;
    return 301 https://$host$request_uri;
}
server {
    listen 443 ssl default_server;
    server_name _;
    ssl_certificate /etc/pki/tls/certs/netbox-dev.crt;
    ssl_certificate_key /etc/pki/tls/private/netbox-dev.key;
    ssl_trusted_certificate /etc/pki/tls/certs/netbox-dev-chain.crt;
    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_ciphers HIGH:!aNULL:!MD5;
    ssl_prefer_server_ciphers on;
    ssl_session_cache none;
    ssl_session_timeout 5m;
    ssl_stapling on;
    ssl_stapling_verify on;

    location / {
        uwsgi_pass unix:///tmp/netbox_uwsgi.sock;
        include uwsgi_params;
        add_header X-Real-IP "$remote_addr";
        add_header X-Forwarded-Proto "$scheme";
        add_header X-Forwarded-Host "$http_host";
    }
    location /static/ {
        alias /opt/netbox/current/netbox/static/;
        autoindex on;
    }

I don't recall stumbling into this issue at my last job, but we were using Debian (which seems to use 0755 for homedirs). I'll try to repro this sometime.

Yeah it's odd, because it is only the actual dir that gets created as part of the user module that has that funky permission set. everything that gets created after that with the file task has 0755. Our org works exclusively in cent/rhel so I haven't really put any time into seeing if it is a distro thing.

If this is just a RHEL issue, setting perms on the netbox homedir to 0711 might be fine, but I think it might be necessary to consider that folks may be using selinux on these systems and overriding default perms might get in the way.

I'm running selinux in my dev environment where I am seeing this so maybe that has something to do with it, but in general I know selinux isn't supposed to modify folder permissions apart from the bits it handles. Maybe that permissions change is a consequence of selinux bieng enabled. I'll spin up a dev box tomorrow and see if it does the same thing if I disable selinux completely before installing the role.

[tyler-8]

My initial thought is this shouldn't be handled by the role, because this role isn't dictating how your NetBox environment is served up, the OS it's on etc. Given that this role is designed to be part of a larger playbook, where a task to change up permissions (and configure nginx, selinux, etc) would be, I would say leave it up to the user to decide what to do in this case.

[madeinoz67]

I'm having similar issues as have just been been trying to implement nginx as a RP on centos purely for SSL/TLS

@kdhlab did you find a workaround by any chance?

[madeinoz67]

ok what worked for me as a future FYI

added in my deploy nginx runbook

pre_tasks:

   - name: Fix Netbox home permissions
     file:
        path: "{{ netbox_home }}"
        state: directory
        mode: '0711'