Steve Jobs

Five years ago Steve Jobs passed away, I want to remember him with Richard Stallman’s words:

Steve Jobs, the pioneer of the computer as a jail made cool, designed to sever fools from their freedom, has died.
As Chicago Mayor Harold Washington said of the corrupt former Mayor Daley, "I'm not glad he's dead, but I'm glad he's gone."

Nobody deserves to have to die - not Jobs, not Mr. Bill, not even people guilty of bigger evils than theirs. 
But we all deserve the end of Jobs' malign influence on people's computing.

Unfortunately, that influence continues despite his absence. We can only hope his successors, as they attempt to carry on his legacy, will be less effective.


Upgrade MySQL 5.1 to 5.7

I love RedHat/Centos 6.x, I think it’s one of the most stable and reliable GNU/Linux distros in the recent history of this OS, it’s actually one of the most used, and yes, I love it because it doesn’t use the cursed systemd (I can get used to it but don’t ask me to love it…).

Despite of all its good features Rhel/Centos 6.x family has one big fault, it has too many old packages, and MySQL is one of them.
Consider that the MySQL version distribuited by the official repository is 5.1 which was released in 2005, 11 years ago!!!
Recently I decided to upgrade some of our MySQL instances and I struggled searching for the right procedure to reach the goal.

Apparently everything seems easy, install the official MySQL community yum repository…


…and launch a “yum upgrade”, right? Well, no….

Check MySQL error log and the cause seems to be the innodb_file_format.


Googling around I found an easy solution, add “innodb_data_file_path = ibdata1:10M:autoextend” to your my.cnf file and restart, easy!
Well again no…


But how can I run mysql_upgrade if my MySQL instance doesn’t start?
Ok take a breath and rollback to 5.1, this time let’s try the upgrade step by step, for instance let’s upgrade from 5.1 to 5.5 and then from 5.5 to 5.7.

For the upgrade to version 5.5 I suggest to use Remi repository, enable it and EPEL using rpm packages.
Remember to enable Remi repository and not only Safe Remi repository (change enable=o to enable=1 in /etc/yum.repos.d/remi.repo file).


Now launch “yum upgrade”, check that MySQL is running with “service mysqld status” and eventually start it with “service mysqld start” and launch mysql_upgrade

06 08

Now if you try to upgrade to MySQL 5.7 via the official MySQL Community repo you will get this bad conflict with some libraries


To avoid that mess you have to:

  1. install MySQL-shared-compat-5.6.33-1.el6.x86_64.rpm (rpm -ivh MySQL-shared-compat-5.6.33-1.el6.x86_64.rpm)
  2. remove compat-mysql51-5.1.54-1.el6.remi.x86_64 (rpm -e compat-mysql51-5.1.54-1.el6.remi.x86_64) and remove Remi and EPEL repositories if you don’t need them
  3. install MySQL Community repository
  4. check your repository


After that upgrade to MySQL 5.7 launching “yum upgrade”


Ok, now check that MySQL 5.7 is running, launch mysql_upgrade and follow instructions for upgrade tables or anything else.



Dell Latitude E7470

Finally I changed my working laptop, 8 years ago I switched from an old IBM ThinkPad R50 (yes! It was a true IBM ThinkPad!) to a T500 ThinkPad from Lenovo.

It was a good pc, not very powerful but sturdy, with a full size keyboard and so many options for upgrade like any other ThinkPad, a war machine!
Now the glorious T500 needs to retire, everything works but I need an SSD, the screen resolution was ridiculous, CPU and RAM were inadequate to run any virtual machine in local, so I started to look around for a new pc, these were the requirements:

  • CPU at least Core i5
    I don’t need a huge computing power beacause I don’t have to render or compile source (I usually spend most of my working time in an ssh shell) and I don’t want a Boeing 747 fan on my side and a heavy PSU.
  • RAM at least 8GB
  • SSD storage (I think I don’t have to explain why…)
  • Display resolution at least 1920×1080 (I don’t want to go crazy with external display for work)
  • 14″ chassis (I hate those horrible 15,6″ chassis with the imho useless numbers keypad)
  • Business line laptop

I started looking for a laptop with these requirements and I came to the Dell Latitude 5000 series, nice line, solid, realiable and with a great customer care (this is my experience with any Dell product, pc or server).
Sadly I had a bad experience with a Dell partner so I started to looking around for an alternative… but last week one of our historic wholesale providers started to sell Dell products and I found the shiny Latitude E7470 which fits perfectly into my requirements to an honest price… check, check, check!


So, here it is my brand new laptop, my first experience with a Latitude product.

My first impressions:

  • it’s thin and light (it’s branded as ultrabook although I don’t think it fits the Intel requirements for that) but it’s super sturdy!
  • the display is AWSOME! It fully deserves all the good feedbacks you can find online.
  • great I/O and options, It has 3 USB 3.0 ports (not bad for a thin laptop), two display output (mini DP and HDMI), it has uSIM slot and also an integrated smartcard reader.
  • nice storage performance (more than 500 MBps in sequential read and more than 250 MBps in sequential write) and I read It’s possible to install a second SSD on another slot.

The only complaint I had is about some keys (for example HOME and END keys which I use a lot) that need the FN key, and obviously the stupid Windows 10 scaling which blurs everything (but this is not a Dell problem).

And yes… I have to use Windows for now… :\

Here is the beast

e7470_1 e7470_2


Psi Probe error

If you work with j2ee application you need Tomcat and not some stupid gigantic enterprise application server, and if you work with Tomcat you really need Psi Probe because it’s the best Tomcat manager you can find all over the galaxy.

Recently I noticed a strange behavior from this tool after some activities focused on security hardening.
I had some old Tomcat 6 instances where I want to get rid of Tomcat version inside error pages and inside http headers, after I removed these data Psi Probe went crazy with a nasty exception “java.lang.RuntimeException: No container found for your server” :\


After some googling I found that Psi Probe uses ServerInfo to determine the Tomcat version, I completely erased this information for security issues so the poor Psi Probe lost its mind…

The solution is quite simple, open the probe.war archive (you can unzip it) and change the WEB-INF/spring-probe-resources.xml file this way:

  1. find “forceFirstAdaptor” variable inside the “com.googlecode.psiprobe.beans.ContainerWrapperBean” and change it’s value from false to true
  2. change the list inside the “adaptorClasses” property putting as first record the value referring to your Tomcat version (in my case “<value>com.googlecode.psiprobe.Tomcat60ContainerAdaptor</value>”)


After that you only have to repackage the files and deploy the war.



Nmon is wonderful, if you need to monitor you server resources in realtime it’s your tool, if you need to monitor resources statistics over time and save them it’s your tool, if you need to check what’s the status of your server’s resources in a precise moment it’s your tool.
I can’t imagine a scenario where you don’t need nmon, more useful and flexible than sar, simpler and more straightforward than any other web based tool, imho it’s the perfect companion for collectd.

Sadly during on my last server setup I noticed that the latest nmon package distributed by Epel repository lacks of all the cron scripts you need to automate nmon startup and data collection, which imho are very useful also if you get nmon directly from the official GNU/Linux project site.

Here’s some hints from the old packages, first of all create the /var/log/nmon directory with nobody user as owner.


Create a new script in cron for example /etc/cron.d/nmon-script.
This cron will launch /usr/bin/nmon-script every day (for example at midnight).


Now you have to create the /usr/bin/nmon-script file (remember to give execution permission) which has:

  • some configuration parameters in /etc/sysconfig/nmon-script
  • commands to kill, cleanup old files (disabled in the example, note the leading # at line 15)


Create the /etc/sysconfig/nmon-script which contains some useful varibles (the directory where to save nmon archive files, retention and nmon options).


That’s enough, at the next midnight nmon will start to save your resources statistics in /var/log/nmon/<hostname>_AAMMDD_0000.nmon files.


You can download all the scripts and files to quickly setup the nmon-script:
nmon-script.tar.gz (656B)
SHA256 hash: 953667d8e2806e4858426fb000d7f3cfc898c53e26ffc7694bf2722442668aa8


Nmon is not distributed by Epel but from RPMForge!!
Although RPMForge version is quite old it has nmon-script cron, I suggest to move to the latest version from the official GNU/Linux project site which do not have nmon-script.

« Post precedenti