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 <[email protected] > <javascript:>> 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] <javascript:>. >> To post to this group, send email to [email protected] >> <javascript:>. >> 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.
