Upgrading Zenoss 4.2.3 to 4.2.4 on CentOS 6.4

The guides I am using for this procedure includes:

The resources above have somewhat conflicting information about upgrading to 4.2.4.  The installation guide lists a long set of instructions to perform but the blog, including the comments, suggest a much simpler course of action.

Some of the steps listed in the installation guide is not even required in my opinion.  For instance, the installation guide included the upgrade of MySQL server as part of the Zenoss upgrade.  However, as I found out after testing a fresh install of Zenoss 4.2.4, the MySQL version installed by the 4.2.4 auto-deploy script is the same as the one used by the 4.2.3 auto-deploy script.  Therefore, I would assume that not all the of the listed actions from the installation guide are totally necessary.

Let’s try the simplest upgrade as suggested by the blog.

Grab the 4.2.4 installer rpm.

# wget http://downloads.sourceforge.net/project/zenoss/zenoss-4.2/zenoss-4.2.4/zenoss_core-4.2.4.el6.x86_64.rpm

Stop Zenoss daemons.

# service zenoss stop
Daemon: zenwinperf stopping...
Daemon: zeneventlog stopping...
Daemon: zenwin stopping...
Daemon: zenjmx stopping...
Daemon: zenrrdcached stopping...
Daemon: zenprocess stopping...
Daemon: zencommand stopping...
Daemon: zenperfsnmp stopping...
Daemon: zenmodeler stopping...
Daemon: zentrap stopping...
Daemon: zenactiond stopping...
Daemon: zenstatus stopping...
Daemon: zensyslog stopping...
Daemon: zenping stopping...
Daemon: zeneventd stopping...
Daemon: zenjobs stopping...
Daemon: zenhub stopping...
Daemon: zopectl .
daemon process stopped
Daemon: zeneventserver stopping...

Install redis.

# yum --enablerepo=epel install redis

Install the installer rpm.

 # rpm -Uvh zenoss_core-4.2.4.el6.x86_64.rpm
Preparing...                ########################################### [100%]
Upgrading from zenoss 4.2.3 to zenoss 4.2.4
Stopping any down-level Zenoss daemons...
   1:zenoss                 ########################################### [100%]

At this point, as I understand it, there will be some problems with passwords not matching in configuration files, because the auto-deploy scripts (for both 4.2.3 and 4.2.4) would perform password synchronization, which is not done by the RPM.  Let’s check them.

# cat /opt/zenoss/etc/hubpasswd

# cat /opt/zenoss/etc/global.conf | grep password
zodb-password <some other password>
zodb-admin-password xxxxxxxxx
amqppassword <some other password>
zep-password <some other password>
zep-admin-password xxxxxxxxx
hubpassword <some other password>

The password in the hubpasswd file should match the <some other password> in global.conf.  So let’s change it.

# vi /opt/zenoss/etc/hubpasswd
# cat /opt/zenoss/etc/hubpasswd
admin:<some other password>

Finally, start the zenoss service.

# service zenoss start
Zenoss upgraded.  Running data migration scripts...
Upgrade pre step
Checking RRDtool version >= 1.4.7: [ OK ] 1.4.7
Creating database: zenoss_zep
Applying schema version: 6
Dropping database: zodb_session
Creating database: zodb_session
Applying schema version: 1
Applying schema version: 2
Upgrading to use persistent sessions...
Already using persistent sessions or using custom session storage. zope.conf will not be altered.
Starting zeneventserver...
Migrating data...


Upgrade install post step
Zenoss upgrade complete.

And the upgrade is done!

The ‘localhost’ device started to give out warnings in Zenoss that the zen processes are not running, but after a remodel of the device, the warnings stopped.

Install Zenoss 4.2.4 on CentOS 6.4

I have not been checking up on Zenoss updates since my initial installation a few months ago.  I did not realise that Zenoss released a bugfix update 4.2.4 in July.

My 4.2.3 install has been working well so far, and I plan to update to 4.2.4 soon.  However, firstly I want to revisit the process of installing a fresh version.  I will repeat the steps of my 4.2.3 installation, and see if anything changed.

Start with a minimal CentOS 6.4 installation.  Then disable SELinux.

Remove the mysql-libs package that has been installed as part of the minimal CentOS install.

# yum remove mysql-libs

Install wget and grab the Zenoss 4.2.4 auto-deploy script.

# yum install wget
# wget --no-check-certificate https://github.com/zenoss/core-autodeploy/tarball/4.2.4 -O auto.tar.gz

Unpack the auto-deploy script.

# tar xzvf auto.tar.gz

Go into the unpacked directory and run the auto-deploy script.

# cd zenoss-core-autodeploy-*
# ./core-autodeploy.sh
Welcome to the Zenoss Core auto-deploy script!

This auto-deploy script installs the Oracle Java Runtime Environment (JRE).
To continue, please review and accept the Oracle Binary Code License Agreement
for Java SE.

Press Enter to continue.

Hit Enter, read the agreement, and press q to exit the agreement page.

Type yes and press Enter to accept the agreement.

The install will proceed and finish successfully.

Zenoss Core 4.2.4 install completed successfully!

Please visit in your favorite Web browser to complete

NOTE: You may need to disable or modify this server's firewall to access port
8080. To disable this system's firewall, type:

# service iptables save
# service iptables stop
# chkconfig iptables off

Alternatively, you can modify your firewall to enable incoming connections to
port 8080. Here is a full list of all the ports Zenoss accepts incoming
connections from, and their purpose:

        8080 (TCP)                 Web user interface
        11211 (TCP and UDP)        memcached
        514 (UDP)                  syslog
        162 (UDP)                  SNMP traps

If you encounter problems with this script, please report them on the
following wiki page:


Thank you for using Zenoss. Happy monitoring!

Now, set up the firewall rules and the zenoss page can be accessed at http://<hostname>:8080

# iptables -I INPUT 5 -p tcp --dport 8080 -j ACCEPT
# iptables -I INPUT 6 -p tcp --dport 11211 -j ACCEPT
# iptables -I INPUT 7 -p udp --dport 11211 -j ACCEPT
# iptables -I INPUT 8 -p udp --dport 514 -j ACCEPT
# iptables -I INPUT 9 -p udp --dport 162 -j ACCEPT
# service iptables save

That’s it!

Disable SELinux on CentOS 6

Check SELinux status using the sestatus command.

# sestatus
SELinux status:                 enabled
SELinuxfs mount:                /selinux
Current mode:                   enforcing
Mode from config file:          enforcing
Policy version:                 24
Policy from config file:        targeted

You can change the mode from enforcing to permissive and vice versa using the setenforce command.

# setenforce permissive

# sestatus
SELinux status:                 enabled
SELinuxfs mount:                /selinux
Current mode:                   permissive
Mode from config file:          enforcing
Policy version:                 24
Policy from config file:        targeted

To disable SELinux completely, modify the line ‘SELINUX=enforcing’ to ‘SELINUX=disabled’ in /etc/sysconfig/selinux .  The file will then look like this:

# This file controls the state of SELinux on the system.
# SELINUX= can take one of these three values:
#     enforcing - SELinux security policy is enforced.
#     permissive - SELinux prints warnings instead of enforcing.
#     disabled - No SELinux policy is loaded.
# SELINUXTYPE= can take one of these two values:
#     targeted - Targeted processes are protected,
#     mls - Multi Level Security protection.

Reboot the server and the config will take effect.

# sestatus
SELinux status:                 disabled

Set up SSL on CentOS running apache

Finally got SSL running on this blog.  This post is to document the steps I took.

This wiki page was what I used as a guide.

OS is CentOS 6.4 running Apache that is packaged together with the base repository.

First, make sure the required packages are installed.

# yum install mod_ssl openssl

The installation of mod_ssl will include a default https configuration with pre-generated key and self-signed certificate.

Pre-generated key = /etc/pki/tls/private/localhost.key
Pre-generated certificate = /etc/pki/tls/certs/localhost.crt
Default config = /etc/httpd/conf.d/ssl.conf

Restarting httpd at this point will give you a working https page served with the certificate mentioned above.  Do not forget to add firewall exception for port 443.

# service httpd restart
# iptables -I INPUT <line#> -p tcp --dport 443 -j ACCEPT
# service iptables save

Browsing to this page will show a security warning on browsers because the certificate used is not issued by a trusted certificate authority.  To get rid of the security warning, we have to sign our key with a trusted certificate authority.

Now let’s move on to generating our own key and getting it signed.

Generate key using openssl (change 1024 to 2048 or higher for better encryption).

# openssl genrsa -out ca.key 1024

Now, generate a certificate signing request (CSR) for the key.

# openssl req -new -key ca.key -out ca.csr

The command will prompt for further details to be embedded in the CSR.  The output file ca.csr will then be sent to a certificate authority for them to come up with a corresponding certificate.

You can also sign your own certificate using the following command.

openssl x509 -req -days 365 -in ca.csr -signkey ca.key -out ca.crt

After you have received the certificate, either from the certificate authority or via self-signing, the CSR file is no longer needed.

Now, copy the key and the certificate to the corresponding directories (so SELinux contexts can be applied without much tinkering).

Certificates go to /etc/pki/tls/certs/while keys go to /etc/pki/tls/private/

Next we can start configuring apache to use the certificate and key.  This can be done either in the main SSL configuration file at /etc/httpd/conf.d/ssl.conf or in the VirtualHost records.

Example VirtualHost record:

<VirtualHost *:443>
        SSLEngine on
        SSLCertificateFile /etc/pki/tls/certs/ca.crt
        SSLCertificateKeyFile /etc/pki/tls/private/ca.key
        ServerName centos01.hazrulnizam.com

Finally, restart httpd and your https page will now use the new key and certificate.  If the certificate comes from a trusted certificate authority, you will no longer get the untrusted warning.

Multiple A record vs CNAMEs (For one IP)

I have been thinking about the best way to handle DNS for multiple services pointing to one IP address.  For instance, you have a server with a configured hostname of server.example.com, and you have two websites www.example.com and blog.example.com running on that server.  This means there will be three names that will have to resolve to the same IP address.  Is it better to have three A records pointing to that IP address, or to use only one A record (server.example.com) and use CNAMEs for www and blog?

Found a good answer here.

Basically, using CNAMEs is easier to manage because a change of IP address of the server will only necessitate the change of one A record.

However, using a lot of CNAMEs will put extra strain on the DNS server, as the DNS server will have to resolve the name twice before getting to the IP address.  If you are worried about the performance of the DNS server, CNAMEs should be avoided.

Using multiple A records poses another problem, which is there can be only one reverse pointer to the IP address.  Ideally, you would want each A record to have a corresponding PTR (not a requirement, though).

Finally, ‘bare’ hostnames like example.com (without any prefix) will have to be A records.  So if you want example.com to go to server.example.com you cannot CNAME it as it will not work.

Insufficient storage available when updating apps on my Android

When updating apps via the Play Store, some apps will fail to update giving the ‘Insufficient storage available’ even when there is plenty of storage space available.



Results from Googling the error show different causes for the failure to update. In my particular case, the problem has something to do with the apps cache.

To overcome this issue, I used an app called App Cache Cleaner to clear the cache of all apps. After cleaning the cache, updates that failed before can now be updated successfully.