There was something wonky with the mapping of OIDC attributes to user properties, so I decided to look at the seahub source and see if it would be easy to fix.
Turns out, the whole thing is held together with hope and spit. Literal beginner code.
Also looking through some of the issues and comments on github about no plans to implement basic features (file search on the android app) does not inspire confidence at all. One of the reasons I’m hoping the OwnCloud rewrite is good.
Any tips for speeding it up? Loading can be painfully slow at times. I was reading that it may be the database (I use MariaDB which in theory shouldn’t limit it with 32gb RAM and an R7 1700x).
I reverse proxy over tailscale to a VPS because I have double NAT… The connection to the VPS is direct with wireguard at least, no relay node. Adds ~30ms latency. But even when I connect direct locally it’s not substantially faster.
I’ll check my config.php for caching. I don’t recall adding anything for it so if it’s not on by default then that’s a likely reason. Thanks!
Yeah for my instance I remember I had to do a few performance optimizations. Also make sure you are up to date because nextcloud has gotten performance upgrades.
I initially set up Nextcloud with MariaDB on spinning disk but it was slow even completely empty. I moved that container to ssd & performance was a lot better. The web UI may still have some slow loading parts but I can’t say for sure since rarely use it. Caldav+carddav+Nextcloud client are how I usually interact with it.
The only thing that makes this case worse in docker is that more info is in ENV variables. The vulnerability has nothing to do with containers though, and using ENV variables to provide sensitive data is in general a bad decision, since they can be leaked to any process with /proc access.
Unfortunately, ENV is still a common way which people use to pass data to applications inside containers, but it is not in any way a requirement imposed by the tech.
Absolutely not. Many applications used ENV variables for sensitive stuff even before. Let’s remember that the vulnerability here is being able to execute phpinfo remotely.
Containerization can do good for security, in general.
This is just a bad practice that was popularized by CI/CD solutions and later on by containers. I’m not saying containers aren’t good for security, what I’m saying is that they’re misused and abused and that images shouldn’t even be a thing. Isolation is great, blindingly trusting images made by someone and/or having people that don’t have any basic knowledge of security nor infrastructure suddenly being able to deploy complex solutions with a click ends up in situations like this.
OK, but how do you solve the problem? Trusting an image is not so different than downloading a random deb and installing it, which maybe configures a systemd unit as well. If not containers you still have to run the application somehow.
Ultimately my point is that containers allow you to do things securely, exactly like other tools. You don’t even have to trust the image, you can build your own. In fact, almost every tool I add to my lab, I end up opening a PR for a hardened image and a tighter helm chart.
In any case, I would not expose such application outside of a VPN, which is a blanket security practice that most selhosters should do for most of their services…
My point was that “random deb” and/or “random web application” are way less likely to come with unsafe default ENV based configuration files and usually go with the config files securely stored in system directories with the proper permissions enforced during installation or simple .php config files that won’t get exposed and that will require the user to configure in a proper way (like WordPress does by providing wp-config-sample.php but not the final wp-config.php file required to run it). Those are the solutions people used before the containerization hype and things were just fine.
My second point: containers “lowered the bar”, allowing for almost anyone to be able to deploy complex solutions and this was / is bound to be a disaster. No matter how safe Docker and others become we can’t just expect people who know almost nothing about computers and networking to be able to safely deploy things. Even the ones that know a lot, like developers, sometimes use Docker to deploy things they wouldn’t be able to deploy otherwise and fall to the pitfalls of not understanding networking and computer security.
In any case, I would not expose such application outside of a VPN, which is a blanket security practice that most selhosters should do for most of their services…
Well, me too, however I understand that some people might want to expose it publicly because they might want to access their instances from public or work machines where they can’t install a VPN. For those cases I would recommend 2FA and only allowing specific IP addresses or ranges access to the thing - the office static IP, their ISP or eventually only the user’s country.
It's probably best to look at what the devops industry is embracing, environment variables are as secure as any of the alternatives but poor implementations will always introduce attack vectors. Secret management stores require you to authenticate, which requires you to store the credential for it somewhere - no matter what there's no way to secure an insecure implementation of secrets access
They are not as secure, because there are less controls for ENV variables. Anybody in the same PID namespaces can cat /proc/PID/environ and read them. For files (say, config file) you can use mount namespaces and the regular file permissions to restrict access.
Of course you can mess up a secret implementation, but a chmod’d 600 file from another user requires some sort of arbitrary read vulnerability or privilege escalation (assuming another application on the same host is compromised, for example). If you get low-privileged access to the host, chances are you can dump the ENV for all processes.
Security-wise, ENV variables are worse compared to just a mounted config file, for example.
In general, a mounted file would be better, because it is easier to restrict access to filesystem objects both via permissions and namespacing. Also it is more future proof, as the actual ideal solution is to use secret managers like Vault (which are overkill for many hobbyist), which can render secrets to files (or to ENV, but same security issue applies here).
I’m using Kubernetes and many of the apps that I use require environment variables to pass secrets. Another option is the pod definition, which is viewable by anybody with read privileges to K8s. Secrets are great to secure it on the K8s side, but the application either needs to read the secret from a file or you build your own helm chart with a shell front end to create app config files on the fly. I’m sure there are other options, but there’s no “one size fits all” type solution.
The real issue here is that the app is happy to expose it’s environment variables with no consideration given to the fact that it may contain data that can be misused by bad actors. It’s security 101 to not expose any more than the user needs to see which is why stack dumps are disabled on production implementations.
The problem is in fact in the applications. If these support loading secrets from a file, then the problem does not exist. Even with the weak secrets implementation in kubernetes, it is still far better than ENV variables.
The disappointing thing is that in many “selfhost” apps, often the credentials to specify are either db credentials or some sort of initial password, which could totally be read from file or be generated randomly at first run.
I agree that the issue is information disclosure, but the problem is that ENV variables are stored in memory, are accessible to many other processes on the same system, etc. They are just not a good way to store sensitive information.
Nobody cares about your home services unless they can use them to send spam or mine bitcoin. Owncloud is a funny name because it seems to imply it’s for personal use: your own cloud. I didn’t know until I found myself in one, but apparently a lot of schools use Owncloud.
phpinfo is just a bad idea. It’s a built in facility that dumps everything without knowing whether it’s sensitive or not, right into the current page, making it trivial to add this vulnerability to your own application or library that an unsuspecting developer will include into their application. There’s not even a single security warning in the documentation. Here’s practically the same problem from 21 years ago: nvd.nist.gov/vuln/detail/CVE-2002-1725
Since a couple years ago they abandoned the php version (=nextcloud) and they are in the process of a complete rewrite in go, which that means is faster and uses less resources but all existing plugins need to be rewritten too, and given the small user base nobody is going to do that.
Ooh interesting, never knew they started a rewrite!
The reports of poor performance with the PHP version was one of the things that pushed me towards using Syncthing instead when I was looking for a solution to view my documents and files from various devices
they call it “owncloud infinite scale” but for some reason they don’t clearly specify that it’s designed for performance, and it has nothing to do with the previous version. They even start the introduction page with this:
Welcome to oCIS, the modern file-sync and share platform, which is based on our knowledge and experience with the PHP based ownCloud server.
If you read that a platform is based on their knowledge and experience with PHP, would you guess that they’re talking about a complete rewrite in go?
Badly. Nextcloud is a very active project with many plugins and integrations. You can even integrate a mail system and AI image tagging, chat and video calls.
Owncloud focussed more on the enterprise sector and less on fancy features. Definitely the more stable product (but not only in the positive sense).
I tried NC recently (like 2 weeks ago) and fuck me it’s an awful piece of shit, full-stop. It broke completely 3x during initial setup, needing a container wipe and beginning from scratch each time, then I was following the official docs and the ‘status / security’ page of the admin area where it told me to do something that had no gui (so they are 100% aware anyone new has to do this but cba to throw it a fucking web page) and if you edit the config file on the machine directly, even if you stop the container, it breaks permissions (???) so you have to download it from your server, edit, and re-upload it (somehow doesn’t break permissions???). This took an hour to figure out, the doc was useless.
Then you get to the plug-in page and fuck me could this be any worse. Pick one fucking category each, guys, I don’t need to see 40% of the same available plug-ins on almost every fucking category, jesus fucking christ. Then you dive into these things and you realize how surface-level they are - a task/to-do list should have a fucking import/export function, as well as REPEATING OPTIONS fuck me sideways are you seriously taking the piss. You’ll be setting up other plug-ins and they don’t actually function at all even though they have been verified to work with your version (medical plug in, for example) and it just keeps crumbling around you the further you go. Shit, even the weather widget on the ‘home page’ will show C instead of F when you select a country during account setup that uses F, with NO OBVIOUS WAY TO CHANGE THAT. The fix? Go through your region options, pick a different country, then back to your actual. Does NOBODY EVEN TEST THIS SHIT? How are they on version SIX of their ‘hub’?! This screams alpha, not multiple-stable-releases!
I did never have any problems with installing it, but once or twice with upgrading. And I agree with you that the setup is complex with all the possible options and getting it to run well takes some time.
When it comes to the apps, Nextcloud is a very open system. Its easy to publish an app, and the quality of the apps varies. Some apps are abandoned and don’t work in recent versions. Personally, I would recommend to keep the number of apps low for stability and security reasons.
The update process is absolutely horrible, especially with containers.
I seriously cannot understand how this hasn’t been fixed ages ago. Upgrading is kind of important and nextcloud isn’t doing that much weird stuff that it didn’t upgrade itself.
That was the case for me. I had a nextcloud setup with a few productivity apps (calendar, contacts, notes, some 3rd party). In one case I forgot to deactivate apps before update and it crashed. In another case I deactivated it first to find out they are partially not usable anymore after update.
Now I try it with one container app for one use case (seafile, baikal etc.).
I’ve been self-hosting since before docker and containers were a thing, and even though Nextcloud kinda pushes their container images these days, I still refuse to use them, and use the community archive releases or web installer when reconfiguring my system or setting up a new system to migrate to. Maybe it’s just Nextcloud and the other software I use, or maybe it’s just that I’m not really trying to build scalable server infrastructure with a lot of users, but I generally find that docker causes more problems than it solves, and it does my head in when I see projects that recommend containers as the primary suggested install method.
Totally agree with your assessment of the plugins/apps systems. Feels like you need to stick to official “apps” and hope they don’t get abandoned to have anything close to a good experience because even minor updates can break all the 3rd party apps because of a compatibility check, where you end up waiting for the app developer to release an “update” that only changes the version compatibility number.
Containers are very useful because they isolate the application from the rest of your server.
This solves a lot of problems: no dependency conflicts with your operating system, you can upgrade/downgrade any time you want, no state gets stored on your main system which makes resetting the application when it misbehaves as easy as deleting and recreating the container.
Before containers, changing my host OS (e.g. because ZFS wasn’t properly supported on the distro I was using) meant reinstalling and configuring a lot of shit, which could take days. With docker, I can migrate in 1-2 hours… Just install docker on the new OS, copy over the files, docker compose up a few times and done. The only things left to setup are samba, ssh and a few cron jobs.
Not saying there aren’t any benefits to docker, migration to a different host distro and dependency conflicts are the big two. But for me they are kinda the only two, I find for what I do it’s just as easy to write a shell script that downloads and unpacks software, and copies my own config files into place than it is to deal with basically doing the same thing, but with docker. I could use ansible or something similar for that, but for me, shell scripts are easier to manage.
Don’t get me wrong, docker has its place. I just find that it gets in my way with it’s own quirks almost as much as it helps in other areas, especially for web apps like Nextcloud that are already just a single folder under the web root and a database.
One additional benefit I get from not using docker, is that I can do more with a lower-powered server, since I’m not running multiple instances of PHP and nginx across multiple containers.
That was my pet peeve too. I installed it some years ago. Months went by, I’ve used it. Then I saw a new version came out. Okay, time to upgrade! Oh, dump the DB, delete everything, install the upgrade and load the DB back? (Or some similar shit.) And do it every time when there is an upgrade? Okay, uninstall it is.
Eek - I’m trying to host services for family and friends, and while I have raid1, snapshots, 3-2-1 backups, etc I’m still very concerned about having a db or other large data corruption occur.
Part of the problem is you don’t understand how containers work. If you need to do a ‘container wipe’ and starting from scratch, you’re doing it wrong.
I’ve been running nextcloud in k8s for years and running a few occ upgrade commands after an upgrade is annoying but not the end of the world.
Yeah, exactly. If you’re starting over from scratch constantly you’re doing something wrong. Check out docs.docker.com/storage/ for a few options on how you should be managing your storage.
This is the only container I’ve had anywhere near the amount of trouble with, others it’s just pulling a new image or something. I’ve been doing docker for like 5 years now, NC was just awful. Shouldn’t need to nuke anything while you’re still in the initial service setup phase…
Considering that any switch to a new platform takes a lot of effort to carry over everything correctly, people are in the right to worry about the future of a product that has an uncertain future.
Ooooor it will become a free vs corporate solution like RedHat and the likes do.
Portainer also does it for example. I think LDAP-Auth is paywalled but it makes sense that features like that are.
It might be, but in the history of that corp, they never had a free/community/oss project. It looks like the typical Embrace Extend Extinguish strategy, where you acquire competitors just to get their customer base instead of the real product. OC 10 it’s already dead (no php 8 support) and ocis has almost no plugins.
Didn’t know about their history.
If that was the case: Fun while it lasted. Havent used it thus far but I wasn’t against the situation if it justified the use of it.
Yes! As soon as your homelab grows above a couple of services and especially if it's used by two or more people SSO becomes an absolute necessity! The tolerance of non-technical users for handling a bunch of passwords and having to enter them everywhere is understandably low.
The Home Assistant devs apparently also deal SSO as "a corporate feature that big-corp interests want to force onto us" whereas it's the exact opposite in many cases: If we want self hosted services to be a realistic alternative to the "big corpo offerings" then we have to consider convenience and security an important feature and SSO is one of the few things that improves both at the same time.
Idk why you’d need LDAP login as the admin for a homelab.
For other things like owncloud it makes sense but not there but eh…Personal preference I guess.
I have something like 40-60 machines between hypervisors, VM, and physical. Central auth is an absolute must for that scale. Sure I could just re use the same password 60 times, but if that gets popped, I’d also have to change it 60 times (adding config management is a soon to be completed task)
Actually, I legally can’t make money off of it for reasons that would dox me.
I already pay for both VMware and Microsoft licensing among several others. If I can get my SSO by saving a little bit of money by using a different product, I will. I don’t mind paying for software I use when it makes sense, I only disagree with companies up-charging features like SSO that should be available to all customers.
You need to keep up that was so last year. The new hottnes is switching back to owncloud because it is so light weight. But now i am guessing the new new hotness is switch from owncloud to Nextcloud.
You’ll find a lot of pessimistic people here because there are few unicorns when a commercial company buying an open source project didn’t go badly for the open source people. Most of the time after a sell-out the projects ends up under highly restrictive licensing, features behind paywalls, and many other problems making it a shadow of its former self.
The most notable recent examples I can think of is IBM buys Red Hat buys CentOS, and that ended with forks as AlmaLinux and Rocky Linux. Oracle buys MySQL ended up forked as MariaDB. Businesses love to push their commercial offerings on open source products, and it’s not always in the form of plain old support agreements (like the people behind AlmaLinux). Often (this is common especially in databases) they’ll tax features like SSO, backups, or literally simple the privilege of having stable software. Projects like CentOS and VyOS don’t have stable OSS versions, and soooo many databases will put LDAP/Kerberos behind the commercial product, charging monthly or yearly operating costs.
Even GitHub (which to be clear was closed source to begin with, but is a haven for F/OSS so I’ll give it an honorable mention here) started showing Microsoft-isms after M$ bought the platform.
Fair, but I would point out that OwnCloud kinda already went that direction years ago. There’s already a very limited free version and a fully featured enterprise version. So it’s not like we’re losing something that the community built here.
I used nextcloud for a year or so, but found the web GUI/apps slow, bloated and sometimes way to buggy ! Switch to owncloud for the simplicity of only having a cloud system without to much bloat.
I just read through the seafile documentation and yeah this is also not going to happen. Maybe I should switch to a simple webdav server…
How was it setup? Make sure you are using a good SQL backend or else it will be slow.
Its also received a bunch of live recently so it may be worth another look. I would be very careful trusting seafile as it sounds like a locked down proprietary solution
owncloud.com
Active