On Fri, 31 Mar 2017 at 23:25, Sean Kloeckner <[email protected]> wrote:
> 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 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 <[email protected]> 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 [email protected]. > To post to this group, send email to [email protected]. > > > 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 [email protected]. > To post to this group, send email to [email protected]. > 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 [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/foreman-users. For more options, visit https://groups.google.com/d/optout.
