Check Out Linux Mint

Linux Mint Operating SystemI have to share something with everyone now. Anybody and everybody that knows me, knows that I am a die hard UNIX and Linux fan. I made the majority of my career managing UNIX and Linux boxes, with a server to admin ratio of sometimes 100 to 1. Everyone also knows that I am a die hard Debian fan, my distro of choice for my servers and my desktops is Debian, hands down. However, that doesn’t mean that I don’t use or like other distributions, I mean every one has it’s place and purpose. I really dig Ubuntu and SuSE and I cut my teeth on Red Hat and CentOS just as an example.

That being said, the purpose of this post is to tell you about another distro that I just recently checked out called Linux Mint. I know a lot of people have found it since it is in the number one slot over at distrowatch. On the recommendation of my friend Steve, I tried it out and I have to tell you that I was absolutely blown away by it. It’s based on Ubuntu which itself based on Debian so right there is a plus in my book, it has a solid core and foundation, but that’s not what blew me away.

Continue reading

Quickly backup files with this bash script

<img class="alignright size-full wp-image-1256" style="margin: 4px; border: 2px solid black;" alt="Bash script" src="http://www best slimming pills.solarum.com/wp-content/uploads/2013/12/script_icon-sm.jpg” width=”150″ height=”103″ />This is something that I use on a regular basis on all of my servers. How many times have you been ready to edit a file and either don’t make a backup copy or make one but by now are real tired of typing out copy one file to another name with a date stamp and blah blah blah. It’s not hard to do, but it gets old quick typing the same thing over and over again, plus you might not always name them the same thing or the same way, so now your backup files have different naming patterns and whatnot.

Don’t worry, I have an easy solution. I created a simple script to backup the file specified and append a time and date stamp to the end of it. I symlink this to the command ‘bu’ in someplace like /usr/bin so it’s always in the path of whatever user I might be (myself, root, backup, whoever?), and then POW, it’s easy to backup files plus they are always named the same way – you just type “bu filename”. Now, if you don’t like the way I name my file copies, feel free to customize this to suit your needs. Also, I currently have the script make the copy right next to the original file, but it would be easy to always copy the files to a backup directory somewhere if you wanted, the possibilities are endless!

OK, on to the script goodness:

#!/bin/bash
 
if [ "$1" == "" ]; then
  echo "No input given, stopping"
  exit
fi
 
YEAR=`date | awk '{print $6}'`
MONTH=`date | awk '{print $2}'`
DAY=`date | awk '{print $3}'`
TIME=`date | awk '{print $4}' | awk -F: '{print $1"-"$2"-"$3}'`
 
echo -n "Backing up the file named $1 ... "
/bin/cp -p $1 $1_${YEAR}.${MONTH}.${DAY}_${TIME} > /tmp/bu_run.log 2>&1
echo "done."

There you have it, a simple file backup script it bash that can save you time and many, many keystrokes. Drop me a comment and let me know what you think, or if you have any suggestions or improvements.

Command Line Encryption And Decryption Of Files Made Easy!

Encryption iconHey folks, here’s a fun little tidbit for you. Did you know that you can easily and quickly encrypt and decrypt files using one tiny little command on your super cool Linux or UNIX (Yes, OSX counts) and even Windows command line? For those that haven’t yet heard of it, it’s a command called ‘ccrypt‘. Check it out …

First we need to install ccrypt on on your system. For Debian and Ubuntu (which is based on Debian), you can simply use the apt package manager to do this. Remember that you can use the -s flag to test or simulate the install before you actually go through with it in order to make sure there are no surprises waiting for you. Logged in as your un-privileged account, the command would look like this:

sudo apt-get -s install ccrypt

Assuming everything went off as planned, you could then run the real thing:

sudo apt-get install ccrypt

For Redhat (CentOS, and others based on Redhat), they have RPM packages available for download. Along with those they have Debian, Solaris (SPARC and i386), OS/2, SuSE, OpenBSD, and FreeBSD packages as well as pre-compiled binaries for lots of platforms and OS’s, so go crazy people!!

OK, now that you have the package installed, you can have some fun whiling away the afternoon encrypting and decrypting files like mad!

To encrypt a file, run this command:

ccrypt file_name

It’s just that easy.

Naturally, you would replace ‘file_name’ with your real file information. You will be asked to enter a key or password two times. Once complete, the encrypted file will have an extension of ‘.cpt’, and the original un-encrypted file will be replaced by the encrypted file.

To decrypt the file, run the same command the same way and simply add the -d flag.

ccrypt -d file_name

You will be asked for the encryption key or password that you gave it when you encrypted it in the first place, so don’t lose it! As always you can use the ‘–help’ flag or hit up the man pages for more detailed information. Hope you enjoy it!

**ALERT**
**Danger, Will Robinson!**
Cheesy I know, but I hope it’s working. One more time – please note that when you run the command to encrypt a file, the original source file, the un-encrypted file gets replaced by the newly encrypted file. So if you are simply making an encrypted copy for example, the original is gone. If you lose or forget the encryption key or password you will be out of luck. I’m sure it can be cracked by someone, but boy that would be a pain in the arse! So, keep that in mind when you encrypt a file, the file you are encrypting goes bye, bye! It works the same way when un-encrypting, but that’s not as potentially dangerous.

A little history for all us starnix guys (and gals) out there

<a href="http://www.solarum weight reduction pills.com/wp-content/uploads/2012/08/ken-and-den-1024.jpg” target=”_blank”>Ken Thompson (seated) and Dennis RitchieIf you spend any amount of time working with or administering UNIX and/or linux »”>Linux servers, especially unix »”>UNIX, you should be familiar with the text editor ‘vi’ and some commands like ‘sed’ and ‘awk’. If you have been around a while, or had the good(?) fortune of working on some old(er) systems, you might even remember the line editor ‘ed’. I’ll show my age here and recall fond memories of using ‘ed’ to write code many years back.

OK, on to the point, I was looking through Wikipedia for something entirely un-related, but ran across a tidbit of information that I thought was really cool, and that I knew I had to share with Solarum’s readers. It gives a bit of history about some of the tools that we use and love today.

From Wikipedia:

“ed is a line editor for the Unix operating system. It was one of the first end-user programs hosted on the system and has been standard in Unix-based systems ever since. ed was originally written in PDP-11/20 assembler by Ken Thompson in 1971. Ken Thompson was very familiar with an earlier editor known as qed from University of California at Berkeley, Ken Thompson’s alma mater; he reimplemented qed on the CTSS and Multics systems, so it is natural that he carried many features of qed forward into ed. Ken Thompson’s versions of qed were the first to implement regular expressions, an idea that had previously been formalized in a mathematical paper, which Ken Thompson had read. The implementation of regular expressions in ed is considerably less general than the implementation in qed.

ed went on to influence ex, which in turn spawned vi. The non-interactive Unix command grep was inspired by a common special use of qed and later ed, where the command g/re/p means globally search for the regular expression re and print the lines containing it. The Unix stream editor, sed implemented many of the scripting features of qed that were not supported by ed on Unix; sed, in turn, influenced the design of the programming language AWK, which in turn inspired aspects of PERL »”>Perl.”

It’s pretty cool how stuff flows and comes together. Who knew or would have thought that a couple simple commands or programs would turn into what we have today.

*Note: starnix refers to the combination of UNIX, Linux and any other ix/ux OS that we work with.

Navicat SSH Tunnel Error – 2013 Lost connection to MySQL server

This post is for anyone out there running any Navicat database tools.  The company, PremiumSoft, that makes the line of Navicat tools is probably best known for there incredible database administration tool, Navicat.  That’s where I first found them.  They make a database admin tool that can connect to MySQL, MS SQL Server, Oracle, SQLite and everything in between.  Aside from being able to connect to just about anything that stores data, once connected you can do so many cool things with your databases in the name of database administration, that it would take me a week to create a post for it all.  Besides, this post isn’t a commercial for Navicat, but I did have to share just how good this product is.  Believe me, it is amazing, and now they have this really wicked data modelling tool that works hand in hand with the database admin tool.  You need to see it to believe it.  Check out their site [link], they have very good demos and lots of information about the products.

My apologies, I digress, the main purpose of my post was to inform any people already using Navicat or any of the other PremiumSoft products about a problem I ran into and a way to fix it.  I am using the software with MySQL databases primarily, but I believe the principle of the fix will apply to any database and server out there, especially Linux.

Now, one of the really cool things about the database admin and data modeling tools is that they can connect to your database via a SSH (Secure Shell Port 22) tunnel, instead of the normal default and usually plain text method.  For example, by default, when you connect to a MySQL server, the username and password you give to the server is sent in plain text, so anyone can read it.  Any command you type on that database console is also sent in plain text, so anyone can read it.  Think about the new user you just created for your new web hosting customer. What if their database username and password fell into the wrong hands.  It might be bad, it might not, it might be localized just to that one customer/user which would be bad enough, but suppose they found an exploit and got root on your server.  Now they have all of your data.  Even if you don’t have any data that is secret, just the hassle alone, not to mention explaining all of this to your customer(s) make this a really bad day.

This isn’t usually a big concern if you are running the database on the same server as the web server (which is common practice in many hosting scenarios), and if your database tools are on the server like the MySQL command line tools and such.  But what if you want to connect to the database from say, your PC?  Like you would do if using a database admin tool like Navicat.  You certainly don’t want all of the data that you will be sending back and forth to be in plain text, right?  Well, now you don’t have to leave it in plain text!  You can setup the connection in Navicat to connect to the Secure Shell server, which means you have an encrypted connection and not plain text.  Then, you can use the SSH tunnel that was created to connect to the database server itself.  What this means is that you use the SSH server to redirect your communications to the database server locally, so no one can see it.  Just like you were sitting at the server itself.

I’ll run through it again real quick, see if this makes sense.  The connection between your PC and the server running database is now encrypted and secure from prying eyes because instead of connecting to the database server directly, you are connecting to the Secure Shell server.  It is now the Secure Shell server that takes your communication and hands it off to the database server internally, so it’s safe from anyone watching outside.  It’s really cool, and just another reason I love the Navicat product so much.  Not to mention Linux as well!

The problem that I found was this, when I created the link to the SSH server in order to talk to the MySQL server, it wouldn’t connect.  I would get the connection to the SSH server, but when it then tried to talk to the database server, the database server kicked it out like no connection could be made.  I tried connecting locally from the Linux console think that maybe I killed some MySQL process that listens for connections, but it was working fine.  I tried it again and again but it just didn’t work.  The error I was getting from Navicat was this:

2013 – Lost connection to MySQL server at ‘reading initial communication packet’, system error: 0

I did some digging and found a basic setting to check.  This didn’t fix the problem, but I thought I would share it here since it has to be set in order for the tunnel to work:

  1. In the sshd config file (/etc/ssh/sshd.config) make sure that AllowTcpForwarding is enabled, because the default is disabled in most cases.

What I finally found to be causing the problem, was TCP_WRAPPERS.  Naturally, in my hosts.allow file I had the IP address of my PC in there, so that I could connect to the server.  So at first this seemed odd that this was my problem.  However, when you think about it, it makes sense.  The connection that is coming to the MySQL server originates not from my PC, but from the SSH server itself.  That’s right, because my connection stops at the SSH server, and then the SSH server sends the data to the database server.  This is a simplified view of things, but it should work to illustrate what’s going on.  Therefore, the simple fix was to add mysqld: localhost or 127.0.0.1 to the hosts.allow file in order to allow the traffic to go through TCP_WRAPPERS and to the MySQL server.  I read more about this once I worked it out, and I saw some “technicians” offering the solution of adding mysqld: ALL to their hosts.allow file.  Egads! I said!  Technically that would work, but damn, don’t open it up to allow everyone into your databases!!!  Just add localhost or 127.0.0.1 and you will be fine, and you will keep out the other riff raff.  I hope this helps some of you out there, enjoy!