... keeping update ...
#!/bin/bash | |
# A simple script to backup an organization's GitHub repositories. | |
#------------------------------------------------------------------------------- | |
# NOTES: | |
#------------------------------------------------------------------------------- | |
# * Under the heading "CONFIG" below you'll find a number of configuration | |
# parameters that must be personalized for your GitHub account and org. | |
# Replace the `<CHANGE-ME>` strings with the value described in the comments | |
# (or overwrite those values at run-time by providing environment variables). |
tl;dr Generate a GPG key pair (exercising appropriate paranoia). Send it to key servers. Create a Keybase account with the public part of that key. Use your keypair to sign git tags and SBT artifacts.
GPG is probably one of the least understood day-to-day pieces of software in the modern developer's toolshed. It's certainly the least understood of the important pieces of software (literally no one cares that you can't remember grep's regex variant), and this is a testament to the mightily terrible user interface it exposes to its otherwise extremely simple functionality. It's almost like cryptographers think that part of the security comes from the fact that bad guys can't figure it out any more than the good guys can.
Anyway, GPG is important for open source in particular because of one specific feature of public/private key cryptography: signing. Any published software should be signed by the developer (or company) who published it. Ideally, consu
// Related to https://issues.jenkins-ci.org/browse/JENKINS-26481 | |
abcs = ['a', 'b', 'c'] | |
node('master') { | |
stage('Test 1: loop of echo statements') { | |
echo_all(abcs) | |
} | |
stage('Test 2: loop of sh commands') { |
The goal was to be able to perform a network install of OmniOS from a Debian system.
I know there is refinement that can take place in this process (and these notes), but this got me up and running.
All testing took place on a Mac running VirtualBox with the extra extensions installed to allow for PXE booting. However I cannot see why this wouldn't work on real hardware in a network that is already setup to do PXE installs.
I setup:
Add the following chunk to your existing ISC dhcpd.conf
file.
if exists user-class and ( option user-class = "iPXE" ) {
filename "http://boot.smidsrod.lan/boot.ipxe";
}
else {
filename "undionly.kpxe";
}
(or see https://gist.github.com/4008017 for a more elaborate setup
# User ssh configuration file ~/.ssh/config | |
# Gist https://gist.github.com/terrywang/3997931 | |
# man ssh_config for more information | |
# Inspired by the blog post below to fight the NSA | |
# https://stribika.github.io/2015/01/04/secure-secure-shell.html | |
# Outside of the firewall, with HTTPS proxy | |
# Package connect-proxy is required. | |
# Amazon EC2 |
host github.com | |
user git | |
hostname ssh.github.com | |
port 443 | |
proxycommand socat - PROXY:<hostname>:%h:%p,proxyport=<port> |
#!/bin/sh -e | |
# This shell script demonstrates how to use the local keyword to create | |
# dynamically-scoped variables in various shells. Notably, this technique works | |
# with AT&T ksh, as well as bash, dash, mksh, pdksh, zsh, busybox sh, and other | |
# Debian Policy-compliant sh implementations. | |
# Simple Perl-compatible testing framework. Produces TAP output. | |
COUNT=0 | |
is () { |