Cloudron Forum

Hi everyone,
the current version of Joplin (2.3.2) suddenly throws a rather strange error and became unresponsive.

 $ yarn run [--inspect] [--inspect-brk] [-T,--top-level] [-B,--binaries-only] [--require #0] <scriptName> ...
Usage Error: The nearest package directory (/app/code/packages/server) doesn't seem to be part of the project declared in /app/code.
- Finally, if /app/code is fine and you intend packages/server to be treated as a completely separate project (not even a workspace), create an empty yarn.lock file in it.
 - If /app/code is intended to be a project, it might be that you forgot to list packages/server in its workspace configuration.
 - If /app/code isn't intended to be a project, remove any yarn.lock and/or package.json file there.
 => Healtheck error: Error: Timeout of 7000ms exceeded

Most interestingly it occured days after the 2.3.2 update and I couldn't identify any other factors that could have caused this.
Does anyone have an idea how to solve this?

Just as a sidenote: Had similar issues recently - Nextcloud appeared to be the issue, more specifically Nextcloud brought the backup process into some strange shenanigans which crashed the whole VM.
I had no time to properly investigate, though, and we do not use nextcloud really, so I simply uninstalled it. Fixed it.

To bring up this issue again: With Keycloak there is now another app that realistically doesn't need to be seen by the everyday user - but they still need access to it if login e.g. to a reverse proxied app, etc. is done through it. So it would be beneficial to have the ability to hide apps either by group or at least "non admin users".

I am also using app proxy,but my question is unrelated to that, nebulon has already noted the intended use Peter (and now I) meant.

Is there any update on this? The current system of allowing all users is a bit suboptimal.

As the MeshCentral Development has taken up speed again after a bit of a hiatus: is there any update on it on Cloudron? Would be an extremely powerful addition, especially together with OIDC.

@umnz Thanks for the confirm, can report the same meanwhile - Hetzner Proxmox, regular 24.04LTS Ubuntu as a VM works as smooth as the old installs did.
The only two problems I encountered are more app related.

So can new installations now be done on 24.04 LTS directly if they are already V8?

Hi,
I know developers rightfully hate nothing more than "are we there yet/when are you done" questions, but could you give a rough guess how far 8.0 is away currently?

We will need to move two servers and while we still got a bit of time a rough guess would enable us to decide if it's worth installing the current version or wait for 8.0 and do a clean Ubuntu 24.04 LTS(which would make a few other things easier for us). We are totally happy to wait (it's done when it's done), but I would hate to install two new installations and then 8.0 comes out 3 days later.

Considering that Discord has said goodbye to it's (never true) ad-free policy as well a revolt is currently gaining more traction again.
(https://www.techspot.com/news/102455-discord-looks-boost-gaming-revenue-ditching-long-time.html)
It might be a even more interesting addition now.

Would be quite an interesting business case for smaller corp. users tbh - KASM can do something similar with their sidecar VPN service (or docker desktop with integrated VPN as it's now available with the development version). This enables users to use the Kasm frontend (which is basically Guacamole), connect to docker desktop instance and then use a VPN to the desktop to the Final destination (e.g) in a jumpserver setting.
The downside is the ridiculous pricing of Kasm workspaces for commercial customers - 600-1200$ for a rarely used tool is unfeasible for most smaller customers.

Cloudron could really be useful as a "rougher but still working solution":
While we have no Docker desktop on Linux, these could easily be hosted elsewhere and are provided by various projects.
BUT people should not keep these desktops publicly available via VNC/RDP - That is where Guacamole cones into play.
One option would be to use Guacamole to point to an internal network "behind" a Cloudron instance in a DMZ. But that is currently not possible as Cloudron basically only supports one network,right?
(See my other topic about this from 2022)

The other, imho much easier to achieve, option would be to make Cloudron internal network connection to OpenVPN instances (Portainer is an example of a project than has done similar things) on a container to container base - e.g. letting Guacamole connect to a WG/OpenVPN to then connect to the required external resources.
Even without providing a actual Docker Desktop it would still make it much much easier and safer to provide properly separated infrastructure.
(Besides, in my jumpserver scrnario of course Guacamole alone can act as an direct Jump to the target infrastructure then).

Tbh,I currently don't see a way for people to safely use Guacamole on Cloudron in a public environment safely at all.

Offering something in that regard would be an compelling business case, even nore so as Cloudron of course offers a massive "SSO" solution for all the other business needs as well.

@girish We would actually ve willing to sponsor that feature at least partially-Feel free to contact me.

The last post in regards of this is from 2022, is there any update on this functionality? It would be very interesting if one could use Cloudron to connect to a VPN server - e.g. to use Guacamole as a support tool.

Yeah, would absolutely love that as well. Rustdesk is generally solid, but selfhosted via Cloudron would be really nice.

Considering the bad shape Calibre Web is after all these years (Not Cloudron,I mean thebase) and how great Kavita meanwhile has become I am also fully in support of bringing that to Cloudron.

@Kubernetes said in No option to select folders?:

I mounted a Hetzner Storage Box to my Audiobookshelf App and specified this path (just replace the \ ) :

/media/storagebox-nextcloud-bx11/audiobooks

if you want to just use the common App storage, you should specify /app/data/audiobooks

You are a rockstar! I spent half a day to figure that out before I for some reason saw your post... Thanks, mate!

That will be indeed very interesting. Zabbis is the only real reason I currently still run a parallel yunohost installation.

I was about to write a entry about Tandoor here myself but you were faster.
Thank you for that, absolute something worth supporting.

@girish
As requested:
https://forum.cloudron.io/topic/7839/more-than-1-network-nic-bind-container-to-networks/1

Hi,
as requested by @girish a feature request thread following a discussion here:

Current situation:
(Please correct me if I am wrong here)
At the moment cloudron only "listens" to one NIC per OS instance it is deployed upon. This is usually (and recommended to be) a public IP.
Requests from other NICs are not handled or not properly handled.

Feature request:

• Allow cloudron to listen to more than one NIC at the same time (but not hard-coded all)
• Allow cloudron to listen to more than one network&IP at the same time at least via different NICs (**)
• Allow cloudron admins to govern what networks a app listens to.

(*: As this could kill the setup of some bare-metal users I recon, e.g. when they have other services running on the same machine already)
(**: I am fully aware that this could also facilitated with one NIC in a lot of cases, but this would require far more modifications on the base OS, so maybe we should split these requirements to later FRs)

Reasoning/scenario:
Keeping internal and external networks appart is always a good idea and network segration has is a de facto industry standard for ages now but has become even more important in cases where IoT or guest devices are used within an internal network.

While some users mainly provide only public facing (e.g. LAMP, Wikis, Helpdesk for customers) or only internally facing services (internal Wiki, Media content, etc.) a deployment in a DMZ - in a laymans words: the middle ground between Internal&external networking- makes sense.
(Note: This of course be also facilitated by using two or more separate cloudron instances if you have a seperate set of apps for internal and external and I would recommend this security wise, but it is outside the scope of cloudron if you don't - keeping Apps synched is it's own game)*

Now, in theory you could always let your internal hosts use the "outside" network to access cloudron - but that is often undesired e.g. for security reasons and additonally puts load on your WAN/UTM/FW.

Especially on virtualized cloudron hosts (e.g. on a bridged Proxmox setup) the easiest way for many users might be to just add another virtual NIC to the VM and define the network the VM should also be connected to.

But here comes the problem - while it is absolutely possible to have a docker container listen to different or multiple hosts so far cloudron does not allow this.

To give a few examples where this would be handy:

• You want IoT devices to access media files and be monitored by Prometheus or the proposed [Zabbix](https://forum.cloudron.io/topic/1211/zabbix-network-monitoring-solution?_=1666369185907?
• You want students to access a wiki, moodle and an internal mail system but not the internet; Staff on their Network should meanwhile access the internet, moodle, media files, the wiki, the ticket system.
• You want internal staff to access certain ressources (e.g. invoice ninja and paperless) but don't want them public facing while a project management system should be both internally and externally used?

In all these cases gradual control over the networks would be used to get a proper setup - and in all those cases you need a host that has acess to multiple networks at the same time.

(Disclaimer: As there are a fair bit of not that adept users and people not speaking english as their first language here I tried to keep wording simple, sorry to all the Pros out there)

@subven
Security wise that is a quite limited scenario.
This would mean that internal clients would need external access for services that are both internal and external- a scenario that is often undesired.
DNS is never a security measure.