_hacks – Page 4 – jozefmares.com
Home top_menu _hacks
Category:

_hacks

_hacks

Managing certificate authority with comfort

by Jozef Mares
written by Jozef Mares

I manage multiple certificate authorities – two are for my company, three are for customers, one is my personal and so on. I run certificate authorities because I do not like feeling dependant on companies with stupid security policies like commercial certificate companies. It my sound like I hate these companies but I only consider them as pure security evil (yet, I still must use them). :)

If you are asking, why you should manage your own certificate authority consider things like very own VPN server (based on OpenVPN or IPSEC), securing your sites and applications like OwnCloud or SOGo, signing emails (yes, you can do it with GPG) and so on. x509 standard is good – implementation and realisation is really bad.

So, if I do not want go usual way I need to manage CA on my own. I just to use TinyCA2 which seems to be dead, and I’m on OS X now so TinyCA2 did not fit to my system and workflow. Thank you for your service, but it is time to move to new home dear TinyCA2.

I found few other options like OpenVPN easy-rsa, some shell-hacked-ultimate-wrappers on Github, huge projects like OpenCA and so on. I even tried to use certificate helper integrated in Keychain Access on OS X.

Results:

* Keychain Access is good for generating certificate request for user, but sucks on CA management;
* OpenCA is way to big for me;
* easy-rsa and shell-hacked-ultimate-wrappers seemed to be solution, yet I do not like it;

Bummer.

Then I started to google around again and I realised I totally missed XCA project. After installation I really did not liked user interface, but it is just about habit. TinyCA2 UI was just different, you have to get used to new software (and is good if you know how certificates work – it will help :) ).

I did not made migration of old CA’s to new system as I’m waiting ’till certificates will expire and then I will migrate users to new standard with 4096 bit long keys.

What else you should know about this software?
* XCA stores whole CA in single file with suffix xdb;
* has pretty decent UI with glitches but I can survive them;
* supports whole subset of formats like DER, PEM, PFX and so on;
* allows you to sign external requests – I needed this;
* supports revocation lists – with little bit scripting you can automate it;
* has templates – I hate to fill forms again and again with same informations;
* has pretty good documentation;

Hope this software will stay with me as long as TinyCA2.

_hacks

Puppetizing OS X – Managing Homebrew

by Jozef Mares
written by Jozef Mares

Recently, I felt in love with Homebrew as it is far better way to manage apps then Fink and Ports I used before.

I want to manage my Homebrew apps with Puppet and this is how I’m doing it.

Some research before coding and found this Homebrew module on github.

Install module wherever you want (depends on setup type – are you standalone or client/server driven?) and we are going to configure it.

I renamed module to osx-homebrew as I want every OS X specific modules visible by simple ls. So, where I type osx-homebrew you will have plain homebrew.

I have now for testing one Puppet master in virtual machine (this workflow will change soon) thus I installed module to $puppet_dir/modules on my master.

In node definition file (in my case only site.pp for now) configuration looks like this:

node 'hack-pro' {
class { 'osx-homebrew':
user  => 'jozef',
}

$pkglist = ['detox', 'nmap', 'git']

package { $pkglist:
ensure   => installed,
provider => brew,
require  => Class['osx-homebrew']
}
}

After test run I found one error:

Error: Could not prefetch package provider 'brew': Could not list packages: Execution of '/usr/local/bin/brew list --versions' returned 1: /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/1.8/pathname.rb:853:in `expand_path': couldn't find HOME environment -- expanding `~/Library/Caches/Homebrew' (ArgumentError)
from /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/1.8/pathname.rb:853:in `expand_path'
from /usr/local/Library/Homebrew/global.rb:22:in `cache'
from /usr/local/Library/Homebrew/global.rb:41
from /usr/local/Library/brew.rb:18:in `require'
from /usr/local/Library/brew.rb:18

Unfortunately this error comes from changes in Puppet 3.X – there was introduced change where Puppet stripes $HOME variable.

You can find hotfix here.

Download it on Puppet master (in my case, find your own install path) to:

wget https://raw.github.com/nanliu/puppet-homebrew/89e5eb7408b13a87f2d229e3b023deca835201d8/lib/puppet/provider/package/homebrew.rb -O ./modules/osx-homebrew/lib/puppet/provider/package/homebrew.rb

In next run on Puppet client you will spot this:

[jozef @ hack-pro ~]$ puppet agent -t
Info: Retrieving plugin
Info: Loading facts in /Users/jozef/.puppet/var/lib/facter/has_compiler.rb
Info: Caching catalog for prg1
Info: Applying configuration version '1361584588'
Notice: /Stage[main]//Node[prg1]/Package[git]/ensure: created
Notice: /Stage[main]//Node[prg1]/Package[nmap]/ensure: created

Win!

One warning: this approach assumes you have compiler installed. If you are compiler-free you can install it with osx-homebrew module:

class { 'homebrew':
command_line_tools_package => 'command_line_tools_for_xcode_os_x_lion_aug_2012.dmg',
command_line_tools_source  => 'http://puppet/command_line_tools_for_xcode_os_x_lion_aug_2012',
}

You should notice that you must have command line tools pre-downloaded as Apple requires Apple ID to download them.

Automation of DMG files install and download security will be covered in some of next posts, for now you are on your own. :)

_hacks

Puppetizing OS X – Very basic module

by Jozef Mares
written by Jozef Mares

Previous posthave covered basic Puppet install. Now it is time to move to first module.

I created very basic module which will use appdmg provider. This is good to remember as on OS X this is standard packaging method of software distribution. To be honest, it is not very elegant nor efficient as Linux RPM or DEB packaging methods – but it is all I have. :)

Unfortunately as there are no repositories (yes, I know about ports, homebrew) and so on but there are not used to distribute software like VMWare, Firefox etc. Enough bullshit, let’s see some code!

class osx-firefox {

package { 'Firefox':
provider  => appdmg,
source    => "http://download.cdn.mozilla.net/pub/mozilla.org/firefox/releases/latest/mac/en-US/Firefox%2019.0.dmg",
ensure    => installed,
}

}

You can see I named module osx-firefox as I have every app as separate module. Why is this useful? If I want to include for example package osx-vmware to node “hack-pro” but not to “macbook-air” node I can with simple:

include osx-vmware

This code is stored in file init.pp which is in $module_path/osx-firefox/manifests/init.pp

You can do test run by removing Firefox and running (this, with –noop option is simple method to test modules):

puppet apply path_to_init.pp

Hooray, my first module works like a charm and installed Firefox for me.

Newer Posts
Older Posts