## File-Sharing under Linux, using Usershares – the Modernistic Way.

One concept which readers may already know, is that under Linux, we can set up a Samba-server, which makes the sharing-out of our home directories possible, and that if we fiddle with the ‘smb.conf’ configuration file thoroughly enough, it becomes possible to browse the available shares on a LAN, in a way semi-compatible with Windows computers that also reside on the same LAN.

Traditionally, this has always been a bit of a PITA, especially since the ‘/etc/samba/smb.conf’ configuration files have been finicky, and since each share practically needs to be configured individually, by a person with the ‘root’ password.

Well an alternative exists under Linux as well, which is the concept of ‘Usershares’. With this concept, each user who belongs to a specific group has the privilege, of designating a folder within his desktop manager, to share out, pointing-and-clicking. This is closer in ease-of-use, to how the process works under Windows. But, it needs to be set up correctly once, by the sysadmin, before it will work as often as simple users wish it to work.

I think that an existing Web-article on the subject, already explains well, what the settings in the ‘smb.conf’ file need to be, as well as what directories need to exist, in order for usershares to work. Except that the article I just linked to, refers to Fedora and SELinux systems and their norms. I happen to be based on Debian and KDE 4 or Plasma 5. And so I have a few observations to add:

Firstly, the following packages should be installed, under Debian also:


#apt-get install kdenetwork samba



Secondly, ‘/etc/samba/smb.conf’ needs to be edited like so:

Under Debian, the directory ‘/var/lib/samba/usershares’ already exists, If the relevant packages are installed. And its permission-bits have already been set as they should be set. Only, the feature is not configured in ‘smb.conf’ by default. And, the additional package named ‘kdenetwork-filesharing’ needs to be installed, in order for the tab to appear in Dolphin’s File-Properties box, that enables sharing from the GUI. Aside from that, enabled users need to be added to the ‘sambashare’ group, after which this membership only goes into effect, once the user in question has started a new session…

(Info Corrected 03/25/2018, 17h10,

Updated again 03/28/2018 … )

## Why visual SAMBA Browsing no longer works On My LAN.

One of the routine tasks which I recently carried out on my LAN, was to retire an old computer named ‘Walnut’. A day later I discovered that I could no longer browse my LAN, by way of my SAMBA shares. BTW, all my computers are by now either Debian / Jessie or Debian / Stretch computers. So what gives with the sudden inability to browse my shares via the GUI, which is the ‘Dolphin file browser’?

(Solved as of 03/23/2018 … )

Well in my ‘/etc/samba/smb.conf’ file, I gave the option:


[global]

(...)

smb encrypt = desired



The purpose of this was, for the Samba Server to query the Client, whether the  client supports encryption, and if affirmative, to enforce such encryption.

And, just to be sure that I haven’t made some silly mistake, I can run the following tests:


root@Phoenix:/etc/samba# cat smb.conf | grep "map to guest"
map to guest = Bad User
root@Phoenix:/etc/samba# cat smb.conf | grep "obey pam"
obey pam restrictions = no
root@Phoenix:/etc/samba#



But the disposition of the client to offer encryption, needed to be decided on the client machines, by creating a user-space file, i.e. a file in the home folder, which is named ‘~/.smb/smb.conf’, which contains the following lines:


[global]
client max protocol = SMB3



This is actually required, in order for the Dolphin / GUI-client even to offer the level of security which I wanted, which is SMB3 security. Without my specifying this, Dolphin would indicate to the Server, that SMB3 is not available, and no encryption would take place. This line of code can also be put into ‘/etc/samba/smb.conf’ , but I chose to put it into my home-folder like that.

## How To Install Yafaray Under Linux

One of the computing subtopics I dabble in, is the acquisition of 3D-graphics software. Therefore, I already have “Blender 2.78a”, which has its own built-in software-rendering engine, and I have several other rendering engines installed on my Linux-based computers.

Further, the rendering engines by themselves can be useless, unless they integrate well with a GUI (such as with Blender). And so one undertaking which I’ll typically reach with a given computer, is to install “Yafaray”, which used to be ‘Yafray’, which stood for ‘Yet Another Free Ray-Tracer’. If it’s installed properly, Blender can render its scenes, using Yafaray, but from within Blender.

Yafray used to be a much simpler piece of software to install than it has become. But I’m sure the effort I put into it this evening, will be well-worth it eventually. What I’m used to doing is to download a source-tree, and if it’s CMake-based, to run ‘cmake-gui‘ on it, to custom-pick my build options, and to go. But as it happens with Yafaray, this approach led to near chaos. What this did, was to compile all the source-code properly into libraries, but then to install those libraries to nonsensical locations within my system folders. One reason was the fact that a part of the project was to create Python 3 bindings, and another was the need for the Blender-integration, where modern Blender versions are based on Python 3. In any case I was sure to install all the build dependencies via my package-manager, but doing so was not enough to obtain working outcomes.

## I’ve just custom-compiled ‘Aqsis’.

To give some context to this proclamation, I had written an earlier posting, about adapting the non-packaged software named ‘Ayam‘ to Debian / Stretch, that had worked just fine under Debian / Jessie. This is a GUI which constructs complex ‘Renderman‘-Compliant rendering instructions, in this case in the form of .RIB-Files, which in turn, ‘Aqsis’ can turn into 2D perspective views of 3D scenes, that have been software-rendered. OTOH, Ayam itself uses OpenGL and H/W rendering, for its GUI.

What I had found before, was that Ayam did not seem stable anymore under Debian / Stretch. I apologize for this assessment. Under close scrutiny, my computer has revealed, that it was really Aqsis giving the problems, not Ayam. Aqsis is a text-based tool in effect.

Ayam does not specifically need to be used with Aqsis to do its rendering. It can be set up to use other rendering-engines, most of which are quite expensive. Aqsis just happens to be the best Open-Source rendering-engine, whose language Ayam speaks. And at this point I’d say that Ayam is still quite stable, after all, under Debian / Stretch.

As is often the case with such troubles, I next sought to custom-compile Aqsis, to see whether doing so could get rid of its quirks. What were its quirks?

Finally, the only problem with Aqsis was and remains, that it cannot produce a real-time preview of the scene being edited, which it used to provide using a component-program named ‘piqsl’. And the reason why the packaged version of Aqsis does not have ‘piqsl’ under Debian / Stretch, is because this distribution of Linux has a very new ‘Boost’ library ( v1.62 ) , and the visual component to Aqsis, that could produce a display, still relies on the Qt4 libraries and their API, which have begun to bit-rot. The Qt4-specific code of Aqsis cannot parse the newest usage of the Boost libraries, and Debian maintainers have long since discovered this. They are shunning the use of ‘libqt4-dev’ and of ‘libqt4-opengl-dev’ to build any of their packages. So they were effectively forced to package a version of Aqsis, which was missing some important components.

(Updated 12/12/2017 … )