sunweaver's NET

Introduction

NX is a software suite which implements very efficient compression of the X11 protocol. This increases performance when using X applications over a network, especially a slow one.

NX (v3) has been originally developed by NoMachine and has been Free Software ever since. Since NoMachine obsoleted NX (v3) some time back in 2013/2014, the maintenance has been continued by a versatile group of developers. The work on NX (v3) is being continued under the project name "nx-libs".

History

Until January 2015, nx-libs was more mainly a redistribution approach of the original NX (v3) software. We (we as in mainly a group of X2Go developers) kept changes applied to the original NoMachine sources as minimal as possible. We also kept the original files and folders structure. Patches had been maintained via the quilt utility on top of a Git repository, the patches had always been kept separate. That was the 3.5.0.x series of nx-libs.

In January 2015, the characteristics of nx-libs as maintained by the X2Go project between 2011 and 2015 changed.

I just did a bundle upload of all MATE 1.14 related packages to Debian unstable. Packages are currently building for the 23 architectures supported by Debian, build status can be viewed on the DDPO page of the Debian MATE Packaging Team [1]

Credits

Again a big thanks to the packaging team. Martin Wimpress again did a fabulous job in bumping all packages towards the 1.14 release series during the last weeks. During last week, I reviewed his work and uploaded all binary packages to a staging repository.

Also a big thanks to Vangelis Mouhtsis, who recently added more hardening support to all those MATE packages that do some sort of C compilation at build time.

After testing all MATE 1.14 packages on a Debian unstable system, I decided to do a bundle upload today. Packages should be falling out of the build daemons within the next couple of hours/days (depending on the architecture being built for).

GTK2 -> GTK3

The greatest change for this release of MATE to Debian is the switch over from GTK2 to GTK3.

People using the MATE desktop environment on Debian systems are invited to test the new MATE 1.14 packages and give feedback via the Debian bug tracker, esp. on the user experience regarding the switch over to GTK3.

Thanks to all who help getting MATE 1.14 in Debian better every day!!!

Known issues when running in NXv3 sessions

The Arctica Project is a task force of people reinventing the realm of remote desktop computing on Linux. One core component for multimedia experience in remote desktop / application scenarios is the to-be-reloaded / upcoming Telekinesis Framework.

Telekinesis provides a framework for developing GUI applications that have a client and server side component. Those applications are visually merged and presented to the end user in such a way that the end user's “user experience” is the same as if the user was interacting with a strictly server side application. Telekinesis mediates the communication between those server side and client side application parts.

As a reference implementation you can imagine a server side media player GUI (TeKi-aware application) and a client side video overlay (corresponding TeKi-aware service). The media player GUI "remote-controls" the client side video overlay. The video overlay receives its video stream from the server. All these interactions are mediated through Telekinesis.

A proof of concept has been developed for X2Go in 2012. For the Arctica Server, we are currently doing a (much cleaner!) rewrite of the original prototype [1]. See [2] for the first whitepaper describing how to integrate Telekinesis into existing remote desktop solutions. See [3] for a visual demonstration of the potentials of Telekinesis (still using X2Go underneath and the original Telekinesis prototype).

As already hinted in my previous blog post, here comes a short howto that explains how to test-build nxagent (v3) against a modularized X.org 7.0 source tree.

WARNING: Please note that mixing NX code and X.org code partially turns the original X.org code base into GPL-2 code. We are aware of this situation and work on moving all NXv3 related GPL-2 code into the nxagent DDX code (xserver-xorg/hw/nxagent) or--if possible--dropping it completely. The result shall be a range of patches against X.org (licensable under the same license as the respective X.org files) and a GPL-2 licensed DDX (i.e. nxagent).

How to build this project

For the Brave and Playful

$ git clone https://git.arctica-project.org/nx-X11-rebase/build.git .
$ bash populate.sh sources.lst
$ ./buildit.sh

You can find the built tree in the _install/ sub-directory.

Please note that cloning Git repositories over the https protocol can be considerably slow. If you want to speed things up, consider signing up with our GitLab server.

For Developers...

... who have registered with our GitLab server.

$ git clone git@git.arctica-project.org:nx-X11-rebase/build.git .
$ bash populate.sh sources-devs.lst
$ ./buildit.sh

You will find the built tree in the _install/ sub-directory.

This is to give a comprehensive overview on the recent progress made in NXv3 (aka nx-libs) development.

The upstream sources of nx-libs can be found at / viewed on / cloned from Github:
https://github.com/ArcticaProject/nx-libs

A great portion of the current work is sponsored by the Qindel Group [1] in Spain (QINDEL FORMACIÓN Y SERVICIOS, S.L.). Thanks for making this possible.

Planned release date: 2nd July, 2016

We aim at releasing a completely tidied up nx-libs code tree versioned 3.6.0 on July 2nd, 2016. There is still a whole bunch of work to do for this, but I am positive that we can make this release date.

Goals of our Efforts

There are basically two major goals for spending a considerable amount of time, money and energy on NXv3 hacking:

• make this beast long-term maintainable
• make it work with latest X11 desktop environments and applications

The efforts undertaken always have the various existing use cases in mind (esp. the framework of the coming-up Arctica Project, TheQVD and X2Go).

Overview on Recent Development Progress

General Code Cleanups

Making this beast maintainable means first of all: identifying code redundancies, unused code passages, etc. and remove them.

This is where we came from (NoMachine's NX 3.5.x, including nxcomp, nxcompext, nxcompshad, nx-X11 and nxagent): 1,757,743 lines of C/C++ code.

[mike@minobo nx-libs.35 (3.5.0.x)]$ cloc --match-f '.*\.(c|cpp|h)$' .
    5624 text files.

Recently, Digital Ocean (which I am a customer of) asked me "how they were doing". Well, yet another survey... Let's ignore this one for now... I thought some days ago.

And then yesterday, I added IPv6 support to my main mail server (which runs at Hetzner, Germany). All my hosted/rented/whatever systems report back to this main mailserver. Now that that main mail server finally has its AAAA record and its own IPv6 address, all associated systems try to reach this main mail server via IPv6. Of course.

Crippling IPv6 support by adding Port Blocks

But, then, I see messages like these in my syslog files on droplets hosted at Digital Ocean:

Apr 13 10:10:59 <do-droplet> postfix/smtp[23469]: connect to mail.<mydomain>[<ipv6-address>]:25: Connection timed out

After some more research [1], I realized that the folks out there at DO really apply some port blockings to IPv6 networks, but not to IPv4 networks. Pardon me? From my DO droplets, I can nmap any port on my mail server (25,80,143,443, 465, 587, etc.) via the IPv4 connection, but not over the IPv6 connection. Wait, not fully true: ports 80 and 443 are not blocked, but the other aforementioned ports are definitely blocked.

Is Digital Ocean a professional ISP or a WiFi hotspot provider at my nearest coffee place? (This really makes me scratch my head...).

Routing only the first 16 addresses of allocated /64 prefixes

At one of your school sites, we encountered an issue where several people could not access the internet via the school's proxy server when using Google Chrome / Chromium Browser

By default those two browser variants use the (Linux) system wide proxy settings. This is not always the best choice. For our setups, we prefer configuring proxy settings via WPAD [1].

We did not investigate each user profile for underlying reasons of not being able to connect via the site's proxy server in depth. Instead, we searched for a system-wide solution that easily enforces WPAD protocol usage when browsing the internet with Google Chrome / Chromium Browser.

From the command line, forcing Google Chrome / Chromium Browser into WPAD proxy mode is very easy. It can be done with the command line option --proxy-auto-detect:

[user@mymachine ~]$ chromium-browser --proxy-auto-detect

To enforce launching these two browser variants with --proxy-auto-detect whenever users click onto icons provided on the Linux desktop, you can simply follow the below recipe:

1. Create /usr/local/share/applications/ unless it already exists
2. Copy /usr/share/applications/google-chrome.deskop to /usr/local/share/applications/.
3. Copy /usr/share/applications/chromium-browser.deskop to /usr/local/share/applications/.
4. Set the x-bit on those .desktop files: sudo chmod a+x /usr/local/share/applications/*.desktop
   

TL;DR;

If you want to know why cloning several of the X.org repositories to Github or GitLab instances fails and how this can be worked around, you may want to continue reading.

Why we stumbled over this issue...

As a joint effort of the Arctica Project, TheQVD and X2Go, Ulrich Sibiller and I are currently preparing a build workflow for the nxagent X-server (version 3) [1] that allows building nxagent against the modular X.org 7.0 (using autoconf and automake) rather than the monolithic build workflow of X.org 6.9 (using ancient imake).

Our goal is to rewind all X.org components required for building nxagent back to a state where nxagent successfully builds and runs. Then we will go through various, (probably) monthly cycles of

• bumping commit level of required X.org components
• rebuild and test nxagent
• fix FTBFS, if any
• fix broken functionality, if any

Our first hurdle...

After Ulrich now has a functioning nxagent-against-X.org-7.0-workflow locally, we want to get everything into the Arctica Project's Github namespace. Which fails...

[mike@minobo xorg.upstream]$ git clone https://anongit.freedesktop.org/git/xorg/lib/libX11.git
Cloning into 'libX11'...
remote: Counting objects: 18520, done.
remote: Compressing objects: 100% (3441/3441), done.
remote: Total 18520 (delta 15094), reused 18325 (delta 14954)
Receiving objects: 100% (18520/18520), 5.98 MiB | 549.00 KiB/s, done.
Resolving deltas: 100% (15094/15094), done.

February 2016 has been a very active month regarding me contributing to the FLOSS world.

• Finalizing MATE uploads to Debian with regards to the Beta 1 Freeze of Ubuntu 16.04
• Work on RDP related packages in Debian
• Work on Debian Edu related packages
• Work on Debian LTS
• Work on nx-libs (NX v3)

Honouring my Sponsors

I am happy to share that this month's FLOSS work has been sponsored by various sponsors.

• Work on the packages mate-dock-applet, topmenu-gtk and getting GIR-support back into libwnck has been sponsored by Martin Wimpress, the main driving force (AFAIK) behind Ubuntu MATE [1].
• Work on Debian LTS has been sponsored by the various Debian LTS sponsors proxied through Freexian SARL (thanks to Raphael Hertzog for organizing the paid LTS contributors team via his company) [2].
• Work on nx-libs has been sponsored by the Qindel Group [3].

Thanks to all people and companies sponsoring my work on FLOSS projects.

This month's MATE uploads to Debian

With regards to the Beta 1 Freeze date of Ubuntu 16.04 LTS (18th Feb 2016), Martin Wimpress, Vangelis Mouhtsis and I performed quite some work on Debian MATE.

Uploads to Debian unstable:

• caja 1.12.4-2 [4]
• mate-menu 5.6.8-1 [5]
• mate-panel 1.12.2-1 [6]
• mate-dock-applet 0.67-3 (NEW) [7]
• mate-polkit 1.12.0-3 [8]
• eom 1.12.2-1 [9]
• pluma 1.12.2-1 [10]
  

This article describes how to use systemd-networkd on Debian Edu 8.x (aka jessie) notebooks.

What we have to deal with?

At the schools we support we have several notebooks running Debian Edu 8.x (aka jessie) in the field.

For school notebooks (classroom sets) we install the Debian Edu Workstation Profile. Those machines are mostly used over wireless network.

We know that Debian Edu also offers a Roaming Workstation Profile at installation time, but with that profile chosen, user logins create local user accounts and local home directories on the notebooks (package: libpam-mklocaluser). For our customers, we do not want that. People using the school notebooks shall always work on their NFS home directories. School notebooks shall not be usable outside of the school network.

Our woes...

The default setup on Debian Edu jessie workstations regarding networking is this:

• systemd runs as PID 1
• ifupdown manages static network interfaces (eth0, etc.)
• NetworkManager manages wireless network interfaces
• for our customers we configured NetworkManager with a system-wide WiFi (WPA2-PSK) profile

We have observed various problems with that setup:

• By default, network interface eth0 is managed by ifupdown (via /etc/network/interfaces):
  

  auto eth0
  iface eth0 inet dhcp
  

  Woe no. 1: In combination with systemd, this results in a 120sec delay at system startup.