I just checked and this is literally the only commit you made after v1.2.1 that could have broken this, it could be related if you can reproduce this at least. I'll try to roll back my Build Service Version in the meantime.
Oh, the commit that could have caused this: https://git.cloudron.io/cloudron/cloudron-build-service/-/commit/5012542ecd7d538a37fe8f84cfab096c588f0ac2
@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.
@nebulon Oh that's perfect, thank you so much for looking into that! Happy to hear it wasn't just me then, haha, just bad luck with the app and timing I guess, glad to know the process I was trying to test works though. Thanks again for the help!
@BrutalBirdie Oh, gotcha, sorry I missed you saying that. Good luck! If you wanna bounce ideas off the wall, keep commenting on this thread.
That's what I did when building the OpenVPN Client, it was just me mostly with more than 100 comments of brainstorming.
@nebulon That’s the exact answer I was hoping for but couldn’t test. Thanks again for the clarification. Trying to avoid any potential bugs even in situations where I can’t test directly so your info really helps out!
@Lonk said in Need help on probably something very easy (Apache Setup):
Sometimes I ask too complex ones, sometimes too simple ones. But the way you explained everything was perfect and I got it working! ️
I feel that's usually the process of learning something new. Glad to be of help.
@mehdi said in Is there a way to make LDAP mandatory on the Cloudron App Store?:
@Lonk I'm not sure I understand the question.
As long as your app has the LDAP addon, you're good. You just have to not include the optionalSSO entry in manifest https://docs.cloudron.io/custom-apps/manifest/#optionalsso
You answered correctly! Thanks.
@girish said in Why wouldn't cloudron install take into account the private registry:
Ah, this is because in the code we assume that if the registry is not set in the image name, it is a public image from the docker.io registry - https://git.cloudron.io/cloudron/box/-/blob/master/src/docker.js#L112 . Currently, the Cloudron App Store images do not use have the registry name in them (since images are public). If you passed in 'lonk/xxx', code doesn't know if it pass auth info or not. I guess we could "hardcode", the username in the check as well but we also have cloudron, cloudron-dev, cloudron-staging and some other usernames in docker hub.
The fix is easy though: cloudron build --set-repository and then enter docker.io/lonk/xyz (i.e include the docker.io part).
Though this solution worked perfectly for me, it was not intuitive. And you did bring up an interesting point. I have two accounts on Docker Hub myself (one for production, one for staging). Could Cloudron support multiple users in the Cloudron Private Registry page? In case some of the projects end up being private?
As for determining if and when to use credentials to pick up a private Docker registry based on the name of the username / base and if the script can find a public registry with that info, if not fall back to authenticated.
I think that wouldn't be a hard edit for your Build Service, let me see if I can make it as a proof of concept.
@rossmaclean On Cloudron, the containers run on a read only file system. They can write only to specific locations at runtime - see https://docs.cloudron.io/custom-apps/guide/#read-only .
For configuring nginx, I think https://docs.cloudron.io/custom-apps/guide/#nginx is the info you are looking for. You can see how it's done in the teamspeak package.
Make a nginx.conf in your repo - https://git.cloudron.io/cloudron/teamspeak-app/-/blob/master/nginx.conf (in your case, you have to fix the port to 80 from 8000).
Add the config to a site - https://git.cloudron.io/cloudron/teamspeak-app/-/blob/master/Dockerfile#L34
@girish said in Finishing the VPN Client app's functionality:
Since, async functions can get some time to get used to, what you can do as a "hack" for now is to just set a property in appdb. For example, add a line https://git.cloudron.io/cloudron/box/-/blob/master/src/appdb.js#L59 like result.networkId = container:vpncontainerappid. Then you have this properly available in the docker.js code.
I think the final code will anyway read the networkId from the app table, so your code won't require much change if you do something like above.
That’s perfect. I hated how hacky my solution was so I’m going to to recode it in the way you described. Doing it the way you described also allows me to add a comma-delimited list of all VPN containers thus supporting more than one VPN client running simultaneously on Cloudron (my hacky code only allows for a single OpenVPN client).
I need to add the container name to the DB and the internal IP of the running vpn client container. Both are essential.
Then when any user chooses to connect to the VPN then that specific app will restart and be configured to route all outgoing traffic to it.
The only caveat in all of this is that though technically an unlimited amount of web apps can connect to the vpn client, a limitation is that the web apps can’t share the same exposed port as any of the others. This is gotten around in Docker by binding randomized ports to the exposed port. But when you connect to a VPN Client, you have to be running on the same IP so you lose the ability to Docker “bind.”
There may be a way around this using Docker Connect -link argument. But I think the same caveat would apply and that would only solve the problem of having the app not have to do a quick restart to connect. But I’ll make sure. ️
@jdaviescoates I’m an idiot, you’re absolutely right: https://forum.cloudron.io/topic/2686/live-stream-on-creating-an-app-for-cloudron?_=1602281676588
This is the clip that made me a Cloudron developer enthusiast. I think it could help anyone / everyone starting out.
Also, if anyone has any questions let me know. I had to take the week off work due to a hugely personal situation. But I’ll be back on Monday full steam on the forum and would love to help any new developers (in the same way @fbartels helped me, indirectly). I don’t know as much about box as @girish but if someone is making an app that needs deeper level dockerode / Docker / node knowledge - let me know. It took me 4 days to understand how node asynchronicity worked. So if I can help someone turn that into one day. I can tell you how do to so.
Note: Cloudron box uses callback Node methodology so when researching it, make sure to look into that type of methodology when it comes to handling asynchronousity since this project was started in the timeframe callbacks were the most popular.