So I encountered some bad system disk issues after a couple hard reboots, and so decided to take the plunge into OpenSUSE land, and found that the system disk itself was the culprit (went read-only and had many parent transid / csum missing errors and such), so I figured I’d automate the post-install with an Ansible playbook, in case I needed to do it again.
I’m running Leap 15.2, so I haven’t tested on 15.1 or Tumbleweed (Avoided Tumbleweed because of Python3 issues which will get worked out later), but it should work well for Leap 15.1 systems as well.
Pro tip: During the user creation process, when you select “Skip User Creation” and set the root user password, you can load in an SSH key if you have another drive mounted with it, which makes running the playbook that much easier. I ended up logging in and ssh-copy-id ing myself, but a good note for the future.
Use at least a 20 GB system disk, this auto enables boot to snapshot functionality.
Server (non transactional)
Default partitioning
Skip user creation (then only root password to enter and leaves all additional users as Rockstor managed)
Optional, load ssh key from thumb drive for root user access via ansible
Click “Software” heading, then uncheck “AppArmor”, then click Next or Apply (I forget which it is specifically)
Disable Firewall
Leave SSH service enabled
Switch to NetworkManager
After the install and initial reboot, make sure you can log in using the previously created SSH Key, or create one now and load it via ssh-copy-id
Create an inventory file for ansible, something like the following in hosts.yml:
all:
hosts:
rockstor:
ansible_ssh_host: 192.168.88.100 # Use your server's IP here
ansible_user: root
Run the ansible playbook: ansible-playbook -i hosts.yml --private-key=~/.ssh/rockstor_ed25519.key main.yml
Enjoy your OpenSUSE-based Rockstor!
It works well enough, but it’s all one file, so it could use some improvements in the organizational department I’m sure, but wanted to share it and see if others thought it useful as well.
I would rather like to incorporate your excellent work here into the rockstor-core repo. And given attribution is super important in open source development I would like to ask that you present this playbook file (I like it being in a single file by the way) as a pull request on the rockstor-core GitHub repo:
Maybe in it’s own ansible directory within our existing top level conf directory. That way we can similarly have a salt alternative (given this is the direction openSUSE is going in) similarly in a salt directory along side this. I’ve personally been intending to do the salt one for a while now but ‘stuff on’ and all that.
But I have a couple of request on this however:
Could you remark out the btrfs-progs update. The reason being is simple: newest is not always best and that repo is, I’m assuming, a convenience for getting the newest. This is akin to our prior use of the elrepo-ml kernel repo, although in that case it was a necessity all those years ago. In short, the latest btrfs-progs is not curated by our upstream distro. And the entire openSUSE move is an attempt to move our base technologies, as much as we can, to a curated (read enterprise linux supported) source. Remarking that section out leave it ready for those wishing to experiment (on purpose) rather than by default . Plus there are serios reasons why they are not carrying the very latest btrfs-progs, such as infinite looks on balance and the like. So, in my opinion, I think we should stick to curated rather than bleading edge core technologies such as our file system drives/tools, and the defaults represent this in our upstream for our ‘Built on openSUSE’ endeavour, plus we stick closer to the actual openSUSE distro rather than deviate too far from it, which is not in our interests I believe.
Given you are tending to the grub ipv6 disable bit, and instigating a reboot, is not the “Disable IPv6 in sysctl” redundant. Plus it adds one more set of configurations to be ‘undone’ upon our own systems dealing more elegantly (read functionally) with IPv6, i.e. folks will only have to un-do one disablement rather than both. And from @tyukh issue linked below is insufficient on it’s own, where as the kernel option appears to be.
We are ‘in the throws’ of asserting architecture awareness within the Rockstor code and as part of this we have recently added an architecture specific repo url that is yet to be established on the backend (more on this very soon hopefully). It’s a bit of a chicken and egg one so had to start somewhere. I’ll link to the more resent/relevant pull request below.
Point 3 related pull requests, with the last being most relevant here:
So do please consider doing that pull request as we can then more easily discuss and particulars and we can then hopefully also get core contributors such as @Flox involved in the review as well. Didn’t expect this coming along so soon. But pretty good timing actually. Know an Salt by chance ? . So lets try and get this one incorporated as it would then be easier in the long run to keep it in sync with such ongoing changes as the above referenced AArch64 rpm repo addition and the like.
Good and timely move I think. Plus we should have an installer soon so that pretty much earmarks the CentOS variant as fully legacy (read obsolete) from that point on. But contributions such as this will definitely help with our aim to maintain compatibility with upstream with just a few ‘tweaks’ (read our legacy approach or technical debt in some areas) and helps to formalise the needed tweaks of course. So hence my enthusiasm towards getting such scripts into the fold as it were.
But I’m afraid I have not working knowledge of Ansible as of yet, aside from what it affords.
Hope that helps towards you popping this in as a pull request (with the suggested tweaks). And you could also include your excellent readme within that suggested directory as that would seem fitting. Then, as rockstor-core develops into requiring less of these ‘tweaks’ we can, in turn, keep these auto config options up to date and thus formalise the requirements as we go.
And pending the merge of this functionality we might consider starting a technical wiki on it’s use as there will always be folks who fancy starting from a vanilla openSUSE variant install anyway. And in there we could purhase cater to the like of me (currently) who knows nothing of Ansible’s initial setup. Oh and just a heads up, our soon-to-be released installer configuration is esentially a lightly modified JeOS variant so that may have some bearing on these types of auto config options.
So thanks again for submitting your work here. Nice.
@StephenBrown2 and @phillxnet, if this ansible could be PR’d I’m happy to help bolting it on to some vagrant to fully automate building an environment.
.