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

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 and Tumbleweed. The latter is particularly experimental and is used by developers as a ‘heads up’ on what’s coming. Neither repositorys offerings are yet at feature parity with our CentOS offering but given they are 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 variant as that is what will become our Stable channel offering, which is a necessity for Rockstor’s sustainability. Tumbleweed is, for now, just a future indicator.

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.
  • The Web-UI ‘System Shell’ is non functional.

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 rpm install.

  • Apply all pending updates to the base openSUSE install.
  • Establish and enable Network manager and stop and disable wicked

For the above 2 items see the linked wiki entry up until but not including “Packages for Building Rockstor from source”.

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 repository.
On a Leap15.1 install:

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

On a Tumbleweed install:

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

and then:

zypper refresh

Both repos will be updated in sync and will carry the same version of Rockstor’s code, assuming both are able to build at the time of that release.

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 / Tumbleweed testing / 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.

4 Likes

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

@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

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

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

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

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

@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.

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

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

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

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.

@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

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

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).

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

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

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