The conference will take place between 3-5 September 2013 in Athens, Greece. The venue and program will be announced soon. Most developers of the Ganeti and Synnefo team will be attending.

The first GanetiCon will be a developer oriented conference. Sessions will be a mix of design talks and discussions about new features and future plans. It will also probably feature an advanced Ganeti workshop, depending on user demand.

The conference is geared towards people interested in:

• learning how other companies/institutions use Ganeti
• checking out how large scale Ganeti deployments look like
• glimpsing the product roadmap of Ganeti
• contributing to future design of Ganeti
• obtaining help with specific Ganeti issues

The organizers do not yet have a website. To be kept informed of information as it is available please fill out this form.

I wish them the best of luck!  It sounds like a great conference!

Previously I hadn't found todo list software for Android that worked well for me, and I had tried many. I'd been doing all my time management on my iPhone because TodoPro worked so well for me. I'm very excited that an Android release is now available.

I don't endorse products but I do let people know what I personally use. I think todo list software is very personal... the definition of "best" is "what works for you". So, try it and see if it works for you.

Visit the TodoPro for Android on Google Play Store.

TodoPro offers a sync service. When you have syncing set up you can access the same data from all your devices as well the web-based interface.

Full details are available on the company's website.

Thieves Stole $45 Million From ATMs Because The U.S. Uses Absurd 40-Year-Old Technology

Let me quote:

So why is the US so far behind? Infrastructure is a major factor; countries like Japan and the UK are much smaller, so replacing all the old point-of-sale machines and ATMs is easier.

Bullshit.

Bullshit. Bullshit. Bullshit.

The reason is that bank executives had the choice between paying a lot of money to do the right thing or a little money to consultants who would tell them what they wanted to hear. It's a big win for consultants.

WHY IS POPULAR SCIENCE BEING SO ANTI-CONSULTANT???

Everyone got what they asked for. What's so bad about that?

And besides, I'm sure the banks are insured for this kind of thing.

The real headline should be, "Insurance companies lose $45 million from signing contracts with banks that couldn't care less because they've signing contracts with insurance companies that remove the need for them to give a shit."

Amirite? (No, really, can someone from the banking industry confirm?)

I haven't used or configured a WAN Accelerator but from the reading I've done so far it seems that the older the protocol is, the better a W.A. will help. Older protocols were designed when we were ignorant of the networking realities we have today. More modern protocols tend to do their own compression, caching, don't do stupid things that fail over high latency links, and so on. In particular: Am I right but if you mostly have home-grown protocols, you can tune them better than a W.A. can accelerate them?

Please post to the comments section.

How can one interview question help me understand what the candiate does and doesn't know Unix?

Here's the question:

What happens with I type this at a shell prompt:

telnet www.wikipedia.org 80 RETURN

Usually the candiate will explain just the command: "It opens a connection to port 80 on wikipedia". That's a good answer.

The follow-up question is, "Please give me more detail".

At this point they might explain how DNS works or how TCP network connections work. Whichever they explain, you can ask about the other one.

That is, of course, skipping the fact that the command was started: You can ask them to explain how a process is created in Unix. You can ask them to explain how command lines are parsed.

Basically you can drill down and down and down and down. Any time the candiate says, "I don't know" ask them to guess. After the guess, move to some other aspect of the system.

You can do this in 15 minutes or 15 hours depending on how detailed you ask the candidate to get.

The point is that you will learn a lot about what the candidate does and doesn't know. Don't get hung up if they don't know half the issues you bring up, just make sure the parts that are known are the parts the job opening requires knowledge. Watch the "guesses" to see if they are logical or do they require what I will politely call "magical thinking". Not knowing how DNS works is forgivable for some positions. Thinking that TCP works with hostnames instead of IP addresses is not forgivable. Thinking that "the computer just knows" is a magical thinking and is not forgivable.

I call this "Zeno's Interview Question" because you never get to the end. There is always more to discuss if you break the situation down into smaller and smaller parts to be described. Generally the conversation doesn't go linearly. You often ask "what happens before that?" When all is said and done you probably have traversed the timeline back and forth and back and forth; moving up and down layers of abstractions again and again.

You can use different command lines depending on if the position is for a sysadmin or software developer. The above example is good for a sysadmin because it involves DNS and networking. A systems programmer might be asked "cat *" instead, especially if you want to introduce that there is a file called "-f" in the current directory. You'll learn a lot about whether or not the candidate understands how command line parsing works.

Here is a list of topics this can generate:

• How USB keyboards transmit keystrokes.
• How keystrokes get processed through the kernel.
• How the unix concept of pty "raw vs. cooked" mode.
• How the shell parses lines (quotes then variables then {} then globs).
• How the shell executes commands: aliases then relative path or search $PATH.
• How commands are executed: all about fork() and exec()
• How a process starts: the Unix disk I/O system, virtual memory, paging executables into memory, bss vs data. Jumping to the first instruction.
• How argv is passed to the process.
• How a process parses flags.
• How DNS lookups work (in the simple case)
• How DNS lookups work (in the recursive case)
• To send the DNS packet we need to discuss:
• How L3 routing works
• How L2 packet passing works (Ethernet Switching, "cam" tables)
• VLANs
• Finally we have an IP address. Now we discuss...
• How a TCP connection is created.
• How sequence numbers work.
• How a TCP connection sends data.
• Nagle's Algorithm
• My fingers are getting tired.

(Note: the above list is incomplete, by definition. It probably also includes a few errors.)

We discussed this at the monthly meeting of the New Jersey Chapter of LOPSA a few years ago. It was 60 minutes before we got to the point that a packet hit the network. At the 2-hour mark we stopped the meeting because, to be honest, we were all pretty exhausted.

If you use this as an interview question I highly recommend you first tell the candidate how much time you've allocated for this question. If they know you want this to last 20 minutes, for example, it helps them give an indication of how much detail is being expected.

The best part of this question is that there's no way to "cheat". If the candidate has heard this question before it doesn't help them. The only way to "cheat" is to read all the books and other resources required to learn all of this. That's called education.

Today is the International Day Against DRM.

As an author, and one that is currently living on unemployment insurance payments, DRM-free scares the shit out of me. Every book I've ever published has been pirated. Some I have even found in the "/tmp" directory of open HTTP servers. Every time I see my books pirated I die a little inside.

Writing is very difficult for me. People don't realize how hard it is. How do I stop procrastinating and sit down to write? I eliminate everything else "tempting" from my life for a year or two until the book is done. Do you know what's more tempting to do than writing? Everything. This basically means anything fun... eliminated. It kills my nights and weekends. It kills my social life. I say "no" to every invitation, movie night, gaming night, etc. When the book is done I always hold a big party to celebrate but also to re-introduce myself to my friends and loved ones that I've haven't seen in so long.

While DRM-free media scares me, I know it is important to be able to store media on all your devices, move it around and so on.

Producing DRM-free media is about trust. It is the author showing trust in the readers that they will do the right thing when it comes to paying for what they use (if there is a charge) and trust that people will abide by whatever copyrights the creator has placed on the work. It is the customer showing trust in the producer that they set reasonable prices.

I want to live in a world with that kind of trust. Publishing books without DRM is, to me, an experiment in seeing if that is the kind of world we can create.

That's why I support the "Day without DRM".

Sign the petition.

O'Reilly demonstrates this trust. It publishes Time Management for System Administrators at a reasonable price. You can download it in many formats, as many times as you wish. You can read it in HTML on Safari Online.

This is a critical moment in the fight against DRM. A proposal currently being considered by the W3C would weave DRM into HTML5 -- in other words, into the very fabric of the Web. This would be bad. If there is DRM on the web, let it remain as proprietary plug-ins, not a requirement of owning a web browser.

Sign the petition.

I'm against including any DRM in HTML5. I hope you are too.

To celebrate "Day Against DRM" you can purchase "Time Management for System Administrators" and 5000+ other O'Reilly eBooks for half price. Use discount code: DRM2013. Deal expires May 3, 2013 at 11:59pm PT.

Sign the petition.

But there's one thing they all agree on: Mentioning Google Glass in a headline gets you readers.

You're reading this. Right? I bet a whole lot of you don't always read my blog but you are reading this post, right?

Writing about the success or failure of Google Glass is fantastic for many reasons:

• It's low cost. You don't have to spend $1,500 on one. Just read other people's blogs and repeat what they've said, speculate, or just make shit up!
• You are automatically correct. The product hasn't been released yet. Nothing you say can be "wrong" right now. Say that the actual sale price will be $10 million dollars or ten cents. You win! They, that's a good idea, actually. Someone should write a blog post saying they heard the final price will be ten cents! It isn't a lie, because you read it here. Just think of how famous you'll be for writing such an article!
• When you are proven wrong, nobody will care. When Google Glass actually ships nobody is going to go back through all the articles written now and see who was wrong and who was right. If someone were to do this, those that were wrong aren't going to be fired or anything. It works this way outside of the tech world too! Heck, every person I saw on the Sunday morning political pundit shows last weekend has been proven wrong on whether Iraq had weapons of mass destruction, or wrong on the housing bubble, or wrong on TONS of things. Yet instead of banning them from ever speaking on economics, politics or foreign policy people like David Gregory just keep inviting them back! The tech world is even worse. Search around and see who predicted (in some cases vehemently!) that any of these products would fail: iPod, iPad, Android, Linux, the mouse, graphical user interfaces. Now take that list of authors and see which of them are still fully employed. All of them! Heck, I still remember John C. Dvorak mocking the Amiga for having multitasking... a feature he claimed nobody would want and nobody could use because "computers only have one keyboard". People still hire him! (I'm sure he never runs two programs at the same time because, he's like... consistent.)
• Everyone else is doing it! Look! Now even I'm doing it! And yes, Mom, if everyone else jumped off a bridge I would too. The bridges in our neighborhood are all pretty darn low.

So take my advice: Mock it or praise it, parody it or deify it, make shit up or do actual research. Whatever you do, just write about Google Glass.

I know I plan on doing it.

P.S. Can I borrow someone's Glass? Please? I haven't tried it yet.

Software Carpentry is running a 2-day software skills boot camp in Boston, June 24-25th 2013, for women in science, engineering, medicine, and related research areas. Registration is $20.

Boot camps alternate short tutorials with hands-on practical exercises. You are taught tools and concepts you can use immediately to increase your productivity and improve confidence in your results. Topics covered include the Unix shell, version control, basic Python programming, testing, and debugging -- the core skills needed to write, test and manage research software.

This boot camp is open to women at all stages of their research careers, from graduate students, post-docs, and faculty to staff scientists at hospitals and in the public, private, and non-profit sectors.

Registration is $20; to sign up, or find out more, please visit the announcement at http://software-carpentry.org/blog/2013/04/announcing-wise-bootcamp.html. If you have questions, there is an e-mail link on the announcement page.

At "candidate night" here are the questions I'll be asking:

Question 1:

"I'd like to know about your experience with community-based projects. Please tell us about a project that you took responsibility for seeing through to completion. Please, only projects that are "done" or have reached a self-sustaining mode only. One or two sentences is fine. It doesn't have to be a project where you thought of the idea or even did all the work: just one where you assured it reached the finish line."

Question 2:

"Surprise! The day after the LOPSA election an anonymous donor gives LOPSA $10 million dollars. The only condition is that it has to be spent in the next 18 months. What should LOPSA do with it? (projects, not investment strategies)"

If candidates wish to include their answers to these questions in their candidate statements it would please me to no end.

I've finally finished my slides for my "Evil Genius 101" class. I'm very excited about this new class. I hear there are still seats left, but it is filling up fast.

To my NYC friends: you can take the train there. The station is 2 blocks away.

To my Linux friends: the Linux content is most excellent this year.

To my Windows friends: Steven Murawski himself is teaching PowerShell classes. Steven FREAKING Murawski! How can you NOT sign up for this?

To my security friends: The keynote is Marcus Ranum. The guy that wrote the first firewall software and, since then, has gone on to do all sorts of amazing stuff like Network Flight Recorder. You should also come to see his keynote because OMG ITS MARCUS RANUM WHY ELSE DO YOU NEED A REASON?

There's still time to register. You can also register "at the door" either Friday morning, afternoon, or Saturday night.

Don't forget:

Thursday evening: It isn't official but people hang out at the bar. It's fun and you will be recruited to help stuff the conference bags.

Friday evening: If you are only registered for Saturday you can still come to the Friday evening stuff. it starts at 5pm and includes the dinner, keynote and the other sessions that night.

http://lopsa-east.org/2013/registration/

What’s your opinion on merging “to-do” lists with issue trackers in The Cycle? I have a pile of To Do items which aren’t properly “issues”, and a pile of issues. I don’t want to duplicate tickets in the to-do list, but I’d like to look at one place to figure out what to work on next.

You are correct in that copying items from your ticket system to your to-do list leads to trouble. They aren’t synced and bad things happen. I have a n-hour to-do item each day called “work on tickets” (where “n” is 1 to 8 hours depending on the requirements of my job). During that time I focus on tickets, using the ticket system’s ability to sort and prioritize the requests. Some tickets require follow-up that is appropriate to track using your to-do list. For example if work related to the ticket involves calling someone on a certain date, putting that on the to-do list for that date assures perfect follow-through.

(Search for a copy of the letter online here)

Many people read it without realizing the joke he put in the first paragraph.

Seldom do I pause to answer criticism of my work and ideas. If I sought to answer all the criticisms that cross my desk, my secretaries would have little time for anything other than such correspondence in the course of the day, and I would have no time for constructive work.

The joke, in case you missed it, is that he doesn't have a big office full of secretaries that manage his correspondence. Like most social activists he's on a shoe-string budget. The people he is replying to, however, probably do have such luxuries.

I often wonder if his intention was to open the letter with a subtle joke or the most polite "F- you" ever delivered in history.

Nearly a year later when he spoke at Drew University (I wasn't born yet, but I would attend that University 20+ years later) his speech also began with a joke. He quoted the great philosopher Bob Hope. I don't want to spoil the joke for you, so you'll have to listen it it yourself here: http://depts.drew.edu/lib/archives/online_exhibits/King/index.html

For those of you that are unfamiliar with Puppet: Puppet is a system for describing what the configuration of a machine should be and then the "puppet agent" will update a machine to have that configuration. If there is no work to be done, the agent does nothing. If you need to make a change globally you could, in theory, make one change to the description and soon every machine will be updated with the Puppet agent doing the right thing on each machine depending on what operating system it is running. This is called "Configuration Management" or ConfigMgmt or CM. Settings can be global or for a particular machine or anything in between. The hallmark of good CM systems is that you specify what you want ("Package foo version x.y.z should be installed") not how ("apt-get install foo-x.y.z"). CM systems are good for maintaining dozens or thousands of machines.

About the book:

Imagine you need to learn Puppet quickly and you have a friend that is a Puppet expert. Imagine that he or she has offered to sit down with you for a few hours and help you go from zero to a running configuration. This ebook is like having that experience in the form of a book. It starts with the fastest way to create a server, a client, and get them talking to each other. Now you use the system to move through a series of exercises that teach you all the rudimentary features that you should know: Installing packages, copying files, using templates to generate files, and so on.

To make the book so compact Jo employs a number of techniques. First, he assumes RedHat or CentOS. This makes the descriptions more concise and uncluttered by the distracting exceptions for other operating systems. If you don't use either of these OSs he has advice on how to apply what you've learned to a different operating system after you are done. Second he focuses on the knowledge needed to take you on the shortest path from no Puppet to a simple Puppet server with a few clients with some typical configurations. Third, he uses thoughtful examples that replace the need for pages and pages of verbiage. Lastly, he saves pages (and your time) by covering advanced topics with an overview, an example, and a pointer to where to learn more. The last section is a "Top 5" list of advanced features that you should be aware of. After reading the overviews and examples of each, you feel like you are conversant enough in the topic to know if you need this feature.

Earlier I said this is like having an expert walk you through the process in person. It is actually better than that. I can't imagine an informal in-person walk-through having such good planning. I mean... when I walk a person through something I always get to a point where I realize I need to backtrack a little! The ebook, however, is excellently planned. Each concept flows from one to the next linearly. Technical books often build a concept hierarchy that becomes a "house of cards": if you forget or don't understand one concept the entire house comes tumbling down. Instant Puppet 3 simplifies the concepts and avoids obfuscation resulting in an approachable learning experience.

As a result, the analogies are well-crafted and the examples are clear.

One particularly good analogy stood out. It can be confusing for a beginner to decide if a new policy should be put in the "site manifest" or in a "module". He writes:

The site manifest expresses what you want. The modules are like butlers and maids; components which implement policy without bothering you with the details. You will find that this approach enables you to do more, faster, and easier than ever before.

That analogy helped me understand the issue better and I've been using Puppet for a while!

As I said before, the examples are also well-crafted. They demonstrate what is needed at this point in the narrative rather than trying to show off every possible feature. (This is a major pet peeve of mine: authors that use examples to show how complex and configurable a system can be and end up confusing the reader with unrealistic examples. To be clear: this book doesn't have that problem.)

The book is not without faults. I found some editing errors but over-all it was well-edited. The author has already updated the errata page on the book's website.

I would recommend this book to anyone that needs to get up to speed quickly with Puppet. If you are managing more than 2 machines, you should be using a CM system: whether it is CfEngine, Puppet, Chef, Bcfg2 or anything else. If you choose Puppet, this is a great way to get started.

The book is compact and straight to the point. The ebook is available for $9.99 from the publisher: http://www.packtpub.com/puppet-3-starter/book

Tom

P.S. You can enter to win a free copy at the author's website: http://www.netconsonance.com/2013/04/win-a-free-copy-of-instant-puppet-3-starter-packt-publishing/

LOPSA-East (May 3-4, 2013) is the best regional conference for sysadmins this side of the Mississippi. It is much less expensive than national conferences because you can probably drive instead of fly. The same nationally known speakers you find at the big conferences travel to us instead of the other way around.

If you are signing up for my tutorials please remember that space is limited so please register soon!

I was thinking about why I like going to conferences the other day and it dawned on me that the answer is simple: I can ask the questions I can’t ask anywhere else. There are plenty of places I can ask questions: online forums, ServerFault, bulletin boards, mailing lists, and so on. However there are many questions that I can not ask online. First, online forums and chatrooms are archived and sometimes I don’t want my question public. The second reason I’d call “discovery”. I don’t always know which online forum is the most appropriate. At a conference you can strike up a conversation and learn about new resources. The third reason is embarrassment. I don’t want to look stupid in front of some unknown huge number of people online. At the conference you can talk to a speaker or just strike up a conversation with the people near you. It can be difficult to ask a question in a public forum when you are new. The same can be said for a senior sysadmin too.

Lastly, and I think this is the most important reason, in-person it is easier to ask a question that you don’t know how to ask. Online forums work best when you know exactly what you are asking for. Ever been “yelled at” online for asking a question “the wrong way” or for incorrect use of terminology? In person you can have a dialog that is exploratory. You work through any vocabulary issues along the way as you discuss the issue. I find that in this situation I usually learn more than just the specific question I was asking.

LOPSA-East is a very friendly conference. It is small enough that everyone feels comfortable striking up a conversation with anyone there. Yet, it is big enough that it has “critical mass” and gets really good presentations.

Hope to see you there!

Info is here: http://lopsa-east.org or click here to register.

LOPSA-East (formerly PICC) is May 3-4, 2013 in New Brunswick, NJ. It is easy to reach by car and train.