Showing posts with label Linux. Show all posts
Showing posts with label Linux. Show all posts

Wednesday, August 14, 2013

Observium On OpenBSD

Note:  The following is a blow by blow of the installation, told in story form.  If you intend to follow this as a guide to the installation of Observium in OpenBSD, please read through to the end before starting the installation.  I will be show config snippets at varying stages of broken-ness.

Always being one to enjoy a technological challenge, I was presented with the task of building out a new management network.  I firmly believe that management of all devices on a network needs to be out of band from the rest of the network operation, so I was quite happy to take on this task.  After installing the new switches, and getting all of the monitor ports cabled up, I stopped to contemplate how I would set up my network monitoring suite, and how I would access this OOB network remotely.

Being a project that requires security (someone finding their way onto this network could be catastrophic), I decided that the best course of action was to set up a machine with a NIC in both my internal and my management networks, and run OpenBSD 5.3 on it.  A few months ago, the friendly folks over at #juniper on freenode recommended Observium as a network monitoring suite, and I have found it to be a fantastic project so far.  The Observium installation documentation is very clear that it supports Ubuntu/Debian only.  There is a second set of installation instructions for RHEL/CentOS.

So off I went with my OpenBSD installation, knowing full well that the Observium installation was probably going to be a painful one, but the machine that spans the gap between the two networks is a prime location for my monitoring utilities, so I decided to do it anyway.  Starting off with the OS installation, I accepted the defaults for the most part, configured my NICs for my network, and allowed OBSD to work its own disklabel magic (use the whole disk, autopartition).  When it came time to choose installation sets, I simply issued a -x* -games*, and went along my merry way (not fully appreciating the implications of my actions at the time).  Once the install was done, and I was presented with a prompt, the first order of business was to get the package mirror set up so I could begin installing the prerequisite software for Observium.  I chose to use the mirror in Denver, CO, USA.  This involved adding one line, and changing one line in .profile (changes in bold):


PATH=/sbin:/usr/sbin:/bin:/usr/bin:/usr/X11R6/bin:/usr/local/sbin:/usr/local/bin
PKG_PATH=ftp://ftp3.usa.openbsd.org/pub/OpenBSD/5.3/packages/amd64/
export PATH PKG_PATH

Next, we need to get a proper editor, and a few tools:

# pkg_add -vi vim nmap svn

After everything is done installing, I picked up the prereqs for Observium from their install documentation:

# pkg_add -vi fping mysql-server net-snmp rrdtool graphviz php

This will chug along for a while, and occasionally ask a question.  When prompted for a php version, I chose the latest 5.3 release (per the prereqs), in the non ap2 build (this is for Apache 2, but Apache 1.3 ships with OBSD out of the box).  But...  the damn thing breaks on rrdtool...  After a bit of Googling, I discovered that the required libraries are part of xcore53...  one of the packages that I opted to not install earlier.  SOOOOO, off to the closest mirror to grab xcore53.tgz, and run a cd / && tar -zxvpf ~/xcore53.tgz, start the pkg_add over, and we're done.

I brought up the mysql database with /usr/local/bin/mysql_install_db, then set the root password, and created a database for Observium according to the installation instructions.  I set the database credentials in /var/www/observium/config.php.

Next, I decided to install observium into /usr/local/observium, as I didn't like the idea of using /opt.  I pulled the code down via SVN per the instructions on the site, and dropped the config snippet from the RHEL instructions into /var/www/conf/httpd.conf, with some minor modifications:



       ServerAdmin webmaster@localhost
       DocumentRoot /usr/local/observium/html
       
               Options FollowSymLinks
               AllowOverride None
       
       
               Options Indexes FollowSymLinks MultiViews
               AllowOverride All
               Order allow,deny
               allow from all
       
       ErrorLog  /usr/local/observium/logs/error.log
       LogLevel warn
       CustomLog  /usr/local/observium/logs/access.log combined


I wound up chasing my tail for an hour or two messing with the httpd configs, before I realized that httpd had chrooted itself into /var/www (hence the funny config location).  I quickly moved the Observium install over to /var/www/observium, and changed the httpd config again:



       ServerAdmin webmaster@localhost
       DocumentRoot /var/www/observium/html
       
               Options FollowSymLinks
               AllowOverride None
       
       
               Options Indexes FollowSymLinks MultiViews
               AllowOverride All
               Order allow,deny
               allow from all
       
       ErrorLog  /var/www/observium/logs/error.log
       LogLevel warn
       CustomLog  /var/www/observium/logs/access.log combined


Much better!  Now we get an error about the database.  pkg_add -vi php-mysql 

Now getting an error about not being able to bind to the MySQL socket.  Wow, wonderful.  More Googling revealed that, yet again, the chroot was biting me:

# mkdir -p /var/www/var/run/mysql
# ln /var/run/mysql/mysql.sock /var/www/var/run/mysql/mysql.sock

Now that we're past that, OH LOOK, It's a 500 error!  After a few hours of sticking die()'s into the code, I figured out that since I was in a chroot, the install_dir variable would be relative to /var/www.  Once this variable was set from /var/www/observium to /observium, the web UI loaded right up.  When I attempted to add a user, I found that adduser.php was now throwing errors about not being able to find functions that should have been included with common.php.  Turns out that even though Apache is chrooted, the php cli, is not.  DOH!  ln -s /var/www/observium /observium  It's a hack, but hey, it works now... Kind of...  In reality, it just fails differently.  Turns out I missed a step in the install documentation, and didn't initialize the database...

After I got the DB initialized, and a user created, I realized that addhost.php wasn't working.  After more tinkering, I realized that all of the default paths for the utilities were wrong, because the software was designed to run in Linux.  I grabbed the whole block of utility path define()'s out of the defaults file, and gave them the correct paths, and lo and behold!  OBSERVIUM IN OBSD.

I will most likely be revisiting this topic in the not-too-distant future, as I find more things that I need to hack around, but for the time being, It looks like I have monitoring running on the machine I wanted it on.  Now it's time for pf!


Saturday, November 3, 2012

Loopback Filesystems Revisited

In a post quite some time ago, I discussed loopback filesystems.  Well, lo and behold, a few weeks ago, I had the opportunity to play with them again.  Xen, a Linux VM Hypervisor (http://www.xen.org) mounts up its disk images as loopbacks.

I found out rather quickly, that the default number of loopback devices available to the Kernel is 8.  When you have one image for disk, and one for swap on each domU (virtual guest), that means you can only cram 4 machines onto a single hypervisor by default...  That's just unacceptable.

I found two methods that worked, although one is a bit more painful than the other:

Hypervisor with Guests running in Production:

When you can't reboot the machine for whatever reason (in my case, it was running VM's that I didn't have any space to migrate, and couldn't shut down), you can modprobe the loop module again and pass it a parameter:

# modprobe loop max_loop=128

This is all fine and good, really, except for the fact that you don't get nodes created for the loop devices in /dev automatically, so you have to do some lovely work with mknod before you can use your new devices, even though the kernel is aware of them:

# mknod -m660 /dev/loop8 b 7 8

Loop devices have a major number of 7, so make sure to change both 8's to the appropriate value for your system.  The defaults on the systems I've been working with (Debian Lenny, Debian Squeeze, and Ubuntu Precise (12.04 LTS)) are to have 8 loop devices, loop0 - loop7.

Of course making 120 new loop devices by hand isn't exactly fun... Time for bash-fu!

# for x in `seq 8 128`; do mknod -m660 /dev/loop$x b 7 $x; done;

This gives us our 128 loopback devices (assuming you had 0-7 OOTB), with the nodes created in /dev.  If you reboot, they're gone, so make sure to add the options to /etc/modules.conf or wherever your flavor decided to keep the module options.

Hypervisor without Guests (or can be rebooted):

If the machine can be rebooted, the situation is much easier.  My solution was to pass the parameter to the kernel at boot time via GRUB.

Simply set the following in /etc/default/grub (for Debian based distros):

GRUB_CMDLINE_LINUX_DEFAULT="max_loop=128 quiet"

Then rebuild your GRUB config and reboot:

# update-grub && shutdown -r now

When the machine comes back up, GRUB will have passed the max_loop option to the kernel at boot, and the kernel will have automatically created all of your loopback devices for you.

Obviously, this is a significantly simpler operation than creating the nodes in place, and if you have the option to reboot, I would say go for it.

Tuesday, October 9, 2012

Victory!

After switching virtual network cards in my hypervisor, I was able to get RH7.1 online.  Textutils compiled as statically linked binaries just as expected, and ran like a mo-f'ing CHAMP on the dettuxx machine.  This allowed me to download coreutils-5.0 and compile/install it.

I ran into another circular dependency with awk (which was a pre-req of upgrading Bash), and was able to cross compile the latest gawk and get it installed just fine via the RH7.1 machine.  Now I'm going to try compiling binutils, as another pre-req of bash, and see what happens... Hopefully I won't have to cross compile too much more.

Several failed attempts...

Apparently, in order to compile textutils, you need to have textutils installed...  Naturally (to me anyway), my first thought was Busybox.  I tried to compile it, no joy (unmet dependancies), I tried the appropriate binaries for my VM, also no joy... insta-segfault.

Fine, let's get the real sort util, and copy it over, perfect!  So I spend the next 20 minutes configuring another (32bit) VM to support SSH1 on the internal network (since, of course, the version of SSH with Dettuxx is ancient), and get scp working.  Copy the binary over, and it crashes complaining about libraries. File confirmed that it was dynamically linked, with libs that weren't installed in Dettuxx, no doubt.  Fine...

export CFLAGS="-static -O2 -g"
./configure --with-prefix=/home/peter/textutils_build
make
make install

This process went along nicely, and generated a statically linked set of textutils bins (the old textutils package wasn't exactly fun to find, mind you).  I scp these binaries over, and get:  "FATAL:  Kernel too old"

As we speak, I have RH7.1 installing in a VM, running a 2.4 kernel out of the box...  Wish me luck...

Back for more...?

So, all these years later, I decided to give DettuxX another try (I mean... we have VM's now... why not), and was able to get it installed, bootable, and on the interwebs last night...  Thats when I remembered just how much of a bitch it is.  I, by some act of God, was able to get gcc compiled, but that's about as far as I got before I started running into... problems.  In order to compile most things, you need to have sort (which was a part of textutils when the distro was released... now textutils has been rolled into coreutils).  Unfortunately, there's a circular dependancy there.  Textutils requires sort to successfully configure, and sort is a part of Textutils...  Guess it's time to evaluate busy box, and the prospect of cross compiling textutils on another machine and copying it over...  Joy...

Wednesday, December 1, 2010

Loopback Filesystem

Ok, so it took quit a bit of expirimentation and FM reading, but here's the lowdown on creating loopback filesystems:

Create a file to hold the system, in my case, it's gonna be 10 megs:

peter@slacktop:~$ dd if=/dev/zero of=/home/peter/fsfile bs=1k count=10240
10240+0 records in                                                     
10240+0 records out                                                    
10485760 bytes (10 MB) copied, 0.0606135 s, 173 MB/s

Next set up the loopback system and point it at your spiffy new file:
peter@slacktop:~$ sudo /sbin/losetup /dev/loop0 /home/peter/fsfile

From here you can create and mount your filesystem:

peter@slacktop:~$ sudo /sbin/mkfs.ext2 /dev/loop0
mke2fs 1.41.8 (11-July-2009)
Filesystem label=
OS type: Linux
Block size=1024 (log=0)
Fragment size=1024 (log=0)
2560 inodes, 10240 blocks
512 blocks (5.00%) reserved for the super user
First data block=1
Maximum filesystem blocks=10485760
2 block groups
8192 blocks per group, 8192 fragments per group
1280 inodes per group
Superblock backups stored on blocks:
        8193

Writing inode tables: done
Writing superblocks and filesystem accounting information: done

This filesystem will be automatically checked every 37 mounts or
180 days, whichever comes first.  Use tune2fs -c or -i to override.


peter@slacktop:~$ sudo mkdir /mnt/lo
peter@slacktop:~$ sudo mount /dev/loop0 /mnt/lo

Tada... loopback filesystem.

Tuesday, September 9, 2008

Goodbye Debian, Hello Hell

Ok... A few quick notes... First off... DON'T do a mkdir /boot accidently, because it wipes the boot directory in the ram disk... bad idea... Beyond that...

Instruction number 8 should read "umount /mnt/mnt" not "umount /mnt"
Instruction number 14 should read "/mnt/bin/lilo -v -C /etc/lilo.conf -r /mnt" not "/mnt/sbin/lilo -v -C /mnt/etc/lilo.conf -r /mnt"

Starting over from scratch SUCKS... More soon.

Rediculous...

I really should have noticed that the first disk had a lower block count than the other 7... Bad media right out of the box. Lets try again...
hackserv:/home/proto/Desktop# dd if=dettuxx_disk01.img of=/dev/fd0
2880+0 records in
2880+0 records out
1474560 bytes (1.5 MB) copied, 100.915 seconds, 14.6 kB/s
Ahhh... much better... now to see if she boots :-P

The first official epic fail.

Well... Disk 1 went into the drive, and away I went with the reboot... The name of this post was supposed to be "Goodbye Debian, Hello Hell", but upon reboot, i recieved

LI_
The activity light on the FDD went out, the cursor was blinking, and lilo never finished the LO and booted... Time to re-dd the disk and see what happens... Not a good start.

dd

Not that anyone really needs to see how the dd command works across all 8 disks, but here you go.
hackserv:~# dd if=./dettuxx_disk01.img of=/dev/fd0
2847+1 records in
2847+1 records out
1458144 bytes (1.5 MB) copied, 101.165 seconds, 14.4 kB/s
hackserv:~# dd if=./dettuxx_disk02.img of=/dev/fd0
2880+0 records in
2880+0 records out
1474560 bytes (1.5 MB) copied, 101.119 seconds, 14.6 kB/s
hackserv:~# dd if=./dettuxx_disk03.img of=/dev/fd0
2880+0 records in
2880+0 records out
1474560 bytes (1.5 MB) copied, 101.119 seconds, 14.6 kB/s
hackserv:~# dd if=./dettuxx_disk04.img of=/dev/fd0
2880+0 records in
2880+0 records out
1474560 bytes (1.5 MB) copied, 102.521 seconds, 14.4 kB/s
hackserv:~# dd if=./dettuxx_disk05.img of=/dev/fd0
2880+0 records in
2880+0 records out
1474560 bytes (1.5 MB) copied, 101.321 seconds, 14.6 kB/s
hackserv:~# dd if=./dettuxx_disk06.img of=/dev/fd0
2880+0 records in
2880+0 records out
1474560 bytes (1.5 MB) copied, 101.518 seconds, 14.5 kB/s
hackserv:~# dd if=./dettuxx_disk07.img of=/dev/fd0
2880+0 records in
2880+0 records out
1474560 bytes (1.5 MB) copied, 101.314 seconds, 14.6 kB/s
hackserv:~# dd if=./dettuxx_disk08.img of=/dev/fd0
2880+0 records in
2880+0 records out
1474560 bytes (1.5 MB) copied, 101.516 seconds, 14.5 kB/s
hackserv:~#

And for thoes who don't know... A short excerpt from "man dd" (RTFM!)

NAME
dd - convert and copy a file

SYNOPSIS
dd [OPERAND]...
dd OPTION

DESCRIPTION
Copy a file, converting and formatting according to the operands.