Hello everyone, We (the Anaconda installer team) want to solve multiple problems by one solution and we want *YOUR FEEDBACK!* In short we are proposing to use custom repo files when configuring Anaconda for image creation instead of adding even more complexity to the kickstart repo command. For more details see the link below. Purpose of this mail is to give everyone interested in the topic a place to discuss our proposal to find out if we didn't miss something or better case, if you agree with it :). It could be that this is not applicable for Lorax / Pungi / live-cd tool in that case please write a response to the document.

Hi James, On Tue, 2019-09-17 at 09:57 -0400, James Cassell wrote: > In general, I'd prefer to extend the ks repo command. > > My main concern is that the original-ks.cfg or anaconda-ks.cfg might > no longer provide a complete description of how a particular system > was installed, so it'd like that info exposed on the installed system > somehow. It's not really related. What we are talking here about is to add repo files in the installation environment. The output kickstart file will be the same as before. What will change is the environment used for the installation.

> As for implementation, perhaps base64 zlib compressed. repo passed as > a cmdline arg would be useful to avoid having to create updates.img. > Could also be done as --repofilecontent for the repo command. Personally, I'm not really sure what would be the benefit here. Also you have a limitation on what you can pass in the kernel command line so I guess having 3 repo files this way is a no-go.

> I think it's already possible to place a .repo file from ks %pre? Yes it is. However, you have to do that manually and download gpg keys and certificates somewhere (which is not secure in general).

You also have to pre-build your filesystems to have a place to copy the files into at installation time. If you're going to go to that much work, why are you bothering with yum? Why not just pre-build and install a base operating system, which is much, much faster and notably more network efficient than pulling down and installing RPMs? I've installed roughly..... 20,000 hosts this way in my career, it works really well for clusters.

On Tue, Sep 17, 2019 at 03:09:01PM +0200, jkonecny(a)redhat.com wrote: > Hello everyone, > > We (the Anaconda installer team) want to solve multiple problems by > one > solution and we want > > *YOUR FEEDBACK!* > > > In short we are proposing to use custom repo files when configuring > Anaconda for image creation instead of adding even more complexity > to > the kickstart repo command. For more details see the link below. > > Purpose of this mail is to give everyone interested in the topic a > place to discuss our proposal to find out if we didn't miss > something > or better case, if you agree with it :). It could be that this is > not > applicable for Lorax / Pungi / live-cd tool in that case please > write a > response to the document. > > You can read details here: > > https://hackmd.io/@prJIqOTeSxC-W0RNGKIGbQ/ByzIz3kIH/edit > > Please, all the relevant comments should stay in the document if > possible. If that solution won't work because of higher traffic > then we > will find a better solution but the point is to have everything on > one > place. Sorry, I really don't like the hackmd.io thing, we regularly use email for discussions like this and should continue the discussion on the feoora-devel list.

With an updates.img solution like you are describing here is there anything to be done? Can't it already drop new repos into /etc/yum.repos.d/ or /etc/anaconda.repos.d/ ?

With my lmc patch for certs I am doing something like this, but only with the cert files, not the repo files. updates.img https://github.com/weldr/lorax/pull/839

From the perspective of lmc no-virt mode and lorax-composer (which use anaconda directly) it would be most useful to add a --repo and/or --repodir cmdline option to anaconda that adds the repos to the dnf base object, similar to the way that lorax does things: https://github.com/weldr/lorax/blob/master/src/pylorax/dnfbase.py#L114 updates.img doesn't help with these use cases.

I totally agree with the goals here, the repo command in kickstart is getting too long, but we need a way to handle special cases where people need access to more of the dnf options. At the same time I'm worried about the loss of information that this can cause. Although I don't want to just dump dnf repo files into kickstart -- that defeats the purpose of making it (somewhat) disconnected from the specific backends like yum vs dnf.

Another option may be to use %pre to write out the repo files (I'm not sure if anaconda will currently pick those up, but it should be possible to fix if it doesn't).

On Thu, Sep 26, 2019 at 02:25:49PM +0200, jkonecny(a)redhat.com wrote: > On Fri, 2019-09-20 at 10:21 -0700, Brian C. Lane wrote: > > On Tue, Sep 17, 2019 at 03:09:01PM +0200, jkonecny(a)redhat.com > > wrote: [snip] > > With an updates.img solution like you are describing here is > > there > > anything > > to be done? Can't it already drop new repos into > > /etc/yum.repos.d/ or > > /etc/anaconda.repos.d/ ? > > In general no, it should work without changes. That is a great > benefit > of this solution. The only thing is if we want to create a tool for > the > updates image creation. > > I was also thinking about a behavior nuances. Like, if we want to > change default behavior of how Anaconda works with these > repositories > than it may be interesting to have a separate folder to found out > these > repositories. > > > With my lmc patch for certs I am doing something like this, but > > only > > with the cert files, not the repo files. updates.img > > > > https://github.com/weldr/lorax/pull/839 > > Our idea is to have everything as part of the updates image, repo > files > and certificates. > > > From the perspective of lmc no-virt mode and lorax-composer > > (which > > use anaconda directly) it would be most useful to add a --repo > > and/or > > --repodir cmdline option to anaconda that adds the repos to the > > dnf > > base > > object, similar to the way that lorax does things: > > > > https://github.com/weldr/lorax/blob/master/src/pylorax/dnfbase.py#L114 > > > > updates.img doesn't help with these use cases. > > Seems interesting. I'm just thinking if we don't want to rather use > configuration files for Anaconda. Not sure, it would require a > change > in the Anaconda but shouldn't be that hard. > > FYI: Configuration files were added to Anaconda recently to be able > override behavior and it is the replacement for install classes. > For > you it would mean that you will create the configuration file (ini > format) in the specified directory to tell us where to look for the > repo files. > > There is also a question, is there a use for the --repodir which > can't > be solved by changing configuration files of Anaconda or otherwise > what > is the preferred way here? Oh, interesting! I wasn't aware of that, I'll take a look at it and see if I can make it work w/o any other changes.

> > I totally agree with the goals here, the repo command in > > kickstart is > > getting too long, but we need a way to handle special cases where > > people > > need access to more of the dnf options. > > > > At the same time I'm worried about the loss of information that > > this > > can > > cause. Although I don't want to just dump dnf repo files into > > kickstart > > -- that defeats the purpose of making it (somewhat) disconnected > > from > > the > > specific backends like yum vs dnf. > > I think you have the same even now. The default settings for Fedora > depends on what variant are you using. Based on the environment you > are > using for the installation you will get the result. With kickstart you don't use the host environment's repos, unless you specifically reference them (at least that's how it used to work). eg. you can enable the updates repo shipped on the boot.iso with 'repo --name=updates' but if you don't do that the only repos used are the ones in the kickstart.

> > Another option may be to use %pre to write out the repo files > > (I'm > > not > > sure if anaconda will currently pick those up, but it should be > > possible > > to fix if it doesn't). > > We are thinking about tweaking existing sections to be able to just > dump a general file somewhere (could be a script which will be run > in > the other section or repo file). That would be better solution for > the > %pre sections repo dumping. It would look like: > > %pre --dump-file=/anaconda.repos.d/my.repo > <repo file content> > %end > > However, this will not solve GPG key files or certificates so we > are > more thinking about this for an image creation which in general can > generate the repo files in a drop dir and used that directory. Yeah, I'm not sure what the benefit there is, it's pretty easy to do a: %pre cat > /etc/rc.d/init.d/livesys << EOF STUFF AND THINGS EOF %end