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
