site  contact  history  index

empty and script utilities for Easy Containers

October 17, 2018 — BarryK

Prior to releasing Easy 0.9.7, there was a problem with launching apps in containers. For 'audacious' (music player) for example, a desktop icon is created, clicking on it runs /usr/sbin/ec-chroot-audacious, which has this in it:

ec-chroot audacious

...which failed, yet does work from a terminal window and from the JWM menu, as I reported here:

I fixed it for 0.9.7, like this:

urxvt -name eclaunch -iconic -e ec-chroot audacious

...where "-iconic" will launch the urxvt window minimized, and the name "eclaunch" is recognised by JWM to hide the window. This is clumsy, but it works.

Something in the 'ec-chroot-audacious' script is expecting the script to have been launched from a terminal. As it hasn't, in the case of ROX-Filer, there is a failure -- though interesting, can launch from the JWM menu OK.

I did some more research on this, and found this excellent discussion:

...the example is given of the 'ls' command. This checks if run in a terminal or in a script, and if the former, outputs with color-highlighted text. In a script, you just want plain text, for parsing purposes. So, that is the gist of the situation, something in 'ec-chroot-audacious' is performing a test, can't find a terminal, and aborts ...or something like that.

The above reference describes using the 'script' command, which fortuitously is a busybox applet. Yes, it works:

script -q -c "ec-chroot audacious" /dev/null

...clicking on the desktop icon, I can see the new pseudo-tty node getting creating in /dev/pts, and removed when quit audacious.

The above link also mentions a command named 'empty', project page here:

That also works:

empty -f ec-chroot audacious

...empty also created named pipes in /tmp, for input and output, though I don't see that I would need them.

Will think about it tonight, whether to use 'script' or 'empty'. If I can't find any downside to 'script', will probably go for that, as it is already available (in busybox). 

Here is another interesting read:  

EDIT 2018-10-17:
Decided to use 'empty'. It is now compiled in oe-qky-src:  

Tags: easy

Chromium browser PET improved

October 15, 2018 — BarryK

I posted recently about creating a PET package of the Chromium web browser, for use in Easy:

There has been some feedback on it. FeodorF informed me about /etc/chromium/00-default.conf, where commandline options may be specified, so they don't have to actually be on the commandline. I have put this into the file:

CHROMIUM_FLAGS="--test-type --no-sandbox"

EDIT 2018-10-16: see below about "--test-type"

Chromium defaults to downloading and saving files to '/root/Downloads'. For Easy, want that to be '/mnt/wkg/home/downloads' for downloads, and '/mnt/wkg/home' for saving files, as '/mnt/wkg/home' is where all personal files are intended to be located.

There does not seem to be any commandline options to specify those paths, cannot find any official way to do it, so improvised this: in the PET, created file root/.config/chromium/Default/Preferences, with just this in it (and no CR on end of line):


At first startup, Chromium will read that file. Although I only put in a tiny portion of what goes into that file, no problem, Chromium will write to it with everything else.

Another tester, belham2, reported being unable to move Chromium into a container. Yes, it can be downloaded inside the "desk" container, using the package manager, that works great. However, if Chromium is installed in the host desktop, then the 'Easy Container Manager' run (Filesystem menu), there is no listing for chromium, so it cannot be made into its own container.
The reason is, it got filtered out as the 'easy-containers' script does not like the "EXEC=chromium --no-sandbox" line in the 'chromium.desktop' file -- it rejects a line with a space character in it.
The new PET has "EXEC=chromium", no space character, so now all should be good.

Here is the new PET, the "bk3" designates it is my modifications (87.3MB): 

Any problems, please post to the new forum:  

EDIT 2018-10-16
The "--no-sandbox" is needed to run in Easy, however it causes a warning message to appear at the top of the Chromium window, "You are using an unsupported commandline flag" -- very annoying, and it has to be manually closed.
I googled, and found how to suppress the warning message, by the "--test-type" parameter, as posted here:!topic/chromium-discuss/O4WpwWvGz4A

I had previously scanned through this list of the commandline flags:

...and the description of "--test-type" does not have any hint of what it can actually do. A bit more of a hint here:

Anyway, thanks to the guy who discovered this switch! The PET is now "bk3". 

Tags: easy

EasyOS 0.9.7 released

October 14, 2018 — BarryK

Yay, here it is! For x86_64 PCs, download from here:

I posted last night about difficulty with launching containerized apps from desktop icons:

There is now a workaround, clicking an icon runs 'urxvt' terminal emulator which then runs the container. You don't want to see the urxvt window, so JWM is setup to hide it -- when you click on a desktop containerized-app icon, if you watch carefully, you will see a window flicker briefly on the screen, then disappear as JWM hides it -- except, I found a couple of times that JWM failed to hide it, leaving behind a visible window in the tray, labeled "ec-chroot".

So, if you do see that "ec-chroot" appearing in the tray, just ignore it. I am going to have another careful look at this, really would prefer not to have the urxvt launcher. An alternative would be not to have ROX-Filer desktop icons at all, use either a JWM panel or icons in the tray.

Anyway, those who are interested in Easy Containers will now be "on the same page" as me, for testing purposes. That urxvt thing is just a launching detail, that I will investigate further.

Another item on the to-do list, is try to fix the Xorg crashing that I reported recently, due to glamoregl and the modesetting driver.

Oh yes, also need to go through the steps of frugal installation, and update/improve the docs. Will do that soon.

One good thing in 0.9.7, for me anyway, is my ethernet connection is now working reliably. At bootup, Easy runs the 'ifplugstatus' utility in a loop, probing the ethernet cable to see if it is active. The odd thing is, from the time that Easy brings "up" the eth0 interface, it can take from 5 to 26 seconds before the router responds and activates the cable, so that ifplugstatus will return "Link beat detected". Increasing the waiting time fixed it.

If you want to read a bit more, please browse this blog. Also, the last release was 0.9.6, both 32-bit and 64-bit:

It would be reasonable to summarize that most of my effort between 0.9.6 and 0.9.7 has been on Easy Containers.

One more thing, do not upgrade from an earlier installation. Treat 0.9.7 as a new install. Have fun!

Forum feedback is welcome here:   

Tags: easy

EasyOS Pyro 0.9.7 almost ready

October 14, 2018 — BarryK

Thought it was ready, built it, some final tests... found another bug, actually, something that worked before, now has decided not to!

The "desk" desktop-in-container is looking really good. It seems to run as fast as the main desktop -- no problem with watching 720p full-screen youtube videos in the desk-container.

Something that has been plaguing me for a few days, is this error message when JWM runs in a container:

tcgetattr(): inappropriate ioctl for device

...and JWM crashes. Not just JWM. This is happening when launch a container from the desktop icon, not when I do it from a terminal. OK also when launch from JWM menu.

I readup on reasons for this crash, and thought that I could use the 'stty' utility to fix it, but no go. The only thing that works is to launch the container via a terminal, so for example an "audacious" container icon will launch "urxvt -e ec-chroot audacious" -- and have to set JWM in the host system to hide the urxvt window.
It works, but not entirely satisfactory.

Anyway, just a couple of things to do, so 0.9.7 should be out tomorrow.

Tags: easy

Keyboard layout for bootup password

October 10, 2018 — BarryK

Earlier this year I wrote about encryption of folders in the working-partition of EasyOS:

This required entering a password in the initrd, before the folders have anything in them. It cannot be done after the folders have some content.

There is a problem though. It is fine for those of us with a US-layout keyboard, but there is a complication for others. I have setup the 'init' script in the initrd, to automatically apply the entered password as the password for 'root' and 'zeus' users.

This is a problem, because after bootup and you choose a non-US layout, then if you ever want to enter the password for 'root' or 'zeus', it might not be correct. I think that is the situation, if I have thought it through correctly.

So, in the 'init' script in the initrd, there is now a list of keyboard layouts, and you type a number corresponding to the one appropriate for your keyboard, then you enter the password.

The layout you choose is remembered, so future bootups will only ask for the password.

I do plan to create a GUI for this, both to select keyboard layout then enter password, or even have an on-screen keyboard and allow mouse input. The plan is to use LittlevGL for this, but that is "down the track".

Tags: easy

Plans for Easy releases

October 09, 2018 — BarryK

There is a new option in the boot menu, "Rollback to pristine first bootup", in addition to "Rollback to last saved session".

The reason for this, is some testers have reporting the system getting messed up somehow, and it won't boot to the desktop. Until I can find out why these problems are happening, this new boot option will enable recovery. It simply wipes the .session folder, meaning that it is like you are booting up for the first time. So, any installed packages will be gone. This does not touch /mnt/wkg/home, the folder where you would normally keep personal files.

Anyway, about releases of Easy. The latest is 0.9.6, and I am gradually working toward 1.0. Lots of thing may change between now and then, so rollback, roll-forward, upgrades, maybe other stuff, might not work properly. The intention is that the underlying infrastructure will be frozen at 1.0, so rollback, etc., should work nicely from then on. Until then, each release will have to be treated as a fresh new install.

So, how far away is 1.0? I have a shortlist of essential infrastructure things, at this stage four items, but I cannot predict when they will be done. Might be mostly there in, say, a week, and plan to release 0.9.7.

I reported about 'glamoregl' causing Xorg to crash:

...not sure what to do about that. I could try upgrading Xorg, again, but reluctant to do that yet. Or, remove the 'glamoregl' module, which will result in software rendering of OpenGL, at least for the Xorg 'modesetting' driver.

Tags: easy

Easy Containers run as user zeus

October 09, 2018 — BarryK

In Easy, containers are run as "crippled root", which does seem pretty secure. However, for the paranoid, there is now a checkbox to run as user 'zeus' in a container:


Yesterday I speculated how to drop down to root in a container:

However, ended up doing it like this:

# pflask --mount=bind:/mnt/sdc2/home/shared:/shared-folder --keepenv --mount=bind:/tmp/.X11-unix/X0:/tmp/.X11-unix/X0 \
--no-ipcns --netif --mount=bind:/dev/snd:/dev/snd --caps=all,-sys_admin,-sys_boot,-sys_chroot,-sys_ptrace,-sys_time,\
-sys_nice,-sys_resource --no-userns --chroot=/mnt/sdc2/containers/sh0/container -- su zeus /ec-run sh0 sakura
...this is an example invocation. The "su zeus" is executed after the chroot.

There are some issues to sort out. The above example, running the 'sakura' terminal emulator, works, however, some other apps don't. For example, I can launch 'audacious' (music player) from the sakura terminal in container, however, trying to run it directly, get an error message "Required key not available". Even running audacious from sakura, there are warning messages, as it is trying to write to /root/.config -- so, things to sort out.

EDIT 2018-10-09
Ah, the "Required key not available" error was because I tried to run as user zeus in an already-existing audacious container. The 'user zeus' checkbox has to be ticked when first creating the container.
Now, audacious runs, but no sound -- so there are still issues! -- my guess would be /dev/snd permissions -- it is a slippery slope when we get into running non-root.

Tags: easy

Kernel 4.14.74 enabled user namespaces

October 08, 2018 — BarryK

The 4.14.73 kernel was compiled only a few days ago:

It has namespaces support, all except user namespaces. Coz I had read various reports about user namespaces being trouble.

However, want to explore user namespace in containers, so have now enabled it in the compile of the 4.14.74 kernel. That is the only configuration difference.

General setup
 Namespaces support
[*] User namespaces

With so much happening, should think about getting out the next Easy, version 0.9.7, soon.

EDIT 2018-10-8
Reverted, going back to the 4.14.73 kernel with user namespaces disabled. Will keep it disabled for future compiles of the kernel. Have been reading some more, and user namespaces seem like asking for trouble. Plus, as already running as root in Easy, there doesn't seem much point in having user namespaces.

What I do want to be able to do is optionally run as user 'zeus' in containers. I was unable to get pflask to do that. rather than get tied up trying to "fix" pflask, perhaps this is a satisfactory workaround:

# pflask -- chroot --userspec=zeus:zeus /mnt/sdc2/containers/sh0/container whoami

Well, that's a starting point, but has limitations. If pflask drops capabilities, will have to make sure that still has the capability to do a chroot and change user:group -- which, oddly, may mean zeus will end up with more capabilities than the "crippled root" -- though, a start-script in the container could drop more capabilities.

Also, the full 'chroot' from 'coreutils' package is required, as the busybox applet does not support that commandline option.

Tags: easy