Showing posts with label bash. Show all posts
Showing posts with label bash. Show all posts

Friday, 8 November 2019

Dull Directory Colour in Ubuntu Server

One of my problems with the latest version of Ubuntu server is the default colour for the ls command, I'd never engaged with this before, but it's a dark blue.  It's probably always been dark blue, if you perform ls with "--color=auto" you'll see it's probably dark blue, but the server always left it without the default colour... until now.

And I can't see the dark blue very well, I have reduced the amount of blue light on all my screens and dimmed things down for long hours in front of the screen, so dark blue really really doesn't work.

I have to change my folders, but I don't want to overload everything... Only the directory colour, if you take a look at the ~/.bashrc file then you will see ls colur defaults to auto:


But, I figured out that the colour will default and THEN another alias will over ride... So, I leave the auto alone and add a new alias at the bottom of the file:


This is setting the "di"rectory to colour 33, which is orange...

Reboot and this is what I now see...


The cyan colour for the files is coming from the auto, the highlight around tmp likewise.  But the orange is coming from my alias... Lovely, now I can read the server information even on this dim dim screen... eye candy!

If you want to follow more of this, check out this source.

Monday, 19 June 2017

Bash : Power of Pipes

Subtitle: "Get IP Address Easily"

When I say easily, I mean not so easily, but with the proper tools... Let me explain, it's been one of those days... I've a remote server running some flavour of Linux, and no-one knows it's remote IP Address, they all SSH into the box run "ifconfig" and note down the value, they then plug this into a config (or worse still were baking it directly into some code) and running their services....

The trouble of course being, years later, they're no-longer the programmers nor maintainers of this machine, I am...

And to be frank whenever the IP address changes I don't want to recompile their java code, nor use vi to edit the various configuration files, I want a script to at least update the settings automatically.

I therefore changed their code to load the IP address, not hard code it, and used some other scripts to put the IP address into the config file at boot...

The first line of that script is what I'm going to document here... so it starts:

#! /bin/bash
ifconfig | grep inet | tr ' ' '\n' | sed -u '/^$/d' | head -2 | tail -1 > ipaddress.txt

This script gives me a single line of text with the IP Address in it, for the one and only adapter in the machine, if you have multiple adapters you'd have to play about with the grep inet to select the row you want with a head & tail call before moving into the  final location, or whatever...

I wrote this up however, and immediately started to use the IP address.

The net result was a request to explain all this functionality to a colleague... Here's what I came up with.

ifconfig gets us the adapter information...
grep strips off lines we don't want only giving lines for the inet adapter
translate turns spaces into new lines
the sed call removes the blank lines, giving just the IP address and some guff
the first adapter IP address is therefore always the second line of this output
we select the first two lines with head
then select only the latter of these two with tail
and write this to a file

Her reply... "What are the Lines?"....

"What lines?"...

"These | things"....

"They're pipes, I'm piping the information from one program to the next..."

"Oh"

"Do you know what pipes do in Unix and Linux?"

"No"

I sent her to this video... https://youtu.be/XvDZLjaCJuw?t=5m15s

Wednesday, 5 April 2017

Development : Anti-Hungarian Notation

Whilst cutting code I employ a coding style, which I enforce, whereby I output the scope of the variable being used with a prefix.

"l_" for Local
"m_" for Member
"c_" for constant
"e_" for enum

And so forth, for static, parameter and a couple of others.  I also allow compounds of these, so a static constant would be:

"sc_"

This is useful in many languages, and imperative in those which are not type strict, such as Python.

Some confuse this with "Hungarian Notation", it's not.  Hungarian notation is the practice of prefixing a type notification to the variable name, for example "an integer called count" might be "iCount".

I have several problems with anyone using Hungarian Notation, and argue against it thus. With modern code completion and IDE lookup tools this is really not needed, with useful and meaningful naming of your variables the type is not needed and finally there are multiple types with the same possible meaning... i.e. "bool", "BYTE" and "std::bitset" are they all 'b'?  What about signing notation, so you compound "unsigned long" as "ul" to the name?

It all gets rather messy, a good name is enough.

However, the scope of the variable might change, the scope might not be enforced, and in none strict languages you might have a variable go out of scope and then automatically re-create the value with a blank value, if you don't follow your scopes.

Therefore I can justify my usage and enforcement of this coding standard.

What I can't stand however is when someone listens to my explaining this, they read my coding standards document, they even go as far as having me reject their code during peer review for these reasons, and then they dismiss my comment with the "it's just Hungarian Notation"... Scope is not type, and type does not define scope, don't be fooled!

Friday, 31 March 2017

Linux Server Admin : Bash Kill Processes By Common Name

On my Linux server I've recently wanted to go through and kill a bunch of application instances in one go, this is a server where students have been connecting and running carious programs under python, therefore I want to remove from my processes anything called "python".

We can see these in our bash shell with the command:

sudo ps -aux | grep python

To remove all these programs I create the following bash shell script:

k = 0
for i in $(ps -aux | grep python)
do
  k=`expr $k + 1`
  kill -9 $i  
done
logger -s "Closed $k Python Instances"

Notice k=`exp... this is NOT a single quote (apostrophe) it is the "smart quote" on a UK English keyboard this is the key to the left of the number 1.  It is used to substitute the command into place, so the value counted in K becomes the result of the expression "$k + 1", i.e. K+1.  More about Command Substitution in Bash here.

The call to logger -s places the message both on screen and in syslog for me to review later.

This simply loops through all the applications resident and kills them off, I've saved this as a "sh" file, added executable rights with "sudo chmod +x ./killpythons.sh" and I created this to run as a cron job everyday at 3am (a pretty safe time, unless I have some students burning the candle at both ends).

That's everything about the bash script, for those of you wondering about the students, they're those folks following my learning examples from my book, which you can buy here.


Monday, 31 March 2014

Ubuntu Server - Automatic E-mail of Status upon Boot

As the multiboxer project has grown, I now need to support multiple bug reporters (I have three helpers now, if you've not donated yet and joined in you're missing out!)....

So with the new bug reports I'm looking at establishing a server at home, with a private IP and allowing the helpers to post their tickets there.  The trouble is, the loft man lab, where the server is stationed, is serviced by wireless only.  The signal strength is good, and I'm not going to throw a cat-5-e cable up there because I've spent too much time fixing walls and removing old dead telephone cables as it is.

The server is a Ubuntu 12.04.4 LTS box, and when it boots I want it to e-mail the testers, and me, its IP Address.  This way I don't have to faff about with dyndns (as much as I love them, their usage terms are a pain in the arse for free users now-a-days) or any other dynamic domain name service.

Now, the IP mailing just needs to send the interfaces information out, through a few tricks the IP of eth0 is the router outbound IP, and I've carefully opened port 80 for them to chat to it over the web...

So, to set this all up... We need a script to wait an amount of time, then get the adapter information, and then e-mail it...

sudo nano /usr/sbin/bootmail.sh

The script then looks like this:

#!/bin/bash
echo Waiting...
sleep 30
echo Getting Interface Info
ifconfig > /tmp/ifinfo.txt
file=/tmp/ifinfo.txt
echo Sending mail...
function mailalert(){
  echo Calling Mail...
  sendmail -F "noreply@Git-Server-VM" -it << END_MESSAGE
To: user1@gmail.com,user2@gmail.com,xelous@hotmail.co.uk
Subject: Multiboxer IP Update

$(cat $file)
END_MESSAGE
}
mailalert
echo Complete

You can look at this yourself in detail, I'm noting it for reference myself...

You save this file and then have to allow it to execute:

sudo chmod +x /usr/sbin/bootmail.sh

And finally we need to add it to the boot script, so its run as the server comes up...

sudo nano /etc/rc.local

And before "exit" at the bottom add:

/usr/sbin/bootmail.sh

Reboot your server and you'll now get an e-mail of the IP interfaces sent out...

I may later improve the script to add the bug reporters to a known user group, use echo & cat to output the members of that group into a file, and use that list as the "To" field.  But for now, with the happy few of us, this will do.

Now, I would have previously (as you can tell by my older blog entries) used Subversion.  However, I'm managing this project with Git, so I may also now set up the Git on this server, and put a centralised copy of the code onto it, securing it with SSH... Pretty sure there was a good tutorial on setting this up on a server in a recent Linux Format...