Network Manager and OpenVPN

It blows my mind that Network Manager is still as bad as ever, I just finished up getting my new phone aimed at the home VPN when I remembered that the laptop lost all the old settings in my switch to Fedora so I figured I would give it a spin and see if somehow NM had been fixed.  A few minutes and some profanity later and it seems it STILL is unable to properly load up .ovpn profiles and parse out the various bits into the fields they need to go.  Even when I manually split up the keys and certs and all that it only worked halfway, I could connect to the VPN but was unable to browse the internet over it or even access resources local to the VPN server itself.  Fortunately the command line comes to the rescue again, all I had to do was tell openvpn itself where the config was and it did all the legwork that the abomination known as Network Manager failed to do.  For those who might care the proper way to invoke it is as follows

sudo openvpn --config /home/user/openvpn.ovpn

Now I just have to make a handy way to suppress the output, give me a status indicator and kill off the connection when I am done with it…

Successful Upgrade is Successful

I would say I can’t believe I’m typing this from a successful full upgrade from Fedora 23 to 24 but I’m not since I am at work and they frown upon me pecking away on my personal laptop, but I am still amazed that it was an absolutely painless process to upgrade from 23 to 24 with dnf.  In prior years it was almost always advisable to reinstall rather than attempt an upgrade from one major release to the next but the fine folks over at Fedora seem to have hit a home run on this one.  Sure it took a while to apply everything but the moment of truth (or reboot) came and passed and all I got was my normal login screen, no fancy explosions of failed video drivers, no corrupted profiles or missing files; it went so smooth I almost didn’t think it worked until I checked the redhat-release file and verified that it was in fact on the 24 release.

Crontab – Always Check your Environment Variables

So I have been running into this issue for like a month now where a script that I can run from the command line by hand executes fine, but when I try to run it via a crontab job it just goes absolutely pear shaped without any real explanation.  Finally I got some time at the beginning of a shift to sit with one of our senior guys to take a look at it as the script provides data the entire team uses and when it doesn’t run they get cranky.  It turns out that the environment my cron jobs run as is highly different, as indicated by the following which is obtained by adding adding a line to output env to a text file every time the crontab job ran.

XDG_SESSION_ID=159
SHELL=/bin/sh
OLDPWD=/home/dword
USER=dword
PATH=/usr/bin:/bin
PWD=/home/dword/labmap
LANG=en_US.UTF-8
HOME=/home/dword
SHLVL=2
LOGNAME=dword
XDG_RUNTIME_DIR=/run/user/1000
_=/usr/bin/env

Compare that against the results from env when run by hand

XDG_SESSION_ID=145
 HOSTNAME=dword-cent7
 TERM=xterm
 SHELL=/bin/bash
 HISTSIZE=500000
 SSH_CLIENT=192.168.42.120 49429 22
 SSH_TTY=/dev/pts/0
 USER=dword
 LS_COLORS=rs=0:di=01;34:ln=01;36:mh=00:pi=40;33:so=01;35:do=01;35:bd=40;33;01:cd=40;33;01:or=40;31;01:mi=01;05;37;41:su=37;41:sg=30;43:ca=30;41:tw=30;42:ow=34;42:st=37;44:ex=01;32:*.tar=01;31:*.tgz=01;31:*.arc=01;31:*.arj=01;31:*.taz=01;31:*.lha=01;31:*.lz4=01;31:*.lzh=01;31:*.lzma=01;31:*.tlz=01;31:*.txz=01;31:*.tzo=01;31:*.t7z=01;31:*.zip=01;31:*.z=01;31:*.Z=01;31:*.dz=01;31:*.gz=01;31:*.lrz=01;31:*.lz=01;31:*.lzo=01;31:*.xz=01;31:*.bz2=01;31:*.bz=01;31:*.tbz=01;31:*.tbz2=01;31:*.tz=01;31:*.deb=01;31:*.rpm=01;31:*.jar=01;31:*.war=01;31:*.ear=01;31:*.sar=01;31:*.rar=01;31:*.alz=01;31:*.ace=01;31:*.zoo=01;31:*.cpio=01;31:*.7z=01;31:*.rz=01;31:*.cab=01;31:*.jpg=01;35:*.jpeg=01;35:*.gif=01;35:*.bmp=01;35:*.pbm=01;35:*.pgm=01;35:*.ppm=01;35:*.tga=01;35:*.xbm=01;35:*.xpm=01;35:*.tif=01;35:*.tiff=01;35:*.png=01;35:*.svg=01;35:*.svgz=01;35:*.mng=01;35:*.pcx=01;35:*.mov=01;35:*.mpg=01;35:*.mpeg=01;35:*.m2v=01;35:*.mkv=01;35:*.webm=01;35:*.ogm=01;35:*.mp4=01;35:*.m4v=01;35:*.mp4v=01;35:*.vob=01;35:*.qt=01;35:*.nuv=01;35:*.wmv=01;35:*.asf=01;35:*.rm=01;35:*.rmvb=01;35:*.flc=01;35:*.avi=01;35:*.fli=01;35:*.flv=01;35:*.gl=01;35:*.dl=01;35:*.xcf=01;35:*.xwd=01;35:*.yuv=01;35:*.cgm=01;35:*.emf=01;35:*.axv=01;35:*.anx=01;35:*.ogv=01;35:*.ogx=01;35:*.aac=01;36:*.au=01;36:*.flac=01;36:*.mid=01;36:*.midi=01;36:*.mka=01;36:*.mp3=01;36:*.mpc=01;36:*.ogg=01;36:*.ra=01;36:*.wav=01;36:*.axa=01;36:*.oga=01;36:*.spx=01;36:*.xspf=01;36:
 MAIL=/var/spool/mail/dword
 PATH=/usr/local/bin:/usr/bin:/usr/local/sbin:/usr/sbin:/home/dword/.local/bin:/home/dword/bin
 PWD=/home/dword/labmap
 LANG=en_US.UTF-8
 HISTCONTROL=ignoredups
 SHLVL=1
 HOME=/home/dword
 LOGNAME=dword
 SSH_CONNECTION=192.168.42.120 49429 192.168.33.232 22
 LESSOPEN=||/usr/bin/lesspipe.sh %s
 XDG_RUNTIME_DIR=/run/user/1000
 _=/usr/bin/env
 OLDPWD=/home/dword/labmap/web

Notice the path statement is very sparse when cron outputs the environment variables, turns out that anemic path lacked access to fping which was integral to my script building out a list of live hosts within our lab environment. Once that was fixed the cron jobs hum along nicely and churn out an updated map of the lab every hour without me doing anything and now I know that crontabjobs run with fairly different environment variables than scripts manually ran and can cause all kinds of havoc if you don’t use full explicit path statements in your bash scripts that you plan to automate.

scripting: system-help

We have this handy script at work that pulls all kinds of useful details from a system and saves us a ton of time checking by hand, so I took a stab at making my own version for generic use. Its not very good at all but it kinda works and probably could be expanded upon to do something actually useful.

#!/bin/bash

SCRIPT_VERSION="0.1"
# things to check
# internal ip, external ip, dns server, connectivity to google
# filesystem usage, current system load, memory usage

> log.log
date >> log.log
IP=`ip addr | grep -P -o 'd{1,3}.d{1,3}.d{1,3}.d{1,3}/24'`
EXT_IP=`curl -s www.ipchicken.com | grep -o -P 'd{1,3}.d{1,3}.d{1,3}.d{1,3}'`
DNS_1=`grep -P -o 'd{1,3}.d{1,3}.d{1,3}.d{1,3}' /etc/resolv.conf`

echo "Internal IP:" $IP >> log.log
echo "External IP:" $EXT_IP >> log.log
echo "DNS Server 1:" $DNS_1 >> log.log

MEM_USAGE=`free -m`
echo -e "nMemory Informationn" >> log.log
echo -e "$MEM_USAGE" >> log.log 

DISK_USAGE=`df -h`
echo -e "nDisk Usagen" >> log.log
echo -e "$DISK_USAGE" >> log.log

TOP_SNAPSHOT=`top -n 1 -b`
echo -e "nTop Processesn" >> log.log
echo -e "$TOP_SNAPSHOT" >> log.log

UPTIME_SNAPSHOT=`uptime`
echo -e "nUptimen" >> log.log
echo -e "$UPTIME_SNAPSHOT" >> log.log

# now lets try some active tests
echo -e "nPing Testn" >> log.log
if eval "ping -q -c 1 google.com> /dev/null"
then
	echo -e "Ping Test: Successful!" >> log.log	
else
	echo -e "Ping Test: Failed!" >> log.log	
fi

Repo on Gitlab

Close Bitnami banner
Bitnami