How to Proxy Chef Server with Apache, simpler setup

Chef Infra (archive)
1

Hi all,

I have a somewhat simpler apache setup than the one featured on the Wiki. It has the advantage of requiring only the default https port for both API and WebUI access.
mod_rewrite points to the right merb instance based on the existence of the X-Chef-Version header presented by API clients.
To keep things simple, the merb instances serves all content. Apache just proxies it all without serving public content.
Do you think it is ok to edit the wiki page with this example?

Best Regards
Miguel Cabeça

<VirtualHost *:443>
ServerName server_fqdn
DocumentRoot /var/www

LogLevel info
ErrorLog /var/log/apache2/chef_server-error.log
CustomLog /var/log/apache2/chef_server-access.log combined

SSLEngine On
SSLCertificateFile /etc/chef/certificates/server_fqdn.pem
SSLCertificateKeyFile /etc/chef/certificates/server_fqdn.pem

ProxyRequests Off
<Proxy *>
Order deny,allow
Allow from all

RequestHeader set X_FORWARDED_PROTO ‘https’

RewriteEngine on
RewriteCond %{HTTP:X-Chef-Version} .
RewriteRule ^/(.) http://localhost:4000/$1 [P]
RewriteRule ^/(.) http://localhost:4040/$1 [P]

2

On 28 June 2010 18:53, Miguel Cabeça cabeca@ist.utl.pt wrote:

Hi all,

I have a somewhat simpler apache setup than the one featured on the Wiki. It has the advantage of requiring only the default https port for both API and WebUI access.
mod_rewrite points to the right merb instance based on the existence of the X-Chef-Version header presented by API clients.

I like this approach, but I wonder if the API genuinely insists on
X-Chef-Version and rejects requests from, say, badly-written clients -
despite the header being documented as required. Perhaps it might be
more predictable to rely on a header that's absolutely essential to
API access: one of those in mixlib/authentication/signedheaderauth.rb:
X-Ops-Sign, X-Ops-Userid, X-Ops-Timestamp or X-Ops-Content-Hash?

Regards,
Jonathan

Jonathan Matthews
London, UK
http://www.jpluscplusm.com/contact.html