All posts by Steven Netting

Building qtel (Echolink client) under Fedora Linux

With both my previous bad experience building qtel (the Linux EchoLink client) and recent discussions on a forum around similar difficulties – I thought I’d identify, resolve and document the issues.

I’m not sure what’s changed but the process is now very simple (Fedora 28):-

git clone https://github.com/sm0svx/svxlink.git
cd svxlink/
cd src
sudo dnf install cmake libsigc++20-devel qt-devel popt-devel libgcrypt-devel gsm-devel tcl-devel
cmake .
make
cp bin/qtel DESTINATION_PATH_OF_CHOICE

Depending on libs already installed, additional packages may be required – as indicated by failures during the ‘cmake’ stage.

GlusterFS / VG Metrics in Prometheus (OCP)

We had a requirement to gather LVM (VG) metrics via Prometheus to alert when GlusterFS is running low on ‘brick’ storage space. Currently, within Openshift 3.9 the only metrics seem to relate to mounted FS. A ‘heketi exporter module’ exists but this only reports space within allocated blocks. There doesn’t appear to be any method to pull metrics from the underlying storage.

We solved this by using a Prometheus pushgateway. Metrics are pushed from Gluster hosts using curl (via cron) and then pulled using a standard Prometheus scrape configuration (via prometheus configmap in OCP). Alerts are then pushed via alertmanager and eventually Cloudforms.

Import the pushgateway image:

oc import-image openshift/prom-pushgateway --from= docker.io/prom/pushgateway --confirm

Create pod and expose route. Then, add scrape config to prometheus configmap:-


- job_name: openshift-pushgateway
scrape_interval: 30s
scrape_timeout: 30s
metrics_path: /metrics
scheme: http
static_configs:
- targets:
- pushgateway-route.example.com

On GlusterFS hosts we then gather metrics in whatever way we like and push to the gateway via curl. Example:-

echo "VG_Gluster 42" | curl --data-binary @- http://pushgateway-route.example.com/metrics/job/pv_mon/pv/vg"

The metrics are then visible via prometheus UI / Grafana and alerts via alertmanager and CFME respectively.

Gnome 3 (Fedora 27) Screen Lock Timeout

Gnome 3 doesn’t appear to offer any GUI control over the screen lock timeout.

So, to get current values:-

[snetting@lapper ~]$ gsettings get org.gnome.desktop.session idle-delay
uint32 300
[snetting@lapper ~]$ gsettings get org.gnome.desktop.screensaver lock-delay
uint32 0

And to set:-

[snetting@lapper ~]$ gsettings set org.gnome.desktop.session idle-delay 600

idle-delay is the time taken to blank the screen.
lock-delay is an additional delay before locking.

OSEv3 Node Utilisation

A quick and dirty script to query all nodes for utilisation data:-


#/bin/bash

printf "%-12s %-25s %-4s %-15s %-20s %-18s %-8s \n" "NODE" "STATE" "PODS" "CPU Req" "CPU Lim" "Memory Req" "Memory Lim"
oc get nodes --show-labels | grep user | while read NODE STAT stuff
do
printf "%-12s %-25s %-5s " $(echo $NODE | cut -f1 -d. ) $STAT $(oadm manage-node --list-pods $NODE 2> /dev/null | sed '/^NAME.*/d' | wc -l)
printf "%-7s %-7s %-7s %-12s %-12s %-5s %-12s %-5s\n" $(oc describe node $NODE | grep -a2 "CPU Requests" | tail -1)
done

Docker Panic, CMD and Hashbang

Noticed issue when rebuilding dockerfile and running image:-

panic: standard_init_linux.go:178: exec user process caused "exec format error" [recovered]
	panic: standard_init_linux.go:178: exec user process caused "exec format error"

goroutine 1 [running, locked to thread]:
panic(0x6f3080, 0xc4201393b0)

Did much digging, identified that when specifying a script as a CMD in the Dockerfile, this script now requires a proper hashbang (aka shebang) or the above panic results.

#!/bin/bash
rm -rf /run/httpd/* /tmp/httpd*
exec /usr/sbin/apachectl -DFOREGROUND

Rebuilding the docker image with –no-cache option ensures the updated file is included.

Dummy java loop/sleep for test of init scripts

A dummy java executable (actually a jar) was required to develop init scripts without access to the client’s application.   The process of creating a Java ‘sleep’ application and wrapping within a ‘jar’ complete with manifest was not obvious to me.  The ‘thread.sleep’ also didn’t work as I expected, requiring an additional exception handler.  Not to mention the requirement for the manifest to require multiple new lines before being syntactically correct (and no report otherwise when incorrectly parsed, except ‘no main manifest attribute’ when attempting to run).  Why Java, WHY?

The following tgz contains both the compiled java executable plus source, manifest and instructions to build / compile the jar should the wait time (default 100 seconds) need to be modified.

WaitLoop.tgz (source and executable tgz)
WaitLoop (Github Project)

The .jar can be executed with:-

java -jar WaitLoop.jar

X forwarding over ssh and sudo

This has bugged me for years – with random success depending on sudo, su – etc.

The proper solution:-

steve@studio:~$ ssh -X 192.168.0.201
Last login: Fri Feb 10 21:54:11 2017 from 192.168.0.247
[steve@fleabox ~]$ xauth list
fleabox.track3.org.uk/unix:12  MIT-MAGIC-COOKIE-1  b4339e07fb0e4febdde6128fc56419e4
[steve@fleabox ~]$ sudo su -
[sudo] password for steve: 
[root@fleabox ~]# xauth add fleabox.track3.org.uk/unix:12  MIT-MAGIC-COOKIE-1  b4339e07fb0e4febdde6128fc56419e4
[root@fleabox ~]# virt-manager &
[1] 7168

Success!

Docker and Apache QuickStart

mkdir -p dockerfile/C7httpd; cd dockerfile/C7httpd
vi Dockerfile

FROM centos:7
MAINTAINER "Steve Netting" steve@netting.org.uk
ENV container docker
RUN yum -y --setopt=tsflags=nodocs update && \
yum -y --setopt=tsflags=nodocs install httpd && \
yum clean all

EXPOSE 80

ADD run-httpd.sh /run-httpd.sh
RUN chmod -v +x /run-httpd.sh

CMD ["/run-httpd.sh"]

vi run-httpd.sh

#!/bin/bash

# Make sure we're not confused by old, incompletely-shutdown httpd
# context after restarting the container. httpd won't start correctly
# if it thinks it is already running.
rm -rf /run/httpd/* /tmp/httpd*

exec /usr/sbin/apachectl -DFOREGROUND

docker build .
docker images
docker run -d -p:8082:80 steve/httpd:latest
docker ps
curl http://localhost:8082

... If you can read this page it means that this site is working properly ...

To start interactive shell from inside running container:
docker exec -i -t romantic_noyce /bin/bash

Retrieving SCSI/LUN IDs from Linux /dev/sd*

Useful to identify disks present before/after a rescan of LUNs:-

for x in `ls -1 /dev/sd*`; do echo -n "$x:"; sudo /sbin/scsi_id -g $x; done > file.txt

The output is then in the format:-

/dev/sdt:360a9800044316f6f543f4646506b334d

Capture output before/after rescan of SCSI bus then use something like this to reveal the newly added LUNs (SCSI IDs):-

sdiff prescan.txt postscan.txt | grep ">"  | awk '{ print $2 }' | cut -d":" -f2 | sort -n | uniq