oh, and now's probably a good time to get an SSD
=)
On Thu, Feb 28, 2013 at 2:13 PM, Sean OMeara < "> > wrote:
> I have it working on mine... you'll need to
>
> I have mine set to 10.9.8.1
>
> a) set up the local /etc/hosts
> b) hack your bento defs to stick the same line in your /etc/hosts
> (ks.cfg for centos, etc)
> c) set up local software mirrors for full effect
> d) reap the awesome.
>
> misc notes -
>
> - list clients
> knife client list -k admin.pem -u admin -s https://localhost
>
> - add a client
> b vagrant ssh -c 'sudo bash -c "export EDITOR=`which cat` ; knife
> client create developer-laptop -a -k /etc/chef-server/admin.pem -u
> admin -s https://localhost -f /etc/chef-server/developer-laptop.pem"
> 2>&1>/dev/null'
>
> - delete client
> b vagrant ssh -c 'sudo bash -c "export EDITOR=`which cat` ; knife
> client delete -y developer-laptop -k /etc/chef-server/admin.pem -u
> admin -s https://localhost" 2>&1>/dev/null'
>
> - get client.pem
> b vagrant ssh -c 'sudo cat /etc/chef-server/developer-laptop.pem' >
> /opt/chef/dev.lap/.chef/developer-laptop.pem
>
> - get validator
> b vagrant ssh -c 'sudo cat /etc/chef-server/chef-validator.pem' >
> /opt/chef/dev.lap/.chef/chef-validator.pem
>
> enjoy!
>
> -s
>
> On Thu, Feb 28, 2013 at 1:59 PM, Cassiano Leal < "> > wrote:
>> I'm trying to run a chef-server on a vagrant VM for local development. Not
>> very worried about SSL working properly as long as I can use it. :)
>>
>> Still, apart from receiving a warning of a name mismatch, what else will
>> break in that case?
>>
>> - cassiano
>>
>> On Thursday, February 28, 2013 at 15:52, Sean OMeara wrote:
>>
>> You need to have a CN that matches the FQDN of your chef-server for
>> SSL to work properly.
>> -s
>>
>> On Thu, Feb 28, 2013 at 1:37 PM, Jesse Campbell < "> > wrote:
>>
>> that is what happens for me, yes.
>>
>> if i connect to http://chef-app01.ops.sub.domain (default port 80), it
>> redirects me to https://chef-app01.ops (default port 443), which doesn't
>> exist... but if i connect directly to https://chef-app01.ops.sub.domain, it
>> works fine.
>>
>> it would be great if it didn't break on redirect, but I don't know where the
>> code is to fix that...
>>
>>
>> On Thu, Feb 28, 2013 at 1:23 PM, Cassiano Leal < "> >
>> wrote:
>>
>>
>> Are you saying that the redirection only occurs if I hit http, not https?
>> That would be helpful.
>>
>> - cassiano
>>
>> On Thursday, February 28, 2013 at 15:07, Jesse Campbell wrote:
>>
>> A more normal redirect pattern I have seen is to save the host name from
>> the request parameter and simply change the scheme from http to https...
>>
>> here's how we do it on an F5:
>>
>> HTTP::redirect https://[HTTP::host][HTTP::uri]
>>
>> I'm not sure off hand what the proper syntax is for nginx or apache, but
>> it should be straightforward
>>
>> -Jesse
>>
>>
>> On Thu, Feb 28, 2013 at 12:36 PM, Cassiano Leal < "> >
>> wrote:
>>
>> Out of curiosity, why redirect in the first place? :)
>>
>> - cassiano
>>
>> On Thursday, February 28, 2013 at 14:06, Adam Jacob wrote:
>>
>> It's a reasonable default for most situations – the alternative is to use
>> the IP Address, which is actively icky as well.
>>
>> Adam
>>
>> From: Cassiano Leal < "> >
>> Reply-To: " "> " < "> >
>> Date: Thursday, February 28, 2013 7:01 AM
>> To: " "> " < "> >
>> Subject: [chef] chef-server on a VM
>>
>> Ohai Chefs,
>>
>> Why does the omnibus chef-server deb not work by default on a VM?
>>
>> I'm following http://docs.opscode.com/chef/install_server_scenario_vm.html
>> but at the end, if I hit the webserver on port 80 it redirects me to the
>> VM's hostname, which is obviously not accessible from outside of the VM
>> unless I edit my hostsfile.
>>
>> I'm wondering why it's set like that by default; it seems like an
>> anti-pattern. Also, how do I change this behaviour?
>>
>> Other than that, the omnibus package is a breeze to install. Fantastic
>> job!
>>
>> - cassiano
>>
>>
Archive powered by MHonArc 2.6.16.