John T Skarbek Reading time ~1 minute

I came across something that threw me for a loop today.  I needed to modify sudoers so that I can help secure a service account to execute a script as a different user.  So here’s my config that was dropped in /etc/sudoers.d/somefile

Cmd_Alias THISCOMMAND = /path/to/the/script
serviceaccount ALL = (otheruser) NOPASSWD: THISCOMMAND
Defaults!THISCOMMAND !requiretty

Nothing out of the ordinary, but when validating the command, sudo fails with an error message:

[root@hostname ~]# sudo -l -U serviceaccount
sudo: >>> /etc/sudoers.d/somefile: syntax error near line 3 <<< 
sudo: parse error in /etc/sudoers.d/somefile near line 3
sudo: no valid sudoers sources found, quitting
sudo: unable to initialize policy plugin

Checking and rechecking the man page and sudo documentation lead me no where.  I even moved this config information into visudo, which worked fine.  So I KNOW my syntax is correct.  Long story short, sudo is expecting a new line in the file.  After throwing a new line in the config, all is well.  Here’s the diff:

@@ -1,3 +1,3 @@
 Cmnd_Alias THISCOMMAND = /path/to/the/script
serviceaccount ALL = (otheruser) NOPASSWD: THISCOMMAND
-Defaults!THISCOMMAND !requiretty
\ No newline at end of file
+Defaults!THISCOMMAND !requiretty

After that, validating sudo returned what I expected it too.

I’m not the only person that has seen this either:

John T Skarbek Reading time ~1 minute

The Problem:

After executing the puppet agent, things break when a package is trying to install, because the apt sources list is out of date.

My Example:

Here’s an example manifest with some attempts at creating a specified order. Check it out:

class play {
 class { "apt":
    always_apt_update =&gt; true,
    before =&gt; Class["mysql"],
  }
  class { "mysql":
    require =&gt; Class["apt"],
  }
  Class["apt"] -&gt; Class["mysql"]
}

When the puppet agent is first run the mysql class does not complete because apt-get needs to update.  When viewing the logs it is apparent that puppet continues to try to run the install for mysql first despite my attempts at pushing it down the list.

The Reason for Failure:

Puppet is unable to maintain resource ordering with complex modules.  Both the apt and the mysql modules have nested classes where puppet does not assign the resource order to the inner class.  When this happens, puppet behaves the way it wants.

The Solution:

Staging. Here’s an example

class play {
  stage { 'first':
    always_apt_update =&gt; true,
    before =&gt; Stage["main"],
  }
  class { "apt":
    stage =&gt; first
 }
  class { "mysql": }
}

There’s only one stage created by default, “main.”  We are now telling puppet to “pre stage,” if you will, the apt class before the “main” stage runs.

Now if one steps back and thinks about it (without all this resource ordering jibberish), if puppet is run a second time, of course it will work, cuz during the first run, eventually puppet does run the apt module to complete it’s task, putting the system in a better state.  But this is not preferred.  Subsequently, if the apt sources list goes out of date later, it will take yet another run before puppet is successful.

Must Reads:

John T Skarbek Reading time ~1 minute

UPDATE:

Thanks for tip. However as per JMeter 2.11 it’s quite enough to use just one Response Assertion, erroneous HTTP status code is being ignored, but the assertion checks the response for any patterns defined and if some condition is not met the sampler is being marked as failed. See How to Use JMeter Assertions in 3 Easy Steps guide for more details.

I recently picked up jmeter and writing a test looking for 401 errors produced from the server.  In my particular case I wanted jmeter to recognize that as a specific error that is valid.  The problem is that by default any 4xx or 5xx error is noted as a problem right off the bat.  Due to this we need to a bit of extra work in order for jmeter to tell me that 401 is a valid response for my test.  To make this work, one needs to add TWO Response Assertations.

The first Assertation you need to configure the ‘Ignore Status’ to true.  This might seem convoluted because you need to look for the 401, but we’ll tackle that in the next Response Assertation.   We ignore the status because jmeter processes responses in a specific order, the first assertation would be ignored because jmeter sensed the error.  If we were to put the pattern of 401 in this one, it would never be tested for.

The second assertation is then configured to test the ‘Response Code’ containing a 401.  This assertation will look at the response code and return an OK status for this test like we expect.

Results from this test are exactly what I needed to prove the 401 from the server was being triggered appropriately.

John T Skarbek Reading time ~1 minute

Yet again, I’m speaking about something that I had fail to install on my workstation.

The error message:

http_proxy not set. please set environment variable 'http_proxy' e.g. export
http_proxy=http://myproxy.mydomain.com:0000 .
ftp_proxy not set. please set environment variable 'ftp_proxy' e.g. export
ftp_proxy=http://myproxy.mydomain.com:0000 .

Unfortunately I do not run a proxy in my environment. I’m not sure why they don’t make this easier it insists on this, but it fails out. To fix this I did this:

export http_proxy=1
export ftp_proxy=1

(This works cuz I’ve looked at the source, where they have a bunch of if statements that look to ensure this is set.)

After more issues, I discovered I needed more dependencies in order to get this installed. Here’s the list overall:

  • libssl-dev
  • perl-doc
  • libxml-libxml-perl
  • uuid-dev

I, however, did have to install a package using cpan cuz the installer failed, however if you run through the above dependencies first, you should be okay. Regardless of struggling with this, I still had issues:

The following Perl modules were found on the system but may be too old to work
with vSphere CLI:

Compress::Zlib 2.037 or newer
Compress::Raw::Zlib 2.037 or newer
IO::Compress::Base 2.037 or newer
IO::Compress::Zlib::Constants 2.037 or newer

But vmware-cmd appears to work ok.

This was accomplished using the latest version of vmware-cli and ubuntu at the time of this writing.

UPDATE:

On my Centos 6.3 system, I ran into the following issue:

cpan[1]> install UUID
<snip>
CPAN.pm: Building L/LZ/LZAP/UUID-0.05.tar.gz

Checking if your kit is complete...
Looks good
Writing Makefile for UUID
Writing MYMETA.yml and MYMETA.json
cp UUID.pm blib/lib/UUID.pm
/usr/bin/perl /usr/share/perl5/ExtUtils/xsubpp -typemap /usr/share/perl5/ExtUtils/typemap UUID.xs > UUID.xsc && mv UUID.xsc UUID.c
gcc -c -D_REENTRANT -D_GNU_SOURCE -fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexcepti
ons -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -DVERSION=\"0.05\" -DXS_VERSION=\"0.05\" -fPIC "-I/usr/lib64/perl5/CORE" UUID.c
UUID.xs:5:23: error: uuid/uuid.h: No such file or directory
<snip>
UUID.xs:30: warning: unused variable ‘str’
make: *** [UUID.o] Error 1
LZAP/UUID-0.05.tar.gz
/usr/bin/make -- NOT OK
Running make test

Can't test without successful make

Running make install
Make had returned bad status, install seems impossible
Failed during this command:
LZAP/UUID-0.05.tar.gz : make NO

In order to fix this crap, you’ll need to install yet another library:

libuuid-devel

Resources:

John T Skarbek Reading time ~1 minute

July’s presentation is courtesy of our very own John Skarbek. John will giving an exciting talk on what he has learned since he started using Vagrant.

Summary: Greet the guy that is going to help you put together, very quickly, a single machine or an entire environment for which you can develop/test something that can be made portable, easily reproducible, highly customizable, and light on the resources. Make a sysadmins life easier and develop locally and build a solution that easily be shared with the community.

  • Date: Wednesday, July 3rd
  • Time: 7-9pm