Secutity Upgrade CentOS

is it possible and safe to perform security upgrade of CentOS with the following command without affecting current Rockstor functionality?

yum --security upgrade

I have installed Rockstor 3.9.1-0 from ISO image, I made no further upgrades, and didn’t even choose between Testing and Stable Updates so far. Right now, I am waiting for the subscription to the Stable release to become available and in the meanwhile, I was thinking to perform at least these security upgrades of the underlying OS.

@Lukas Hello again and appologies for slow response.

Not sure of upgrade but you can do as you wish re yum updates, ie:

yum update

also not that the Web-UI has an indicator to the left of the kernel version to present ‘all but rockstor’ package updates.

You could for the time being select testing, just keep in mind that there is a known bug when moving from testing to stable that requires a:

yum update rockstor

as the following chicken and egg bug ends up showing available rather than installed when moving from testing to stable channels. It’s fixed in an update:

but given the issue it never offers that update (via Web-UI) hence the one of ‘yum update rockstor’ requirement to get the fix !

Bar that testing channel should give you better Rockstor code than what the iso release contains.

Just remember that once the update has been initialised it will take quite some time to perform as there are many hundreds of MB of packages to download and install (our iso is now quite old); so give it time and keep an eye on activity so that you don’t accidentally reboot mid update. Oh and testing channel should also give you a newer (although still old unfortunately) kernel so worth changing to testing in the mean time just for that.

Hope that helps.

Hello @phillxnet and thank you for the deatiled answer.

First of all, I’ve tried to update the system with the command:

yum update

which result in updating everything including Rockstor - to package rockstor-release-3-8.16.el7.x86_64
Although I have not selected a test or stable branch yet (in the WebUI), I assume that the package automatically used is in the test branch.

I rolled back the changes (I am testing on VM environment) and tried updating everything except the Rockstor package:

yum update --exlude=rockstor*

Here I ended up with the same error as if I was updating via WebUI:

Error: initscripts conflicts with rockstor-release-3-8.16.el7.x86_64
You could try using --skip-broken to work around the problem
You could try running: rpm -Va --nofiles --nodigest

Finally I have tried to updat the system with the following command:

yum update-minimal

And this has been successful.

I am now in the situation, that I need to prepare the Rockstor to production environment in a few days, so, my question here is, regarding the suggestion by @phillxnet:

testing channel should give you better Rockstor code than what the iso release contains

Should I update to rockstor-release-3-9.23.el7.x86_64, even if it is the testing release and I plan to deploy that into the production environment?
Or should I rather stay with the Rockstor 3.9.1 and wait for the stable release?

No, the testing repo is only used if selected, as per the stable. But the iso comes with a default rockstor repo and the rockstor-release package that you saw updated is not the core rockstor code, that is held in the rockstor package.

yum list installed rockstor*
Loaded plugins: changelog, fastestmirror
Loading mirror speeds from cached hostfile
 * base:
 * epel:
 * extras:
 * updates:
Installed Packages
rockstor.x86_64                                                3.9.1-0                                            @anaconda/3
rockstor-release.x86_64                                        3-8.16.el7                                         @anaconda/3

where the contents of the rockstor-release package is as follows:

rpm -ql rockstor-release.x86_64

The error you encountered:

Was due to a conflict with upstream (when CentOS had a version update) that arose after the iso was released and was then fixed in the default repo. However your “–exlude=rockstor*” side stepped that fix in the understandable belief that this package represented more than it actually does: see above file list for that package’s contents).

And so after a yum update (no update channel selected) we have:

"Transaction Summary

Install 11 Packages (+51 Dependent packages)
Upgrade 341 Packages

Total download size: 288 M

which ends requesting 3 more keys on the way with 2 pertaining to the “rockstor-release-3-8.16.el7.x86_64” package and another to the “epel-release-7-9.noarch” package.

_ yum-plugin-changelog.noarch 0:1.1.31-50.el7 yum-plugin-fastestmirror.noarch 0:1.1.31-50.el7 _
_ zlib.x86_64 0:1.2.7-18.el7 _

_ NetworkManager.x86_64 1:1.4.0-20.el7_3 grub2.x86_64 1:2.02-0.44.el7.centos grub2-tools.x86_64 1:2.02-0.44.el7.centos _
_ pygobject3-base.x86_64 0:3.14.0-3.el7 rdma.noarch 0:7.3_4.7_rc2-6.el7_3 usbmuxd.x86_64 0:1.0.8-11.el7 _


ie no errors and everything updated via the suggested “yum update”.
and we also see that our rockstor packages are now thus:

 yum list installed rockstor*
Loaded plugins: changelog, fastestmirror
Loading mirror speeds from cached hostfile
 * base:
 * epel:
 * extras:
 * updates:
Installed Packages
rockstor.x86_64                                                3.9.1-0                                            @anaconda/3
rockstor-release.x86_64                                        3-9.23.el7                                         @rockstor

With the Rockstor code held in the rockstor package.

Tested in full just now so that’s the best I can contribute for the time being by way of supporting my original suggestion.

Which still leaves you with the well old rockstor code that was released on our last iso, ie 3.9.1-0. The testing channel, which no longer receives updates, stopped at 3.9.1-16, and received 16 fixes released since the 3.9.1 iso.
3.9.1-16 code was released in stable channel as ver 3.9.2 where upon our focus moved to updating only the stable channel between iso releases, effectively so far anyway, and we are now overdue for a new iso. However the next iso work may well go into our next generation of Rockstor which is to be rebased on the openSUSE distributions due to it’s native (and default) support for btrfs and due to their sponsors, SUSE among them, employing many of the btrfs developers.

So you see our last testing release was actually the first of the next line of stable releases:
3.9.1-16 =
where by rights would otherwise have been another iso but it didn’t pan out that way this time (human resources mainly).
And we have since 3.9.1-16/ had 45 additional releases.

The changes relating to each release are available on our GitHub Releases page:

So again, adding no repo gets you everything bar rockstor and the kernel updated as we carry our own (in testing and stable repos) as our old base of CentOS/RedHat had really really old kernels and only a technical preview of btrfs which was never updated hence having to use elrepo’s kernel-ml (another reason we are moving to openSUSE as we have failed to keep this updated, even in our own repos - resources again). The RedHat technical preview was then depricated as they no longer employed the one person they use to employ on btrfs. Hence our slow but steady move to openSUSE.

I hope that this helps to re-assure you and I know it’s a poor show that our stable subscription which directly leads to my further sustainable involvement in the project is currently still “Sold Out” but I have no control over that. I am for the time being continuing my contributions in the hope that Rockstor re-asserts it’s path to sustainability as we have many who want to support us financially yet cant due to the shop bug/issue. Very frustrating for all concerned. @suman, current project lead, is the only contact I have for this show stopper ‘bug’ in our shop and I have unfortunately not as yet heard anything re this issue.

Thanks again for your patience re the stable channel subscription ‘sold out’! It’s an alarming issue for all concerned and given the difficulty in achieving sustainability when developing open source, quite surprising. However I am not currently aware of the actual problem afoot here or the significance of the amount collected via the stable channel.

Thank you @phillxnet for this detailed answer - especially the part about the correlation between the current testing and stable channels status.

I have finally decided to select the testing channel and made the update. I am now on the 3.9.1-16 and everything works like a charm :slight_smile: Now I will wait for the availability of the stable channel.

There is one more thing, that I though of. Would it be possible to pay for the stable subscription using prepayment invoice and wire (bank) transfer? This way, we could bypass the problem with e-shop.

@Lukas Glad your up and running and you are welcome.

That’s an idea but I really don’t know. This one is firmly in project lead @suman realm. So unfortunately I’m unable to answer that one.

Ok, I understand. I will try then to write e-mail to
Anyway thank you very much for all support on this forum :smiley: