Community ks.cfg directory proposal

[Greg Morgan]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Would a community kick start directory/repository be possible? The idea
is that a body of kick start scripts would be developed by the
community.  So, if a squid server is needed, say, the
ksrepo/squidserver/ks.cfg file could be used to implement such a system.

Advantages:
1.) A repository of system patterns could be developed and maintained.
2.) The scripts may be helpful in testing future fedora releases.
3.) Example, snippets of ks.cfg code would be available to new kick
start users.
4.) Users could rebuild the CD set with additional files that require a
separate download.
a.) A place for %pre files would be on CD1.
b.) A place for %post files would be on the last CD in the set.

It would be great if these ks files were on the first CD for easy boot
time access, if there is not too great of a size impact.

It would be great if a person could override the defaults in a sample
script with an "include" file placed in a special directory on, say, a
USB key drive, local hard drive, etc.  The defaults to be overridden may
include things like a 192 non-routing IP address, etc.  This would allow
some scripts to be used as is without any script or CD rewriting.

Regards,
Greg
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.2.2 (GNU/Linux)
> Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
>
> iD8DBQFGCuNCxyxe5L6mr7IRAlk6AJ9oJZRPMmb7wJYwOV/ymfjy9C2VPgCeOvFr
> WcfmexevEJzCKY2e2fgCWEU=
> =z/De
> -----END PGP SIGNATURE-----

[Matthew Miller]

On Wed, Mar 28, 2007 at 02:50:58PM -0700, Greg Morgan wrote:
> Would a community kick start directory/repository be possible? The idea
> is that a body of kick start scripts would be developed by the
> community.  So, if a squid server is needed, say, the
> ksrepo/squidserver/ks.cfg file could be used to implement such a system.

Yes. Probably better to discuss this on the Fedora list, though.

[Greg Morgan]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Matthew Miller wrote:
> On Wed, Mar 28, 2007 at 02:50:58PM -0700, Greg Morgan wrote:
> > Would a community kick start directory/repository be possible? The idea
> > is that a body of kick start scripts would be developed by the
> > community.  So, if a squid server is needed, say, the
> > ksrepo/squidserver/ks.cfg file could be used to implement such a system.
>
> Yes. Probably better to discuss this on the Fedora list, though.

I was thinking the progressing would be: anaconda-devel-list,
kickstart-list, and then move to the larger user lists.  It seems to me
that by in from anaconda-devel and additional fine tuning from the
kickstart-list is in order.

Regards,
Greg
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.2.2 (GNU/Linux)
> Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
>
> iD8DBQFGCwOcxyxe5L6mr7IRAgkKAJ9X8Blv/oqjuUnXxvYdisxNABK1nwCgp86b
> 2KHO5gMEKjyycBhDPIVUYas=
> =MROb
> -----END PGP SIGNATURE-----

[Karanbir Singh]

Greg Morgan wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Would a community kick start directory/repository be possible? The idea
> is that a body of kick start scripts would be developed by the
> community.  So, if a squid server is needed, say, the
> ksrepo/squidserver/ks.cfg file could be used to implement such a system.

could you not achieve pretty much similar results with rpms in a 
repository and just enable that repo at install time ? you could also 
get the flexibility of storing them on whatever media you want.

that way people can still do their own ks.cfg's and have this benefit

- KB

[Greg Morgan]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Karanbir Singh wrote:
> Greg Morgan wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > Would a community kick start directory/repository be possible? The idea
> > is that a body of kick start scripts would be developed by the
> > community.  So, if a squid server is needed, say, the
> > ksrepo/squidserver/ks.cfg file could be used to implement such a system.
>
> could you not achieve pretty much similar results with rpms in a
> repository and just enable that repo at install time ? you could also
> get the flexibility of storing them on whatever media you want.
>
> that way people can still do their own ks.cfg's and have this benefit
> KB

I was thinking that if the ks.cfg files were already on the first
CD/ISO, then existing anaconda boot syntax could be used to locate the
files. This idea would make the scripts accessible to folks right away
without modifying the stock CD/ISOs. Modifying the first and last CD/ISO
are anaconda tricks to take advantage of the implicit "beginning and
ending installation events".

Your point is well taken if the repository will only be implemented as
an rpm.  Those who wanted to use community development ks files would
then have to install the rpm and then respin the first CD/ISO or use one
of the other ways of accessing the ks files.

Regards,
Greg
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.2.2 (GNU/Linux)
> Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
>
> iD8DBQFGCwhNxyxe5L6mr7IRApFUAJ9d4D4Z/ToGTvZ07WkmgVTBhpLHdwCgkP6h
> +w9wVkCblAiuPUlgvkVGlWg=
> =XQCv
> -----END PGP SIGNATURE-----

[Steven Fernandez]

Hi,

Greg Morgan wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Karanbir Singh wrote:
> > Greg Morgan wrote:
> > > -----BEGIN PGP SIGNED MESSAGE-----
> > > Hash: SHA1
> > >
> > > Would a community kick start directory/repository be possible? The idea
> > > is that a body of kick start scripts would be developed by the
> > > community.  So, if a squid server is needed, say, the
> > > ksrepo/squidserver/ks.cfg file could be used to implement such a system.
> >
> > could you not achieve pretty much similar results with rpms in a
> > repository and just enable that repo at install time ? you could also
> > get the flexibility of storing them on whatever media you want.
> >
> > that way people can still do their own ks.cfg's and have this benefit
> > KB
>
> I was thinking that if the ks.cfg files were already on the first
> CD/ISO, then existing anaconda boot syntax could be used to locate the
> files. This idea would make the scripts accessible to folks right away
> without modifying the stock CD/ISOs. Modifying the first and last CD/ISO
> are anaconda tricks to take advantage of the implicit "beginning and
> ending installation events".
>
> Your point is well taken if the repository will only be implemented as
> an rpm.  Those who wanted to use community development ks files would
> then have to install the rpm and then respin the first CD/ISO or use one
> of the other ways of accessing the ks files.

If it is just a matter of customizing the packages to the installed so that 
one my develop specific 'targeted installs', wouldn't it be easier to have 
repository of community comps.xml files ?

I don't know much about the latest in anaconda, but by the looks of it, 
anaconda is still using the comps.xml to decided package groups to install.

I would recommend a customized comps.xml rather than a ks.cfg simply because a 
kickstart is much more than just package selection, and as such the 
combinations possible with kickstart would never be "one size fits so and so 
requirement".

regards,
- steve
> Regards,
> Greg
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.2.2 (GNU/Linux)
> Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
>
> iD8DBQFGCwhNxyxe5L6mr7IRApFUAJ9d4D4Z/ToGTvZ07WkmgVTBhpLHdwCgkP6h
> +w9wVkCblAiuPUlgvkVGlWg=
> =XQCv
> -----END PGP SIGNATURE-----
>
> Anaconda-devel-list mailing list
> [e-mail]
> https://www.redhat.com/mailman/listinfo/anaconda-devel-list

[Steven Fernandez]

Ugh ! too many typos ! Please ignore my earlier mail. Resending the mail with 
the typos corrected.
--------------------------------
Hi,

Greg Morgan wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Karanbir Singh wrote:
> > Greg Morgan wrote:
> > > -----BEGIN PGP SIGNED MESSAGE-----
> > > Hash: SHA1
> > >
> > > Would a community kick start directory/repository be possible? The idea
> > > is that a body of kick start scripts would be developed by the
> > > community.  So, if a squid server is needed, say, the
> > > ksrepo/squidserver/ks.cfg file could be used to implement such a system.
> >
> > could you not achieve pretty much similar results with rpms in a
> > repository and just enable that repo at install time ? you could also
> > get the flexibility of storing them on whatever media you want.
> >
> > that way people can still do their own ks.cfg's and have this benefit
> > KB
>
> I was thinking that if the ks.cfg files were already on the first
> CD/ISO, then existing anaconda boot syntax could be used to locate the
> files. This idea would make the scripts accessible to folks right away
> without modifying the stock CD/ISOs. Modifying the first and last CD/ISO
> are anaconda tricks to take advantage of the implicit "beginning and
> ending installation events".
>
> Your point is well taken if the repository will only be implemented as
> an rpm.  Those who wanted to use community development ks files would
> then have to install the rpm and then respin the first CD/ISO or use one
> of the other ways of accessing the ks files.

If it is just a matter of customizing the packages to be installed, so that
one may develop specific 'targeted installs', wouldn't it be easier to have
repository of community comps.xml files ?

I don't know much about the latest in anaconda, but by the looks of it,
anaconda is still using the comps.xml to decide package groups to install.

I would recommend a customized comps.xml rather than a ks.cfg simply because a
kickstart is much more than just package selection, and as such, the
combinations possible with kickstart would never be "one size fits so and so
requirement".

regards,
- steve

[Jeremy Katz]

On Wed, 2007-03-28 at 14:50 -0700, Greg Morgan wrote:
> Would a community kick start directory/repository be possible? The idea
> is that a body of kick start scripts would be developed by the
> community.  So, if a squid server is needed, say, the
> ksrepo/squidserver/ks.cfg file could be used to implement such a system.

I'd love to see some of this.  I started to make a place for things like
this on the wiki a while ago at
http://fedoraproject.org/wiki/KickstartSnippets but it really is going
to require more than me to flesh it out

[snip]
> It would be great if these ks files were on the first CD for easy boot
> time access, if there is not too great of a size impact.

The problem with having it on the first CD is that the package set
that's on the CD is something that's going to start being a lot more
fluid.  And trying to match "this ks.cfg should go on this CD, but not
this one" just isn't something that I'm really interested in having to
maintain.  And things like partitioning, networking, passwords really
don't want to be defaulted as that's going to cause weirdness for people

Jeremy

[Chris Lumens]

> Would a community kick start directory/repository be possible? The idea
> is that a body of kick start scripts would be developed by the
> community.  So, if a squid server is needed, say, the
> ksrepo/squidserver/ks.cfg file could be used to implement such a system.
>
> Advantages:
> 1.) A repository of system patterns could be developed and maintained.
> 2.) The scripts may be helpful in testing future fedora releases.

Yes, this would be great.  Not only does it provide a bunch of examples
for users to take and adapt, but it would be a great help in testing.
I'd like to have a battery of test cases to throw at ksvalidator when I
make changes to pykickstart.  That would help in finding regressions.
It'd also give me an idea of what sorts of things people are commonly
doing that could be added to our anaconda tests.

You guys come up with some strange things that I don't think up, so it'd
be nice to be testing real world examples instead of the contrived
things I create.
> 3.) Example, snippets of ks.cfg code would be available to new kick
> start users.
> 4.) Users could rebuild the CD set with additional files that require a
> separate download.
> a.) A place for %pre files would be on CD1.
> b.) A place for %post files would be on the last CD in the set.
>
> It would be great if these ks files were on the first CD for easy boot
> time access, if there is not too great of a size impact.
>
> It would be great if a person could override the defaults in a sample
> script with an "include" file placed in a special directory on, say, a
> USB key drive, local hard drive, etc.  The defaults to be overridden may
> include things like a 192 non-routing IP address, etc.  This would allow
> some scripts to be used as is without any script or CD rewriting.

There has been some talk of this in the past - of providing sample
workstation, server, whatever kickstart templates on the CDs that the
user can pick from.  However not much has come of it yet.  Jeremy
mentioned a couple of his concerns, and they're valid.  But I think we
should investigate this further.  More thought is needed.

I don't have any thoughts formed on this matter just yet, though.

- Chris

[John Summerfield]

Greg Morgan wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Would a community kick start directory/repository be possible? The idea
> is that a body of kick start scripts would be developed by the
> community.  So, if a squid server is needed, say, the
> ksrepo/squidserver/ks.cfg file could be used to implement such a system.

Let's start with a problem definition:

What problems are you trying to fix?

Who might it help?

Who would actually go looking for such a thing? (I ask this having just 
seen some twit being scolded for not doing the research before asking 
whether RHEL5 had been released and/or when will CentOS be out?).

[Jane Dogalt]

--- Greg Morgan  wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Would a community kick start directory/repository be possible? The
> idea
> is that a body of kick start scripts would be developed by the
> community.

+1*10^101

Thats an emphatic yes.  I've been working on such a system for years
now, though within a framework which

a) can easily take these system dna fingerprints (don't worry, the
genetic metaphor keeps on going... ;) and generate system images.  I.e.
a qemu/vmware system image.

b) can easily transmogrify these system images into other formats. 
I.e. livecds, bootable usbs, payloads for PXE and other network
push/pull installation methods, ...

c) provide the user with the natural conveniences that are desired when
dealing with creating these things.  I.e. read the fedora-livecd-list
archives to see the obvious headaches (can it be easier than rolling
custom rpms+yumrepos to make 'traits' to add to kickstart that don't
fit in %post, can it be easier to deal with local mirrors of yum
repositories, can it be easier to rebrand/relogo the system, etc...)

d) provides automated regression testing for strains/recipes.  I.e.
after easily spawning the generated image, you can virtually boot it
and perform blackbox&glassbox regression tests against it.  I.e. the
vision of a strain/recipe getting daily built against the rawhide repo,
and automatically checked against a suite of regression tests.

Anyway, I don't have any useful contribution yet (my code is horribly
ugly, and my todo list is almost longer than the code).  But I
absolutely think this is the killer app.

Again, yes, yes, and more yes.  In my past sysadmin experiences, the
above tool is what I most would have liked to have.  (considering the
output livecds can be 1-button-non-interactively installable...)

As always, I'll post to fedora-livecd-list when I have code that is
useful, but for now, in the dukenukem spirit, the name of my project is
'viros4ever'.

-dmc/jdog

____________________________________________________________________________________
The fish are biting. 
Get more visitors on your site using Yahoo! Search Marketing.
http://searchmarketing.yahoo.com/arp/sponsoredsearch_v2.php