Cloudron Forum

@staypath Yes, I tried to keep things simple with my approach. I am not aware of any Node-RED core functionality that is not working. By using the Cloudron proxy as auth in front of Node-RED, it is single user only though and would be tricky to combine it with auth-mechanisms within Node-RED. This is probably the biggest downside to my approach.
Another thing, that I would do differently is the approach to send out e-mails. I wanted to make use of the per-app smtp settings that Cloudron provides and pre-provision that transparently into Node-RED. That lead to quite some "glue" in between that seemed somewhat disproportionate in the end.
I should update my repository to a newer Node-RED version by the way and will probably remove the e-mail part at that point.

Ok, thanks for the update. Works for me as it is, but was curious if the ideas discussed above are still to be implemented.

As far as I see, this has not been implemented yet. Is there any news on SFTP access for volumes? Either through the apps operator access or separate passwords?

Sure, here is what I did:
I took the supervisord-setup of the tutorial-supervisor-app as a template. One process is apache, as in the default lamp-app. The other process I start is a custom bash-script which sleeps for a longer amount of time and then performs a log rotation including the "apachectl graceful" mentioned above. After that it exits and gets restarted by supervisord.

@robi I know containers are isolated from each other. I was just surprised to figure out that cronjobs via the Cloudron UI oder the scheduler in the app manifest are run in a separated container. Hence my question how to signal apache from the outside.
But I solved it for me, by running a separate process within the same container

Thanks for your replies, @girish, @robi. Both good ideas for further improvement, but they do not adress the main problem I encountered. 'apachectl graceful' is equivalent to the 'kill -s USR1' approach I described above.

My point was that the signal does not reach the apache process, if called from a separate cron-environment. I could solve this through the use of supervisord though.

I went forward now by using supervisord. Instead of starting apache directly as init process, supervisor takes care of starting apache. My log rotation script gets started in parallel and thus has the ability to send signals to the apache process. This works as well of course, but is way more complex. My inital hope was to be able to utilize the scheduler/cron facilities of cloudron, but I could not figure out a way how to solve the problem mentioned above.

As a matter of fact, I created a custom lamp package already. I also tried using the scheduler addon instead of the cron-entry in the app settings. But also that one seems to be run in a different container.

I could of course use supervisor to start things in parallel within my container. But my line of thought was to use the existing cron-mechanisms that Cloudron provides. Hence my question if anyone knows of alternative ways to accomplish the apache restart.

Restarting the whole app would indeed also restart apache. But this is not what I want. I only want to send a USR1 signal, which is equivalent to 'apachectl graceful' as described here: https://httpd.apache.org/docs/2.4/logs.html#rotation

In my case, I want to import some custom logs (with different level of details based on the headers set) into Matomo. Before importing the log file, I want to rotate the logs and ask apache to reopen its log files.

Hi,

I have some custom logging configured in apache/app.conf. For log rotation purposes I want to restart apache gracefully. On the web terminal using 'kill -s USR1 1' works as expected. (PID 1, since apache is the init process within the container.)

The same does not work, when executing the script form the web-based cron configuration within the app settings. This surprised me at first, bit seems logical considering that the cron-tasks are executed within their containers. A signal sent to PID 1 will be the cron process itself ...

-> Does anyone have an idea how to solve this? Does apache have any mechanism to trigger a graceful restart "remotely"? Or any clever way to get the process signal from one container to the other?

@girish said in Node-RED - Flow-based programming for the Internet of Things:

The app package uses the Cloudron sendmail and mongodb addons. Mails can be sent using node-red-contrib-sendmail and the database can be accessed using node-red-contrib-mongodb4. Both modules come preinstalled and are preconfigured using the environment variables that Cloudron exports.

Nice, as expected of any cloudron app email and db are auto-configured.
Both are not required to run Node-RED though. They are optional modules that can be used within flows that one wants to implement, but have no functionality for the core itself. Still, I thought that its useful to be able to access the functionality that Cloudron as a platform provides.

Implementing LDAP, as @staypath has done, also has its benefits though. I'm currently a bit indecisive which approach is preferable.

Does node-red have a real concept of users and roles ? Meaning, can individual users create and manage separate flows?
I'm relatively new to Node-RED myself and can't tell with certainty. As far as I understand the documentation, one can differentiate between users and assign specific permissions for different methods of the API (create a flow, enable a module, etc.), but cannot differentiate between flows. Flows seem to be shared between users in any case. So it's not a real multi-user application, where each user can create their own flows. This post proposes to run multiple node-red instances if users shall be able to create independent flows.

When LDAP is implemented, who provides the login page? Is this part of some plugin?
The login page seems to be the default one provided by Node-RED. It is only the authentication-scheme which is plugged in through an extra module.

The LDAP-module does not seem to support different permissions though. Each user with valid credentials gets full permissions (see this line).

I've been working on a Cloudron-app for Node-RED as well. Using node-red-docker and adapting it to Cloudron felt too complicated to me. So, as opposed to the app package that @staypath has been working on, I started with a Cloudron package from scratch.

You can find my repo here: https://git.vereint-digital.de/hendrik/node-red-app

Node-RED itself is simply installed through npm, so the code does not come bundled in the repo itself. Since Node-RED does rely on npm quite a lot anyhow, that seemed more straightforward to me. Plus it makes the Dockerfile really simple.

The code of Node-RED itself (including three modules that are installed out of the box) is located in /app/code. The node-red userdir is in /app/data. So updates of node-red should work, but I've not been testing it long enough to tell.

The app package uses the Cloudron sendmail and mongodb addons. Mails can be sent using node-red-contrib-sendmail and the database can be accessed using node-red-contrib-mongodb4. Both modules come preinstalled and are preconfigured using the environment variables that Cloudron exports.

I must say though, that I do not feel too confident about my solution to send mails. I initially thought, that it would be easier to utilize a command line mail utility, but it turned out to be quite complex as well. In the end, I had to write my own script to act as mail utility, so that it matches the assumptions of node-red-contrib-sendmail. Writing a custom Node-RED module that uses Nodemailer and accesses the Cloudron environment variables probably would have been a better approach.

For authorization, I currently use Cloudron proxyauth and only leave one route (/public) unprotected. Since custom user authentication can be implemented in Node-RED quite easily, it would be highly beneficial to have the authenticated user as part of the request headers, as discussed here. Implementing LDAP, as @staypath has done, also has its benefits though. I'm currently a bit indecisive which approach is preferable.

I hope this is helpful to others, who want to use Node-RED on Cloudron. And maybe we get the discussion on including Node-RED in the app-store going again.

@plan-a The same applies for other settings, such as Webhook URL and message. They are emptied when logging in again.

I use a Hetzner storagebox via sshfs as backup provider and also have the issue with the volume being not mounted after reach reboot. Clicking the remount volume button solves it for me though. All previous backups are correctly listed after remounting.

Having to remount the volume manually is somewhat annoying though and I would appreciate a solution which solves the issue with the circular dependency on boot.

I had the same issue with a custom app I created. My solution was to include a webserver that runs in parallel via supervisord, although my custom app would not require it for its own functioning.
A sample of what this could look like is in the supervisor demo-app: https://git.cloudron.io/cloudron/tutorial-supervisor-app/
The webserver in there only returns a static page with status code 200, which is all you need to pass the health-check.

Thinking more about it, the option b) I considered above seems too much effort to implement. Creating a directory structure, including document types and everything, from information stored in the DB could lead to a usable result, but would require some tinkering on both sides. If one would invest that effort, why not create a Nextcloud App providing a custom external storage, which connects to the paperless-ng API (https://paperless-ng.readthedocs.io/en/latest/api.html). Such a solution would not depend on manual configuration of Cloudron volumes and could be used straight from Nextcloud. I wonder if there is anything like that out there already, but could not find anything related on a quick search.

@girish Ok, good to know that the fix is already there. Thanks!

The users page in the Cloudron panel has that setting labeled "Allow users to edit their name and email", which is also named profile lock in the manual.

When that checkbox is disabled (users are not allowed to edit), I noticed some strange behaviour: New users can be created, but they cannot set their password after using the invite link. What happens instead is the following: User clicks invite link, gets screen where to input password. After submitting that form the next screen "Your Account is ready, open dashboard" is shown. But after clicking open dashboard, one gets to the regular login screen. From there one cannot login with the newly setup credentials.

I checked in the box-database what happens: After creating the user, the new entry in the users-table seems correct. What is strange is that even the moment the "Your account is ready"-screen is shown, the password-field has not changed and the inviteToken is still there. There is no difference whether the profileLocked-parameter is included in the invite-URL or not.

After enabling the checkbox in the users page again, the setup works allright. Even with the old invite-link.

I could reproduce that behaviour on two different cloudron instances being on v7.0.4.

I also thought about that, since I would like to be able to access my scanned documents from Nextcloud as well.
I considered to use a separate volume as data exchange between paperless-ng and Nextcloud. On the Nextcloud side one could use the external storage-app to get /media/volumeXYZ "mounted" in the Nextcloud. The question is how to get the archive-folder of paperless-ng to that volume.

I currently see two options for that:
a) Configure paperless-ng to use the volume as media-root (PAPERLESS_MEDIA_ROOT in /app/data/paperless.conf). That way all folders thumbnails, originals and archive would be on the volume. But with the external storage-app one could make only of them (most likely the archive one) accessible from Nextcloud. Biggest disadvantage I see: Documents would have OCR on them, but are only accessible by ID from Nextcloud (no document types or tags).
b) Leave the media-root in /app/data as it is by default, but copy all files to the volume once they have been processed by paperless. That would most likely require a custom cronjob, but maybe there is also some post-processing option available in paperless? Disadvantage: even more tweaking necessary and duplicate storage requirements. Advantage I see with that option: One could implement something to include captions, tags or document types in the filenames, making files easily accessible from Nextcloud as well.

I only recently discovered, that cloudron uses a local unbound installation as DNS recursor and ignores DNS servers that were in /etc/resolv.conf before installing cloudron. Using unbound to include the local cloudron network, seems a good idea, but I am wondering whether using root DNS servers is necessary. (This is at least what happens on my machine, when resolving external hostnames: unbound queries its way down from the root DNS servers)

As an alternative to the root DNS servers I added a new config /etc/unbound/unbound.conf.d/forward.conf:

forward-zone:
        name: "."
        forward-addr: 1.1.1.1
        forward-addr: 8.8.8.8

(Cloudflare and Google DNS servers just as an illustration, I used the ones from my VPS hoster)

Two questions/points for discussion on this:

1. Do you see any problems how this could interact with the local name resolution in an unintended way?

2. Would it be a good idea to generate such a config file as an optional step during the web-based Cloudron-setup?