Tag Archives: cfengine

Links: Jun 3

Writing is nature’s way of telling you how sloppy your thinking is.

 Technology:

  • Shocking post-mortem from Joyent: operator mistake and a tool which reboots the whole datacenter without requesting additional confirmation.
  • Defensive BASH programming — an excellent post on scripting techniques!
  • Thinking for programmers by Leslie Lamport. The epigraph comes from this talk.
  • The best expect script I found to execute commands on servers remotely via ssh. This is really handy when one does not have key-based authentication set up. The downside is that it’s slow, so one need to parallelise it if one has over few dozen of servers to crawl.
  • ncf — CFEngine framework for small installations, runs in pure CFEngine language, to help structure your CFEngine policy and provide reusable, single purpose components distributed under the GPLv3 license.
  • The same guys are behind the Rudder — web-driven, role-based solution for IT Infrastructure Automation & Compliance.
  • “Law of Murphy for devops: if thing can able go wrong, is mean is already wrong but you not have Nagios alert of it yet”. Therefore, don’t forget to monitor these things.
  • Interesting stats on monitoring tools — Nagios is the king, Sensu and Zabbix have a large chunk of large deployments.

English:

  • Hilarious story about why programming sucks. Careful and exact observations put in a lively and funny language. It definitely made my day!
  • Quirks with pronunciation of some borrowed words:

    Another word that the British Anglicized from French is harass and its related noun harassment. They shifted the accent to the first syllable, sounding like “harris.” The Americans preferred the French-style second-syllable stress, no doubt further encouraged by the double s. But the British style is becoming more popular with people who don’t want to sound like they’re saying “her ass” — sort of like how the British “urine-us” pronunciation of Uranus, based on the Latin and Greek stress pattern, is sometimes preferred by Americans who don’t like how the American say-it-like-it-looks version sounds like “your anus.”

  • Stop new wordage? Never gonna happen. In defence of unnecessary words.
  • Corporate speak — speaking strategically without a strategy.

As languages go, English is particularly extreme in differentiating between stressed and unstressed syllables; the stressed syllables play a disproportionately big role in making words identifiable, and because unstressed syllables are out of the spotlight, and don’t contribute much to the exact identity of words, it doesn’t really matter exactly what they sound like. For example, some people pronounce the first syllable of believe as /bɪ/, others as /bə/, and in fact it would often be hard to tell exactly which vowel sound is used. Even if you use a different one – if you say, for example, /bʊ/ or /be/ – the identity of the word will be clear; the important thing is to pronounce the stressed second syllable with a clear /iː/ vowel.

— http://www.macmillandictionaryblog.com/schwa-syllables-and-words-in-different-guises-part-1

Other:

The story behind lavabit shut down.



Links: Jan 2

Merry Christmas and a happy New Year! :-)

Technology

  • A very interesting and simple video explaining how the Bitcoin works. As Tom Limoncelli mentioned, this is first time I understood it:



  • A video from ChefConf, Phil Dibowitz’s talk about Scaling systems configuration at Facebook. Very interesting to listen what they count as important achievements and what sort of approaches they use. Few things irked me though:
    • What point is in comparing Chef, first released in 2010, with CFEngine 2, which was released in 1998, especially considering CFEngine 3 is around since 2008? Most of the complaints about CFEngine or its shortcomings Phil makes either have been addressed or are easily implemented in CFEngine 3.
    • The lessons they have learned are enlightening, though achieving idempotent systems is very complicated in cases when you do not own the systems you are supposed to manage via configuration management.
    • Full programming languages versus DSL — well, no one argues that full programming languages are way more versatile compared to domain-specific, but that’s their purpose. Implementing functionality which DSL is tailored for, on the other hand, is faster and more efficient in DSL. I would try to strike a balance here, using each tool in the domain it is targeted at.
  • And two messages I wanted to highlight:
    • Scale is more than number of clients — this is a very powerful message that many miss.
    • Regarding testing — not long ago I had a lunch with couple of younger colleagues and we were discussing release rollouts and time estimates. I started with saying ‘Suppose your release fails at the very last step of the procedure…’ and was interrupted with ‘why would it fail?!’. I had to stop and explain that ‘Why would it fail’ is a wrong question to ask. If we knew why it would fail, we could have prepared or even address it. This is just to reinforce Phil’s message that ‘until you run it in production, you cannot know it works’. Totally agree with this.



  • An example of Docker and CFEngine integration
  • On the relevant note — is Docker really suited for use with configuration management?
  • To end chef-related links, here is a web-tool that lets you browse the data in your Chef server: Chef Browser.
  • Switching to hiring matters, two excellent blog-posts: Interviewing as a Front-End Engineer in San Francisco and On Interviewing Front-End Engineers 
  • Unknown MS-DOS 4.0M:
    • Multitasking MS-DOS 4.0 was a little known and separate development of DOS done in parallel with the development of DOS 3.x in 1985. It should not be confused with the later retail DOS 4.0 that was released in 1988. DOS 4.0 supported preemptive multitasking, shared memory, semaphores, advanced memory management, a session manager, imports, exports and a new executable format. Many of the ideas and features introduced here found their way into OS/2. Unfortunately DOS 4.0 was limited by the real-mode 8086 environment and the 640KB address space. Also programs which were not well-behaved or relied upon undocumented DOS functions would not run properly under DOS 4.0, particularly TSR programs.
    • From Larry Osterman’s blog: MS-DOS 4.0 was unique because it was developed “on spec” – IBM didn’t see a need for a multitasking version MS-DOS and didn’t have a new hardware offering on which to attach the product. But IBM did have the PC/AT which was an 80286 based processor and it didn’t have an OS that took advantage of that hardware. So IBM and Microsoft started negotiations to take the MS-DOS 4.0 code base and turn it into what eventually turned into OS/2. I ended up not working on the OS/2 effort, instead I worked on finishing up MS-DOS 4.0 for the OEM partners who had licensed MS-DOS 4.0.
    • Investigation report on MS-DOS 4.0M in Russian
  • Finally this is happening: routing battles, somebody forced the world’s Internet traffic through Belarus and Iceland.

Other



Links: Dec 24

Just when you think you’ve sorted things out it appears the whole world gone mad :-) Ukraine has got its next Maindan (that’s how we call a nation-wide protest here) and the time is even more scarce than it was. Here are few links to sum up and give you the taste:

Some other, more conventional news:

Technology

English

Other

  • NYTimes article on Lviv’s history in architecture.
  • Triumph of ignorami lasted 7 days: Ukrainian ski resort outlawed mobile phones based on citizens fantasies. Reminds me how bus and tram drivers were complaining they are receiving a radiation from newly installed GPS receivers (which do not emit any radiation by definition)

pay map
pay list

vim syntax highlighting for cfengine3

Major part of my work these days is connected with cfengine3 and writing promises. I’m kind of a vim-guy, so clearly I’m using it when writing cfengine promises and when you write a lot of code, you’d definitely want to make your development environment comfy and snug. Part of being comfy and sung in my understanding is syntax highlighting, which tremendously simplifies reading code and makes you spot typos and other sorts of mistakes right away.

There’s an initial version of syntax highlighting for cfeninge, written by Neil Watson available on github. However, I wanted more sophisticated highlighting functionality, so I took Neil’s work and spent couple of weekends extending it. Here are some screenshots with results of that extension (click to see them full-size):


At the moment, the module highlights correctly cfengine-stdlib.cf and all cf files in examples/ directory of cfengine with exception of knowledge-related promises. There’s still a lot of work to do – a bit of refactoring and then, perhaps, a rudimental syntax checker – but it seems to me already usable, so I decided to release it’s “first” version.

The syntax highlighting module is available at https://github.com/ivanpesin/vim_cf3/tree/master/syntax. To activate it, you’ll need to save cf3.vim in ~/.vim/ directory and add following lines to your ~/.vimrc:

 

Bundle execution time randomization in cfengine3

Read this article in Russian.

In our environment we use cfengine to manage servers across the organization. Having a fairly large infrastructure we have to give a lot of thought to such things as smoothing the load on cfengine hubs and other parts of the infrastructure.

This article presents some approaches to bundle execution time randomization. This might be useful when you have a bundle which is going to affect a lot of servers and you don’t want it to execute simultaneously across a whole lot, thus causing a pressure point and possible event storms.

The first approach which comes to mind is splayclass() function, which defines a class if the system clock lies within a scheduled time-interval that maps to a hash of the first argument – arbitrary string, usually set to fqdn. Different strings will hash to different time intervals, and thus one can map different tasks to time-intervals. The code utilizing this function looks like this:

This will execute report at a random moment every hour.

A nuisance with this function is that it’s somewhat limited, having only “hourly” and “daily” policies. With “hourly” policy, the class will be defined for a 5-minute interval every hour, and with “daily” policy then the class will be defined for one 5-minute interval every day. This might be either too frequent or too seldom for a specific case. This also might be a problem if you use an cfengine run interval different from a default one.

To address this nuisance we might employ dist keyword in classes’ definition which generates a probabilistic class distribution. For example:

In this example class “percent_of_runs_15”  will be defined in 15 out of (15+85=) 100 cases or in 15% of cf-agent runs. Considering that cf-agent runs with 5 minutes interval by default, that makes 15% out of (24*12 =) 288 runs per day, or 43 runs, or approximately twice per hour at a random moment. Tuning the sum and the initial number we might change the random frequency at which the class will get defined.

Dist might give us even more flexibility, for example when we need the bundle to execute at the random hour every 12 hours, but at that hour we’d like bundle to run every 5 minutes. This might be needed when bundle requires multiple runs to fix things (deleting stuff from a file is a good example). So for that matter we might combine dist keyword with persistent classes, like in:

This approach seems to be more flexible, but it also contains an issue – due to its nature, dist is probabilistic and that means it doesn’t guarantee that the percent of distribution will be exact. In fact, you should keep in mind that +/- error is a norm here and, for instance, running the 15%/85% example drew results from 13% to 18% for 15% class.

We can also apply the approach with persistent classes to splayclass() function in the following manner:

Which would allow us to execute a report (or bundle) every 5 mins throughout a random hour of the day.