Greetings.
Btrfs looks amazing, and I quite like many of the ideas behind Rockstor.
It looks good. It looks very good.
However: I kind of prefer a different Linux distribution. I took a look, and it didn’t seem hard to bring the code over to some other infrastructure - arch-like or otherwise.
Would love to hear your thoughts about that.
Hi @Argo,
Rockstor is already in the midst of being rebased to OpenSUSE.
What you see as a trivial task is actually quite a large task, as Rockstor relies various parts of the underlying OS, which can differ between linux distributions, such as:
I personally would love to see Rockstor for Debian, but every distro that they attempt to support, some fairly monumental changes need to be made.
However, if you’re so inclined, I encourage you to pull down the freely available source and make these changes in your own fork.
If you make them in a way that retains backwards compatability with the CentOS and future OpenSUSE distributions, submit a pull request to have your changes brought into the release version.
Thank you @Haioken. I’d argue that some of these parts are not as movable as they used to be.
Example: systemd, which is pretty universal nowadays.
Perhaps then it would be well-received if Rockstor was delivered in two different flavors.
Neatly bundled as an iso, or “installable”. As a platform.
The underlying languages, after all, are all portable.
I don’t know why people keep arguing this idea.
The short answer is this isn’t how it was conceived, and tearing out the parts that are OS specific leaves you with very little of Rockstor - you’d basically be looking at a Web UID wrapper for BTRFS and Docker.
Regardless, Rockstor is provided as source, it can be installed on any Linux flavour you like, It just won’t work the way you expect it to.
This is because some of the underlying requirements are different per OS, as I began outlining above.
Yes, systemd is pretty ubiquitous these days, and can be used via sysv commands with the Systemd sysv extensions, however this is one of many things that differ between distributions.
However, it should be noted that there is some drift amongst systemd unit names across different distributions.
Try restarting Apache or Samba in both Debian and CentOS.
My stated differences in my previous response are not a comprehensive list, there are many other differences between distributions
Rockstor would need to be altered at minimum to understand how Arch maintains packages. At the moment it is built under the premise that the underlying OS uses ‘yum’ for package management. This is being extended to allow for zypper, but honestly, how many package management systems must the devs be responsible for here?
Lets assume the devs acquiesce to building for Arch.
While they’re at it, they can also build for my preferred OS - Debian. You know, because time isn’t finite.
I’m sure somebody will want Rockstor built for for Alpine, Gentoo, Slack, some BSD variants.
Now the developers need to maintain routines for package installation via:
Now, lets say this is done the way I’d do it, by storing the package maangement commands in a database keyed to the distro name, meaning you can easily add and alter them (better portability).
You still need to account for package name drift amongst different distributions (CentOS - httpd vs Debian Apache2).
Beyond that, different distros have different ways of managing configurations for third party services.
CentOS avoids altering any configs modified by user. Some distros allow for elements of the config to remain untouched in comment tagged areas.
Debian instead opts for providing <config>.d directories defined as wildcard includes in the service config directory.
These things all need to be accounted for for the OS in question.
I’ve mentioned this on other threads in the past, but remember that Rockstor is not supposed to be an application, it’s an appliance.
This is the same logic behind why FreeNAS is FreeBSD based and not installable on Arch, Debian, CentOS, OpenBSD, etc (ostensibly, most BSD things are cross compilable with Linux).
Also the same logic that OpenMediaVault is based on Debian, and not installable on other distributions.
It’s also worth noting that Arch isn’t exactly
If you want Arch support, it’s probably something that you’ll need to bring to the table yourself.
I’m not saying that the Devs won’t choose to support Arch in the future, I’m saying they shouldn’t.
Not because there’s anything wrong with Arch. They also shouldn’t choose to support Debian in the future.
The reason for this is simple - Rockstor is to be installed as an OS, and run as an Appliance. It’s not supposed to be installed onto an OS and run as an application.
Also worth noting is that Arch hasn’t even been in the top 10 distros on Distrowatch any time recently, and has been declining.
Ostensibly, this means that users are less likely to be familiar with it and less likely have the inclination to learn it.
Personally speaking, had Rockstor been provided as OpenSUSE (Or Arch!) when I initially looked into it, I probably would have avoided it (Sorry Rockstor dudes!), purely because I’m familiar with BSD, Debian and CentOS already, figuring out the nuances of another OS and a new NAS framework at the same time would have been too much of a hassle.
I don’t know why people keep arguing this idea.
Probably because, like with FreeNAS, there is a sense that being locked into an appliance, especially for tinkerers - which Linux or BSD persons are - risks to somehow be limiting in the long term.
Example: I expect the casual glitch when backing up my photos through Plex, and I expect that to lead me to duplicates. And I also expect to have to regularly run a tool to deal with those duplicates.
This is not something I want to integrate into my workflow. This is something of a rescue or maintenance task.
Hence, I am planning to keep a multiboot on my NAS by way of a secondary boot drive. That’s a whole paradox right there.
I am grateful for a system which enables me to customize some things about file or media storage. But if it started that way it might as well go all the way.
I don’t see much of anything wrong with having an application for the purpose.
Rockstor doesn’t have a very large development team. There’s very few of the developers that are actually active in developing Rockstor.
I’m sure the Rockstor team would love to make Rockstor as Linux distribution agnostic as possible. However, that’s currently not possible. There would need to be a huge influx in developers as well as funding for that to be possible.
From my understanding, Rockstor started out with the intent of being an appliance without being tied to specific hardware. Heck, the first I’d heard of Rockstor was at an InfoSec conference about 5 years ago and 45Drives was demoing one of their appliances powered by Rockstor. The 45Drives guys had chosen Rockstor as one of their options because it allowed them to not have to stick to specific hardware and be able to quickly push out new appliances.
@vesper1978 hit the nail on the head here. The choices realistically are:
Beyond that, given your only example in the statement:
I don’t see how being distro agnostic resolves this. This is an issue within the Plex application, running in a container. The problem will be present no matter which distro you start the container on.
Also, I have had this issue, I rolled back my plex container’s data share to a previous snapshot and did the sync again - no issues.
No paradox here, feel free to have a secondary boot drive. You can still have the btrfs-tools goodies for R&R, you’ll only lose the pretty interface - which is not particularly useful for R&R anyway.
It’s funny, but Rockstor actually removes a lot of configuration options. tiered subvolumes, path configuration, etc are all locked down from the UI, and many features will cause issues in the UI if you try to do them yourself.
Likewise, except the development lead time.