ForLinux Blog

ssh keeps track of the systems it is connected to, and is able to tell you if a particular system has changed. It is a security feature – informing you about the change of a fingerprint of the system you are connecting to.
If that change is unexpected, obviously you need to be careful, as it may be a man-in-the-middle attack.

It can be annoying however, as ssh sometimes decides that you not allowed to connect to that new system. It always disallows the log-in if you’re trying to use password authentication, to prevent giving it away to a potential attacker.

You are usually presented with few lines of text explaining that in such a situation, and that you can get into the system with expected fingerprint change by removing a certain line in known_hosts file, where the list of fingerprints is held.

You can do it via any test editor, like Vi, nano or emacs. But you need to find this specific line first. You can use sed to help you do that. For example, remove line 526 from user’s known_hosts file:

sed -i ’526d’ /home/user/.ssh/known_hosts

at that point most sysadmins would think about how to shortcut usage of this command. Bash provides a very useful mechanism to achieve that – namely aliases. You can assign a complicated or lengthy  command to an alias, which may be a lot shorter:

alias ll=’ls -l’

The nice thing is that aliases are substituted before running the command, so we can add further parts of the command at the end, and the following usage is possible:

ll /etc (equivalent to ls -l /etc)

However, our command has a line number in the middle, and aliases don’t work well with variables. You would have to use a system variable and redefine it everytime you were to use the alias – quite annoying!

Lucky for us, bash is rather advanced and allows you definition of functions. Functions can have variables:

function rm_fingerprint { eval sed ‘”$1″!d’ \ /home/user/.ssh/known_hosts; }

Running the command rm_fingerprint 526 will now substitute $1 variable with our line number and remove it – and the good thing is that you can add either alias or function definition to your .bashrc file, so it will be available to you the next time you log in.

1. View all emails in the mailqueue, with destination and mail ID exim -bp

2. If you have emails older than a day in the mail queue which don’t look like they’ll ever be delivered you can remove these; exiqgrep -o 86400 -i | xargs exim -Mrm

3. View all email’s in the queue from a specific address; exiqgrep -f

4. Remove all messages which are in a frozen state; exiqgrep -z -i | xargs exim -Mrm

5. Remove all messages from a specific sender; exiqgrep -i -f | xargs exim -Mf

Recently I’ve had chance to learn that there is a fairly simple way to migrate MSSQL database to MySQL – I’ve run the test myself and succeeded – so if you fancy MySQL, go for it, but read what I’ve learnt first!

The migration tool I used was MySQL Workbench 5.2.42, which provides quite an easy way to migrate databases. However, there are problems created by the same tool (at least in this version, which was the newest at the time of testing) which is converting the MSSQL schemas missing some details.

All of the rows that contained fields holding images were stripped during migration, as the Workbench has created a field too small in size to hold such data. Anther problem was that in some cases fields holding float numbers were converted incorrectly – stripping all after the decimal point and/or cutting the floating number after the second digit after the decimal point – which, of course, is unacceptable.

These two reasons alone should make you seriously consider if you really want to migrate. In my opinion it’s OK when your database is rather small and you know it well, and you are aware where and what sort of data is held and it’s purpose – but even then you may need to rewrite your queries and some code to work with your new database. This depends on your solution.

The Workbench provides a way to amend the schemas during the migration process – so if you know where some vulnerable data is kept then theoretically you could prevent any unwanted and/or harmful changes to the schemas.

Personally, I’d wait for a newer release of Workbench and hope it’ll fix all these bugs. But if you have no choice or time then this could be a solution for you.

If you’re a die hard javascript aficionado and haven’t bothered to look at jQuery you might be thinking, what’s all the fuss about? The best way to explain is by a code example.

The scenario is, your manager calls you into the office and sayes “We urgently need a javascript program writing to get a value from a text box and then output to the screen.”

You first write the html to draw an input box and button:

<input id="textbox" type="text" />
<button id="submitbtn">Get textbox value</button>

Now we’ve got to write the javascript/jQuery to respond to the on click event of the button, by output a message box with the value of the text box, the jQuery way is to do this:

The jQuery way is to do this:

1
2
3
4
5

// Submit button click event
$("#submitbtn").click(function() {
    // Textbox value alert message
    alert( 'Jquery: ' + $("#textbox").val()  );
});

The javascript way is this:

1
2
3
4
5
6
7
8
9
10
11
12

// Initialize event listener
initializeEventListener();
 
// Add onclick event listener
function initializeEventListener() {
    document.getElementById("submitbtn").addEventListener("click", alertMessage);
}
 
function alertMessage(e) {
    // Textbox value alert message
    alert( 'Javascript: ' + document.getElementById("textbox").value );
}

In my opinion, I think jQuery is much easier to read, write and understand. I hope this simple example illustrates why jQuery has become so popular. To understand more about the power of jQuery you must understand selectors which I will talk about next month in part two.

The White Screen of Death (WSOD) is a problem often encountered when developing on Drupal. Usually, most debugging output from PHP is suppressed, so when a problem with the code is encountered, PHP stops and a blank screen is presented to the user. This doesn’t help the development, when the error is usually vital to fix the problem.

The immediate way to fix this is by adding the following lines to the main index.php file:

error_reporting(E_ALL);
ini_set(‘display_errors’, TRUE);
ini_set(‘display_startup_errors’, TRUE);

This will send all debugging output to the screen, including simple notices (to remove notices from the output, change the first line to ‘error_reporting(E_ALL ^ E_NOTICE);’).

Sometimes you don’t want to reveal your errors to everyone who can view the server. In this situation, wrap the code in an ‘if’ statement that checks for the connecting IP address:

if ($_SERVER['REMOTE_ADDR'] == ’123.123.123.123′) {
  error_reporting(E_ALL);
  ini_set(‘display_errors’, TRUE);
  ini_set(‘display_startup_errors’, TRUE);
}

This will limit output to the IP address ’123.123.123.123′. If you’re unsure about your IP address, just ask google:

If you are running a server after the initial set-up, creating a redundancy plan in case of failure or accidental solutions is a must. The well known free backup solutions such as Bacula and Amanda now have some competition. Three products ‘Burp’ ‘Obnam’ and Backshift are the new comers that might be worth investigating.

Burp: http://burp.grke.net/

Burp is a network backup and restore program. It uses librsync in order to save network traffic and to save on the amount of space that is used by each backup. It also uses VSS (Volume Shadow Copy Service) to make snapshots when backing up Windows computers.

Obnam: http://liw.fi/obnam/

Obnam is an easy, secure backup program. Backups can be stored on local hard disks, or online via the SSH SFTPprotocol. The backup server, if used, does not require any special software, on top of SSH. Some features that may interest you:

• Snapshot backups. Every generation looks like a complete snapshot, so you don’t need to care about full versus incremental backups, or rotate real or virtual tapes.
• Data de-duplication, across files, and backup generations. If the backup repository already contains a particular chunk of data, it will be re-used, even if it was in another file in an older backup generation. This way, you don’t need to worry about moving around large files, or modifying them.
• Encrypted backups, using GnuPG.

Backshift: stromberg.dnsalias.org/~strombrg/backshift/

Backshift is a deduplicating (variable-sized, content-based blocks), compressing (xz or bz2) backup program. Full saves and incrementals are pretty indistinct other than the amount of data transmitted, somewhat like with “rsync –link-dest” but without the huge number of hardlinks.

So as you can see, three new and potential solution providers for keeping your own backups either on server or offsite for disaster recovery.