File “/opt/rockstor/src/rockstor/rest_framework_custom/generic_view.py”, line 41, in _handle_exception
yield
File “/opt/rockstor/src/rockstor/storageadmin/views/rockon.py”, line 395, in _get_available
response = requests.get(remote_root, timeout=10)
File “/opt/rockstor/eggs/requests-1.1.0-py2.7.egg/requests/api.py”, line 55, in get
return request(‘get’, url, **kwargs)
File “/opt/rockstor/eggs/requests-1.1.0-py2.7.egg/requests/api.py”, line 44, in request
return session.request(method=method, url=url, **kwargs)
File “/opt/rockstor/eggs/requests-1.1.0-py2.7.egg/requests/sessions.py”, line 289, in request
history = [r for r in gen] if allow_redirects else []
File “/opt/rockstor/eggs/requests-1.1.0-py2.7.egg/requests/sessions.py”, line 133, in resolve_redirects
proxies=proxies
File “/opt/rockstor/eggs/requests-1.1.0-py2.7.egg/requests/sessions.py”, line 279, in request
resp = self.send(prep, stream=stream, timeout=timeout, verify=verify, cert=cert, proxies=proxies)
File “/opt/rockstor/eggs/requests-1.1.0-py2.7.egg/requests/sessions.py”, line 374, in send
r = adapter.send(request, **kwargs)
File “/opt/rockstor/eggs/requests-1.1.0-py2.7.egg/requests/adapters.py”, line 213, in send
raise SSLError(e)
SSLError: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:618)
I’ll try to see if I can find the source of this; it might be an old package on CentOS7 that Rockstor 3 uses, or maybe related to our somewhat recent backend upgrades. @phillxnet, do you think it could related to that? Rockstor-3 is still using http for the remote metastore URL after all…
We haven’t touched the CentOS repos since they were last updated. However we did move to redirecting our Rock-ons from http to https. My guess is that the CentOS system used in our legacy installer now has outdated root certificates for the new https validation.
It may be that doing a
yum update
at the command line as the ‘root’ user will resolve this. But far far better to start over with our v4 installer all around really.
Curious. And although we sign our newer v4 zypper repos for the ‘Built on openSUSE’ v4 variant we never did sign our yum repos. Not directly relevant here.
Also the certificate used for the rock-ons https access is as-per the one used for:
Hello, tried the UYUM update which prompted to allow 3 certs from CentOS (x2) and one from what appeared to be rockstor. I assumed this is what you anticipated. After update the error remains. It seems more to do with the redirect than the certs?
Traceback (most recent call last):
File “/opt/rockstor/src/rockstor/rest_framework_custom/generic_view.py”, line 41, in _handle_exception*
yield*
File “/opt/rockstor/src/rockstor/storageadmin/views/rockon.py”, line 395, in _get_available*
response = requests.get(remote_root, timeout=10)*
File “/opt/rockstor/eggs/requests-1.1.0-py2.7.egg/requests/api.py”, line 55, in get*
return request(‘get’, url, *kwargs)
File “/opt/rockstor/eggs/requests-1.1.0-py2.7.egg/requests/api.py”, line 44, in request*
Alternately, couldn’t the JSON file be placed on the server so the app doesn’t have to retrieve it? Once the list has been retrieved and unless Rockstor updates the Rock-On repo it should be static, correct?
We had a product that performed FLAWLESSLY up until about 3 to 4 weeks ago. I see Rockstor stopped Incident Based Support for Rockstor 3 on the commercial side. What are we to do, we cant even pay you to fix this
It’s actually a little of both. Our redirect from http -> https, introduced recently after popular demand, in combination with a root cert change in Let’s encrypt, means that our older version of requests (at least on the CentOS patched side) doesn’t recognise the ssl cert any longer. The update suggestion of mine was in the hope that ‘requests’ referenced system certs but the intrepid @Flox has tracked down that this is in fact not the case in our CentOS version. And as we can no longer build rpm packages for CentOS (we did parallel builds for as long as we were able) we can only offer a hand-patch to get this resolved. But as stated we no longer support the CentOS version as we favoured focusing on getting a more viable option available instead. Adopting instead an upstream that actively supports btrfs rather than actively dropping it form a meagre technical preview status.
However the v4 “Built on openSUSE” endeavour took a lot longer than anticipated and we failed to for-see our inability to build the CentOS based rpms. Leaving an unfortunate gap in support’. But we have at least now side-stepped the CentOS ‘change of heart’ (read Red-Hat re-defining / re-purposing the CentOS folks they now employ).
As stated @Flox to the rescue. But keep in mind that this is not maintenance. That would be updating to a supported OS. Or at least an OS that actively supports/fixes your base filesystem. Hence our v4 initiative.
My apologies for predominatly my failure to get v4 out-the-door. Please be patient. I am, as we speak, working on the web-site to help with aiding in the distribution of our soon to be pre-build installers. But we have and have had a DIY installer build options for quite some time now in the form of our installer recipe which in-turn inclues a Release Candidate 10 v4 variant that is far and away better than anything we have ever offered before. And, just to stress this point, receives upstream updates to kernel. This also is something never before seen in Rockstor’s history. We are really trying to help folks out here so please be patient.
Hope that helps and please be patient as @Flox fathoms just a little more in this area that he has so kindly delved into in quite the detail since we were made aware of this issue in our legacy v3 installs.
I am perfectly fine waiting. And there is even good in all this. In the past couple weeks I have learned Docker, Portianer, cockpit, and Samba shares on Ubuntu Server. I could post a tutorial for newbs at this point, lol. But alas, I would still rather have the Rockstor GUI that I have come to love!
So I took your initial advice of just using the new installer. Seemed simple enough. However, when following the steps on the git hub page… It appears you left something out, I think? See here: https://github.com/rockstor/rockstor-installer#edit-rockstorkiwi
"Leap15.2.x86_64 profile
Executed, as the root user, in the directory containing this repositories rockstor.kiwi file.
I downloaded leap 15.3 which is supported per the document. However when installing and getting to the “Edit rockstor.kiwi” you only have a command for 15.2, not 15.3. So the instructions, although prep the install for using the 15.2 or 15.3 label, there is no mention of 15.3 in the final steps and you could only, in theory build on 15.2.
I am reading this right and someone just forget that section when they last updated for 15.3?
I assume I can download a 15.2 ISO, but using the logic of this thread uses and how Rockstor is moving forward without looking back, it seems it would be useless to even install on 15.2?
Please help me out. I want to build this thing back as quickly as I cant but this threw me. Ive never used Suse / kiwi-ng before, only Ubuntu, so its a little foreign to me. So I am not sure if this 15.2 vs 15.3 is indeed even relevant?
One last question from my first question. I think you missed in your responses…
Is it all possible to just wget the json file and place it where it needs to be for digestion or does it not work like that.
Secondly, what line of code sends the request to rockstor.com? Could we just edit that line of code, send it to a sudo server and get it https’ed?
This may sound stupid but dont laugh. I am an also an open source developer on Android. Mostly ap[ps and ummm “reverse engineering :)” One time I figured out how to bypass AT&T’s tethering restrictions by decompiling a specific library, changing the URL, recompile and place int he /system with the original app signatures. For example this is what I produced: [MOD][5/22/2015][ATT] - Tether hack - OE2 build | XDA Forums (xda-developers.com). Long story short, the ATT server looked at the telephone number making the request for tethering. From there they decide if you get tether. With my hack, it reouted it to my ROM server and every one got free tether (for educational purposes of course!).
Could I do something like this here or would that be just too simple for this situtaion?
Also, I found the open Suse 15.2 ISO, I Download finished as I was typing this out so I will run through the git hub article with 15.2 tomorrow when I am bored at work.
Oh and one final suggestion. This is just small point of criticism beyond any typos or missing data. Maybe you could just post a script for us depending on the Leap version we are installing on. Ideally the script would be a copy and paste from the GitHub instructions in an executable format. I believe you may see a faster adoption rate if you do.
As @phillxnet previously mentioned, I posted a brief workaround to temporarily resolve this issue in a dedicated thread:
While we still recommend to transition to Rockstor v4, the manual described in that thread linked above should help you temporarily get around the problem reported here.
Yes, indeed. Our 15.3 work is far newer given we have now released rpms for 15.1 & 15.2 for their entire supported cycle, come November. And have yet to finalise our ‘focus’ to the 15.3 variant. We have a pending issue in that repo to ‘up’ the Readme thus:
Which would be a good opportunity to move the example commands along some. We actually started the transition on Leap 15.0 !!
You can get away with zero edits to the rockstor.kiwi. Nice if you do as you get a nicely named installer file but it’s not required. I recently clarified this in the Readme. Just specify the 15.3 profile instead of the 15.2 and ideally use a Leap 15.3 host to do the build on. But again a Leap 15.2 install will currently happily create a 15.3 profile.
Not forgotten just awaiting the contribution / time for the doc/Readme changes. All in good time.
There are no official public downloads as of yet (but soon). Hence folks using the rockstor-install repo Recipe which is the exact same way we are building our current closed beta installers for testing before we finally release pre-built installers.
I’m not sure that fair actually. We are about to provide a workaround for our 2017 installer. That’s a fairly good show I’d say. And we released updates for it 3.9.2-57 (stable channel) which was April 2020:
And only stopped when an included upstream library in CentOS became completely unworkable and broke our ability to build. And by then the “Built on openSUSE” endeavour was well underway (just as well it would seem).
Use either a 15.2 or 15.3 openSUSE Leap install to build a 15.3 profile by substituting the 15.3 profile name in the 15.2 example. That all.
No unfortunately. That is an ‘index’ and there is then one additional json for each Rock-on. See:
Note also that you can have a local repo, intended for local development but interesting never-the-less. See the readme in that repo. It’s how folks develop Rock-ons before submitting them to that repo.
Just addressed by @Flox as I was typing this it seems. The venerable and all that
Again I think @Flox has just posted a work around here and from what I’ve seen previously of it it’s quite neat. Essentially the old CentOS patched requests just needs a leg-up. All irrelevant in v4 for now at least.
Also if you are interested in how the Rock-ons internals work see @Flox exemplary technical wiki entries here:
No reverse engineering necessary . Thanks again to @Flox for re-vamping and maintaining our Rock-ons and doc by the way. Also have you seen the rock-nets ?
Then you might like to take a look at our ‘workings’. All that runs on folks machines in Rockstor is open source. Again no reverse engineering necessary. Although our continued efforts and infrastructure costs dependant our our Stable release and support model. So theirs that.
Agreed. Fancy submitting a pull request containing these scripts. But note that the actual build process is essentially a single kiwi-ng command !! And our main aim in the repo is to inform and facilitate. Those that struggle with this as-is are also those who are likely to just resource a pre-build installer. But building your own is super empowering and something I personally am really pleased we have achieved. But yes, our instructions need work However we now have 6 possible targets (2 OS * 3 machine targets (across 2 architectures)). So the script would need to account for that. But again scope for improvement as always.
Thanks for your enthusiasm and I think you will find straight forward engineering far more rewarding than the reverse kind. That way everybody wins which is key in an open source environment.
Hope that helps. And do take a look at our various code repositories. Almost all code is now black formatted (on the Python front) and fairly well documented/self documenting. We have a fair bit of technical debt but we are a small team so are always limited by people resources.
Your awesome! Thanks for all the info. Its greatly appreciated! I just cant see myself using another NAS solutions. I have tried them all, built my own, but still come back to Rockstor. Its just that great!!! Now I can even recommend Rockstor based on the level of support I got on this thread. You and your team are awesome! Thanks for doing what you are doing! Seriously!
Yes, gotta agree with that one. I have found the Rockstor team to be very helpful and friendly, and very willing to take on board thoughts and suggestions from users. Also, the community here is just as good to be a part of.
With the forthcoming release of v4, there are more great times ahead for this excellent NAS solution.
I only discovered Rockstor last year and it has been a revelation for me.
