ownCloud 9 is Here
-
@dafyre said:
@scottalanmiller said:
@IRJ said:
I just want to troubleshoot this issue
Well your version is part of troubleshooting the issue. Your OS lacks the support that you want (support meaning it lacks support for PHP7 with LDAP.) That's part of the issue. It's not an aside.
Does ownCloud9 actually REQUIRE PHP 7?
My install updated without any headaches, but that is because I already had PHP-7 installed.
no no, not at all, I just gave that as example on MY system. It requires PHP 5.4+
So installing php5-ldap or php-ldap should do the trick...
-
@dafyre said:
@scottalanmiller said:
@IRJ said:
I just want to troubleshoot this issue
Well your version is part of troubleshooting the issue. Your OS lacks the support that you want (support meaning it lacks support for PHP7 with LDAP.) That's part of the issue. It's not an aside.
Does ownCloud9 actually REQUIRE PHP 7?
My install updated without any headaches, but that is because I already had PHP-7 installed.
Just going by what ownCloud posted. I didn't think that PHP7 was a requirement. They are running from OpenSuse which is way more up to date than CentOS or Ubuntu, so that might be all that it is.
-
Installing php7 in ubuntu 14.04
- sudo apt-get install python-software-properties
$ sudo add-apt-repository ppa:ondrej/php
$ sudo apt-get update
$ sudo apt-get install -y php7.0
- sudo apt-get install python-software-properties
-
Php7 modules from the ppa
$ sudo apt-cache search php7-*
php7.0-common - Common files for packages built from the PHP source
libapache2-mod-php7.0 - server-side, HTML-embedded scripting language (Apache 2 module)
php7.0-cgi - server-side, HTML-embedded scripting language (CGI binary)
php7.0-cli - command-line interpreter for the PHP scripting language
php7.0-phpdbg - server-side, HTML-embedded scripting language (PHPDBG binary)
php7.0-fpm - server-side, HTML-embedded scripting language (FPM-CGI binary)
libphp7.0-embed - HTML-embedded scripting language (Embedded SAPI library)
php7.0-dev - Files for PHP7.0 module development
php7.0-dbg - Debug symbols for PHP7.0
php7.0-curl - CURL module for PHP
php7.0-gd - GD module for PHP
php7.0-imap - IMAP module for PHP
php7.0-intl - Internationalisation module for PHP
php7.0-ldap - LDAP module for PHP
php7.0-pgsql - PostgreSQL module for PHP
php7.0-pspell - pspell module for PHP
php7.0-recode - recode module for PHP
php7.0-snmp - SNMP module for PHP
php7.0-tidy - tidy module for PHP
php7.0-json - JSON module for PHP
php-all-dev - package depending on all supported PHP development packages
php7.0-sybase - Sybase module for PHP
php7.0-modules-source - PHP 7.0 modules source package
php7.0-sqlite3 - SQLite3 module for PHP
php7.0-mysql - MySQL module for PHP
php7.0-opcache - Zend OpCache module for PHP -
no need for PHP 7, really
-
@jospoortvliet said:
no need for PHP 7, really
Actually, I'd recommend it. My ownCloud 8.2 instance was slow on PHP 5.x... I upgraded to PHP 7, and it noticeably improved.
I have no other benchmarks against to measure 9, but it works rather nicely too.
-
@jospoortvliet said:
@JaredBusch said:
@jospoortvliet said:
Yeah, we keep hardening oC so you get more and more warnings... But you also get a more and more secure system if you do what they suggest
The docu should be up, if you bump in missing links, pls let me know!
Those warnings are silly in 8.2. Things like saying that I have no internet access
Edit: here is what my 8.2 panel shows on a fully updated CentOS7 install.
The 'no internet' error, just like many others, does come only when there IS a problem - so are the other warnings
I strongly suggest to take the security issues very serious, and no memory cache (performance) and PHP version (performance AND security) are also very useful warnings.
Isn't it better to know about these problems than not?
These errors show up immediately after install. The system obviously has internet access because it works. So that error is misleading.
Of course knowing is better. but. The problem is you are expecting things to be done outside of the repository. that is not a good practice.
You should never expect or require people to manage things outside of the repositories. That very quickly becomes unmanagable at scale.
-
@JaredBusch the alternative would be for us to ship a PHP stack, CURL and everything else which is outdated or broken. We're not a distribution
-
@jospoortvliet said:
@JaredBusch the alternative would be for us to ship a PHP stack, CURL and everything else which is outdated or broken. We're not a distribution
Or, of course, to cease support for the platform. And we dropped support for some with ownCloud 9.0 - see the upgrade blog.
-
@jospoortvliet said:
@JaredBusch the alternative would be for us to ship a PHP stack, CURL and everything else which is outdated or broken. We're not a distribution
Well, that's not the only option. Throwing an alert that PHP is no longer supported by PHP is fine and all, but misleading as it is alerting that the PHP supported by Red Hat is out of date, which it is not. You are choosing to define out of date in a way that is uncommon in the industry and there isn't a real need for that. Most companies, I'll guess over 90%, use Red Hat, Canonical or Suse's definition of "up to date" not the individual package maintainers.
You are free to do what you want and do is as you see fit. But the path you have chosen, to me and I think nearly all businesses, simply means that you've chose to throw pointless, useless errors which create "crying wolf" noise for no reason. It is worse than if the alerts were not there.
You do clarify that PHP is out of date "according to PHP" which isn't important. But to an application admin, this is confusing and they do not know who their PHP vendor is.
-
@jospoortvliet said:
@jospoortvliet said:
@JaredBusch the alternative would be for us to ship a PHP stack, CURL and everything else which is outdated or broken. We're not a distribution
Or, of course, to cease support for the platform. And we dropped support for some with ownCloud 9.0 - see the upgrade blog.
I would agree that if you feel the need to not trust the vendors that you support that you should remove them and focus on fewer. I think that throwing alerts for PHP while saying that you support the platform that you alert on is a bad combination. Don't call CentOS 7 fully patched "out of date" while saying you support the platform. Just say you don't support it and move on.
-
I think that this page is confusing. It doesn't just list CentOS and RHEL as peers with everyone else, it even lists CentOS first. If CentOS and RHEL are not supported, but are just "included for repos" there should be something that makes that clear. Going to this page led me to believe that CentOS was a top tier supported option:
https://download.owncloud.org/download/repositories/stable/owncloud/
-
What are the officially supported, no "you shouldn't run that", recommended distro(s) for ownCloud? How do we run it so that OC never sees us as doing anything except what is absolutely intended and recommended? I can't find clear documentation on that. What I found led me to the wrong stuff.
-
@scottalanmiller said:
@jospoortvliet said:
@jospoortvliet said:
@JaredBusch the alternative would be for us to ship a PHP stack, CURL and everything else which is outdated or broken. We're not a distribution
Or, of course, to cease support for the platform. And we dropped support for some with ownCloud 9.0 - see the upgrade blog.
I would agree that if you feel the need to not trust the vendors that you support that you should remove them and focus on fewer. I think that throwing alerts for PHP while saying that you support the platform that you alert on is a bad combination. Don't call CentOS 7 fully patched "out of date" while saying you support the platform. Just say you don't support it and move on.
That is the problem.
-
Here is what ownCloud is showing me as their distros. I'm confused...
Which of these are red herrings and which are real? CentOS and RHEL we've been told are "out of date" and unsupported in the other thread. SLE is old in the same ways as those. OpenSuse comes in Leap and Tumbleweed varieties. Leap is identical to SLE, so should have the same issues of being out of date. Debian isn't really a production platform. Same for Fedora. Ubuntu isn't ideal and has the confusion of their fake LTS and their every six months current release.
Where do we turn? What does ownCloud expect us to do?
-
I have a feeling that OpenSuse Tumbleweed, which many shops would be scared to run, is the actual only supported platform. That's not a horrible thing, if that is the case I would say just announce that, focus on it and move forward. Don't pretend that there aren't dependencies there and don't act like we aren't trying to stay totally current when we think we are doing what is recommended.
Just make it insanely clear that Tumbleweed is the one and only true supported platform and be done.
-
What's even crazier is that the worst possible option would be Ubuntu LTS. All of the "out of date" of something like CentOS 7 yet without the support infrastructure. ownCloud said that they are not in the distro business. Yet... they build their appliances on the most out of date, least supported option of the bunch, Ubuntu 14.04!! So these things totally conflict. ownCloud themselves is actively promoting the least business class, least supported, most out of date option while telling us that we are out of date and unsupported for trying to do the opposite.
I find this very upsetting. The message to the customers is extremely mixed.
-
@IRJ said:
The 9.0 appliance is built on Ubuntu 14.04
ownCloud just told us that LTS releases are conceptually bad (and I'm not disagreeing), so by extension, they don't feel that their own appliances are serious.
-
I'm not saying CENTOS or RHEL are not supported. I'm saying that those old versions ship with software with some know security issues and we warn for that. That is all. We're not in charge nor feel responsible for fixing those problems - they are Red Hat's or CentOS' problems, simple as that. But we want ownCloud users to be aware of problems we detect.
In case of the 'no internet access', this can be caused by a number of problems, from missing proper certificates to other stuff. I don't know why we don't give a more specific error message - perhaps nobody had time to investigate it, perhaps it is impossible as it is on a level below ownCloud (CURL is used by PHP which is used by ownCloud - we might not have access to the error that CURL throws).
Generally, the error is related to broken/insecure openSSL. My security guy tells me we actually do catch the broken-curl thing separately but some others are bunched together still.
Obviously, if customers bump into this, our support helps them track down the exact problem. There are probably even knowledge base articles available on our enterprise site on this subject. But that's different from users of the community edition of course. They have each other and the forums and github... Well, and a bit of me sometimes
-
@scottalanmiller said:
What's even crazier is that the worst possible option would be Ubuntu LTS. All of the "out of date" of something like CentOS 7 yet without the support infrastructure. ownCloud said that they are not in the distro business. Yet... they build their appliances on the most out of date, least supported option of the bunch, Ubuntu 14.04!! So these things totally conflict. ownCloud themselves is actively promoting the least business class, least supported, most out of date option while telling us that we are out of date and unsupported for trying to do the opposite.
I find this very upsetting. The message to the customers is extremely mixed.
A clarification: a customer is somebody who is paying us. Our messaging to them is on owncloud.com and perfectly clear with regards to platforms - CENTOS and RHEL are actually the preferred platforms, and ownCloud 9 is not available for customers at all.
