<?xml version="1.0" encoding="UTF-8"?>
 <rdf:RDF xmlns="http://purl.org/rss/1.0/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:cc="http://web.resource.org/cc/" xmlns:syn="http://purl.org/rss/1.0/modules/syndication/" xmlns:admin="http://webns.net/mvcb/">
  <channel rdf:about="http://pinboard.in">
    <title>Pinboard (bpo)</title>
    <link>https://pinboard.in/u:bpo/public/</link>
    <description>recent bookmarks from bpo</description>
    <items>
      <rdf:Seq>	<rdf:li rdf:resource="http://dyn.com/5-myths-about-implementing-configuration-management/"/>
	<rdf:li rdf:resource="http://www.cmdln.org/2012/10/24/cfengine-3-policy-update-or-how-cf_promises_validated-works/"/>
	<rdf:li rdf:resource="http://www.rudder-project.org/foswiki/bin/view"/>
	<rdf:li rdf:resource="http://chester.id.au/2012/06/27/a-not-sobrief-aside-on-reigning-in-chaos/"/>
	<rdf:li rdf:resource="http://michaeldehaan.net/post/29084242802/double-tap-theorem-of-configuration-management"/>
	<rdf:li rdf:resource="http://research.iu.hio.no/papers/virt.pdf"/>
	<rdf:li rdf:resource="http://research.iu.hio.no/papers/burgess-ACM-TOCS.pdf"/>
	<rdf:li rdf:resource="http://blog.lusis.org/blog/2012/05/24/configuration-drift-and-next-gen-cm/"/>
	<rdf:li rdf:resource="http://cfengine.com/markburgess/papers/totalfield.pdf"/>
	<rdf:li rdf:resource="http://rsug.itd.umich.edu/software/radmind/"/>
	<rdf:li rdf:resource="http://www.infrastructures.org/"/>
	<rdf:li rdf:resource="http://www.cfengine.org/docs/cfengine-Reference.html"/>
      </rdf:Seq>
    </items>
  </channel><item rdf:about="http://dyn.com/5-myths-about-implementing-configuration-management/">
    <title>Debunking 5 Myths About Implementing Configuration Management | Dyn Blog</title>
    <dc:date>2012-11-27T21:33:01+00:00</dc:date>
    <link>http://dyn.com/5-myths-about-implementing-configuration-management/</link>
    <dc:creator>bpo</dc:creator><dc:subject>cfengine</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:bpo/b:ec6e4649f8f4/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:bpo/t:cfengine"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://www.cmdln.org/2012/10/24/cfengine-3-policy-update-or-how-cf_promises_validated-works/">
    <title>CFEngine 3 Policy Update or How cf_promises_validated Works – cmdln.org (a sysadmin blog)</title>
    <dc:date>2012-11-19T18:00:05+00:00</dc:date>
    <link>http://www.cmdln.org/2012/10/24/cfengine-3-policy-update-or-how-cf_promises_validated-works/</link>
    <dc:creator>bpo</dc:creator><dc:subject>cfengine</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:bpo/b:f4d3cbc41c01/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:bpo/t:cfengine"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://www.rudder-project.org/foswiki/bin/view">
    <title>WebHome &lt; Main &lt; Rudder Project</title>
    <dc:date>2012-11-12T23:02:49+00:00</dc:date>
    <link>http://www.rudder-project.org/foswiki/bin/view</link>
    <dc:creator>bpo</dc:creator><dc:subject>cfengine</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:bpo/b:7c9ce5ce8a41/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:bpo/t:cfengine"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://chester.id.au/2012/06/27/a-not-sobrief-aside-on-reigning-in-chaos/">
    <title>A not-so-brief aside on reigning in chaos | Journal de Jacques</title>
    <dc:date>2012-11-08T20:14:01+00:00</dc:date>
    <link>http://chester.id.au/2012/06/27/a-not-sobrief-aside-on-reigning-in-chaos/</link>
    <dc:creator>bpo</dc:creator><description><![CDATA[Part of why it took me so long to realise this is that Chef falls prey to the Ruby community propensity to utterly unnecessary puns and wordplay. I’m now embarking on my fourth decade and the appeal of wrapping concepts in clever but non-descriptive names has well and truly worn the hell off. Chef takes the whole metaphor to the nth degree — recipes, knives and so on — until mysteriously it doesn’t (Ohai). This did not help me in coming to grips with how the thing actually worked.

And that’s the second problem: you need to know too much about how Chef works in order to get work done. Chef is less a tool and more a framework; and it’s not until you’ve spent weeks head-butting the documentation that it becomes apparent that this framework is about abstractly listing commands for remote execution.

If only I’d paid more attention to the surrounding literature. Chef’s documentation repeatedly mentions the concept of idempotency. The point is that Chef only seems to get as far as idempotency and no further. If you scripts are idempotent, goes the Chef reasoning, running them multiple times will always cause your system to converge to the correct state.

The problem is that this pushes all responsibility for ensuring idempotency back onto me. And I don’t bloody want it. I would rather have a detect-repair mechanism embedded in the tool than have to recreate that logic myself. So far as I can tell, Chef supports this only partially.]]></description>
<dc:subject>chef cfengine puppet</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:bpo/b:a4ea414f1aee/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:bpo/t:chef"/>
	<rdf:li rdf:resource="https://pinboard.in/u:bpo/t:cfengine"/>
	<rdf:li rdf:resource="https://pinboard.in/u:bpo/t:puppet"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://michaeldehaan.net/post/29084242802/double-tap-theorem-of-configuration-management">
    <title>Michael DeHaan • Double Tap Theorem of Configuration Management</title>
    <dc:date>2012-09-11T19:24:40+00:00</dc:date>
    <link>http://michaeldehaan.net/post/29084242802/double-tap-theorem-of-configuration-management</link>
    <dc:creator>bpo</dc:creator><description><![CDATA[Fun read, though I think he misses Burgess's purpose.

---

Simple software evolves fastest — innovators dilemma applies just as much to software as Sears in the modern era of the internet.  Systems are solved by doers.   By complicating the way we talk about the field, and making simple things complicated, we increase the mass of the system, and as the Bernoulli Principle indicates, we can’t compress the flow of information.  The spice must flow.  

The best way for the spice to flow is we talk about systems the way they really are and just get stuff done.   There’s complexity in stuff like video encoding, filesystems, crypto,  virtualization, or computer graphics rendering — but configuration management should not be rocket surgery.   ]]></description>
<dc:subject>cfengine sysadmin</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:bpo/b:8525b2d34fd9/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:bpo/t:cfengine"/>
	<rdf:li rdf:resource="https://pinboard.in/u:bpo/t:sysadmin"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://research.iu.hio.no/papers/virt.pdf">
    <title>Adaptive provisioning using virtual machines and autonomous role-based management</title>
    <dc:date>2012-08-14T18:05:10+00:00</dc:date>
    <link>http://research.iu.hio.no/papers/virt.pdf</link>
    <dc:creator>bpo</dc:creator><description><![CDATA[A modern server system must deliver a complex set of obli- gations towards its users. We study the concept of roles as au- tonomous encapsulations of a set of promises. Using virtualiza- tion and configuration management, every defined role for a real- life computer system can be realized as a self managing agent that is aware of other, related roles within the same broader context. A prototype implementation that provides web hotel services for customers is presented and discussed.]]></description>
<dc:subject>paper infrastructure cfengine</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:bpo/b:4ae1663c27fd/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:bpo/t:paper"/>
	<rdf:li rdf:resource="https://pinboard.in/u:bpo/t:infrastructure"/>
	<rdf:li rdf:resource="https://pinboard.in/u:bpo/t:cfengine"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://research.iu.hio.no/papers/burgess-ACM-TOCS.pdf">
    <title>Measuring System Normality</title>
    <dc:date>2012-06-11T20:36:33+00:00</dc:date>
    <link>http://research.iu.hio.no/papers/burgess-ACM-TOCS.pdf</link>
    <dc:creator>bpo</dc:creator><description><![CDATA[A comparative analysis of transaction time-series is made, for light to moderately loaded hosts, motivated by the problem of anomaly detection in computers. Criteria for measuring the statistical state of hosts are examined. Applying a scaling transformation to the measured data, it is found that the distribution of ﬂuctuations about the mean is closely approximated by a steady-state, maximum-entropy distribution, modulated by a periodic variation. The shape of the distribution, under these conditions, depends on the dimensionless ratio of the daily/weekly periodicity and the correlation length of the data. These values are persistent or even invariant. We investigate the limits of these conclusions, and how they might be applied in anomaly detection.]]></description>
<dc:subject>cfengine monitoring</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:bpo/b:b22f9c2f2c9a/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:bpo/t:cfengine"/>
	<rdf:li rdf:resource="https://pinboard.in/u:bpo/t:monitoring"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://blog.lusis.org/blog/2012/05/24/configuration-drift-and-next-gen-cm/">
    <title>Configuration Drift and Next-gen CM - blog dot lusis</title>
    <dc:date>2012-05-31T18:42:32+00:00</dc:date>
    <link>http://blog.lusis.org/blog/2012/05/24/configuration-drift-and-next-gen-cm/</link>
    <dc:creator>bpo</dc:creator><dc:subject>cfengine chef puppet cm sysadmin</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:bpo/b:6432608db492/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:bpo/t:cfengine"/>
	<rdf:li rdf:resource="https://pinboard.in/u:bpo/t:chef"/>
	<rdf:li rdf:resource="https://pinboard.in/u:bpo/t:puppet"/>
	<rdf:li rdf:resource="https://pinboard.in/u:bpo/t:cm"/>
	<rdf:li rdf:resource="https://pinboard.in/u:bpo/t:sysadmin"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://cfengine.com/markburgess/papers/totalfield.pdf">
    <title>On system rollback and totalised fields: An algebraic approach to system change</title>
    <dc:date>2012-02-06T20:59:23+00:00</dc:date>
    <link>http://cfengine.com/markburgess/papers/totalfield.pdf</link>
    <dc:creator>bpo</dc:creator><description><![CDATA["In system operations the term rollback is often used to imply that arbitrary changes can be reversed i.e. ‘rolled back’ from an erroneous state to a previously known acceptable state. We show that this assumption is ﬂawed and discuss error-correction schemes based on absolute rather than relative change."

"By formulating this problem algebraically, the discussion is distanced from the sometimes emotional standpoints that bind system administrators to the notion of rollback: desperately wanting does not make it possible. The discussion about totalisation of ﬁelds is particularly useful, as it maps nicely to the ﬂaws in this thinking. To deal with the inverse of a many-to-one map, one must invoke a policy or arbitrary selection."]]></description>
<dc:subject>paper deployment cfengine automation</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:bpo/b:6a321abf7798/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:bpo/t:paper"/>
	<rdf:li rdf:resource="https://pinboard.in/u:bpo/t:deployment"/>
	<rdf:li rdf:resource="https://pinboard.in/u:bpo/t:cfengine"/>
	<rdf:li rdf:resource="https://pinboard.in/u:bpo/t:automation"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://rsug.itd.umich.edu/software/radmind/">
    <title>Research Systems Unix Group: radmind</title>
    <dc:date>2009-11-17T17:21:00+00:00</dc:date>
    <link>http://rsug.itd.umich.edu/software/radmind/</link>
    <dc:creator>bpo</dc:creator><description><![CDATA[At its core, radmind operates as a tripwire. It is able to detect changes to any managed filesystem object, e.g. files, directories, links, etc. However, radmind goes further than just integrity checking: once a change is detected, radmind can optionally reverse the change.

Each managed machine may have its own loadset composed of multiple, layered overloads. This allows, for example, the operating system to be described separately from applications.
]]></description>
<dc:subject>tools sysadmin deployment unix automation cfengine</dc:subject>
<dc:identifier>https://pinboard.in/u:bpo/b:dae914c0d3a3/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:bpo/t:tools"/>
	<rdf:li rdf:resource="https://pinboard.in/u:bpo/t:sysadmin"/>
	<rdf:li rdf:resource="https://pinboard.in/u:bpo/t:deployment"/>
	<rdf:li rdf:resource="https://pinboard.in/u:bpo/t:unix"/>
	<rdf:li rdf:resource="https://pinboard.in/u:bpo/t:automation"/>
	<rdf:li rdf:resource="https://pinboard.in/u:bpo/t:cfengine"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://www.infrastructures.org/">
    <title>Infrastructures.Org: Best Practices in Automated Systems Administration and Infrastructure Architecture: Home</title>
    <dc:date>2008-04-21T20:43:46+00:00</dc:date>
    <link>http://www.infrastructures.org/</link>
    <dc:creator>bpo</dc:creator><dc:subject>architecture automation cfengine deployment infrastructure monitoring reference sysadmin</dc:subject>
<dc:identifier>https://pinboard.in/u:bpo/b:6c9a36c7dd19/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:bpo/t:architecture"/>
	<rdf:li rdf:resource="https://pinboard.in/u:bpo/t:automation"/>
	<rdf:li rdf:resource="https://pinboard.in/u:bpo/t:cfengine"/>
	<rdf:li rdf:resource="https://pinboard.in/u:bpo/t:deployment"/>
	<rdf:li rdf:resource="https://pinboard.in/u:bpo/t:infrastructure"/>
	<rdf:li rdf:resource="https://pinboard.in/u:bpo/t:monitoring"/>
	<rdf:li rdf:resource="https://pinboard.in/u:bpo/t:reference"/>
	<rdf:li rdf:resource="https://pinboard.in/u:bpo/t:sysadmin"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://www.cfengine.org/docs/cfengine-Reference.html">
    <title>GNU cfengine</title>
    <dc:date>2007-10-10T00:48:53+00:00</dc:date>
    <link>http://www.cfengine.org/docs/cfengine-Reference.html</link>
    <dc:creator>bpo</dc:creator><dc:subject>documentation reference cfengine</dc:subject>
<dc:identifier>https://pinboard.in/u:bpo/b:d54ddb930248/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:bpo/t:documentation"/>
	<rdf:li rdf:resource="https://pinboard.in/u:bpo/t:reference"/>
	<rdf:li rdf:resource="https://pinboard.in/u:bpo/t:cfengine"/>
</rdf:Bag></taxo:topics>
</item>
</rdf:RDF>