Looking to extend OS respository with IPFS

Hello there Foreman users(And hopefully developers if you're reading this),

I am pretty new to foreman and I am enjoying learning how Foreman works
with various things under the hood. I have reviewed other PXE solutions and
I believe Foreman has the least barrier to entry to start using it, from
everything to the install and the user interface so my colleagues can look
into using it and deploying different OSes. Gotta give credit to the
interface guys. Once I used it a couple days, the layout of where to find
stuff became 2nd nature.

Now on to the fun bits…

My goal right now is to have the Foreman server be able to deploy offline
in the sense that it doesn't need to connect to the internet in order to
deploy an OS. I want it to cache all repo data that the install requests
through the Foreman server itself. From what I've gathered so far is that
Foreman caches the initrd and the vmlinuz just necessary to boot the
initial kernel stuffs. I have not found any evidence that foreman is
actually caching packages and whatnot nor does my network traffic suggest
that Foreman is serving these files although I could be missing something
here. I've searched through the documentation and from what I can discern,
it's not the goal of the Foreman project to decide how to cache this data
for OS deployment in order to overstress the server(My best guess).

Anyway, my solution was to add some lines to a custom kickstart
file(Perhaps this belongs as a snippet? If so, not sure how to go about
this properly). I chose to use an ambitious project's binary (ipfs.io) in
order to add a Centos 7.3.1611 ISO as a repo accessible only over IPFS.
This would require my PXE booting clients to then run this IPFS binary at
some point to then get the remainder of the packages and

Steps to add the Centos 7 ISO to IPFS:

mount centos7.iso /mnt/centos7.3.1611

ipfs add -r /mnt/centos7.3.1611

This gives us a root hash accessible through the local daemonized IPFS
at http://127.0.0.1:8080/ipfs/QmQsiRu98XJACpMXnFvFqd5CvoSJHuoXmwr1WqJEvqHrcu

My thought process was that if Foreman just caches the kernel and PXE boots
it, maybe at some point in the kickstart file I could run the ipfs daemon
to then get the repo data from the IPFS proxy at 127.0.0.1:8080 and as a
biproduct, this would enable me to scale my deployment of 1 server to
potentially thousands using IPFS as a "bittorrent" like deployment. It
solves the local repo problem, primarily, but both are very appealing to me
and would make Foreman better than it is today. Perhaps a plugin would be
better to achieve this but I do not have the forte at the moment to make
this a reality, thus, here is my hacky thought process.

So, here's where my experiment starts:

  1. I already had a kernel cached in /var/lib/tftpboot before doing this
    step, I just cloned my Centos 7.3 repo.

  2. Change the installation media

  3. Add the installation media to the Centos 7 OS as a repo option.

  4. Added these lines to my kickstart file(This is where I believe the
    problem of my implementation
    starts): https://github.com/skloeckner/foreman-ipfs/commit/5f018d2b9a0dae533ae49e4a0445031f1e1aec3c

  5. Change repo from my Centos test machine in Foreman to IPFS repo.

So first boot did not go so well. It PXE'd everything OK until it looked
for the squashfs.img which is the rootfs with all the binaries. Also, where
I placed the lines to run the binary failed as you can see in the
screenshot I provided.

This is where I realized I need a different approach to solve this without
changing how Foreman serves stuff up to PXE clients.

My next thoughts to achieve my goal are this:

  1. Keep the installation media the same so the initial boot process is the
    same until it mounts the squashfs.img root volume containing binaries. I
    believe this makes my goal futile, however, because the rootfs contains
    everything needed for Centos 7, AFAIK.

  2. Embed the ipfs binary in the initramfs somehow? or just wget it in the
    appropriate line in the kickstart location before any additional
    downloading of packages (Would need help where to place this as I'm a
    newbie when it comes to kickstart but I would appreciate a shove in the
    right direction). Then change the Centos repo locations on the fly to point
    to the IPFS locations somehow.

  3. Suck it up and write a plugin before someone else does or just host a
    local repo of Centos 7 to not complicate peer to peer installations.

I would appreciate any input at this point. I figured I would at least
throw this idea out there to extend Foreman and hopefully start some
discussion on this. Stacki does this really well as offloading a lot of the
installation data seems to not stress out Foreman and it doesn't require a
centralized place to be a single point of slowness for deployments when
you're performing many deployments at once.

··· to: http://127.0.0.1:8080/ipfs/QmQsiRu98XJACpMXnFvFqd5CvoSJHuoXmwr1WqJEvqHrcu

I think I may need to dive in deeper into kickstart. Apparently the way it
parses the file, doesn't matter where I put the commands, just as long as
it has %pre in front of it. I am wondering if it mounts the squashfs.img
rootfs for the install by this time, however.

https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/5/html/Installation_Guide/s1-kickstart2-file.html

··· On Thursday, March 30, 2017 at 10:48:22 PM UTC-7, Sean Kloeckner wrote: > > Hello there Foreman users(And hopefully developers if you're reading this), > > I am pretty new to foreman and I am enjoying learning how Foreman works > with various things under the hood. I have reviewed other PXE solutions and > I believe Foreman has the least barrier to entry to start using it, from > everything to the install and the user interface so my colleagues can look > into using it and deploying different OSes. Gotta give credit to the > interface guys. Once I used it a couple days, the layout of where to find > stuff became 2nd nature. > > Now on to the fun bits... > > My goal right now is to have the Foreman server be able to deploy offline > in the sense that it doesn't need to connect to the internet in order to > deploy an OS. I want it to cache all repo data that the install requests > through the Foreman server itself. From what I've gathered *so far* is > that Foreman caches the initrd and the vmlinuz just necessary to boot the > initial kernel stuffs. I have not found any evidence that foreman is > actually caching packages and whatnot nor does my network traffic suggest > that Foreman is serving these files although I could be missing something > here. I've searched through the documentation and from what I can discern, > it's not the goal of the Foreman project to decide how to cache this data > for OS deployment in order to overstress the server(My best guess). > > Anyway, my solution was to add some lines to a custom kickstart > file(Perhaps this belongs as a snippet? If so, not sure how to go about > this properly). I chose to use an ambitious project's binary (ipfs.io) in > order to add a Centos 7.3.1611 ISO as a repo accessible only over IPFS. > This would require my PXE booting clients to then run this IPFS binary at > some point to then get the remainder of the packages and > > Steps to add the Centos 7 ISO to IPFS: > > mount *centos7.iso* /mnt/centos7.3.1611 > > ipfs add -r /mnt/centos7.3.1611 > > This gives us a root hash accessible through the local daemonized IPFS at > http://127.0.0.1:8080/ipfs/QmQsiRu98XJACpMXnFvFqd5CvoSJHuoXmwr1WqJEvqHrcu > > My thought process was that if Foreman just caches the kernel and PXE > boots it, maybe at some point in the kickstart file I could run the ipfs > daemon to then get the repo data from the IPFS proxy at 127.0.0.1:8080 > and as a biproduct, this would enable me to scale my deployment of 1 server > to potentially thousands using IPFS as a "bittorrent" like deployment. It > solves the local repo problem, primarily, but both are very appealing to me > and would make Foreman better than it is today. Perhaps a plugin would be > better to achieve this but I do not have the forte at the moment to make > this a reality, thus, here is my hacky thought process. > > So, here's where my experiment starts: > > 1. I already had a kernel cached in /var/lib/tftpboot before doing this > step, I just cloned my Centos 7.3 repo. > > 2. Change the installation media to: > http://127.0.0.1:8080/ipfs/QmQsiRu98XJACpMXnFvFqd5CvoSJHuoXmwr1WqJEvqHrcu > > 3. Add the installation media to the Centos 7 OS as a repo option. > > 4. Added these lines to my kickstart file(This is where I believe the > problem of my implementation starts): > https://github.com/skloeckner/foreman-ipfs/commit/5f018d2b9a0dae533ae49e4a0445031f1e1aec3c > > 5. Change repo from my Centos test machine in Foreman to IPFS repo. > > So first boot did not go so well. It PXE'd everything OK until it looked > for the squashfs.img which is the rootfs with all the binaries. Also, where > I placed the lines to run the binary failed as you can see in the > screenshot I provided. > > This is where I realized I need a different approach to solve this without > changing how Foreman serves stuff up to PXE clients. > > My next thoughts to achieve my goal are this: > > 1. Keep the installation media the same so the initial boot process is the > same until it mounts the squashfs.img root volume containing binaries. I > believe this makes my goal futile, however, because the rootfs contains > everything needed for Centos 7, AFAIK. > > 2. Embed the ipfs binary in the initramfs somehow? or just wget it in the > appropriate line in the kickstart location before any additional > downloading of packages (Would need help where to place this as I'm a > newbie when it comes to kickstart but I would appreciate a shove in the > right direction). Then change the Centos repo locations on the fly to point > to the IPFS locations somehow. > > 3. Suck it up and write a plugin before someone else does or just host a > local repo of Centos 7 to not complicate peer to peer installations. > > I would appreciate any input at this point. I figured I would at least > throw this idea out there to extend Foreman and hopefully start some > discussion on this. Stacki does this really well as offloading a lot of the > installation data seems to not stress out Foreman and it doesn't require a > centralized place to be a single point of slowness for deployments when > you're performing many deployments at once. >

I would strongly recommend look into Katello. Though you cannot install it
onto an existing Foreman right now :frowning:

https://theforeman.org/plugins/katello/3.3/index.html

··· On Fri, 31 Mar 2017 at 07:29, Sean Kloeckner wrote:

I think I may need to dive in deeper into kickstart. Apparently the way it
parses the file, doesn’t matter where I put the commands, just as long as
it has %pre in front of it. I am wondering if it mounts the squashfs.img
rootfs for the install by this time, however.

https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/5/html/Installation_Guide/s1-kickstart2-file.html

On Thursday, March 30, 2017 at 10:48:22 PM UTC-7, Sean Kloeckner wrote:

Hello there Foreman users(And hopefully developers if you’re reading this),

I am pretty new to foreman and I am enjoying learning how Foreman works
with various things under the hood. I have reviewed other PXE solutions and
I believe Foreman has the least barrier to entry to start using it, from
everything to the install and the user interface so my colleagues can look
into using it and deploying different OSes. Gotta give credit to the
interface guys. Once I used it a couple days, the layout of where to find
stuff became 2nd nature.

Now on to the fun bits…

My goal right now is to have the Foreman server be able to deploy offline
in the sense that it doesn’t need to connect to the internet in order to
deploy an OS. I want it to cache all repo data that the install requests
through the Foreman server itself. From what I’ve gathered so far is
that Foreman caches the initrd and the vmlinuz just necessary to boot the
initial kernel stuffs. I have not found any evidence that foreman is
actually caching packages and whatnot nor does my network traffic suggest
that Foreman is serving these files although I could be missing something
here. I’ve searched through the documentation and from what I can discern,
it’s not the goal of the Foreman project to decide how to cache this data
for OS deployment in order to overstress the server(My best guess).

Anyway, my solution was to add some lines to a custom kickstart
file(Perhaps this belongs as a snippet? If so, not sure how to go about
this properly). I chose to use an ambitious project’s binary (ipfs.io) in
order to add a Centos 7.3.1611 ISO as a repo accessible only over IPFS.
This would require my PXE booting clients to then run this IPFS binary at
some point to then get the remainder of the packages and

Steps to add the Centos 7 ISO to IPFS:

mount centos7.iso /mnt/centos7.3.1611

ipfs add -r /mnt/centos7.3.1611

This gives us a root hash accessible through the local daemonized IPFS at
http://127.0.0.1:8080/ipfs/QmQsiRu98XJACpMXnFvFqd5CvoSJHuoXmwr1WqJEvqHrcu

My thought process was that if Foreman just caches the kernel and PXE
boots it, maybe at some point in the kickstart file I could run the ipfs
daemon to then get the repo data from the IPFS proxy at 127.0.0.1:8080
and as a biproduct, this would enable me to scale my deployment of 1 server
to potentially thousands using IPFS as a “bittorrent” like deployment. It
solves the local repo problem, primarily, but both are very appealing to me
and would make Foreman better than it is today. Perhaps a plugin would be
better to achieve this but I do not have the forte at the moment to make
this a reality, thus, here is my hacky thought process.

So, here’s where my experiment starts:

  1. I already had a kernel cached in /var/lib/tftpboot before doing this
    step, I just cloned my Centos 7.3 repo.

  2. Change the installation media to:
    http://127.0.0.1:8080/ipfs/QmQsiRu98XJACpMXnFvFqd5CvoSJHuoXmwr1WqJEvqHrcu

  3. Add the installation media to the Centos 7 OS as a repo option.

  4. Added these lines to my kickstart file(This is where I believe the
    problem of my implementation starts):
    https://github.com/skloeckner/foreman-ipfs/commit/5f018d2b9a0dae533ae49e4a0445031f1e1aec3c

  5. Change repo from my Centos test machine in Foreman to IPFS repo.

So first boot did not go so well. It PXE’d everything OK until it looked
for the squashfs.img which is the rootfs with all the binaries. Also, where
I placed the lines to run the binary failed as you can see in the
screenshot I provided.

This is where I realized I need a different approach to solve this without
changing how Foreman serves stuff up to PXE clients.

My next thoughts to achieve my goal are this:

  1. Keep the installation media the same so the initial boot process is the
    same until it mounts the squashfs.img root volume containing binaries. I
    believe this makes my goal futile, however, because the rootfs contains
    everything needed for Centos 7, AFAIK.

  2. Embed the ipfs binary in the initramfs somehow? or just wget it in the
    appropriate line in the kickstart location before any additional
    downloading of packages (Would need help where to place this as I’m a
    newbie when it comes to kickstart but I would appreciate a shove in the
    right direction). Then change the Centos repo locations on the fly to point
    to the IPFS locations somehow.

  3. Suck it up and write a plugin before someone else does or just host a
    local repo of Centos 7 to not complicate peer to peer installations.

I would appreciate any input at this point. I figured I would at least
throw this idea out there to extend Foreman and hopefully start some
discussion on this. Stacki does this really well as offloading a lot of the
installation data seems to not stress out Foreman and it doesn’t require a
centralized place to be a single point of slowness for deployments when
you’re performing many deployments at once.


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.

Hey Sean, nice name.

Thanks for mentioning Katello, I have no idea how I managed to overlook
this plugin.

What do you mean you cannot install it onto an existing foreman? You mean
an existing install? Do you have to install it right when you install
foreman or include it into the installer command line?

··· On Friday, March 31, 2017 at 12:49:31 AM UTC-7, Sean O'Keeffe wrote: > > I would strongly recommend look into Katello. Though you cannot install it > onto an existing Foreman right now :( > > https://theforeman.org/plugins/katello/3.3/index.html > > On Fri, 31 Mar 2017 at 07:29, Sean Kloeckner > wrote: > >> I think I may need to dive in deeper into kickstart. Apparently the way >> it parses the file, doesn't matter where I put the commands, just as long >> as it has %pre in front of it. I am wondering if it mounts the squashfs.img >> rootfs for the install by this time, however. >> >> >> https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/5/html/Installation_Guide/s1-kickstart2-file.html >> >> >> On Thursday, March 30, 2017 at 10:48:22 PM UTC-7, Sean Kloeckner wrote: >>> >>> Hello there Foreman users(And hopefully developers if you're reading >>> this), >>> >>> I am pretty new to foreman and I am enjoying learning how Foreman works >>> with various things under the hood. I have reviewed other PXE solutions and >>> I believe Foreman has the least barrier to entry to start using it, from >>> everything to the install and the user interface so my colleagues can look >>> into using it and deploying different OSes. Gotta give credit to the >>> interface guys. Once I used it a couple days, the layout of where to find >>> stuff became 2nd nature. >>> >>> Now on to the fun bits... >>> >>> My goal right now is to have the Foreman server be able to deploy >>> offline in the sense that it doesn't need to connect to the internet in >>> order to deploy an OS. I want it to cache all repo data that the install >>> requests through the Foreman server itself. From what I've gathered *so >>> far* is that Foreman caches the initrd and the vmlinuz just necessary >>> to boot the initial kernel stuffs. I have not found any evidence that >>> foreman is actually caching packages and whatnot nor does my network >>> traffic suggest that Foreman is serving these files although I could be >>> missing something here. I've searched through the documentation and from >>> what I can discern, it's not the goal of the Foreman project to decide how >>> to cache this data for OS deployment in order to overstress the server(My >>> best guess). >>> >>> Anyway, my solution was to add some lines to a custom kickstart >>> file(Perhaps this belongs as a snippet? If so, not sure how to go about >>> this properly). I chose to use an ambitious project's binary (ipfs.io) >>> in order to add a Centos 7.3.1611 ISO as a repo accessible only over IPFS. >>> This would require my PXE booting clients to then run this IPFS binary at >>> some point to then get the remainder of the packages and >>> >>> Steps to add the Centos 7 ISO to IPFS: >>> >>> mount *centos7.iso* /mnt/centos7.3.1611 >>> >>> ipfs add -r /mnt/centos7.3.1611 >>> >>> This gives us a root hash accessible through the local daemonized IPFS >>> at >>> http://127.0.0.1:8080/ipfs/QmQsiRu98XJACpMXnFvFqd5CvoSJHuoXmwr1WqJEvqHrcu >>> >>> My thought process was that if Foreman just caches the kernel and PXE >>> boots it, maybe at some point in the kickstart file I could run the ipfs >>> daemon to then get the repo data from the IPFS proxy at 127.0.0.1:8080 >>> and as a biproduct, this would enable me to scale my deployment of 1 server >>> to potentially thousands using IPFS as a "bittorrent" like deployment. It >>> solves the local repo problem, primarily, but both are very appealing to me >>> and would make Foreman better than it is today. Perhaps a plugin would be >>> better to achieve this but I do not have the forte at the moment to make >>> this a reality, thus, here is my hacky thought process. >>> >>> So, here's where my experiment starts: >>> >>> 1. I already had a kernel cached in /var/lib/tftpboot before doing this >>> step, I just cloned my Centos 7.3 repo. >>> >>> 2. Change the installation media to: >>> http://127.0.0.1:8080/ipfs/QmQsiRu98XJACpMXnFvFqd5CvoSJHuoXmwr1WqJEvqHrcu >>> >>> 3. Add the installation media to the Centos 7 OS as a repo option. >>> >>> 4. Added these lines to my kickstart file(This is where I believe the >>> problem of my implementation starts): >>> https://github.com/skloeckner/foreman-ipfs/commit/5f018d2b9a0dae533ae49e4a0445031f1e1aec3c >>> >>> 5. Change repo from my Centos test machine in Foreman to IPFS repo. >>> >>> So first boot did not go so well. It PXE'd everything OK until it looked >>> for the squashfs.img which is the rootfs with all the binaries. Also, where >>> I placed the lines to run the binary failed as you can see in the >>> screenshot I provided. >>> >>> This is where I realized I need a different approach to solve this >>> without changing how Foreman serves stuff up to PXE clients. >>> >>> My next thoughts to achieve my goal are this: >>> >>> 1. Keep the installation media the same so the initial boot process is >>> the same until it mounts the squashfs.img root volume containing binaries. >>> I believe this makes my goal futile, however, because the rootfs contains >>> everything needed for Centos 7, AFAIK. >>> >>> 2. Embed the ipfs binary in the initramfs somehow? or just wget it in >>> the appropriate line in the kickstart location before any additional >>> downloading of packages (Would need help where to place this as I'm a >>> newbie when it comes to kickstart but I would appreciate a shove in the >>> right direction). Then change the Centos repo locations on the fly to point >>> to the IPFS locations somehow. >>> >>> 3. Suck it up and write a plugin before someone else does or just host a >>> local repo of Centos 7 to not complicate peer to peer installations. >>> >>> I would appreciate any input at this point. I figured I would at least >>> throw this idea out there to extend Foreman and hopefully start some >>> discussion on this. Stacki does this really well as offloading a lot of the >>> installation data seems to not stress out Foreman and it doesn't require a >>> centralized place to be a single point of slowness for deployments when >>> you're performing many deployments at once. >>> >> -- >> 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-user...@googlegroups.com . >> To post to this group, send email to forema...@googlegroups.com >> . >> Visit this group at https://groups.google.com/group/foreman-users. >> For more options, visit https://groups.google.com/d/optout. >> >

> Hey Sean, nice name.
>
> Thanks for mentioning Katello, I have no idea how I managed to overlook
> this plugin.
>
> What do you mean you cannot install it onto an existing foreman? You mean
> an existing install? Do you have to install it right when you install
> foreman or include it into the installer command line?
>

You can't install Foreman and then add the Katello plugin into it. Instead
you need to follow the instructions on the link below to install it

··· On Fri, 31 Mar 2017 at 23:25, Sean Kloeckner wrote:

On Friday, March 31, 2017 at 12:49:31 AM UTC-7, Sean O’Keeffe wrote:

I would strongly recommend look into Katello. Though you cannot install it
onto an existing Foreman right now :frowning:

Foreman :: Plugin Manuals

On Fri, 31 Mar 2017 at 07:29, Sean Kloeckner seankl...@gmail.com wrote:

I think I may need to dive in deeper into kickstart. Apparently the way it
parses the file, doesn’t matter where I put the commands, just as long as
it has %pre in front of it. I am wondering if it mounts the squashfs.img
rootfs for the install by this time, however.

https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/5/html/Installation_Guide/s1-kickstart2-file.html

On Thursday, March 30, 2017 at 10:48:22 PM UTC-7, Sean Kloeckner wrote:

Hello there Foreman users(And hopefully developers if you’re reading this),

I am pretty new to foreman and I am enjoying learning how Foreman works
with various things under the hood. I have reviewed other PXE solutions and
I believe Foreman has the least barrier to entry to start using it, from
everything to the install and the user interface so my colleagues can look
into using it and deploying different OSes. Gotta give credit to the
interface guys. Once I used it a couple days, the layout of where to find
stuff became 2nd nature.

Now on to the fun bits…

My goal right now is to have the Foreman server be able to deploy offline
in the sense that it doesn’t need to connect to the internet in order to
deploy an OS. I want it to cache all repo data that the install requests
through the Foreman server itself. From what I’ve gathered so far is
that Foreman caches the initrd and the vmlinuz just necessary to boot the
initial kernel stuffs. I have not found any evidence that foreman is
actually caching packages and whatnot nor does my network traffic suggest
that Foreman is serving these files although I could be missing something
here. I’ve searched through the documentation and from what I can discern,
it’s not the goal of the Foreman project to decide how to cache this data
for OS deployment in order to overstress the server(My best guess).

Anyway, my solution was to add some lines to a custom kickstart
file(Perhaps this belongs as a snippet? If so, not sure how to go about
this properly). I chose to use an ambitious project’s binary (ipfs.io) in
order to add a Centos 7.3.1611 ISO as a repo accessible only over IPFS.
This would require my PXE booting clients to then run this IPFS binary at
some point to then get the remainder of the packages and

Steps to add the Centos 7 ISO to IPFS:

mount centos7.iso /mnt/centos7.3.1611

ipfs add -r /mnt/centos7.3.1611

This gives us a root hash accessible through the local daemonized IPFS at
http://127.0.0.1:8080/ipfs/QmQsiRu98XJACpMXnFvFqd5CvoSJHuoXmwr1WqJEvqHrcu

My thought process was that if Foreman just caches the kernel and PXE
boots it, maybe at some point in the kickstart file I could run the ipfs
daemon to then get the repo data from the IPFS proxy at 127.0.0.1:8080
and as a biproduct, this would enable me to scale my deployment of 1 server
to potentially thousands using IPFS as a “bittorrent” like deployment. It
solves the local repo problem, primarily, but both are very appealing to me
and would make Foreman better than it is today. Perhaps a plugin would be
better to achieve this but I do not have the forte at the moment to make
this a reality, thus, here is my hacky thought process.

So, here’s where my experiment starts:

  1. I already had a kernel cached in /var/lib/tftpboot before doing this
    step, I just cloned my Centos 7.3 repo.

  2. Change the installation media to:
    http://127.0.0.1:8080/ipfs/QmQsiRu98XJACpMXnFvFqd5CvoSJHuoXmwr1WqJEvqHrcu

  3. Add the installation media to the Centos 7 OS as a repo option.

  4. Added these lines to my kickstart file(This is where I believe the
    problem of my implementation starts):
    https://github.com/skloeckner/foreman-ipfs/commit/5f018d2b9a0dae533ae49e4a0445031f1e1aec3c

  5. Change repo from my Centos test machine in Foreman to IPFS repo.

So first boot did not go so well. It PXE’d everything OK until it looked
for the squashfs.img which is the rootfs with all the binaries. Also, where
I placed the lines to run the binary failed as you can see in the
screenshot I provided.

This is where I realized I need a different approach to solve this without
changing how Foreman serves stuff up to PXE clients.

My next thoughts to achieve my goal are this:

  1. Keep the installation media the same so the initial boot process is the
    same until it mounts the squashfs.img root volume containing binaries. I
    believe this makes my goal futile, however, because the rootfs contains
    everything needed for Centos 7, AFAIK.

  2. Embed the ipfs binary in the initramfs somehow? or just wget it in the
    appropriate line in the kickstart location before any additional
    downloading of packages (Would need help where to place this as I’m a
    newbie when it comes to kickstart but I would appreciate a shove in the
    right direction). Then change the Centos repo locations on the fly to point
    to the IPFS locations somehow.

  3. Suck it up and write a plugin before someone else does or just host a
    local repo of Centos 7 to not complicate peer to peer installations.

I would appreciate any input at this point. I figured I would at least
throw this idea out there to extend Foreman and hopefully start some
discussion on this. Stacki does this really well as offloading a lot of the
installation data seems to not stress out Foreman and it doesn’t require a
centralized place to be a single point of slowness for deployments when
you’re performing many deployments at once.


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-user...@googlegroups.com.
To post to this group, send email to forema...@googlegroups.com.

Visit this group at https://groups.google.com/group/foreman-users.
For more options, visit https://groups.google.com/d/optout.


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.