site  contact  history  index

Nheko Matrix chat client

July 18, 2018 — BarryK

Purism are using Matrix for chat forums, including for the Librem 5 phone:

So, decided to give it a go. There are various Matrix client apps, and I compiled Qt5-based Nheko:

The PET for EasyOS 0.9.5+ (not yet released) is here:

Dependencies are 'olm', 'libsodium', 'liblmdb', which are also PETs. Also 'boost' version 1.66, which is in the upcoming Easy 0.9.5.

Nheko, at startup, offered to register, where a username, password, and "Home Server" can be entered. For the latter, I entered "", and a captcha came up in the browser to verify that I am a human.

After starting Nheko, I was in my own "room", "@<myusername>", but unable to change out of it. Nheko is lacking some features, but is under rapid development.

I logged in at the online browser Matrix client:

Logged in, I was able to ratify a user-agreement, that then allowed changing rooms. I was also able to personalize my account, with email and avatar, which cannot be done in Nheko.

Started up Nheko, logged in, then hit the "+" icon and was able to change rooms. Chose "", and yay, there it is!

Hmmm, perhaps it is easier just to use the online client.

Tags: linux, easy, quirky

Librem 5 phone progress report 15

July 17, 2018 — BarryK

I haven't backed the phone (yet) but have ordered the development-kit. Posted about the project recently:

This is an exciting project, and I frequently visit the News page to see if there is any update posted. Today there is, Progress Report #15:

One thing that impresses me is that they are working with developers of other projects, engaging them and submitting patches. This is the way to go, an ambitious project like this needs lots of participants.

The dev-kit is promised for August 2018. I will be pleasantly surprised if it does meet that deadline, as they have only just designed the board and ordered the components. I think that they are using a CPU SOM module, which does make things easier. Hopefully the components will arrive, but even so, they are optimistic. Usually there are iterations, some boards made, tested, changes, then more made. 

Tags: tech

Still waiting for my Andromium Superbook

July 17, 2018 — BarryK

This was a Kickstarter project, that I backed on August 3, 2016, for US$134 plus US$35 shipping:

...yep, 2016, and I am still waiting.


Get regular emails explaining various reasons for more delays. For awhile now, there have been photos shown of palettes of them, ready to ship. A shipment have arrived in the USA apparently. Further manufacture has been delayed by one of the component suppliers failing to supply paid-for components.

Whatever. Things have moved on, I am not so certain anymore that the concept is useful. Don't want to judge yet, got to play with it first. Anyway, here is their website (Andromium is now Sentio): 

Tags: tech

meta-qt5 layer now in oe-qky-src

July 15, 2018 — BarryK

A little over a week ago, I added the meta-qt5 layer to oe-qky-src, my fork of OpenEmbedded. However, it broke the build of some packages.

So, I went on a journey, exploring how to compile Qt5 without the meta-qt5 layer, from basic principles. A very intense several days, ended with frustration. Well, lots of frustration during those several days!

I did get it to build, using autotools only, but only for x86_64 host and x86_64 target. Kept getting errors when attempted cross-compile for aarch64 target.

Yesterday, gave up, and went back to the meta-qt5 layer, this time hunted down why it's introduction caused some other packages to fail.

Got it sorted, qt5 5.10.1 now builds, but have not yet ported any qt5-based apps into oe-qky-src. Did attempt Scribus, but got a compile error. For now, will build Scribus in the final running system.

This morning, tried to use Smartgit to commit the latest changes. Did something wrong... it seems, when committed a couple of files and a directory together, Smartgit got confused. Smartgit seems to be thinking that the 'meta-qt5' folder is a file!

Git is very powerful, but when something goes wrong, you can really get your knickers in a twist.

To get it uploaded, here it is as a tarball:

Expand somewhere, it will expand to folder 'oe-qky-src', and there is a readme inside.

Right, now to fix Smartgit...

OK, fixed. The problem was, folder meta-qt5 had a .git folder in it, which confused Smartgit. See commits for July 15, 2018:

EDIT 20180717:
I built EasyOS in woofQ from binary packages imported from oe-qky-src, then attempted to compile Scribus. Lots of configure errors. I found that .cmake files in /usr/lib/cmake are somewhat broken. They are setup to work inside OE. I have fixed them, the fixes are in the template files in woofQ, woof-code/packages-templates/qtbase, qttools, etc.

Interesting observation: cmake seems a lot more troublesome in a cross-compiling environment than autotools-based projects. This is an interesting observation due to the praise for cmake that I read everywhere, and some projects, such as Scribus going over to it.

Tags: oe

petget0, a single container runs all of EasyOS

July 07, 2018 — BarryK

As I posted recently, I have been rethinking how containers are implemented in EasyOS. Overall, I want to make them simpler to use.

In the previous post, I explained that X server security in containers has been improved, and introduced a new container named 'petget0':

The basic idea to make container usage extremely simple, is to do away with the need to create containers for running individual apps. Instead, there is just one container, pre-created, and all apps can be run in it.

The concept is simple: the petget0 container is a complete EasyOS, that does everything the main EasyOS does, in a separate desktop, and you can toggle between the container desktop and the main desktop. It is two separate operating systems, the difference being that the containerized one is highly locked down.

The name "petget0" is an arbitrary choice. After bootup, in the main desktop, you can see the petget0 container files here:

/mnt/wkg/containers/petget0/container you can poke around in the container as much as you want. You are "outside" the container, in the main desktop, running as root, so have unlimited power.

Now, to flip into the containerized desktop...

In the JWM tray, you will see a process named "containerized apps", click that, and you will be flipped into the containerized desktop. This is what you will see:


The containerized desktop is running pekwm window manager and lxpanel tray. Everything runs as per normal, as you can see in the above snapshot. Everything, even the PETget Package Manager, so you can install packages -- these will install into the petget0 container, which is completely separate from the main desktop.

To flip back to the main desktop, press ALT-F6, that is, hold down the ALT key and tap the F6 key.

Note, I have set it up so that when EasyOS is booted up, it automatically flips into the containerized desktop. Because, it is likely that this is where you will mostly like to be.

Now for some technical details...

Technical notes

It is useful, for users and developers, to know how all of this is achieved "under the hood".  At bootup, the main desktop starts in the normal way, with Xorg, running JWM window manager and ROX-Filer for the desktop icons and wallpaper.

In /root/Startup, there are various scripts that run after X has started. To follow the trail from the commandline, /usr/bin/xwin is run, which launches Xorg and /root/.xinitrc. The latter launches various things, including /usr/sbin/delayedrun and finally JWM.

It is /usr/sbin/delayedrun that runs the scripts in /root/Startup. These are mostly applets that run in the JWM tray, such as battery-status and volume-control. It also runs /root/Startup/xephyr.

/root/Startup/xephyr launches the Xephyr server, then starts the container:

 Xephyr :1 -fullscreen -title "$TXT1" -name "xephyr" -zap -dpi "$DPI" -nolisten tcp &
sleep 0.5
#next, run window manager and panel inside petget0 container...
ec-chroot petget0 pekwm-lxpanel

Xephyr is started fullscreen, so a black screen will appear. I have only tested this on my midi-tower PC, with Intel video, so I don't know if this fullscreen startup will work with other video hardware. I opted for fullscreen, as starting in a window has some problems.

Look at /usr/local/easy_containers/ec-chroot to see how it starts the container and launches it. Following the trail, the /ec-run script will run first in the petget0 container, which will then run /usr/bin/pekwm-lxpanel. The latter will launch pekwm and lxpanel.

pekwm, lxpanel

I chose these two rather than JWM, as had some show-stopper problems with running the latter in Xephyr. Though, that was when I was using Xephyr as a resizeable window. Now running fullscreen only, will revisit JWM.

pekwm and lxpanel have been compiled in my fork of OpenEmbedded (commits July 6, 2018):

I used a very old version of lxpanel,, partly because it is simple and does the job, and secondly because Puppy Forum member plinej created some patches for that version. I modified those patches to suite EasyOS, and they are in the github repo. What the patches do is add paths to where icons are kept in EASYOS, and to automatically load from the XDG .desktop files -- so no external menu converter is required, just restart lxpanel.

I am unfamiliar with pekwm and lxpanel, getting up to speed. With pekwm, a right-click brings up a menu, generated by the 'xdg2pekwm' uility, but it looks awful. If anyone has experience with pekwm, your input will be welcome!

Network access

I have not unshared the network namespace. The ultimate security would be to do so, but this is a maybe for the future. So, apps in the container use the main system Internet connection. This requires /etc/resolv.conf to be copied into the container, and this is done in the ec-chroot script.

However, it is likely that the network connection is not established at bootup, when the petget0 container is started, so /etc/resolv.conf is empty.

There is a fix for this, service-script /etc/init.d/petget0. This script runs when there is Internet connection, and copies /etc/resolv.conf into the container.

EasyOS has pup_event service management, my own creation to start and stop services when dependencies are met. Examine scripts /etc/rc.d/ and /etc/rc.d/rc.services_ipc, and file /etc/eventmanager, to see how pup_event service management works.

Mount namespace

petget0 is pretty well locked down, though there are still some things that need to be done.

I would like to unshare the mount namespace, however, SeaMonkey crashes. But, only when accessing https sites. This is something that needs further investigation.

petget0 configuration file currently has these settings:

#For security, unshare these namespaces:

....the ultimate aim is to set all of them to "true".

User zeus

There is a user:group named zeus:zeus. This can be used in containers to lock-out access as required. In EasyOS, like Puppy Linux, the user runs as root, having unlimited rights. In a container, the user is still "root", but with limited rights. Examine the ec-chroot script, and /ec-run to see how Linux Capabilites is used to restrict the rights.

The ec-run script is an example. It is owned zeus:zeus, with 700 permissions, so only zeus can use it. The password assigned to zeus is the same as that given at bootup, so only you know it.

Running as "root", in a container, does have one big advantage: copying files to and from the main root filesystem. It becomes a non-issue, no need to be concerned with file ownerships and permissions. That is, if, in the main desktop, you copy a file into the petget0 container, perhaps something that you want to open by an app in the container, no problem with it being owned by root, the app in the container will have full rights over it.

Enough rambling on, this post has become too long. But, it is good to document as much as possible. For me too -- I look at what I did a couple of years ago, and can't recall how it works, so I also need these posts to refresh my memory!

Tags: easy

Improved X server security in Easy Containers

July 06, 2018 — BarryK

I am gradually ramping up the security for Easy Containers. Most recently, attention has been given to the X server that is used in a container, and the ways in which it can be accessed. Here is a snapshot of the latest Easy Container Management (see Filesystem menu):


Now, there is a choice of Xorg or Xephyr X servers. The latter is a nested server, which outputs to its own window within the main Xorg desktop. Using Xephyr in a container is considered to be more secure.

There are four ways in which an application can "connect" to the X server: tcp port, abstract socket, pipe or Unix Domain Socket. Both Xorg and Xephyr are started with "-nolisten tcp", thus disabling that option.

To see where the servers are launched and the commandline, for Xorg, see /usr/bin/xwin, for Xephyr see /root/Startup/xephyr (in the upcoming EasyOS 0.9.5)

The other three have arguments for an against. For EasyOS 0.9.5, I decided to launch Xorg with "-nolisten tcp -nolisten local", thus in the case of Xorg there only remains the Pipe and Unix Domain socket options.

Anyway, the "?" help button that you can see in the above snapshot, has useful summaries of each option.

To see the choices applied to a container, there is a configuration file. EasyOS 0.9.5 has a new container named "petget0", and the configuration file is here:


Printing the X choices:

#Connect to X by abstract socket, pipe, or unix domain socket (abstract|pipe|unix)...
#Use Xorg or Xephyr server (xorg|xephyr)...

As I posted recently, I wanted to rethink some of the basics. That will be ongoing, however, I am now looking at implementing containers in a different, simpler, way. Simple, so that the above Easy Containers Management GUI app will never even be needed to run. So the user will not have to get involved in the details of creating a container and making those technical security choices.

Will explain more soon...

Tags: easy

coreutils cp utility broken compiled with musl

July 02, 2018 — BarryK

In the latest build of EasyOS I am getting file copy errors when using 'cp'. This build is using a statically compiled coreutils single-binary (with applets symlinked to it, just like busybox), that was compiled in OE.

Here is an example:

# coreutils --coreutils-prog=cp -a -f /mnt/sdb1/projects/woof/woof-project/builds/quirky-out_amd64_amd64_oe_pyro_easy/sandbox3/rootfs-complete/var varX
coreutils: failed to preserve ownership for varX/local/pupdial/isp: Not supported

"isp" is a symlink to a folder, target with permissions '777'. That is what causes the error message, though the copy does succeed.

Alright, trying busybox cp:

# rm -rf varX
# busybox cp -a -f /mnt/sdb1/projects/woof/woof-project/builds/quirky-out_amd64_amd64_oe_pyro_easy/sandbox3/rootfs-complete/var varX

...good, no error message.

OK, compiling coreutils with uClibc. I used a very old uClibc, refer to, and bumped coreutils to 8.30. Have a static single binary, test it:

# rm -rf varX
# coreutils --coreutils-prog=cp -a -f /mnt/sdb1/projects/woof/woof-project/builds/quirky-out_amd64_amd64_oe_pyro_easy/sandbox3/rootfs-complete/var varX


Grumble, grumble, this reinforces my dislike of musl. I did a search on the Internet, this bug has been reported over several years.

Tags: easy, oe

Xorg .Xauthority is extra protection

July 02, 2018 — BarryK

I don't know of any pups that have bothered with this, however, ~/.Xauthority is an extra level of security, that I have now implemented in EasyOS.

I am playing with running X apps in containers with the Xephyr nested X server. In /usr/bin/xwin, I now launch Xorg with "-nolisten tcp -nolisten local", which prevents any app to connect to the Xorg server via a TCP port or what is called an "abstract socket".

That leaves /root/.X11-unix/X0 a Unix Domain Socket. This is how apps will communicate with Xorg.

Inside a container, it is still possible to connect with Xorg :0, even though apps inside the container cannot "see" /root/.X--unix/X0 in the host. This can be done with 'socat'. Do this in the host:

# socat -ly -d -d TCP-LISTEN:6000,fork,bind=localhost UNIX-CONNECT:/tmp/.X11-unix/X0 &

Then in the container:

# export DISPLAY=localhost:0

However, Xorg itself is considered to have many security weaknesses, and one step-up to improve security is to use Xephyr, which is a nested kdrive X server. I am running this on DISPLAY :1, launched in the host,

Putting that aside, while reading up on X xecurity, it seemed to me that it will be a good thing to implement /root/.Xauthority. A "cookie" can be placed in this file, and any other computer that wants to connect to our local Xorg must have a matching cookie in its own ~/.Xauthority file.

So, /etc/rc.d/rc.sysinit now has this, just after the hostname is autogenerated:

 xPW="$(< /dev/urandom tr -dc 'a-f0-9' | head -c32)"
echo -n '' > /root/.Xauthority
xauth -f /root/.Xauthority add ${PUPHOSTNAME}/unix:0 . ${xPW}

The hostname may also be changed in QuickSetup, /usr/sbin/quicksetup, which calls /usr/sbin/hostname-set. So, the same code is now in hostname-set, just after writing to /etc/hosts.

I think that I have got it right, not verified yet! If I haven't, if the cookie has the wrong hostname, then the desktop will become non-functional.

There is something called "FamilyWild", which basically enters a wildcard in place of the hostname. That means the cookie will work for all local displays, regardless of what the hostname is. Unfortunately, I want to distinguish between :0 and :1, whereas the docs state that FamilyWild applies to "all displays".

Here is some further info:


A special connection family (FamilyWild, value 65535) causes an entry to match every display, allowing the entry to be used for all connections.

For the record, I found this on the Internet, a way to convert a cookie to FamilyWild:

# touch test1
# xauth nlist :0 | sed -e '/^..../ffff/' | xauth -f test1 nmerge -
# xauth -f test1 list

Tags: easy