@nhl-pl Good resource, thanks for sharing!

The issue tracker feature is switched off for Chrischenny/nodebb-plugin-node-ldap-ad, so I'm not sure what else to do, unless he happens to be active in the forums here.

It seems kind of silly to open a PR against his repo, just to ask him to please open a PR against another repo, when I can just as easily do the latter myself.

@nhl-pl Since the Dockerfile in the NodeBB is currently misbehaving as stated above, or at the very least the documentation is lacking in that it doesn't tell you you must create a local node user*, do you have a recommendation of how to move forward?

* …at least I think that's the problem/solution

@nhl-pl OK, thanks.

I get that, but my question is why is the one that shows up when you search for "ldap" coming from a third-party repo, rather than the (semi-)official NodeBB-Community GitHub org?

Certainly not trying to minimize Chrischenny's contributions, and maybe it's just an oversight, but it makes more sense for a plugin like this one (especially like this one) to be under the watchful eye of more people, with more checks in place to prevent something untoward from happening to the code.

I'd be willing to do a PR against NodeBB-Community/nodebb-plugin-node-ldap that preserves Chrischenny's fixes, and also fix package.json to restore the original authors' names. Does that help resolve this?

What I'm not sure about is how to make sure the NodeBB-Community/nodebb-plugin-node-ldap version of the plugin shows up in search in the admin panel. Is there a review/approval process for community plugins that I just overlooked in the documentation? (probably the case)

Does anyone know why the LDAP plugin you find in plugin section of the admin panel coming from a third-party repo, rather than the official (?) NodeBB-Community/nodebb-plugin-node-ldap repo it was originally forked from?

@nhl-pl At first I didn't know what I was looking at, and just thought, well, that's what the Dockerfile in the NodeBB repo already does, so why is this interesting?

But they're similar enough that maybe there was some cross-pollination of the NodeBB Dockerfile with the setup scripts for the Podman rendition, from the nobbic repo. Things were copy-pasted because they worked, not because they were needed. That's relatable though.

The nobbic maintainers helpfully commented the script(s), which is really the only way to let other people inside your head about decisions like this. The why of it is probably still not clear to me just due to my relative inexperience with running production web applications in containers.

@douglasparker said in error "permission for /opt/config nodebb" in installing with Docker compose:

@ernstki It’s best practice to drop down to a non root user for docker images for security purposes.

Agreed, in any other context. My Docker daemon is already running non-root, which I thought was the actual best practice.

I get that container security is complex, and the topic of countless blog posts and conference talks, but the fact remains I've not (yet!) seen many other examples of popular containerized software in the wild doing this in their Dockerfiles, and that incongruity is what made me wonder.

I'm starting to wonder if this is a reportable bug, since it appears to be the same script everyone else is running, and that referred to by the documentation.

Does anyone know the analog of that when running inside the Docker container? The nodebb inside the container doesn't seem to understand start, stop, or any of the other subcommands documented here, but rather just tries to start the server (again) regardless of what option is given:

$ docker-compose exec nodebb ./nodebb --help
2024-01-10T04:24:22.786Z [2454] - info: Launching web installer on port 4567
2024-01-10T04:24:23.439Z [2454] - info: [installer] Found setup.json, populating default values
2024-01-10T04:24:32.763Z [2454] - error: uncaughtException: listen EADDRINUSE: address already in use :::4567
Error: listen EADDRINUSE: address already in use :::4567
    at Server.setupListenHandle [as _listen2] (node:net:1872:16)
    at listenInCluster (node:net:1920:12)
    at Server.listen (node:net:2008:7)
    at Function.listen (/usr/src/app/node_modules/express/lib/application.js:635:24)
    at launchExpress (/usr/src/app/install/web.js:100:15)
    at web.install [as webInstall] (/usr/src/app/install/web.js:85:3) {"date":"Wed Jan 10 2024 04:24:32 GMT+0000 (Coordinated Universal Time)","error":{"address":"::","code":"EADDRINUSE","errno":-98,"port":4567,"syscall":"listen"},"exception":true,"os":{"loadavg":[1.19,0.83,1.02],"uptime":30791.73},"process":{"argv":["/usr/local/bin/node","/usr/src/app/nodebb","--help"],"cwd":"/usr/src/app","execPath":"/usr/local/bin/node","gid":0,"memoryUsage":{"arrayBuffers":7123005,"external":10782422,"heapTotal":112189440,"heapUsed":79256000,"rss":193617920},"pid":2454,"uid":0,"version":"v20.10.0"},"stack":"Error: listen EADDRINUSE: address already in use :::4567\n    at Server.setupListenHandle [as _listen2] (node:net:1872:16)\n    at listenInCluster (node:net:1920:12)\n    at Server.listen (node:net:2008:7)\n    at Function.listen (/usr/src/app/node_modules/express/lib/application.js:635:24)\n    at launchExpress (/usr/src/app/install/web.js:100:15)\n    at web.install [as webInstall] (/usr/src/app/install/web.js:85:3)","trace":[{"column":16,"file":"node:net","function":"Server.setupListenHandle [as _listen2]","line":1872,"method":"setupListenHandle [as _listen2]","native":false},{"column":12,"file":"node:net","function":"listenInCluster","line":1920,"method":null,"native":false},{"column":7,"file":"node:net","function":"Server.listen","line":2008,"method":"listen","native":false},{"column":24,"file":"/usr/src/app/node_modules/express/lib/application.js","function":"Function.listen","line":635,"method":"listen","native":false},{"column":15,"file":"/usr/src/app/install/web.js","function":"launchExpress","line":100,"method":null,"native":false},{"column":3,"file":"/usr/src/app/install/web.js","function":"web.install [as webInstall]","line":85,"method":"install [as webInstall]","native":false}]}

I wish I had better Docker comprehension to establish what the original author of the Dockerfile in the repo was trying to accomplish, with regards to all the USER nodes and chmods. Don't Docker services normally just run as the root user inside the container?

In any event, if you remove all the chown -R node:nodes, --chown=node:nodes, and USER nodes from the Dockerfile, then docker-compose build, then docker-compose up, you might have yourself a workaround. That's what I did. Granted, I'm not running a Docker image in production, just trying NodeBB out for the first time. A bad time to run into a problem like this, to be honest—fortunately I'm stubborn/persistent. :)

If you need more of a nudge than the above, I'd encourage you to wait until someone with more experience weighs in on the discussion here, in the PR that originated these changes to the Dockerfile.