544 Posts By ben
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 ] ; then 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 ] ; then $1 > /dev/null 2>&1 ; # otherwise stderr will follow its normal path and find its way to email else $1 > /dev/null ; fi ; # lastly if running the $1 resulted in an abnormal exit, the counter is incremented if [ ! $? = 0 ] ; then counter=`cat /tmp/counter_ri7g3` ; echo "$counter+1" | bc > /tmp/counter_ri7g3 ; # and if $1 exited normally, we reset the counter else 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"
- make sure that nmap, ifconfig & arping are installed and in your path
- 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 ipv6_surface_analyzer.py 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:
- link-local isn’t routed and thus your visibility is bound to networks you have a presence on.
- 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.
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: www.xgaming.com
And the control board to make them interface with a PC is an Ipac2: www.ultimarc.com
It can also be addressed directly via:
for all your API needs.
Link-local IPv6 addresses are used as part of the IPv6 network auto-configuration process. Instead of getting an address via DHCP, a NIC will hop on the network with a link-local IPv6 address and with this will have to ability to do further configuration automatically (soliciting neighbors, router, et cetera).
This link-local IPv6 is infered from the NIC’s mac address.
A mac address is 48 bits, an IPv6 address is 128 bits. Here’s the conversion process step by step:
- take the mac address: for example 52:74:f2:b1:a8:7f
- throw ff:fe in the middle: 52:74:f2:ff:fe:b1:a8:7f
- reformat to IPv6 notation 5274:f2ff:feb1:a87f
- convert the first octet from hexadecimal to binary: 52 -> 01010010
- invert the bit at index 6 (counting from 0): 01010010 -> 01010000
- convert octet back to hexadecimal: 01010000 -> 50
- replace first octet with newly calculated one: 5074:f2ff:feb1:a87f
- prepend the link-local prefix: fe80::5074:f2ff:feb1:a87f
Going the other way
A converter to do the same operation in reverse is available here.
There have been a few interesting comments on this post, I encourage you to read them if you want to learn more about this mechanism. Specifically:
Modeling in Google Sketchup really helped make building fast & seamless. The 2x12x16 are very thick so the hive weights a ton, on the other hand joining pieces was really easy as there is much surface for glue and screws. And I hope this will provide some good insulation against New England winters.
Here’s a Google Sketchup design for a simple top-bar beehive.
Only 2 measurements really matter in the design of a top-bar beehive: the angle of the side panels (70 degrees) & the width of the top bars 35mm. They both pertain to bee behavior and this design has them both optimized. From what I gather, other measures are quite forgiving.
This design is simple & well researched, I do not know yet how it will fare in practice, more to come on that.
All you’ll need as far as wood is concerned is a couple of 2x12x16 and a 3/4″ sheet of plywood:
My wife & I have just released our first children story! As an app for iOS devices. This is the achievement of what started innocently as a small project reading stories to mp3. Months of work, huge investment for the art, it feels great to have put this project behind us.
My only hope now is that the market gods will treat us well.
Here it is in all its glory:
English version: http://itunes.apple.com/us/app/id480065432
Hungarian version: http://itunes.apple.com/us/app/id480080998
French version: http://itunes.apple.com/us/app/id480175112