RT initialdata and Perl’s nested map

Request Tracker (aka RT) comes with a very powerful, yet not too widely known tool – initialdata.  This helps with automating configuration of the new system and data migration.  Combined with the power of Perl’s map() function, some really awesome things can be done in a jiffy.

Here is a snippet I’ve used recently, to set a list of access rights to a list of queues:

push @ACL, map {
  my $queue = $_;
  map {
    {
      GroupDomain => 'SystemInternal',
      GroupType => 'Everyone',
      Queue => $queue,
      Right => $_,
    }
  } qw(
    CreateTicket
    ReplyToTicket
  )
} qw(
  dpt-Support-EN
  dpt-Support-RU
  dpt-Support-FR
);

Nginx and Memcached, a 400% boost!

Here is an idea to try on a slow weekend: Nginx and Memcached, a 400% boost!

nginx_memcache

 

Memcached, the darling of every web-developer, is capable of turning almost any application into a speed-demon. Benchmarking one of my own Rails applications resulted in ~850 req/s on commodity, non-optimized hardware – more than enough in the case of this application. However, what if we took Mongrel out of the equation? Nginx, by default, comes prepackaged with the Memcached module, which allows us to bypass the Mongrel servers and talk to Memcached directly. Same hardware, and a quick test later: ~3,550 req/s, or almost a 400% improvement! Not bad for a five minute tweak!

Software Engineering Radio : CAP Theorem

On the way to work today I enjoyed an excellent episode of Software Engineering Radio which featured an interview with Eric Brewer, a VP of Infrastructure at Google,  probably more famous for his CAP Theorem.

In theoretical computer science, the CAP theorem, also known as Brewer’s theorem, states that it is impossible for a distributed computer system to simultaneously provide all three of the following guarantees:

  • Consistency (all nodes see the same data at the same time)
  • Availability (a guarantee that every request receives a response about whether it succeeded or failed)
  • Partition tolerance (the system continues to operate despite arbitrary message loss or failure of part of the system)

The discussion around “2 out of 3″ was very thought-provoking and, at first, a little bit counter-intuitive.  If you don’t want to listen to the show, read though this page, which covers the important bits.

The easiest way to understand CAP is to think of two nodes on opposite sides of a partition. Allowing at least one node to update state will cause the nodes to become inconsistent, thus forfeiting C. Likewise, if the choice is to preserve consistency, one side of the partition must act as if it is unavailable, thus forfeiting A. Only when nodes communicate is it possible to preserve both consistency and availability, thereby forfeiting P. The general belief is that for wide-area systems, designers cannot forfeit P and therefore have a difficult choice between C and A. In some sense, the NoSQL movement is about creating choices that focus on availability first and consistency second; databases that adhere to ACID properties (atomicity, consistency, isolation, and durability) do the opposite.

This puts some of the current trends into perspective.

Alex Stamos : AppSec is Eating Security

I’m throwing this into the pile of arguments for “security and privacy are little but myths” discussions.  If top of the top companies, with multi-million budgets and hundreds or thousands of top security professionals get compromised, how realistic is it for the average Joe to protect his business?  I say – not very.

I think 80% of problems can be prevented with the 20% time and effort investment: minimize attack surface by removing and disabling everything you don’t need or use and limiting access to everything else, use layered defense where possible, use encryption where possible and strong passwords if you have to, don’t rely on security through obscurity, have log analyzers and/or intrusion detection system installed, etc.  But most importantly, make peace with the fact that being compromised is not the question of “if”, but “when”.  Prepare yourself.  Have an offsite backup and know how to restore your services in a completely new environment, if necessary.

And as far as your privacy goes, if you put anything private on the Internet, as well, prepare for it to be stolen and leaked.  If it never happens, consider yourself lucky.  Otherwise, just learn to deal with it.  It’s very unpleasant in a variety of ways, but seldom deadly.

Via EtherealMind.