I often end up holding ownCloud updates back in apt as there's always this sense of dread that I'll have trouble getting the app out of maintenance mode. Versions 9+ have been better but upgrades sucked in the beginning even as a home user not using disk encryption.
I've never used apt, I always use source .tar.gz - it is just a web app. I keep a separate disc with data, html, tmp (for working etc source packages) and mount it to /srv/nextcloud. I then symlink /srv/nextcloud/html to /var/www/html/nextcloud to avoid surprises (where the hell is the bloody app!)
The config does need a bit of care but the docs are great. I do recommend that you add in redis etc and all the php caching etc. Also, get a Lets Encrypt cert on it.
Upgrades? I bit the bullet and tried out the auto upgrade button in the web interface on my largest install after doing a VM snapshot of course. I now always do it that way because in the past I generally end up re learning how to do it each time. You do need to get the file permissions correct for the web app to be able to update itself.
I have had problems and errors sometimes but the forums and docs have always given me a fix. Learn how to do a dump/restore of the database (you should ideally be using MariaDB and know a bit about it) and learn about the occ command eg:
# sudo -u www-data /var/www/nextcloud/occ status --output=json_pretty
The NextCloud desktop app works well on both Windows and Linux (I don't have any Mac experience) As I mentioned before, I use Foldersync Pro on Android for photos because you can do a one way sync, with deletes on the phone not being mirrored to the repository (phones have rather less storage than desktops or my servers).
I like nextcloud a lot more and it's performance is great, especially since I started using redis (that was a huge pain to install on the rpi though).
I only use Google Drive as an encrypted backup. I've replaced everything it did with nextcloud + collabra + talk.
So your performance will already improve if you delete your local STUN and TURN and use the Nextcloud STUN as our free STUN runs in a big data center. Then you have to find a TURN somewhere that you can run also close to the backbone, or try using without...
Yes, running STUN and TURN properly is a pita.
I'm no super expert so check what I'm saying, but this is based on my best understanding of what these do and I had to write our documentation for customers about our Spreed High Performance Backend which, among other things, does STUN and TURN ;-)
(Nextcloud marketing dude here)
I just prefer to self-host as much as possible.
For myself, my usage is small enough that I don't care if my "migration" is that I just copy over the two user's worth of data I have in the file sharing and set up the one shared folder I have again by hand. (It's a home cloud, not corporate.) In fact in some ways it'll be easier than what I was planning on doing.
While feature-wise, we're still not really missing anything oC has, the underlying codebase is really diverging, we're not really merging any code from oC since a year now...
Migration will become a real, risky pita at some point I'm afraid. Apps are already dropping compatibility and mobile apps, too.
Like I said, a brute-force migration for me isn't too big a deal. Half the work for things like switching apps on my phone I'd have to do anyhow.
If Nextcloud continues to add features and get more traction, perhaps it can become a viable alternative to Google drive/mail/calendar?
Does anyone here have experience deploying Nextcloud in a business setting?
Anything else could make for some really terrible data breach possibilities. At scale. :/
The maximum's seem pretty low though (to me), considering it's used for housing peoples personal data.
For instance, the deployment and updating process (which Nextcloud has no control over) is just as important.
I wonder what domain they'll be using for these self-hosted Nextcloud instances. Are they going to allow for custom domains?
The big issue with PHP's security is that there are a lottt of old guides and stackoverflow answers out there with terrible, unsafe practices.
Still 80%+ of PHP sites.
5.6.36 was released in April 2018; 5.6 was released in 2014. 5.1 was released in 2005 by contrast.
There's nothing terribly wrong with running 5.6x if you have a good reason to do so (eg legacy), other than that the performance sucks compared to 7.2.
You can dig further into the w3tech numbers here:
Nobody is using 5 or 5.1. The majority of all PHP installations are using more modern versions, either 5.6x or 7.x.
PHP needs to go away.
And from sitting in on a lot of leadership meetings, they're one of the few groups that perpetually seems to be concerned with something they depend on sunsetting.
As long as they're passing with ISO, I just stay out of it.
Php is a go-to route of getting a shell.
And the only reason you see more vulnerabilities for CMS's written in PHP is because the most popular CMS's (Wordpress, Joomla, Drupal) are all written in PHP.
We'd see the same thing happen regardless of the language (except maybe Ada or Rust. They do a good job at stopping you from shooting yourself in the foot).