Oh, and it may require like 4 or 5 patches to box code. Forgot about that. 😅It's fully functional tho, a little unpolished, a lot unpolished. But everything works. @girish and I will work together to integrate it properly at some point after 6.0. My patches run at "start" time, so the fact they're inefficient isn't too big of a deal, but just know that somewhere down the line, @girish and I will add it properly into a stable version of Cloudron.
What an accomplishment this was for me back then. I like that my first post in the forums is this crazy hellscape of Cloudron and Docker development jargon. I also wonder if this will ever help anyone down the road. Either way, I'm glad this whole thing is archived, it's p nostalgic for me. ☺️
@nebulon would all binaries not run (eg. /bin/sh from within the base) or just Go binaries that you compiled within the buildx pipeline? If it's the former, it may not be using the right base image. If it's the latter and the former works, perhaps setting the GOARCH variable via a build-arg would solve it.
Note: I personally have not used buildx yet, but from what I can see it's a simpler, automatic version of what I'm trying to do with qemu that handles the manifest for you. So I think you should just be able to build without the muckiness of all the build-args I pass, but if not you can play with mixing those in until it works.
I think buildx is supported on my laptop, so I can give it a try, but it's not supported on my CI box yet, so I haven't switched.
1-Is a security plugin necessary in wordpress managed?
I use the Developer package for WordPress so can't speak for the Managed version too much, but my general advice would be the following:
Generally speaking, it'd best to only install plugins when you know you have a need that isn't already addressed in the system. Thus, knowing your exact needs would come before choosing any particular plugin. My rule of thumb personally is not to install a plugin unless I understand why I need it and what I want to achieve with it.
Security is a huge umbrella with probably hundreds of different sub-categories / uses. So for example, it'd be good to know if you are wanting to be notified of any irregular file changes, block specific functionality in WordPress, lockdown user accounts with custom permissions, change the login page URL, rate limit logins, or a mix of those or a whole bunch of other ones.
It's good to copy an existing WordPress site (or a default one) to test new plugins on to see if they will interfere with your current setup, avoiding testing in any live production website.
Aside from the above, I'd honestly recommend just using the Developer package of WordPress. I know that goes against Girish's recommendation 👼 but there are at least several of us "power users" in Cloudron that feel there's no real upside to the Managed package other than a little bit more security by default. Eventually, whether it's sooner or later, you'll likely have the need to use a particular plugin that will need to modify files or access certain files, in which case you'll then have to do a bunch of work to migrate from the Managed package to the Developer package, so IMO you may as well just start on the Developer package to begin with unless you have very basic needs for WordPress and don't plan on growing it at all. And you won't want to be caught in a project that's time-sensitive to then find out you need to now also migrate an entire website to a new app instance type. I learned that lesson the hard way myself. 😉
By the way, every app has its own category in the forum. You may be better served to create a separate and dedicated post in the WordPress (managed or developer) categories. This thread in particular is pretty old and is generally on a different topic than "security plugins" for WordPress.
Update minio to 2021-04-22T15-44-28Z
fix: pick valid FileInfo additionally based on dataDir. See (#12116) for more details.
Service account related improvements. See (#12117) for more details.
fix: newMultipartUpload should go to same pool as existing object. See (#12106) for more details.
ignore more tokens in some mountinfo entries. See (#12104) for more details.
Grab read lock while reading usage cache. See (#12111) for more details.
Update Ghost to 4.3.3
Removed unused and insecure preview endpoint - Hannah Wolfe
Fixed error when using staff access tokens - Daniel Lockyer
Fixed Ghost 4.3.0 migration that put all sites into "allow free members signup" (#12904) - Kevin Ansfield
@atrilahiji Yeah, it's a compromise step I feel. Secure enough to be better than ad-tech's conflicts of interest, but still aware that the metadata for who's chatting with whom and when still has some potential value that one wouldn't want to share if given an assured choice.
Matrix I love the ideals and successes of. Element seems the best of the bunch. So for this audience, certainly the best we have.
For my entire social circle, well I can't see it happening but would be happy to see otherwise.
I guess the original point of the post was non-Cloudron specific, and potential for mass-market.
I guess we have to wait and see what Elon Musk shills next 😂 if Signal's MOB payments sour the new kid capturing mindshare.
I have published this app as unstable now. It also has an integrated UI. I have only very mildly tested it, so do not use it in production. I have created an app category for this, please report any issues there.
@jdaviescoates Agreed. Likely not an issue for a server with only a few apps, but can be a quick time saver for that at-a-glance info when hosting many of them. I'd personally like to see a toggle that allows this for admins so that it's not there for people who don't want to see them. But that can always be second iteration. haha.
My package includes a ton of extra packages to cover the most popular programming and scripting choices. (Some are actually already in the Cloudron base image, which I use.)
PHP7.4 (PHP8.0 will be included soon!)
DotNet Core (C#, VB.NET, etc) (.NET Full will be included soon as well since full supports Linux now I believe)
NodeJS (Updated to latest)
I am probably missing a couple but I wanted to make sure a lot of the popular stuff was covered here.
thats unfortunately a bit impractical to do. kwmbridge requires a large range of udp ports so running it in a container with forwarded ports is quite inefficient (because there is also quite a memory overhead in Docker in this case).
But it should be easy to make the app configurable enough to have kwmbridge running on a dedicated host and simply hook up to kwmserver inside of the app. having (multiple) external kwmbridge endpoints is kind of the setup we are expecting anyways.