Here are the main advantages:

Disadvantage: It does not have YAST!

Now I wanted to document some neat tricks and details.

When you have the hex-encoded sha256sum of a small file – for this example let’s use the GPLv3.txt on our media –
sha256sum /ipns/opensuse.zq1.de/tumbleweed/repo/oss/GPLv3.txt
8ceb4b9ee5adedde47b31e975c1d90c73ad27b6b165a1dcd80c7c545eb65b90

Then you can use the hash to address content directly by prefixing it with /ipfs/f01551220 so it becomes

/ipfs/f015512208ceb4b9ee5adedde47b31e975c1d90c73ad27b6b165a1dcd80c7c545eb65b903

In theory this also works with SHA1 and the /ipfs/f01551114 prefix, but then you risk experiencing non-unique content like
/ipfs/f0155111438762cf7f55934b34d179ae6a4c80cadccbb7f0a

And dont even think about using MD5.

For this trick to work, the file needs to be added with ipfs add --raw-leaves and it must be a single chunk – by default 256kB or smaller, but if you do the adding, you can also use larger chunks.

Here is a decoding of the different parts of the prefix:
/ipfs/ is the common path for IPFS-addressed content
f is the multibase prefix for hex-encoded data
01 is for the CID version 1
55 is for raw binary
12 is for sha2-256 (the default hash in IPFS)
20 is for 32 byte = 256 bit length of hash

And finally, you can also access this content via the various IPFS-web-gateways:
https://ipfs.io/ipfs/f015512208ceb4b9ee5adedde47b31e975c1d90c73ad27b6b165a1dcd80c7c545eb65b903

You can also do the same trick with other multibase encodings of the same data – e.g. base2

Base2 looks pretty geeky, but so far I have not found practical applications.

• AutoYaST support for using Btrfs subvolumes as user home directories.
• Improved Certificates management in the registration module.
• Correct detection of DASDs when using virtio-blk.
• Proper handling of the resume option in the bootloader module.
• Display fonts and icons properly during installation.

And, as a bonus, some insights about a YaST font scaling problem on the GNOME desktop (spoiler: not a YaST bug at all).

Adding bcache support to AutoYaST

A few days ago, support for bcache landed in the YaST Partitioner. In a nutshell, bcache is a caching system that allows to improve the performance of any big but slow disk (so-called backing device) by using a faster and smaller disk (caching device).

The way to describe a bcache in AutoYaST is pretty similar to how a RAID or a LVM Volume Group is described. On one hand, you need to specify which devices are going to be used as backing and caching devices by setting bcache_backing_for and bcache_caching_for elements. And, on the other hand, you need to describe the layout of the bcache device itself. As you would do for a RAID, you can partition the device or use it as a filesystem.

The example below creates a bcache device (called /dev/bcache0) using /dev/sda to speed up the access to /dev/sdb.

<partitioning config:type="list">
    <drive>
      <type config:type="symbol">CT_DISK</type>
      <device>/dev/sda</device>
      <disklabel>msdos</disklabel>
      <use>all</use>
      <partitions config:type="list">
        <partition>
          <!-- It can serve as caching device for several bcaches -->
          <bcache_caching_for config:type="list">
            <listentry>/dev/bcache0</listentry>
          </bcache_caching_for>
          <size>max</size>
        </partition>
      </partitions>
    </drive>

    <drive>
      <type config:type="symbol">CT_DISK</type>
      <device>/dev/sdb</device>
      <use>all</use>
      <!-- <disklabel>none</disklabel> -->
      <disklabel>msdos</disklabel>
      <partitions config:type="list">
        <partition>
          <!-- It can serve as backing device just for one bcache -->
          <bcache_backing_for>/dev/bcache0</bcache_backing_for>
        </partition>
      </partitions>
    </drive>

    <drive>
      <type config:type="symbol">CT_BCACHE</type>
      <device>/dev/bcache0</device>
      <bcache_options>
        <cache_mode>writethrough</cache_mode>
      </bcache_options>
      <use>all</use>
      <partitions config:type="list">
        <partition>
          <mount>/data</mount>
          <size>20GiB</size>
        </partition>
        <partition>
          <mount>swap</mount>
          <filesystem config:type="symbol">swap</filesystem>
          <size>1GiB</size>
        </partition>
      </partitions>
    </drive>
  </partitioning>

Using Btrfs Subvolumes as User Home Directories in AutoYaST

In our last report we presented a new feature to allow using Btrfs subvolumes as user’s home directories. However, the AutoYaST support for that feature was simply missing.

Now you can use the home_btrfs_subvolume to control whether a Btrfs should be used as home directory.

<user>
   <encrypted config:type="boolean">false</encrypted>
   <home_btrfs_subvolume config:type="boolean">true</home_btrfs_subvolume>
   <fullname>test user</fullname>
   <gid>100</gid>
   <home>/home/test</home>
   <shell>/bin/bash</shell>
   <uid>1003</uid>
   <user_password>test</user_password>
   <username>test</username>
</user>

Tuning the Bootloader’s resume parameter

The resume parameter is used by the bootloader to tell the kernel which swap partition should be used for the suspend to disk feature. If you are curious enough, you can find the value for your system in the Kernel Parameters tab of the YaST bootloader module. Now that we know what the resume parameter is, it is time to talk about the two issues we have solved recently.

The first problem was related to the way in which YaST determines which swap partition should be used. The bug report mentioned that YaST was taking a swap partition not used by the system that, in addition, was located in a removable device. After checking the code, we found out that we were using a simplistic heuristic which just selected the biggest swap partition available. We improve that logic to use the biggest swap partition which is being used by the system. However, if no suitable partition is found, YaST will fall back to the old behaviour.

The second problem was related to AutoYaST not handling the noresume option properly. When a user specified that option, AutoYaST just blindly added it to the kernel command line keeping the conflicting resume parameter too. Of course, that caused troubles. Now when noresume is given, AutoYaST simply removes all occurrences of the resume parameter.

Registration, OpenSSL and Debugging

These days, handling the SSL certificates in a proper way is key to keep our systems secured. So during this sprint, we invested quite some time improving how certificates are used in our registration module. Basically, we have improved YaST behaviour in these scenarios:

• Using self-signed certificates.
• Handling with unknown certificate authorities.

When the custom registration server (the new RMT or the older SMT) use a self-signed certificate, YaST offers to import the server certificate and make it known to the system.

On the other hand, when the server SSL key was signed by an unknown key, YaST used to just display an error popup. That was not much helpful as it was not obvious what to do. Now a new popup which contains some hints about how to import the CA certificate manually is displayed. In this case it cannot be imported automatically as YaST does not know where to obtain it, it is not present in the server response.

The work of importing and activating the certificate is now performed by a YaST script, preventing the user from having to run some complicated (and error prone) commands manually.

These improvement and some other OpenSSL details have been documented in the OpenSSL Certificates documentation. Additionally, if you ever need to debug some SSL related issue, this new OpenSSL Debugging Hints documentation might be useful for you. It covers basic topics, like displaying PEM certificate details, running a testing HTTPS server, creating a self-signed certificate, etc.

Detecting DASDs when using virtio-blk in zKVM

IBM’s S/390 platform has some special features that you will not find in conventional architectures like x86. One of them are DASD hard disks. These devices can be accessed in zKVM using the virtio-blk backend, but DASDs need special handling. For instance, the most common DASD type (CDL ECKD) cannot be used with an MS-DOS partition table nor a GPT, instead a DASD partition table is required. Having this requirement in mind, YaST now detects DASDs using virtio-blk properly and uses the correct DASD partition table.

Improving Fonts and Icons Handling in the Installer

Back some time ago, Stasiek Michalski (a.k.a. as hellcp), one of our very active openSUSE community contributors, spent quite some work for better artwork in YaST. As a result, icons are now used from the desktop’s icon theme whenever possible, and the installer font was changed.

One fallout of the latter was that the font size was now too small for users with diminishing eyesight: That new font has different font metrics, so the default font size was too small. We fixed that during this sprint. See also openSUSE/branding#107.

By the way, the disappearing icons issue was solved too. See libyui/libyui-qt#100 if you are interested in the details.

And just to get this straight: We are welcoming active community members to contribute (thanks again, @hellcp!). There will be some bugs; that’s just natural. We need to cooperate to fix them.

YaST Font Scaling Problem on the GNOME Desktop

This is not really a YaST problem, but of course it was still the natural thing to write a bug report against YaST for this bsc#1123424. And it took us quite a while to figure out what went wrong here.

Basically, when you use the GNOME Tweak Tool to set a Font Scaling Factor that is not a multiple of 0.25, this is completely ignored, and so all Qt5 applications (including the YaST Qt Control Center and all YaST modules) appear with unscaled fonts.

The problem is this GNOME Tweak Tool setting non-integer DPI values (which is already out of spec and thus a bug) and the Qt5 libraries consequently completely ignoring that DPI value. So that GNOME tool should do it correctly, but the Qt5 libs could also handle this more gracefully.

Unfortunately, there is nothing that we can do about this from the YaST side, even though we are aware that this might become reported as a YaST bug again in the future

Closing Thoughs

As we stated at the beginning of this post, we are basically in bug squashing mode. So, please, if you have some time, give the testing versions of (open)SUSE a try and report as many bugs as you can.

Thanks!

I see the official documentation has full tutorial for RHEL 6 or CentOS 6 and RHEL 7 or CentOS 7. The main documentation covers Ubuntu 14.04 LTS

openSUSE already has the Nextcloud client packaged in Tumbelweed and the Server is in the PHP extra repo! Personally, I prefer to install eveything from official repository, so when an update is available, I can have it without a glitch. This tutorial describes how to install Nextcloud using command line. I followed the official documentation of Ubuntu 14.04 LTS installation.

Why choose openSUSE Leap? openSUSE Leap is a brand new way of building openSUSE and is new type of hybrid Linux distribution. Leap uses source from SUSE Linux Enterprise (SLE), which gives Leap a level of stability unmatched by other Linux distributions, and combines that with community developments to give users, developers and sysadmins the best stable Linux experience available. Contributor and enterprise efforts for Leap bridge a gap between matured packages and newer packages found in openSUSE’s other distribution Tumbleweed. You can download openSUSE Leap from the site https://software.opensuse.org/.

Make sure that ssh (sshd) is enabled and also the firewall either is disabled or make an exception to the apache and ssh services. You can also set a static IP (check out how).

First of all, let’s install the required and recommended modules for a typical Nextcloud installation, using Apache and MariaDB, by issuing the following commands in a terminal:

Create Database (optional since it’ll create eveything automatically)
Next step, create a database. First of all start the service.

The root password is empty by default. That means that you can press enter and you can use your root user. That’s not safe at all. So you can set a password using the command:

Where newpass is the password you want.

Now you set the root password, create the database.

mysql -u root -p
#you’ll be asked for your root passwordCREATE DATABASE nextcloudb;

GRANT ALL ON nextcloudb.* TO ncuser@localhost IDENTIFIED BY ‘dbpass’;

Database user: ncuser
Database name: nextcloudb
Database user password: dbpass

You can change the above information accordingly.

PHP changes
Now you should edit the php.ini file.

nano /etc/php5/apache2/php.ini

change the values

post_max_size = 50G
upload_max_filesize = 25G
max_file_uploads = 200
max_input_time = 3600
max_execution_time = 3600
session.gc_maxlifetime = 3600
memory_limit = 512M

and finally enable the extensions.

extension=php_gd2.dll
extension=php_mbstring.dll

Apache Configuration
You should enable some modules. Some might be already enabled.

a2enmod php5
a2enmod rewrite
a2enmod headers
a2enmod env
a2enmod dir
a2enmod mime

Now start the apache service.

systemctl start apache2.service
systemctl enable apache2.service

Install Nextcloud from source code (option 1, preferable)
Before the installation, create the data folder and give the right permissions (preferably outside the server directory for security reasons). I created a directory in the /mnt directory. You can mount a USB disk, add it to fstab and save your data there. The commands are:

mkdir /mnt/nextcloud_data
chmod -R 0770 /mnt/nextcloud_data
chown wwwrun /mnt/nextcloud_data

Now download Nextcloud (find the latest version at https://nextcloud.com/install/). Then unzip and move the folder to the server directory.

wget https://download.nextcloud.com/server/releases/nextcloud-10.0.0.zip
unzip nextcloud-10.0.0.zip
cp -r nextcloud /srv/www/htdocs
chown -R wwwrun /srv/www/htdocs/nextcloud/

Make sure that everything is OK and then delete the folder nextcloud and nextcloud-10.0.0.zip from the root (user) directory.

Now open your browser to the server IP/nextcloud

Set your administrator username and password.
Your data directory is: /mnt/nextcloud_data
Regarding database, use the following.
Database user: ncuser
Database name: nextcloudb
Database user password: dbpass

Wait until it ends the installation. The page you’ll see is the following.

Install Nextcloud using the respository (option 2)

If you want to have automatic updates of your Nextcloud instance when there’s a new version, you can add the repository. There are packages available for openSUSE Leap 42.1, 42.2 and Tumbleweed (we recommend openSUSE Leap 42.1). You should be an administrator, so you can install Nextloud on your server.

1. Add the Nextcloud repository.
openSUSE_Leap_42.2

zypper ar http://download.opensuse.org/repositories/server:/php:/applications/openSUSE_Leap_42.2/ Nextcloud

openSUSE_Leap_42.1

zypper ar http://download.opensuse.org/repositories/server:/php:/applications/openSUSE_Leap_42.1/ Nextcloud

openSUSE_Leap_Tumbleweed

zypper ar http://download.opensuse.org/repositories/server:/php:/applications/openSUSE_Tumbleweed/ Nextcloud

2. Refresh your repositories

zypper refresh

3. Install Nextcloud (be careful you have to install LAMP first and change permissions of the files).

zypper install nextcloud

4. Open http://serverIP/nextcloud to install your instance (admin user account). Be careful to create another folder with the proper permissions for your data (as described).

5. Login and use Nextloud.

For more information about Nextcloud on openSUSE, check openSUSE wiki.

For any changes, check the github page.

For more configuration, you can follow the official documentation. That was the basic installation on openSUSE Leap.

Tally multiuser is served from a Samba share  on a NAS device, Tally folder is copied to samba share and path to Tally Data is changed so that it points there. Everything they need including printing and export(CSV) works from all clients. Same way Tally can be run on standalone computers. Neither Tally, Wine or openSUSE are modified for getting it working as it would under Windows environment.

As with previous releases we have bundled a ton of softwares on this live DVD/USB specially packaged for education, along with the Plasma, GNOME and Mate Desktop Environments, full multimedia experience is also provided out of the box thanks to the Packman repositories. Only x86_64 architecture is supported, if you have a lot of machines that only support x86 then read on to find out how you can extend their Li-f-e.

You can of course very easily turn Li-f-e to full-fledged LTSP server to PXE boot machines in your local network. Booting both i686 and x86_64 architectures is supported. In case you need to PXE boot machines below i686 then you would have to install this package.

Happy holidays!

Get Li-f-e from here: Direct Download | md5sum | Alternate download and mirrors

First of all, check out how you can install openSUSE on Raspberry Pi.

Now, you have to compile ZNC. There’s no package in the repositories. If developers read this, please please make an ARM package. Please!!!

First of all, you have to install the following packages (that’s what I did):

zypper in gcc-c++ gcc git libopenssl-devel make

Now, let’s download the last release (you can find the whole procedure at official page)

wget http://znc.in/releases/znc-latest.tar.gz

Then untar the file:

tar -xzvf znc*.*gz

Then you have to do some steps that usually do when you compile:

cd znc*

and run the command

./configure

Next command will take a lot of time to finish

make

When it’s over, run the final command:

make install

You’re ready to use it. Now login as user and run the command:

znc –makeconf

If you have an older configuration, you can use it (run only the command znc).

There is BerryTerminal project which makes it possible to use Raspberry Pi as LTSP Thin Client, on the server you can run any distribution that can run LTSP server, it can be running CPU with x86/x86_64/whatever architecture as LTSP provides a way to run X session from the server via SSH tunnel. Biggest benefit of running LTSP is centralized user and data management, and clients can be of modest specification as all clients’ sessions are run on the server. This is a drawback as well, as the server needs to be powerful enough to handle many sessions. This is where LTSP Fat Client help, it allows running of users’ session on the client that are powerful enough, while users and data are stored on the central server allowing modest server to serve many more clients than it would otherwise. Raspberry Pi is not that capable to run full featured Linux desktop, Banana Pi with it’s dual core CPU and 1 GB RAM is just good enough to work as a Thin Client as well as a Fat Client. perfect for home, small office or school lab.

Piece of history, first ever Banana Pi LTSP terminal running openSUSE KIWI-LTSP

There is openSUSE 13.1 available for Banana Pi, it comes with XFCE desktop and many useful software pre-installed. Because I do not know how to create images for this hardware, that image is used as a base for Banana Terminal. Here are the steps to turn your Banana Pi into LTSP client.

* Download openSUSE-Bananapi-LTSP.tar.xz

* Extract the archive to get openSUSE-Bananapi-LTSP.img from it.

* Dump the openSUSE-Bananapi-LTSP.img on to a SD card, see step 5 here.

* Change settings according to your network configuration

In the second partition of SD card etc/lts.conf edit the SERVER variable to point to LTSP server in your network.

* Plug the SD card in your Banana Pi and boot it up, make sure the network is connected and LTSP server is set up properly. You have to create users on the server to use for login on client.

*  In case you have a bigger SD card, use yast2 disk(partitioner) on the client to expand the second partition. You can use yast’s package manager to install more software. The default password for root is bananapi, you may want to change that first thing after booting.

If you would like to run LTSP client on ARM7 hardware supported by openSUSE I would be happy to accept hardware donation to get it working

Have a lot of fun…

Enter Tiny Core Linux, one awesome distribution in a very tiny bundle. So tiny in fact that the whole OS that PXE boots and gives full desktop X session via ssh or rdesktop is just 27M in size. Compare that to 26M size of just the initrd of standard openSUSE, 49M kiwi-ltsp’s initrd and 180M kiwi-ltsp’s system image. And incredibly it works very well on P4 PC with 128M RAM.

So if you have some old hardware get some new Li-f-e, set up kiwi-ltsp and after that install kiwi-ltsp-tinycore-tc package. Once the package is installed you would see tinycore-thinclient available in PXE boot menu.

Edit /srv/tftpboot/images/tc/nfsrw/home/tc/client.conf according to your need. Change RUN_COMMAND=mate-session on Li-f-e GNOME Classic edition, GNOME seems to have this annoying bug that locks the screen and does not allow unlocking if GDM was not used as display manager. You can remove/comment RSESSION=ssh line to use rdesktop. Use the xrdp package from server:ltsp repository, and of course enable/start the service(chkconfig xrdp on && rcxrdp start). Change the line in /etc/xrdp/startwm.sh that starts Xsession appending the session you want it to start by default for example: /etc/X11/xdm/Xsession mate-session, without that the DEFAULT_WM from /etc/sysconfig/windowmanager is used.

If you are not using openSUSE or cannot use rpm package, get the files from here, adapt the setup script to suite your need.