What's coming in 4.2
-
@d19dotca yes that is intentional, what we do is we have a white/black list of domains to which we push out updates one after another. This allows more fine grained testing from our side. You can send us an email at support@cloudron.io and we can whitelist yours if you want to test it sooner.
-
@d19dotca yes that is intentional, what we do is we have a white/black list of domains to which we push out updates one after another. This allows more fine grained testing from our side. You can send us an email at support@cloudron.io and we can whitelist yours if you want to test it sooner.
@nebulon Okay, I kind of understand that methodology but I would still like to request then that for the future, when a user manually checks for an update it's because they want to update so that should be sort of auto-whitelisted (not to mention it would save you some unnecessary support emails). I can appreciate and totally understand scattering it for automatic download types, but it should be understandable from your side too that when a user is manually tapping the Check For Update button it's because they already know there's a new update out and are ready to deploy it.
So it'd be great if that auto-whitelisted the domain. -
Hey @girish. Congrats on the release! I know it took a bunch of work.
Did this feature get pulled from the 4.2 release? I wasn't able to see it in the release notes or on the demo site. Really looking forward to this feature.
@girish said in What's coming in 4.2:
Customizable app data directory - this will allow you to mount an external disk (like a DO block storage) and make an app use that storage block
-
@tamayers @d19dotca We have made the release available but it's only in use for new installations. This allows us get some early testing before we push it to all the existing Cloudrons. We are still working on the new app configuration UI + the mailbox forwarding feature. The data directory change is also there in the 4.2 release.
-
@d19dotca yes that is intentional, what we do is we have a white/black list of domains to which we push out updates one after another. This allows more fine grained testing from our side. You can send us an email at support@cloudron.io and we can whitelist yours if you want to test it sooner.
@nebulon & @girish - my Cloudron still shows 4.1.7 when I check for updates. I would definitely say this should be a feature request then that is a user manually clicks/taps the Check For Updates button, the latest build is presented. It would only generally be used when someone is aware of an update and expecting to install it. I understand the blacklist/whitelist thing but I would say it should be ignored when the button is pressed. The rollout using a blacklist/whitelist should only be done for those who don't manually use the button so it notifies them when it's ready.
-
@d19dotca we don't push out 4.2.0 yet, even when checking for updates manually, has good reasons. We have found a few regressions which will affect existing Cloudrons, for example the stats view will miss data since that release would not reconfigure collectd as required. Newly created Cloudrons are not affected here.
-
@d19dotca we don't push out 4.2.0 yet, even when checking for updates manually, has good reasons. We have found a few regressions which will affect existing Cloudrons, for example the stats view will miss data since that release would not reconfigure collectd as required. Newly created Cloudrons are not affected here.
@nebulon So to confirm then... 4.2 isn't really released at all then yet. It's pretty much in a "beta" state, used for new installs but nobody with an existing install will have received it yet unless we formally request our domain be whitelisted. Is that correct? There seems to be confusion here with the way things are being worded. 17 days ago it was stated "The initial 4.2 was pushed out yesterday" but now you're saying "we don't push out 4.2.0 yet" -- this is creating a bit of confusion.
-
It's out!
Add external LDAP server integration
This is very good. Now if only the reverse was possible too we'd have ourselves a real symphony.
-
@yusf If you don't mind a bit of a "hack-n-slash" you could open up ports 389 and 636 in iptables to access the cloudron ldap server remotely
-
@yusf You can restrict the port in IPTABLES as well, I don't remember if cloudron uses just IPTables or UFW but here is a rule for both that would work for routing to internal networks only:
UFW:
ufw allow from 192.168.1.0/24 to any port 389
(This allows from the 192.168.1.0 network to TCP/UDP port 389. You can change the word "any" to "tcp" to restrict it to TCP only as well.)IPTABLES:
iptables -I INPUT -p tcp -s 192.168.1.0/24 --dport 389 -j ACCEPTPlease research what cloudron uses as it's firewall (I am almost positive it is iptables).
Also note - This is an unsupported modification too.
Also also note - You can probably make an app that can proxy this connection instead, using a different port, you can proxy to the LDAP server instead. (Say port 1389 as an example). This would probably work better since LDAP clients normally allow you to configure a port to connect to anyway.
--
https://urgero.org
~ Professional Nerd. Freelance Programmer. ~ -
@yusf You can restrict the port in IPTABLES as well, I don't remember if cloudron uses just IPTables or UFW but here is a rule for both that would work for routing to internal networks only:
UFW:
ufw allow from 192.168.1.0/24 to any port 389
(This allows from the 192.168.1.0 network to TCP/UDP port 389. You can change the word "any" to "tcp" to restrict it to TCP only as well.)IPTABLES:
iptables -I INPUT -p tcp -s 192.168.1.0/24 --dport 389 -j ACCEPTPlease research what cloudron uses as it's firewall (I am almost positive it is iptables).
Also note - This is an unsupported modification too.
Also also note - You can probably make an app that can proxy this connection instead, using a different port, you can proxy to the LDAP server instead. (Say port 1389 as an example). This would probably work better since LDAP clients normally allow you to configure a port to connect to anyway.
-
@murgero Thanks! Though very unsupported also very interesting. Thought about the proxy app approach but you know my level id of expertise: not enough.
-
@yusf Maybe it will be my weekend project this week. Build an LDAP Proxy app for Cloudron.
I'll hit you up on Matrix if I get something working.
@murgero I’ve been meaning to do the same.
Should be doable with something like HAProxy, but I wanted to use some better auth mechanism, so I’ve been working on this: https://git.iamthefij.com/iamthefij/dockamole
The server is essentially just an ssh server that is configured to disallow running commands and only allow port forwarding. The client can be run anywhere and it exposes the ports for you.
I’m planning to run a server on my Cloudron to forward LDAP and Graphite (hopefully), and then I can deploy a client on my other VPS. I also plan to do the same with my NAS at home so I can have my VPS access it without exposing http access to my home network.
There are many ways to do this though.
-
@murgero I’ve been meaning to do the same.
Should be doable with something like HAProxy, but I wanted to use some better auth mechanism, so I’ve been working on this: https://git.iamthefij.com/iamthefij/dockamole
The server is essentially just an ssh server that is configured to disallow running commands and only allow port forwarding. The client can be run anywhere and it exposes the ports for you.
I’m planning to run a server on my Cloudron to forward LDAP and Graphite (hopefully), and then I can deploy a client on my other VPS. I also plan to do the same with my NAS at home so I can have my VPS access it without exposing http access to my home network.
There are many ways to do this though.
@iamthefij said in What's coming in 4.2:
There are many ways to do this though.
True. I was more thinking of using stunnel for this.
