@scottalanmiller said:

@jospoortvliet said:

Again, you want us not to warn even though there IS something broken, even though we can't figure out exactly what it is?

I never said that in the least. I want you to fix your bug where you report the wrong thing. Simply report the truth, don't hypothesize and act like the issue couldn't be the most obvious thing.

And likewise, I'm telling you that you have a bug. A bug that you've stated yourself that you have in your description. Do you not want us telling you when ownCloud has a very obvious problem and just ignore it?

We have been telling you that you have issues and you are making excuses to act like the system should be wrong, should throw false errors, etc. I want real errors as a best case, no errors as an acceptable case, and never false errors. Nothing is worse than false errors.

I'm sorry, what? I've agreed that the wording on one of the warnings is unclear - it should probably state "ownCloud failed to connect to ownCloud.org" rather than "this server has no working internet connection". Despite the bad wording, it is still not a 'false error': there IS a problem with the server configuration and the lack in clarity of the error message is sad but bugs happen and this minor wording problem can be fixed with a very simple pull request on github. And if a customer would have this problem, they have a phone number to call.

The other errors - perhaps you don't trust them, that's fine. I do unless I see evidence to that points out that they're wrong, that's all I said. And I still don't see how you can claim that warning about outdated PHP or cURL versions is a bad thing.

As you stated:

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 caused by a mis-understanding we had about the term 'support'. I think I explained what I mean with it - and how it couldn't mean anything else unless we're talking about a customer-vendor relationship. Which, here, we're not - ownCloud is an open source, volunteer-run project and you're users who use it for free. When we say 'support' - don't expect more than you can expect from any other open source platform. And thus, yes, a 'platform' which we 'support' can be a 'problem'.

@scottalanmiller said:

@jospoortvliet said:

Then about the term 'supported platforms' you seem to consider 'vague' from me. First, I didn't know what centOS version was being used so perhaps I was to quick saying it might not be supported. Supported is CentoS 7. But the term 'support' seems mis-understood here, too.

Looking for a version that doesn't cause ownCloud to ever consider saying that maybe we are on an outdated and unsupported OS. I want the version that ownCloud stands behind and takes ownership of working on. I want the version that the conversation that happened won't happen on.

Ah, ok. Honestly, I don't know. I run openSUSE 13.2, I don't have these issues. So that one certainly works. I guess SLE and LEAP might work, too. It surprises me too that these errors occur on the latest CENTOS, isn't that based on the latest RHEL? Amazing that these are so outdated, or, indeed, perhaps there's a bug in ownCloud which incorrectly states these things. Again, if you are sure of that - file a bug. Please forgive me for assuming our software does what it should do until I see evidence to the contrary.

@scottalanmiller said:

@jospoortvliet said:

There is a cURL warning. The system uses an outdated NSS version. There might not be a newer version from your vendor, but that does not make it any less outdated or insecure - bug your vendor. You have a problem with us warning you about issues in a platform, even if we support that platform? Sorry, that's a no-fix. We warn of issues, even if we can't fix them.

Are you confident that you are checking that correctly? Is the RHEL version not patched? Have you confirmed that? If so, then okay, good catch. But from the other things, I'm guessing that this is based on an incorrect assumption and is a false alarm. The track record thus far of crying wolf has already made me sceptical of claims like this.

Do you have information on what this version is not patched?

It gives pretty specific information but if it isn't patched or not - that's a question for our security guy who maintains these issues. If you know for sure that this version is perfectly fine, file a bug and we can fix this. For now, I'll trust our security guy.

@scottalanmiller said:

@jospoortvliet said:

Now the 'no internet access' error above it - this is most likely caused by the cURL version. What the error warns about is simple: ownCloud tries to connect to https://www.owncloud.org - if it can't, it gives this warning.

Exactly, that's what's wrong. You are testing a certification via HTTPS, not testing Internet access. Then you report that Internet access is not working. Those are two different things. This is pretty basic - don't check one thing and report something else. This is an ownCloud bug, very clearly.

Well, it won't work - it won't be able to do what it says, like installing apps from apps.ownCloud.com because it just tried to connect there and failed. That's enough for not working, I'd say. Not saying there's no room for improvement here, feel free to file an issue or submit a patch - but it isn't so horribly wrong as you seem to imply.

@JaredBusch said:

@JaredBusch said:

@jospoortvliet said:

re why the YUM repo doesn't have ownCloud 9.0 - that might actually be because we don't support your old OS anymore? See the upgrade blog for what we support as of today. You can use packages from another repo, actually, as the 'owncloud-files' one has no dependencies or other magic and thus should work nearly anywhere. That way, you can still have ownCloud 9 if you want.

But I'd recommend not to run such old software if you can avoid it.

My old OS? WTF?

Last login: Wed Mar  9 10:39:15 2016 from 10.254.103.20
[root@oc ~]# cat /etc/redhat-release
CentOS Linux release 7.2.1511 (Core)
[root@oc ~]# rpm -q centos-release
centos-release-7-2.1511.el7.centos.2.10.x86_64
[root@oc ~]# uname -rmi
3.10.0-327.10.1.el7.x86_64 x86_64 x86_64
[root@oc ~]#

@jospoortvliet I am still waiting on you to answer this...

sorry, I was juggling to many threads and mixing up some. I didn't know what OS you were running, we dropped support for Fedora for example. You run CentOS 7.x, that we provide packages for. And that is all that 'support' means (unless you're paying for a actual support contract with Inc, of course). So if there are problems with a platform we provide packages for - well, we'll warn you about those problems. We can't fix them (your vendor has to) but we warn about them.

See http://mangolassi.it/topic/8379/owncloud-9-is-here/96 for a longer answer to a similar conversation.

@scottalanmiller said:

@jospoortvliet said:

well, if you are running a broken CURL or openSSL, we warn you. If those come with your platform, even if we support that platform, it is still broken, so we warn you. I don't see how that is bad...

PHP wasn't broken, though. That was the issue that was more key. PHP was fully up to date on a fully updated install, fully supported by the correct vendor and yet still the alert.

perhaps we're mixing up things here. Let's go back to the image we're talking about:

There is a cURL warning. The system uses an outdated NSS version. There might not be a newer version from your vendor, but that does not make it any less outdated or insecure - bug your vendor. You have a problem with us warning you about issues in a platform, even if we support that platform? Sorry, that's a no-fix. We warn of issues, even if we can't fix them.

There is a PHP version warning. That PHP version is old and no longer supported by the PHP project. Yes, it there might not be a newer version from your vendor for your platform. That does not make it any less outdated etc etc etc.

We could disable these errors - it might make you feel better but it would make your platform equally insecure. That is called a false sense of security. Gosh, I expected that you'd appreciate the fact that we won't do that.

Now the 'no internet access' error above it - this is most likely caused by the cURL version. What the error warns about is simple: ownCloud tries to connect to https://www.owncloud.org - if it can't, it gives this warning. There can be 100 reasons why it can't connect: a broken DNS, no network connection, a broken PHP, the wrong moon phase and many more. Some of these we can detect and give more detailed errors (that's why we warn about cURL and PHP there!), others we can't detect. Doesn't mean there is no problem, so we'll still tell you about it. What you do with it - well, Google the problem, ask on a forum or, if you have a support contract, call our support.

Again, you want us not to warn even though there IS something broken, even though we can't figure out exactly what it is? Wow! I hear this from our support team too - some admins want warnings to disappear without having to actually solve the problem. Well, the customer is always right I guess, but I wouldn't hire somebody with the attitude of ignoring problems rather than fixing them. No offense.

Then about the term 'supported platforms' you seem to consider 'vague' from me. First, I didn't know what centOS version was being used so perhaps I was to quick saying it might not be supported. Supported is CentoS 7. But the term 'support' seems mis-understood here, too.

Let me be clear: nobody gets any support until they PAY. Then they get a contract. If you have no contract, the term 'support' means the same as it means when you hear it from Ubuntu, KDE, LibreOffice and everything else which is free and from a community of volunteers: it means we do our best to run on these platforms. NOTHING MORE. We certainly don't promise these platforms are awesome and great for our software. Those platforms might suck and in that case, we give you warnings. We feel no obligation to fix those problems - you, as sysadmin, can, if you like. You probably should, but - that is not our call. If we fail in anything, well, you can file a bug or help us fix it - we're an open source project (until somebody pays us, then we're ownCloud, Inc. and they get to yell at us all they want).

I hope that that is clear and sane.

Of course, if this level of transparency makes you feel uncomfortable or unable to trust us, there are plenty of projects out there who would be happy to not spend any resources and time on warning their users about security or performance issues at all and paper over any problems of the underlying platform. I know there is no other open source file sync and share which has a decent security vulnerability disclosure policy, for example - and no publicity about security bugs might mean there are none, at least to some people. Good that there is choice, right?

@scottalanmiller said:

@jospoortvliet said:

Seems like your internet connection is working again? If the error is still there, I looked and it is caused by a problem with the CURL version your PHP is built with. In other words, it is a bug in your distribution which causes this error. ownCloud tries to check if it is connected, it gets an error and thus lets you know that. You'll find the error in your logs. See this github issue.

cURL is testing and failing on a certificate, not on the Internet connection according to what I read there. That would mean that the error is also wrong as it isn't the Internet test that failed. So while you can say that cURL has a bug, the error is blatantly wrong given the error that happens. So while cURL needs to be addressed, this is obviously an ownCloud bug too that needs to be fixed. Bubbling up a false error message is always wrong.

True, it'd be nicer to give a warning which accurately reflects the problem. I guess this is low in the stack and can't be detected by ownCloud, or we just didn't get to fixing this part...

@scottalanmiller said:

@jospoortvliet said:

On a different note, with each release our packages have been in flux - we very much recognize that by trying to provide packages, we've taken on a task which seems to be too large. We might do what most other PHP web apps do - just offer zip and tar balls. But that's up in the air, I really don't know what we'll do here. Help with packaging is obviously welcome...

Packaging is good, but I would limit it to platforms that you feel are modern and supportable. If you feel the need to warn, I would hesitate to provide a package in the same way as the full support packages.

Yeah, that's sane, I don't disagree with you here. But we also have to provide what users need - and many run RHEL and CENTOS. And, as there are ways to fix the problems we point out (you can grab a newer openSSL or CURL), we warn...

And we did drop a number of platforms to keep things more manageable... Hope this will help improve stuff.

@scottalanmiller said:

@jospoortvliet said:

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.

But you are still calling them problems. That, itself, is a problem. You are saying that the platform itself is a problem. This isn't a bug, this is the concept of the platform.

well, if you are running a broken CURL or openSSL, we warn you. If those come with your platform, even if we support that platform, it is still broken, so we warn you. I don't see how that is bad...

On a different note, with each release our packages have been in flux - we very much recognize that by trying to provide packages, we've taken on a task which seems to be too large. We might do what most other PHP web apps do - just offer zip and tar balls. But that's up in the air, I really don't know what we'll do here. Help with packaging is obviously welcome...

@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.

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

@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.

@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

@scottalanmiller I agree on your stance with regard to LTS, by the way

I think that the LTS idea is just not really that relevant anymore in 2016. Better upgrade often and in small steps with each perhaps a minor issue to resolve than only break everything once every three years...

re why the YUM repo doesn't have ownCloud 9.0 - that might actually be because we don't support your old OS anymore? See the upgrade blog for what we support as of today. You can use packages from another repo, actually, as the 'owncloud-files' one has no dependencies or other magic and thus should work nearly anywhere. That way, you can still have ownCloud 9 if you want.

But I'd recommend not to run such old software if you can avoid it.

the fact that there's no more up to date CURL/NSS version for your OS doesn't mean the problem has gone away

Seems like your internet connection is working again? If the error is still there, I looked and it is caused by a problem with the CURL version your PHP is built with. In other words, it is a bug in your distribution which causes this error. ownCloud tries to check if it is connected, it gets an error and thus lets you know that. You'll find the error in your logs. See this github issue.

with regards to the VHDX, we decided to remove the VHDX for now, we can't built it due to a server problem... It'll be back but that can take a while. Sorry! Hope the other formats suffice.

Thanks for your feedback !

ok, got it. Well - this is a business thing, if .com decides to open it (they've done it for other features before) that'd be nice. But it won't be for 9.0

no need for PHP 7, really