Kickstart Configuration Managers

Thu Apr 1 19:15:22 UTC 2004

Can you frame out what the word 'distro' means in your vision?

I'm thinking one major problem you are going to see will center around
packaging and distribution centric assumptions in packages.  I admit to
being largely RedHat focused for the past few years, so I'm not sure how
much of what I understand in distributions has been widely adopted
versus rh centric. 

I'm thinking about things like chkconfig for service management.
Differing versions of rpm not always playing well together. Different
distributions assumptions about what it is a package is providing and
where files should go.

So on and so forth.

How are you foreseeing addressing those sorts of issues?

--Chris

On Thu, 2004-04-01 at 12:09, Adam T. Gautier wrote:
> I am in the process of creating a system that could incorporate the 
> feature of a kickstart configuration manager.  I am building an online 
> service for designing and building custom Linux distributions based on 
> the big four Linux distos (RedHat(Fedora), Mandrake, Suse, and Debian).  
> I am building this for two reasons.
> 
> 1.) I have a series of utilities and scripts already built for my own 
> use in this area.
> 2.) I would like to bootstrap some consulting services around this concept.
> 
> The main purpose of this service is to allow the community to design 
> distos around particular solutions without fracturing the Linux 
> community with more bistro's.  An example of solutions could be a pre 
> configured dedicated email server, a Linux gaming distribution, etc...  
> To me, there is no reason that a PROPERLY customized distribution of an 
> existing distro is any different from installing packages and modifying 
> their configuration files.  I am striving that it would not even 
> invalidate the support contract.  I want to expand this concept by 
> pushing more configuration capabilities into Anaconda (by default also 
> supporting Kickstart) and the initial config script.  I am also hoping 
> to provide a set of services to support the community.  I would like to 
> allow the sharing of these custom distro iso, ks files, anaconda 
> modules, etc... for anyone to pick and choose between what they want to 
> include in their own distro.
> 
> Currently, I am working on a package tracker for the service (think 
> rpmfind.net or Brad Smith's Tracker 
> http://academy.phpwebhosting.com/cgi-bin/tracker/tracker.py  ).  This 
> will provide an online service that resolves package dependencies and 
> allow for the definition of solution sets (think groups of the comp.xml 
> file).  These solution sets would be shared with the community.  These 
> solutions would then be added to the top of defined distribution bases 
> (the big four Linux distros).  All of these selections on the webapp are 
> structured into a distro spec file.  This is my own invention and would 
> define base distro, packages (location, versions), configurations (ks, 
> anaconda), This can be downloaded and fed into some client software (the 
> utilities and scripts I already have).  Then, client software will 
> download the packages (distro packages and third-party packages), check 
> them (MD5 and GPG), and setup the distribution directory.  This client 
> software will also allow for the customization of look and feel (logo's, 
> desktop, icons, display names) and additional private packages not 
> exposed to the community.  Then the user would just use mkisofs to 
> create iso files or deploy using http and/or ftp.
> 
> The main features of this service would be:
> 
> 1.) Custom distros based on existing Linux distros
> 2.) Custom distros based on existing custom distros
> 3.) A library of custom disto's
> 4.) A library of ks file components
> 5.) A library of anaconda modules
> 6.) A library of package solution sets
> 7.) A library of packages (distro's and third-party packages)
> 8.) Client software to simplify branding of the custom distro.
> 9.) Community (forum's and mailing lists)
> 10.) Ongoing package support for the custom distros.  (Customized 
> up2date/yum)
> 11.) Many more... I have an ongoing wishlist
> 
> I am thinking of charging $30/year for access to the service.  This is 
> simply to help pay for the massive costs of hosting.  The market is not 
> that big and I am not trying to get rich, I just want to split the cost 
> (like I said I am hoping to make my money in consulting).  Does $30/year 
> seem reasonable for this service?  I also want to charge $2-5/month for 
> end user ongoing package support.  I was thinking of allowing the distro 
> creators a revenue sharing model whenever an end user registers to 
> receive updated packages.  Not sure if any of these money concepts are 
> going to fly, I am building the service anyway and worst case scenario I 
> give allot of code to the community.  Again, I just want to come up with 
> a way to offset my costs to put up this service. 
> 
> Please, let me know what everyone thinks.  I am about 1 month into the 
> development and should have an alpha version deployed mid April for 
> review.  Also, please help me with ideas around how best to dissect the 
> ks config file into reusable chunks for publication.
> 
> Thanks,
> 
> Adam
> 
> 
> 
> _______________________________________________
> Kickstart-list mailing list
> Kickstart-list at redhat.com
> https://www.redhat.com/mailman/listinfo/kickstart-list