Vim & Vision

[ #219 ] Modify sudo's use of environment variables Permalink

Shell Added about two months ago and last edited about two months ago

When I:

$ sudo -s

... I want to have the same environment variables set/unset as the user I currently am.

To achieve this, add this line to /etc/sudoers (using the visudo command please!) like so:

Defaults    !env_reset

... and remove any env_keep stuff.

When I want to have the env vars set like root, I just:

$ sudo -i

[ #218 ] Install all Perl modules Permalink

Perl, Shell, apt Added about two months ago and last edited about two months ago

In Debian or Ubuntu you can install all apt provided Perl modules like so:

apt-cache search "\-perl" | grep -e '^lib' | awk '{ print $1 }' | xargs sudo apt-get install

If, before running that command, you just want to check what it would install, run this:

apt-cache search "\-perl" | grep -e '^lib' | awk '{ print $1 }'

[ #217 ] Mutt - delete old messages Permalink

Mutt Added about two months ago

To delete messages older than 90 days:

D
~d >90d

[ #216 ] OpenVZ VPS and swap space Permalink

Linux, OpenVZ Added less than a year ago

I got a surprise yesterday when I was looking at a VPS. free -m reported no swap space! I didn't know the VPS was an OpenVZ container. These containers will report no swap space from within the VPS - however the whole system still does use swap, it manages it for you.

[ #215 ] fail2ban on NetBSD for ssh Permalink

NetBSD, SSH Added less than a year ago

Check out fail2ban - it's a great way of securing your system using firewall rules (to block offending IPs) when hack attempts like numerous failed ssh logins occur.

To set it up on NetBSD, install it from source - it's Python so you can just:

$ sudo python setup.py install

Then add an rc script:

#!/bin/sh
#
# PROVIDE: fail2ban
# REQUIRE: NETWORKING syslogd

. /etc/rc.subr

name="fail2ban"
rcvar=$name
command="/usr/pkg/bin/fail2ban-client"
pidfile="/var/run/${name}/${name}.pid"
extra_commands="reload"

fail2ban_start()
{
    if [ -n "${the_fail2ban_pid}" ]; then
        echo "${command} already running as pid ${the_fail2ban_pid}."
        return 1
    fi
    echo "Starting ${name}"
    ${command} start
}

fail2ban_stop()
{
    if [ -z "${the_fail2ban_pid}" ]; then
        echo "${command} not running? (check ${pidfile})."
        return 1
    fi
    echo "Stopping ${name}"
    ${command} stop
}

fail2ban_status()
{
    if [ -z "${the_fail2ban_pid}" ]; then
        echo "${command} is not running? (check ${pidfile})."
    else
        echo "${command} is running as pid ${the_fail2ban_pid}."
    fi
}

fail2ban_reload()
{
    if [ -z "${the_fail2ban_pid}" ]; then
        echo "${command} not running? (check ${pidfile})."
        return 1
    fi
    echo "Reloading fail2ban"
    ${command} reload
}

start_cmd="fail2ban_start"
stop_cmd="fail2ban_stop"
status_cmd="fail2ban_status"
reload_cmd="fail2ban_reload"
the_fail2ban_pid=`check_pidfile ${pidfile} /usr/pkg/bin/python`

load_rc_config $name
run_rc_command "$1"

(don't forget to add fail2ban=YES to your /etc/rc.conf)

And setup your jail.conf with a section like this:

[ssh-ipfilter]

enabled  = true
filter   = sshd
action   = sendmail-whois[name=SSH, dest=youremail@email.com, sender=fail2ban@yourbox]
           ipfilter[name=SSH, port=ssh, protocol=tcp]
logpath  = /var/log/authlog
maxretry = 5

(Read the fail2ban docs or the message after installation to determine where your jail.conf and other conf files are. Mine are in /etc/fail2ban/)

Then start it up like this:

$ sudo /etc/rc.d/fail2ban start

Check out all the other actions and filters too... fail2ban is not just for blocking failed ssh authentications!

I get an email whenever fail2ban is started or stopped - and also whenever it blocks a possible attacking IP. It works great!

[ #214 ] NetBSD - Using sup Permalink

NetBSD Added less than a year ago

If you want to use sup and you get an error like this:

SUP: Can't find my host entry '(null)'

You need to:

$ hostname yourbox
$ domainname yourdomain
Ensure you have a 127.0.0.1 yourbox yourbox.yourdomain line in your /etc/hosts file

[ #213 ] Python - testing for a sys.exit Permalink

Python, Testing Added less than a year ago

Whenever a function of yours calls:

sys.exit(1)

... a SystemExit exception is raised. This can be tested for in the usual way:

assertRaises(SystemExit, yourfunction, arg1)

[ #212 ] Python Best Practice Link Dump Permalink

Python Added less than a year ago

http://eikke.com/how-not-to-write-python-code/

http://bayes.colorado.edu/PythonGuidelines.html

http://pycheesecake.org/wiki/PythonTestingToolsTaxonomy

http://docs.python.org/py3k/howto/doanddont.html

http://python.net/~goodger/projects/pycon/2007/idiomatic/handout.html

http://www.python.org/dev/peps/pep-0008/

... and use pychecker and nose

[ #211 ] Python script names Permalink

Python Added less than a year ago

Don't put dashes in your script names. When you go to test and you have dashes, you will find that:

import your-script # fails

... because the parser thinks it's doing this: import 'your', subtract 'script'. You can get around it by doing this:

__import__('your-script')

... but the best advice is to forget about dashes.

[ #210 ] Perl - Using an expensive module Permalink

Perl Added less than a year ago

(Obviously expensive in this context refers to time or resources.)

From perldoc -f use, we know that use Module; is the same as:

BEGIN { require Module; Module->import( LIST ); }

Code in BEGIN blocks is executed at compile time, not run time. ('Compilation' in perl refers to the compilation to internal bytecode format.)

Consider an expensive module that your script uses. Imagine that the functionality that this module provides is only used in one of your subroutines, and that this subroutine is not necessary run in every invocation of your script.

If you used the expensive module, it would be included every time your script is run. If, instead, you simply required this module within the subroutine that actually needs it, you could avoid the cost of including the module when you don't need it!

Consider this expensive-to-use module, Expensive.pm:

package Expensive;

sleep 5;

1;

Now consider use.pl:

#!/usr/bin/env perl

use strict;
use warnings;

use Expensive;

sub rarely_called {
    # uses Expensive.pm's functionality here
    return;
}

rarely_called if defined $ARGV[0];

versus require.pl:

#!/usr/bin/env perl

use strict;
use warnings;

sub rarely_called {
    require Expensive;
    Expensive->import();
    # uses Expensive.pm's functionality here
    return;
}

rarely_called if defined $ARGV[0];

Let's time them:

$ time ./use.pl 

real    0m5.011s
user    0m0.008s
sys     0m0.008s

$ time ./use.pl xxx # see how both invocations of use.pl take the same amount of time

real    0m5.011s
user    0m0.008s
sys     0m0.004s

$ time ./require.pl # but when require doesn't call the sub it is fast!

real    0m0.010s
user    0m0.004s
sys     0m0.004s

$ time ./require.pl xxx

real    0m5.011s
user    0m0.012s
sys     0m0.000s

Oh, and in case you are wondering, no you can't just put the use statement in the sub... all uses are processed at compile time, so it would still be expensive even if that sub was never called.

Older Posts ... Newer Posts

Colophon

Django Python 960.gs Git Vim NetBSD Nginx

The Author

This is the blog of Brad Willis, a software engineer living in Brisbane.

Links

ChoppingBoard, DaveMisc, Project365, RageQuit