Monday, April 28, 2014

Sunday, April 27, 2014

SaltStack iptables states just don’t seem to work (at least in CentOS 6.5)

The iptables state would be freakin awesome to be able to use. http://ift.tt/1isIDgB


The only iptables state stuff I can get to work is the iptables.append, and even then it, well, always appends, even if the rule is already there. It doesn’t seem there is any way to tell it to only append the rule if that exact rule is not already in there.


Ideally, the iptables states would let you define very readable iptables rules. Each time you run state.highstate for a machine, it would enforce your defined state rules. This would be fantastic for me, since I want to by default deny all traffic. Then I want to allow some globally-applicable inbound rules, say, for SSH from the salt master. Then, I want to allow 80 and 443 for only web servers (define those particular rules in the init.sls for the web servers group). Then, I want to allow 9200:9300 for just the elasticsearch machines.


Oh well. I have to continue to use static iptables files for each group of machines. It’s kinda lame having to add some inbound SSH rule, but I suppose it’s a good step or two better than logging in to each machine and adding it that way. Besides, doing it through salt implicitly documents your iptables configs in a central location.


The docs seem to be either wrong or out of date.


iptables.flush doesn’t work (example from an init.sls file):


flush-iptables:

iptables.flush


Here’s the error after running a state.highstate:

———-

ID: flush-iptables

Function: iptables.flush

Result: False

Comment: An exception occurred in this state: Traceback (most recent call last):

File “/usr/lib/python2.6/site-packages/salt/state.py”, line 1372, in call

self.verify_ret(ret)

File “/usr/lib64/python2.6/contextlib.py”, line 34, in __exit__

self.gen.throw(type, value, traceback)

File “/usr/lib/python2.6/site-packages/salt/utils/context.py”, line 43, in func_globals_inject

yield

File “/usr/lib/python2.6/site-packages/salt/state.py”, line 1371, in call

**cdata['kwargs'])

File “/usr/lib/python2.6/site-packages/salt/states/iptables.py”, line 487, in flush

if not __salt__['iptables.flush'](kwargs['table'], kwargs['chain'], family):

KeyError: ‘table’


Here’s a sample of an iptables.append block that works, but note, if you run “salt ‘*’ state.highstate” you will end up with 2 of the same rule in your iptables rules. Run it 32 times? Yup, you will have 32 iptables rules, each identical:


ssh-from-managementserver:

iptables.append:

– chain: INPUT

– proto: tcp

– connstate: NEW

– jump: ACCEPT

– source: 8.8.8.8 #put in a real IP here

– dport: 22

– table: filter

– match: state

– save: True


here’s a sample of an iptables.append block that does NOT work (taken from docs page). The problem seems to be when you try to add a comment:


httpd2:

iptables.append:

– table: filter

– chain: INPUT

– jump: ACCEPT

– match:

– state

– comment

– comment: “Allow HTTP”

– connstate: NEW

– source: ‘! 127.0.0.1′

– dport: 80

– proto: tcp

– sport: 1025:65535

– save: True


Here’s the error:

———-

ID: httpd2

Function: iptables.append

Result: False

Comment: An exception occurred in this state: Traceback (most recent call last):

File “/usr/lib/python2.6/site-packages/salt/state.py”, line 1372, in call

self.verify_ret(ret)

File “/usr/lib64/python2.6/contextlib.py”, line 34, in __exit__

self.gen.throw(type, value, traceback)

File “/usr/lib/python2.6/site-packages/salt/utils/context.py”, line 43, in func_globals_inject

yield

File “/usr/lib/python2.6/site-packages/salt/state.py”, line 1371, in call

**cdata['kwargs'])

File “/usr/lib/python2.6/site-packages/salt/states/iptables.py”, line 233, in append

rule = __salt__['iptables.build_rule'](family=family, **kwargs)

File “/usr/lib/python2.6/site-packages/salt/modules/iptables.py”, line 135, in build_rule

kwargs['match'].replace(‘ ‘, ”)

AttributeError: ‘list’ object has no attribute ‘replace’





Thursday, April 24, 2014

How to Update OpenVPN Access Server on CentOS

Linux Observations from a bit of a Noob

So this is a bit of an embarrassing post. I still consider myself a bit of a Linux noob. Most of what I’ve done with Linux has been because I had to use it for one thing or another. I’ve never really embraced the OS as something I enjoy messing around with. I’m a Windows guys – mostly because Windows is where all the games are.


How do you “install” stuff in Linux? The overwhelming impression I’ve gotten over time is that there are no installers (yes, there’s YUM and apt-get and others). However, step-by-step tutorials on how to install things in Linux seem to overrepresent the “build it from source” mindset. Just do a search for “install nagios”. *Maybe* you’ll find the post that says, in CentOS, type “yum install nagios.*”. The typical post seems to be an 18-page arcane dissertation.


I know I could be wrong. I’m wrong about stuff more often than I am comfortable with. But with Linux I fairly constantly feel there is some orientation session that everyone else attended but I missed.





Wednesday, April 23, 2014

This is how I want to use Salt Stack and Nagios plugins for server monitoring

This blog post by Russel Ballestrini is in the direction of using Salt for at least part of your infrastructure management systems.


http://ift.tt/1f8H2lk


For system monitoring, I’d like to be able to run “salt ‘*’ cmd.run….” commands periodically. Have Nagios/Icinga plugins on the minions that get called by the Salt commands. Dump the output straight into an elasticsearch cluster and then do stuff with it from there.


I reason is that I’ve found Nagios and Icinga to be really really complex to set up and configure. Why not remove the need to set that up and just do a lot of the work with Salt? Alert thresholds, alerting systems, statistical stuff would be something to still figure out (yeah, really easy, that).


Maybe this is just roll-your-own pie in the sky thinking, but it sure would be nice to be able to use Salt for management as well as the monitoring/scheduling engine.





Friday, April 18, 2014

Windows Storage Spaces: Warning separated from pool; reset drive

“Warning separated form pool; reset drive”


That really just means the drive was disconnected and the Storage Pool software doesn’t want to simply assume it should clobber whatever is there with what “should” be there, based on the storage pool config.


So, in my case, I just clicked the “reset” option and everything was happy.


Interestingly, this storage pool was created on a Windows Server 2012 box and the drives were moved over to a Windows 8.1 machine.





Tuesday, April 15, 2014

WordPress 3.8.3 fixes the bug where your Draft posts disappear

Good fix :) I can paste in draft posts on the dashboard without them getting shot off into the ether.





Monday, April 14, 2014

Install Kibana3

Setting up an Elasticsearch Cluster

Programatically change a logging target’s path and file name for NLog

Programatically change a logging target’s path and file name for NLog. Figured I’d put this out there in case it speeds up someone’s learning process. This is in C#.


FileTarget target = LogManager.Configuration.FindTargetByName(“file”) as FileTarget;

String logfile = “somepath” + “/some_name.txt”;

target.FileName = logfile;


From: http://ift.tt/1hFLQix





Sunday, April 13, 2014

Logstash 1.4 and Elasticsearch 1.1.x

Forwarding logs to Logstash 1.4 with rsyslog (working nginx logs too)

Wednesday, April 9, 2014

Upgrade OpenVPN Access Server in CentOS

Get link to the latest OpenVPN-AS package for your OS here: http://ift.tt/1g8Pmwl

1. wget http://ift.tt/1lRihMN

2. rpm -Uvh openvpn-as-2.0.6-CentOS6.x86_64.rpm

3. service openvpnas restart


If you originally installed it that way (which I most wholeheartedly recommend), it’ll detect it should do an upgrade rather than a full install. It’ll be done in a few seconds.


Some reference:


http://ift.tt/1g8Pmwm


http://ift.tt/1lRifEH (for Debian/Ubuntu)





WordPress 3.8.2 Breaks QuickDraft blog posts

When you type out a blog post in the “QuickDraft” widget on the Dashboard it disappears after you click “Save Draft”.





How do you Patch the Heartbleed Vulnerability?

How do you fix the Heartbleed bug on a server? In short, update the OpenSSL package and then reboot the machine.


Most Linux OS distributions have fixed versions of OpenSSL released to their package management systems, so you can now just update the easy way.


For Fedora/CentOS:

yum update openssl*


For Debian/Ubuntu:

apt-get install openssl


Here’s a detailed write up on this process:


http://ift.tt/1kHUlaE


Just to post it again, here’s a web site that lets you check if a web site is still vulnerable:


http://ift.tt/1kkYl58





“HeartBleed’ vulnerability – what it means for you

In short, as an end-user, you can’t do anything except refrain from going to web sites that are vulnerable (check with this tool: http://ift.tt/1kkYl58). I bet someone will make a browser extension for that. Maybe Google will push an update to Chrome, for instance, that checks the site for the vulnerability before displaying the “safe https” stuff in the URL bar.


If you want to use a web site that is vulnerable, try to contact the owner and ask them to update the OpenSSL package on their servers.


You’re going to want to change your passwords. But not yet. You’re going to have to wait until after servers get updated to fix the bug.


Here’s another post on the topic:


http://ift.tt/1itdY4K





Tuesday, April 8, 2014

“Heartbleed” vulnerability/bug in OpenSSL

Here’s a tool to test web sites to see if they have the Heartbleed vulnerability:


http://ift.tt/1kkYl58


For fun, try putting in “facebook.com” and “bankofamerica.com”. If you see “yellow submarine” in the text block that appears, it means the web site is vulnerable.


This bug is nasty. Effectively, anyone can directly see various chunks of server memory… and keep pulling different chunks until they’ve got something interesting. It’s sort of like a free slot machine, only as a hacker you can create as many slot machines as you want!


You can see the source code of the above web site here:


http://ift.tt/1mXHe6J





Monday, April 7, 2014

You know those “security vulnerabilities” you hear about… well, this is a bad one

Apparently, the internet has not been quite as secure as we had thought, not for the past year or so anyways. There’s a bug in the software that makes “https” secure. An attacker can see all encrypted traffic on a server in real time. Chances are many of the web sites you visit use an affected version of OpenSSL.


The affected scenario is if an attacker targeted a bank’s web site and picked up usernames and passwords that were entered during his capture session.


http://heartbleed.com/


http://ift.tt/1imrMww