Friday, May 16, 2014

HOWTO: Clean up /boot partition in Ubuntu

Normally, Ubuntu has a few Kernel Updates so, if you installed your Computer with a /boot Partition of 200MB it may get full and it will need some Cleaning Up task.

This one-liner that I've found will delete all the kernels that are not in use and it will just keep the one that is being used at the moment. It works like a charm!

dpkg --get-selections|grep 'linux-image*'|awk '{print $1}'|egrep -v "linux-image-$(uname -r)|linux-image-generic" |while read n;do apt-get -y remove $n;done

I hope it helps!

Thursday, May 15, 2014

Puppet: Generating password hashes

I became across the need of changing the Password of one of our Users on most all of our Servers, so we decided to build something in Puppet:.

For this task, we will use the Type USER and also the Type SCHEDULE wich is part of the Metaparameters. See: http://docs.puppetlabs.com/references/latest/metaparameter.html
With this "schedule" metaparameter, our Puppet Module will change the Password of the User once a day.
To generate a password hash to use within the Puppet Modules Manifests files we are going use the mkpasswd utility, which is available in the "whois" package (and it works!). In this case we will use Puppet’s "generate" function to call "mkpassword" and return the generated the hash version of the password.

So, our Manifest will look something like this:

$pass   = 'YOUR_PASSWORD_HERE'

schedule { 'everyday':
        period  => daily,
        range   => "8 - 18",
        repeat  => 1,
}

user { 'backup':
        name    => backup,
        ensure  => present,
        password => generate('/bin/sh', '-c', "mkpasswd -m sha-512 ${pass} | tr -d '\n'"),
        schedule => 'everyday',
}

This is an easy and effective way to make it work.

The Puppet Documentation says that we can use the built-in "sha1" function to generate a hash from a password, but sadly didn't work for me (maybe I'm to dumb to make it work), so I researched a bit and I found the Solution above.

As always, I hope this can help any lost soul around there. :)

Fixing MySQL replication after a faulty query

When you check your MySQL Slave Status and you have some of the following Statements:

mysql> SHOW SLAVE STATUS \G
*************************** 1. row ***************************
             Slave_IO_State: Waiting for master to send event
                Master_Host: 1.2.3.4
                Master_User: slave_user
                Master_Port: 3306
              Connect_Retry: 60
            Master_Log_File: mysql-bin.001079
        Read_Master_Log_Pos: 269214454
             Relay_Log_File: slave-relay.000130
              Relay_Log_Pos: 100125935
      Relay_Master_Log_File: mysql-bin.001079
           Slave_IO_Running: Yes
          Slave_SQL_Running: No
            Replicate_Do_DB: mydb
        Replicate_Ignore_DB:
         Replicate_Do_Table:
     Replicate_Ignore_Table:
    Replicate_Wild_Do_Table:
Replicate_Wild_Ignore_Table:
                 Last_Errno: 1146
                 Last_Error: Error 'Table 'mydb.taggregate_temp_1212047760' doesn't exist' on query. Default database: 'mydb'. 
Query: 'UPDATE thread AS thread,taggregate_temp_1212047760 AS aggregate
        SET thread.views = thread.views + aggregate.views
        WHERE thread.threadid = aggregate.threadid'
               Skip_Counter: 0
        Exec_Master_Log_Pos: 203015142
            Relay_Log_Space: 166325247
            Until_Condition: None
             Until_Log_File:
              Until_Log_Pos: 0
         Master_SSL_Allowed: No
         Master_SSL_CA_File:
         Master_SSL_CA_Path:
            Master_SSL_Cert:
          Master_SSL_Cipher:
             Master_SSL_Key:
      Seconds_Behind_Master: NULL
1 row in set (0.00 sec)

mysql>

You will need to Repair your Replication. Fixing the problem is easy, but you need to be careful.
The Solution is to tell the slave to skip the invalid query, by running the following:

mysql> SET GLOBAL SQL_SLAVE_SKIP_COUNTER = 1; START SLAVE;

And then, we will check if the replication is working correctly again:

mysql> SHOW SLAVE STATUS \G
*************************** 1. row ***************************
             Slave_IO_State: Waiting for master to send event
                Master_Host: 1.2.3.4
                Master_User: slave_user
                Master_Port: 3306
              Connect_Retry: 60
            Master_Log_File: mysql-bin.001079
        Read_Master_Log_Pos: 447560366
             Relay_Log_File: slave-relay.000130
              Relay_Log_Pos: 225644062
      Relay_Master_Log_File: mysql-bin.001079
           Slave_IO_Running: Yes
          Slave_SQL_Running: Yes
            Replicate_Do_DB: mydb
        Replicate_Ignore_DB:
         Replicate_Do_Table:
     Replicate_Ignore_Table:
    Replicate_Wild_Do_Table:
Replicate_Wild_Ignore_Table:
                 Last_Errno: 0
                 Last_Error:
               Skip_Counter: 0
        Exec_Master_Log_Pos: 447560366
            Relay_Log_Space: 225644062
            Until_Condition: None
             Until_Log_File:
              Until_Log_Pos: 0
         Master_SSL_Allowed: No
         Master_SSL_CA_File:
         Master_SSL_CA_Path:
            Master_SSL_Cert:
          Master_SSL_Cipher:
             Master_SSL_Key:
      Seconds_Behind_Master: 0
1 row in set (0.00 sec)

mysql>

Now you will also see that "Seconds Behind Master" is "0" and "Slave IO Running" and "Slave SQL Running" are set to "Yes" now.
Everything should run smoothly now :)