Wandering Thoughts archives

What contracts aren't

One persistent general belief, probably most common among a subset of the people who insist on going commercial for products (instead of open source), is that your problems are over once you have a contract for something with some appropriate entity.

This is false. Contracts and agreements and so on do not insure actual performance, especially performance to your satisfaction; all that they actually do is enable you, in theory, to recover some amount of money some distance in the future. In practice this 'remedy' is so counter-productive to your actual goals that it is almost never invoked.

(After all, your actual goals are the performance, not your money. Often you need the performance badly, so it is better to spend some more money now and get results instead of doing without entirely and getting money back later.)

Contracts do improve the chance of performance, but a large part of this improvement is that many organizations definitely won't perform if you don't have a contract. Of course, this is not true of the open source world, which makes me wonder if this is one of the quiet cultural issues between (big) business and open source.

(Also, getting a contract means that it is generally not your fault if things go wrong anyways, which is very important for many organizations and people.)

Users are rational

Here is something important to remember about your users:

Users are rational.

Users aren't crazy, and they don't do things just to irritate you; what they do and what they report about problems is not crazy from their perspective, however odd it looks from yours. If users report 'I cannot log into the intranet' when they cannot log in to the IMAP server, it is not because they are stupid, it is because 'the intranet' is how they think about your system.

(The answer to 'how can they be so ignorant?' is that they don't care to learn the details, any more than most people care to learn the details about how their phone service, their plumbing, or their car work. Everyone has massive areas of ignorance in their life; it's how we deal with a very complicated world.)

I think that it is especially easy for system administrators to fall into this mindset, because we see our systems so clearly that we can easily miss how other people don't and how complicated things are from an outside perspective and so on. (Plus, there is a cultural tradition of sysadmins thinking of their users as stupid, however ill advised this is, with all sorts of supporting cultural institutions and mythology.)

One of the corollaries of this is that how users refer to things gives you valuable clues about their mental model of your systems. This is not just useful for understanding problem reports and requests; it's very important for building systems that behave predictably and do what the users want, and making sure that the users have an accurate mental model of what is going on is vital in avoiding terrible mistakes.

(This is closely related to how users are almost always right.)

What protects the strength of a ssh connection's encryption

Here is a suddenly burning question: what protects the strength of a ssh connection's encryption?

The answer is that the connection encryption is protected only by the strength of the random numbers chosen for the initial Diffie-Hellman key exchange that arranges the session key. This protection depends on both the server and the client using strong random numbers; if an attacker can guess the random number for either side, they can immediately recover the session key simply by acting out that side of the exchange.

The server's host key doesn't get involved in the actual Diffie-Hellman key exchange; it is merely used to sign a shared secret in order to verify that the server is who it says it is. This means that a weak server key doesn't weaken the connection encryption (although it enables man in the middle attacks), but also that a strong server key is no protection if either side is using weak random numbers.

(This comes from RFC 4253, section 8.)

The answer to the next burning question is that OpenSSH gets its random numbers (at least for Diffie-Hellman) from the OpenSSL libraries.

Some thoughts on tradeoffs between storage models

To stereotype, there are two models of operating your storage: long term storage, where you evolve your storage over time without the users noticing, and run it into the ground storage, where you just buy the best thing of the moment and replace it when it's too outdated. So, what are the tradeoffs between the storage models, or in other words when should you pick one or the other?

My thoughts so far on this is that there are a number of issues:

• what sort of downtimes can you afford when you upgrade your storage? The run it into the ground model generally requires that you can live with user-visible changes and potentially significant downtime to move data from one storage technology to another.

• what sort of expansion do you need; particularly, do you need to expanding existing things, or can you get away with adding new things?

  The run it into the ground model is often not so great at expanding existing storage; once you max out a unit, that's generally it. The long term model generally has more ability to expand existing storage on existing servers.

  (Better tools for transparent data migration would help a lot here.)

• how much work it is to add a new server to your environment, because significant expansion in a run it into the ground model means adding more servers even if you don't migrate existing data.

My feeling is that long term storage trades off extra expense for less user pain in the future; however, a lot depends on how your data is organized and how it expands. (To put it one way, do people's home directories grow endlessly, or do they start working with bigger and bigger datasets over time? I suspect that most environments have a mix of both.)