Boot disk based imaging, katello capsule in the DMZ - server still needs access to main katello srv?

Hi all,

I have installed a Katello capsule (wellcapsuletst.niwa.co.nz) into our
DMZ, added lifecycle environments to it and synced content -

hammer capsule content add-lifecycle-environment --environment-id 2 --id 5
hammer capsule content add-lifecycle-environment --environment-id 4 --id 5
hammer capsule content add-lifecycle-environment --environment-id 8 --id 5
hammer capsule content add-lifecycle-environment --environment-id 9 --id 5
hammer capsule content add-lifecycle-environment --environment-id 7 --id 5
hammer capsule content synchronize --async -id 5

I then added new installation media via Hosts > Installation media, and
assigned that to operating systems via Hosts > Operating Systems > CentOS7
> Installation Media

Next, I tried deploying a new VM into the DMZ using bootdisk based imaging,
pointing at the capsule for content -
On the hosts tab:

  • content source was the new capsule
    On the Operating system tab
  • provisioning method = bootdisk based
  • media selection was "all media"
  • media = the new capsule media source

The VM was created fine, but it is still trying to download something from
the main katello server (which it can't get to because of firewall rules) -

http://wellkatellotst.niwa.local/unattended/iPXE?=token=4fa1e41e-00d0-a67a-2821f09e3e59&mac=00%3A50%3A56%3A85%3A27%3A7b…Connection
timed out

I thought the idea of a capsule was that all provisioning/content could be
handled by the capsule - am I doing something wrong? Using the spoof
address to inspect the kickstart file
(https://servername/unattended/provision?spoof=xxx.xxx.xxx.xxx)
I can't see any mention of wellkatellotst.niwa.local (the internal katello
server), and the install URL is set to the capsule -

install
url --url http://wellcapsuletst.niwa.co.nz/pulp/repos/NIWA/Library/custom/CentOS7/os_x86_64/

Have I missed something?

Thanks heaps!

Dylan

When you say you added installation media, did you add it manually or did
you sync a kickstart repository?

Eric

··· On Wed, Jul 6, 2016 at 11:28 PM, Dylan Baars wrote:

Hi all,

I have installed a Katello capsule (wellcapsuletst.niwa.co.nz) into our
DMZ, added lifecycle environments to it and synced content -

hammer capsule content add-lifecycle-environment --environment-id 2 --id 5
hammer capsule content add-lifecycle-environment --environment-id 4 --id 5
hammer capsule content add-lifecycle-environment --environment-id 8 --id 5
hammer capsule content add-lifecycle-environment --environment-id 9 --id 5
hammer capsule content add-lifecycle-environment --environment-id 7 --id 5
hammer capsule content synchronize --async -id 5

I then added new installation media via Hosts > Installation media, and
assigned that to operating systems via Hosts > Operating Systems > CentOS7

Installation Media

Next, I tried deploying a new VM into the DMZ using bootdisk based
imaging, pointing at the capsule for content -
On the hosts tab:

  • content source was the new capsule
    On the Operating system tab
  • provisioning method = bootdisk based
  • media selection was “all media”
  • media = the new capsule media source

The VM was created fine, but it is still trying to download something from
the main katello server (which it can’t get to because of firewall rules) -

http://wellkatellotst.niwa.local/unattended/iPXE?=token=4fa1e41e-00d0-a67a-2821f09e3e59&mac=00%3A50%3A56%3A85%3A27%3A7b…Connection
http://wellkatellotst.niwa.local/unattended/iPXE?=token=4fa1e41e-00d0-a67a-2821f09e3e59&mac=00%3A50%3A56%3A85%3A27%3A7b.................Connection
timed out

I thought the idea of a capsule was that all provisioning/content could be
handled by the capsule - am I doing something wrong? Using the spoof
address to inspect the kickstart file
(https://servername/unattended/provision?spoof=xxx.xxx.xxx.xxx)
I can’t see any mention of wellkatellotst.niwa.local (the internal katello
server), and the install URL is set to the capsule -

install
url --url http://wellcapsuletst.niwa.co.nz/pulp/repos/NIWA/Library/custom/CentOS7/os_x86_64/

Have I missed something?

Thanks heaps!

Dylan


You received this message because you are subscribed to the Google Groups
"Foreman users" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to foreman-users+unsubscribe@googlegroups.com.
To post to this group, send email to foreman-users@googlegroups.com.
Visit this group at https://groups.google.com/group/foreman-users.
For more options, visit https://groups.google.com/d/optout.


Eric D. Helms
Red Hat Engineering
Ph.D. Student - North Carolina State University

I added it manually as it didn't appear - possible it doesn't even exist
:slight_smile: How do I sync the existing kickstart repo to the capsule?

··· On Friday, July 8, 2016 at 6:29:23 AM UTC+12, Eric Helms wrote: > > When you say you added installation media, did you add it manually or did > you sync a kickstart repository? > > >

This is what I'm currently seeing in the installation media (I've removed
my manually created one)

<https://lh3.googleusercontent.com/-7XsZ0155aYs/V37Sh7LEwlI/AAAAAAAAHSs/I0yRlvoxTXMqm39KbADf3SEJuPA_T6EwQCLcB/s1600/Capture.JPG>
Here is the available life-cycle environments for the capsule

—|---------------------------|----------------------------------------|--------------------------
[root@wellkatellotst ~]# hammer capsule content
available-lifecycle-environments --id 5
—|--------------|---------------------

ID NAME ORGANIZATION
2 Library NIWA
5 Test-Desktop NIWA
3 VMware Host NIWA
6 Prod-Desktop NIWA
1 Library Default Organization
7 Dev-Server NIWA
9 Prod-Server NIWA
8 Test-Server NIWA
4 Kickstart NIWA
-------------- ---------------------

I have synced everything except the *-Desktop environments

Having read a bit about the installation media, it looks like if Katello
detects there is installation media available, it should be automatically
created. I checked under "Manage organizations" > NIWA, > Media, but there
is no new media available other than the existing
"NIWA/Library/Centos7/os_x86_64" media (which is already a "selected item"

So I guess I'm asking how do I make installation media available on the
capsule?

Thanks for your help!
Dylan

Any suggestions?

Thanks :slight_smile:

··· On Friday, July 8, 2016 at 10:11:13 AM UTC+12, Dylan Baars wrote: > > > > So I guess I'm asking how do I make installation media available on the > capsule? > > Thanks for your help! > Dylan >

Some more information:

I have confirmed that the capsule path:
http://wellcapsuletst.niwa.co.nz/pulp/repos/NIWA/Library/custom/CentOS7/os_x86_64/

does exist, and has the same synced media content as the main katello
server (
http://wellkatellotst.niwa.local/pulp/repos/NIWA/Library/custom/CentOS7/os_x86_64/)
After adding it manually to Installation Media, assigning to
locations/organization and rebooting, the media is visible if I manage the
organization > Media tab.

<https://lh3.googleusercontent.com/-6Smp96RpF5g/V4LG31BKSEI/AAAAAAAAHTo/Ii9MeLG2K-M1woMaQtjF8Tu2aLAjyKdMgCLcB/s1600/organization_media.JPG>

I then assigned the media to locations (DMZ networks).

<https://lh3.googleusercontent.com/-1Xuxy6O5uko/V4LITi-VJ6I/AAAAAAAAHT0/BxSp1xiRXPwLO45eahInPgcDVMeAYdzzgCLcB/s1600/location_media.JPG>

But if I attempt to create a new VM, deploying a new VM into the DMZ using
bootdisk based imaging, pointing at the capsule for content -
On the hosts tab:

  • content source was the new capsule
    On the Operating system tab
  • provisioning method = bootdisk based
  • media selection was "all media"
  • media = the new capsule media source

The VM was created fine, but it is still trying to download something from
the main katello server (which it can't get to because of firewall rules) -

http://wellkatellotst.niwa.local/unattended/iPXE?=token=4fa1e41e-00d0-a67a-2821f09e3e59&mac=00%3A50%3A56%3A85%3A27%3A7b…Connection
<http://wellkatellotst.niwa.local/unattended/iPXE?=token=4fa1e41e-00d0-a67a-2821f09e3e59&mac=00%3A50%3A56%3A85%3A27%3A7b…Connection> timed
out

The installation media is there and available/visible, but the bootdisk
being created is using the wrong installation source?

It is trying to download the kickstart file from the main katello server.
Inspecting the kickstart file using the spoof address, everything in the
kickstart is pointing at the capsule address for content etc,

https://wellkatellotst.niwa.local/unattended/provision?spoof=192.168.228.7

but there is no equivalent (kickstart provisioning address) on the capsule
in the DMZ. I created an HTTP hole for a test VM to the katello server,
booted and it started working - all content is downloaded from the capsule
in the DMZ, but the kickstart file is stored on the main server. Is there a
way to have the kickstart file be created and presented on the capsule that
the server is being built from? Shall I submit a feature request?

> The installation media is there and available/visible, but the bootdisk
> being created is using the wrong installation source?

Which bootdisk are you using?

Have you tried Subnet bootdisk? That should do it via capsule.

··· -- Later, Lukas #lzap Zapletal

Hi Lukas,

not sure how/where I specify that? These are the "Templates resolved for
this operating system" on the Operating System tab of a "New Host"

PXELinux Template: Kickstart default PXELinux
finish Template: Katello Kickstart Default Finish
iPXE Template: Kickstart default iPXE
provision Template: NIWA Kickstart
user_data Template: Katello Kickstart Default User Data

Under Host > Provisioning Templates, if I do a search for "Kind = Bootdisk"
only two are listed:
Bootdisk iPXE - generic host
Bootdisk iPXE - host

but I'm not sure how (or which) of these are chosen given the templates
resolved above?

Thanks for your help :slight_smile:
Dylan

··· On Monday, July 11, 2016 at 8:23:46 PM UTC+12, Lukas Zapletal wrote: > > > The installation media is there and available/visible, but the bootdisk > > being created is using the wrong installation source? > > Which bootdisk are you using? > > Have you tried Subnet bootdisk? That should do it via capsule. > > -- > Later, > Lukas #lzap Zapletal >

Solved! I had to

  1. Install a tftp-server on the smart proxy - yum install tftp-server
  2. Enable tftp on the smart proxy, edit
    /etc/foreman-proxy/settings.d/tftp.yml and change ":enabled: false" to
    ":enabled: true"
  3. Add a couple of firewall rules
    firewall-cmd --permanent --zone=public --add-port="69/udp"
    firewall-cmd --permanent --zone=public --add-port="8000/tcp"
  4. On the web interface of katello, Infrastructure > Smart Proxies >
    Refresh features on the capsule
  5. Infrastructure > Subnets, select the relevant subnet(s) > Proxies > Set
    "TFTP proxy" to the capsule

Done!