KDE Plasma likes, dislikes, and would be nice to haves

With each new release of Ubuntu, I’ve stuck with the default desktop environment. These have worked well for me over the years, but thought I should see what else there is.

The only way for me to do it justice is to run KDE Plasma as my only desktop environment for a minimum of 2 weeks. So both my work station and my personal laptop are use KDE Plasma installed alongside Gnome 3 Shell on Ubuntu 19.10.

If I’m unhappy after the 2 weeks, I can always go back to Gnome. Or maybe try something else, like lxde or xfce.

I started on Sunday evening, and it’s now Wednesday afternoon. The following are my findings.

This is likely to be updated as I find new things or ways to fix niggles.

Likes

  • When an application shows in the “Task Manager” bar, one can click it to minimise the active window.
  • All icons showing in the “Task Manager” bar (Autokey is a GTK application, but can’t show its icon in Gnome 3, but manages to in KDE Plasma?).
  • Simple music controls on lock screen.

Dislikes

  • Even at max mouse sensitivity, it feels slower than on Gnome 3 – not good for a 3 monitor set-up – this may be subjective and not be an issue in time.
  • No option to locate the mouse cursor by pressing [ctrl].
  • Some windows don’t respond to a mouse wheel scoll until the window is clicked – this may be an issue only with GTK applications running on KDE Plasma.
  • Being asked for my SSH key in the terminal for every action – is there a key manager like in Gnome that I need to enable? Manually resolved by running `ssh-add` against each key required. Gnome does handle this a lot better 😐
  • Scrolling in an application window does not respond while a OSN is displayed – example: Spotify changing tracks

Things I’d like to see ported from Gnome 3 Shell

  • The option to only switch the central monitor when changing between virtual desktops.
  • Change between virtual desktops using [ctrl]+[alt]+arrow keys.

Things I’d like to see in all desktop environments

  • Option to have the cursor colour to invert as it passes over other colours – Windows does this.
  • Automatic window scaling based upon the native resolution of the monitor in use. If a window is moved from one monitor to another, and the resolution changes, the scale should adapt to keep it readable – Windows does this.

Embiggen .desktop loaded applications on Ubuntu

I keep forgetting the steps required for this, so thought I should write them up in one easy to remember blog post for myself.

My desktop set-up consists of 2 x 1080 and 1 x 4k display. Making sure that applications are readable is a bit of a farce.

But as long as I ensure that certain applications only ever appear on the correct monitor, means that I can alter the launcher to set the correct DPI scaling.

Case in point is the “thunderbird.desktop” launcher. I only ever use it on the 4k display (central monitor), so I can alter the launcher to pre-set the scaling to two times normal. Making it readable without squinting (I’m nearly 40 you know).

Using “locate thunderbird.desktop” we find that it’s stored at “/usr/share/applications/thunderbird.desktop”. So raised privileges will be needed to edit it.

“sudo nano -w /usr/share/applications/thunderbird.desktop”

Using “ctrl+\” to replace text, search for “Exec=thunderbird” and replace it with “Exec=env GDK_SCALE=2 thunderbird”. Use “ctrl+x” to save and exit the editor.

Now when the Thunderbird launcher icon is clicked, the application will be rendered at twice the normal size. Making the working day a lot less squinty.

apt-upgrade

I used to use a 2 command 1 liner to update my system:

sudo apt-get update && sudo apt-get dist-upgrade

That was easy enough to type out now and then. But over time it grew to include removing and cleaning downloaded packages as well.

Then there’s the matter of knowing if an update requires a system restart.

The lazy me put it all into one bash script and made it globally accessible and executable:

#!/bin/bash
apt update && apt full-upgrade && apt-get autoremove && apt-get autoclean
if [ -f /var/run/reboot-required ]; then echo && cat /var/run/reboot-required; fi

Placed it in /usr/local/bin/apt-upgrade  and made it executable with sudo chmod +x /usr/local/bin/apt-upgrade .

Now I can run sudo apt-upgrade on all of my servers and it’ll update things as well as letting me know if a reboot is required.

Most amusing spam received to date

Good morning...

Do not consider on my English, I am from Iran.I installed the virus on your system.After that I pilfered all confidential info from your OS. Furthermore I received some more compromising evidence.The most interesting evidence which I thieftend- its a record with your self-abusing.I adjusted malicious software on a porn web site and after you installed it. As soon as you picked the video and pressed play, my software immediately set up on your OS.

After loading, your web camera shoot the record with you self-abusing,  furthermore it saved precisely the video you watched. In next week my malicious software collected all your social and work contacts.

If you wish to delete  the videotape- transfer me 380 united state dollar in BTC(cryptocurrency).
I provide you my Bitcoin wallet address - [redacted]  

You have 22 hours from this moment. When I receive transfer I will destroy the evidence forever. Differently I will send the tape to all your contacts.

Sent 5 days ago to my work address, no less.

Guess I got away with it!

Unable to install sass gem on CentOS 6.9 with Ruby 2.4

Something changed recently, preventing a VM from fully provisioning. Tracking it down was a bit of a PiTA.

OS: CentOS 6.9
Ruby: 2.4 – installed from source with the gearlingguy.ruby ansible role
Gems to be installed: sass

$ sudo gem install sass
Fetching: rb-fsevent-0.10.2.gem (100%)
Successfully installed rb-fsevent-0.10.2
Fetching: ffi-1.9.21.gem (100%)
Building native extensions.  This could take a while...
ERROR:  Error installing sass:
    ERROR: Failed to build gem native extension.
    current directory: /usr/local/lib/ruby/gems/2.4.0/gems/ffi-1.9.21/ext/ffi_c
/usr/local/bin/ruby -r ./siteconf20180222-18730-x7wu2n.rb extconf.rb
checking for ffi.h... no
checking for ffi.h in /usr/local/include,/usr/include/ffi... no
checking for shlwapi.h... no
checking for rb_thread_blocking_region()... no
checking for rb_thread_call_with_gvl()... yes
checking for rb_thread_call_without_gvl()... yes
creating extconf.h
creating Makefile
current directory: /usr/local/lib/ruby/gems/2.4.0/gems/ffi-1.9.21/ext/ffi_c
make "DESTDIR=" clean
current directory: /usr/local/lib/ruby/gems/2.4.0/gems/ffi-1.9.21/ext/ffi_c
make "DESTDIR="
Running autoreconf for libffi
autoreconf: Entering directory `.'
autoreconf: configure.ac: not using Gettext
autoreconf: running: aclocal --force -I m4
configure.ac:3: error: Autoconf version 2.68 or higher is required
configure.ac:3: the top level
autom4te: /usr/bin/m4 failed with exit status: 63
aclocal: autom4te failed with exit status: 63
autoreconf: aclocal failed with exit status: 63
make: *** ["/usr/local/lib/ruby/gems/2.4.0/gems/ffi-1.9.21/ext/ffi_c/libffi-x86_64-linux"/.libs/libffi_convenience.a] Error 63
make failed, exit code 2
Gem files will remain installed in /usr/local/lib/ruby/gems/2.4.0/gems/ffi-1.9.21 for inspection.
Results logged to /usr/local/lib/ruby/gems/2.4.0/extensions/x86_64-linux/2.4.0/ffi-1.9.21/gem_make.out

The issue is with the ffi ruby gem.

Looking at the releases in github, a recent release updated the required version of autoconf installed on the system. Fine for modern systems, not so much for CentOS 6.9.

The solution is to install the ffi ruby gem with the version prior to this recent change:

$ gem install ffi -v 1.9.18

This then allows sass to be installed without complaint!

Setting up an On-Premise instance of Amon

NewRelic no longer offers server monitoring for free accounts, so what are the alternatives when you’re on a skin-flint budget?

There are lots, but I’m not going to review any of them. Instead, I’ve been tasked with getting Amon running on a DigitalOcean droplet so that it might be appraised.

Amon can either be used as a SAAS, hosted by Amon themselves. Or it can be run “On-Premise” by cloning the git repo to your own server.

The On-Premise instructions didn’t work for me as-is on a fresh Ubuntu 16.04 server. So I present to you here the result of getting it going!

Assumptions:

  1. You know what you’re doing with Linux on a server.
  2. You can create your own VPS, or have dedicated hardware, that will only be used for server monitoring.
  3. MongoDB is installed from Mongo’s repo, not Ubuntu’s.
  4. Let’s Encrypt is used for the SSL certificate.
  5. The FQDN used for accessing the Amon instance matches the server’s full hostname (easy enough to change by altering FULL_HOSTNAME).
  6. Postfix is used on localhost as the MTA (alter the content of /etc/opt/amon/amon.yml if that’s not to be the case).

The following took the instructions of https://docs.amon.cx/onpremise/ and then extended/tweaked them to create a fully working server.

So the initial script I wrote turned out better suited to being a collection of scripts. And to keep them together, I’ve created a new GitHub repo to house them.

If you find it useful, great! If you would like to help make the installation provisioning system better, PRs are very welcome 🙂

https://github.com/bigcalm/amon-server

Upgrading Jenkins war file the quick and dirty way

#!/bin/bash

set -e

if [ $# -eq 0 ]; then
    echo "New Jenkins version number missing"
    exit 1
fi

VERSION=${1}

set -x

cd /usr/share/jenkins/
wget http://updates.jenkins-ci.org/download/war/${VERSION}/jenkins.war -O jenkins.war-${VERSION}
rm jenkins.war && ln -s jenkins.war-${VERSION} jenkins.war
service jenkins restart

The above bash script will download a given version of the jenkins.war file and symlink it into place before restarting the jenkins service.

Assumptions made:

  • The jenkins.war file is installed to /usr/share/jenkins
  • The server is using upstart for running services
  • User input is sane – there is no validation or sanitisation

Vagrant: sudo access and the hostsupdater plugin

Bringing up a vagrant machine is as easy as `vagrant up`.

If you’re a web developer, it would be nice if it were to add the private network IP address to `/etc/hosts` of the host machine. Thus giving you instant access to http://my-awesome-site.dev/

This doesn’t happen by default, but it is possible with the use of a plugin. The one I like to use is `vagrant-hostsupdater`.

Install thus:

vagrant plugin install vagrant-hostsupdater

When you bring up the vagrant machine, it will now automatically add the VM’s name to `/etc/hosts`.

As `/etc/hosts` is owned by `root` (and I hope you aren’t running everything as `root`), you have to provide `sudo` access to edit `/etc/hosts`.

Either you manually enter your `sudo` password every time you run `vagrant up`, or you can add some rules to `sudoers`.

This will work on Ubuntu type systems. Paths to `sh` and `sed` may be different on your own system.

Copy/paste the following into `/etc/sudoers.d/vagrant` and `chmod` the file to `0440`

# vagrant-hostsupdater plugin
Cmnd_Alias VAGRANT_HOSTS_ADD = /bin/sh -c echo "*" >> /etc/hosts
Cmnd_Alias VAGRANT_HOSTS_REMOVE = /bin/sed -i -e /*/ d /etc/hosts
%sudo ALL=(root) NOPASSWD: VAGRANT_HOSTS_ADD, VAGRANT_HOSTS_REMOVE

A similar system can be used if you want to make use of `nfs` for the file sharing with the VM.

Again, this works for Ubuntu systems, you mileage may vary.

Copy/paste the following into `/etc/sudoers.d/vagrant` and `chmod` the file to `0440`

# nfs mounting in vagrant
Cmnd_Alias VAGRANT_EXPORTS_ADD = /usr/bin/tee -a /etc/exports
Cmnd_Alias VAGRANT_EXPORTS_COPY = /bin/cp /tmp/exports /etc/exports
Cmnd_Alias VAGRANT_NFSD_CHECK = /etc/init.d/nfs-kernel-server status
Cmnd_Alias VAGRANT_NFSD_START = /etc/init.d/nfs-kernel-server start
Cmnd_Alias VAGRANT_NFSD_APPLY = /usr/sbin/exportfs -ar
Cmnd_Alias VAGRANT_EXPORTS_REMOVE = /bin/sed -r -e * d -ibak /tmp/exports
%sudo ALL=(root) NOPASSWD: VAGRANT_EXPORTS_ADD, VAGRANT_NFSD_CHECK, VAGRANT_NFSD_START, VAGRANT_NFSD_APPLY, VAGRANT_EXPORTS_REMOVE, VAGRANT_EXPORTS_COPY

You will now be able to use `nfs` without having to enter your `sudo` password on each `vagrant up` and `vagrant halt`.
 

Basic set-up of a 3com 4500 managed network switch

I’m a PHP developer by trade with a strong Linux background. One thing that has been lacking from my skill set is how networking really works.

In an effort to rectify this, I bought myself a 2nd hand managed network switch from ebay. A 26 port (24 x 10/100mb + 2 x 1gb) “3com SuperStack 3 Switch 4500”.

Flashing lights and noisy fans, I feel like I’m headed in the right direction.

First things first – can I plug it into my router (with DHCP), have it get an IP address and log into the web interface?

No 🙁

Using nmap to sweep the subnet, that the router manages, returned no results for the known MAC address of the switch.

Even checking the router for connected devices didn’t list the known MAC address of the switch.

If I wasn’t getting into the system via the network, I would have to use the console port instead.

As I didn’t have a null modem cable to hand, and I don’t have an active machine with a d9 serial port, I grabbed something from Amazon: http://www.amazon.co.uk/gp/product/B00HUZ6OMQ (NB: does not work with this switch, keep reading)

As I’m a Linux user, I would be playing with /dev/ttyUSB0. And to use that, my user has to be in the dialout group:

sudo usermod -a -G dialout iain

Connecting to the serial console should be easy with:

byobu-screen /dev/ttyUSB0 19200

Hooked up the cable, ran the command to bring up the serial interface and switched on the switch.

This, annoyingly vertical, video shows that something happens (watch the green block skit around in the black window) but no text appears: https://www.youtube.com/watch?v=sXVYtClNDYU

Every different program I tried (screen, minicom, putty) to connect to the device all resulted in the same output.

Thanks to fellow 3com switch owner Intrbiz, I have been able to borrow a known working cable.

Hooked up between the PC and switch, ran the byobu-screen command and turned on the switch – It lives!

Now that I have a way of talking to the switch, I can configure it in a way so that I don’t need the console cable (as much).

 

Factory reset (this requires the console cable):

We need to factory reset for the following reasons:

  • remove any unknown users
  • restore the admin password to the factory default
  • remove any network configuration set-up by the previous owners
  • set-up our own network configuration

Start a console session and power on or reboot the switch.

  • Hit ctrl+b when prompted. Be quick, you don’t get long.
  • Now in the boot menu, tell the switch to ignore the saved configuration for the next reboot (option 7).
  • Reboot the switch (option 0).

Let it boot normally and wait until something like this appears:

User interface aux0 is available.
Please press ENTER.
  • Hitting enter will log you in as the admin user.
<4500>
%Jun 6 13:41:38:126 2015 4500 SHELL/5/LOGIN:- 1 - Console(aux0) in unit1 login
  • Hit enter again to put your cursor on a new line, not at the end of the debug output line. Enter “save” to save the default configuration over the configuration that was written by the previous owner.
<4500>save
The configuration will be written to the device.
Are you sure?[Y/N]y
Please input the file name(*.cfg)(To leave the existing filename 
 unchanged press the enter key):
Now saving current configuration to the device.
Saving configuration. Please wait...
......
 Unit1 save configuration flash:/ccc.cfg successfully
<4500>
%Jun 6 13:43:04:746 2015 4500 CFM/3/CFM_LOG:- 1 -Unit1 saved configuration successfully.
<4500>

It’s now safe to reboot or power cycle the switch as much as you like and it’ll have the factory default settings.

 

Assign a static IP address to the network switch (this requires the console cable):

  • Ensure that the switch has booted and then connect to the console
byobu-screen /dev/ttyUSB0 19200
[- press enter if the screen is just blank -]
<4500>
  • Enter the system view
<4500>system-view
System View: return to User View with Ctrl+Z.
[4500]
  • Switch to vlan 1
[4500]interface vlan 1
[4500-Vlan-interface1]
  • Set an IP address followed by netmask
[4500-Vlan-interface1]ip address 192.168.1.13 255.255.255.0
[4500-Vlan-interface1]
  • Set the default route for the switch
[4500-Vlan-interface1]ip route-static 0.0.0.0 0.0.0.0 192.168.1.1
[4500]
  • Return to the user view
[4500]quit
<4500>
  • Save the configuration
<4500>save
The configuration will be written to the device.
Are you sure?[Y/N]y
Please input the file name(*.cfg)(To leave the existing filename 
 unchanged press the enter key):
Now saving current configuration to the device.
Saving configuration. Please wait...
......
 Unit1 save configuration flash:/ccc.cfg successfully
<4500>

 

Enable SSH login (this requires the console cable):

  • Ensure that the switch has booted and then connect to the console
byobu-screen /dev/ttyUSB0 19200
[- press enter if the screen is just blank -]
<4500>
  • Enter the system view
<4500>system-view
System View: return to User View with Ctrl+Z.
[4500]
  • Create the public SSH key
[4500]public-key local create rsa
The range of public key size is (512 ~ 2048). 
NOTES: If the key modulus is greater than 512, 
 It will take a few minutes.
Input the bits in the modulus[default = 1024]:
Generating keys...
...............................................................................++++++
.....................................................++++++
......
[4500]
  • Configure the authentication mode
[4500]user-interface vty 0 4
[4500-ui-vty0-4]authentication-mode scheme
[4500-ui-vty0-4]
  • Enable the SSH protocol for inbound connections
[4500-ui-vty0-4]protocol inbound ssh
[4500-ui-vty0-4]
  • Exit the interface configuration and return to the system-view
[4500-ui-vty0-4]quit
[4500]
  • Create a new user for our SSH connections
[4500]local-user client001
New local user added.
[4500-luser-client001]
  • Set the user’s password
[4500-luser-client001]password simple abc4567890
Updating user password, please wait..........
[4500-luser-client001]
  • Give the user SSH access
[4500-luser-client001]service-type ssh level 3
[4500-luser-client001]
  • Exit back to the system view
[4500-luser-client001]quit
[4500]
  • Allow the user to login via SSH using their password
[4500]ssh user client001 authentication-type password
[4500]
  • Exit back to the user view
[4500]quit
<4500>
  • Save the configuration
<4500>save
The configuration will be written to the device.
Are you sure?[Y/N]y
Please input the file name(*.cfg)(To leave the existing filename 
 unchanged press the enter key):
Now saving current configuration to the device.
Saving configuration. Please wait...
......
 Unit1 save configuration flash:/ccc.cfg successfully
<4500>
  • Check that the SSH login works
snafu2 ~ $ ssh client0011@192.168.1.13
The authenticity of host '192.168.1.13 (192.168.1.13)' can't be established.
RSA key fingerprint is 6c:46:57:da:74:f3:9d:e0:80:4e:46:c1:a8:9a:d3:83.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '192.168.1.13' (RSA) to the list of known hosts.
client001@192.168.1.13's password:
********************************************************************************
* Copyright(c) 2004-2012 3Com Corp. and its licensors. All rights reserved. *
* Without the owner's prior written consent, *
* no decompiling or reverse-engineering shall be allowed. *
********************************************************************************
<4500>
%Apr 1 23:58:56:199 2000 4500 SHELL/5/LOGIN:- 1 - client001(192.168.1.4) in unit1 login
<4500>

 

Enable Web login (this can be done with the console cable or an SSH session to the switch):

  • Connect to the switch via the console
  • Change to the system view
<4500>system-view
System View: return to User View with Ctrl+Z.
[4500]
  • Switch to the admin user
[4500]local-user admin
[4500-luser-admin]
  • Configuration stuff
[4500-luser-admin]attribute access-limit 1
[4500-luser-admin]level 3
[4500-luser-admin]service-type telnet level 3
[4500-luser-admin]service-type lan-access
[4500-luser-admin]
  • Return to the user view
[4500-luser-admin]quit
[4500]quit
<4500>
  • Save the config changes
<4500>save
The configuration will be written to the device. 
Are you sure?[Y/N]y
Please input the file name(*.cfg)(To leave the existing filename 
 unchanged press the enter key):
Now saving current configuration to the device. 
Saving configuration. Please wait...
......
 Unit1 save configuration flash:/ccc.cfg successfully
<4500>

 

Reference

Firmware: https://h10145.www1.hp.com/downloads/SoftwareReleases.aspx?ProductNumber=JE045A

Enabling SSH logins: http://h30499.www3.hp.com/t5/Comware-Wireless-Unified-Series/How-To-Enable-SSH-In-3com-4500-Switch/td-p/2318357#.VXLVtd9jPRY

Fixing the web login: http://brittadams.com/blog/2014/08/25/unable-to-log-into-web-interface-3com-4500-switch/