I stucked here:
sudo ds
[sudo] password for docker:
2019-03-27 21:39:14 [INFO] yum package manager detected.
2019-03-27 21:39:14 [INFO] Removing old Docker packages.
2019-03-27 21:39:22 [INFO] Upgrading packages. Please be patient, this can take a while.
2019-03-27 21:41:56 [INFO] Installing dependencies.
2019-03-27 21:42:53 [INFO] Removing unused packages.
2019-03-27 21:42:59 [INFO] Cleaning up package cache.
2019-03-27 21:43:05 [INFO] Installing latest docker. Please be patient, this can take a while.
2019-03-27 21:43:20 [FATAL] Failed to install docker.
The short answer is no. Rockstor is designed to manage docker integration itself.
The long answer is a bit more complex, but it largely comes down to “you’re playing with things that aren’t mean to be played with”, and as your modifications fall outside of supported configurations, I don’t foresee anybody knowing specifically how to resolve your issues.
In essence, if this were your 2004 Ford Escort, you’ve just come to ford asking why it stopped running when you put a 2019 Ford Explorer engine it. We don’t know.
The command you’re running, ‘ds’ has removed packages that Rockstor relies on, which means that the rockstor packages themselves have likely been removed as part of that - breaking your Rockstor installation.
In particular, part of your install script calls the following:
This is removing docker, and everything that relies on it, and because of the -y, it’s doing it forcibly, with no confirmation requests and no output.
This means that when the yum command wants to ask ‘In order to uninstall docker, I also need to remove rockstor-core and some other things’, it’s being told ‘yes’ in advance, and just does it.
As such, my first suggestion would be to try reinstalling the Rockstor base package from the repo, failing that - wipe and reinstall.
If you plan on doing things like plugin management (Rockons/Docker containers) manually, I strongly suggest that something designed as an appliance is not for you, and you’d be better off with a standard Linux install and configuring the OS to your requirements as you go.
You’re better off seeking answers for your rockon problems.
Rockstor thinks that it’s the default method for working with docker containers. Even if you found a way to install DockSTARTer alongside Rockstor, you’ll just end up with issues when these two things conflict.
It’s not a viable option to try and replace 1 part of the Rockstor appliance’s functionality.
Unless you want to fork the repository, pull the Rockstor code apart, kill the references and hooks to Docker and run your own complete custom installation, this is not a good idea, and it’s just not going to work.
I disagree with Haioken, Rockstor works fine with other docker containers installed. You’re not going to see them in the main UI, but if you’re fine with that, Rockstor will run fine, assuming your app doesn’t remove needed parts
Regarding having no WebGui, your best bet is likely to reinstall from scratch again.
Rather than using DockSTARTer I would recommend trying Portainer.
I created a Portainer rockon, and then used that to setup other docker instances.
If you want to use Portainer like I did, you can put the following portainer.json into /opt/rockstor/rockons-metastore and then install it as a Rockon in Rockstor itself.
He’s not asking to install other containers , he’s asking to install a container management system that inherently conflicts with Rockstor, and that cannot (without forking and altering the codebase) be removed.
Unlike Portainer, Dockstarter wants to install a non-package maintained local instance of the Docker engine, removing the package managed one in the process.
This kill the Rockstor.
He can screw with the backend scripts of Dockstarter, however Dockstarter is designed to use Docker’s currently bleeding edge updates.
This likely kills the Dockstarter.
Most importantly, I believe that Portainer communicates with Docker over Docker’s native API (either via TCP or local unix socket), whereas DockStarter seems to be little more than a shell wrapper around docker and docker-compose - this is much more likely to have compatability issues with unexpected docker versions, and also much more likely to conflict with Rockstor’s in built functions which also communicate with Docker via the shell and expect particular versions.
That’s why I said he’d have to go digging through the scripts to make sure it doesn’t mess with docker.
It seems that I did misunderstand you slightly, as I got the impression you meant ANY other container manager, rather than DockSTARTer itself. My Apologies.
To add to this: it would be considered a Bad Idea™ to try and replace the default Docker version, for example with the Docker CE version that’s being supported by Docker itself?
I was wondering about this, since the currently installed version is so old it’s still in black and white… Also, is the whole Docker version thing taken into account with relation to the switch to Suse? Is it possible for Rockstor to depend on a Docker version being present on the system, without being absolutely tied to a specific version from the CentOS repos?
Yes the testing updates channel does have a way old docker version (nice touch with the black and white there) but the stable updates channel moved to docker-ce at the end for 2017:
Although it’s version is old as well, however re:
we have made our wrapper able to use the latest Tumbleweed docker-ce version and given Leap15.1 and Tumbleweed both launch docker differently from each other and from CentOS we have now in place (in latest stable) code that adapts our docker wrapper accordingly. This was added at the end to 2018 as part of the following pull request:
i.e. “Add distro aware docker.service template file selection based on distro.id(); moving fully to a live edit (during Rock-on service enable) rather than build time customization: ie to accommodate for our docker wrapper redirect and it’s consequent requirement for NofityAccess=all for Type=notify docker configs. Both included openSUSE templates are taken from their respective distro default installs of docker-ce.”
Although in the case of Tumbleweed they made a recent change that we have yet to account for in code, but it should be fairly easy to sort, see:
The “UNKNOWN VERSION” is an indication of a ‘built from source’ install as that version display otherwise keys from the rockstor rpm version.
Note though that the indicated version of Tumbleweed (see mouse over tooltip) is now most likely getting long in the tooth at 2 days (as of writing)
And Tumbleweeds current default docker-ce version is as follows:
tumbleweed:~ # docker --version
Docker version 18.09.3, build 774a1f4eee66
Yes, in latest stable channel updates, and when on openSUSE LEAP 15.1 or Tumbleweed (above caveat currently) we use the distro’s included docker-ce version. We want to move to rely on the upstream distro’s versions of as much as we can as they obviously have more resources/expertise which, in time at least, should allow us more time to develop Rockstors; which is far more in our wheel house.
Hope that is at least encouraging, at least on the docker front anyway.
The whole rockon system was keeping me from testing Rockstor but with access to portainer… I’ve already got an install up and running and copying over TB’s now for further testing & evaluation.
Just as a side note, since that portainer.json example was created, Portainer has moved to split into a biz and community edition so that original image from back then has been deprecated (it’s still listed on docker hub, but not actively maintained anymore).
Thanks a lot. I’d like to install Immich on my Rockstor somehow, but as it is not listed among Rockons (yet), I guess it might work via Portrainer. I will keep you informed, how it is going.
It’s easy. Just activate rockons, then install portainer using portainer cli command. Then you can install all docker containers you need using portainer.
Not a supported method from rockstor, but it works.
I would use a different share than rockon installations, so there is no conflicts there.
