Starting with Docker

Definition from Wikipedia

Docker is an open-source project that automates the deployment of applications inside software containers, by providing an additional layer of abstraction and automation of operating system–level virtualization onLinux.[2] Docker uses resource isolation features of the Linux kernel such as cgroups and kernel namespaces to allow independent "containers" to run within a single Linux instance, avoiding the overhead of starting virtual machines.[3]

What about Docker?

Docker reminds me old isolation container technology, such as Solaris Zones, *BSD Jails or even Linux OpenVZ. In fact, it is the same technology. Docker uses LXC linux kernel module that derivates from OpenVZ.
Docker is newer, better and simpler than the old alternatives. It provides you with an API, a Container repository and an easy CLI management interface. These points make Docker really powerful and modern.

A fast way to find a LAMP memory leak

This summary is not available. Please click here to view the post.

Recipe: Linux SNMPD script OID & Cacti example ( VSFTD number of users )

Today we have to implement a new chart in our Cacti, this chart has to display the number of users connected to a VSFTPD server in a CentOS server.

VSFTPD CONFIG
Firstly, you have to setup VSFTD to display the number of connections, to do this, you have to add this variable setproctitle_enable=YES in the vsftpd.conf file and restart the service.
This setting allows you to monitor the clients, now you can see the connection in the output of ps command, in this case the output looks like this:
vsftpd_daemon_user 11203  1.0  0.3  56320  1548 ?        Ss   15:12   0:00 vsftpd: 90.IP.IP.IP: connected
Counting the number of connections is very easy, one script like this is enough:

 #!/bin/bash  
 ps aux | grep vsftp | grep connected | wc -l  

It will return the number of the connected users.
We are going to save it as /scripts/ftp-who.sh to use it in the next examples.
Now is time to integrate it on SNMPD config.

Recipe: How to know when was the last update in Linux

Today we are going to write about the difference between the two main package managers. Last week we were setting up some systems to be ready for ISO 27000 audit and we needed to know when the last updates were installed in  Linux servers. We have two types of Linux distributions in the company, Debian and CentOS, we think that CentOS is more enterprise friendly, especially the package manager (yum) is more enterprise friendly than dpkg and here is an example.

In CentOS you need to execute the command yum history to get a report of the last software installed in the machine. In Debian on the other hand, you need to execute something like this, date -d @$(stat -c %Y /var/cache/apt/) and it just return the last day when apt-get installed a package, it looks more tricky and it is not a function of dpkg.

This kind of details, like update history, are very important to us because they are very annoying in day by day operation, so we strongly recommend CentOS instead of Debian for enterprise systems.

SCOM Linux Agents

This is the part four of a set of articles related to SCOM

Part1 - SCOM BASICS

Part2 - Useful SQL queries in SCOM database
Part3 - Basic reporting in SCOM
Part4 - SCOM scripting basics

How to deploy

Before SCOM 2012 SP1, if you didn´t  have the supported Linux Versions like Red Hat or SUSE, it was hard to deploy a Linux agent, nowadays with the new management packs, it is much easier.
In this article, we are going to a make a sumary which covers the installation and basic troubleshooting in Linux systems, but it could also be useful with Unix agents.

SCOM scripting basics

This is the part three of a set of articles related to SCOM

Part1 - SCOM BASICS

Part2 - Useful SQL queries in SCOM database
Part3 - Basic reporting in SCOM

Why scripting with SCOM?

Scripting is the most powerful tool in SCOM, with scripts and imagination you can monitor everything, from a folder in the filesystem to a coffee machine.

Usually we use Visual Basic Script for scripting in SCOM, because it works in all Windows systems, from 2003 to 2012R2, but you can use Powershell if you prefer,  as long as it is installed in the monitored system. Bash or Python can be used as well, if you are monitoring Linux servers.
Scripts could be emebeded in Management packs or can be developed from the administration console as monitor or rule.

This article is focused on monitor scripts, but it can give you an idea about how scripts work in SCOM and how to use them on rules or management packs.