Skip to content

Instantly share code, notes, and snippets.

@tylerflint
tylerflint / manifesto.md
Created November 10, 2015 22:40
Nanopack manifesto

Nanopack - Automated, api-driven infrastructure

Our Vision

What we want is clear: to develop and manage our infrastructure like we do our apps; with direct api-access at the source for real-time configuration. This requires more than just an automation layer on top of services that were designed before the cloud. This requires a fundamentally different approach to building infrastructure components and services.

api access what?

Consider a popular webserver like Apache or Nginx. To use either of these, you will write configuration in a file, and then start the service. To adjust the running configuration you would modify the same file, and restart or reload the service. A remote login and direct administrative access is required to perform both actions. Sure, you can automate this administrative task with a configuration management tool like chef or puppet, but it is still a task, and all the overhead of login and administration is still required. Imagine if the same result could be achieved via an

@tylerflint
tylerflint / 1.sh
Created July 31, 2015 21:04
nanobox simple nginx config
# generate nginx config
cat > "$(payload 'build_dir')/etc/nginx/nginx.conf" <<END
daemon off;
worker_processes 1;
error_log /data/var/log/nginx/error.log;
events {
worker_connections 1024;
}
@tylerflint
tylerflint / mk.conf
Created July 24, 2015 21:48
pkgsrc base mk.conf
.ifdef BSD_PKG_MK # begin pkgsrc settings
ABI= 64
PKGSRC_COMPILER= gcc
GCCBASE= /usr
PKG_DBDIR= /data/pkg
LOCALBASE= /data
VARBASE= /var/${project}
PKG_TOOLS_BIN= /data/sbin
@tylerflint
tylerflint / fsops.c
Created July 24, 2015 17:32
fixed fsops.c
char *
read_repos()
{
FILE *fp;
char *tmp, *b, *repos = NULL, buf[BUFSIZ];
int curlen = 0, repolen = 0;
const struct VarParam *vp;
if ((fp = fopen(PKGIN_CONF"/"REPOS_FILE, "r")) == NULL)
return NULL;
=> Bootstrap dependency digest>=20010302: found digest-20121220
=> Checksum SHA1 OK for 2e1630265953c9c01836a4b62acfa8397579346a.tar.gz
=> Checksum RMD160 OK for 2e1630265953c9c01836a4b62acfa8397579346a.tar.gz
===> Installing dependencies for pkgin-0.8.0
==========================================================================
The following variables will affect the build process of this package,
pkgin-0.8.0. Their current value is shown below:
* PKGIN_REPOSITORY_URL (not defined)
* SSLBASE (defined)
@tylerflint
tylerflint / gist:0251f1bdc788952d6bae
Last active August 29, 2015 14:25
pkgin is a booger
=> Bootstrap dependency digest>=20010302: found digest-20121220
=> Checksum SHA1 OK for 2e1630265953c9c01836a4b62acfa8397579346a.tar.gz
=> Checksum RMD160 OK for 2e1630265953c9c01836a4b62acfa8397579346a.tar.gz
===> Installing dependencies for pkgin-0.8.0
==========================================================================
The following variables will affect the build process of this package,
pkgin-0.8.0. Their current value is shown below:
* PKGIN_REPOSITORY_URL (not defined)
* SSLBASE (defined)
@tylerflint
tylerflint / procedure.md
Last active August 29, 2015 14:20
SmartOS recover from zfs core dump reboot cycle
  1. boot into option that does not import the dataset (noimport=true)

  2. import the zones zpool without mounts

zpool import -N zones
  1. scrub the zones pool to ensure data consistency
zpool scrub zones  
@tylerflint
tylerflint / gist:bdb51ecab211b50a7c39
Created March 24, 2015 17:38
dtrace quantize all userland exec
dtrace -n '
proc:::exec-success
{
self->startexec = timestamp;
self->exec = execname;
}
proc:::exit
@tylerflint
tylerflint / workflow.md
Last active August 29, 2015 14:16
illumos-joyent development workflow

Workflow

This workflow was designed specifically to aid in development of the illumos kernel, specifically for the SmartOS distribution via illumos-joyent. This guide was designed as a SmartOS supplement to the illumos developer's guide.

Goals

The goals of this workflow are to allow the following:

  1. Development occurs directly on the developers workstation, in his or her native editor and toolchain.
  2. Incremental builds can generate an official boot image.
@tylerflint
tylerflint / workflow.md
Last active August 29, 2015 14:15
smartos-live src publish/testing workflow

Workflow

This guide was designed to be the second phase of the development workflow. While the first guide focuses on a quick iterative sandbox where changes can be previewed immediately, this guide focuses on putting those changes into a live image and testing the final implementation.

Goals

The goals of this workflow are to allow the following:

  1. Development occurs directly on the developers workstation, in his or her native editor and toolchain.
  2. Incremental builds can generate an official boot image.