Ubuntu LTS vs non LTS releases

Good day. As I install various versions of Ubuntu on a few virtual machines and computers and also use Debian on some as well, there is naturally an important comparison to be made between the Debian and Ubuntu release cycles. Ubuntu has stabilised on a twice yearly release cycle but the LTS releases are every two years and as I am now finding, the 5 years of support for an LTS release is much preferable to only a few months for intermediate releases. Recently I have had to deal with systems installed with Disco releases that are now not being supported for updates as what I understood to be about two years of support has been dropped to just nine months resulting in 404 errors when apt attempts to contact the servers for updates. This in turn affects the ability to install new software as well as update existing packages.

This realisation leads me to conclude that as far as any version of Ubuntu is concerned, it is best to stick with LTS unless you are intending to keep updating every year or twice a year to the latest release. For my laptop that is only used occasionally I am depending on it being able to be installed with new software at any time and not have the situation I had this week where I was unable to install Zoom because the supporting packages for the installation were not available from the official repositories. I was then forced to update to a later version before being able to complete the installation.

For this type of situation we must therefore conclude that it is best to rely on the Ubuntu LTSs which like Debian come out less frequently but are supported for a longer period. The latest LTS is 20.04 (Focal) and hopefully it won't need to be updated until at least 2 years when the next LTS comes out for the software I use on the laptop because I don't want to be caught the same way again. The best thing that can be said is that you can streamline a reinstall by remounting /home to a separate partition and then install as much software as you can to your home folders but this is not possible to achieve for software that relies on apt, dpkg or snap to install. I have only been able to achieve this with portable type software such as AppImage that can be placed into any path as a single file and run there, as well as Firefox Developer and Thunderbird which are designed as portable applications that can run from any folder path and consist of multiple files and folders that can be extracted to any path from an archive.

How to PERMANENTLY disable an input device in Linux (Xorg Display Server)

About 2 months ago I posted on how to use the xinput command (on Ubuntu and derivatives) to disable an input device. This, however, only works until the next time the computer is restarted. In addition, not all distros provide the xinput command; Debian doesn't, and I haven't done any research to determine whether this command needs to be installed or if there is a Debian specific alternative. For the time being, the device in which I need this function to work is my Dell E6410 laptop with an Alps pointing stick which is drifting. By default this is enabled alongside the touchpad, so you can use either of these devices, but there is no simple way to disable the touch stick, even if you plug in a USB mouse as I often do.

The answer for when the Xorg display server is used (generally this is the default display server based on X11 for many years, that is now gradually being superseded by Wayland) is to change the configuration settings in a file that is stored in /usr/share/X11/xorg.conf.d/ and in this case the file name to be edited is 40-libinput.conf . In order to effect the disablement, the xinput list command was first used to get the name of the touchpad device, and then this section making use of that name was added to the bottom of the aforementioned file:

Section "InputClass"
        Identifier "disable touch stick"
        MatchProduct "AlpsPS/2 ALPS DualPoint Stick"
        Option "ignore" "on"
EndSection

So that section in the file is pretty straightforward. The MatchProduct entry contains the exact device name string that we got from xinput list and the Option specified "ignore" "on" tells the Xorg server to ignore the device and not enable it.

After doing a reboot the touch stick was found to be out of operation and the xinput list command no longer lists this device.

As I noted in my previous post, the flaky touch stick on this laptop has been a significant issue since it will cause the mouse pointer to drift across the screen quite randomly even when an external mouse is in use and possible options to disable the touch stick at a hardware level (there is for example a Bios setting that in theory would disable it with an external mouse connected) have not worked so far. I did not investigate any possibility however of physically disconnecting the device inside the laptop, but I believe this could be quite difficult as the touch stick is physically located between the keyboard keys and thus it is probably at a hardware level integrated into the keyboard itself and therefore could not be unplugged.

Having this option to disable the touch stick is proving extremely useful since the laptop is otherwise in very good condition for its age and with the installation lately of a 160 GB SSD in place of the regular hard drive and the replacement a few years ago of the original battery, with the limited amount of use since then meaning the new battery should still have at least 90% of its life left, if carefully looked after it will keep going for another decade probably.

I am guessing this xorg.conf.d file entry will work with most distros (including Debian) even if xinput command doesn't work on some.

Lubuntu 19.04 with LXQt

It should generally be known by now that the Lubuntu project, which produces a version of Ubuntu that utilises the LX desktop environment for low resource usage, has switched from LXDE to LXQt in its more recent releases. The use of LXQt provides for a refreshing modern interface design in this application and for me, it makes it possible to consider LXQt based distros as being a worthwhile replacement for XFCE, which is falling too far behind in development.

Although these days I prefer to use Debian as my base distro and install one of the desktop environments provided by the installer (KDE, XFCE and LXQt are all available in Debian 10, along with several other environments), for some of my computers extra hardware drivers such as for Wifi simply make it more convenient to install a Ubuntu-based distro that has these drivers built in. An example would be the NUC and the R500 laptop. 

The Lubuntu installer is very straightforward with a smooth GUI that breaks down the installation steps into a small number and it installs very quickly from the DVD ISO image on a pen drive.

The best part is that it works flawlessly compared to my experience of missing GUI interface tools for network connections in Debian 10/LXQt. The connection manager supplied in Lubuntu is interesting in that it uses a text based interface to set the parameters, but everything worked exactly as it should have for the requirement of a wired connection only working on the local network and a wireless connection for Internet. It would seem in the Debian installation I may have had two connection managers conflicting with each other but this is difficult as there was not any installed by default and I had to find which packages to install.

I will be using Lubuntu more in future on the wireless devices that I only use occasionally and on VMs where I need to test against a Ubuntu based distro so that I don't need to use up too much resources in the host system. LXQt while still at version number 0.1x has had a fair bit of updating lately since the earlier version that I installed over XFCE on systems for testing and then ended up discarding because of too many missing features so it is good to see this progressing and becoming more user friendly.

Ubuntu Touch may step in where Firefox OS finished....maybe?

We certainly have a strong case for an alternative to Android because we should get a choice to be free of Google's massive data collection infrastructure that is tracking everything we do and everywhere we go with our phones. Revelations for example that Android 8 screen scrapes every app in the system are mind boggling. I have by choice switched my PCs to Firefox Aurora as the main browser and regular Firefox as a secondary, dropping Chrome for nearly everything, but I still use a lot of Google accounts on my computers. On the Android platform the scope is there for a much more universal collection of data by Google even as the European Union looks at more stringent penalties and regulations to force Google to cut back the scope of its data mining.

Ubuntu Touch is these days more of a community effort compared to when it was officially funded by Canonical. Firefox OS looked good for a while and it's a shame it was dropped. UT does look like it is gaining ground but of course is limited by the degree to which it can be adapted to a very large number of different hardware specifications. So far not many pieces of hardware are supported.

Or of course one can go back to the "dumb" or feature phone I guess....

KDE remote desktop sharing

One of the best things about KDE is the amount of apps they have available that are integrated into the shell. As XFCE lacks its own remote access integration you have to install x11vnc and muck around trying to get it to run as a service which I have yet to be able to complete. In KDE you have several apps available, I chose to use Krfb (RFB is the protocol that VNC uses) and it comes up as "Desktop Sharing" which is essentially the correct description of what I want to achieve.

With just a few clicks I was able to enable the desktop sharing and also enable it as unattended because I want to be able to connect to this desktop all the time without having to go to it to authorise a connection.

It will be interesting to see how Plasma develops in its latest high efficiency optimisation. It is quite possible some of my computers will be switched to KDE instead of XFCE but there is no huge rush as I just want to spend some time figuring out how everything works with KDE. Most of my PCs are fast enough to have few issues with the somewhat greater resource use in KDE and I will be keeping Debian as the base OS, no more Ubuntu for now. 

The only real thing with the Debian install of KDE is the clunky default logon theme which you'll want to change to the Breeze logon, for which you have to install additional packages. I last had a play with the Breeze logon when I had LXQt on one or two of my computers. Incidentally LXQt is now an option to install in the Buster alpha and the next release of Lubuntu will use it by default.

One of the reasons KDE looks good is because they are making steady progress towards integrating Wayland, something XFCE is falling further and further behind on. Pretty soon Wayland will replace X11 as the default display protocol and then some of the Linux desktop environments will not support it very well. Interestingly enough Ubuntu 17.10 installs Wayland by default (Xubuntu doesn't, so I won't have seen Wayland on anything yet). In Ubuntu 18.04 they reverted to Xorg after discovering Wayland still has some issues.

Mainpc at the moment is getting reinstalled with Debian and KDE because some sort of stupid crap bug resulted in an apt autoremove command removing a lot of core install packages including all of LibreOffice and some essential stuff, basically stuffing the system and making it unable to connect to the internet. So Debian 9.5 will be on it along with KDE and this will be only the second time I have tried KDE on one of my major computers that I use every day. This time hopefully I can make it stick (last time it was too hard to migrate from XFCE).

How to set a custom display resolution in Xubuntu

This is the way to mirror my pair of screens on my bedroom PC. One screen is 1360x768 (a little odd) and the other is 1680x1050. The default mirroring in XFCE will only run them both at a 4:3 resolution like 1280x1024, since this is the highest resolution they are both compatible with, even though the aspect ratio is wrong and so a part of the screen is not actually used.

x.org server ships with a command line tool called xrandr. This is capable of changing the display settings on the fly and in this case the command we want is either of the following:

xrandr --fb 1360x768 --output VGA-0 --mode 1360x768 --scale 1x1 --output HDMI-0 --same-as VGA-0 --mode 1680x1050 --scale-from 1360x768

Alternate form (which I also tested): 

xrandr --fb 1680x1050 --output HDMI-0 --mode 1680x1050 --scale 1x1 --output VGA-0 --same-as HDMI-0 --mode 1360x768 --scale-from 1680x1050

Which one you use will depend on which screen it is more important to run in native mode. At the moment I am using the first option, as it gives a native size picture on the 1360x768 screen which is the easiest to read bedside screen. The important difference over what xfce4-display-settings can achieve is that one of the screens can be scaled to match the other. It would also be possible to have some oddball configurations like three displays with two of them an extended desktop and one mirroring one of the others.

Running this command only lasts as long as the next boot. In order to make it come into effect at every startup it needs to be put into a file that the LightDM window manager executes when it initialises.

In this case, after looking at the Ubuntu documentation over here on the wiki, I made a file in the path /etc/lightdm/lightdm.conf.d and called it 50-myconfig.conf

The contents of this file are just two lines:

[Seat:*]
display-setup-script=xrandr --fb 1360x768 --output VGA-0 --mode 1360x768 --scale 1x1 --output HDMI-0 --same-as VGA-0 --mode 1680x1050 --scale-from 1360x768

Basically display-setup-script is a prefix that tells LightDM to run this command after it starts the X server, and then it is the xrandr command I mentioned above.

Just as an aside, right now I am looking at putting MainPC to Debian 9.1 with XFCE as the front end. The issues to be resolved will be how to get a more up to date version of XFCE than the default from the Debian repository, this will probably entail using the unstable repositories. This will all be tested out in a VM before migrating. No other computers are planned to be shifted, it is mostly about getting the best system on a PC that is used for the most work I do.

[UPDATE] When I reinstalled the bedroom PC with Debian recently I had to put this setting back in to the computer. The PC is also using XFCE as its GUI and the settings were the same, except I put the display-setup-script line into /etc/lightdm/lightdm.conf file. An interesting twist was I had to install some extra packages for Radeon drivers before Xrandr could detect the display settings and ports properly. Since there have been questions over video performance on this computer with late releases of Xubuntu it will make an interesting comparison. Although, this tiny PC is to get a makeover soon with a Asrock Q1900 board that will run Intel chipset and graphics which will help a lot because of better support in Linux.

Capturing video in Linux / Video resizing / DVR recording

Simple Screen Recorder is a great Linux software package that can be used to capture video from the screen. I set up my media PC to use it after connecting a second screen to use as the control screen for all applications (in other words, the application itself runs on the control screen while the video to be captured is playing on the main screen). I tested it out by capturing a Vimeo video clip and a clip from iTBN which has all the Hillsong Channel previous content available for playing. Both of these worked quite well. The iTBN clip included a Christine Caine message from Colour Conference 2016. As the videos for this conference are no longer available from Hillsong I may look to capture more of them from iTBN if anyone I know wants them for any particular purpose. This particular one was played on Colour Conference Main Stage on Hillsong Channel earlier this week, but for some reason these Mainstage clips aren't being repeated throughout the week so I was pleased to be able to find it on iTBN.

DVR recording is something I have begun to do with my satellite box. It has 16 GB of internal memory available for recording programs and I used it this week to record part of "The Story" broadcast on Hillsong Channel. I prefer to use a USB stick plugged into the front USB port of the box to record onto. The resultant .ts file can simply be renamed as .mpeg and then imported into an editing program like AviDemux. The main issue then is that the aspect ratio of the source video needs to be fixed.

In AviDemux the file from the DVR turned out to be too high vertically (rather common to see with video playback but not at all desirable) so configuring it to resize to 840x484 as I found on a tutorial on Youtube fixed the problem and put the aspect ratio back correctly for when I play the clip in Kodi. The "Story" clip had a 6 1/2 minute segment from when Hillsong United visited a Syrian refugee camp in Lebanon as part of their "Of Dirt And Grace" project in the Middle East in April 2016.

I am now getting the maximum usage out of my satellite box by connecting it to a second TV and speakers in the bedroom. I first experimented with having a fourth computer in there with the same TV as a display. This was OK playing the Hillsong Channel from iTBN except for the video being slow and the computer generally challenged because of its slow speed (it is one of the AMD E350s). As I had already put a network cable through the wall I decided a better option was to have a analogue video cable and sound cable through from the satellite box making the most of the multiple outlets on the box. This also meant making use of the second discrete audio output and running it through the CYP digital to analogue sound converter that I purchased last year. So the box has the maximum number of cables connected to it to drive all the different devices. The picture on the TV in the bedroom, while made with an analogue composite cable, is still way better than with a computer playing iTBN in a web browser because it is good quality and doesn't have jerky video or problems when the network speed is slow. The sound is also better quality. So I have dispensed with the fourth computer and now just back to three computers in the lounge.

For social media I now have the Vodem that I plug into my Windows 10 PC when I want to access Instagram etc with my tablet share SIM. This computer is really being annoying because unlike the other Windows 10 computer I tried the Vodem on, it won't redetect the Vodem when it comes back up from hibernation, so I have to keep unplugging and replugging the Vodem to use it.

UPDATE:

• The Vodem is being detected as a Remote NDIS thingy when the computer comes back from hibernation/restart, all you have to do is to enable and disable it.
• Since writing the original post about using captures I have discovered that the incredible youtube-dl software will work with both the Vimeo and iTBN sites. So both of the above mentioned videos could be downloaded from their respective sites and no screen capture was necessary. (Since about the fourth week in April however iTBN has a new site format that does not work with youtube-dl)
• Computer 4 (the AMD E350 in the Antec mini chassis) has gone back into the bedroom not to play iTBN over the internet, but to enable videos to be played there. Instead of using a network cable connection it is using wireless.
• I have found out how to save Instagram stories with a Chrome app. How to save Instagram videos is a mystery - youtube-dl allegedly supports them but I can't make it work. Fortunately I can play them in a web browser, which means I can use SimpleScreenRecorder on a VM running Xubuntu on the computer that has the Vodem plugged into it.

Android desktop options

So after my last post I have had a play with Android x86 on the Linux PCs with very mixed results. Quite why Facebook finds it difficult to support the desktop / browser based version of Instagram with the ability to post images is hard to fathom considering how well they have made Facebook work on the browser (better than a lot of apps) and clearly the only reason Facebook bother continuing to support Instagram is to ward off competition in the mobile app marketplace.

The biggest issue with Android x86 is that the developers have given it a landscape orientation by default and Instagram will auto rotate this into portrait which means you actually have to have a screen you can physically rotate or have hotkeys to turn the screen sideways itself. That is partly the reason I have wanted to run it on Windows where the hotkeys are well supported. I am not sure about Linux support for screen rotation hotkeys. Androidx86 has some hotkeys that will sometimes rotate the screen, sometimes not. So turning the screen or pressing the screen rotation hotkeys seem to be the only realistic options.

The other option is if the developers come up with something that will allow you to choose a landscape orientation by default. I have also tried this with changing video modes but wasn't able to find something that the version of Android itself could cope with so I guess I will be talking to them to see what can be done. Obviously I am quite keen to be able to post in Instagram from my PC without all this having to switch to a handheld to post on IG. But there are pros and cons to the different approaches and I have got around it up to now by composing the posts in Google Docs and then pasting that on the phone. And that approach does have its advantages particularly as you can review the document's character count which has to be held under 2200.

At any rate upgrading the Windows PC will go ahead, and I think putting Windows 10 on it is a highly likely outcome as well. Having Windows 10 means I will also have to buy a Pro license for it sooner or later since I have to migrate off using schools' licenses at some point. Whether the Windows computer when upgraded is going to be good enough with Androidx86 is something still to be tested out. Right now I am going to be probably keep using a handheld with Google Docs composition on the PC which has been very productive (and transferring images using Bluetooth). It is not really that hard and almost makes it unnecessary to have Androidx86 considering the hassle involved with that platform.

Linux RAID-1 [9]: Removing an array

The last step having set up a new array is to remove the old one from the computer. This is relatively straightforward.

Firstly the array has to be unmounted, which is a simple umount command with the path, in this case umount /oldhome. The next thing is to run a mdadm command to remove the array from the disk.

mdadm --manage --stop /dev/md0

is the command that will stop the running md0 RAID array.

Then another command removes the array:

mdadm --remove /dev/md0

Final action is to remove the superblock on the individual disks (only one disk present in this case as the failed drive has already been taken out of the computer):

mdadm --zero-superblock /dev/sdd

We also need to remove its entries from /etc/fstab  and from /etc/mdadm/mdadm.conf

At this point GDU is showing me the disk is just a disk with nothing on it, it still shows "Block device /dev/md0" however, I have not got much of an idea whether that will just disappear the next time the computer is restarted, I assume it will.

Linux RAID-1 [8]: Setting up the replacement array

As I mentioned last time I have bought the 2 TB disks so that I can have a RAID-1 array in the main computer that is big enough to hold all of my stuff, meaning the second computer (and by extension, its screens and desk) will be effectively redundant. So here I am essentially repeating the steps of the earlier instruction sequence of the previous articles in this series.

After backing up my stuff, I shut the computer down, found the faulty disk from the 1 TB array and removed it from the PC. The other half of the array was left in the computer and reconnected while the two new disks were put into the other bays. With everything plugged in the computer was turned back on again and should have come back up straight off but it was not so easy as the 1 TB disk was now plugged into a different port, so a mdadm --assemble --scan command sequence was needed to get the 1 TB array back online. After another reboot everything is now where it is supposed to be so /home is back going again, and the two new disks are ready to be made into a new array.

The new disks are /dev/sdb and /dev/sde this time, so first thing to do is to partition them, using gnome-disk-utility, with one partition on each disk. Then we issue this command to create the array:

sudo mdadm --create --verbose /dev/md1 --level=mirror --raid-devices=2 /dev/sdb /dev/sde

After that we can see that /dev/md1 is online in GDU. Now have a look at /proc/mdstat and it tells us that /dev/md1 is resyncing and will be finished in about three hours. This does not preclude it from being used, however. So our next step is to format the 2 TB partition, mount it and then rsync the existing home drive to it. At the same time we can start to move data across from the 2nd computer, but before we do that, the 2nd computer needs to have its own local backup, so that is also started with another rsync.

Next is to save the details of the array for mdadm 

mdamd --detail --scan >> /etc/mdadm/mdadm.conf

I then rebooted and on running a blkid see the new array renamed to md127. Then we put it into /etc/fstab as the mount point for /home, and change the old disk to /oldhome. So the fstab first looks like
# <file system> <mount point>   <type>  <options>       <dump>  <pass>
UUID=f49e5734-6c56-4f17-81b1-6423e4045e75 /               ext4    errors=remount-ro 0       1
UUID=cd9d465e-5574-4afd-85a6-851ace3959b7 none            swap    sw              0       0

UUID=6f1ea562-fb78-44ea-9262-d4234886064d /home           ext4    defaults        0       2

and now it will look like

UUID=f49e5734-6c56-4f17-81b1-6423e4045e75 /               ext4    errors=remount-ro 0       1
UUID=cd9d465e-5574-4afd-85a6-851ace3959b7 none            swap    sw              0       0
UUID=6f1ea562-fb78-44ea-9262-d4234886064d /oldhome        ext4    defaults        0       2

UUID=dfc4fa75-63e1-49ad-9a82-d9d0b826db3f /home           ext4    defaults        0       2

Now reboot is the simplest step to follow next. On coming back up after the reboot, everything is mounted correctly and some simple checks show that stuff is where it's meant to be.

In this case the final step is to move - over the network - the files from the 2nd computer. Leaving it only with the VirtualBox and Google Drive folders in its home drive for when I do my study in there. At some point in the future I will remove the md0 RAID array and its disk from the system.

The relocation of data from both sources was completed during the day and during the next night all of the data from the old 1 TB array (oldhome) was again copied into the 2 TB disks, this time as a move rather than a copy, in order to clean up the 1 TB array, the new array having proved its operational capability. Actually this is what I should have done the first time instead of rsyncing from oldhome to home. The hidden folders (dot folders) on oldhome will get moved into a backup folder rather than pasted over into home as a lot of contents will have changed unlike the visible folders.

Linux Kiosk computer with Chrome Browser [2]

So my steps followed are:

1. Install Ubuntu Server 14.04.5 from a bootable pen drive
2. Set my username to user with a password
3. Enabled automatic updates
4. Install OpenSSH server in the tasksel at the end
5. Reboot
6. Log or SSH into the system (latter from another system is preferred since you can copy and paste instructions from this web page)
7. Install some packages:
1. sudo apt install --no-install-recommends chromium-browser
2. sudo apt install  --no-install-recommends xorg openbox pulseaudio
3. sudo usermod -a -G audio $USER
8. Edit the kiosk.sh file:
1. sudo nano /opt/kiosk.sh
2. Enter the following lines:
   #!/bin/bash
   
   xset -dpms
   xset s off
   openbox-session &
   start-pulseaudio-x11
   
   while true; do
   rm -rf ~/.{config,cache}/chromium/
   chromium-browser --incognito --disable-background-mode --disable-sync --start-maximized --no-first-run 'http://www.example.com
   done
3. Ctrl-O to write the file then Ctrl-X to exit
9. sudo chmod +x /opt/kiosk.sh to make the script executable
10. Edit the kiosk.conf file:
1. sudo nano /etc/init/kiosk.conf
2. Enter the following lines:
   

   start on (filesystem and stopped udevtrigger)
   stop on runlevel [06]
   
   console output
   emits starting-x
   
   respawn
   
   exec sudo -u user startx /etc/X11/Xsession /opt/kiosk.sh --
   
   

3. Ctrl-O to write the file then Ctrl-X to exit

11. sudo dpkg-reconfigure x11-common and select "Anybody" can start the X server
12. try sudo start kiosk for testing and away it should go (or reboot)
13. Change grub configuration to hide startup messages:
1. sudo nano /etc/default/grub
2. Find GRUB_CMDLINE_LINUX_DEFAULT and put quiet splash inside the quotes.
3. Ctrl-O to write the file then Ctrl-X to quit
4. Run the command sudo update-grub
5. Reboot to test

I am still looking at whether to clone the disk to copy it to another computer. It looks complex to do this, because we really want to be copying a whole disk (two partitions) instead of just a partition at a time.

Chromium policies are also a possible scenario as referred to in the previous post.

There is some OpenBox stuff we want to change, particularly the number of virtual desktops offered and the right click menu that we don't want. Only one virtual desktop and disable the popup etc.

To do this copy /etc/xdg/openbox/rc.xml to /home/user/.config/openbox and then use nano to edit the latter. Look for the <desktops> section to set the number of desktops to 0, look for <keybind>s that relate to switching desktops, and look for a <mousebind> for a right mouse click that relates to the root menu to get rid of the right click menu.

Linux Kiosk computer with Chrome Browser [1]

Here is an option for making your own "Chromebox" out of some old PC you have lying around. It lends itself well to educational scenarios with old computers that are too slow to run a modern operating system, but which can be perfectly satisfactory for the Chrome browser to run Google Apps etc.

I am going to build up a test system using these instructions and then perhaps clone it to see how easy it is to set up a bulk lot of computers for this scenario. It is certainly a more viable option to use Ubuntu instead of Chromium OS. The latter has limited hardware support and every time we have tested it on regular desktop computers we have run into some sort of issues with it. Consequently just using regular Ubuntu has a lot in its favour. In this case the server version because it is very easy to customise exactly what is installed and therefore limit it to just the bare minimum.

Therefore I started with downloading Ubuntu Server 32 bit 14.04 and making a bootable pen drive for my test computer. In practice the computers it is going to run on are HP DC7100 PCs with 256 MB of RAM and a HDD of 40 GB or less. These computers have only a 32 bit CPU and cannot run 64 bit OSs. With the ISO image I downloaded I used the USB Image Writer tool in Mint to put it on the pen drive for the test computer. The system was then booted and came up in a text mode installer. The disk was partitioned into 1 GB of swap and 9 GB of ext4 mounting to /. The server operating system was then installed with the exact same options specified in the article. It was then allowed to reboot and came up normally.

The main difference from the article is that since it was written, Google has dropped 32 bit support for Chrome for Linux, which means I had to switch to Chromium instead. The biggest problem with Chromium is lack of support for Adobe Flash. But we hope that Flash isn't a problem in Google Apps. And also I didn't want to use Kiosk mode. So I changed some flags. My command to start the browser in /opt/kiosk.sh looks like this instead:

•   chromium-browser --incognito --disable-background-mode --disable-sync --start-maximized --no-first-run 'somewebsite'

incognito is necessary to stop the user settings (including being logged in) being saved when the browser is closed, so the user gets logged out automatically of the browser. It also wipes history etc. This is a relevant thing when the same computer is being used by multiple Google Apps users so that they don't get the history etc of the previous user. In our case with the use of web filtering, they will still be logged through the web filtering system so we have a record of their usage.

Once you have this thing set up fully as a "kiosk" you can use ssh to get into change settings and do stuff remotely.

Other things not mentioned in the original article:

• Disable function keys that you would press to get to a terminal for logon (because you can always SSH to the computer remotely)
• If you minimise the browser window then you will never see it again as there is no taskbar. But pressing Alt-Tab will bring it back.
• Downloading and so forth onto the local computer needs to be disabled. In other words that rm -rf command needs to be extended to some other local directories that stuff could end up in, otherwise the disk space can fill up when you don't want it to.
• Chromium policies may be useful to set in addition to the kiosk settings. See links below.

I will post a complete list of steps taken to set up the kiosk in my next post.

• https://thepcspy.com/read/building-a-kiosk-computer-ubuntu-1404-chrome/
• https://www.chromium.org/administrators/linux-quick-start
• https://www.chromium.org/administrators/policy-list-3