Running is therapy


function smv(){
  scp $1 $2 && rm $1;
}


Oddly, when restarting Bind 9 on Ubuntu I noticed it would tell me it restarted OK, but in fact wouldn’t be running.

npowell@chihiro:~$ sudo /etc/init.d/bind9 restart
* Stopping domain name service...                              [ ok ]
* Starting domain name service...                              [ ok ]
npowell@chihiro:~$ ps aux | grep bind
npowell  23418  0.0  0.0   2880   800 pts/1    S+   09:16   0:00 grep bind


Also, Ubuntu’s penchant for breaking up absolutely ALL the logs is a little annoying (maybe they got this from Debian, I dunno). Nonetheless, if you look in the daemon.log, you will see the error

root@chihiro:/var/log# tail -n 9 /var/log/daemon.log
Apr 28 09:16:06 chihiro named[23411]: starting BIND 9.3.2 -u bind
Apr 28 09:16:06 chihiro named[23411]: found 2 CPUs, using 2 worker threads
Apr 28 09:16:06 chihiro named[23411]: loading configuration from '/etc/bind/named.conf'
Apr 28 09:16:06 chihiro named[23411]: listening on IPv4 interface lo, 127.0.0.1#53
Apr 28 09:16:06 chihiro named[23411]: listening on IPv4 interface eth1, 192.168.0.1#53
Apr 28 09:16:06 chihiro named[23411]: listening on IPv4 interface eth2, 192.168.1.1#53
Apr 28 09:16:06 chihiro named[23411]: /etc/bind/named.conf.local:14: undefined ACL 'wtf'
Apr 28 09:16:06 chihiro named[23411]: loading configuration: not found
Apr 28 09:16:06 chihiro named[23411]: exiting (due to fatal error)


I made up that error, but you get the idea. Why it returns ‘OK’ when it didn’t start, I do not know.

I ran into a package today that I couldn’t find in the repos for Dapper. So I had to figure out a way to get it on there.

Luckily I ran into mah online, and I asked him for some dpkg-fu. He was kind enough to give me a hand getting this working. Here is what we did.

First, I added a Feisty repo to my sources.list so I could grab the source files and patch them for Debian.

echo "deb-src http://us.archive.ubuntu.com/ubuntu/ feisty main universe" >> /etc/apt/sources.list

Next we had to increase the cache size for apt so it wouldn’t choke on the new repo

echo "APT::Cache-Limit \"33554432\";" >> /etc/apt/apt.conf

Then, you can update and install the source files

sudo apt-get update
apt-get source php5-ming

This should, among other things create a directory called ming-0.3.0. Next, see what deps are missing. Install them.

cd ming-0.3.0/
debuild -uc -us -b

This will tell you all the packages you need. The only one you won’t be able to install is python-central…who cares python sucks anyway. Let’s get rid of the need for it.

vi debian/rules

Change lines 25 and 26 to

#PYDEF=$(shell pyversions -d)
#PYVERS=$(shell pyversions -r)

And lines 181 and 182 to

  #dh_pycentral
  #dh_python

Now we are ready to build…but we’ll have to force it.

debuild -uc -us -b -d

In the parent directory (after that finishes) there will be a bunch of deb’s. Just install the lib-ming, and the php5-ming deb’s.

sudo dpkg -i php5-ming_0.3.0-11ubuntu1_i386.deb libming0_0.3.0-11ubuntu1_i386.deb

One last thing, you have to enable the use of ming in the php.ini file

echo "extension=ming.so" >> /etc/php5/apache2/php.ini

Then restart Apache.

That’s it. You can also now take those deb’s and use them on any Dapper machine…though, as mah pointed out…I wouldn’t use the Python ones if I were you :)

**EDIT, don’t use this :) I am pretty sure it’s not working properly, see previous edit, I am running out of time today to fix it. If I don’t get it right soon, I am going to take this down till I do get it working right**
**EDIT: I am not convinced the auth takes place before the rewrite to SSL, I am looking at that now **

So…you want to use PAM to do authentication for Cacti over SSL? Sweet, here is how. (These directions are for Ubuntu, but could probably be extrapolated to other distros).

First, install mod_ssl (This is something separate that I am not going over here, it’s pretty straight forward).

Now, install mod_auth_pam

  apt-get install libapache2-mod-auth-pam

And add the apache user to the shadow group

  usermod -G shadow www-data


At this point, www-data can talk to PAM for authentication.

Now we need to force SSL so that our communication with the server is encrypted:

  vi /etc/apache2/sites-available/default

Adding this to the file (in the < virtualhost *:80> section):

    RewriteEngine on
    RewriteCond %{REQUEST_URI} ^\/cacti\/.*
    RewriteRule ^(.*)$ https://%{SERVER_NAME}$1 [L,R=301]

Now, reload Apache

  /etc/init.d/apache2 reload

There, now visit http://yoursite.com/cacti. It should reroute you to https, and the login page of Cacti. Login, and go to settings (in the lower left hand corner). Then click the ‘authentication’ tab. The first config param should be a checkbox with ‘ Use Cacti’s Builtin Authentication’ checked. Uncheck that. Now, anyone can get into your Cacti install! Wooo! Actually, let’s fix that.

Open the apache conf file for cacti:

  vi /etc/apache2/conf.d/cacti.conf

And add these lines (after the Alias directive):

<location />
    AuthType Basic
    AuthName "Cacti"
    Require valid-user
< /location>

Reload apache, and go back to the url. It should prompt you for your username/password (this will be your system username/password).

That is all.

(note, in < /location> and < virtualhost> there is a space after the < symbol…wordpress keeps doing weird things. Take that space out)

Since Zenoss runs inside of Zope, you have to do a couple of things to get it to run over ssl. There are zope plugins, and perhaps there is another way that Zenoss would recommend, but I have never been one for reading when I can stomp full speed ahead :)

I just created a vhost and used modproxy to proxy all the connections to https:


<virtualhost *:443>
  ServerAdmin bignate@yourwindowsbox.com
  ServerName zen.domain.com
 
  SSLEngine On
  SSLCertificateFile /etc/apache2/ssl/apache.pem
  <directory />
    Options ExecCGI Indexes FollowSymLinks
    AllowOverride All
  
  ErrorLog /var/log/apache2/error.log
  LogLevel warn
 
  CustomLog /var/log/apache2/access.log combined
  ServerSignature On
 
  ProxyPass / http://127.0.0.1:8080/
  ProxyPassReverse / http://127.0.0.1:8080/
</virtualhost>
 


Update: the plugin I use to format code is messing that up

The version of Monit in the Dapper repositories is old. Installing version 4.9 of monit makes sense to me, so that is what I did.


sudo apt-get install libssl-dev build-essential bison flex
wget http://www.tildeslash.com/monit/dist/monit-4.9.tar.gz
tar xvzf monit-4.9.tar.gz
cd monit-4.9/
./configure && make && make install
vi /etc/monitrc
monit


If you use Monit and DenyHosts together…make sure you put ‘ALL: 127.0.0.1′ in your /etc/hosts.allow…DenyHosts sees monits checks and thinks it’s a ssh attack.

At work we launched the new colo over last weekend. In the aftermath it was time to get pam_abl installed. However for some reason it wouldn’t work. I found one blog post that suggested that the OpenSSH server that is on Dapper doesn’t properly call pam and so you need a patched version to run pam_abl. Well the idea that 1. I only found it in one blog, and 2. He was offering a deb that was patched, didn’t really sit well with me.

I am all about community, but something as fundamental as ssh, I am sorry I am not willing to install that on the word of some yabo with a wordpress blog.

I decided that there was more than one way to skin a cat, and that I would give DenyHosts a try. It’s a simple idea. It’s a python script that adds IP’s to /etc/hosts.deny on failed attempts at whatever protocol you give it. I just wanted to stop the lame ssh brute force attacks (and really if I had my druthers I would have used pam_abl, I think it’s much more elegant). I installed DenyHosts and am pretty pleased so far. I set it up to send me a notification when a host is blocked (at least for a little while till I trust it). It’s not surprising that I get about 8 emails at a time. The brute force script just goes down the line of IP’s on the subnet and tries each one…so in turn each server blocks the ip and sends me an email.

This is the most recent jackass: 69.249.96.57 (c-69-249-96-57.hsd1.nj.comcast.net)

Fricken stupid people.