Trisquel based Suda
**Note - this is not complete yet and is in the process of being edited.This note will be removed when I consider this to be finished and complete**
What is this ?
Caveats and parameters - all work on this and the subsequent Gnuinos versions of Suda are intended for personal or local network use. Though they are both fully functional as operating systems and fully installable they do not recreate the web based Suda experience other than in a local network situation in which they can be accessed via a vnc viewer (such as TigerVnc) or directly through a browser or for that matter just running on a local machine. All installations were created and tested deliberately on low end or older machines including a Lenovo Thinkpad T61 with 4gb of ram and a 2ghz core 2 duo processor, a Toshiba Satelite L500 from 2009 with 4gb of ram and a low end dual core Penryn based Pentium and an Acer Atom based Aspire E 15 start. I felt it was important to use low end machines and especially laptops as they quickly show problems with reproducibility due to the nature of Bios and hardware which may not show up in Virtual machines or desktops especially given the nature of completely libre linux distributions not including proprietary blobs and firmware drivers. I wanted what I came up with to run straight off the bat without needing interventions or too much specialist knowledge other than knowing how to change boot device.
This details my attempts and missteps in trying to recreate a system based on the Suda project using Trisquel 10. Suda is based on Parabola Linux and I have in the past managed to copy the same functionality (in a desktop system) using the latest Debian 11, but the problem with that is that Debian 11 is not fsf approved ie contains non-free firmware and software. As this project is based on using only fsf approved or fully Libre software and operating systems I first looked at Trisquel 9 which works perfectly as a drop in replacement for Parabola bar a non working noVNC (used to connect to Suda online or via local network via a web browser) due to outdated versions of websockify so moving on from Trisquel 9 I saw that Trisquel 10 had finally had an official release so upgraded the working Trisquel 9 to 10 but due to large amount of relics left over from that upgrade and signfigant difference sin structure I decided to start from scratch.
This is a 64 bit system as unfortunately Trisquel hasn't released an X86 version of Trisquel 10, though it is possible to recreate this system on Trisquel 9.0.2 which does have an X86 version. For older X86 systems Parabola works better (and the Gnuinos system which will be detailed elsewhere.
Download Trisquel from here https://trisquel.info/
One of the goals of the current Suda project was to build an iso factory so we could reproduce the whole system and install it via self built isos - this I achieved first on Trisquel 9 using a set of tools from a project based on Devuan Linux called Refracta find more information on the Refracta tool set here https://github.com/fsmithred (these work across most Debian based and Ubuntu based systems). I have successfully built isos and installed the complete system from those isos, these were created on Trisquel 9 and replicated all features , documents and functionality of the host system (a clone version) whilst giving the opportunity via the refractainstaller to change user name and password at install.
First I installed Trisquel 10 mini (lxde) on an Acer Aspire es1 512 c9qm (rocking a Celeron n2840 processor and Intel hd graphics with 4gb of ram) onto a samsung 120gb ssd using the default partitioning scheme (esp partition with two extra partitions for swap and / one ext4 one xfs), the Acer Aspire is set to boot in legacy mode (I wouldn't usually use that partitioning scheme but went with the defaults offered just to see how that worked)
So from that base I installed lxdm (LXDM is needed for simplicity’s sake and for the graphic error shown in the original Suda ie the repeating trails and errors exploited for glitch art purposes via the glitchify.sh shellscript). Lxdm and lightdm are both window managers, there are various ones in linux just to clarify and all of them have slightly different quirks lxdm being that bit older harks back to the times of editing xorg.conf files by hand and easily readable and parsable configuration files in sensible places. Trisquel and a lot of other distros ship with lightdm as standard but lxdm as stated is needed as it seems to be slightly lower resource than lightdm plus it matches the methods we used when using Parabola and as I found out later it has handy configuration files which are basically bash scripts which are useful for bringing up services or just auto-running scripts that Suda uses on login
After installing lxdm I reboot and then install ctwm. Unlike installing ctwm on Parabola there are very few problems (adding configuration files is the same) like most Debian based Linux distros I’ve used when installing ctwm it automatically pulls in dependencies like m4 (ctwm needs m4 otherwise it just won’t start) which parabola does not do which led to problems when I first tried to create my own parabola based Suda analogue for experimenting with before committing changes to the online version.
Why ctwm? Twm and ctwm (Ctwm comes out of twm) are lightweight and, unlike more modern desktop environments, they are very bare and stark and visually very appealing as well as being very very low resource, they look almost alien when compared to say Windows 10 or MacOS in ways which I think jar the user out of the established desktop paradigm.
Ctwms functionality is all configurable via a single easy to read and alter text file, unlike other later desktop environments, so adding clickable links to run shell scripts and program groupings becomes very easy just using a simple text editor. Originally we looked at twm but it didn’t serve our purposes well, it works but the original aim of using a low resource desktop environment to enable functionality and usability online (as Suda is an online collaborative environment run via the web) was better served using ctwm which can be seen as a successor to twm, mainly for click to focus, ctwm has click to focus and twm does not. Click to focus is important because when you spawn a terminal or program window and click on it your actions via keyboard or other input affect that window so if the mouse is moved then that window retains input focus unless you click the mouse elsewhere. Older desktop environments have hover to focus so where your mouse is becomes the focus of input - this is important when thinking about the manifesto.sh script which types out the manifesto over and over again in vim running in a terminal window. Without click to focus this can bring out very unpredictable behaviour, and whilst that can be fun, its good to know that you can bring it under some sort of control without the manifesto leaping across terminals and fighting over menus. A good overview of various older desktop environments can be found here http://www.xwinman.org/ and was in fact my main source when researching twm and ctwm especially for configuration files. This guide from Arch linux was handy as well for working out where to put configuration files etc https://wiki.archlinux.org/title/Twm
Interestingly on reboot having installed lxdm over lightdm the computer first brings us to a console login screen on tty1 and to get to the lxdm sign in screen you have to use the old ctrl alt f7 trick to switch to the standard tty7 default
graphical login screen (is there somewhere to change this and why does it do this when it doesn’t do this on Trisquel 9 or Parabola? - I did find a solution to that which I talk about later)
So on to ctwm - sudo apt install ctwm which pulls in librplay3, libsigsegv2 and m4.
As we found with Parabola, before using ctwm first we have to create a configuration file, .ctwmrc and place that in our home folder. Then we have to create a ctwm.desktop file in /usr/share/xsessions as root, otherwise it won’t register in the lxdm sessions menu at the login screen. I created that on Parabola using guidance found here https://wiki.archlinux.org/title/Twm so having done that, I’ll logout of lxde and into ctwm just to see if those configurations work.
And logging into ctwm for the first time we see the problem I had when trying to recreate Suda as a standalone for myself for experimental purposes. The scaling and fonts are wrong. So I will have to install unifonts and a few other fonts to get everything looking right (especially important online given that Suda online has a screen resolution of 1024x768) so in synaptic if we search for unifont (which is what we need) we find psf-unifont, ttf-unifont and unifont itself which also pulls in xfonts-unifont. Having opened the file manager pcmanfm in ctwm also makes me realise that I have to change the icons to adwaita as well ( easier to change that in lxde though) so having installed those fonts I will log out and back in again to make sure everything is looking right.
After logging back in and checking fonts and window decorations are now scaled and looking right, back to lxde desktop to find and install the next stage ie the three shell scripts that give us the basic look and feel of suda running, ie sudacam, glitchify and manifesto - for these to work correctly I’ll also need to install a few other packages like ffmpeg, smplayer audacious and a few other command-line tools. oh yes and alter those damn icons. the three shell scripts are just placed in the users home folder and made executable (the lazy way, right click, properties, permissions, allow executing by anyone)
Then sudo apt install ffmpeg smplayer audacious gimp gmic audacity sox mc gdebi yad build-essential nasm yasm xosview x11vnc gparted xdotool
One of the differences between Debian based distros and Arch based distros, (Trisquel is based on Ubuntu which is based on Debian, Parabola is based on arch Linux), is how they handle package management, some of Sudas functionality is based on obscure tools like xsetroot and xdotool, tools from the dawn of time and a different era in Linux when setting up a desktop environment was more granular and gritty and hands on, Parabola packages certain of these tools seperately which is sometimes non-obvious (such as m4 needed by ctwm to run ), Debian based distros tend to have complete collections which are bundled together (on Debian based distros xsetroot and tools like xwininfo (handy for working out geometry of windows and placement to put into shell-scripts using terminals and windows) are bundled with the package x11-xserver-utils which is generally automatically installed with a base installation and xorg, on Parabola you install each one individually)
gdebi is needed for the next phase (after installing everything needed for suda itself to run) for the ISO factory.
So now having checked in ctwm that we get the nice glitchy trails in ctwm when running the glitchify.sh script (we do) I move on to installing and checking the next phase, can I install and use the refracta tool set. When building the Trisquel 9 based system I found two of the dependencies are unsatisfiable via the Trisquel 9 repos so I sourced two dependencies from the Debian Buster repos, these worked on Trisquel 9 so I’m hoping they will on 10, as one of the main goals of Suda is that its reproducible, shareable and installable. These as well as a few other packages can be found in the /home/crash-stop/Downloads folder in the live and installed versions, refracta tools are in /home/crash-stop/refracta tools, In Documents are various files and this document.
Earlier we installed yad so we don’t need to deal with that so then we will install the two dependencies in the addenda for systemd dependencies folder in the refracta tools folder first using gdebi but on firing up gdebi I discovered that Trisquel 10 already has live-config in its repos, extra bonus it pulls in live-config-systemd as well (the other dependency for the refracta tools- the list is
live-config live-config-doc live-config-systemd live-tools user-setup)
Now lets install the refracta tools in order, first refractasnapshot-base_10.1.1_all.deb which requires an extra seven packages to be installed - isolinux, libisoburn1, live-boot, live-boot-doc, live-boot-initramfs-tools, squashfs-tools and xorriso (Which gdebi pulls in and installs). And then to make any iso we make installable we install refractainstaller-base_9.3.3_all.deb (which can be called via a terminal from a live instance running from usb or dvd).
before installing anything else I’m going to test if we can make our iso. Opening an lxterminal and running sudo refractasnapshot should work (and follow the instructions it gives carefully, pressing the enter button to page down)
at which point refractasnapshot craps out after asking what we want to name the distro even though that works on the previous installation via a Trisquel 9 to 10 upgrade, weird!
this message appears
Warning: Kernel image is missing.
Warning: initrd image is missing.
Make sure the kernel_image and/or initrd_image
set in the config file are correct, and check
which would mean maybe the config file is looking for those two in the wrong place as this is on a different partition system to previous install or that Trisquel 10 stores the files in a different location to Trisquel 9 ( which didn't have the esp partition)
Do I need to alter /etc/refractasnapshot.conf to make this work?
yep it works if you alter this part in /etc/refractasnapshot.conf to this
# Change this if you want the live system to use other than the default
# kernel and initrd. You may need to edit the isolinux boot menu to
# match the filenames. (Also see custom boot menu section below.)
# Example: for kernel_image="/boot/vmlinuz-3.16.0-4-amd64" then the kernel
# line in the boot menu would contain:
# kernel /live/vmlinuz-3.16.0-4-amd64
#
# (Defaults are /vmlinuz and /initrd.img)
kernel_image="/boot/vmlinuz"
initrd_image="/boot/initrd.img"
so having verified this works and boots we can get onto the next stage does it install. welllll we'll find out it in a moment but once it does we move on to getting local network access via x11vnc, and browser access via novnc.
web access (local network only in this version) soooooo you will need to download novnc for the web part, x11vnc takes part of the vnc part itself we installed that earlier. so fire up a terminal and do this
(all vedrans work here)
leave that terminal running and if you want to test ssh ing into this computer via a second computer ( on the same network) just note down your ip address for this computer , open a terminal on a second computer on the same network and ssh this computer if you get asked for a password and get access, all is good, you could also try using vncviewer as well
The next step is getting novnc downloaded and running
to use novnc we need to download novnc and install a self signed certificate.
to do that do this (you need git installed to download if using git)
git clone https://github.com/novnc/noVNC.git --depth 2
cd noVNC
(in the novnc folder or if you do this elsewhere move the generated ssl certificate into your novnc folder)
# Set up SSL
openssl req -x509 -nodes -newkey rsa:2048 -keyout novnc.pem -out novnc.pem -days 180
leave that terminal
sudo apt install websockify which pulls in python3-numpy and python3-websockify as dependencies
then in the novnc folder run
./utils/novnc_proxy --vnc localhost:5900
TO TEST work out what the host ip address and hostname is then on a separate computer on the same network open a browser window and go to this address
http://hostip:6080/vnc.html?host=hostname&port=6080
so if all that works you will now have access to this computers desktop via web browser
BUT what if we want to have all of this start up at boot so we don’t have to mess with messy scripts, but also have password security for access as well ?
after much tooing and froing i found this guide:
https://jasonschaefer.com/setup-x11vnc-server-with-systemd-auto-start-up/
which basically walks through the process simply and excellently and it works so that’s what I did:
make sure you have x11vnc installed ie do
sudo apt install x11vnc
and openssh-server
create and store a password that only root can change
sudo x11vnc -storepasswd /etc/x11vnc.pwd
create this text file and open it
sudo texteditorofyourchoice /etc/systemd/system/x11vnc.service
put in this text:
[unit]
Description=Start x11vnc at startup.
After=multi-user.target
[Service]
Type=simple
ExecStart=/usr/bin/x11vnc -auth guess -forever -loop -noxdamage -repeat -rfbauth /etc/x11vnc.pwd -rfbport 5900 -shared -o /var/log/x11vnc.log
[Install]
WantedBy=multi-user.target
save that and thats it.
then enable the service by doing
sudo systemctl enable x11vnc
start it by doing
sudo systemctl start x11vnc
check it by doing
systemctl status x11vnc
that works if someone ie the default user ie me - crash-stop is logged in on the host computer but what if we want to be able to access the graphical login screen via vncviewer or novnc?
we can change the above configuration file and instead do this (from here
https://askubuntu.com/questions/229989/how-to-setup-x11vnc-to-access-with-graphical-login-screen/) with slight modification to this
[unit]
Description=Start x11vnc at startup.
Requires=display-manager.service
After=display-manager.service
[Service]
Type=simple
ExecStart=/usr/bin/x11vnc -auth guess -forever -loop -noxdamage -repeat -rfbauth /etc/x11vnc.pwd -rfbport 5900 -shared -o /var/log/x11vnc.log
[Install]
WantedBy=multi-user.target
And this works!! I have this working via ethernet and wifi now but if we log out of that account then the tigervnc viewer or vncviewer exits (why ?).
Now could we do the same for novnc?
I placed noVNC folder in /usr/share and added the vncup.sh script in /home/crash-stop/ and made that executable. If this works I might remove that folder from downloads. (vncup.sh points to the utils folder in novnc which is novncs script for bringing itself up)
Create a similar file to x11vnc.service called novnc.service but point it at the vncup.sh shellscript to start the service on boot, the file itself ends up as a symlink (and can be edited and saved there) in
/etc/systemd/system/multi-user.target.wants/
Then with all of that working we can go onto the next step installing to a second computer
That step worked, I installed a working system from the live image created using refractasnapshot and burnt to usb stick (formatted to fat 32 and boot flag marked using gparted) using balena etcher on the source computer. Booted target computer succesfully from usb stick logged into live Trisquel mini desktop then ran sudo refractainstaller from lxterminal, followed prompts no install problems rebooted and system was all as on original host system.
next problem was that annoyingly after changing the display manager from lightdm to lxdm (necessary cos its light weight and exhibits the glitchy behaviour seen on original suda on Parabola when using ctwm and subsequently on any systemd based linux distro including Debian and Pureos when running ctwm) when booting the computer you get faced with a virtual terminal tty1 rather than the login screen of lxdm (traditionally on tty7) looked up this problem online via arch linux forums and found this article:
https://bbs.archlinux.org/viewtopic.php?id=212979
which hinted that the problem might be this line in /etc/systemd/system/display-manager.service
'Conflicts=getty@tty7.service plymouth-quit.service’ by commenting out that line with a #
on reboot behaviour reverts to what we would expect ie not tty1 and command prompt but lxdm graphical login screen.
but it turns out that if we comment out that line what happens is yes we get the login screen without having to switch from tty1 to tty7 manually and can proceed but we lose the glitchify.sh functionality which is important to the look and feel of Suda itself , it took half a day to work this one out and in fact I tried a few different ways altering display-manager.service in different ways leading to needing to reboot in recovery mode and change that text file back. The real problem lay in the default.conf file in /etc/lxdm we need to uncomment a line in that file as root and save it ie this line:
in default.conf its ‘#arg=/usr/bin/X -nr vt1‘
change that to this arg=/usr/bin/X -nr vt7
and that fixed that problem and retained glitchify.sh function yea ! now to the other scripts.
The next problems are making sure the suda scripts themselves work in the chosen ctwn environment. so far I’m having problems with one script in particular, the sudacam.sh which calls forth virtual webcam like windows which show where the mouse points, the mouse acting as a camera. So far running the script as before on Parabola causes the display to lock up needing me to switch to a virtual terminal and restart lxdm itself using sudo systemctl restart lxdm. tried installing ffmpeg from source which didn't solve the problem ( and lost the ffplay functionality that I want) so reinstalled distros version. Running the command from the terminal in ctwm ie this ‘ffplay -f x11grab -follow_mouse centered -framerate 10 -video_size 640x480 -i :0.0' works, and the script executed in lxde rather than ctwm doesn’t lock up the display so maybe I just need to rewrite the script?
in the end for the sudacam.sh script i created two shell scripts sudacam1.sh and sudacam2.sh which have their own seperate menu entries in .ctwmrc under the suda menu heading as that was the only way i could find of calling the script without everything locking up.
minor annoyances, I'm running this development on a laptop, and Trisquel-mini doesn't want to play nice with my screen brightness so I've followed this guide
https://wiki.archlinux.org/title/Backlight#ACPI
created the file backlight.rules as per the guide in
/etc/udev/rules.d/
RUN+="/bin/chgrp video /sys/class/backlight/intel_backlight/brightness"
RUN+="/bin/chmod g+w /sys/class/backlight/intel_backlight/brightness"
and saved that (all as root)
so now i should be able to change brightness from the command line as these newer led screens are hard on my eyes at max brightness!
check your brightness cat /sys/class/backlight/intel_backlight/max_brightness
to adjust brightness control I installed commandline program brightnessctl which has to be run as root
man page has details of how to use it
And thats pretty much it ! Its not exactly how Suda works online but its a close analogy which is installable and shareable and runs from live and is accessible in a similar way to online Suda albeit only on a local network. If running from dvd or usb as a live disc make sure to be connected via ethernet to local network otherwise network functionality may not work - this problem doesn't happen with an installed system for reasons I am uncertain of.
To install permanently from a running live system open a terminal and type in ‘sudo refractainstaller’ and follow the instructions carefully.
After getting the Trisquel system running smoothly I then had to alter it slightly so that on live boot from usb or dvd it logins in to the default user automatically and then runs the main scripts which give Suda its look and feel ie glitchify.sh. sudacam1 and 2 .sh and the manifesto script. The next bit details how I went about that.
Getting the scripts to run after autologin
To replicate the look and functionality of the online Suda we want the scripts glitchify.sh, sudacam1.sh, sudacam2.sh and finally manifesto.sh to run after user login, I dont need to discuss the networking scripts x11vnc and noVNC as these are handled by systemd as services and started automatically.
The online version I seem to recall allows you to start the scripts via the right click menu but to get the look and feel we first have to change a few scripts in /etc/lxdm/ ( which becomes even more important in the Gnuinos version) where we will find the configuration files for the lxdm window manager. The first file we will alter is /etc/lxdm/default.conf ( as root or as a sudoer), look for the line which says '# autologin=dgod' and change that to the user to autologin (in the isos built by me the default user is always crash-stop) so we uncomment that line and replace it with 'autologin=crash-stop', now the desktop automatically loads on successful boot without needing to go through a login screen. Save and close that.
Next we open /etc/lxdm/PostLogin (as root or sudoer) and add in a line which says './glitchify.sh & ./sudacam1.sh & ./sudacam2.sh & ./manifesto.sh'
Now on login these four scripts will run and there is our suda desktop.
The final thing to alter I discovered had to be added to the Gnuinos versions otherwise if the user tries to logout the computer just returns a black screen instead of a login screen thats not a problem on trisquel as the window manager doesn't seem to break (gnuinos is nonsystemd, Trisquel is sytemd based), I haven't worked that one out so this alteration just restarts the window manager and autologin sequence. To do that find /etc/lxdm/PostLogout and add in this line '/etc/init.d/lxdm restart' - which restarts the window manager and starts the autologin process all over again.
If we wanted to install trisquel from the live disc as its running we could switch to a terminal via pressing ctrl+alt+f2 login as crash-stop and using the password 'zoostorm' which is the default password for all of the isos I've built issue the command 'sudo /etc/init.d/lxdm stop' (which halts the window manager) and issue the comand 'sudo refractainstaller' and follow the onscreen instructions. If you have already partitioned your discs your good to go or you could consider commenting out the lines added to /etc/lxdm/PostLogin and /etc/lxdm/PostLogout and restart the window manager (ie 'etc/init.d/lxdm start') if you prefer using a gui, open a terminal and type in sudo gparted, partition your discs using gparted then opening a terminal and running 'sudo refractainstaller' from there.
No Comments