bhalothia

This gist contains everything you need to install StatsD and Graphite on CentOS 6.3. Unless I forgot something. If I did, shoot a reminder email to noah at one more bug dot com. **tl;dr: womm, ymmv, yolo.**

I (mostly) followed the steps shown in the [EZUnix wiki](http://www.ezunix.org/index.php?title=Install_statsd_and_graphite_on_CentOS_or_RHEL)

And I also referred back to [this gist by Michael Grace](http://geek.michaelgrace.org/2011/09/how-to-install-graphite-on-ubuntu/)

bhalothia

I would like to list out some of the points that differentiates GIT from SVN as a Version Control tool.

 1. Basic difference between the above mentioned tools are that SVN is a Centralized and GIT is a Distributed version control tool.
 
 2. Commit happens atomic in nature for SVN where as for GIT it's more like file versioning happens with every commit.

 3. GIT versions by storing the contents of the files for tracking history where as in SVN the basic data storage is done by creating a differences between the individual files for each change.

 4. GIT stores every changes in any of its sub-directories of its project structure within the .git folder that gets created only on the parent folder of the project structure where the git initialized a new git repository where as in SVN the .svn will be created in every sub-directories within the project structure to store the metadatas of each and every file and folder.

bhalothia

# -*- mode: ruby -*-
# vi: set ft=ruby : 
# David Lutz's Multi VM Vagrantfile
# inspired from Mark Barger's https://gist.github.com/2404910

boxes = [
  { :name => :web,    :role => 'web_dev',     :ip => '192.168.33.1', :ssh_port => 2201, :http_fwd => 9980, :cpus =>4, :shares => true },
  { :name => :data,        :role => 'data_dev',         :ip => '192.168.33.2', :ssh_port => 2202, :mysql_fwd => 9936, :cpus =>4 },
  { :name => :railsapp,    :role => 'railsapp_dev',     :ip => '192.168.33.3', :ssh_port => 2203, :http_fwd => 9990, :cpus =>1}
]

bhalothia

[user]
	name = Pavan Kumar Sunkara
	email = pavan.sss1991@gmail.com
[core]
	editor = vim
	whitespace = fix,-indent-with-non-tab,trailing-space,cr-at-eol
	excludesfile = ~/.gitignore
[sendemail]
	smtpencryption = tls
	smtpserver = smtp.gmail.com

bhalothia

#!/bin/sh

# Sublime Text 3 install with Package Control
# http://simonewebdesign.it/install-sublime-text-3-on-linux/

# Run this script with:
# $ curl -L git.io/sublimetext | sh


# Detect the architecture

bhalothia

#!/bin/bash

env x='() { :;}; echo vulnerable' bash -c "echo this is a test" | grep vulnerable > /dev/null 2>&1
if [ $? -eq 1 ]; then
  echo "Not vulnerable. Machine is safe."
  exit 0
else
  echo -n "Vulnerable. Version: "
  /bin/bash --version
  echo "Installing patch."

bhalothia

RDpropertyfilelogin {
    org.mortbay.jetty.plus.jaas.spi.PropertyFileLoginModule sufficient
    debug="true"
    file="/.../server/config/realm.properties";

    com.dtolabs.rundeck.jetty.jaas.JettyCachingLdapLoginModule sufficient
    debug="false"
    contextFactory="com.sun.jndi.ldap.LdapCtxFactory"
    providerUrl="ldap://xx.xx.xx.xx:389"
    port="389"

bhalothia

ORIGINAL_JENKINS_SERVER=
ORIGINAL_SERVER_USER=

NEW_JENKINS_SERVER=
NEW_SERVER_USER=

# ON THE ORIGINAL JENKINS SERVER
ssh $ORIGINAL_SERVER_USER@$ORIGINAL_JENKINS_SERVER
cd /var/lib/jenkins/
for i in `ls jobs`; do echo "jobs/$i/config.xml";done > config.totar

bhalothia

#
# This is an example of a knife.rb configuration that uses yml and a 
# simple env var (CHEF_ENV) to manage multiple hosted Chef environments.
#
# Example usage:
# export CHEF_ENV=evnironment_01
# knife status
# 
# Based on: http://blog.blankpad.net/2010/09/28/multiple-knife-environments---the-return/
#

bhalothia

Jenkins Best Practices
https://en.wikipedia.org/wiki/Continuous_integration<- Read this!
https://wiki.jenkins-ci.org/display/JENKINS/Jenkins+Best+Practices
http://www.slideshare.net/andrewbayer/7-habits-of-highly-effective-jenkins-users
Set up version control of job configurations
Keep jobs simple! Don't put a ton of bash in each job. If a job needs to do something complex, put it in a script in GitHub and check it out as needed.
Use templated builders to simplify common tasks
Keep all scripts in version control - avoid running scripts that live on the Jenkins server filesystem
Don't install unnecessary plugins - plugins are often written by third parties and can interact with each other in strange ways
Use LDAP authentication if possible for traceability - avoid anonymous access