Can rockstor-core NAS be used on debian?
This is for personal usage for my family. And Debian is what I use.
Probably in the FAQ Frequency Asked Questions
I missed it.
@tdwebste Welcome to the Rockstor community forum
No, and this is intentional: but!
The main (but still resolvable) issue here is that Debian is deb based, We use both zypper (openSUSE native) and Yum (actually dnf-yum). This is a complicated problem to resolve as in our history we were CentOS based and so we have mechanisms in play still that look, via the distro python library, to identify what we run on. We then have o discern between versions of yum/dnf-yum and also use zypper in parallel. The former to extract changelog from uninstalled rockstor package versions available (zypper can’t do this yet) and the latter (zypper) to do the actual package install and management.
The main issue here, as I see it, is that we are not a package as much as a customized distro - hence our installer. So there are many assumptions, through-out the code, about the system we run on. But on the other had there are code forks (not git) that did (these will be removed soon) on thing on CentOS, and another on openSUSE Leap, and yet another on openSUSE Tumbleweed. We also have similar life dicisions made according to the architecture we find we are running on - x86_64 vs aarch64.
So in short we very much want to reduce this broad target rather than extend it. Any code contributions towards extending these targets will likely be rejected as we have more than enough mess as a result of our last ‘broadening’ that we can currently deal with anyway. So this all comes down to complexity. We are not so much an app running on generic linux - but an appliance (in a single package mainly) that configures the large parts of the OS that it runs on. Hence the requirement to know about what we are targeting. In theory this is entirely doable - but not with our current team size. And as indicted the breadth of the code would be more than would be manageable.
However I think this is backwards in a sense. What you need, linux knowledge wise, is likely already sufficient from your debian experience as you interactions with the system will likely be less ‘intricate’ than what Rockstor will be doing for your (the Appliance part). If they were not then we wouldn’t be an Appliance but a hinderance and you would not be the intended audience - or we would not yet have achieved the stated goal of easy to use. In other words - assuming basic linux familiarity - our openSUSE base will likely be way familiar enough to you for it not to be at all daunting. Certainly far less so than having to port yet again to yet another linux OS. Linux distros share more than the don’t and as we progess in our own sofistication we will likely be able to support other distros more easily - but that does not make it trivia/easy. It will still be a montain of our own making - easily avoided by focus - which we have.
So succinctly, you are already familiar enough with openSUSE certainly more so than the intricacy required to machine alter configurations that we current do based on assumptions that would, necessarily be, more detailed: else you would be building your own NAS by hand.
Aside from my above comment, it isn’t really. In time we will transition to less (by-machine-hand) config management to employing higher level managers. This will empower us to be more hands-off on the system config front - and thus be more adaptable to our base OS. But we arn’t there yet.
Once upon a time, in a half remember dream - way back in our history - our founder had a ‘mockup’ of Rockstor that ran I think on debian. But we hare very much larger and more complicate (and more capable) now. And it wasn’t a completely functional ‘port’ at all. So again we would need to farm out our config changes to a specialised manager subsystem to be able to approach this. And to prove function/capability we would have to have our ‘in progress behind-the-scenes’ OpenQA setup fully working and well into development before we could even start to embark on such a thing. But this is all planned but we have bigger battles to attent to first - such as moving to a modern Python.
Not really, but we do say our base OS. And as stated we did originate in CentOS: and it is noteworthy that we found a number of bugs moving to openSUSE - via the rigour required to do that move.
However all of the above taken into accound - our openSUSE base is a happy one for us. We have, natively, such things as our installer builder kiwi-ng and again natively the planned OpenQA. There are all fantastic projects that do benefit othe distros but are native to openSUSE.
And underlying all of the above is why we chose openSUSE as our host. They are super keen (and actively backport) btrfs stuff - sort of key to our key purpose.
I say give our install a go on a dedicated machine. We are not just a package but an appliance configured via that package. As such a Rockstor install is considered to be a dedicated system. We cannot account for other configurations outside of or remit - other systems can more expertly cater to other needs. But we do have a docker based plug system.
Hope that helps.
I hesitate to create an openSUSE appliance not because of lack of familiarity with openSUSE, but because I can’t move/run system scripts across local and remote computers.
I already run ROS and nvidia cuda tensorflow / pytorch dockers on the desktop server. This is single will be converted into a dual server. That will local sync backup drives. The desktop server already runs dockers and VMs adding another is a simple matter.
In this setup I don’t backup the OS, I only snapshot it for fast recovery. I only backup data and the OS deployment scripts.
Can you point me to the Rockstor docker. I would love to try Rockstor.
You have been very helpful.
@tdwebste the docker based plug system that @phillxnet is mentioning refers to the Rock-ons that you can use with Rockstor to extend functionality/usage, like a Plex/Emby/jellyfin server, OpenVPN server, etc. not really the Rockstor appliance as a docker container itself.
The only alternative at this time is using a VM (logical, considering @phillxnet’s explanation above). the instructions for that can be found here, though you will already know 90% of the required setup since you indicated you’re using VMs in other scenarios on your setup already: