Built on openSUSE testing channel live (early-adopters/developers only)

Announcements
1

As per more recent changes to our Update Channels docs and following our ongoing developer doc:

We now have very early testing channel rpms available for openSUSE Leap15.1 / Leap15.2, and Tumbleweed (but only if you have the required python2 libs grandfathered in). All variants are now close to feature parity with our CentOS offering and getting closer all the time. I would like to inviting linux proficient / ideally developer capable forum members to try these rpms out. Another prerequisite is a familiarity with the state of our current Stable Channel updates function on CentOS. The main focus is on the Leap15.1/15.2 variants and Leap15.2 is our intended ‘re-launch’ / Stable channel offering, which is a necessity for Rockstor’s sustainability. Tumbleweed is, for now, just a future indicator, but interesting for extreme case or very new hardware that required completely up to date kernels etc.

Please note that the above “openSUSE dev notes and status” is a controlled document (mostly) and is under continuous development. As from this paragraphs addition we have a new section on AppArmor, please refer to that wiki entry again if you are having difficulties authenticating Rockstor initiated Samba shares.

Please do not expect full function as this is simply not their, and familiarity with both of the above referenced docs is assumed as it is expected that you will be, as the testing channel is defined, contributing fixes while finding them. Or at least giving detailed and informed reports of your findings with hopefully some pointers as to the failure cause. Please do not report issues that you cannot re-produce.

Some but not all known issues are listed in the above wiki entry and in addition:

  • The system drive is known to be non functional with regard to Rockstor created shares (they vanish after a few seconds). So any system used to test these rpms must have at least one dedicated data drive. Fixed in [3.9.2-58 after reboot)
  • The Web-UI ‘System Shell’ is non functional. Fixed in 3.9.2-55

It is expected that as from 3.9.2-51 these rpms should be able to update themselves when new versions become available so the hope is that we can iterate, as before, within the testing channel, with the aim of initially reaching a CentOS feature parity, or near enough, where upon we can then establish our first openSUSE compatible Stable Channel release.

Initial requirements prior to testing rpm install.

The following points all have additional details in the above dev notes wiki reference.
Please also read that thread up until but not including “Packages for Building Rockstor from source” as we are testing the rpm install in this instance and not building from source.

  • Apply all pending updates to the base openSUSE server install. (Note: ‘up’ for the Leaps and ‘dup’ for Tumbleweed; " --no-recommends" for all to keep the install small.
  • Establish and enable Network Manager and stop and disable wicked.
  • Disable IPv6 via grub config.
  • Add OBS ‘shells’ repo appropriate to you base distro.
  • Disable AppArmor.

Fresh reboot to enact the above system wide updates/changes.

Import Rockstor’s public key

Our rpms and repositories are now signed.
As the root user:

rpm --import https://raw.githubusercontent.com/rockstor/rockstor-core/master/conf/ROCKSTOR-GPG-KEY

Add the relevant rockstor testing channel repository.

Note that the repo name is important here so copy exactly.

Leap15.1

x86_64:

zypper addrepo -f http://updates.rockstor.com:8999/rockstor-testing/leap/15.1/ Rockstor-Testing

AArch64:

zypper addrepo -f http://updates.rockstor.com:8999/rockstor-testing/leap/15.1_aarch64/ Rockstor-Testing

Leap15.2:

x86_64

zypper addrepo -f http://updates.rockstor.com:8999/rockstor-testing/leap/15.2/ Rockstor-Testing

AArch64:

zypper addrepo -f http://updates.rockstor.com:8999/rockstor-testing/leap/15.2_aarch64/ Rockstor-Testing

Tumbleweed (grandfathered python2 libs only)

x86_64

zypper addrepo -f http://updates.rockstor.com:8999/rockstor-testing/tumbleweed/ Rockstor-Testing

Refresh zypper:

zypper refresh

Install Rockstor testing rpm

zypper in --no-recommends rockstor

Start the relevant rockstor related systemd services:

This is the ‘top’ service and in turn depends on rockstor-pre and rockstor-bootstrap so starting this one service will initiate the start of those other services.

systemctl start rockstor

Every effort is made to updated all repos in sync, but Leap ones are favoured, and we try to carry the same version of Rockstor’s code in all of them, assuming they are all able to build at the time of that code release/tag.

Again please note that these rpms are not nearly ready for production, but with skilled community feedback we can get them that way.

If you are particularly interested in this effort but are struggling with this install method, or need to ask more on how to do this, then please wait until our Alpha openSUSE based installer is released. It may not be all that long :slight_smile:

Thanks to all those how have helped to get us this far. I’m chuffed to at least get here and special thanks to our forum moderator come major contributor @Flox who has done a tone of Rockstor on Leap15.1 / Leap15.2 / Tumbleweed testing and developing.

Again please only try these rpms if you are very familiar with linux and current Rockstor Stable Channel updates and have familiarised yourself with the above referenced docs. There is of course every intention of making these openSUSE compatible offerings our main stay, where upon they will be fit for purpose as best we can make them. But for the time being these are early developer releases that need a lot of work. But are nevertheless, within some areas, surprisingly functional.

Hope you enjoy the testing and remember that we are still supporting our current CentOS subscribers so please be patient.

3 Likes
2

I just installed a fresh suse leap 15.1 and tried
zypper addrepo -f http://updates.rockstor.com:8999/rockstor-testing/leap/15.1/
but the response was

If only one argument is used, it must be a URI pointing to a .repo file.
addrepo (ar) [OPTIONS] <URI> <ALIAS>
addrepo (ar) [OPTIONS] <FILE.repo>

adding rockstor as last parameter fixed the problem though.

2 Likes
3

@Marenz Thanks for the head up on my forgetting the repo name.

I’ve now updated the original post and I think it’s important to use the name given there, ie:

Rockstor-Testing

This should allow the resulting rpm install to then manage that repo via the Web-UI and, when it becomes available, be able to supplant it with the Stable repo, and visa-versa. Otherwise the testing repo you have put in under the name “rockstor” will be co-resident and nullify the Web-UI’s capability to mange these repos for folks.

This was a silly mistake on my part and I think I remember thinking I should go check on the exact name before posting and then getting distracted and ending up putting in no name at all!

So for testing it is important that these repo names be exactly “Rockstor-Testing” and nothing else. So for those who have already put in repos named otherwise I’d recommend deleting these and adding again as per my now @Marenz prompted correction in the original post.

Thanks again for the heads up and apologies for slipping up on this rather important config element.

And Thanks for helping to test the ‘Alpha’ testing releases.

2 Likes
4

I’ve just released, slightly behind our Leap15.1 and to-be deprecated CentOS 3.9.2-52 rpms, our Tumbleweed equivalent. It was a little delayed as there was a build issue that only held up the Tumbleweed build and I didn’t want to delay the others for this.

This has now been fixed and merged into master and I’ve released a new Tumbleweed rpm only as this is the only change and it only really affected Tumbleweed, I’ve versioned the Tumbleweed rpm accordingly:

2113-changelog
2113-changelog780×410 44.8 KB

given it’s identical to the other 3.9.2-52 rpms but for the build fix.

Hopefully from here on in we can return to simultaneous releases, which is the intention during the transition over to our “Built on openSUSE” offering and until we reach feature parity or near enough.

And post Web-UI initiated rockstor package update we have, on this fully updated Tumblweed:

28-jan-2020-TW-install-top-right

Our main focus in on Leap15.1 but Tumbleweed is serving well as an early warning system for; package changes, btrfs command output format changes, and the like.

Lets hope this encourages more alpha testers to jump in.

1 Like
5

Thanks to @def_monk and @Flox for finding another requirement relevant to trialling our current “Built on openSUSE” rpms out.

I’ve updated the canonical “openSUSE dev notes and status” technical wiki entry accordingly and further emphasised that doc’s changing nature in this threads original post. In short the addition, a hard won finding, is as follows:

systemctl stop apparmor
systemctl disable apparmor

for Rockstor initiated samba shares to be accessible. Please read the dev notes for our prior status re SELinux and our plans/hopes re apparmor.

Hope that helps our early adopters of the testing channel re-launch to get just a little bit further.

2 Likes
6

The only thing I have struggled with so far after a clean install of Tumbleweed and Rockstor today is that the default systemd smb.service file in Tumbleweed is broken.

Trying to start Samba with systemctl start smb.service I was getting:

Feb 11 00:30:41 rockstor systemd[1]: Starting Samba SMB Daemon…
Feb 11 00:30:41 rockstor smbd[5602]: [2020/02/11 00:30:41.674112, 0] …/…/lib/util/become_daemon.c:135(daemon_ready)
Feb 11 00:30:41 rockstor smbd[5602]: daemon_ready: daemon ‘smbd’ finished starting up and ready to serve connections
Feb 11 00:30:41 rockstor systemd[1]: smb.service: Failed with result ‘protocol’.
Feb 11 00:30:41 rockstor systemd[1]: Failed to start Samba SMB Daemon.

The smb service logs indicated no problem:

[2020/02/11 00:30:41.657055, 0] …/…/source3/smbd/server.c:1775(main)
smbd version 4.11.5-git.114.5685848b8fcSUSE-oS15.5-x86_64 started.
Copyright Andrew Tridgell and the Samba Team 1992-2019
[2020/02/11 00:30:41.674112, 0] …/…/lib/util/become_daemon.c:135(daemon_ready)
daemon_ready: daemon ‘smbd’ finished starting up and ready to serve connections

After much wailing and gnashing of teeth it turns out the fix is to update a line in the following file

/etc/systemd/system/smb.service

Change the line:

ExecStart=/usr/sbin/smbd $SMBDOPTIONS

To:

ExecStart=/usr/sbin/smbd --foreground --no-process-group $SMBDOPTIONS

Then run:
systemctl daemon-reload
systemctl status smb.service

And all (so far) is right with the world.

This is from https://git.samba.org/?p=samba.git;a=commitdiff;h=8b6f58194da7e849cdb9d20712dff49b17a93a77
which was posted in 2017

3 Likes
7

@gaspode Hello again.

It’s actually rockstor’s ‘default’ smb.conf file that is broken, the default in Leap15.1 (our main focus) and presumably Tumbleweed already has this line in place. We are planning to do things differently here than we have done to date and have already implemented our newer system to get docker working in the two openSUSE targets. If you take a look at @Flox recently opened issue you will see what is planned. This looks very much like it will sort the problem you encountered.

https://github.com/rockstor/rockstor-core/issues/2127

Well done on finding the fix but the fault is all ours as we overwrite the smb.conf with a now old, and fine for CentOS template. We are moving to sourcing the package default found and edit it to create our initial template, such as we now do for docker (in our openSUSE variants only).

Thanks for sharing your work around, and until we get this recent issue’s pull request prepared and merged your advise is relevant. Do take a look at the issue though as @Flox indicates the where and what of the upstream distro’s default samba which for those having difficulties is an important reference untill we get out ‘old ways’ template system updated. @def_monk and @Flox have just been battling with samba so more input on this is very timely. Thanks again.

Do also take a look at the btrfs backport comparisons between Leap15.1 and Tumbleweed in the following post as Leap 15.1 is kept surprisingly up to date on these:

Thanks again for sharing your findings and do keep the reports coming. Much appreciated.

2 Likes
8

Thanks a lot for sharing your findings, @gaspode.

@phillxnet already explained everything but your timing couldn’t have been better as I was installing a fresh Tumbleweed just to double-check its smb.service default configuration just as you were writing your post.
I could thus verify that the Tumbleweed defaults are the same as Leap 15.1 ones (for smb.service), so that should simplify (and thus speed up) our work on this. I’m hoping to be able to start working on this in the coming days so we might have that resolved in the very near future as that is a priority (for me, at least) at the moment.

Thanks a lot for your report and confirming that is the right way to approach this… that makes everything a lot more motivating and always give a smile :slight_smile: .

Thanks again.

2 Likes
9

Ahh, well good to know OpenSUSE aren’t that far behind in squashing bugs and are fully committed to creating new ones :smile:

I was running a 5.1 series kernel (I have a recent Ryzen system) on the old CentOS install, and was in the process on upgrading to a 5.5 kernel when I had a late night brain fart and managed to uninstall Rockstor.

So as I’d have to reinstall it anyway I thought I may as well migrate to the new SUSE codebase.

If Tumbleweed lets me down I’ll swicth to LEAP. but it’s working now so…

2 Likes
10

Running Leap 5.1 on the beta channel, here.
I don’t have a problem starting the samba service and creating shares, but I absolutely can’t access my shares from my windows machine, no matter what password/user combination I try (even though guest access should also work, too).
I do see the shares listed though.
The journalctl -f command also didn’t yield any output at all upon failed login attempts…

Maybe I am just too early and it isn’t expected yet to work? In any case, let me know if I can help debugging this in any way.

11

@Marenz Hello again.

Did you do the following from an earlier post:

Hope that helps, and thank for the offer of assistance. We are due for another release very soon so will note that here when it’s published. It contains a improvement to our Samba config on openSUSE by @Flox.

1 Like
12

Ah, no I did not. I just assumed the last update addressed this. Will try when I get home.

13

I am now running 3.9.2-54. Before the update, I stopped and disabled apparmor now, recreated my shares, restarted the smb service, restarted the whole server, but I still can’t browse my share, always authentication failure (even though guest access should work, too).

14

To the ‘Built on openSUSE’ early-adopters/developers:

Just a quick note that we have a new requirement re disabling IPv6 via grub. All details in the canonical wiki under a new section entitled:

Disable IPv6 at the kernel level

Thanks to @tyukh for diligently chasing this one down. Referencing their GitHub issue for context:

1 Like
15

Hi @Marenz,

I would like to first apologize for letting your message unanswered for several days… I wanted to get back with you earlier than that, but my current schedule is a lot busier than usual and leaves me with very little time to spend here.

Maybe a dedicated forum thread would be more appropriate to your issue, and we would then report here any fix or resolution that may come out of it. This way we could keep this “Announcement” thread as focused as possible.

To your issue now, I unfortunately am not aware of a single way to troubleshoot samba that would tell us everything, as so many factors are at play. I would thus start with the most obvious things (that you most likely already tried), but I’d rather make sure of these elements first before diving into something more complex than we should have been.

First, you have already done so, but I would make sure we start from a clean plate by deleting all your samba exports, and turning off your Samba service. Then, make sure apparmor is indeed turned OFF with systemctl status apparmor.

Second, click on the configure Samba service in the webUI, and make sure to fill in your WORKGROUP. Do you also use to use custom global options or did you use to let it blank?

Third, click submit to save the configuration file. You can also verify that all was written correctly by looking at the file: cat /etc/samba/smb.conf.

Fourth, toggle the Samba service ON. When troubleshooting like that, I usually like to have a terminal session open at the same time and monitor the logs with journalctl -f so that I can see what is happening. You should see mentions that smb and nmb are turning ON, and then a message from nmb telling you that this computer is now the master of your workgroup after a few seconds (that one can take a minute to appear sometimes).

Fifth, export one share with the settings you’d like, and make sure the settings were correctly applied to /etc/samba/smb.conf. If you are still monitoring the system logs, you should see that the Samba service is restarted to refresh its configuration (which means the same messages as in step 4 above should appear).

Sixth, regarding your client, you mentioned windows, but can you tell us which version by any chance? Also, you said you were able to see your share exported correctly, but were having an issue trying to connect to it: could you get more information? Are you using the WORKGROUP\user format for the username? Would you be lucky enough to have an explicit error message? I know Windows is terrible at giving useful information in its error messages, unfortunately, so we usually only get a useless “Acces denied”…

The best way to see what is happening is to monitor the samba logs themselves: /var/log/samba/*.log if my memory is correct. You will see several ones and all will have different information. You could try to monitor all of them at once while trying to (1) see the share from your Windows client and (2) after entering your credentials and actually trying to access it, but we will probably be drowned in information. Best chance at first would be to monitor the following ones at first:

  • smb.log
  • the one having your client’s IP in its name
  • the one having your client’s hostname in its name

You will see a lot of information, and warning messages as well, but hopefully these would prove helpful. There’s a lot more troubleshooting that can be done as well, but let’s start with that at first, at least.

Hope this helps,

2 Likes
16

Additional repo required

We now have 3.9.2-55 “Built on openSUSE” testing rpm out but note that, to address one of the few remaining feature parity issues, we needed to add an additional repo to cover the shellinabox package dependency. Details are in the usual place:

Add ‘shells’ OBS repo

Web-UI updates will most likely fail until you have done this extra step.

Cheers.

2 Likes
17

Hello, seems like some great progress is being made. I’m curious if there is an “upgrade” path for those on the CentOS version, if we want to migrate over.

Is it as “simple” as taking a backup of the config on CentOS (and saving that off). Then installing a new USB stick with the OpenSUSE build, and then restoring the config I backed up? I’m assuming my btrfs pools will be detected, but will things like Shares, NFS mounts, SMB mounts, etc all also be detected?

18

@kupan787 Hello again.

Currently the Built on openSUSE Stable channel is un-populate but that’s only a matter of time hopefully. And out release target disto is likely to be Leap15.2 but re:

Pretty much yes. But note that you should only use high performance USB sticks, if you have to use this medium for the system disk, and ideally a real hdd,ssd is always preferred. And it’s best to import your pool once all of the above ‘early-adopter’ config and prep is done, and only then restore your configuration. The two operations are separate. That way the config restore has existing imported shares etc to map the config restore elements to. As to what is backed up and restored that is as per our following doc section:

Configuration Backup and Restore: http://rockstor.com/docs/config_backup/config_backup.html

With the caveat that we have now dropped AFP.

In time we should be ready to release our ‘Built on openSUSE’ installer but that will likely no be until after Leap15.2 is out anyway, so currently one has to just do a server install of Leap and config as per in the original post in this thread and it’s linked wiki entry here on the forum. But I’m hoping to release the kiwi build config for it much sooner. All a work in progress though and we have working prototypes for 15.1/2 and Tumbleweed.

We’ve only recently added server status restore to config save/restore and there has been a report by @shocker of some initial sync issues. The thread is labelled openSUSE but I’m pretty sure it’s actually generic:

So hopefully we can look to that soon as it seems to affect, from that report, a number of the services.

So look out for that. Also note the dev wiki link for known outstanding openSUSE variant related issues like no share on the system drive. But we are definitely getting there.

Do take a fresh look at this threads original post as I’ve recently edited it to make it clearer and hopefully easier to follow. It’s still early adopters but if you are comfortable with a little command line and happy to chip in with informed reports then great. I’d go for Leap15.2beta given it’s only a week or so from package freeze and has a much newer kernel base. All openSUSE variants get aggressive btrfs backport but it’s still nice to have newer kernel base.

As you have no doubt seen there are now a few active and technically knowledgeable/capable forum members who have taken the plunge and more of the same can only help. But the original message of this thread still stands. That we are more after solutions to reported problems, or at least strong pointer, than simple reports of their existence. But is can only help to have more folks involved. See how you feel, but if you are after a tailored installer and are not familiar with cli/systemd etc then it’s not quite ready yet.

Bit of a chicken and egg really but given few have as yet tried it to my knowledge you may well have surprises but if you can drill into these yourself a bit and are prepared to chip in then super; go for it. If nothing else you data may in fact be better maintained on the newer Leap15.1/2 base than it is currently in our CentOS offering. But ideally we await the Leap 15.2 release proper. And if you are in two minds then I would suggest waiting for the 15.2 release first. I believe it’s due out proper beginning of July. And if that’s just too long then jump on the Leap15.1 testing.

On a related note re newer kernels I’ve still not gotten around to addressing what you brought up here:

So if you did fancy picking that back up then great: pull requests welcome. Especially given the kernel versions now in Leap15.2beta (5.3.18-lp-152.10-default) and Tumbleweed (5.6.2-1-default) as of a few days ago. But remember that if doing a source install then do it in a separate dir i.e. “/opt/rockstor-dev” not the default rpm one. That way you can more easily jump back to an rpm install with the caveat that it will always be like a fresh install to go between them, i.e. config save, import pool, restore method again as the db is necessarily wiped during this source/rpm (and reverse) process.

Hope that helps.

1 Like
19

@kupan787, @phillxnet,

I just tested that quickly, but noticed that the current Leap15.2 beta is still using Btrfs-progs 4.19.1 (with kernel 5.3.18) so the btrfs scrub satus output format is still OK for us. Only tumbleweed should have this problem. I know it’s only a matter of time, though, so it looks like we still need to account for the btrfs-progs version when applying this fix.
For instance, I have:

rockdev:~ # btrfs --version
btrfs-progs v4.19.1 
rockdev:~ # uname -a
Linux rockdev 5.3.18-lp152.11-default #1 SMP Wed Apr 15 12:02:19 UTC 2020 (71e1af4) x86_64 x86_64 x86_64 GNU/Linux

…which gives me:

rockdev:~ # btrfs scrub status -R /mnt2/test_pool
scrub status for 18ed12fc-fa61-4076-b522-3e37f4e6e9d7
        scrub started at Wed Apr 29 08:14:05 2020 and finished after 00:00:00
        data_extents_scrubbed: 1
        tree_extents_scrubbed: 18
        data_bytes_scrubbed: 65536
        tree_bytes_scrubbed: 294912
        read_errors: 0
        csum_errors: 0
        verify_errors: 0
        no_csum: 16
        csum_discards: 0
        super_errors: 0
        malloc_errors: 0
        uncorrectable_errors: 0
        unverified_errors: 0
        corrected_errors: 0
        last_physical: 1179648000

…that itself is picked up nicely by the webUI:

image
image715×650 28.3 KB

I don’t know whether or not Leap 15.2 will ship with newer btrgs-progs version, however.

1 Like
20

So I am still on CentOS, but I’ve been upgrading my kernel and btrfs progs:

[root@rocknas ~]# btrfs --version
btrfs-progs v5.6
[root@rocknas ~]# uname -a
Linux rocknas 5.6.7-1.el7.elrepo.x86_64 #1 SMP Wed Apr 22 18:05:11 EDT 2020 x86_64 x86_64 x86_64 GNU/Linux

And here is what btrfs scrub looks like:

[root@rocknas ~]# btrfs scrub status -R /mnt2/MainPool
UUID:             23cad14d-6fec-4482-997c-d62021de832a
Scrub started:    Wed Apr 15 00:05:04 2020
Status:           finished
Duration:         10:49:34
	data_extents_scrubbed: 660905136
	tree_extents_scrubbed: 2753807
	data_bytes_scrubbed: 43241772498944
	tree_bytes_scrubbed: 45118373888
	read_errors: 0
	csum_errors: 0
	verify_errors: 0
	no_csum: 491699192
	csum_discards: 0
	super_errors: 0
	malloc_errors: 0
	uncorrectable_errors: 0
	unverified_errors: 0
	corrected_errors: 0
	last_physical: 5688272945152

And without the -R:

[root@rocknas ~]# btrfs scrub status /mnt2/MainPool
UUID:             23cad14d-6fec-4482-997c-d62021de832a
Scrub started:    Wed Apr 15 00:05:04 2020
Status:           finished
Duration:         10:49:34
Total to scrub:   40.03TiB
Rate:             1.03GiB/s
Error summary:    no errors found

A while back I tried to do some work to identify the btrfs progs version, and update the output. It is a little “hack-y”, so if I get some time, I’ll try and clean it up and submit a pull request. But I also made a few changes to my UI, to incorporate some of the fields that I think are new (not sure if they are in the old version of not):

image
image1988×942 131 KB

Here I added a SCRUB rate column. I also made the End Time display the ETA while a scrub is in progress.

image
image1092×764 52.4 KB

Here I added the ETA column and the Scrub Rate column.

These changes were obviously for myself per my preference, so might not fit into the overall direction of Rockstor.

However, the fixes to parse the SCRUB output will be needed once you get to a more modern btrfs-progs. I’m surprised that tumbleweed would have a newer kernel, but still be using the older btrfs-progs.

2 Likes