Welcome to 2017!

One of my working goals for 2016 was to get rid of old systems, old OS’s and old products.
Well, I partially reach that goal but I still have some old monsters which still run on some prehistoric hardware and software.

Recently I had problems with and old Oracle 9i instance running on RedHat Enterprise Linux 3 on a glorious IBM x365 server and IBM DS4300 Fibre Channel SAN.
We already planned to migrate this Oracle database to a new Oracle instance installed on a beautiful blade server, but some problems on the SAN caused some performance issues and pushed us to accelerate this process.

The problem is that developers are not ready for this migration so I had to think to a temporary solution to fix the performance problem while people working on the migration. The SAN problem required some spare parts that does not exist anymore (that’s the direct response from IBM) so I had to find another way: virtualize!
I already tried some Rhel 3 P2v on Vmware ESXi, and after a lot of googling I found this procedure which seems to work very well.

The only requirement is a Rhel3 boot ISO from RedHat Network or from cdrom, you only need the first ISO/CD.

Install Vmware Converter Standalone and create the vm based on the physical system, you can do a live clone, just pay attention to your services, specially if they are locking files or things like that (think about Oracle tablespaces datafiles in my case).
I don’t explain this step because it’s full of how-to on Vmware Converter, it’s basically a “next next next” process…

After P2v finished you can try to startup your vm (always pay attention to network settings to avoid ip conflicts, disconnect virtual nic) but that’s the result. :(

Change the scsi controller on vm settings to BusLogic. I know it’s labeled as old and deprecated, but hey.. are we working on an old and deprecated OS or what? ;)

Now boot the vm using your Rhel3 ISO and start GNU/Linux in rescue mode typing “linux rescue” and press enter.

Choose language, keyboard layout, ignore network and when you are at the shell prompt you have to chroot using “chroot /mnt/sysimage”

Now you have to edit your /etc/modules.conf file adding BusLogic scsi module and nic module, this is my modules.conf file before…

…and that’s after

Now you have to create a new init image with these modules using your current kernel, look at /boot/grub/grub.conf file, as you can see the line starting with “default” has a value (zero in my screenshot).
This number identify (starting from zero for the first configuration) the default configuration which is loaded by the grub boot manager, in my example the first (zero) configuration is the one using 2.4.21-52.ELsmp kernel.

Use the same kernel version you are booting on the physical server and create a new init image with mkinitrd.
I suggest to not overwrite any other image, just use a different filename (initrd-2.4.21-52.ELsmp.vmware.img istead of initrd-2.4.21-52.ELsmp.img).

Now edit /boot/grub/grub.conf file adding a new configuration, you can copy the existing configuration for your kernel version and change only the title and initrd image path to the new image you created.
You can put it on the 1st place (zero) and leave the default directive as it is, or put the new configuration wherever you want, just remember to use that configuration by default as you complete the P2V prcedure.

The final step is to reinstall the boot manager using grub-install command.

That’s all, now you can boot your vm properly and install vmware tools.
Live long and prosper!

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.

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.

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

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.