Posted on

CentOS 7 aapt ELF and Missing Lib

While building an Android Studio app the build failed with aapt errors.   The aapt part of the build started off with a missing error.    Turns out I had already installed the zlib library with yum install so already existed in /usr/lib64/.    The problem was with the library path.   That is easily fixed.

Put these commands in your ~/.bashprofile as well:


However the ELFs were not happy.    For those that don’t know what an ELF error means, it has something to do with byte offsets and library file formats.  Turns out it is a cryptic way of telling you the program is trying to load a 64-bit version of the library it needs instead of the 32-bit version.

Again an easy fix;

# sudo yum install zlib.i686

# LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/lib/;/usr/lib64/;

The .i686 versions of the yum install kits are the 32-bit versions of the libraries.  They are placed in the /usr/lib directory.  Setting LD_LIBRARY_PATH helps the 32-bit dynamically linked executable find the proper link library.

Now on to building this Android app on my CentOS dev box.

Posted on

Creating A Self Contained WordPress GUI Dev Box

After a few days of doing a whole lot of nothing as I recover from surgery I decided that it was time to start doing some computer hacking.   I’m not nearly as tired today as I have been.    The post-surgery cobwebs are mostly gone and I’m thinking clearly enough to do some productive computer work.   I’m still not 100% so staying away from code for another day may not be a bad idea.   I figure creating an upgraded WordPress Development Kit box has no chance of wreaking havoc on my published WordPress plugins.   Today is going to be an “upgrade my virtual development environment” day.

The task at hand?   Upgrade my WordPress Development Kit Vagrant box.

The original box runs a fully self-contained GUI development box on CentOS 6.5 running a local version of WordPress 3.9 with some PHP developer tools like NetBeans at-the-ready.     This makes it easy to “pack up and move” my entire development and testing system and bring it to any laptop that can run VirtualBox.     This also gives me a solid baseline to get new developers started with the same exact tools and user experience which expedites the process of getting new people online with helping code the WordPress plugins.

Today I am upgrading the WP Dev Kit Box to run on CentOS 7.     CentOS 7 has an upgraded desktop GUI and, more importantly, is virtualization-aware with built-in OS-level tools that detect when it is running as a VirtualBox guest.   It should make for a more seamless experience when going between the virtual guest box and the host system.   I’ve also moved my development over to phpStorm versus NetBeans so an eval copy of phpStorm will be installed along with the latest free version of NetBeans.   SmartGit and grunt will remain as part of the plugin development toolkit.    WordPress will be the latest production version of 4.x.

Guest System Specifications

  • CentOS 7 with GUI
  • 2GB RAM
  • 20GB dynamic HDD
  • 4 CPU cores
  • 1x 32MB video at 1440 x 1050 resolution
  • no audio
  • USB 2 support
  • NAT networking
  • Bidirectional clipboard.
  • Bidirectional drag-and-drop.
  • Port Forwarding localhost ( port 4567 to guest port 22 (ssh).
  • Standard vagrant user credentials.

Augmenting Minimal Setup

The box is installed using minimal install for CentOS 7.  The following elements have been updated to get to a standard WordPress plugin development environment:

  • vim installed
  • gvim installed
  • vagrant user added to sudoers file
  • GNOME desktop added
  • Graphical Admin Tools added
  • GUI runlevel (5) set as default
  • Install VirtualBox guest additions
  • Run the software update for all packages to 19-Oct-2014
  • Added the vagrant “base box public key” to the authorized keys file (allows vagrant scripts to run commands)

CentOS 7 GUI Base Box

The above configuration, without the developer tools like NetBeans, phpStorm, SmartGit, and Grunt nor the WordPress install is published as the “CentOS 7 GUI Base” box on VagrantCloud.   It is this foundation on which the WP Dev Kit Box will be built.

CentOS 7 WP Dev Kit Box

Now that the base GUI box is built it is time to layer on the WordPress system and development tools.  The following items are added to the mix:

  • Install PHP and PHP MySQL library.
  • Start httpd web server at boot (note: CentOS 7 uses the systemctl app to configure startup apps)
  • Install MariaDB (public domain MySQL branch) and set to start at boot.
  • Disable SELinux
  • Create the WordPress database.
    • database name: wordpress
    • database user: wpuser
    • database password: wppasswd
  • Install WordPress 4.0 and activate up to the “Enter site title, admin username, admin password” stage.
  • Install git
  • Install SmartGit 6.0.7 eval
  • Install NetBeans 8.0.1 HTML & PHP configuration
  • Install phpStorm 8.0.1 eval
  • Add Selenium IDE with GoTo lib, LastPass, and FireBug extensions to Firefox.

The WP Dev Kit box is also available in the Vagrant Cloud


Posted on

Installing Sass on CentOS 6.5

SLP Sass Banner

I just discovered that Sass is missing from my WordPress Development Kit Vagrant box.   My Vagrant box is on the latest CentOS 6.5 release and, luckily, setting up Sass is very simple for vanilla CentOS 6.5 users.  It is literally a two-step process:

$ sudo yum install rubygems
$ sudo gem install sass

Now I can add this to the NetBeans executables configuration by adding the path /usr/bin/sass.

Configuring Sass in NetBeans
Configuring Sass in NetBeans

Now I can edit my .scss files and have the corresponding .css files auto-generated right from NetBeans.  Nice!

Posted on

Forcing Display Resolution on VirtualBox and CentOS 6.5

VirtualBox Display Resolution

Last evening my Oracle VM VirtualBox development system stopped auto-detecting my guest display resolution when I re-connected my laptop to the docking station.   The maximum resolution I could get was 1600 x 1200 instead of the native display resolution of 1920 x 1200.   After literally hours of research this morning with many dead-ends I found the proper solution.  Here is my “cheat sheet” on how I got it working in my dev environment.

For CentOS 6.x systems the system-config-display command is obsolete.  The replacement, for today anyway, is xrandr.

VBoxManage is useless unless you are running the virtual box management service, which is not a typical default setup for VirtualBox on a Windows host.

Updating VirtualBox guest additions does not help if you already have a current version.  You WILL need VirtualBox guest additions for the display driver interface on the guest operating system to function properly.   If you don’t have that installed you can use the GUI interface and finding the “machine / install guest additions” option.   It should drop a CD image on your CentOS 6.5 desktop that you can run with autoprompt.  Run it as a priv’ed user such as root.

Once you have VirtualBox guest additions installed login to your system and get to the command prompt.    Switch to a priv’ed user.  I login as my standard account and execute the command:

# sudo su -

To setup xrandr and add a manual resolution to your list you need to get the configuration setting line.   Use the utility cvt to get the right command line.  Here is the command to find the xrandr mode for a 1920 x 1200 resolution:

# cvt 1920 1200

It returns the line:

Modeline "1920x1200_60.00" 193.25 1920 2056 2256 2592 1200 1203 1209 1245 -hsync +vsync

Those are the parameters for my particular monitor configuration.  It is a basic reference label, a configuration tag, and monitor timing, resolution, and sync timings.  This will be specific to your monitor so run the cvt command, don’t just copy the line here.

For xrandr you will need everything AFTER the Modeline portion.

Find out what monitors your system thinks it has.  I have 3 monitors so this is my output:

# xrandr
Screen 0: minimum 64 x 64, current 4800 x 1200, maximum 16384 x 16384
VBOX0 connected 1600x1200+0+0 0mm x 0mm
   1600x1200      60.0*+
   1440x1050      60.0  
   1280x960       60.0  
   1024x768       60.0  
   800x600        60.0  
   640x480        60.0  
VBOX1 connected 1600x1200+1600+0 0mm x 0mm
   1600x1200      60.0*+
   1440x1050      60.0  
   1280x960       60.0  
   1024x768       60.0  
   800x600        60.0  
   640x480        60.0  
VBOX2 connected 1600x1200+3200+0 0mm x 0mm
   1600x1200      60.0*+
   1440x1050      60.0  
   1280x960       60.0  
   1024x768       60.0  
   800x600        60.0  
   640x480        60.0  
  1920x1200_60.00 (0x10c)  193.2MHz
        h: width  1920 start 2056 end 2256 total 2592 skew    0 clock   74.6KHz
        v: height 1200 start 1203 end 1209 total 1245           clock   59.9Hz

Now to add the manual entry so I can later use the CentOS 6.5 GUI display manager to set the resolution:

# xrandr --addmode VBOX0 "1920x1200_60.00"
# xrandr --addmode VBOX1 "1920x1200_60.00"
# xrandr --addmode VBOX2 "1920x1200_60.00"

Now I can go to System / Preferences / Display on the system admin menu.

CentOS 6.5 Forced Display Resolution
CentOS 6.5 Forced Display Resolution
Posted on

Update Git On CentOS 6.3

As of this writing, CentOS 6.3 has a default git version of 1.7.1-2.  This version is what you will have installed if you run the typical install command:

# yum install git

However, GitHub and many other services require git version 1.7.10 or higher. It turns out there is a very easy way to get git.  You need to do this from a privileged account, but then the process is simple.

Add RPM Forge to Yum Repos

# wget ''

# rpm --import

# rpm -i ''

# yum clean all

Install New Version from RPM Forge

# cd /etc/yum.repos.d
# vim (or whatever) rpmforge.repo

change the enabled=0 flag to enabled=1 in the section labelled [rpmforge-extras].

# yum  update
# yum provides git

This will return a longer list of available git modules.

Install the newer git by copying the FULL REPO NAME.   For example:

# yum install git- 
# git --version

You should have the new release installed.

Now go back and edit rpmforge.repo and disable the rpmforge-extras repository.  Then ensure the yum directory is cleaned up.

# yum update
Posted on

weaken … XS version of Scalar::Util

weaken is only available with the XS version of Scalar::Util

Every time we upgrade Perl on our CentOS box we get this message.  The fix is very simple .  Re-install Scalar::Util via CPAN.  For some reason the bindings are not updated and the proper version needs to be re-registered with the Perl modules directory.

The command sequence you need to run to restore the Scalar::Util functionality is..

> force install Scalar::Util

The simple command line cpan -i Scalar::Util will not do the trick.  If you already have Scalar::Util installed this command will skip the installation telling you so.

You will also find references online to needing to install perl-Task-Weaken.  That did nothing for us.

Since this is the third time this has happened on our development server running CentOS 5, we figured we’d post it here and maybe help someone else out.  If nothing else we’ll remember what we did in 10 less Google searches next time around!

Posted on

Upgrading Logwatch on CentOS 5


I finally got tired at looking at the thousand-plus line daily reports coming to my inbox from Logwatch every evening.  Don’t get me wrong, I love logwatch.  It helps me keep an eye on my servers without having to scrutinize every log file.  If you aren’t using logwatch on your Linux boxes I strongly suggest you look into it and turn on this very valuable service.  Most Linux distros come with this pre-installed.

The problem is that on CentOS the version of logwatch that comes with the system was last updated in 2006.   The logwatch project itself, however, was updated just a few months ago.  As of this writing the version running on CentOS 5 is 7.3 (released 03/24/06) and the version on the logwatch SourceForge site is 7.3.6 (updated March 2010).   In this latest version there are a log of nice updates to the scripts that monitor your log files for you.

The one I’m after, consolidating brute force hacking attempt reports, is a BIG thing.  We see thousands of entries in our daily log files from China hackers trying to get into our servers.   This is typical of most servers these days, however in many cases ignorance is bliss.  Many site owners and IPPs don’t have logging turned on because they get sick of all the reports of hacking attempts.  Luckily we block these attempts on our server, but our Fireant labs project is configured to have iptables tell us whenever an attempt is blocked at the kernel level (we like to monitor what our labs scripts are doing while they are still in alpha testing).   This creates THOUSANDS of lines of output in our daily email.   Logwatch 7.3.6 helps mitigate this.

Logwatch 7.3.6 has a lot of new reports that default to “summary mode”.  You see a single line entry for each notable event, v. a line for each time the event occured.  For instance we see a report more like this for IMAPD..

 [IMAPd] Logout stats:
 User | Logouts | Downloaded |  Mbox Size
 --------------------------------------- | ------- | ---------- | ----------
 cpanel@localhost |     287 |          0 |          0 |       4 |          0 |          0
 291 |          0 |          0

Versus the older output like this:

--------------------- IMAP Begin ------------------------
 **Unmatched Entries**
LOGIN, user=cpanel@localhost, ip=[::ffff:], port=[32811], protocol=IMAP: 1 Time(s)
LOGIN, user=cpanel@localhost, ip=[::ffff:], port=[32826], protocol=IMAP: 1 Time(s)
LOGIN, user=cpanel@localhost, ip=[::ffff:], port=[32981], protocol=IMAP: 1 Time(s)

LOGIN, user=cpanel@localhost, ip=[::ffff:], port=[32988], protocol=IMAP: 1 Time(s)

LOGIN, user=cpanel@localhost, ip=[::ffff:], port=[33040], protocol=IMAP: 1 Time(s)

LOGIN, user=cpanel@localhost, ip=[::ffff:], port=[33245], protocol=IMAP: 1 Time(s)

LOGIN, user=cpanel@localhost, ip=[::ffff:], port=[33294], protocol=IMAP: 1 Time(s)

LOGIN, user=cpanel@localhost, ip=[::ffff:], port=[33310], protocol=IMAP: 1 Time(s)
 repeat 280 more times...

So as you can imagine, with 10 sections to our logwatch report, the new summary reports make our email a LOT easier to scan for potential problems in our log files.

Upgrading Logwatch

In order to get these cool new features you need to spend 10 minutes, 5 if you’re good with command line Linux, and install the latest version of logwatch. In essence you are downloading a tarzip that is full of new shell and Perl script files.  The install does not compile anything, it simply copies scripts files to the proper directory on your server.

Our example here are all based on the default CentOS 5 paths.

  • Go to a temp install or source directory on your server.
    # cd /usr/local/src
  • Get the source for logwatch
    # wget
  • Extract the files
    # tar xvfz logwatch-7.3.6.tar.gz
  • Make the install script executable
    # cd logwatch-7.3.6
    # chmod a+x
  • Run the script & enter the correct paths for logwatch:
    # ./
    ...Logwatch Basedir [/usr/share/logwatch]  : /etc/log.d
    ...Logwatch ConfigDir [/etc/logwatch] : /etc/log.d
    ...temp files [/var/cache/logwatch] : <enter>
    ...perl [/usr/bin/perl] : <enter>
    ...manpage [/usr/share/man] : <enter>


That’s it.  You should now be on the latest version of logwatch.

You can tweak a lot of the settings by editing the files in /etc/log.d/default.conf/services/<service-name>, for example we ask logwatch to only tell us when someones attempt to connect to our server has been dropped more than 10 times by our Fireant scripts (we do this via the iptables service setting).

Hope you find this latest update useful.   We certainly did!