start new:
tmux
start new with session name:
tmux new -s myname
| #!groovy | |
| import groovy.json.JsonOutput | |
| import groovy.json.JsonSlurper | |
| def label = "mypod-${UUID.randomUUID().toString()}" | |
| podTemplate(label: label, yaml: """ | |
| spec: | |
| containers: | |
| - name: mvn | |
| image: maven:3.3.9-jdk-8-alpine |
| import hudson.triggers.*; | |
| for (item in Jenkins.instance.getItems(Project)) { | |
| println("--- Scheduling for " + item.name + " ---") | |
| def trigger = item.triggers.get(Jenkins.instance.getDescriptor(TimerTrigger.class)); | |
| if (trigger) { | |
| println trigger.spec; | |
| } | |
| } |
| ''' | |
| @author Bommarito Consulting, LLC | |
| @date 2012-12-23 | |
| Generate .ssh/config lines from EC2 instance information. | |
| ''' | |
| # Imports | |
| import boto | |
| import os |
| #!/usr/bin/python | |
| """AWS EC2 SSH config Generator.""" | |
| import boto3 | |
| import os | |
| # The location and name of our generated config file | |
| path_to_config = '/.ssh/aws_demo.config' |
| # /srv/salt/upgrade_the_app.sls | |
| # Example of a complex, multi-host Orchestration state that performs status checks as it goes. | |
| # Note, this is untested and is meant to serve as an example. | |
| # Run via: salt-run state.orch upgrade_the_app pillar='{nodes: [nodeA, nodeB], version: 123}' | |
| {% set nodes = salt.pillar.get('nodes', []) %} | |
| {% set all_grains = salt.saltutil.runner('cache.grains', | |
| tgt=','.join(nodes), tgt_type='list') %} | |
| {# Default version if not given at the CLI. #} |
I use tmux splits (panes). Inside one of these panes there's a Vim process, and it has its own splits (windows).
In Vim I have key bindings C-h/j/k/l set to switch windows in the given direction. (Vim default mappings for windows switching are the same, but prefixed with C-W.) I'd like to use the same keystrokes for switching tmux panes.
An extra goal that I've solved with a dirty hack is to toggle between last active panes with C-\.
Here's how it should work:
| Some Jenkinsfile examples |
| #!/bin/sh | |
| # Suspend, hibernate, restart or shutdown the computer without sudo! | |
| # by Chris Wong | |
| # Released to the public domain. | |
| NAME=$0 | |
| usage() { | |
| echo "Usage: $NAME suspend|hibernate|restart|shutdown" |
This gist provides a quick overview of deploying SSL certificates to servers using Salt. I use a wildcard certificate for our domain, which makes management easier.
pillar_ssl-certificate.sls, which should be populated with your certificates and placed in Salt's pillar_roots directory (typically /srv/pillar).state_ssl-certificate.sls in Salt's file_roots directory (typically /srv/salt).top.sls in both the pillar and state top.sls file. (Modify for your minion IDs of course.)Use pillars to distribute sensitive data, such as SSL certificates. Accoring to the [Salt Pillar Walkthrough][2]:
Information transferred via pillar is guaranteed to only be presented to the minions that are targeted, making Pillar suitable for managing security information, such as cryptographic keys and passwords.