Skip to main content

Git Ansible Playbooks

One of the reasons I love Ansible over any other config management tool is because of its simplistic design and ease of use. It literally took me less than 15 minutes to write a set of playbooks to manage my local git server.

git_server_setup.yml - configures base server git repository configuration.

---
- hosts: git
  tasks:
  - name: Installing git package
    yum: name=git state=latest

  - name: Creating developers group
    group: name=developers state=present

  - name: Creating git user
    user: name=git group=developers home=/home/git shell=/sbin/nologin

  - name: Updating /home/git permissions
    file: path=/home/git mode=2770

create_git_user.yml - creates local system git user accounts.

---
- hosts: git
  tasks:

  - name: Creating new git user
    user: name={{ user_name }} password={{ user_password }} home=/home/git shell=/usr/bin/git-shell group=developers

  vars_prompt:
  - name: "user_name"
    prompt: "Enter a new git username"
    private: no

  - name: "user_password"
    prompt: "Enter a password for the new git user"
    private: yes
    encrypt: "sha512_crypt"
    confirm: yes
    salt_size: 7

create_git_repo.yml - creates an empty bare git repository.

---
- hosts: git
  vars:
    repo_name: www.alpha01.org

  tasks:
  - file: path=/home/git/{{ repo_name }} state=directory mode=2770

  - name: Creating {{ repo_name }} git repository
    command: git init --bare --shared /home/git/{{ repo_name }}

  - name: Updating repo permissions
    file: path=/home/git/{{ repo_name }} recurse=yes owner=git

Awesome Applications: 

Server Move and Upgrades!

My little corner of the internet has a new home. My old $29.99 8GB RAM, 3.40GHz Intel Core i3 dedicated server was simply not enough to handle my server needs. Which apparently OVH doesn't even provide that service anymore. So instead I hoped to their mid-tear dedicated service service branch they call So you Start. I opted with their $49.00 SYS-IP-2 service. Now my server's specs is a follows:

  • 2.66 GHz+ Intel Xeon W3520 (4 cores/ 8 threads)
  • 32 GB ECC
  • 2 x 2 TB SATA drives (Software RAID)

I would've love the drives to be SAS and the RAID to be hardware based, but it's definitely not a deal breaker, and just $49.99 a month, it's not much to complain about.

CentOS 6 to CentOS 7 upgrade:
My server migration was fairly straight forward for the most part. I opted to re-create the KVM hypervisor and its guests from scratch. Mainly because I wanted to upgrade all of guests and host from CentOS 6 to CentOS 7. This is where I encountered my first problem. Since I rely on custom nat PREROUTING/POSTROUTING iptables firewall rules for my VMs to properly be able to talk to each other and to the internet. I realized CentOS 7 defaults to firewalld, so instead of trying to rewrite my firewall rules to be compatible with firewalld, I decided to continue to use CentOS 6 on my host operating system, and only upgrade my guests VMs to CentOS 7.

On a side note, my previous guest VMs were originally using raw image format (default cache settings) for its storage, and by god what a hell of a difference it makes changing to use native block storage via LVM. I/O performance on my old server was terrible, the I/O wait percentage was roughly about 6%, now it's less than 1%. Even with the software raid, I/O performance is much better on my new server.

PHP 5.3 to 5.6 upgrade:
Since I don't have anything heavily customized on any of sites, the PHP version upgrade was practically painless.

Apache 2.2 to 2.4 upgrade:
Luckily, upgrading Apache wasn't a big hassle. Anyone considering upgrading from 2.2 to 2.4, it's definitely worth checking out the official upgrade documentation since dropping the old 2.2 configs in onto a 2.4 environment won't work off the gecko. In my case all of my sites were returning 403 forbidden replies and non of my .htaccess files weren't being read by Apache. The fix was really simple.

                AllowOverride All
                Require all granted
   

I must say, I really like Apache 2.4 new authorization syntax. What used to be a three line configuration is now a single line configuration, and much more human readable.

Future Upgrade Plans:
I didn't tackle this during the server migration, but I'll definitely going to be upgrading to Varnish 4 and use PHP FastCGI via php-fpm and mod_proxy_fcgi.

Programming: 

Linux: 

Awesome Applications: 

Networking Quirk in CentOS 7 - Virtual IP not being assigned

I just realized the order of which the IP configurations are set in the /etc/sysconfig/networking-scripts/ifcfg-* file does matter.
For example the following config was failing to assign the virtual IP 192.168.100.218 to one of my systems:

TYPE="Ethernet"
BOOTPROTO="static"
IPADDR=192.168.100.218
NETMASK=255.255.255.0
DEVICE="ens3:1"
NAME="ens3:1"
ONBOOT="yes

Systemd was spitting out the following errors:

Jun 14 01:04:19 webapps network: RTNETLINK answers: File exists
Jun 14 01:04:19 webapps network: RTNETLINK answers: File exists
Jun 14 01:04:19 webapps network: RTNETLINK answers: File exists
Jun 14 01:04:19 webapps network: RTNETLINK answers: File exists

Fix: It turns out that the DEVICE and NAME declaration needs to be assigned and specified before the networking information.

DEVICE="ens3:1"
TYPE="Ethernet"
NAME="ens3:1"
BOOTPROTO="static"
IPADDR=192.168.100.218
NETMASK=255.255.255.0
ONBOOT="yes"

Linux: 

Automated SSL certificate expiration check

It is quite simple to automate checking for near expiring SSL certificates in CentOS. This is accomplished using the certwatch tool. This tool is part of the crypto-utils package.

yum install crypto-utils

Installing crypto-utils, will create the following cron job, /etc/cron.daily/certwatch. By default the /etc/cron.daily/certwatch script only checks for SSL certificates loaded by Apache (httpd -t -DDUMP_CERTS). So Apache users don't have to do any additional config changes to in order to automate the check of near expiring SSL certificates.

Since in https://www.rubysecurity.org I use Nginx as a SSL termination proxy for an Apache backend webapp on a different machine. I had to manually update the /etc/cron.daily/certwatch script to point to my SSL certificates directly.

    #certs=`${httpd} ${OPTIONS} -t -DDUMP_CERTS 2>/dev/null | /bin/sort -u`
    INCLUDE_CERTS='/etc/nginx/certs/*.crt'
    certs=`ls $INCLUDE_CERTS 2>/dev/null`

Here is an example of an expired SSL certificate alert

[[email protected] certs]# certwatch /etc/nginx/certs/www.rubysecurity.org_2014/www.rubysecurity.org.crt
To: root
Subject: The certificate for www.rubysecurity.org has expired

################# SSL Certificate Warning ################

Certificate for hostname 'www.rubysecurity.org', in file (or by nickname):
/etc/nginx/certs/www.rubysecurity.org_2014/www.rubysecurity.org.crt

The certificate needs to be renewed; this can be done
using the 'genkey' program.

Browsers will not be able to correctly connect to this
web site using SSL until the certificate is renewed.

##########################################################
Generated by certwatch(1)

certwatch is far from perfect. It doesn't have any verbose output when doing a check, it solely relies on its exit status to verify if the check was successful. Excerpt from the man page is somewthat appalling.

DIAGNOSTICS
The exit code indicates the state of the certificate:

0
The certificate is outside its validity period, or approaching expiry

1
The certificate is inside its validity period, or could not be parsed

Linux: 

Awesome Applications: 

Restoring access to Fedora after Ubuntu upgrade

I have a quadroboot OS installation environment in my primary laptop.

  • Ubuntu (primary OS)
  • Kali
  • Fedora
  • Windows 7

I decided to upgrade my Ubuntu installing to the latest 15.04. As soon the upgrade completed and rebooted, I noticed the GRUB menu was no longer displaying my Fedora 21 environment. The problem was because I had installed Fedora under an LVM partition, while the others weren't.

Restoring boot access to Fedora was fairly simple.

First, I had install lvm2 package in Ubuntu so it's able to view and configure the LVM

[email protected]:~$ sudo apt-get install lvm2

Then I had to activate the Volume Group.

[email protected]:~$ sudo vgchange -a y

After updating the Volume Group, I was able to verify that Ubuntu was able to my Fedora 21 install.

[email protected]:~$ sudo os-prober
/dev/sda1:Windows 7 (loader):Windows:chain
/dev/sda6:Debian GNU/Linux (Kali Linux 1.0):Debian:linux
/dev/mapper/fedora-root:Fedora release 21 (Twenty One):Fedora:linux

So the last step was to generate a new grub config.

[email protected]:~$ sudo grub-mkconfig > /boot/grub/grub.cfg

Linux: 

Awesome Applications: 

Spell check from the command line

I was pleasantly surprise to learn about a utility which lets you spell check text files or any string passed as standard input, directly from the command line.

Example 1

[email protected]:~$ echo "What the fuc or what the fuck" | spell
fuc

Example 2

[email protected]:~$ cat test.txt
Fuck thi shit.
[email protected]:~$ spell test.txt
thi

Awesome Applications: 

Installing system-config-kickstart on Ubuntu

So, system-config-kickstart fails to start after the initial install.

Error:

[email protected]:~$ system-config-kickstart
Traceback (most recent call last):
File "/usr/share/system-config-kickstart/system-config-kickstart.py", line 92, in
kickstartGui.kickstartGui(file)
File "/usr/share/system-config-kickstart/kickstartGui.py", line 131, in __init__
self.X_class = xconfig.xconfig(xml, self.kickstartData)
File "/usr/share/system-config-kickstart/xconfig.py", line 80, in __init__
self.fill_driver_list()
File "/usr/share/system-config-kickstart/xconfig.py", line 115, in fill_driver_list
raise RuntimeError, (_("Could not read video driver database"))
RuntimeError: Could not read video driver database

Fix:
Downgrade the hwdata package.

# apt-get remove hwdata
# wget ftp://mirror.ovh.net/mirrors/ftp.debian.org/debian/pool/main/h/hwdata/hw...
# dpkg -i hwdata_0.234-1_all.deb
# apt-mark hold hwdata
# apt-get install system-config-kickstart

This is a known bug in Ubuntu that is yet to be fixed...
https://bugs.launchpad.net/ubuntu/+source/system-config-kickstart/+bug/1260107
https://bugs.launchpad.net/ubuntu/+source/system-config-kickstart/+bug/1236315

Linux: 

Awesome Applications: 

Ah Shit - check_http string

After updating the themes of www.alpha01.org, www.rubysecurity.org, www.rubyninja.org I completely forgot to also update the header template files to include once again their respective Google Analytics tracking code. This resulting in almost three months of no stats. When I originally setup the Nagios check_http 's on my sites, I didn't set them to also search for the custom Google Analytics string, which I always use this configuration at work on all http checks.

This can easily be accomplish using the -s|--string option of the check_http plugin.

/usr/local/nagios/libexec/check_http -I www.rubysecurity.org -S -t 10 --string UA-12912270-3

So the lesson learned, you should always configure your check_http Nagios service checks to also search for a custom string as part of the check!

Awesome Applications: 

Google Apps API OAuth2 shenanigans

So I literally was just about to start flipping tables because I wasn't able to get my Google Apps API OAuth2 api verification to work. I was getting the following error:

401. That’s an error.

Error: invalid_client

no support email

As the documentation describes, I created my application and enabled Calendar API access to it, and lastly setup my credentials. The problem was that I was generating my OAuth 2.0 client IDs without completing the app's consent screen data. As soon as I specified my email address in my app's consent screen data and regenerated new a client ID, I was able to authenticate my application. If only the Google Developer Console would've given a warning of some sort prior to generating a client ID, a lot of #!%[email protected]*# moments would've been avoided.

Programming: 

Awesome Applications: 

PF syntax check

[[email protected] /etc]# pfctl -nf /etc/pf.conf
/etc/pf.conf:4: syntax error

Awesome Applications: 

Unix: 

Pages

Premium Drupal Themes by Adaptivethemes