Bootstrapping a node without internet access


#1

I see reference to this in the documentation, but am unclear how it might
be accomplished. Anyone with a link to a tutorial or guide on how this is
to be accomplished?


Locking chef-client version after updating
#2

I have been dealing with this issue as well. Here are some of the things I
have been working on:

  1. Created an internal web server to allow wget of Chef RPM and
    installation script and then install locally.

    Install Chef Client from Our Repo

    cd /tmp
    wget http://chefserver:4002/chef/chef-11.8.2-1.el6.x86_64.rpm
    yum install -y chef-11.8.2-1.el6.x86_64.rpm

  2. We have our own internal yum repository for Red Hat.

  3. In the process of building our own gem server and configure gem to use
    it instead of rubygems. Still having problems with this, but it is lack of
    time rather than a technical issue.

We had tried to chase down all the IPs that could be used to fetch these
resources. But it seems to be an ever changing list.

Using an internal source also ensures consistency of the versions of
software installed. I had found that the zk gem, for example, had changed
and was incompatible with other components.

JOHN HASTY
Software as a Service - DevOps
Software Group

Phone: 1-512-804-9968 IBM
E-mail: jahasty@us.ibm.com
2407 S Congress Ave Ste E-350
Austin, TX 78704
United States

From: Kenneth Barry kbarry-x@tunein.com
To: chef@lists.opscode.com,
Date: 02/24/2014 10:16 AM
Subject: [chef] Bootstrapping a node without internet access.

I see reference to this in the documentation, but am unclear how it might
be accomplished. Anyone with a link to a tutorial or guide on how this is
to be accomplished?


#3

On 2/24/14 8:16 AM, Kenneth Barry wrote:

I see reference to this in the documentation, but am unclear how it
might be accomplished. Anyone with a link to a tutorial or guide on
how this is to be accomplished?
if you’ve got your own internal kickstart server and yum repo then you
could simply download the chef client RPMs and put them in your repo and
then have your ks.cfg install and configure the client. you don’t
necessarily need to use bootstrap.

if all your servers are uniform (you only use RHEL6 or Ubuntu 12.04 or
whatever) then you don’t really need all the machinery of install.sh
which has its own mini-ohai and then uses a webservice to find the
latest chef client to install. you can pin the distros that you use and
pin the chef-client versions that you use and write your own simplified
bootstrap scripts that just wget/curl the package you like and then
install and bootstrap it. if you have your chef-client packages
accessible somewhere that both your public and private clouds can find
it (or a list of URLs that you can plow through until you get one that
doesn’t error because of firewalls) then you can have one knife
bootstrap script that works across all your clouds, but without needing
install.sh

i wouldn’t try porting install.sh directly to your internal
infrastructure since it relies on the omnitruck API. its been mentioned
that we should ship omnitruck with enterprise chef (nee private chef)
along with some scripts to sync our packages from S3 down to a repo
sitting on the internal EC server, but that’s never bubbled up to the
top of things to do.


#4

I’ll keep this in mind re: our Linux stuff, but we are also about 60%
Win…

On Mon, Feb 24, 2014 at 11:25 AM, Lamont Granquist lamont@opscode.comwrote:

On 2/24/14 8:16 AM, Kenneth Barry wrote:

I see reference to this in the documentation, but am unclear how it
might be accomplished. Anyone with a link to a tutorial or guide on how
this is to be accomplished?

if you’ve got your own internal kickstart server and yum repo then you
could simply download the chef client RPMs and put them in your repo and
then have your ks.cfg install and configure the client. you don’t
necessarily need to use bootstrap.

if all your servers are uniform (you only use RHEL6 or Ubuntu 12.04 or
whatever) then you don’t really need all the machinery of install.sh which
has its own mini-ohai and then uses a webservice to find the latest chef
client to install. you can pin the distros that you use and pin the
chef-client versions that you use and write your own simplified bootstrap
scripts that just wget/curl the package you like and then install and
bootstrap it. if you have your chef-client packages accessible somewhere
that both your public and private clouds can find it (or a list of URLs
that you can plow through until you get one that doesn’t error because of
firewalls) then you can have one knife bootstrap script that works across
all your clouds, but without needing install.sh

i wouldn’t try porting install.sh directly to your internal infrastructure
since it relies on the omnitruck API. its been mentioned that we should
ship omnitruck with enterprise chef (nee private chef) along with some
scripts to sync our packages from S3 down to a repo sitting on the internal
EC server, but that’s never bubbled up to the top of things to do.


#5

We rolled a series of custom bootstrap templates to handle this use case on
our end. We have a mirror of the opscode packages on an HTTP endpoint, and
we have our custom bootstrap templates pull from there rather than the
internet. We are also heavily windows biased at the current time.

On Mon, Feb 24, 2014 at 3:28 PM, Kenneth Barry kbarry-x@tunein.com wrote:

I’ll keep this in mind re: our Linux stuff, but we are also about 60%
Win…


#6

The pxe_dust cookbook has a pair of recipes for mirroring installers
and creating a local bootstrap template to your mirror.

Thanks,
Matt Ray
Cloud Integrations Product Lead :: Chef
512.731.2218 :: matt@getchef.com
mattray :: GitHub :: IRC :: Twitter

On Mon, Feb 24, 2014 at 12:38 PM, David Petzel davidpetzel@gmail.com wrote:

We rolled a series of custom bootstrap templates to handle this use case on
our end. We have a mirror of the opscode packages on an HTTP endpoint, and
we have our custom bootstrap templates pull from there rather than the
internet. We are also heavily windows biased at the current time.

On Mon, Feb 24, 2014 at 3:28 PM, Kenneth Barry kbarry-x@tunein.com wrote:

I’ll keep this in mind re: our Linux stuff, but we are also about 60%
Win…


#7

On 2/24/14 12:28 PM, Kenneth Barry wrote:

I’ll keep this in mind re: our Linux stuff, but we are also about 60%
Win…

Can you bake in the chef-client MSI into whatever you’re using to
provision your O/S images (WDS?).


#8

Mind sharing those template? How did you go about mirroring the OpsCode packages?

Thanks,
Bernie

From: David Petzel [mailto:davidpetzel@gmail.com]
Sent: Monday, February 24, 2014 3:39 PM
To: chef@lists.opscode.com
Subject: [chef] Re: Re: Re: Bootstrapping a node without internet access.

We rolled a series of custom bootstrap templates to handle this use case on our end. We have a mirror of the opscode packages on an HTTP endpoint, and we have our custom bootstrap templates pull from there rather than the internet. We are also heavily windows biased at the current time.

On Mon, Feb 24, 2014 at 3:28 PM, Kenneth Barry <kbarry-x@tunein.commailto:kbarry-x@tunein.com> wrote:
I’ll keep this in mind re: our Linux stuff, but we are also about 60% Win…