Running a masterless salt-minion lets you use salt's configuration management for a single machine. It is also useful for testing out state trees before
WITH btree_index_atts AS ( | |
SELECT nspname, relname, reltuples, relpages, indrelid, relam, | |
regexp_split_to_table(indkey::text, ' ')::smallint AS attnum, | |
indexrelid as index_oid | |
FROM pg_index | |
JOIN pg_class ON pg_class.oid=pg_index.indexrelid | |
JOIN pg_namespace ON pg_namespace.oid = pg_class.relnamespace | |
JOIN pg_am ON pg_class.relam = pg_am.oid | |
WHERE pg_am.amname = 'btree' | |
), |
// Check if a slave has < 10 GB of free space, wipe out workspaces if it does | |
import hudson.model.*; | |
import hudson.util.*; | |
import jenkins.model.*; | |
import hudson.FilePath.FileCallable; | |
import hudson.slaves.OfflineCause; | |
import hudson.node_monitors.*; | |
for (node in Jenkins.instance.nodes) { |
#!/bin/sh | |
# size of swapfile in megabytes | |
swapsize=512 | |
# does the swap file already exist? | |
grep -q "swapfile" /etc/fstab | |
# if not then create it | |
if [ $? -ne 0 ]; then |
#!/usr/bin/env python | |
""" | |
This is a cute little script for easily running shell commands across many | |
servers using salt. | |
Copyright (c) 2013 Steven Arcangeli | |
Permission is hereby granted, free of charge, to any person obtaining a copy of | |
this software and associated documentation files (the "Software"), to deal in |
You are now connected to database "postgres" as user "postgres". | |
postgres:5432# create table birds (bird_info json); | |
CREATE TABLE | |
Time: 162.227 ms | |
postgres:5432# insert into birds VALUES( '{"name": "scrubjay", "where": "my backyard", "when": "2013-05-24"}'); | |
INSERT 0 1 | |
Time: 0.616 ms | |
postgres:5432# select * from birds; | |
bird_info | |
-------------------------------------------------------------------- |
Use extractDocs.py to parse and index the StackOverflow posts.xml file into an existing index. | |
Usage: extractDocs.py [options] file | |
Options: | |
-h, --help show this help message and exit | |
-s SERVER, --server=SERVER | |
ElasticSearch Server | |
-i INDEX, --index=INDEX | |
Index name to use |
I'm a big fan of the Ops School idea. I've struggled for years about how to "train up" someone coming into this field. So much of our skill set is forged in the fire of outages and troubleshooting.
One of the things that is both good and bad about system administration and operations is that we tend to see patterns. It's good in that we immediately see things that stand out. The downside is we tend to superimpose that pattern recognition in inappropriate ways.
We had an interesting issue happen yesterday at the dayjob. I won't go into exactly what it was here but I had an idea based on some graphs I was looking at. It's part social experiment but it's also part problem solving skills.
Given the following image with no context, what do you think happened? What are some of the key indicator points that jump out and what pattern do they call to mind?
_(Since it may not be clear simply from an image resolution perspective, there are 4 me
/** | |
* Modified version of TJ's http support file from the Express repo: | |
* https://github.com/visionmedia/express/blob/master/test/support/http.js | |
* | |
* Module dependencies. | |
*/ | |
var EventEmitter = require('events').EventEmitter | |
, should = require('should') | |
, methods = ['get','post','put','delete','head'] |
If you have ruby-1.9.2, good. I used rvm, and did a recent install with | |
rvm install ruby-1.9.2 | |
rvm --default use 1.9.2 | |
Then to the SproutCore parts: | |
gem install sproutcore [The console output indicated SproutCore 1.6] | |
cd to your dev area, e.g. .../Development/sproutcore |