I’ve finally become a dinosaur, near extinction.

There are two problems I face:

1. I’m not a cloudy-cloud person. I love hardware.
2. I can’t keep up with how Linux does things.

I’ll work on the first, becaused after we moved a datacenter 10 miles over one night, I really wished everything we had was in EC2. The second… I’m not going to at all.

Let me explain.

I was building a new KVM environment using oVirt, which so far has been pretty cool. Part of the setup is the ovirt engine, which runs on top of Fedora 19 (or, that was recommended on their site). Cool! I love trying out a new release.

So, I get everything installed, still scratching my head why a f19 install insists on LibreOffice when I select a “server” environment.

When I’m ready to install and enabled some familiar services (like sshd and salt) I came across a terrible realization.

I’m a init person! SysV or BSD, thats me. Painfully, I admit it is all my brain has the capacity for. I have years of Star Wars and Good Eats trivia crammed in there, and I know my priorities.

At first, I just thought Solaris 10 enjoyed over-engineering a system with its init replacement, SMF, and then Ubuntu was doing their own thing with upstart

When I did the ol’ “service sshd start” I wasn’t all that surprised when I saw the message:

$ sudo service sshd restart
[sudo] password for admin:
Redirecting to /bin/systemctl restart  sshd.service
[admin@ovirt ~]$

Awesome, now we have systemctl. That wont conflict at ALL with my brains auto-compete for sysctl…

That is when I realized, I don’t care all that much to learn another init system.

Thankfully, I have Salt, and I’m getting pretty handy with it.

I would much rather run:

$ salt "ovirt*" service.restart sshd
ovirt.discdrive.bayphoto.com:
    True

What is great, is salt is now the great consistent management tool. I can’t even rely upon tools like ipconfig to output the same information across platforms, so the network module is salt is a real life saver:

$ salt "ovirt*" network.ip_addrs
 ovirt.discdrive.bayphoto.com:
     - 10.5.68.179

Salt has also replaced my need for tools like C3, for I find myself in the occasional situation where I have to execute a command across all systems at once, or just a subset of systems:

$ salt -G "os:FreeBSD" cmd.run "pkg install pkg ; pkg update -f ; fetch http://salt/fix-pkgng.sh ; sh fix-pkgng.sh"

For example, when pkgng 1.2 came out and broke salt highstate runs with its new warning message, I had to manually update pkg, and run a stand-alone script to fix our local repository.

That stand-alone script:

#!/bin/sh

# Setup Release and Architecture vars
#  for pkg.conf
REL=`uname -r | awk -F\- '{print $1}'`
ARCH=`uname -m`
DOMAIN="discdrive.bayphoto.com"


/usr/sbin/pkg install -yf pkg

rm /usr/local/etc/pkg.conf
fetch -o /usr/local/etc/pkg.conf http://salt/pkg.conf

mkdir -p /usr/local/etc/pkg/repos

echo "packagesite : {" >> /usr/local/etc/pkg/repos/pkgng.discdrive.bayphoto.com.conf
echo "   url : \"pkg+https://pkgng.discdrive.bayphoto.com/${REL}-freebsd-${ARCH}/server/\"," >> /usr/local/etc/pkg/repos/pkgng.discdrive.bayphoto.com.conf
echo "   enabled : true," >> /usr/local/etc/pkg/repos/pkgng.discdrive.bayphoto.com.conf
echo "   mirror_type : \"SRV\"," >> /usr/local/etc/pkg/repos/pkgng.discdrive.bayphoto.com.conf
echo "   signature_type : \"PUBKEY\"," >>/usr/local/etc/pkg/repos/pkgng.discdrive.bayphoto.com.conf
echo "   pubkey : \"/usr/local/etc/pkg/ssl/pkgng.discdrive.bayphoto.com.pub\"," >> /usr/local/etc/pkg/repos/pkgng.discdrive.bayphoto.com.conf
echo "}" >> /usr/local/etc/pkg/repos/pkgng.discdrive.bayphoto.com.conf

/usr/sbin/pkg audit -F
/usr/sbin/pkg update -f

Happy post-Turkey day, now go automate the rest of your holiday!