Maybe this is the wrong place to post, but I’m having a bit of trouble testing out a chef-server cookbook run (I’m using the off-the-shelf chef server cookbook, but supplying my own attributes in my cookbook).
I installed ChefDK and was up in running really quickly (massive kudos on that!). And within a minute I was running “kitchen converge” and I had a chef-server in a local vm (using the vagrant driver and the chef-zero provisioner).
In my kitchen.yml file, I have the following:
platforms:
name: centos-7.2
driver:
network:
[“forwarded_port”, {guest: 80, host: 8080}]
[“forwarded_port”, {guest: 8000, host: 8888}]
[“forwarded_port”, {guest: 443, host: 443}]
I logged into the vm and created an org (set aside the validation.pem) and a user (set aside that user.pem) and have them properly configured in my knife.rb file.
However, now, from my workstation, I want to berks upload a different cookbook. Berks upload fails stating it cannot connect to localhost on 443, “knife ssl check” responds with:
WARNING: No knife configuration file found
Connecting to host localhost:443
ERROR: Network Error: Connection refused - connect(2) for “localhost” port 443
Check your knife configuration and network settings
The warning is weird because further down, it seems it CAN find the knife.rb.
Anyway - any hints/suggestions? Any support would be greatly appreciated (even if it’s to tell me to go to some other forum).
However, even doing 8443 and 8080 (for 443 and 80 respectively), there’s nothing visible via a browser anywhere.
Also - is there some magic to make berkshelf successfully use a self signed cert? Again - my current testing is to bring up a chef server and “berks upload” to it. After stumbling around and issuing the correct incantations with knife, knife doesn’t have any more problems, however, it doesn’t seem like berks respects the .chef/trusted_certs prior to version 5.3.0.
Is this a matter of upgrading my chefdk installation or can I independently upgrade berkshelf within chefdk’s environment?
I accomplished this by updating the gem with chef gem update --no-user-install berkshelf, editing /opt/chefdk/bin/berks, changing any reference to version 5.1.0 to 5.3.0. This is likely not the best way and if the newer chefdk has this version of the gem I'd be inclined to just update the whole thing.
Unfortunately we have "real" certs on our Chef servers so I don't have an easy way to check this. The berkshelf configuration file does allow you to turn off verification- maybe try that and see if you get further along:
Yeah - I tried the ssl verify (which can be passed in on the command line) to no avail. It seems like I just can’t turn this off with berkshelf 5.2.0.
Thanks for the feedback - wondering - if you’re a chefdk user, you too could kitchen converge the chef-server cookbook, then (after the org/user creation) try uploading a cookbook.
Seems like this berkshelf “fix” (in 5.3.0) is relatively new, meaning, no new chefdk release since.
Actually scratch all of this - "knife cookbook upload " also fails to work:
ERROR: Connection refused connecting to https://server-centos-72/bookshelf/organization-....., retry 1/5
I just get that over and over. What’s really strange is, I can create a databag, I can create an environment, but I can NOT upload any cookbooks. Any suggestions? Really stuck here…
The Chef Server generates URLs where cookbook files should be uploaded to, and sends those to knife or whatever tool you're using. I'm guessing your Chef Server is configured with an incorrect FQDN so it's generating bad URLs. This would show up as the Connection refused connecting to part of the error message referring to an incorrect URL.
Thanks a TON for replying - getting to the bottom of my rope here
On the VM (which is local to my workstation - using chefdk/kitchen to provision this thing), I can see that “hostname” and the /etc/hosts file on the VM correctly have the hostname set as “server-centos-72”.
Where else should I be poking? The VM seems to THINK that’s it’s hostname :-/
Oh, right. Looking through the earlier messages in the thread and rereading the error message, the hostname could be correct but the port is probably not. Connection refused means that the machine running knife can resolve an IP for a host with that name and whatever host that is, is up, but it's not listening on the port you wanted, which in this case is 443.
You probably need to tune bookshelf['external_url'] in your chef-server.rb to make it work with your networking configuration. chef-server.rb Optional Settings
Huh - bookshelf - I wonder - how do I just disable that entirely?
For this particular test, I don’t need it (local storage is fine). Somewhere in my wrapper cookbook, I’ll add an “if vagrant” type environmental check and then programattically disable that.
Seems like with the VIP removed and the enable still set to false, it still is trying to pass through my aws key - so I’ll assume it’s still trying (somewhere) to use bookshelf.