Planet SysAdmin

Chris Siebenmann: The Solaris 10 NFS server's caching of filesystem access permissions

Tue, 16 Mar 2010 05:06:51 +0000

The Solaris 10 NFS server's caching of filesystem access permissions

Earlier, I mentioned that modern NFS servers don't have a comprehensive list of NFS filesystem access permissions stored in the kernel; instead they have a cache and some sort of upcall mechanism where the kernel will ask mountd if a given client has access to a given filesystem if necessary. I've recently been investigating how Solaris 10 handles this, so here's what I know of the kernel authorization cache:

First, the Solaris kernel does cache negative entries (this IP address is not allowed to access this filesystem at all). This turns out to be fairly dangerous, because the cache has no timeout. If a negative entry is ever checked and cached, it will stay there until you flush the filesystem's cache entirely.

(The same is true of positive entries that you want to get rid of, either because you've removed a client's authorization or because you want to change how the filesystem is exported to it; part of the cache entry is whether the client has read-write or read-only access, and whether root is remapped or not. Or just because a machine has changed IP address and you want to get rid of any permissions that the old IP address has.)

The overall cache has no size limit at all, beyond a general one set by kernel memory limits. It will get shrunk if the kernel needs to reclaim memory, but even then no entry less than 60 minutes old will be removed. In our environment, such cache reclaims appear to be vanishingly uncommon (ie, completely unseen), based on kernel stats.

There is a separate auth cache for each exported filesystem. As far as I can tell, a filesystem's auth cache is discarded entirely if it is unshared or reshared, including if it is reshared with the same sharing settings. It otherwise effectively never expires entries. Flushing a filesystem's auth cache causes every client to be revalidated the next time that they make an NFS request to that filesystem.

Because all of this is only in kernel memory, all auth caches are lost if the system reboots. Thus on fileserver reboot all clients are revalidated for all filesystems on a rolling basis, as each client tries to do NFS to each filesystem that they have mounted. This may provoke a storm of revalidations after the reboot of a popular fileserver with a bunch of clients.

The cache is populated by upcalling to mountd on hopefully infrequent demand (through mechanisms that are beyond the scope of this entry). If mountd answers properly its answer of the moment, whatever that is, gets cached. There are presumably timeout and load limits on these upcalls, but I don't understand (Open)Solaris code well enough yet to find them. (I hope that more than one upcall can be in progress at once.)

Sidebar: Getting cache stats

This is for the benefit of people (such as me) poking around with mdb -k. The internal NFS server auth cache stats are in three variables: nfsauth_cache_hit, nfsauth_cache_miss, and nfsauth_cache_reclaim, which counts how many times a reclaim has been done (but not how many entries have been reclaimed). To see them (in hex) one uses the mdb command:

nfsauth_cache_hit ::print

The code for most of this is in nfs_auth.c in usr/src/uts/common/fs/nfs; see also nfs_export.c, which has the overall NFS server export list.

Brian Jones: Quick Loghetti Update

Tue, 16 Mar 2010 00:23:01 +0000

For the familiar and impatient: Loghetti has moved to github and has been updated. An official release hasn’t been made yet, but cloning the repository and installing argparse will result in perfectly usable code. More on the way.

For the uninitiated, Loghetti is a command line log sifting/reporting tool written in Python to parse Apache Combined Format log files. It was initially released in late 2008 on Google Code. I used loghetti for my own work, which involved sifting log files with tens of millions of lines. Needless to say, it needed to be reasonably fast, and give me a decent amount of control over the data returned. It also had to be easy to use; just because it’s fast doesn’t mean I want to retype my command because of confusing options or the like.

So, loghetti is reasonably fast, and reasonably easy, and gives a reasonable amount of control to the end user. It’s certainly a heckuva lot easier than writing regular expressions into ‘grep’ and doing the ol’ ‘press & pray’.

Loghetti suffered a bit over the last several months because one of its dependencies broke backward compatibility with earlier releases. Such is the nature of development. Last night I finally got to crack open the code for loghetti again, and was able to put a solution together in an hour or so, which surprised me.

I was able to completely replace Doug Hellmann’s CommandLineApp with argparse very, very quickly. Of course, CommandLineApp was taking on responsibility for actually running the app itself (the main loghetti class was a subclass of CommandLineApp), and was dealing with the options, error handling, and all that jazz. It’s also wonderfully generic, and is written so that pretty much any app, regardless of the type of options it takes, could run as a CommandLineApp.

argparse was not a fast friend of mine. I stumbled a little over whether I should just update the namespace of my main class via argparse, or if I should pass in the Namespace object, or… something else. Eventually, I got what I needed, and not much more.

So loghetti now requires argparse, which is not part of the standard library, so why replace what I knew with some other (foreign) library? Because argparse is, as I understand it, slated for inclusion in Python 3, at which point optparse will be deprecated.

So, head on over to the GitHub repo, give it a spin, and send your pull requests and patches. Let the games begin!

Brian Jones: Programmers that… can’t program.

Tue, 16 Mar 2010 00:06:19 +0000

So, I happened across this post about hiring programmers, which references two other posts about hiring programmers. There seems to be a demand for blog posts about hiring programmers, but that’s not why I’m writing this. I’m writing because there was this sort of nagging irony that I couldn’t help but stumble upon.

In a blog post, Joel Spolsky talks about the mathematical inaccuracies associated with claims of “only hiring the top 1%”. It seemed pretty obvious to me that whether or not you’re hiring the top 1% of all programmers is pretty much unknowable, and when managers say they hire “the top 1%”, I assume they’re talking about the top 1% of their applicants. Note too that I always thought it was idiotic to point this out, because, well, isn’t that what you’re SUPPOSED to do? You’re not very well going to aim for the middle & hope for the best are you?

Apparently I’ve been giving too much credit to management. There I go giving people with ties on the benefit of the doubt again.

Then, in another blog post, Jeff Atwood talks about how it’s very difficult to even get interviews with programmers who can actually program. The problem is real.

The original blog post that pointed me at the two others is one by Roberto Alsina where he talks about his own methods for weeding out the non-programmers. He’s clearly seen the issue as well.

But if you open all three of these posts in separate tabs and read them, you’re likely to come away with the same basic problem I did:

Who the hell are these managers who can’t figure out a dead simple statistics problem?
How can a person fairly inept at simple math be qualified to make a hiring decision for anything but a summer intern?

That sorta blew my mind a little. But it blew my mind a lot when Atwood started describing the problems that interviewees *couldn’t* perform in an interview! One task described by Imran was called a ‘FizzBuzz’ question. Here’s one such question:

Write a program that prints the numbers from 1 to 100. But for multiples of three print “Fizz” instead of the number and for the multiples of five print “Buzz”. For numbers which are multiples of both three and five print “FizzBuzz”.

Here’s the part that blew my mind: He says, and I quote:

Most good programmers should be able to write out on paper a program which does this in a under a couple of minutes.

Want to know something scary ? – the majority of comp sci graduates can’t. I’ve also seen self-proclaimed senior programmers take more than 10-15 minutes to write a solution.

That’s amazing to me. I decided to quickly pop open a Python prompt and see if I could do it:

>>> for i in range(1,101):
...     if (i % 3 == 0) and (i % 5 == 0):
...             print i,'FizzBuzz'
...     elif i % 3 == 0:
...             print i, 'Fizz'
...     elif i % 5 == 0:
...             print i, 'Buzz'
...     else:
...             print i
...

Turns out it worked on the first try! That was pasted directly from my terminal screen. I didn’t time myself, but it took far less than 5 minutes. This leads to my other question, of course, which is “if you’re going to complain about CS degree holders not writing good code, maybe it’s time to open the doors to non-CS degree holders?”

TechRepublic IT Security: Are users right in rejecting security advice?

Mon, 15 Mar 2010 21:10:19 +0000

Should you change your passwords often? What’s the risk if you don’t? Little did I know, listening to one podcast would cause me to rethink how I would answer those questions.

—————————————————————————————

I now understand why my friend insisted I listen to Episode 229 of the Security Now series. He wanted to introduce me to Cormac Herley, Principle Researcher at Microsoft and his paper, “So Long, and No Thanks for the Externalities: The Rational Rejection of Security Advice by Users.”

Dr. Herley introduced the paper this past September at the New Security Paradigms Workshop, a fitting venue. See if you agree after reading the group’s mandate:

“NSPW’s focus is on work that challenges the dominant approaches and perspectives in computer security. In the past, such challenges have taken the form of critiques of existing practice as well as novel, sometimes controversial, and often immature approaches to defending computer systems.

By providing a forum for important security research that isn’t suitable for mainstream security venues, NSPW aims to foster paradigm shifts in information security.”

Herley’s paper is of special interest to the group. Not only does it meet one of NSPW’s tenets of being outside the mainstream. It forces a rethink of what’s important when it comes to computer security.

Radical thinking

To get an idea of what the paper is about, here’s a quote from the introduction:

“We argue that users’ rejection of the security advice they receive is entirely rational from an economic perspective. The advice offers to shield them from the direct costs of attacks, but burdens them with far greater indirect costs in the form of effort. Looking at various examples of security advice we find that the advice is complex and growing, but the benefit is largely speculative or moot.”

The above diagram (courtesy of Cormac Herley) shows what he considers as direct and indirect costs. So, is Herley saying that heeding advice about computer security is not worth it? Let’s find out.

Who’s right

Researchers have different ideas as to why people fail to use security measures. Some feel that regardless of what happens, users will only do the minimum required. Others believe security tasks are rejected because users consider them to be a pain. A third group maintains user education is not working.

Herley offers a different viewpoint. He contends that user rejection of security advice is based entirely on the economics of the process. He offers the following as reasons why:

Users understand, there is no assurance that heeding advice will protect them from attacks.
Users also know that each additional security measure adds cost.
Users perceive attacks to be rare. Not so with security advice; it’s a constant burden, thus costs more than an actual attack.

To explain

As I read the paper, I sensed Herley was coaxing me to stop thinking like an IT professional and start thinking like a mainstream user. That way, I would understand the following:

The sheer volume of advice is overwhelming. There is no way to keep up with it. Besides that, the advice is fluid. What’s right one day may not be the next. I agree, this link is to US-CERT security bulletins for just the week of March 1, 2010.
The typical user does not always see benefit from heeding security advice. I once again agree. Try to explain to someone who had a password stolen by a key logger, why a strong password is important.
The benefit of heeding security advice is speculative. I checked and could not find significant data on the number and severity of attacks users encounter. Let alone, data quantifying positive feedback from following security advice.

Cost versus benefit

I wasn’t making the connection between cost-benefit trade-offs and IT security. My son, an astute business-type, had to explain that costs and benefits do not always directly refer to financial gains or losses. After hearing that, things started making sense. One such cost analysis was described by Steve Gibson in the podcast.

Gibson simply asked, how often do you require passwords to be changed? I asked several system administrators what time frame they used, most responded once a month. Using Herley’s logic, that means an attacker potentially has a whole month to use the password.

So, is the cost of having users struggle with new password every month beneficial? Before you answer, you may also want to think about bad practices users implement because of the frequent-change policy:

By the time a user is comfortable with a password, it’s time to change. So, users opt to write passwords down. That’s another whole debate; ask Bruce Schneier.

Users know how many passwords the system remembers and cycle through that amount, which allows them to keep using the same one.

Is anything truly gained by having passwords changed often? The only benefit I see is if the attacker does not use the password within the password-refresh time limit. What’s your opinion? Is changing passwords monthly, a benefit or a cost?

Dr. Herley does an in-depth cost-benefit analysis in three specific areas, password rules, phishing URLs, and SSL certificate errors. I would like to spend some time with each.

Password rules

Password rules place the entire burden on the user. So, they understand the cost from having to abide by the following rules:

Length
Composition (e.g. digits, special characters)
Non-dictionary words (in any language).
Don’t write it down
Don’t share it with anyone
Change it often
Don’t re-use passwords across sites

The report proceeds to explain how each rule is not really helpful. For example, the first three rules are not important, as most applications and Web sites have a lock out rule that restricts access after so many tries. I already touched on why “Change it often” is not considered helpful.

All said and done, users know that strictly observing the above rules is no guarantee of being safe from exploits. That makes it difficult for them to justify the additional effort and associated cost.

Phishing URLs

Trying to explain URL spoofing to users is complicated. Besides, by the time you get through half of all possible iterations, most users are not listening. For example, the following slide (courtesy of Cormac Herley) lists some spoofed URLs for PayPal:

To reduce cost to users, Herley wants to turn this around. He explains that users need to know when the URL is good, not bad:

“The main difficulty in teaching users to read URLs is that in certain cases this allows users to know when something is bad, but it never gives a guarantee that something is good. Thus the advice cannot be exhaustive and is full of exceptions.”

Certificate errors

For the most part, people understand SSL, the significance of https, and are willing to put up with the additional burden to keep their personal and financial information safe. Certificate errors are a different matter. Users do not understand their significance and for the most part ignore them.

I’m as guilty as the next when it comes to certificate warnings. I feel like I’m taking a chance, yet what other options are available? After reading the report, I am not as concerned. Why, statistics show that virtually all certificate errors are false positives.

The report also reflects the irony of thinking that ignored certificate warnings will lead to problems. Typically, bad guys do not use SSL on their phishing sites and if they do, they are going to make sure their certificates work, not wanting to bring any undue attention to their exploit. Herley states it this way:

“Even if 100% of certificate errors are false positives it does not mean that we can dispense with certificates. However, it does mean that for users the idea that certificate errors are a useful tool in protecting them from harm is entirely abstract and not evidence-based. The effort we ask of them is real, while the harm we warn them of is theoretical.”

Outside the box

There you have it. Is that radical-enough thinking for you? It is for me. That said, Dr. Herley offers the following advice:

“We do not wish to give the impression that all security advice is counter-productive. In fact, we believe our conclusions are encouraging rather than discouraging. We have argued that the cost-benefit trade off for most security advice is simply unfavorable: users are offered too little benefit for too much cost.

Better advice might produce a different outcome. This is better than the alternative hypothesis that users are irrational. This suggests that security advice that has compelling cost-benefit trade off has real chance of user adoption. However, the costs and benefits have to be those the user cares about, not those we think the user ought to care about. “

Herley offers the following advice to help us get out of this mess:

We need an estimate of the victimization rate for any exploit when designing appropriate security advice. Without this we end up doing worst-case risk analysis.

User education is a cost borne by the whole population, while offering benefit only to the fraction that fall victim. Thus the cost of any security advice should be in proportion to the victimization rate.

Retiring advice that is no longer compelling is necessary. Many of the instructions with which we burden users do little to address the current harms that they face.

We must prioritize advice. In trying to defend everything we end up defending nothing. When we provide long lists of unordered advice we abdicate all opportunity to have influence and abandon users to fend for themselves.

We must respect users’ time and effort. Viewing the user’s time as worth $2.6 billion an hour is a better starting point than valuing it at zero.

Final thoughts

The big picture idea I am taking away from Dr. Herley’s paper is that users have never been offered security. All the advice, policies, directives, and what not offered in the name of IT security only promotes reduced risk. Could changing that be the paradigm shift needed to get information security on track?

I want to thank Dr. Cormac Herley for his thought-provoking paper and e-mail conversation.

Standalone Sysadmin: NJ SysAdmin Conference Early Bird Extended

Mon, 15 Mar 2010 20:20:58 +0000

PRESS RELEASE

Discounted fee schedule ends Sunday, March 21st

New Brunswick, NJ, Today 42, 2010 – The Professional IT Community Conference (PICC) early bird registration prices have been extended for one week, in order to assist area administrators who have been hit with the economic downturn. This short term rate reduction ends Sunday, March 21st. Until that time, the price for the two-day conference is $249, or $399 for the conference and training. Special low prices are available for students, as well, with conference and training only $99.

The New Jersey chapter of the League of Professional System Administrators, an organization dedicated to facilitating information exchange pertaining to the field of system administration, extended the reduced rate “early bird” registration, citing their desire to ensure that all area system administrators had a chance to take part in the conference. The significantly reduced pricing schedule has been designed to appeal to administrators from infrastructures of all sizes. The conference will be held Friday, May 7th through Saturday, May 8th at the Hyatt Regency in New Brunswick.

The Professional IT Community Conference is a gathering of people from the diverse IT community in New Jersey to learn, share ideas, and network. The conference will include invited speakers and keynotes, top-notch training sessions that are relevant, useful, and recession-friendly, as well as an “unconference” track where attendees propose and host their own topics.

LOPSA-NJ and the Professional IT Community Conference are dedicated to fostering our local expert community and strengthening tomorrow’s computing infrastructure.

For Media Inquiries:

Matt Simmons
PICC Marketing Chairman
http://www.picconf.org
Email: media@lopsanj.org
Tel: +1 (740) 403-9997

SysAdmin1138: Centralized IT

Mon, 15 Mar 2010 18:26:25 +0000

I've had quite a bit of experience with the process of centralizing IT. At my last job I was at ground zero as I was on the committee that was charged with rationalizing an IT job family structure that was grounded in the early 1980's (key clue, the phrase, "electronic data processing" was slathered across many job titles, a phrase not at all in vogue in the 1990's). This particular consolidation event was driven from a directive from on high, above the CIO. So, as it were, it happened in spite of the grumbling.

WWU has gone through some of its own consolidations, but there are natural barriers to complete consolidation in the Higher Ed market. I'll get to those in a bit. The one thing acting as a serious barrier to consolidation in any organization are departments that are large enough to support their own multi-person IT departments. Departments with one or two people effectively doing the full IT stack (stand-alone sysadmins who also do desktop support, database maintenance, to-the-desk network wiring, and maybe a bit of app-dev along the side) are most vulnerable to being consolidated into the central Borg.

Some departments are all too happy to join the central IT infrastructure, as they see it as a way to shed costs onto another business unit. Others are happy because their own IT people are so overworked, the idea of getting them help is seen as a cost-free mercy; or put another way agreeing to consolidation is seen as a cost-free way to increase IT investment. Still others are happy to join because they want some nifty new technology and their stick-in-the-mud IT people keep saying, "no," and view the central Borg as a way to get that thing.

The big reason departments don't want their IT people consolidated away from them is personalized service. These are people who know the business intimately, something those central-office folk don't. The cost of maintaining an independent IT infrastructure is seen as a perfectly valid business investment in operational efficiency. Any centralization initiative will have to deal with this concern.

The other big reason shows up less often, but is very hard to overcome without marching orders delivered from On High: distrust of central IT in specific. If the business unit that contains central IT is seen to be less competent as compared to the local IT people, that business unit will not consent to centralization. If the people in central IT are collectively viewed as a bunch of idiots, or run by idiots, the only way that unit is centralizing is if a metaphorical gun is held to their heads.

My last job handled the all of the above and eventually came to an agreement. First and foremost, it was a fiat from On High that IT centralization would happen. All IT job titles started being paid out of the same budget. We then spent the next four years hammering out the management structure, which meant that for a long time a whole bunch of people had their salary paid by people with 0% influence on their work direction.

Many departments gleefully joined the central infrastructure, driven in large part by their own IT people. They'd been overworked, you see, and the idea of gaining access to a much wider talent pool, and a significantly deeper one as well, was hard to not take advantage of. These were the departments with 1-3 IT people. In almost every case the local IT people stayed in their areas as the local IT contact, which maintained the local knowledge they'd developed over the years.

There was one small department that was a holdout until the very end. An attempt to merge some 5 years earlier had gone horribly wrong, and institutional memory remembered that very clearly. It wasn't until that department got a new director that an agreement was reached. The one IT guy up there stayed up there after the merger and stopped doing server and desktop support in favor of department-specific app-dev work, what he was hired to do in the first place as it happened.

Then the arm-wrestling over the bigger departments took place. For the most part they kept near complete control over their own IT staffs, but their top level IT managers were regularly hauled back to the home IT office for 'management team meetings'. This ended up being a good move, since it reduced the barriers for communication at the very top level, and ultimately lead to some better efficiencies overall; especially in the helpdesk area as staff started to move between stacks after a while. Also, the departments that had been deeply skeptical of this whole centralized IT thing started working with other IT managers and getting their concerns heard, which reduced some of the inherent distrust.

With Higher Ed, there is an additional factor or two that my previous job didn't face. First of all, the historic independence of specific Colleges. Second, Universities are generally a lot less command-and-control than their .com or even .gov brethren. This means that centralization relies far more on direct diplomacy between IT business units than it does on direct commands from on high. Distrust in this environment is much more hard to overcome as coercion is not a readily available option.

Back in the day, WWU had 7 separate NDS trees. 7. That's a lot. Obviously, there wasn't much in the way of cross-departmental access of data. Over the course of around 5 years we consolidated down to a single 'WWU' NDS tree. Some departments happily stopped spending IT time on account maintenance tasks and let central IT do it all. Some departments gave up their servers all together. Time passed and still more areas decided they really didn't need to bother keeping local replicas, and let central IT handle that problem.

In the end, handling IT in Higher Ed means dealing with a more heterogeneous environment than is otherwise cost-effective. I've mentioned before how network management on Higher Ed networks resembles ISPs more than it does corporate networks, and that unfortunately applies to things like server and storage purchases. Now that we're in the process of migrating off of NetWare and onto Windows, it means we're now in the process of wrangling over rules governing Active Directory management.

We wrangled NDS control back in the 90's and early 00's, and now it's Microsoft's turn. As with the last round of NDS wrangling, some departments have gleefully turned over control (GPOs and file-server management specifically) of their department over to us in ITS. Others, specifically one with a large local IT presence, is really holding out for complete control of their area. They're clearly angling to just use us as an authentication provider and they'll do the rest, something that... well... negotiations are ongoing.

My crystal ball says we have somewhere between 5 to 10 years before the next wave of 'directory' upgrade forces another consolidation. That consolidation just might involve consolidating with a State agency of some kind. Perhaps the State will force us to use a directory rooted in the wa.gov DNS domain (wwu.univ.wa.gov perhaps), and our Auth servers will be based in Olympia rather than on our local network. Don't know. What is true, is that we'll be going through this again, probably within the next decade.

:wq: How I develop Clojure with Vim

Mon, 15 Mar 2010 17:30:48 +0000

Recently Lau Jensen wrote a post talking about the features of Emacs and why it increases the productivity of Clojure programmers. While I don’t disagree that lisp programming in general benefits greatly from using Emacs as an editor, there are simply people who are too heavily invested into Vim (like myself) for things like viper-mode to work for them. So, I thought I’d share how I do Clojure development with Vim. Throw in my 2 cents.

The key (for me) to editing Clojure code in Vim is a combination of two plugins, VimClojure and slime.vim (see associated blog post). One of the difficult things is that slime.vim doesn’t actually exist anywhere on vim.org’s list of scripts, so it has to be downloaded from the aforementioned blog post. Stick it in the ~/.vim/plugins directory to install it.

First, VimClojure. I tend not to use Nailgun at all, some people like it, I don’t. So instead of the regular install for vimclojure, I copy over the files from the autoload, doc, ftdetect, ftplugin, indent and syntax folders to their respective Vim folders. If you think you’ll want the Nailgun functionality, you should use the installation instructions provided by Kotarak.

Now, add the settings you need for VimClojure to your .vimrc:

" Settings for VimClojure let g:clj_highlight_builtins=1 " Highlight Clojure's builtins let g:clj_paren_rainbow=1 " Rainbow parentheses'!

I have to say, rainbow parentheses’ is one of the best features of vimclojure, making it easy to see exactly what parentheses closes which statement:

Now that VimClojure is set up, time to set up the integration with Clojure’s REPL, to do that I use slime.vim. Slime.vim uses screen to send the input from your editor to any window in a running screen session, so to get started we’ll have to start up a screen session. To make it easier, you can name it something so you don’t have to look up the pid, I’ll call this session “clojure”:

‹ ~ › : screen -S clojure

If you didn’t name your session, or forgot what you named it, you can use screen -ls to look up all the screen sessions you’ve started:

‹ ~ › : screen -ls There are screens on: 41837.clojure (Attached) 8970.ttys000.Xanadu (Attached) 8990.ttys001.Xanadu (Attached) 9010.ttys002.Xanadu (Attached) 4 Sockets in /tmp/screens/S-hinmanm.

Now, start a REPL in the screen terminal window (use ‘clj’ or ‘lein REPL’ or however you like to start a Clojure REPL). Next, open a clojure file with Vim, highlight a block of code (slime.vim will automatically select a paragraph if your cursor is in the middle of something like a defn), now, press Control-c + Control-c (Ctrl+c twice in a row). You should be prompted by Vim like this:

Enter the name of the screen term, if you named your session “clojure” you’d enter “clojure”, if you didn’t name it, use the pid number you see from the output of ’screen -ls’, next it will ask for which window to send the output to:

If you’ve used screen before (and I’m assuming you have), this is the window number your REPL is running on. After you enter this information the plugin will send the paragraph/line of text to the REPL. From here on the session id and window will be cached, so hitting ctrl+c,ctrl+c again will immediately send whatever function the cursor is on to the REPL. You can also select a block of code using visual mode and use ctrl+c,ctrl+c to send everything selected to the REPL. If you used the wrong numbers, use ctrl+c,v (Control+c, then v) to have slime.vim ask you for the numbers again.

There you go, you now have a 1-way pipe from your Vim editor to any kind of REPL (be it Clojure, Ruby or Python). Here’s a couple of screenshots of the plugin in action:

I know this doesn’t even come close to the amount of integration the Emacs has using SLIME, but for me, this is exactly what I want out of a Clojure development environment, develop some code and be able to easily send it to a REPL. Hopefully a Vim user or two out there will find this setup useful.

UPDATE: If you’re interested in my full Vim setup for some reason, you can check it out here.

TechRepublic IT Security: The Microsoft Internet Driving License

Mon, 15 Mar 2010 17:28:37 +0000

Microsoft’s Craig Mundie is building on his legacy of advocating terrible “security” policy. This time, he has picked up the Internet Driving License bug.

Microsoft executive Craig Mundie has a solid track record for supporting heavily restrictive technologies and technology policies. He has been a vociferous advocate of both the Trusted Computing initiative and DRM, both of which present serious privacy and security issues for individual computer users.

With that track record in mind, it should be no surprise that Mr. Mundie has taken on the mantle of champion of yet another ill-conceived “security” measure that, if implemented worldwide, would have disturbing consequences for individual security and privacy. At the Davos Economic Forum in Switzerland, he called for requirements for individuals to acquire licenses before they can access the Internet. While this sounds like a good idea in theory — if we could ensure everybody who uses the Internet was competent to do so, we really would have a safer Internet — it is not quite so palatable in practice.

As any (real) engineer can tell you, theory and practice are the same in theory, but they are quite different things in practice. When was the last time you saw a licensing system that actually guaranteed competence or, for that matter, at least guaranteed that competent people would not be excluded in favor of the incompetent at least some of the time?

As someone who has been licensed and certified in a number of different areas (including Microsoft certifications, physical security and deadly force management licensing, heavy equipment operation, and even hazardous materials transportation, among others), your humble author can tell you with a fair bit of confidence that it does not take much to corrupt a licensing system to the point that it no longer guarantees anything in particular, other than that a lot of money will be spent, and the more money one has to spend the more likely one is to get licensed.

The problems with Mundie’s suggestions do not stop with licensing itself, however. He also suggested that the United Nations should be granted the power to “organize the systematic quarantine of computers without their owner’s permission.”

Of course, there appears to be little danger of Craig Mundie’s fever dreams becoming a reality. Any effective licensing policy for ensuring that only competent people get to use the Internet would probably effectively bar 80% or more of current users (your humble author’s guesstimate is something more like 98%), and that certainly will not fly. Even ignoring the tremendous outcry of dissent from the populace at large, ISPs will not stand for having the majority of their customers taken away from them.

The alternative (and more likely) licensing scheme would be one that is wholly ineffective, and more prone to ensuring that only people who like the “right” brands and have memorized the “right” corporate-mandated policies will have access to the Internet, aside from those who gain illicit access. It seems unlikely that this sort of mandatory licensing scheme could come to pass as well, though it is at least a vague possibility if the whole world goes nuts next week.

It also seems unlikely that the UN would be granted the power to arbitrarily cut off Internet access for individuals, if only because many of the most powerful nations simply are not strongly inclined to let the UN cut into their economic sovereignty so egregiously. We should keep our fingers crossed, though, just to be sure.

Let’s keep our ears to the ground, listening for the sound of approaching legislation, just in case some technophobes in government might otherwise manage to slip one by us. When dealing with the technologically incompetent in government trying to manage the lives of technical experts in the general populace, there is always the danger that incompetence might win the day.

TechRepublic IT Security: A Special Offer From Our Sponsor

Mon, 15 Mar 2010 17:28:37 +0000

iDogg: Got preliminary approval for PICC Conference

Mon, 15 Mar 2010 14:49:09 +0000

After a bit of discussion, I got approval to go to the PICC Conference in Jersey. I’m looking to jump on the storage and NAS/SAN workshops. I little knowledge of IPv6, so I’m going to jump on that session as well. I haven’t gone to a conference in at least half a decade, so I’m looking forward to this.

I’ll probably be the only person who admins a “Novell” network at the conference.

Standalone Sysadmin: Switch Speed and Price – Tradeoffs

Mon, 15 Mar 2010 14:15:49 +0000

How fast should your switches be?

Sure, the answer is “as fast as you can get”, but we don’t all have the budget for, say, this beast (chassis sold separately). Lots of us don’t have money for even a 48 port Gb managed switch.

So when deciding on a switch to buy, there are a lot of variables to examine.

First, the hard requirement is the number of nodes we have to connect to the network. Then we have niceties such as management (so that we can configure and monitor them, use VLANs, etc etc), whether or not they’re stackable and all that…but where does speed come in?

Obviously, a 100Mb/s switch costs less than an otherwise equivalent Gb/s switch.

The rule of thumb I’ve been operating by is that the end user switch shouldn’t be the bottleneck. In other words, the users in my offices talk to servers over the WAN. I’m never (not soon, anyway) going to get a GbE WAN link between my sites. Because of that, the 100Mb/s switches we’re using don’t hold us back. We don’t share files between the users directly, so anything bigger would be overkill.

If my users used local servers, though, an increase in switch speed would dramatically improve the response of the server. The quality of experience would improve, and it would be worth upgrading the switch.

What kind of mental calculations do you use when picking a switch? I’m interested in learning if there’s a “right” way, and if not, maybe we can aggregate all the ways we make the decision into some smart ideas…comment below!

Slaptijack: Voice over IP (VoIP) Protocol Review

Mon, 15 Mar 2010 14:00:13 +0000

Protocol Basics
Layer:	Application
Transport:	TCP or UDP
Port(s):	5060, 5061
RFC(s):	2543, 3261

SIP (Session Initiation Protocol)

SIP is by far the most popular protocol used in VoIP communication today. SIP was designed as a signaling protocol in charge of setting up and tearing down sessions between two or more devices. Additionally, SIP can be used to modify existing sessions. The protocol was designed to be independent of transport protocols. Thus, SIP can be used over both TCP and UDP. As of this writing, popular open source PBX Asterisk only supports SIP over UDP.

Protocol Basics
Layer:	Application
Transport:	TCP or UDP
Port(s):	1720
RFC(s):

H.323

H.323 isn’t a single protocol as much a system of protocols. It is an ITU recommendation focused on providing multimedia communication in IP networks. On of its strengths over purely audio-based protocols is the ability to provide video conferencing. Other protocols often used in conjunction with H.323 include H.225 for call signaling, H.245 for call control, and Real-time Transport Protocol (RTP) for multimedia communication.

Protocol Basics
Layer:	Application
Transport:	TCP or UDP
Port(s):	200
RFC(s):

MGCP (Media Gateway Control Protocol)

Like SIP, MGCP is a signaling protocol. Unlike SIP, MGCP relies on another protocol, Session Description Protocol (SDP), to handle session creation and termination. MGCP was originally designed to handle scaling issues experienced by large service providers. The original purpose of the protocol was to handle communication between call routing devices and media conversion gateways. For example, MGCP might be used between an Asterisk server and a Cisco AS5350 Universal Access Server connected to the PSTN.

Protocol Basics
Layer:	Application
Transport:	UDP
Port(s):	2427
RFC(s):	3435

SCCP (Skinny Client Control Protocol)

Skinny is a proprietary protocol originally developed by Selsius Systems and now owned and maintained by Cisco Systems. Although proprietary, open source versions of the protocol have been implemented. Although Cisco 7900 series phones use Skinny to communicate with Cisco CallManager, the SMB-targeted Linksys IP phones use SIP.

Protocol Basics
Layer:	Application
Transport:	UDP
Port(s):	4569
RFC(s):	5456

Inter-Asterisk Exchange (IAX / IAX2)

IAX was designed to provide call control functionality between Asterisk PBXs. One of the benefits of IAX is that both control and data traffic are included in the same stream. Therefore, if a connection can be established, audio will pass successfully. This is not true of signaling protocols that rely on other protocols to provide audio traffic. This makes IAX particularly useful in firewalled / NATed environments. Mark Spencer detailed the benefits of IAX versus SIP.

TechRepublic Network Administrator: Network-based storage options for robust home labs

Mon, 15 Mar 2010 13:19:17 +0000

For many IT pros, the ability to have a robust test environment at home is critical for success on the job or to learn a new skill. IT pro Rick Vanover shares his favorite tools to build up a home lab storage.

————————————————————————————-

Last week’s post by Brad Bird hit home with me. Making a home lab is important, but it can really add up! I maintain a private lab at home where I do extensive testing with virtualization for various network and Windows Server technologies. The one technology, above all else, that needs to be in place to make any degree of home lab effective is some form of shared storage.

My lab has a DroboPro device for my network-based storage. Both the DroboPro and DroboElite units can function as an iSCSI target for SMB or home lab situation. Be sure to check Scott Lowe’s review of the DroboElite in this TechRepublic post. I’ve used the DroboPro as a storage target in my lab, and have been generally satisfied with it. The Drobo series of iSCSI storage devices support VMware connectivity, but not fully supporting Hyper-V with clustered shared volumes (CSV) as persistent SCSI-3 reservations are required for Hyper-V virtualization in clusters.

Another popular product is the iomega StorCenter series of products. These offer iSCSI connectivity at a nice entry price as well. Storage expert Stephen Foskett has done a nice independent review of the ix4-200d device on his personal blog site. The StorCenter does have VMware and Hyper-V compatibility, but again does not support persistent SCSI-3 reservations for clustering operations with Hyper-V.

The shared storage wish-list item does not have to be met by purchasing a storage device, however. There are a number of free products that can function as shared storage resources for labs. Here is a breakdown of the one’s I’ve used over the years:

StarWind Free: This free software engine can virtualize the storage on a local server, and present it as an iSCSI target. You can purchase software to increase the feature set, including mirroring and failover. StarWind does support Hyper-V clustering with persistent SCSI-3 reservations with their iSCSI target implementation.

Openfiler: This free software-based storage virtualization engine is multi-protocol, including iSCSI and NFS. Should also have a fibre channel or CIFS itch to scratch, this free product can help here as well.

NexentaStor: This software-based storage virtualization engine also can do many different protocols, including iSCSI and NFS. Further, there is a VMware-based image as a storage device to plug into your existing test installation.

FalconStor Network Storage Server: This software-based storage virtual appliance has a free offering for the small business or remote office.

When it comes to deciding between a dedicated, purpose-built storage device like the Drobo or StorCenter devices or software-based devices like StarWind or Openfiler; there are a number of considerations one must take into account. First of all, both products should be given their own network. Running a storage protocol over a network that may approach line rate with normal traffic will be less than optimal. Performance wise, you may have better disk access from the software-based solutions that utilize potentially higher-performing array controllers.

One last recommendation is to create two classes of logical unit numbers (LUNs). One class would be for static data that will never be erased. The second class would be true lab use LUNs. The best way to distinguish between them is to do both LUN masking at the storage controller (if possible) and in my case, I make them a special size. For example, I know that the 2 TB LUN is the permanent LUN with all of my CD-ROM .ISO files and permanent virtual machines. Therefore, any 1 TB LUN is a lab-use LUN that I can break down and re-use as needed.

Above all else, dedicated storage allows the lab to reset and be rebuilt. Whether or not virtualization is in play, it is important to have a storage environment that is relatively removed from the constant tear-down and rebuild of the lab systems.

How do you provision storage in your lab? Do you use a network-based storage protocol? If so, which product?

Everything Sysadmin: Motivation for sysadmins to write documentation

Mon, 15 Mar 2010 12:03:23 +0000

My new O'Reilly blogpost about getting the motivation to write docs.

TechRepublic Network Administrator: Product Spotlight: Desktop Authority Password Self-Service

Mon, 15 Mar 2010 12:00:36 +0000

Derek Schauland introduces the Desktop Authority Password Self-Service app from ScriptLogic that allows users to reset their own passwords.

—————————————————————————————

Keeping track of passwords is increasingly difficult, with PIN numbers, bank passwords, Web site logons, Windows passwords, and more; it’s an ever-increasing list to manage. It’s also no wonder that the password reset feature gets used so often.

In business, the Windows logon password is the key to many employees’ work lives. Occasionally, they are going to forget their password or enter it incorrectly too many times, which may lock them out for a period of time. This is where Desktop Authority Password Self-Service (DAPSS) by ScriptLogic comes in, helping out users and help desk staff in a pinch.

Specifications

DAPSS requires SQL 2000 or 2005 for data storage and reporting and Internet Information Server on the server end.

Supported operating systems:

Windows 2000
Windows XP
Windows Vista
Windows 7
Windows Server 2003 SP1 or higher

Who’s it for?

DAPSS is great for organizations of all sizes where resources are stretched thin or at a premium because of other challenges. The product also licenses for about US$7 per user, less if you are already a Desktop Authority customer, which makes the application very affordable for organizations of any size.

What problem does it solve?

The application puts password control in the hands of the users. Allowing a user to change an expired or forgotten password or unlock a user account by answering some challenge questions eliminates the need for the user to call the help desk. It also makes the password accessible 24 hours per day. This improves the convenience for the users as well.

Standout features

DAPSS is very easy to configure. The user information is imported from Active Directory to speed setup and avoid record duplication. The tool also comes with a help desk component which allows users to get help if they have not yet registered with the service or need help getting the hang of it. Because the help desk does not need to access the user account directly to reset the password or unlock the account, the users needing help will get it much faster.

The user experience within the application is very simple. You can search for a user’s account by certain characteristics from the user name to partial first or last name. Challenge questions are configured during the initial setup and used to aid with the account actions going forward.

DAPSS includes a free trial to allow you to test it in your environment with a pilot group or to get it configured and ensure it works as needed before paying for a license.

Figure A

Click to enlarge.

The user experience for registered users of Password Self-Service

Figure B

Click to enlarge.

The Admin console

What’s wrong?

Changing the password policies at any organization can be a challenge for IT, but will be a benefit for the users in the long run. It will take some time to change the habit of your users to manage their own passwords rather than calling the help desk.

Because users are allowed to manage their own passwords through a Web interface, some vulnerability is introduced. Social engineering scammers (or just employees who already know a lot about each other) could guess the answers to challenge questions for their fellow users, leaving the door open to unauthorized use of accounts.

The application can set the questions to be configured by the user, and the answers to these questions are specific to the user, but employees should be cautioned to create questions that are “secret” or at least, would be very hard to guess. In production, it would make sense to refresh the challenge questions every year or so, just to keep things more secure.

Competitive products

Bottom line for business

If your help desk staff is overwhelmed by projects or day to day operations, allowing users to maintain their own passwords can be a huge time saver for everyone. Allowing password resets and account unlocking to be handled completely by the user can also removes frustration on the part of the employee because the employee does not need to contact the help desk and wait until they have time to assist.

Anton Chuvakin - Security Warrior: RSA 2010 – Day 1 Metricon

noreply@blogger.com (Dr Anton Chuvakin) — Mon, 15 Mar 2010 10:39:37 +0000

Let me start my [much delayed] coverage of RSA 2010 conference with the awesomeness of Metricon 4.5 (technically, a Mini-Metricon 4.5 :-)) where I spent my first RSA day (sacrificing the Cloud Security Alliance meeting that was reported to be packed).

Here is an agenda for the meeting with my comments:

08:45 - 10:05: Morning Session I - Chair: Jeremy Epstein

Qualitative Tuning as Preparation for Quantitative Methods, Pete Lindstrom

This was one of the most fun presentations, focusing on expert opinion vs. fact/metric in security. Pete showed an interesting approach for assessing the opinions in order to come up with something that looks more like fact.

Metrics for insights on the state of application security, Ashish Larivee

This was an interesting presentation of Veracode research of binary analysis (paper, some highlights). A few thing actually blew me away first, but, upon further consideration, started to look perfectly logical. For example, software industry is worse at developing secure software than financial service industry. It can be explained that FS folks develop only mission-critical software though. Still, this seems to prove that in some areas “if you want it done well, do it yourself and do NOT trust the professionals to do it” :-) In fact, commercial software overall fared worse [vulnerability-wise] than internally developed AND outsourced software. It also had longest remediation cycle, while open source had the shortest (for methodology details see their full report)

10:20 - 11:40: Morning Session II - Chair: Joe Magee

Translating the Narrative into Metrics: The Verizon Incident Sharing Framework,Alex Hutton and Wade Baker

Verizon VerIS was released via this presentation (release, exec summary, document [PDF]). VerIS “translates the incident narrative (the attacker did this, then that, then the other thing) into a data set” and thus allows the creation of such awesomeness as DBIR.

Ontologies for Modeling Enterprise Level Security Metrics, Anoop Singhal

This presentation was a bit of a cruel joke. It carried unfortunate signs of being done by somebody who never ventured in the real world of security (for example, single number “asset value”, “risk = damageValue”, “security measures that reduce the frequency of attacks”, etc, etc, etc). And, what was even more embarrassing, it came after the stellar presentation by the Verizon team; I think I have seen the grimaces on their faces :-) And every time the NIST speaker mentioned “this was done on tax payer dime” or uttered the word “ontology”, I wanted to just reach for a ShmooBall. To make his material even more insulting, he was also a bad presenter. Yuck!

13:10 - 14:40: Afternoon Session I - Chair: Caroline Wong

Improving CVSS-based vulnerability prioritization with business context information, Christian Fruhwirth

This was a curious little preso that basically can be summarized in one phrase “using CVSS as it was intended by the original team – with Env scores – is valuable.” Even though there was one “cringe moment” when the speaker expected a normal distribution of vulnerability CVSS scores (pray tell me, why medium severity are more likely than low severity?)

Security Metrics Field Research, Ramon Krikken

This presentation by a Burton …eh... Gartner… analyst Ramon Krikken was hugely insightful. They did some metrics research among their clients and came up with some surprising conclusion that shows metrics programs largely in the Stone Age (in fact, what was before the Stone Age? Ah, yes, Sharpened Stick Age! The maybe the metrics are in that age…). Here are some of the themes, but get the presentation materials when they are posted – very worthwhile. As expected, “compliance metrics are easy; security metrics are hard”, “assessments and audits matter”, “need to map to ” and “ONLY prevention of ‘business being stopped’ matters at many companies.” The research showed no focus on improvements, no peer benchmarking, etc. Regarding tools, MS Excel was by far the #1, couple of times RSA/Archer and SIEM.

15:10 - 16:30: Afternoon Session II - Chair: Ray Kaplan

Metrics for Cloud Security, Lynn Terwoerds, Caroline Wong, Betsy Nichols

This panel announced that CSA is starting a cloud security metrics effort, which was in a VERY early stage. No material has been created yet.

Identifying critical information security areas with a Threat Agent Risk Assessment, Matthew Rosenquist

I read the TARA paper back when it came out, but this presentation (and the discussion) was still VERY interesting. The main idea is that vulnerability or asset focused approach makes no sense since there are way too many vulnerabilities (presenter example was “data center is vulnerable to a meteor strike”) and thus the way to go is to focus on threat agents that are motivated to cause damage and that can realistically to do so. The logic thus becomes: threat agent –> vulnerability –> control –> what remains is the risk that needs to be dealt with somehow. But read the paper instead of this, Intel folks explain it much better :-)

So, as I said, Metricon was the most thought-provoking part of RSA for me! And I am not even mentioning the level of hallway discussions there…

A Year in the Life of a BSD Guru: FreeBSD Lectures Captioning Project Complete

Mon, 15 Mar 2010 08:45:38 +0000

Murray Stokely has completed his captioning project and provides the following update:

Chris Siebenmann: How to create pointless error reports (and how not to)

Mon, 15 Mar 2010 05:46:12 +0000

How to create pointless error reports (and how not to)

Linux's little love notes about software RAID consistency errors makes a perfect example of something that system administrators run into all the time: pointless error reports.

It's worth noting that a pointless error report is something different from a useless error report. A useless error report tells you that something has gone wrong but doesn't identify what it is, what exactly has gone wrong, and so on; you have to hunt that down on your own. A pointless error report shouldn't even have been generated in the first place, at least not in the form that you get it in. Noise from monitoring systems is one form of pointless error reports.

So what makes a pointless error report? The aforementioned software RAID errors have at least three things wrong with them, namely that the error happens all the time, that the 'error' is actually (in theory) something that happens routinely, and that there's nothing you can do about the error in practice. Complaining about non-errors that happen all the time that you can't do anything about anyways is pretty much the jackpot in terms of pointless error reports.

We can turn this around to create a list of what makes a good error report for sysadmins:

it is complaining about a real error (not a routine and theoretically harmless event)
... that does not happen all the time
... that is actively dangerous
... that you can (and should) do something about
it contains a clear description of what is wrong
it contains all of the details about the situation that are known, provided that those details are useful for resolving the problem (and not merely useful for debugging the code)

Things that fail some of these criteria may be useful to log and capture for historical purposes, but they do not rise to the level of useful error reports. Failing any of the first four points makes an error report pointless; failing the last two makes it more or less useless.

I include 'is actively dangerous' on the list of important points because there are always things happening on any system that might be worthy of note, for example people trying brute force attacks on your ssh port. What should create error reports is not merely something wrong, but something that is bad enought that it needs to be dealt with. Someone failing to get in to your system with ssh is not worthy of a report; someone ssh'ing in to root and getting the password right but being refused access because you have PermitRootLogin set to no in the sshd configuration, now that is worthy of an error report.

League of Professional System Administrators: LOPSA Sponsoring LinuxFest Northwest

Sun, 14 Mar 2010 18:52:35 +0000

Start: 2010-04-24 10:00

End: 2010-04-25 17:00

Timezone: US/Pacific

Lopsa is proud to be a sponsor and have a booth at the 10th annual LinuxFest Northwest conference this year. There are great talks including sessions by LOPSA members Ski Kacoroski and Leon Towns-von Stauber.

Everything Sysadmin: How to "un-send" email.

Sun, 14 Mar 2010 16:37:40 +0000

It is a fact of modern life that you can't unsend email. The problem is that to really unsend email you need a time travel device.

It's a shame, really.

MS-Exchange has the ability to send a request that will hide the email, but most non-Exchange providers don't support the protocol. Besides, the horse has left the barn. You can't put the toothpaste back in the tube.

Gmail has the ability to unsend an email if you sent it in the last 10 seconds. Useful and cute, but not awesome. (Awesomer is their "prove you are sober before sending a message" feature.)

One way to mitigate this risk of wishing you had an "undo" is to send out a first paragraph plus a URL to the entire message. This way you can rewrite, refine, and update the body of the email as much as you want.

We use this technique at work. Suppose we want to tell people that the printing system will be down on Thursday evening so that we can upgrade the print server software. We put the basic message in a 1-paragraph email, and list a link to a document with more info. The link might be to a ticket # that tracks the issue, or a blog post (yes, we have internal blogs), a web page, or a document. We can constantly update the document over time.

Maybe we should extend this. All email should be a subject line plus a URL to the actual message. Made a typo? Correct it. Regretted what you said? Delete it. Called your boss an asshole? Change it to be a loverletter.

You still need to get the subject right, but the message can change. Maybe we could invent a way for the email to be "frozen" once the person reads it (one way would be for the email client to cache the message once it is downloaded). Spammers would have a harder time spamming us, since we'd be able to track their message back to their web site and therefore identifying them would be, well, if not easier, differently harder.

Or maybe we shouldn't even send email. The user interface would still look the same. Behind the scenes it would just be sending URLs.

Usenet made this transition. Usenet was replaced by RSS feeds, which are just lists of URLs. Maybe email should make the same change.

TaoSecurity: Verizon Incident Sharing Framework

noreply@blogger.com (Richard Bejtlich) — Sun, 14 Mar 2010 16:16:20 +0000

Earlier this month Verizon Business announced their Verizon Incident Sharing Framework (VerIS framework). This document is a means to describe digital security incidents, using four main groupings: 1. Demographics, 2. Incident Classification, 3. Discovery and Mitigation, and 4. Impact Classification.

The idea is to provide a framework that incident investigators can complete for every digital security incident. Using the output, security teams can better identify trends and make recommend improved security strategies and tactics. For example, Verizon builds their Data Breach Investigation Report using data from their incident responses as formatted using the VerIS framework.

Verizon asked me to participate on a "board" affiliated with this project, so you can expect to hear more from me. Verizon started a Zoho Forum to discuss the framework, but I think a Wiki would better facilitate collaboration and development of the document. At work we are working on our next generation incident management system, so I think the VerIS framework might help us identify information to collect on incidents.

Standalone Sysadmin: Blog Upgraded and Fixed

Sun, 14 Mar 2010 15:00:30 +0000

Hi All,

I spent some time last night upgrading the blog to the latest versions of Wordpress and plugins. I also added a mobile version of the site, so handheld device users can actuallly use the site now without zooming in.

Also, with the help of Greg over at Reject Reality, I got WP SuperCache working. This will hopefully let the blog take more and more traffic as time goes on, and delay me ordering a new virtual host (I go with the guys at prgmr.com).

Anyway, the point of this post is to ask you to let me know if you notice anything strange. Drop me an email if you see anything weird, or if the mobile site shows up but shouldn’t, or any of that. This is my blog, and I write in it, but you all are the ones who are good enough to read my stuff. The least I could do is make it easily accessible to you.

Thanks for your patience, and thanks for reading!

PS – I’ve added a Google Translate widget to the far right bar. This is the first step in what I hope will be many that enable this blog to be read by non-english speaking people from around the world. Please let me know if you have any questions or problems with it.

RISKS Digest: Silly season: DST is approaching