@mehdi Yes I saw that part, that's where I got the 1048576000 from and it got me digging into it further. I guess then the display is using binary in Cloudron UI so the value it's set to isn't quite 1 GB in binary so it shows 1000 MB. Interesting. That seems wrong to me though, I assume the value in that manifest should actually be 1073741824 to match others that are 1 GB. Right?

Example: 1073741824 is what's set for Bitwarden: https://git.cloudron.io/cloudron/bitwardenrs-app/-/blob/master/CloudronManifest.json#L17

Am I right in assuming then from this that the Cloudron UI basically shows in Decimal, and not Binary? But ideally the Manifest should be in Binary still so the UI shows the more expected typical numbers and increase segments, right?

Now increased to 100

@yusf said in Why do we have to push an image to a registry?:

Does this mean that we can also host the Cloudron build service on production machines, or am I mistaken?

Well, I run it only on a dev machine since I only use Cloudron to dev. But tbh, after 100s of builds. All of the other apps are still running smoothly so it's not recommended because it's the only app with the docker add-on and thus could technically mess with other apps. It has never done so, I just think they'd rather not have the responsibility of calling it "production-ready" even though in my dev environment, it gives me no issues. I would feel comfortable running this in production tbh. The worry is if it ever bugged. But I can actually work around that by accounting for it using a Cloudron add-on I'm building (Dot the Repair Bot) so even though it's never happened, if I account for the Build Service being able to destroy containers / data outside it's sandbox (what the devs mean when they say it's not for production), I can have them auto-restored by Dot.

But if Dot got destroyed by the Build Service I'd be screwed. 😂

@girish Sorry for the late reply, I tried this and got it working!
Thanks,
Ross

@marcusquinn Oh yes think it would be help

@mehdi said in Updating a node app:

@atrilahiji Also, some browsers are a bit ... aggressive with their caching policies. You may want to force-refresh (ctrl/cmd + shift + R in most browsers), maybe even a few times, before anything else, just to check it wasn't just cache

This has been my experience as well.

I took a quick look at that some time ago, but it wasn't that trivial for me at least unless I would rewrite parts of the element table management around sorting. Happy to accept any patches there of course.

@murgero HAH! Oddly enough making my script specifically cd into the backend directory and running the server.js there instead of running server.js from outside that directory did it. Unsure why. Works now and I have 0.1.1 of my app released and 0.1.0 of the cloudron integration. Thanks guys! 🙂

@girish I also think about this. The use case is. I need the first db and dbuser for the web app. And the second db and dbuser for view tables from the first db. This second db and db user is used for metabase report so the original db and table structure not shown for the metabase user.

Another case i can think of is to make a slave db on the lamp app from external db.

Let’s not forget about the mounting feature in 6.0 tho. ☺️

@malvim Definitely update us on progress in either thread. I'll be getting my Pi in November and will join the "Cloudron on Pi" team! ☺️

great! luckily we can re-watch 😄

Tagging @luckow since he has customer experience with Greenlight and could tell us how often a customer wants/uses to use this feature.

So, it should be obvious for someone who has worked in IT for a while like me, but... Kids, DON'T EVER run tests on your production servers. Ever! 🤣 🤣 🤣

@nebulon said in Remote SQL into Cloudron's App DB for debugging purposes:

What do you mean with Cloudron's App DB? Like the main platform database?

That would be simply available on your host system only on localhost. You can access it with mysql -uroot -ppassword box (password is literally password) Of course you are on your own if you tinker with that database, changing things there might break the system.

I honestly never would have figured out the password (not joking), thanks, that worked! ☺️

Is there only one cloudron database which is "box"?

Got the tool fully working on macOS. Worked like a charm after I figured out everything the tool wanted.

I had to make a small commit to dashboard since macOS doesn't support the timedatectl CLI tool so I converted that command into a universal one that returns the same values on either Ubuntu and Macs. But that was literally the only thing that didn't work in the entire tool and I've already committed a change for that (locally, of course).

So, thanks for your help @girish, this will allow me to build a cloudron-master Cloudron install that's, ofc, unstable - but it will be just to test my apps in before you turn your new commits into a release to make sure my apps are always compatible with your newest changes! ☺️

@mehdi That’s what I’m thinking it must be - it’s happening with my VPN Client since that’s what I’ve been working. But the box code treats the OpenVPN Client like normal and only treats the apps connected to it special.....wait, what if the cache of the domain exists because an app was connected to my OpenVPN Client app so it’s still “somewhere” in memory even though technically that container is no longer referencing an active container.

That’s a great idea and I think that may be the cause. Because it would persist reboots even, the app connected to the VPN Client attempting to connect. I’m just hoping I can get some advice on how to access Cloudron’s internal app DB via Remote SQL (like you can with individual apps) so I can debug this issue entirely.

I want to release the OpenVPN Client on the store in 2021. So I gotta make sure it’s perfect - and your comment just sparked a thought process that very likely could be the problem and I was dismissing it in my head for silly reasons. Thanks. I’ll reproduce it now that I know it’s just me, and see if I can fix it.

I really just needed one other person on the latest Cloudron perform those steps and have it go perfectly for me to know it was my app (and box changes).

Oh, that’s easy. It’s already there in the environment variables. Cool, I’ll adjust my library to include it so that the app doesn’t break when Cloudron starts enforcing the bind password (which it’s only not for 4 apps I guess - so when / if they ever support it, Cloudron will require the password).

Thank you so much @mehdi. Sometimes I miss the easiest of things.