A trivial scenario. We had the following location declared to test if the server is reachable:

location = /ping {
    return 204;
}

We have decided that we want to protect it with the same auth_request logic we have for other endpoints, which work and are contained within the same server {} block. We simply added the auth_request directive but both attempts have failed:

This one always returns 204, even when the auth_request returns 401/403:

location = /ping {
    auth_request /validate;
    return 204;
}

which is somewhat of a surprise, given the documented behaviour for auth_request, I assumed it would simply stop processing further directives:

If the subrequest returns a 2xx response code, the access is allowed. If it returns 401 or 403, the access is denied with the corresponding error code.

A second attempt to directly return the auth_request's status directly also didn't work:

location = /ping {​​​​​​​​
    auth_request /validate;
    auth_request_set    $auth_status        $upstream_status;
    return $auth_status;
}​​​​​​​​

as it fails with

[emerg] invalid return code "$auth_status" in /etc/nginx/conf.d/default.conf:157

The problem seems related to my use of return? I have seen nginx auth_request how to return backend status code but it doesn't appear to address my situation.

Attempting to use Puppet to install PostgreSQL 9.5 on an Ubuntu Trusty, using all the documentation I could find, with the following simple class structure:

  class { 'postgresql::globals':
    manage_package_repo => true,
    version             => '9.5'
  }
  ->
  class { 'postgresql::server':
    ip_mask_allow_all_users => '0.0.0.0/0',
    listen_addresses        => '*',
    postgres_password       => '',
    encoding                => 'UTF-8',
    locale                  => 'en_US.UTF-8',
  }

I encounter the following fatal error:

==> default: Debug: Automatically imported postgresql::server::database_grant from postgresql/server/database_grant into production
==> default: Error: validate_re(): "B97B0AFCAA1A47F044F244A07FCC7D46ACCC4CF8" does not match ["\\A(0x)?[0-9a-fA-F]{8}\\Z", "\\A(0x)?[0-9a-fA-F]{16}\\Z"] at /tmp/vagrant-puppet/modules-964288a1df1d89c6bf2b0015dc43c600/apt/manifests/key.pp:60 on node vagrant.local
==> default: Error: validate_re(): "B97B0AFCAA1A47F044F244A07FCC7D46ACCC4CF8" does not match ["\\A(0x)?[0-9a-fA-F]{8}\\Z", "\\A(0x)?[0-9a-fA-F]{16}\\Z"] at /tmp/vagrant-puppet/modules-964288a1df1d89c6bf2b0015dc43c600/apt/manifests/key.pp:60 on node vagrant.local

I have tried

Adding package_name => 'postgresql-9.5' to ::globals, to no avail.

In an act of desperation, even:

  exec {'Add postgresql 9.5 key':
    command => '/usr/bin/wget --quiet -O - https://www.postgresql.org/media/keys/ACCC4CF8.asc | sudo /usr/bin/apt-key add -',
    user    => 'root'
  }
  ->
  exec {'Add postgresql 9.5 apt':
    command  => '/bin/echo "deb http://apt.postgresql.org/pub/repos/apt/ trusty-pgdg main" >> /etc/apt/sources.list.d/postgresql.list',
    user     => 'root'
  }
  ->
  exec {'apt-get update':
    command  => '/usr/bin/apt-get update',
    user     => 'root'
  }
  ->
  class { 'postgresql::globals':
  ...

I noticed that B97B0AFCAA1A47F044F244A07FCC7D46ACCC4CF8 corresponds to postgresql 9.3: it seems something is not getting updated in the correct sequence.

Scenario

We use a Vagrant-based virtual machine running Ubuntu 12.04 LTS for development of three Node.JS servers that are started using foreverjs. We run the services under the vagrant user and mount the projects from the host to the virtual machine as shared folders.

When starting a script with forever, it will fork to the background after starting, maintaining a central list of all scripts running (per user). For scripts that use different names, you can reference them by name as well as a numeric index.

Scripts are then managed (started, restarted, stopped, etc) using the forever command.

Upstart configuration

I have created similar upstart conf files for each service thusly:

description "Control server.js"

chdir /vagrant/server

start on vagrant-mounted

stop on runlevel [016]

expect fork

pre-start script
  test -d /vagrant/server
end script

exec sudo su vagrant -c "/usr/local/bin/forever start server.js"

Problem — hangs on shutdown

The upstart successfully starts the service once the vagrant shared folder has mounted. However, shutting down the virtual machine (i.e., vagrant halt) hangs until it times out and force-shuts-down the VM.

I assume this is because it doesn't know how to stop the forever service, since forever is merely an interface to the services I actually want to stop.

My only attempt didn't work (it does stop the service, but the Vagrant hangs to timeout):

pre-stop script
  forever stop server.js
end script

The node services do not need to terminate gracefully: I would be happy with any scenario that kills the scripts but does not cause the Vagrant to hang on shutdown.

Also, removing the stop on runlevel line seems to have no effect.

A puppet novice, I'm currently working on a deployment script that will start a couple of foreverjs services from rc.local at boot time.

My concern is that, in Ubuntu, rc.local comes with an exit 0 at the bottom of the file.

I don't see a way of using stdlib's file_line directive to ensure that my lines appear above the exit command (or anywhere else in particular, should the need arise).

I can do it with an exec block and some ugly sed, but there must be a more standard, elegant way in puppet?

Testing performance improvements, I added an .htaccess file with the following directives to my /assets folder (where I store a few images of various types).

<FilesMatch "\.(jpg|jpeg|png|gif)$">
  Header set Cache-Control "public,max-age=7200"
</FilesMatch>

Looking at ySlow's output, it bizarrely shows me this:

Resource                        Expires
/assets/slide-1.jpg             2012/5/22
/assets/partners/part_01.gif    2012/5/22
/assets/partners/spacer.gif     2010/4/15

Inspecting spacer.gif's header, I note that the one gif has both my Cache-Control: public,max-age=7200 header and an Expires: Thu, 15 Apr 2010 20:00:00 GMT header, whereas all of the other images in the folder respect the max-age header and have no explicit expiration header.

I'm certain that there are no other filename-specific cache-control directives at play. I used to have a cache-busting in-the-past-expiration-date header in the web root, but that's since been removed, and seems not to be 'sticky' for any of the other files.

Why might this be?