Add fault tolerance to cron noise

Not all cron jobs are created equal, and some of them can afford to fail sporadically before we need to worry about them. Maybe they rely on a third party server, and we don’t want the occasional fail to pollute our inbox.

Here is a little cron job wrapper I created that will suppress stderr but keeps track of the job’s returned exit codes. Above a certain threshold of consecutive abnormal exits it doesn’t suppress stderr anymore.

# if the counter file doesn't already exist we create/initialize it
if [ ! -f /tmp/counter_ri7g3 ] ;
    echo 0 > /tmp/counter_ri7g3 ;
fi ;

# we pull the current counter
counter=`cat /tmp/counter_ri7g3` ;

# if the counter is still small, we send stderr to /dev/null
if [ $counter -lt 5 ] ;
    $1 > /dev/null 2>&1 ;
# otherwise stderr will follow its normal path and find its way to email
    $1 > /dev/null ;
fi ;

# lastly if running the $1 resulted in an abnormal exit, the counter is incremented
if [ ! $? = 0 ] ;
    counter=`cat /tmp/counter_ri7g3` ;
    echo "$counter+1" | bc > /tmp/counter_ri7g3 ;
# and if $1 exited normally, we reset the counter
    echo 0 > /tmp/counter_ri7g3 ;
fi ;

a cron entry calling it looks as such:

30 * * * *      root      /usr/local/bin/cron_wrapper "/path/to/script arg_1 arg_2"

IPv6 link-local surface analyzer



Quick Start

    1. make sure that nmap, ifconfig & arping are installed and in your path
    2. run as root

    tested on Ubuntu 11.10 64b


    (actual ips obfuscated)


    With more devices coming IPv6 ready out of the box, a shadow network is emerging that nobody is paying attention to.

    There’s Joe sysadmin, configuring a tight firewall for this new server, default deny, very restrictive & all. This is great but did he realize that there is nothing in front of IPv6? We are used to setting up iptables, ipfw, et cetera. Unfortunately ip6tables & ip6fw too often get forgotten.

    With IPv4, a device was manually configured or wasn’t configured until it got an address from DHCP. With IPv6 a device that is not manually configured will hop on the network with a link-local address and try to further discover its settings. In fact, IPv6 reserves a range of addresses for network discovery, these link-local addresses are based on the device’s mac address.

    Here is what does:

    • iterate through a given IPv4 range
    • for each address in the range, discover if a host sits behind it
    • port scan potentially found host on IPv4
    • infer IPv6 link-local address of host based on its mac address
    • port scan inferred IPv6 address

    The purpose of which is to establish by how much your attack surface is augmented by link-local IPv6.

    This threat threat is somewhat mitigated by its local nature and there are 2 reasons why:

    1. link-local isn’t routed and thus your visibility is bound to networks you have a presence on.
    2. Getting a host’s mac address is only possible while being on the same network.

    Local as it may be, having a shadow network providing a way to circumvent firewalls is quite risky.

    Mame box

    Here’s another project that’s been on the back burner for a while: my new Mame box:

    This is the 5th arcade cabinet I turn into a Mame box. Gutting them always breaks my heart but having all the games in one cabinet with original artwork is very much worth it. The X-men cabinet is spacious, easy to work with and looks great.

    The buttons and joysticks were bought from X-arcade:

    And the control board to make them interface with a PC is an Ipac2: