btm.geek

One of the great features of Chef is that you write configurations in Ruby. When wanting to push a number of configuration files out for nagios, I initially turned to the Remote Directory resource. However this could interfere with configuration files created and owned by the debian package, so I needed to be more specific. In the past with Puppet I’ve had a remote file definition (that uses the file type) for each configuration file. This works fine, but gets to be repetitive when it doesn’t need to be. With Chef, you can combine a little ruby with the Remote File resource like so:

for config in [ "contacts.cfg", "contactgroups.cfg" ] do
  remote_file "/etc/nagios3/#{config}" do
    source "#{config}"
    owner "root"
    group "root"
    mode 0644
    notifies :restart, resources(:service => "nagios"), :delayed
  end
end

The benefit of this approach is that it makes your configuration management cleaner and more DRY. This is perhaps at the cost of a little complexity, albeit at a degree that I think is pretty easily understood by reading the code.

Two or three times now libvirt (0.4.4-3ubuntu3.1, Ubuntu Intrepid 8.10) has automatically generated overlapping MAC addresses on me. I can’t find the source for this MAC address generation in 0.4.4, but in 0.6.1 which is included in Ubuntu Jaunty 9.04 it’s virGenerateMacAddr in src/util.c. This leads me to believe it’s been rewritten, and I’m hoping it’s better. It looks perfectly fine.

In the midst of Jaunty testing, I decided to try out paravirtualized disks with KVM. I switched to virtio for networking a while ago with good results. I already built the guest I’m testing with, so I wanted to modify the libvirt xml file, but didn’t see anything of note related to virtio and storage. I did however deduce that the trick is to change the bus attribute in the target element from ‘ide’ to ‘virtio’. Because Ubuntu uses UUID’s instead of paths, the change from ’sda’ to ‘vda’ didn’t affect startup. I was confused at first though as mount still showed ‘/dev/sda1′ but the dmesg output clearly lacked an ’sd’ device but had a newly acquired ‘vd’ device.

Bonnie++ was run on a single cpu guest with 768MB ram. The guest is Ubuntu Jaunty 9.04 with all of todays packages, using virtio for network + disk. Otherwise pretty standard with everything that might matter. The Host is also Jaunty, running on a Dell 1955 blade with a couple Xeons and about 7GB of RAM. KVM is ‘1:84+dfsg-0ubuntu7′, and libvirt is ‘0.6.1-0ubuntu1′.

The numbers aren’t all that interesting. Virtio was a little bit faster. I’m not that familiar with using bonnie. Who knows if caching or anything negated these tests, I didn’t try to research turning it off. The performance testing was mostly an afterthought of setting it up, as I see no reason not to use it now.

With ide disk driver:

Version 1.03c       ------Sequential Output------ --Sequential Input- --Random-
                    -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine        Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP  /sec %CP
it-util01     1496M 37162  94 56108  20 39997  14 42209  89 247590  59  4706  93
                    ------Sequential Create------ --------Random Create--------
                    -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
              files  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP
                 16 +++++ +++ +++++ +++ +++++ +++ +++++ +++ +++++ +++ +++++ +++
it-util01,1496M,37162,94,56108,20,39997,14,42209,89,247590,59,4705.6,93,16,+++++,+++,+++++,+++,+++++,+++,+++++,+++,+++++,+++,+++++,+++

With virtio disk driver:

Version 1.03c       ------Sequential Output------ --Sequential Input- --Random-
                    -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine        Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP  /sec %CP
it-util01     1496M 39831  88 56480  13 41427  14 45489  86 291109  57  7915  90
                    ------Sequential Create------ --------Random Create--------
                    -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
              files  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP
                 16 +++++ +++ +++++ +++ +++++ +++ +++++ +++ +++++ +++ +++++ +++
it-util01,1496M,39831,88,56480,13,41427,14,45489,86,291109,57,7914.5,90,16,+++++,+++,+++++,+++,+++++,+++,+++++,+++,+++++,+++,+++++,+++

A few minutes ago I got a cold call on my cell phone. I almost didn’t answer, I tend not to answer calls to my cellphone from unknown numbers. I have teams of lawyers and medical people out there looking for me sometimes, so sometimes I must.

The caller said that my SSL certificate was expiring soon with Company A (who I forget because it’s an old certificate for email I don’t use anymore since I switched to Google for mail) and they’d like the chance to win me over. I paused as I added this all up in my head. After I realized it was just telemarketing, I said “No, thanks” and hung up. Then I get an email from them. Scroll down and read it, them come back.

I like the Creating Trust Online part. Is this a strong arm technique meant to scare me into purchasing from them? Are they trying to create some kind of trust in a “we know more than you, buy our stuff” way? Is this Louis character rogue or is this standard operating procedure?

Ways to get me to never buy products or services from you:
1) Call me
2) Call me, then send me an email

I almost filed the call under weird and forgot about it, thanks for the email that I can search for later when I’m shopping for SSL certificates so I know who not to call.

Delivered-To: btm@loftninjas.org
Received: by 10.142.215.17 with SMTP id n17cs645196wfg;
        Thu, 12 Mar 2009 10:48:23 -0700 (PDT)
Received: by 10.150.95.15 with SMTP id s15mr422861ybb.247.1236880102854;
        Thu, 12 Mar 2009 10:48:22 -0700 (PDT)
Return-Path: 
Received: from sharon.nj.office.comodo.net (mail.nj.office.comodo.net [38.104.66.254])
        by mx.google.com with ESMTP id 1si2384323gxk.79.2009.03.12.10.48.18;
        Thu, 12 Mar 2009 10:48:19 -0700 (PDT)
Received-SPF: pass (google.com: domain of louis.cicero@comodo.com designates 38.104.66.254 as permitted sender) client-ip=38.104.66.254;
Authentication-Results: mx.google.com; spf=pass (google.com: domain of louis.cicero@comodo.com designates 38.104.66.254 as permitted sender) smtp.mail=louis.cicero@comodo.com
Received: (qmail 13908 invoked by uid 1001); 12 Mar 2009 17:48:17 -0000
Received: from mmonroe.comodo.net (HELO louisc) (192.168.68.79)
    by sharon.nj.office.comodo.net (qpsmtpd/0.40) with ESMTP; Thu, 12 Mar 2009 13:48:17 -0400
From: "Louis Cicero" 
To: 
Subject: Info on compromised root key
Date: Thu, 12 Mar 2009 13:48:16 -0400
Message-ID: <00a201c9a33a$b955fa20$4f44a8c0@comodo.net>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_00A3_01C9A319.32445A20"
X-Mailer: Microsoft Office Outlook 11
Thread-Index: AcmjOrkMPeS02oldT1mZI5bKFnL3rA==
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350
X-Comodo-Virus-Checked: Checked by ClamAV on sharon.nj.office.comodo.net
X-Comodo-ClamAV-Virus-Program: ClamAV 0.92.1

This is a multi-part message in MIME format.

------=_NextPart_000_00A3_01C9A319.32445A20
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

http://www.computerworld.com/action/article.do?command=viewArticleBasic
 &articleId=9124558&intsrc=it_blogwatch

http://bits.blogs.nytimes.com/2008/12/30/outdated-security-software-threaten
s-web-commerce/

1024-bit encryption is 'compromised'

Upgrade to 2048-bit, says crypto expert

Written by James Middleton

vnunet.com  

According to a security debate sparked off by cryptography expert Lucky
Green on Bugtraq yesterday, 1,024-bit RSA encryption should be "considered
compromised".

The Financial Cryptography conference earlier this month, which largely
focused on a paper   published by
cryptographer Dan Bernstein last October detailing integer factoring
methodologies, revealed "significant practical security implications
impacting the overwhelming majority of deployed systems utilising RSA as the
public key algorithm".

Based on Bernstein's proposed architecture, a panel of experts estimated
that a 1,024-bit RSA factoring device can be built using only commercially
available technology for a price range of several hundred million to $1bn.

These costs would be significantly lowered with the use of a chip fab. As
the panel pointed out: "It is a matter of public record that the National
Security Agency [NSA] as well as the Chinese, Russian, French and many other
intelligence agencies all operate their own fabs."

And as for the prohibitively high price tag, Green warned that we should
keep in mind that the National Reconnaissance Office regularly launches
Signal Intelligence satellites costing close to $2bn each.

"Would the NSA have built a device at less than half the cost of one of its
satellites to be able to decipher the interception data obtained via many
such satellites? The NSA would have to be derelict of duty to not have done
so," he said.

The machine proposed by Bernstein would be able to break a 1,024-bit key in
seconds to minutes. But the security implications of the practical
'breakability' of such a key run far deeper.

None of the commonly deployed systems, such as HTTPS, SSH, IPSec, S/MIME and
PGP, use keys stronger than 1,024-bit, and you would be hard pushed to find
vendors offering support for any more than this.

What this means, according to Green, is that "an opponent capable of
breaking all of the above will have access to virtually any corporate or
private communications and services that are connected to the internet".

"The most sensible recommendation in response to these findings at this time
is to upgrade your security infrastructure to utilise 2,048-bit user keys at
the next convenient opportunity," he advised.

But a comment   from
well known cryptographer Bruce Schneier casts doubt on Bernstein's findings
in practical application.

"It will be years before anyone knows exactly whether, and how, this work
will affect the actual factoring of practical numbers," he said.

But Green, much to the clamour of "overreaction" from the Slashdot
community, added: "In light of the above, I reluctantly revoked all my
personal 1,024-bit PGP keys and the large web-of-trust that these keys have
acquired over time. The keys should be considered compromised."

Whatever the practical security implications, one sharp-witted Slashdot
reader pointed out: "Security is about risk management. If you have
something to protect that's worth $1bn for someone to steal, and the only
protection you have on it is 1,024-bit crypto, you deserve to have it stolen

Louis Cicero

Business Development Executive - Comodo 

Direct Line 1- 908- 376-0145

Main Office US: +1 888.COMODO1 (888.266.6361) ext.4062

Fax US: +1 866-405-5816

Louis.Cicero@Comodo.com 

Creating Trust Online

Comodo   Helps
Leading Cutlery eTailer Increase Individual Transactional Value By Over 250%

Normally I would use ‘openssl passwd’ to generate encrypted passwords for scripts and config files, but it doesn’t appear to support sha256 and sha512 yet. There doesn’t appear to be an openssl ticket for this yet. Ubuntu has switched to using SHA512 by default (see ENCRYPT_METHOD in /etc/login.defs). In the course of tracking down the use of passwd/root-password-crypted not working in a jaunty pxe/network install (LP: 340841), I needed to generated a sha512 password to replace the md5 password in the d-i config file.

15:11 < cjwatson> $ echo cjwatson:foo | chpasswd -S -c SHA512
15:11 < cjwatson> cjwatson:$6$K./rc/OhIRi$ylKWgewTkGP3TyXfwj8nnKyIhph66WucLseLjGKKzRM0oRcuRzng2szcC/JZpY13dLxmlILx7eSfdfMHTruH40

I’ve been working on testing jaunty before it goes live. Winbind stopped working and I initially assumed it was another configuration change. In the end, it was. The caching functionality wasn’t very straight forward so it took me a while to get to a point where I could test configurations without the cache messing with the results. Intrepid to Jaunty is Samba 3.2.3 to 3.3.1, which being a different major version includes some changes. Mostly the internet is chock full of examples that don’t specify the version of Samba that they’re for, and it’s been changing a lot.

It looks like 3.0.21a added support for ‘idmap backend = ad’ for retrieving uid/gid information from active directory. At some point ‘idmap config’ showed up, for maintaining multiple domains. I assume this was around 3.0.25 where ‘idmap domains’ showed up. Apparently with 3.3.0, the ‘idmap backend’ is back, which became depreciated with the 3.0.25 changes. There is talk in the release notes of using ‘idmap uid’ and ‘idmap gid’. I’ve seen errors about these not existing, I just went without. Without further ado, here’s my working winbind config:

[global]
security = ADS
server string = %h server (Samba %v)
workgroup = WM
realm = CORP.WIDEMILE.COM
idmap config WM : backend = ad
idmap config WM : schema_mode = rfc2307
idmap config WM : range = 1000-20000
winbind enum users = Yes
winbind enum groups = Yes
winbind use default domain = Yes
winbind nested groups = Yes
template shell = /bin/bash
template homedir = /home/%U
allow trusted domains = No

The other interesting thing was the caching. I eventually read the code while watching the output of ‘winbind -i -d10 -n -s /etc/samba/smb.test.conf’ and saw that ‘-n’ which is supposed to disable caching doesn’t affect the idmap cache. The ‘winbindd_cache.tdb’ and ‘winbind_idmap.tdb’ files were not said cache. It ended up hiding in ‘/var/run/samba/gencache.tdb’, with who knows what else. You need to delete this file manually each run. I filed a bug over it too.

After a couple of the couchdb developers commented on my earlier post about binary data and couchdb, I took their advice in the next round of testing. I upgraded to CouchDB pre-0.9.0 from svn, then wrote read/write tests for storing data using byte[], base64 String, and byte[] via attachment. The updated code is available in the same github gist. These tests were not scientific. I ran each combination of data type over n threads for 100 iterations and compared the total times. I averaged the results when using more than one thread for the total. Consider the data completely empirical, but the relationship stands. The binary attachments are fast. That’s all we wanted to know.

So fast even I can’t get consistent numbers and the java libraries throw “httpMethodBase.getResponseBody - Going to buffer response body of large or unknown size. Using getResponseBodyAsStream instead is recommended.” I left the ‘attach read’ out of the graph to keep the numbers on a closer scale.