Securing MySQL databases (the short way)

If you have ever installed of MySQL on a *nix system, you may have come across the mysql_secure_installation script. It takes you through a number of interactive questions/steps that help you to increase the security of your MySQL installation, and is quite a useful script.

As we have a high deree of automation in our server environment, we decided to break this script down to its raw MySQL command, and in a nut shell, here is what it actually does behind the scenes (assuming you want to answer Yes to all of the questions it asks in interactive mode):

UPDATE mysql.user SET Password=PASSWORD('XXXX') WHERE User='root';
DELETE FROM mysql.user WHERE User='';
DELETE FROM mysql.user WHERE User='root' AND Host!='localhost';
DROP DATABASE test;
DELETE FROM mysql.db WHERE Db='test' OR Db='test\\_%';
FLUSH PRIVILEGES;

Naturally, you should replace the XXXX in the first command with an appropriate password.

Variable manipulation from within a Bash subshell

Consider a shell script that counts the number of lines in a file. There are a number of ways to do this and I initially chose the following method:

NUMLINES=0
cat /tmp/file.txt | while read LINE;
do
NUMLINES=`expr $NUMLINES + 1`
done
echo "Number of lines was $NUMLINES"

However, using this approach the value of NUMLINES was always zero after the while loop has ended, even though when I printed out its value inside the while loop it appeared to be incrementing just fine.

The problem turned out to be the use of the pipe at the beginning of the the while loop. This causes a new sub-shell to be created, which in turn creates a new local version of the NUMLINES. Thus, the original copy of the NUMLINES variable (outside the while loop) is never actually changed. Here is one solution to this that eliminates the use of the pipe (i.e. replace the piping of the file in the while with a redirection from the file at the end of the while statement):

NUMLINES=0
while read LINE;
do
NUMLINES=`expr $NUMLINES + 1`
done < /tmp/file.txt
echo "Number of lines was $NUMLINES"

This worked for me!

Making scripts executable inside Subversion

The Problem

Every time you check out a script file from Subversion on a Unix system, the file is missing the execute permission and you have to manually perform a chmod +x every time. This usually happens if the file was either originally added without the permission set or if it was added to Subversion from a Windows system. But more to the point, it is extremely annoying.

The Solution

The solution to this involves adding an internal Subversion property called svn:executable to the script file(s) in question. The property can either be set using Tortoise SVN from a Windows system (as described by a posting on Late Night PC found by my colleague Máté Rácz) or can be done from the command-line as follows:

$ svn propset svn:executable true myscript.sh

Both methods work and required a SVN commit afterwards.

To script or not to script

In an interesting article on the merits (or not) of scripting languages, James Turner outlines where some of their strengths and weaknesses lie. He uses Perl as the example in this instance but on reading the article I found that many of the pros and cons readily apply to most other scripting languages I’ve used (Tcl, Python, Bash, Sh).

In particular, his comments about them being strong on cross-platform support and weak on performance-related applications definitely ring true from my past experiences with Tcl/Tk. However, one point that he did not make, which I feel is definitely one of scripting languages’ stronger points, is in the area of custom testing and debugging, in the context of prototype product design and integration.

The likes of Perl, Python and/or Tcl really can enable you to glue together some pretty compelling, custom-made testing utilities, often without the need for complicated frameworks or other plugins. In particular, the ability to create your own extensions (using C or even SWIG) can make for some pretty powerful, tailor-made manufacturing test tools (trust me, I’ve been there!).

Of course this may not suit everyone’s needs, and there will be those that will opt for off-the-shelf products that do similar. However, if you are dealing with a newly designed product or hardware appliance featuring custom firmware not seen before, that needs to run on several different platforms, then a decent scripting language will most definitely be your friend.

Source: CIO.com

Linux /etc/bash.bashrc versus /etc/profile

The most common place that people add system-wide environment variables on Linux is in /etc/profile. However, this requires that you log out and back in again (or start another session) for these changes to take effect. Whilst this is acceptable practise for most Linux desktop developers, I find it a little tedious when working from the Linux command-line.

So, after a little probing, I discovered that you can also make system-wide changes in /etc/bash.bashrc file but can use these immediately by simply invoking a new bash session (by typing bash at the same command prompt).

Of course if you have desktop applications that require the new settings then you will still have to log out and back in again as before but, if like me, you work a lot from the command-line, then you have the added benefit of being able to use the new settings immediately.