allaryin's questions

I have a Men & Mice (8.2.2) installation managing DNS (bind) on our internal networks. We use Route53 for public DNS. M&M 8.2 added better cloud integration, so I am attempting to connect the two. No dice. The M&M docs are completely unhelpful on the subject.

Regardless of the credentials I use when attempting to configure an AWS service account from the M&M console, the error message is the same - a timeout trying to establish connection "Unable to connect to endpoint."

The M&M central server can see AWS just fine - I even installed the AWS cli tools on the host and can perform Route53 actions with the IAM credentials I want to eventually use. Rudimentary packet sniffing on the server does show some encrypted traffic going out to AWS when I try to configure things (but I've not tried to go any deeper than that).

Does anyone have experience with M&M's cloud service integration? Is there some super obvious first step that I need to take first, or some better way to debug this process?

So I have a 16tb raid6 on one of a new batch of machines I am setting up. I will be using LVM on top of this and am wondering if there are any compelling reasons to break the raid up into partitions first or any compelling reasons not to.

I know that if I want to use different volume groups in lvm I'll need different physical volumes... but I don't know if that really matters a whole lot here.

The OS is installed on a separate 2tb raid1.

Regardless of what I do, Nginx keeps breaking my url's. I believe this only occurs when the response contains a redirect. I believe I have tried every combination of suggestions from the wiki and the first 20 or so pages on google by now to no avail.

My configuration looks something like this:

upstream tomcat {
    server 10.0.0.1:8080;
}
upstream opsview {
    server 127.0.0.1:3000;
}

server {
    listen 80;
    server_name example.com;

    location / {
        proxy_pass     http://tomcat/;
        proxy_redirect http://tomcat/ /;
        server_name_in_redirect off;

        proxy_set_header  Host       $host;
        proxy_set_header  X-Real-IP  $remote_addr;
        proxy_set_header  X-Forwarded-For  $proxy_add_x_forwarded_for;
    }
}

I have tried:

1. both upstreams (and they behave differently)
2. passing and redirecting directly to the ip:port instead of to an upstream
3. with and without trailing slashes
4. proxy_redirect off
5. with and without the server_name_in_redirect off
6. with and without the header directives

The error cases that keep coming back:

• If proxying to an external host, I am liable to find my browser literally redirected to http://tomcat/.
• If proxying to another service on the same host, I am liable to find my browser redirected to the other port: http://example.com:3000/.

What on earth am I doing wrong?

I have a branch office behind a Watchguard XTM that needs VPN into an EC2 VPC. I am unfamiliar with Watchguard and am unable to find all of the knobs and dials in the flash admin interface to bring it in line with Amazon's expectations.

After much ui frustration, I managed to create configurations for both expected tunnels that meet most of the specified criteria - as I was unable to locate some settings like MTU and ESP options but I have the correct PSK, PFS settings, and am telling it to use SHA1 and AES128 as requested. Attempts to access EC2 private addresses from the office generate a bunch of debug spam as is expected. However, IKE fails with:

Debug   2011-05-31T23:40:45 Process=iked  msg=Process 5/6 Msg : failed to process ID payload

For obvious reasons, I haven't even started trying to configure BGP throught the tunnel.

At this point, I am wondering if it is even proven possible to configure l2l into VPC with a Watchguard firewall? If so, where might I be going wrong?

I am converting a legacy Apache server to Nginx and do not have the luxury of changing URL's or rearranging the filesystem.

Is it possible to use nested location{} blocks in the Nginx configuration to tell it to feed the .php files in an aliased directory to fastcgi while serving static content normally?

Similar configuration to what fails me:

server {
  listen 80;

  location / {
    index  index.html;
  }

  location /foosite/ {
    alias  /var/aliases/foo;
    location ~ \.php$ {
      include fastcgi_params;
      fastcgi_param   SCRIPT_FILENAME $document_root$fastcgi_script_name;
    }
  }
}

Requests for /foosite/static.jpg are served fine, but nginx appears to garble the path to any .php files when attempting to dispatch them to fastcgi.