linux on Andrés Álvarez

Debian Package Versioning

Thu, 13 Apr 2017 00:00:00 +0000

In a previous post I talked about managing Debian package dependencies. However I did not go into detail about the structure the versioning of packages must have.

To recap, let's see how we can specify a specific package version of a dependency that our package needs:

Depends: erlang (>= 1.2)

In the example above, the required version for erlang is simply 1.2 or greater. A package's version format however, can be a bit more complex than this.

Version Format and Components

The official format of a Debian package's version is:

[epoch:]upstream_version[-debian_revision]

Let's go into detail about each of the components in that format.

Setting Up an OpenStack Dev Environment

Wed, 22 Mar 2017 00:00:00 +0000

Before beginning to contribute to OpenStack, it is necessary that we setup an ideal development environment for a smoother workflow.

In this post I will cover how to setup a Devstack development environment in a Ubuntu 16.04 virtual machine using VMware Player.

Setting Up the Ubuntu Virtual Machine

Make sure you have VMware Player installed in your system. Then we need to choose an appropriate Ubuntu ISO image for our virtual machine. In my case I am using a Ubuntu Desktop 16.04.2 LTS (Xenial Xerus) for 32-bit PC i836.

In VMware Player, create a new virtual machine using the wizard. Assign your preferred amount of memory and storage space. Now start the machine, and select the Ubuntu .iso image file when prompted. Proceed with the installation and select the Erase Disk and Install Ubuntu option when prompted.

~> I tried using VirtualBox for virtualization but I could not successfully install Devstack with it. Probably due to issues on using the correct network adapter. I also tried using Ubuntu 14.04 without success as well. This is why I recommend Ubuntu 16.04.

Once the installation is finished, restart the virtual machine.

Useful Zendmd Tricks

Tue, 14 Feb 2017 00:00:00 +0000

The Zenoss Zendmd Tips Wiki page contains a few useful tricks using zendmd to perform tasks. In this post I am adding more tricks that I discover and learn along the way.

Removing Device Classes

We can easily remove device classes within zendmd with a simple command. Assuming we want to remove the default “KVM” device class:

dmd.Devices.manage_deleteOrganizer("/zport/dmd/Devices/KVM")
commit()

Change Zenoss User's Password

Let's say we want to change the default admin user's password (zenoss) in the Ubuntu auto deploy:

app.acl_users.userManager.updateUserPassword('admin', 'newpassword')
commit()

Getting Started With Juju Locally

Fri, 10 Feb 2017 00:00:00 +0000

Juju is a great tool that allows us to deploy many services in a local or cloud environment. Services are deployed into virtual containers and can be removed and re-deployed at any time. It is perfect for creating sandbox and test environments for specific kind of services that you develop for.

In this post I will explain how easy it is to get started with Juju in a local environment.

Installation

To start we will need to add the necessary repository from where we will retrieve the Juju packages:

sudo add-apt-repository ppa:juju/stable
sudo apt-get update

Next we will download and install the Juju core package and the package for local deployment:

sudo apt-get install juju-core
sudo apt-get install juju-local

Setting Up the Local Environment

Before we set up the local environment, let's first generate a configuration file. This file will contain the configuration for many kinds of environments (OpenStack, AWS, MaaS, etc.), including a local environment configuration. We will generate the file and then switch to the local environment:

juju generate-config
juju switch local

Once we have switched to the local environment, we can simply bootstrap the environment with the following command:

juju bootstrap

After the process is complete, we are now ready to start using Juju.

Using RRDTool in Zenoss

Tue, 22 Nov 2016 00:00:00 +0000

rrdtool is an awesome high performance data logging and graphing tool for time series data. Zenoss Core uses RRDTool to collect, monitor, and graph peformance data for devices.

However Zenoss Core comes with built-in helper wrappers around RRDTool that makes using it within Zenoss much easier. These source code files can be found in $ZENHOME/Products/ZenRRD/.

RRDUtil

Located in $ZENHOME/Products/ZenRRD/RRDUtil.py, this Python module contains many wrapper methods around the rrdtool library. These methods can help us write to, create new, and read .rrd files using Python.

We can easily import this module into our code, using the following import statement:

from Products.ZenRRD.RRDUtil import RRDUtil

IPMI & Baseboard Management Controllers

Fri, 18 Nov 2016 00:00:00 +0000

An Intelligent Platform Management Interface (IPMI) is a set of interfaces that allow system administrators to manage and monitor systems, independently of the system's CPU, BIOS, and operating system.

IPMI can also help manage computers that are unresponsive or powered off, by using a network connection to the hardware, rather than to a operating system or login shell.

More specifically, IPMI can help us monitor, obtain data, and perform tasks such as:

System temperature
Voltages
Fans
Power supplies
Chassis intrusion
Perform recovery procedures
System rebooting
System powering

An IPMI sub-system consists of a main controller, called the baseboard management controller (BMC) and other management controllers distributed among different system modules that are referred to as satellite controllers. The satellite controllers within the same chassis connect to the BMC via another system interface (not covered in this post) called Intelligent Platform Management Bus/Bridge (IPMB)

Creating Zenoss ZenPack Daemons

Mon, 07 Nov 2016 00:00:00 +0000

ZenPacks are powerful custom add-ons that can help us extend Zenoss's functionality. In this post I will go over on how to create a ZenPack that adds a custom daemon to the existing Zenoss daemons and runs on a configured cycle time to perform custom tasks. We will achieve this by creating the ZenPack using zenpacklib, but it is also possible to create it from the Zenoss user interface.

About zenpacklib

zenpacklib is a Python library developed by the Zenoss team to facilitate the process of creating ZenPacks, specially ZenPacks that deal with modeling and monitoring devices and components. Most of the newer ZenPacks that are being released are now being built with zenpacklib.

We can obtain zenpacklib by running the following commands:

wget http://zenpacklib.zenoss.com/zenpacklib.py
chmod 755 zenpacklib.py

This will download the zenpacklib Python library and give it executable permissions.

Creating the ZenPack

Using the zenpacklib file we just downloaded, we proceed to create a new fresh ZenPack:

./zenpacklib.py create ZenPacks.<your_namespace>.<zenpack_name>

This will create the ZenPack base directory with the necessary base files.

Now we go into this directory to begin.

cd ZenPacks.<your_namespace>.<zenpack_name>

Creating the ZenPack Daemon

Our custom daemon declaration will be located in a directory named daemons, inside our ZenPack directory:

mkdir ZenPacks.<your_namespace>.<zenpack_name>/<your_namespace>/<zenpack_name>/daemons

Here we will create a new Bashscript file with the name of our daemon. In this case we will name it mydaemon:

#! /usr/bin/env bash

DAEMON_NAME="mydaemon"

. $ZENHOME/bin/zenfunctions

MYPATH=`python -c "import os.path; print os.path.realpath('$0')"` THISDIR=`dirname $MYPATH` PRGHOME=`dirname $THISDIR` PRGNAME=$DAEMON_NAME.py CFGFILE=$CFGDIR/$DAEMON_NAME.conf

generic "$@"

Once the ZenPack is installed, files under this daemons directory will become executable (chmod 0755), a symlink to the file will be created in $ZENHOME/bin, and a configuration file will be generated in $ZENHOME/etc/<daemon_name>.conf

NOTE: If you created your ZenPack using the Zenoss user interface, the daemons directory will also be automatically created, and will contain an example daemon file named zenexample with code similar to the one above. In this case you should simply replace the necessary values.

Monitoring CPU Utilization in Zenoss

Fri, 04 Nov 2016 00:00:00 +0000

While taking a look at the CPU Utilization graphs offered Zenoss Core's Linux Monitor ZenPack (v1.2.1), I noticed that the percentage values for Idle were ridiculously high:

This made sense since this particular device contains 16 cores. However, this then means that the monitoring template isn't really taking this into consideration, and instead just spits out the total value from all cores.

Zenoss Monitoring Template Data Points

Thu, 03 Nov 2016 00:00:00 +0000

Content from this post is mostly obtained from Zenoss Core Administration guide.

In Zenoss Core monitoring templates, data sources can return data for one or more performance metrics. Each metric retrieved by a data source is represented by a data point.

When creating a data point, there are some important fields that we can define for our data point:

Name: Displays the name you entered in the Add a New DataPoint dialog.
RRD Type: Specify the RRD data source type to use for storing data for this data point. (Zenoss Core uses RRDTool to store performance data.) Available options are:
- COUNTER: Saves the rate of change of the value over a step period. This assumes that the value is always increasing (the difference between the current and the previous value is greater than 0). Traffic counters on a router are an ideal candidate for using COUNTER.
- GAUGE: Does not save the rate of change, but saves the actual value. There are no divisions or calculations. To see memory consumption in a server, for example, you might want to select this value.
- DERIVE: Same as COUNTER, but additionally allows negative values. If you want to see the rate of change in free disk space on your server, for example, then you might want to select this value.
- ABSOLUTE: Saves the rate of change, but assumes that the previous value is set to 0. The difference between the current and the previous value is always equal to the current value. Thus, ABSOLUTE stores the current value, divided by the step interval.
Create Command: Enter an RRD expression used to create the database for this data point. If you do not enter a value, then the system uses a default applicable to most situations. For details about the rrdcreate command, go here.
RRD Minimum: Enter a value. Any value received that is less than this number is ignored.
RRD Maximum: Enter a value. Any value received that is greater than this number is ignored.

Data Point Aliases

Performance reports pull information from various data points that represent a metric. The report itself knows which data points it requires, and which modifications are needed, if any, to put the data in its proper units and format.

The addition of a data point requires changing the report.

To allow for more flexibility in changes, some reports use data point aliases. Data point aliases group data points so they can be more easily used for reporting. In addition, if the data points return data in different units, then the plugin can normalize that data into a common unit.

Configuring a local apt repository

Mon, 17 Oct 2016 00:00:00 +0000

Setting up a local apt repository can allow you to use apt-get install command to install your own packages. This is a better approach than using dpkg -i because apt will fetch and install the required dependencies (which should also be located in your local repository) in an offline fashion.

Add Local Repository to Sources

First we need to add our local repository to apt's list of source repositories, this can be found in /etc/apt/sources.list. To add our local repository, we add the following line at the top of the file:

/path/to/local-deb-repo/ ./

Where local-deb-repo is the name of our local repository directory.

Add Debian Packages

Now we create local repository's directory just like we specified it in the previous step:

mkdir /path/to/local-deb-repo/

Once we've done that, we can proceed to put the Debian package files (.deb) and their dependencies inside the directory.

Managing Debian Package Dependencies

Fri, 14 Oct 2016 00:00:00 +0000

In a previous post, I talked about building a simple Debian package in Ubuntu, however I did not go into details on how to manage the dependencies that your Debian package might require. In this post I will cover exactly that.

dpkg and Dependencies

Previously we installed our package using the dpkg -i command. However, the problem with dpkg is that by itself, it is not capable of managing repositories. Therefore, higher level tools (such as apt-get) are required to fetch dependencies from repositories.

dkpg is only the core tool that installs/removes/configures packages, taking care of dependencies and other factors. apt-get and aptitude are tools that manage repositories, download data from them, and use dkpg to install/remove packages from them. This means, that apt-get and aptitude can resolve dependencies and get required packages from repository, but dpkg cannot, because it knows nothing about repositories.

Debian Packaging in Ubuntu

Tue, 11 Oct 2016 00:00:00 +0000

Debian packaging is a nice way to organize our software so that it can be installed and uninstalled with more ease. In this post we will go through the basics of creating a simple Debian package in Ubuntu 14.04 LTS.

Package Source & Structure

We will first create our working space for our package along with the necessary basic structure needed. For this example, we will create a directory for our package source, using the package title and 3 digit versioning in the directory's title:

mkdir mypackage-1.0.0

Inside our package, we will need a directory where we will hold the control files that give the Debian package the desired behavior:

cd mypackage-1.0.0
mkdir DEBIAN
touch DEBIAN/control

This control file will describe our package to the Debian package manager (dpkg). Inside, we can specify information about the package such as version, architecture, dependencies, maintainer, etc, as shown below:

Package: mypackage
Version: 1.0-0
Section: base
Priority: optional
Architecture: all
Depends: python2.7
Maintainer: Andres Alvarez <myemail@gmail.com>
Description: A new and improved C++ Compiler

With this basic setup, we now have a basic working package that can be handled by the Debian package manager, albeit, with no contents.