Recently in Systems Category

I be, you be, Yubikey

| No Comments | No TrackBacks
Cool, and simple.  The Yubikey is a one-time password generator in a USB key.  Plug in in and it emulates a USB keyboard.  Touch the button on it and it will type out a one-time use password.  Basically the same system as "rolling code" garage door openers.

The hardware should be pretty cheap having no battery like the RSA SecurID tokens, just a microcontroller.   It claims to be somewhat resistant to phishing, though I cannot see how that works. 

The YubiKey
It works seamlessly with any hardware and operating system combination supporting USB keyboards such as Windows, MacOS, Linux and others. The Key generates and sends unique time-variant authentication codes by emulating keystrokes through the standard keyboard interface. The computer to which the Key is attached receives this authentication code character by character just as if it were being typed in from the keyboard - yet it's all performed automatically. This process allows the Key to be used with any application or Web-based service without any need for special client computer interaction or drivers.

The YubiKey differs from traditional authentication tokens based on time-variant codes in that it needs no battery and therefore does not rely on an absolute time generated by an accurate time source. No battery means unlimited shelf life, no synchronization and customer support issues, and enables significant cost reduction.

Link

I was writing a build script in Bash for one of the development projects and I wanted to have a list of patches that would be applied to a "clean" distribution of JBoss to create the fully configured app server.  I needed something simple so the development team could continue to maintain and update the script.  I came up with this idea while looking at RPM building.


#!/bin/bash

PATCH0=$SOURCES/jboss-4.2.3.GA.base.patch
PATCH1=$SOURCES/log4j-setup-append.patch
PATCH2=$SOURCES/jboss-set-call-by-value.patch
PATCH3=$SOURCES/add-security-policy-login.patch
MAXPATCHES=100  #The script searches for PATCH{value}= lines from zero to this number

echo "Applying patches"
i=0
while [ $i -lt $MAXPATCHES ] ; do
  PATCH=$(eval echo $echo PATCH${i});
  if [ ! "$PATCH" == "" ] ; then
    echo "Applying patch: $PATCH"
    patch -p0 < $PATCH
  fi
  i=$[$i+1]
done;


In the end it might have been simpler to use a datafile, or a language with Array support, but this works well enough and is fairly usable.

Opportunity knocks, but usually the door is locked

| No Comments | No TrackBacks
Rather Interesting, it is a very nicely designed central locking system for server cabinets.  The TZ Praetorian uses an end of row control pad and standard access control device (badge reader, biometric station etc) and ties into your existing access control system.  All of the lock controls are low current (unlike magnetic locks) and are designed to run over standard UTP cabling.  Door open/close indication is built in and displayed on the end of the row, so unsecured cabinets can be caught quickly.

Watch the video... 

http://anixter.com/praetorian

Failover, Fail

| No Comments | No TrackBacks
Datacenter to datacenter failover for many database backed websites is hard.  For it to work well it must be designed into the app.. Please don't expect your Operations team to fire up DB replication and have it magically work.

  • Autoincrement fields?  DB supported, or hosted in the app, what happens if both sites are up? Can you get conflicting ids?
  • Background jobs... how to you make sure only one copy is running or tolerate several?
  • Latency... Can you even replicate the data in real time?
  • Failover reponse... manual operation?  Automated?
  • IP/DNS issues, the simplest failover is to change DNS entries, but that can take a significant amount of time to replicate.  Will your customers wait?
  • How will you QA?  Test failover in prod?  Dual QA envs?
  • Failback?  How are you going to switch back?

Another Disaster Recovery Plan Tip

| No Comments | No TrackBacks
Here's one that should be in everyone's Disaster Recovery Plan/Operations Manual:  What to do and whom to call when the government shows up with a search and seizure warrant.

Because of the confiscation of computers at Core IP Networks, a number of legitimate businesses have been affected.

From the downtown office building in the 2300 block of Bryan Street, FBI agents seized what one source described as millions of dollars in computer equipment.

Matthew Simpson, the owner of Core IP Networks, said in a letter posted online that FBI agents raided two floors and 'pulled the plug' on his clients' web servers starting at 6 o'clock Thursday morning. Agents also raided Simpson's house in Ovilla.
Link

If you are a co-location or managed services customer and uptime is important to you, don't put all your eggs in one datacenter, and have a good plan on how to fail over.  No matter how redundant or what Tier your datacenter provider offers, outages at the datacenter level still happen.

My advice (INAL, and I know nothing about the legal issues)... If you are providing a shared resource to customers, either datacenter space, bandwidth services or shared hosting have a plan for dealing with search warrents.  It seems most will be polite requests during business hours but some may not.  You don't want your on-site tech trying to decide if he should allow the police in the door.  Make sure Operations has on call access to Legal, or knows someone high enough who can reach legal services in time.   

On another note...I do hope Simpson is not the focus of the investigation solely because his name is on the IP allocation.

About this Archive

This page is an archive of recent entries in the Systems category.

REVOLT is the previous category.

Find recent content on the main index or look in the archives to find all content.

Powered by Movable Type 4.24-en