[BUG] LDAP integration issue

[spl33f]

Is there an existing issue for this?

• I have searched the existing issues

Current Behavior

Hello,

I need your help please, I try to figure out LDAP integration with Netbox.

I have the following error message:

<class 'ImportError'>

cannot import name 'ldap_config' from 'netbox' (/app/netbox/netbox/netbox/__init__.py)

Python version: 3.11.6
NetBox version: 3.7.1
Plugins: 
  netbox_ipcalculator: 1.1

I tried LDAP search in CLI and it seems ok, I can retrieve my account info.
"ldap_config.py" is saved in the same directory as "configuration.py"
"init.py" is also present in "/app/netbox/netbox/netbox" but empty.

I also added the following to "configuration.py" file :

LOGGING = {
    'version': 1,
    'disable_existing_loggers': False,
    'handlers': {
        'netbox_auth_log': {
            'level': 'DEBUG',
            'class': 'logging.handlers.RotatingFileHandler',
            'filename': '/config/django-ldap-debug.log',
            'maxBytes': 1024 * 500,
            'backupCount': 5,
        },
    },
    'loggers': {
        'django_auth_ldap': {
            'handlers': ['netbox_auth_log'],
            'level': 'DEBUG',
        },
    },
}

The container starts as expected, the file "django-ldap-debug.log" is created but it is empty.

I defintely missed something 🤔

Expected Behavior

Netbox should synced with LDAP and I should see "authentication and authorization" section in netbox administration page.

Steps To Reproduce

FROM lscr.io/linuxserver/netbox:latest
RUN pip install --upgrade pip && pip install netbox-ipcalculator
RUN echo -e 'netbox-ipcalculator' >> /app/netbox/local_requirements.txt
RUN apk --update --upgrade add gcc build-base openldap-dev python3-dev
RUN pip install --upgrade pip && pip install django-auth-ldap
RUN echo -e 'django-auth-ldap' >> /app/netbox/local_requirements.txt

Change REMOTE_AUTH_BACKEND = 'netbox.authentication.RemoteUserBackend'
to
REMOTE_AUTH_BACKEND = 'netbox.authentication.LDAPBackend'
in configuration.py

Configure LDAP settings in ldap_config.py

Run recommended docker-compose

Environment

What browsers are you seeing the problem on?
Microsoft Edge

Where is your instance running?
Linux Server

Additional context
Using Portainer within Container Manager on Synology NAS

CPU architecture
x86-64

Docker creation

I'm using the recommended docker-compose settings from:
https://docs.linuxserver.io/images/docker-netbox/#docker-compose-recommended-click-here-for-more-info

Container logs

# docker logs netbox
[migrations] started
[migrations] no migrations found
───────────────────────────────────────

      ██╗     ███████╗██╗ ██████╗
      ██║     ██╔════╝██║██╔═══██╗
      ██║     ███████╗██║██║   ██║
      ██║     ╚════██║██║██║   ██║
      ███████╗███████║██║╚██████╔╝
      ╚══════╝╚══════╝╚═╝ ╚═════╝

   Brought to you by linuxserver.io
───────────────────────────────────────

To support LSIO projects visit:
https://www.linuxserver.io/donate/

───────────────────────────────────────
GID/UID
───────────────────────────────────────

User UID:    1026
User GID:    100
───────────────────────────────────────

Building local documentation
INFO    -  Cleaning site directory
INFO    -  Building documentation to directory: /app/netbox/netbox/project-static/docs
INFO    -  The following pages exist in the docs directory, but are not included in the "nav" configuration:
  - index.md
INFO    -  Documentation built in 141.80 seconds
Operations to perform:
  Apply all migrations: account, admin, auth, circuits, contenttypes, core, dcim, django_rq, extras, ipam, sessions, social_django, taggit, tenancy, users, virtualization, vpn, wireless
Running migrations:
  No migrations to apply.
Superuser creation skipped. Already exists.
[custom-init] No custom files found, skipping...
[uWSGI] getting INI configuration from uwsgi.ini
[uwsgi-static] added mapping for /static => static
*** Starting uWSGI 2.0.21 (64bit) on [Mon Jan 22 17:29:37 2024] ***
compiled with version: 12.2.1 20220924 on 28 April 2023 21:13:09
os: Linux-3.10.108 #69057 SMP Fri Jan 12 16:59:54 CST 2024
nodename: netbox
machine: x86_64
clock source: unix
pcre jit disabled
detected number of CPU cores: 4
current working directory: /app/netbox/netbox
detected binary path: /usr/sbin/uwsgi
your memory page size is 4096 bytes
detected max file descriptor number: 1048576
building mime-types dictionary from file /etc/mime.types...1390 entry found
lock engine: pthread robust mutexes
thunder lock: disabled (you can enable it with --thunder-lock)
uwsgi socket 0 bound to TCP address :8000 fd 3
Python version: 3.11.6 (main, Oct  4 2023, 06:22:18) [GCC 12.2.1 20220924]
PEP 405 virtualenv detected: /lsiopy
Set PythonHome to /lsiopy
Python main interpreter initialized at 0x7f6b145d0f78
python threads support enabled
your server socket listen backlog is limited to 100 connections
your mercy for graceful operations on workers is 60 seconds
mapped 203184 bytes (198 KB) for 1 cores
*** Operational MODE: single process ***
running "exec:python3 ./manage.py collectstatic --noinput" (pre app)...
[ls.io-init] done.

0 static files copied to '/app/netbox/netbox/static', 535 unmodified.
running "exec:python3 ./manage.py remove_stale_contenttypes --no-input" (pre app)...
running "exec:python3 ./manage.py clearsessions" (pre app)...
WSGI app 0 (mountpoint='') ready in 5 seconds on interpreter 0x7f6b145d0f78 pid: 153 (default app)
*** uWSGI is running in multiple interpreter mode ***
spawned uWSGI master process (pid: 153)
spawned uWSGI worker 1 (pid: 189, cores: 1)
[pid: 189|app: 0|req: 1/1] 172.16.0.1 () {56 vars in 1103 bytes} [Mon Jan 22 17:30:30 2024] GET / => generated 0 bytes in 64 msecs (HTTP/1.1 302) 8 headers in 262 bytes (1 switches on core 0)
[uwsgi-daemons] spawning "python3 ./manage.py rqworker" (uid: 1026 gid: 100)
[pid: 189|app: 0|req: 2/2] 172.16.0.1 () {56 vars in 1128 bytes} [Mon Jan 22 17:30:30 2024] GET /login/?next=/ => generated 5232 bytes in 12605 msecs (HTTP/1.1 200) 9 headers in 436 bytes (1 switches on core 0)
No queues have been specified. This process will service the following queues by default: high, default, low
17:30:48 Worker rq:worker:056e74c982df4150825bf20e10125962 started with PID 190, version 1.15.1
17:30:48 Subscribing to channel rq:pubsub:056e74c982df4150825bf20e10125962
17:30:48 *** Listening on high, default, low...
17:30:48 Cleaning registries for queue: high
17:30:48 Cleaning registries for queue: default
17:30:48 Cleaning registries for queue: low
17:30:48 Scheduler for default, low, high started with PID 192
[pid: 189|app: 0|req: 3/3] 172.16.0.1 () {66 vars in 1344 bytes} [Mon Jan 22 17:30:46 2024] POST /login/ => generated 2373 bytes in 2844 msecs (HTTP/1.1 500) 8 headers in 319 bytes (1 switches on core 0)
[pid: 189|app: 0|req: 4/4] 172.16.0.1 () {54 vars in 1055 bytes} [Mon Jan 22 17:30:49 2024] GET /favicon.ico => generated 0 bytes in 2 msecs (HTTP/1.1 302) 8 headers in 273 bytes (1 switches on core 0)
[pid: 189|app: 0|req: 5/5] 172.16.0.1 () {54 vars in 1080 bytes} [Mon Jan 22 17:30:49 2024] GET /login/?next=/favicon.ico => generated 5243 bytes in 16 msecs (HTTP/1.1 200) 9 headers in 436 bytes (1 switches on core 0)
[pid: 189|app: 0|req: 6/6] 172.16.0.1 () {58 vars in 1168 bytes} [Mon Jan 22 17:30:53 2024] GET / => generated 0 bytes in 2 msecs (HTTP/1.1 302) 8 headers in 262 bytes (1 switches on core 0)
[pid: 189|app: 0|req: 7/7] 172.16.0.1 () {58 vars in 1193 bytes} [Mon Jan 22 17:30:53 2024] GET /login/?next=/ => generated 5232 bytes in 18 msecs (HTTP/1.1 200) 9 headers in 436 bytes (1 switches on core 0)
[pid: 189|app: 0|req: 8/8] 172.16.0.1 () {66 vars in 1344 bytes} [Mon Jan 22 17:30:56 2024] POST /login/ => generated 2373 bytes in 1406 msecs (HTTP/1.1 500) 8 headers in 319 bytes (1 switches on core 0)
[pid: 189|app: 0|req: 9/9] 172.16.0.1 () {54 vars in 1055 bytes} [Mon Jan 22 17:30:57 2024] GET /favicon.ico => generated 0 bytes in 2 msecs (HTTP/1.1 302) 8 headers in 273 bytes (1 switches on core 0)
[pid: 189|app: 0|req: 10/10] 172.16.0.1 () {54 vars in 1080 bytes} [Mon Jan 22 17:30:57 2024] GET /login/?next=/favicon.ico => generated 5243 bytes in 15 msecs (HTTP/1.1 200) 9 headers in 436 bytes (1 switches on core 0)
[pid: 189|app: 0|req: 11/11] 172.16.0.1 () {40 vars in 672 bytes} [Mon Jan 22 17:31:05 2024] GET / => generated 0 bytes in 2 msecs (HTTP/1.1 302) 8 headers in 262 bytes (1 switches on core 0)
[pid: 189|app: 0|req: 12/12] 172.16.0.1 () {40 vars in 697 bytes} [Mon Jan 22 17:31:05 2024] GET /login/?next=/ => generated 5232 bytes in 15 msecs (HTTP/1.1 200) 9 headers in 436 bytes (1 switches on core 0)

[github-actions]

Thanks for opening your first issue here! Be sure to follow the relevant issue templates, or risk having this issue marked as invalid.

[LinuxServer-CI]

This issue has been automatically marked as stale because it has not had recent activity. This might be due to missing feedback from OP. It will be closed if no further activity occurs. Thank you for your contributions.

[homerr]

What Synology are you using and what kernel is it running?

[spl33f]

majorversion="7"
minorversion="2"
major="7"
minor="2"
micro="1"
buildphase="GM"
buildnumber="69057"
smallfixnumber="4"
nano="4"
base="69057"
productversion="7.2.1"
os_name="DSM"
builddate="2024/01/12"
buildtime="16:52:29"

Linux SERVER 3.10.108 #69057 SMP Fri Jan 12 16:59:54 CST 2024 x86_64 GNU/Linux synology_braswell_716+II

[LinuxServer-CI]

This issue has been automatically marked as stale because it has not had recent activity. This might be due to missing feedback from OP. It will be closed if no further activity occurs. Thank you for your contributions.

[adevries17]

Hi @spl33f I ran into this problem myself and figured it out.

In the image build configuration a symbolic link is being created to the configuration.py file.

To resolve this, I added the following line to my Dockerfile:

COPY ldap_config.py /app/netbox/netbox/netbox/ldap_config.py

[LinuxServer-CI]

This issue has been automatically marked as stale because it has not had recent activity. This might be due to missing feedback from OP. It will be closed if no further activity occurs. Thank you for your contributions.

[OWA-dbell]

I've been trying to get my Netbox install over to docker. I'm using this image and I'm running into the same issues. You can set REMOTE_AUTH_BACKEND='netbox.authentication.LDAPBackend' in the compose file, but it seems to be ignored. Keeps the default setting of 'netbox.authentication.RemoteUserBackend'.

But after editing the configuration.py file directly to set that, it complains that django-auth-ldap isn't installed. When you try to install that, gcc isn't installed, etc.

Getting all of that installed and now we have this error:

<class 'ImportError'>

cannot import name 'ldap_config' from 'netbox' (/app/netbox/netbox/netbox/__init__.py)

when we try to get to the homepage. So it seems a lot is lacking to make REMOTE_AUTH_BACKEND a usable variable.

[thespad]

django-auth-ldap isn't part of the netbox requirements file, which is why it's not installed, but we can add it easily enough.

[OWA-dbell]

django-auth-ldap isn't part of the netbox requirements file, which is why it's not installed, but we can add it easily enough.

would be handy for anybody wanting to use the REMOTE_AUTH_BACKEND set to LDAP.

I think the last thing I'm stuck on is any additional config files I put in my config volume don't get copied over into the container. So I added ldap_config.py in my volume, but it doesn't exist in my container.

[OWA-dbell]

Well, it gets copied over into /config, but doesn't make its way to /app/netbox/netbox/netbox

[thespad]

Yeah that's annoying that they use a separate config file for it, we'd have to pre-symlink it

[OWA-dbell]

Yeah that's annoying that they use a separate config file for it, we'd have to pre-symlink it

seems a number of the ways Netbox does things causes some weird issues. Or maybe its just django. Assuming I manually copy it from /config to /app/netbox/netbox/netbox, I assume it will have to be re-copied any time I update?

[thespad]

When it's built can you see if #60 works for you? I'm creating a symlink for /config/ldap_config.py to /app/netbox/netbox/netbox/ldap_config.py

[OWA-dbell]

While you are looking at that, I went ahead and manually copied it over. seems it also needs a log file that already exists to write to.

[OWA-dbell]

FYI, with a manual symlink it worked. The only other thing I had to do was create a log file (i used /var/log/ldap.log) that the app had access to and authentication is working. I'll re-pull after it is available and test without my manual interventions.

[thespad]

Can you change the log location in the config?

[OWA-dbell]

Can you change the log location in the config?

Yes. There is a section in ldap_config.py:

## Logging
logfile = "/var/log/ldap.log"
my_logger = logging.getLogger('django_auth_ldap')

That location is just where I chose for testing. But it can be pointed anywhere.

[thespad]

Probably makes sense to tell users to log to a writable location rather than trying to preconfigure a log file with the right permissions somewhere

[OWA-dbell]

I imagine so. I guess you could just dump an empty ldap log file somewhere, but would you really do that for every possible thing somebody might want to log? I think I could just remove that from the config as well if I didn't want to log anything.

[dcbell]

@thespad FYI, i just did a pull and the only issue was permission to the log file. Was going to add a volume for it on my compose file, but just commented out logging for LDAP to test and everything seems to have worked.