Installation SQLplus

For a customer I was required to extract and report data from an Oracle database
Ofcourse I want to automate this task to the full extent. Normally I would use a scripting language like bash/perl/python for this task. Unfortunately, the environment did not allow for “easy” retrieval of external modules to interface with an Oracle database.

However, the environment did allow access tot the Oracle SQLplus instantclient. The instantclient allows running SQL-queries directly against Oracle databases, much like running “mysql -u root -p$password $mydatabase” in a MySQL environment. By piping or redirecting commands to such a “connection” we are able to extract the required information from the database.

Below I will outline the required steps and after I will show you snippets of the code I used for the reporting mechanism.

1. yum install oracle-instantclient11.2-sqlplus-11.2.0.3.0-1.i386
2. useradd oracle
3. edit /usr/lib/oracle/12.1/client64/network/admin/tnsnames.ora:
TDIGJ =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(HOST = ${IPADDRESS})(PORT = ${PORT:1521}))
)
(CONNECT_DATA =
(SID = ${SID})
)
)
4. test:
echo “SELECT table_name FROM DICTIONARY ORDER BY table_name;” | sqlplus ${USER}@${DBNAME}/${DBPASSWD}

Advertisements

How to setup nagios event handlers using passive checks and NRPE

Introduction

Nagios event handlers allow nagios to automatically apply remedial actions when certain events occur (e.g. automatic restart of a service when it goes down).
The NSCA (Nagios Service Check Acceptor) daemon allows nagios to receive passive checks from hosts. Passive checks can be advantageous since they do not require the nagios server to initiate a connection to the client. Instead the client reports its results itself to the server.

By combining event handlers with passive checks and NRPE, nagios can apply automatic remediation when hosts get online.

To configure and enable event handling on the nagios server follow these steps

1. Enable the path to the script (commands) to be triggered when the event handler should be run on the server side:

/etc/nagios/private/resource.cfg
# uncomment $USER2$, as the path to the event handlers
$USER2$=/usr/lib64/nagios/plugins/eventhandlers

2. Place the server-side event handler in the $USER2$ path:
/usr/lib64/nagios/plugins/eventhandlers/handle_windows

3. Add handle_windows as a new command in nagio(sql)

# see

https://assets.nagios.com/downloads/nagioscore/docs/nagioscore/3/en/macrolist.html#servicestate

Command: handle_windows
 Commandline: $USER2$/handle_windows $SERVICESTATE$ $SERVICESTATETYPE$ $SERVICEATTEMPT$
$HOSTADDRESS$ $SERVICEDISPLAYNAME$ $SERVICEDESC$
define command {
    command_name handle_windows
    command_line $USER2$/handle_windows $SERVICESTATE$
    $SERVICESTATETYPE$ $SERVICEATTEMPT$ $HOSTADDRESS$     $SERVICEDISPLAYNAME$ $SERVICEDESC$
    register 1
 }

4. Go to the services tab in nagiosql and
4.1 create a new service with a dummy check (will be reported by NSCA)
4.2 make sure the service check is configured and available on the client (next section)
4.3 enable the “Event handler” for this service (and select the right one (handle_windows)

5. Now make sure that both Nagios and the NSCA client are active and that Nagios is able to execute commands via NRPE and receive results from NSCA (check nagios.cfg for
this).

Configuring the Nagios client

For Windows setup NSClient++

Make sure the following is configured:

# in modules
[/modules]
CheckExternalScripts = 1
CheckSystem = 1
NRPEServer = 1
NSCAClient = 1
Scheduler= 1

[/settings/default]
 allowed hosts = #ipaddress of nagios server
 timeout = ##
# enable NRPE daemon
 [/settings/NRPE/server]
 insecure = true
 allow arguments = true
 port = 5666
[/settings/NSCA/client]
 hostname = auto
[/settings/NSCA/client/targets/default]
 address = #ipadress of nagios server
 encryption = 0
# set targets of external scripts for service checks and remediation
[/settings/external scripts/scripts]
handle_domaintrust = cmd /c echo scripts\handle_my_issue.ps1 ; exit($lastexitcode) | powershell.exe -command - 

check_my_issue = cmd /c echo scripts\check_my_issue.ps1 ; exit($lastexitcode) | powershell.exe -command -
# set the passive check run interval
 [/settings/scheduler/schedules/default]
 interval = 30s
# schedule the check
 [/settings/scheduler/schedules]
 check_my_issue = check_my_issue

debugging

To debug
1. tail -f nagios.log on the nagios server
2. net stop nscp on the client
3. nscp.exe test on the client
4. Now trigger the scripts / commands from either the server or the client (inside the nscp console)
(type queries to see if all scripts are listed)

Utilizing lvm thin provisioned snapshots

To fully utilize the few bits of space which is provided by my SSD, I always take the following approach.

1. Create an “as large as possible” LVM volume group to hold all my data.
2. Create a thin_pool within the volume group for my virtual machines.
3. Create one “base VM” which contains just a bare installation of my preferred OS (inside the thinpool).
4. Now for each VM I need for my labs I create a snapshot from the base VM:
lvcreate --snapshot --name thin_snapshot vg/thin_base

5. Now to ensure that I can actually utilize the newly created snapshot I have to activate it first.
LVM (thin) snapshot are “by default” created in inactivated mode, but it also has the “activation skip flag“. This flag prevents the system from activing the partition with the usual commands. To active the partition use:
lvchange -ay -K vg/thin_snapshot
To remove the skip flag completely add:
lvchange -kn vg/thin_snapshot

Finally the newly added thinly provisioned snapshot is available for usage by my virtualisation tool.

Preparing Powershell (Scripting) Development Environment

The Windows Powershell scripting language is a powerful advancement from older scripting language in Windows (Batch, VBScript). The language integrates features from other scripting languages (bash) and it is able to utilize existing (.Net) libraries.

A big difference between other scripting languages and Powershell is that it is fully object-based and not text-based. Therefore it is important to keep in mind that what you might see as output on your screen is only a representation of the object, but not the object itself.

In this post I will explain the basic steps to set up a “sane” working environment, which allows you similar experience as a Bash shell with TMUX.

In specific I will discuss the following tools/modules:

  • ConEmu
  • Environment Settings
  • Powershell Profile
  • Using Modules
  • PSGet / NuGet
  • PSReadline

ConEmu

ConEmu is a console emulator with tabs and panes. It is able to provide a similar management experience as Tmux on Linux.

For usage with Powershell I use the following settings in ConEmu:

  • Startup
    • “Specified named task” = {Shells::Powershell}
    • Tasks > “5 {Shells::Powershell}” = “C:\Windows\System32\WindowsPowershell\v1.0\powershell.exe -new_console:d:C:\gitrepo\powershell”
    • Environment > “Set up environment variables” = “set HOME=C:\gitrepo\powershell”
  • Features
    • Colors = <xterm>
  • Keys & Macro
    • As you wish, I’d recommend setting the following:
      create new split /vertical /horizontal, new tab, zoom, switch windows

The above settings ensure that any new shell is spawned from the directory containing my Powershell scripts and also allows to run scripts directly from this path.

Environment Settings

Only one environment variable should be set for Powershell, namely the “PSModulePath” variable. This variable allows the usage of modules (and functions within these modules) straight from any Powershell CLI, it doesn’t matter whether it is the powershell.exe, the Powershell ISE, or a custom execution from a different path.
To set the variable go the following:

# get current path
$curpath = [Environment]::GetEnvironmentVariable("PSModulePath")
# update path with new path
[Environment]::SetEnvironmentVariable( "PSModulePath", "C:\gitrepo\powershell\modules;" + $curpath)
# check if settings were updated correctly
get-childitem env:psmodulepath

Source: MS TechNet

Powershell Profile

Powershell also allows you to specify a set of commands which will be run before spawning a new shell. This is convenient for pre-loading modules, setting aliases and setting the path.

The powershell powerfile can be set up by creating a new textfile in the following location:
$HOME\Documents\WindowsPowerShell\Microsoft.Powershell_profile.ps1

# powershell profile

#set path
$env:Path = "C:\gitrepo\powershell"

# import modules
import-module psreadline

# set aliases
set-alias vim 'C:\Program Files (x86)\Vim\Vim74\vim.exe'

# To edit the Powershell Profile
Function Edit-Profile {
    vim $profile
}
# To edit Vim settings
Function Edit-Vimrc {
    vim D:\powershell\_vimrc
}

Besides some convenient shortcuts, the most important module I load here is the PSReadline module.

Using Modules

Powershell modules allow you to reuse existing code of yourself and others.
Modules are basically plain powershell scripts without any directly executed statements, but merely (groups of) functions. Also the extension ends with .psm1 instead of .ps1 .

Powershell modules can also contain some documentation and things like author and license however this is not required.

To be able to use modules the PSModulePath needs to be set and your modules should be available in this path.

Alternatively, from Powershell 4, the following path is added by default, which can be used for global modules:
$EnvProgramFiles\WindowsPowerShell\Modules\

PSGet

PSGet is a module and repository of useful powershell modules, a.o. the PSReadline module, to install it follow the instructions on the site

PSReadline

PSReadline enables readline support for Powershell terminals. The features are a.o.

  • enhanced tab completion
  • history
  • history search (Ctrl+r)
  • command line editing

See also Scripting Guy’s blog at: http://blogs.technet.com/b/heyscriptingguy/archive/2014/06/17/a-better-powershell-command-line-edit.aspx

To install PSReadline, first install PSGet, then execute the following command in your environment:

# install psreadline with psget
install-module PsReadLine

Installing an SSD (Fedora 16)

I just bought an SSD drive and I want to make sure it works best as it can.
I migrate my old / (ext4) partition to this drive.
For best performance I decide to switch to a GPT-based disk layout and use btrfs for the filesystem.

Steps (mostly from ArchLinux SSD tutorial

1: Physically install SSD,
2: Boot from livecd/usb (systemrescuecd) and create GPT partition table and partitions, using gdisk (g fdisk).
Create at least two partitions!
..BIOS_boot partition code: EF02 size: 1 MiB
..Linux/Windows data, root partition code: 0700 size: any
!! gdisk automatically aligns partitions on 2048-sector boundaries for best performance.

3: Now format root partition as btrfs*:

mkfs.btrfs -L MyLinuxOS /dev/sda2

4: Copy data from old partition to new partition using rsync with -a(rchive) option to make sure all rights are preserved.

5: Mount and chroot to new partition and install grub2:

mount /dev/sda2 /mnt
mount -o bind /dev /mnt/dev
mount -t proc /proc /mnt/proc
mount -t sysfs /sys /mnt/sys
chroot /mnt
## possibly fedora specific:
grub2-mkconfig -o /boot/grub2/grub.cfg
grub2-install /dev/sda

6: Edit fstab to make the most of the SSD:

LABEL=Fedora / btrfs defaults,noatime,discard,ssd 0 0

This post contains information from the following sources:
https://wiki.archlinux.org/index.php/Solid_State_Drives

http://tincman.wordpress.com/2011/01/20/installing-arch-linux-onto-a-gpt-partitioned-btrfs-root-ssd-on-a-legacy-bios-system/

http://fedoraproject.org/wiki/Grub2