Apr 09

For loops and pillar data in saltstack states

Posted on by

I was tinkering with iterating through pillar data in saltstack and I hit an odd bump. First and foremost, pillar data is apparently only available during the highstate runs. Calling a state that sources pillar data in an iterative fashion will fail when called via ‘salt \* state.sls mystate’. And it’ll fail silently, that’s the ugly part.

Anyway, quick rundown of adding a bunch of SSH Keys to a single user using Pillar data. :)

Pillar data located in /srv/pillar/dev-keys/init.sls

dev-keys:
beavis:
sshkey: ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEA7zP6KewSJhSbmLAJoldDBiJlMEVZw2N0fdKX/0up6iYU0xlFjHpefwy3vCrGrlO4z6G09KRJoS2RnyyDn6o8CaCCfJNpQwMPtrMf/bYwdTwwktRXH44cQB54g+D1wSxJvpEKId3VpgEsvp+F9vBioWSJZOi8nm46/BwJZbmAWOM4KcQ2erAP7Y0VdfI42c4qraP/p8EQH6IiLFZqcaX/M2osuz1piKbi0R2UrPNeQW2JnLAXFOiqppPBRKhh5a5jDVYaeNYrp3HN2V9CzqsCxHNZ0kyb/OnKeZDtQW56oeywQNmVH1ujXSNxG9aeNOv8JoJ5AUuOWRWYkDfTpoOWSw== beavis@i.am.cornhol.io
butthead:
sshkey: ssh-dss AAAAB3NzaC1kc3MAAACBAJeFBZLdxOCEoQlcxQl2//3QfYHg0SEI21wtSgpz4Xkr3BaLAu/Ne9w4xBOd0cD6DchqqjXDTuO8xV996LVX/Tgb+eFXHjCHeKpzNdpv/Lk68QhsXaYgFWNf0SM4JOuIAditB/l6N6jxdI/UpGws51rjsZfjJmBeY1ozW3RFcUFJAAAAFQChe22uEXLRiLgDoxQGreYnu8JItwAAAIAXa3uUNv/pLVpLDPWkciin7f4fguhmPeqZqPEtkucxAtFot0YIBSeY9j1x4KcNsd7Hdifu8dCUysAeUi1vtqqgnT3DwgvTjw4WHxTl7F9sVAZZBXvIucc88cBs81Bz0i7cDvzs/XAZmwy51vTYdTc0pEWwzadiqI/fQAox+CVicAAAAIBFHCM/wKzLwfQTqBsXZbIudqUEDtvLM1x3seWYhZ93BNQIvJsWu4OtggH9LE7bd1Q6D01wQNHXylw+C1/UQxspUSVL/wtxt6z24A4pEUnU8hr1+OhRa5pw3x5Gu8fuDSd0f4UoDDJkU5EGGa/CfnzlN0B8kGIybNNpfajnXb3/zg== butthead@huhuhuh.huh.local

And our statefile…

shareduser:
user:
- present
- home: /home/shareduser
ssh_auth:
- present
- user: shareduser
- require:
- user: shareduser
- names:
{% for keys, args in pillar['dev-keys'].iteritems() %}
- {{ args['sshkey'] }}
{% endfor %}

Remember, run that from highstate or face the ugly “print hostname and exit” “error” that salt will throw at you. :)

Mar 28

Configuring PostgreSQL on CentOS using Saltstack

Posted on by

Recently I’ve fallen in love with a mass server management system called “Salt” or “Saltstack”.  After playing with Chef and Puppet, this thing stands out as truly amazing…   For the first time possibly ever, I’m actually having *FUN* with a mass management system, however that’s a full writeup for another day. :) In this post I’m going to give a brief overview of how to install PostgreSQL 9.1 on CentOS/RedHat using Salt.

First of all, I’m using the Postgres RPMs from the PGDG repo, directly from postgresql.org.  The big problem that you’ll run into is initializing the base pgsql directory/datases so Postgres can start.   When doing this manually, it’s pretty simple, you just run /etc/init.d/postgresql-9.1 initdb, and then start your service, done/done.   Salt, by default, will try to install the RPM and just fire off the service as it’s unaware of this manual necessary step, so here’s how you get around that…

Here’s the init.sls file for postgres that I have working now. This does the following things…

1. Installs the postgresql91-server RPM
2. Runs the equiv of “chkconfig on postgresql91-server”
3. Verifies the service is running everytime salt-master checks in with the salt-minion, if not it starts it.
4. Runs the initdb command, but *ONLY* if the postgresql.conf doesn’t exist, which it doesn’t on a fresh install, pre-initdb.


postgresql-9.1:
pkg.installed:
- name: postgresql91-server
service.running:
- enabled: True

postgresql-first-run-init:
cmd.run:
- cwd: /
- user: root
- names:
- service postgresql-9.1 initdb
- unless: stat /var/lib/pgsql/9.1/data/postgresql.conf
- require:
- pkg: postgresql91-server

There ya go, that should give you a fresh install of postgresql on CentOS/RedHat using the PGDP repo and the *AWESOME* SaltStack utility!

May 23

Setting up internal IPs on SolusVM (with CentOS or RedHat)

Posted on by

Hey there, I ran into a bit of an oddity today, so I figured I’d post it on up here to hopefully save someone else a bit of trouble. :)

We’ve recently been using SolusVM internally for our dev infrastructure and have been enjoying it. I’m currently in the process of lighting up a new datacenter w/ a proper A/B network setup and hit an oddity for the SolusVM side of things.

SolusVM is pretty good about setting up just about everything you need, however not so much here. Here’s a quick way to get Internal addressing working on your CentOS Based machines.

This assumes that ETH0 is your public interface and that ETH1 is your private network interface. It’ll also bring up the bridge under the name “Xenintbr0″ this is the default that SolusVM looks for.

So first off, your /etc/sysconfig/network-scripts/ifcfg-eth1 file should look like this…

DEVICE=eth1
ONBOOT=yes
BRIDGE=xenintbr0
HWADDR=00:25:90:68:E9:D1

That tells CentOS to configure ETH1 as a bridging device. Now let’s get an IP on that thing! Go ahead and create a file in /etc/sysconfig/network-scripts/ called ‘ifcfg-xenintbr0′ and populate it as follows… You should use the internal IP you want bound to this server in the configuration and your own subnet. In this case, my hardware node has an internal IP of 10.0.0.8/24.

DEVICE=xenintbr0
TYPE=Bridge
BOOTPROTO=static
ONBOOT=yes
IPADDR=10.0.0.8
NETMASK=255.255.255.0
DELAY=0

Finally, one last file… This will be /etc/sysconfig/network-scripts/route-xenintbr0

10.0.0.0/24 via 10.0.0.8 dev xenintbr0

This tells CentOS to create a route for 10.0.0.0/24 using 10.0.0.8 as the gateway.

After that, you should be able to do a ‘service network restart’ and be done! Any VMs you bring up in SolusVM and bind an internal address to should “just work”. :)

Feb 21

SSH timeouts suck.

Posted on by

So if you’re ever connected to a remote machine (or several), and you frequently see this message after you walk away from your term for a bit…


Write failed: Broken pipe

Do this from the machine you’re connecting from. SSHD for Macs/Linux boxes should all have this file. Windows, I’m not so much sure on.

(if not root already)

sudo echo "ServerAliveInterval 5" >> /etc/ssh_config

Or just open it up in your favorite text editor, save and call it good.

What’s happening here is that somewhere between you and your destination, there’s a long enough of a timeout happening that you hit SSHs internal timeout. This line just forces your SSH client to send a keepalive pulse fairly regularly to the endpoint.

Anyway, dumb quick fix to what ails so many of is.

Dec 07

Adding custom nameservers and a custom gateway to your openstack virtual machines

Posted on by

This took me awhile to figure out today, so I figure it’s worth a post (and we all know I’m WAAAY behind on those!).

The problem I ran into was with an OpenStack (diablo build) instance that we use internally at my work. To make a long story short, I chose to go around the nova-network method of routing and use my own hardware gateway as opposed to using the software appliance provided by the OpenStack setup.

Now, a brief bit of Background here.

1. Openstack is a “Virtualization Fabric”, i.e., a piece of software that ties together hypervisors with a nice API. It handles the networking, connection to the hypervisors, sercurity and let’s you access everything with an API. This is the same software that the Rackspace Cloud is setup and comparable to what VPS.Net uses (onapp.com).

2. Openstack is comprised of components, nova-network handles the networking, routing and firewalling. Nova-api handles the API calls. Nova-scheduler handles all the scheduling. Nova-compute actually interfaces with the hypervisors and creates/manages the VMs with nova-volume providing an EBS style of volume provisioning.

3. When you provision a VM, it automatically routes through the machine you’ve designated to run nova-network, I didn’t like this.

So, I decided to change how the networking on the VMs routes to the public internet. There’s a service called ‘dnsmasq’ that runs on the nova-network machine which hands out IP and basic configuration information to your VMs when they come up. It gives your VMs their IP, Gateway, subnet mask, resolvers and a few other items as well. So here’s, where things needed to change.

Step 1. Know your real network gateway!

Traditionally in an openstack setup, your VMs will route like this…

VM->Nova-network appliance->network gateway->Internet.

I was modifying it to route as follows…

VM->Network Gateway->Internet.

This is handled by adding one line to your nova.conf file, and creating a super basic configuation file to go along with it. By adding ‘–dnsmasq_config_file=/etc/nova/dnsmasq.conf’ to your nova.conf file, and ensuring that /etc/nova/dnsmasq.conf looks like the following snippet, you’ll 1. route through your own gateway, and 2. use your own resolvers.

—-
dhcp-option=6,10.1.100.254
dhcp-option=3,10.1.100.254
—-

dhcp-option 6 should be set to the resolver you want to use, and dhcp-option 3 should be set to the gateway you want to use.

After that, do a ‘killall dnsmasq; /etc/init.d/nova-network restart’, and then restart your instances and you should be good to go!

May 18

Something old, something new, something borrowed, something… Orange?

Posted on by

Guys and Gals,

Awhile back, I had a list of URLs that were handy to me, as an admin. Mailchecker sites that’d hit up SPF/MX/RBL/header checks, DNS verification sites and gimmicky little things like “what is my ip” that’d get used fairly frequently. The sad thing is that the vast majority of my old go-to sites are now gimped in favor of “please pay us”, inundated with ads, or simply gone to hell in a handbasket. What’s an admin to do?

Code. That’s what an admin is to do. :) So I present to you, the very first alpha release of MXReport.com, my site that’ll hopefully contain all of those gimpy little scripts that have been so handy in the past.

The goal of MXReport.com are as follows.

    Fast. It has to be fast.
    Curl/wget/LWPable (or your web autobot dejour).
    Efficient. No bumbling through 234234 menus to find the one little script you want.
    Fast.
    Free (no ads either).
    Open. (github links will be dropped once I get things a bit more under control)
    oh yeah and did I mention, Fast?

With that in mind, please feel free to kick around http://mxreport.com. Is it proper and fully ready? Nah. Does it do all the fancy stuff? Nope. Does it do RBL Checks quickly? Yep! Sure, there’s bugs, which are fairly easy to trip over once you start playing with input, but those should be resolved fairly soon. In the meantime, kick it around and let me know what you think. If you’ve got ideas, please feel free to send them on over.

This isn’t something for me. This is something for Us.

May 17

Woops.

Posted on by

Hey guys, just so you know, I’m in the process of rebuilding and restoring serveradmins.NET. I hit an odd bug on the FreeBSD 7.4->8.2 upgrade which resulted in the default FreeBSD kernel simply not booting due to ACPI issues on this hardware.

As this machine is colo’d far away, and important to have live, I opted for the reinstall and rebuild quickly rather than running down the bug.

Please tolerate the breakage for a little bit, I’ll get you all sorted out quickly. :)

Edit: Done. Things should be good again now, sorry for the url breakage.

Jun 25

XCache 1.3.0 install – with cPanel and CentOS

Posted on by

Hey there!

I figure it’s been a little bit, so I’ve gone ahead and decided to update the XCache installer for version 1.3.0, and my favorite control panel, cPanel. :)

This is incredibly easy to do and should get a basic/barebones XCache installation up and going fairly quickly on your CentOS + cPanel machine.

First, let’s grab our XCache sources…

cd /usr/src/
wget http://xcache.lighttpd.net/pub/Releases/1.3.0/xcache-1.3.0.tar.gz

Now, go ahead and unarchive the source, and change into the XCache build dir…
tar -xzvf xcache-1.3.0.tar.gz
cd xcache-1.3.0

Let’s prep our sources for the current PHP ecosystem…

root@SERVER [/usr/src/xcache-1.3.0]# phpize
Configuring for:
PHP Api Version: 20041225
Zend Module Api No: 20060613
Zend Extension Api No: 220060519

Now that should have gotten everything sorted with our sources so the XCache install is ready for our PHP version and environment, Let’s go ahead and kick off the build! Keep in mind, this build should be fairly fast and lightweight.


./configure && make && make install

The above line basically says “Run configure, if that is successful w/o errors, run a make, and if that finishes w/o error, run the install”. Once this is complete, you should see a line that says something like the following…

Installing shared extensions: /usr/local/lib/php/extensions/no-debug-non-zts-20060613/

This is going to be where our xcache.so file is located, however when cPanel builds your php.ini file, it’s going to have that set already. So getting the base module loaded is as simple as running the following command.

echo "extension=xcache.so" >> /usr/local/lib/php.ini

After that, you should be able to do a quick check of the PHP CLI and verify that it loaded properly with the ‘php -v’ command…

root@SERVER [/usr/src/xcache-1.3.0]# php -v
PHP 5.2.13 (cli) (built: Jun 16 2010 09:27:33)
Copyright (c) 1997-2010 The PHP Group
Zend Engine v2.2.0, Copyright (c) 1998-2010 Zend Technologies
with XCache v1.3.0, Copyright (c) 2005-2009, by mOo

And there you go, you can safely restart Apache now and you should be serving cached content. Please keep in mind, you’ll need to configure your XCache setup to ensure everything is working properly, all we’ve done here is install the base module.

I’d suggest taking a look at our other article regarding the tuning of XCache for a bit more information on this. :)

That does it for now!

May 28

Howto show the current runlevel in linux…

Posted on by

Quick one here, mostly for my own notes than anything else. :)

An easy way to see the existing runlevel is with the ‘who -r’ command.


root@server:~ # who -r
run-level 3 May 22 03:54 last=S

Here we show the last boot and current runlevel (3). In order to modify this, you can open up /etc/inittab and look for the following line.


id:3:initdefault:

This shows that runlevel 3 is the default one kicked off by init on a bootup.

For what it’s worth, this refers to the directories in /etc/rc.d/rcX.d/, where X is #. The number correlates to the runlevel of your machine, and all of the scripts stored in that directory are executed when that runlevel is enabled.

TMYK!

May 14

Howto enable CGI in the builtin OSX webserver

Posted on by

Recently I’ve caught myself writing more code on my Macbook and for the first time in… YEARS, not needing an internet connection to actually be productive. To be quite honest, it’s a bit weird. :)

So, the first thing I wanted was the ability to run/exec CGI via a webserver. At first, I was thinking I’d go about a source build of Apache, and then I remembered OSX comes with one built in. Huzzah!

So, first let’s enable the builtin webserver.

System Preferences -> Sharing, and then click on “Web Sharing”. Go ahead and close out the window now, you’ve just fired off Apache. (hooray!). You should now be able to open your browser of choice and go to http://127.0.0.1/~

Now, the document root is going to be off of your user account in /sites/. My user is chrismm on my machine, so /Users/chrismm/Sites/ is my public HTML. Any web content you want to view with the above URL needs to go off of this directory. Go ahead and add the obligatory "Helloworld.html", I'll wait. :)

Now that that's done and functioning, I needed to get some hawt hawt Perl/CGI action going on. This, was incredibly easy.

OSX's main httpd.conf does a per-user http include in /private/etc/apache2/users/.conf, so once again for me, it was /private/etc/apache2/users/chrismm.conf. This file contains just a super basic Directory configuration for apache to parse and we only need to make one quick change here…

First and foremost, we need to be the root user, so go ahead and open up Terminal (Finder->Applications->Utilities -> Terminal), and type ‘sudo su -’ . Here, you’ll be prompted to enter your password.

Keep in mind as soon as you do this, you are the root user on your machine, ***BE VERY CAREFUL AS IF YOU ARE NOT YOU CAN END UP WITH A WORTHLESS WORKSTATION ***.

Now, go ahead and open up the include for your user, at /private/etc/apache2/users/.conf, and make the following changes.

Original:

maynard:beta root# cat /private/etc/apache2/users/chrismm.conf

Options Indexes MultiViews
AllowOverride None
Order allow,deny
Allow from all

Needs to be changed to....


maynard:beta root# cat /private/etc/apache2/users/chrismm.conf

Options Indexes MultiViews ExecCGI
AllowOverride None
Order allow,deny
Allow from all

See that? All I added was “ExecCGI” at the end of that Options statement. We’re halfway done now!

One more change…

Go ahead and open up ‘/private/etc/apache2/original/httpd.conf’ in your text editor of choice, and search for ” #AddHandler cgi-script .cgi”

Go ahead and remove the ‘#’ mark, save and exit.

Now, let’s restart the webserver…


killall -HUP httpd

Done!

And now, you can use your CGI and be happy. :)