Cloudron Forum

@andreasdueren Cool, thx! Will try that approach and report back.

Ah, I just found the error. For whatever reason the 2fa got disabled for my user and therefore the cli app did not ask for it. My password manager always filled out the 2fa field so I was unaware that it had actually been deactivated.

I never thought of this use-case. Using sftp inside a Cloudron app to move data away. Unique, I must admit. Testing inside a LAMP app to the new unstable SFTPgo app. mkdir -p /tmp/testing; cd /tmp/testing ssh-keygen -t ed25519 -f /tmp/testing/this -q -N "" # put the publickey into my profile in sftpgo.cloudron.dev sftp -i this -P 2022 elias.hackradt@sftpgo.cloudron.dev:/ sftp> put /app/data/tcl.zip [image: 1740783672764-e26df4a0-195d-43cb-9f69-46f3fa8516d4-image-resized.png] Seems to be working Sorry, where was I? Ah yes, your issue The error message OpenSSL version mismatch. Built against 30000020, you have 30100070 indicates that the version of OpenSSL used to build the sftp or related binary (such as ssh, libssh, openssh) is different from the version of OpenSSL currently installed on your system. Specifically: Built against 30000020: This means the binary was compiled against OpenSSL version 3.0.2 (I think don't pinpoint me on the semver). You have 30100070: This means your system currently has OpenSSL version 3.1.7 (same again, don't pinpoint me on the semver, not used to the 30100070 format). This mismatch can cause compatibility issues because the binary expects a specific version of OpenSSL but finds a different one at runtime. Running this in my LAMP App: openssl version OpenSSL 3.0.2 15 Mar 2022 (Library: OpenSSL 3.0.2 15 Mar 2022) and ssh -V OpenSSH_8.9p1 Ubuntu-3ubuntu0.4, OpenSSL 3.0.2 15 Mar 2022 Reveals, there is no issue inside the LAMP app. @chetbaker Could you maybe run openssl version, ssh -V and ldd $(which sftp) in your app with the id 23f10ac0-d9a3-4a1d-8265378464d7b1caasdasdas0 and post that output? Also can you tell us what app 23f10ac0-d9a3-4a1d-8265378464d7b1caasdasdas0 is? Since most apps are inherited from the Cloudron base image, that should be the same everywhere. So this error might be rather unique to your app. Could it be that your app is a custom packaged app? Since you are comfortable using the cloudron-cli, is this by chance an issue from your custom packaged app?

Seems like a connectivity issue. I assume you can connect via the browser. Is your system using a http proxy or anything like that? Does curl https://my.domain.com work ?

Thanks for the explanation.

Well, apparently the only way to "fix" this, is to docker stop the yellow services Mail / Mongo / Postgres / MySQL and then restart them in the dashboard and they start up succesfully, and then you can start other apps that have been stopped.

Ah, thanks! I hadn't seen the app-mail-folders before.

@girish Thank you, Girish! After I updated the node, this error went away.

@luckow good catch. In fact, the sort function usage was entirely wrong. Fixed in https://git.cloudron.io/cloudron/cloudron-cli/-/commit/87dcb5f8cc8ae29f877a6f5b96c865ec48dd8846 I published a new CLI 5.5.0

Solution is to install the Cloudron CLI in a container, LAMP App or Surfer App work well. See: https://forum.cloudron.io/topic/10966/installing-custom-apps-on-cloudron/

Got it, thanks!

Ok got it, thanks @BrutalBirdie ! No problem with doc being overhauled, I understand it's a WIP; just wanted to make sure it's not me that can't properly RTFM

Please check if it's any better with CLI 5.4.1

@webvsnet Ah alright Remember that when you upgrade Cloudron, you will have to get back to CLI 5.4.0

Thank you

Ok. I will doublecheck this. Give me a few hours for this. Thanks for the moment Update: Solution work fine! Thanks a lot.

@nebulon said in Cloudron CLI: ah. The cli is actually not built to run on Cloudron itself, but it would interact with a Cloudron via REST api. Is there a specific use-case where you need it on the server? I want to install the InfluxDB Package, I thought then via Cloudron CLI. So I have to install it on my Client, to install this package.

@scooke I am out of ideas then. If you like, you can reach out on support@cloudron.io and we can debug further to see if we can resurrect the app.

Found https://rsync.samba.narkive.com/DFt4GEa9/over-stdin-stdout which has some interesting discussion.

@girish Sure for test domains w/o any subdomains. What I'm suggesting is a non-entirely blocking situation when the automation fails what it thinks it needs with no simple recourse. Would improve UX flow in edge cases..