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

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.

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

[EDIT]

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.

Well, time has passed since the last update on this blog, it’s time to do a quick recap on some of my new year’s goals.

First of all I archived one of the most important and desired goals: swimming!
During these first 3 and a half months I went swimming almost two times a week, sometimes three, starting with 20 pools at low pace and raising up to the actual 40 pools in 40-45′; as I expected each time I go swimming I feel better and better, actually it’s the only thing makes me feel really good and the only weapon I have against my terrible working stress…

Talking about work I can’t deny we have huge emergencies during the last month, as I predicted (I repeat the same thing for years…) we had great problems on our biggest customer with some stupid custom applications deployed on a huge WebSphere Portal cluster.
Remember the KISS model? My company did the exact opposite, this application produced huge out of memory problems on the Portal jvm, I sent logs and begged developers to fix the huge amount of exceptions we collected but nothing changed  since the problem went really crytical; at the end they fixed the exceptions and made changes to the code and all returned to work normally.

Remember: if you are working on some big enterprise software meatball like WebSphere Portal DO NOT deploy custom applications on that product unless you are ABSOLUTELY sure of their quality!
Use some easy Tomcat or Jboss instance, hundreds of them if you need to scale out for a big workload, you will live better, spent an infinitesimal part of money and will get a better result.

And what about Eve?
Well I finally get a second account, I used the buddy program and made a brand new cyno/scout alt and I’m skilling for the biggest and most ambitious project since I started play: two jumpfreighter pilots!
Yes, it’s not a typo, I need two JF pilots for take my future Rhea in null space and also in hi-sec, so I need a second JF pilot in npc corp to fly safe and now lose this huge ship in some stupid war brawl…
Look at that beauty, isn’t it gorgeous?

I know there are many good hypervisors, some of them are free and are full of advanced features (someone say oVirt?) but if you want to work into virtualization you can’t ignore Vmware.

Don’t get me wrong, I like Vmware products and I use them every day on servers, on my lab workstation and also on my old duty laptop, but sometimes customers tend to be too much conservative and sticked to it.
For example I found many people who prefer to use free Vmware ESXi (without vcenter, vmotion or svmotion) insted other solutions (free or low cost) with all the advanced features that any server hypervisor must have.

One of the most evident limitations of the free ESXi is the client which require a Windows OS, fortunately there’s a wonderful free solution for that: ESXi Embedded Host Client.

The installation is really easy, first of all you must download the installation package (esxui_signed.vib) from the official site and copy on the ESXi host (you can use the datastore browser or copy via scp).
After that you must access ESXi using ssh protocol, and launch “esxcli software vib install” command

That’s all, now you can open your browser to url https://youresxiserver/ui and…

What?!?!?
Keep calm, if you’re using ESXi 5.5 prior to update 2 there are some known issues, this is one of them.
To solve it we must edit  /etc/vmware/rhttpproxy/endpoints.conf, but the file is locked (operation not permitted error), so we must copy it to a temporary location (for example /tmp), edit it and copy on the original path again.

The only change you must to is to comment the line starting with /ui putting a # at the beginning (force write on exit with :x! vi command)

Now copy the edited file into its original path with “cp /tmp/endpoints.conf /etc/vmware/rhttpproxy/endpoints.conf” and restart rhttpproxy daemon with “/etc/init.d/rhttpproxy restart”

Now try to browse https://youresxiserver/ui/ url (don’t forget the trailing /, another bug in ESXi 5.5U2 and earlier versions) and…

Mission accomplished!