FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > CentOS > CentOS Development

 
 
LinkBack Thread Tools
 
Old 12-30-2011, 09:49 PM
Karanbir Singh
 
Default custom iso spin

Hi Guys,

On 12/30/2011 02:55 PM, Lamar Owen wrote:
> I'd like to make an install USB with all the CentOS packages, sorted into repositories, and with updates integrated. Also, I'd like to put some select third party repos, and be able to use them at install time (anaconda is capable of using any repo at install time, of course). With 16 and 32GB USB bootable USB sticks somewhat affordable now, I can see great utility in being able to carry a key around to do installs to non-network attached PC's (of which we have a few) as well as being able to yum update off of that media (as documented in a form in the CentOS-Media.repo file).
>
> And, like the OP, I'd like to drive the tools, meaning build it myself so that I can include packages that CentOS can't distribute (in particular, some site-developed packages that for various reasons we can't or won't distribute). The SL project documents a good deal of this process in their 'sites' documentation, incidentally.

the actual tools are all just anaconda/scripts - included in the rpms's
- BUT, you dont need to rebuild the installer to achieve any of that.
All you need to do is decide on the layout ( ideally, dont change the
layout already in place so you dont lose the ability to
use/abuse/incorpotate existing tools ), add your content into place and
setup a new installclasses/<lamar.py> which sets up whatever install
options you want pre-selected ( or just do that via kickstart ).

anaconda in c6 will work with arbitary media:// style repos as well as
the usual http:// ftp:// etc ones.

--
Karanbir Singh
+44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh
ICQ: 2522219 | Yahoo IM: z00dax | Gtalk: z00dax
GnuPG Key : http://www.karan.org/publickey.asc
_______________________________________________
CentOS-devel mailing list
CentOS-devel@centos.org
http://lists.centos.org/mailman/listinfo/centos-devel
 
Old 12-30-2011, 10:21 PM
夜神 岩男
 
Default custom iso spin

On 12/31/2011 05:47 AM, Karanbir Singh wrote:
> On 12/30/2011 04:25 PM, Johnny Hughes wrote:
>> We have a custom build system. It uses a beanstalkd workqueue to submit
>> packages to mock and can scale up or down as required and submit
>
> Just to add a few more bits :

> The entire system is called 'reimzul'
>
> As soon as I have got the basic functional stuff in place, and some docs
> around it I'll have it up in a git repo where people can clone and join
> the fun.

> Bit of a brain dump, but there you have it.

Thanks! That was informative, and it sounds like I'm reinventing the
wheel, or at least a few spokes. Currently I've got a small automation
of mock, signature, placement and repo creation.

When it comes to custom applications or things just not found anywhere
else I have a script per application that pulls stable/specified source
from a tree, scrubs out the fluff or shuffles things around to be the
way Linux people are accustomed to, touches the standard bits of the
spec (of course sometimes this isn't possible to do properly), and puts
an srpm into the directory the mock script will reference. At first I
thought this would be a pain to maintain, but its easier than
maintaining spec files and init scripts anwyway, and saves me time (the
goal).

So generally, from custom code to combining with standard srpms to
producing a complete repo is not an issue -- and this isn't such a hard
problem for a single distro anyway.

What I need is a way to move from a complete repo to an install ISO. I'm
completely missing this step, and suck at doing it manually so need to
learn more in any case. Doing a livecd isn't a big issue, I just don't
know much about how to call the anaconda scripts reliably to where I can
simply pick a repo and wind up with a complete install image and not a
livecd when necessary.

Beyond that I want to make a way to split the repo list, so I can
maintain a core repo and then add accessory repos that are segregated
when they conflict greviously with one another (which is the problem
with things we have now with some base subsystems like Python3, or
Postgres 8.4 vs 9.1 specific things that we haven't figured out how to
make play nicely together, etc.). This issue might parallel some of the
issues you face maintianing multiple versions of the standard distro.

I am very interested to see whatever you guys put on git. If the shoe
fits, I might wear it myself and roll my effort into enhancing yours.
Package management is a pain -- enormously easier than it was in the mid
90's (when we didn't really have packages yet... hehe) -- but still a
bit of a pain.
_______________________________________________
CentOS-devel mailing list
CentOS-devel@centos.org
http://lists.centos.org/mailman/listinfo/centos-devel
 
Old 12-31-2011, 12:28 AM
An Yang
 
Default custom iso spin

On 2011-12-30 Fri 20:47 +0000,Karanbir Singh wrote:


On 12/30/2011 04:25 PM, Johnny Hughes wrote:
> We have a custom build system. It uses a beanstalkd workqueue to submit
> packages to mock and can scale up or down as required and submit

Just to add a few more bits : the queue system is meant to extend in
both directions ( import and tracking of sources on one end - and
testing + release management at the other end ). At the moment there is
a bunch of band-aid and Johnny and me typing up stuff to bridge those
bits, but I hope to have the entire setup in place end to end by end of
March 2012. Apart from the cli, some of the other interesting interfaces
that are semi functional at this point include an irc-bot, a rest api
and a publicly available http callback server that allows arbitrary
subscription.

There is, by design, no web interface. The plan is to focus on the
mechanics and make the entire system work, with enough hooks that allows
anyone / everyone to do the client side work. Eg. being able to write a
yum plugin that would harvest update metadata from the buildsystem and
be able to report on 'upcoming updates' ( a PoC for this is functional
now.. )

The entire system is called 'reimzul'


Great works.



As soon as I have got the basic functional stuff in place, and some docs
around it I'll have it up in a git repo where people can clone and join
the fun.


How can I take part in? I'm glad to contribute more works.


And yes, this is very* custom done for the CentOS ecosystem and
address's the problems and hurdles that we run into with the localised
process. Koji is a great system, just like OBS is - but they solve
different problems and do so in a way that makes both of them really bad
solutions for the distro-rebuild and tracking process's.

In other interesting artifacts ( and mostly from free win's ) include
being able to test external third party repo's for pre-updates-release
breakage's.... Another feature is the constant compose ( the
next-release-tree is constantly composed on every update build, so were
pretty much ready to go for the next release every night.. a feature
that came in handy for the 6.2 release.)

again, just to be clear - this system works for c6 now, and will for c7
etc ( unless we come up with something else ). We are very much
committed to using plague for c4/c5 for the time being. The pain
associated with migrating and then proving the system for c5 would be
more than is justifiable at this point.

Bit of a brain dump, but there you have it.







_______________________________________________
CentOS-devel mailing list
CentOS-devel@centos.org
http://lists.centos.org/mailman/listinfo/centos-devel
 
Old 01-04-2012, 03:29 PM
Karanbir Singh
 
Default custom iso spin

On 12/31/2011 01:28 AM, An Yang wrote:
>> The entire system is called 'reimzul'
> Great works.

thanks!

>> As soon as I have got the basic functional stuff in place, and some docs
>> around it I'll have it up in a git repo where people can clone and join
>> the fun.
> How can I take part in? I'm glad to contribute more works.

In the immediately future, I'm going to try and get all the blocks
together and remove any site specific code / config / requirements so
its actually possible to run this stuff off the centos buildsystem. And
then get the code into a git repo that people can look at, contribute into.

the original plan was also to get a public facing buildsystem ( with
people having the ability to add in and send up builds ) using reimzul.
Lets see if we can still get that done. It does mean having working
policies for:
- making sure only open source stuff does through
- making sure no one is doing anything that could be considered illegal
- making sure that the system stays safe/secure

If we do get it going, I would love it to be the entire system from the
source management to the builds and testing frameworks.

--
Karanbir Singh
+44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh
ICQ: 2522219 | Yahoo IM: z00dax | Gtalk: z00dax
GnuPG Key : http://www.karan.org/publickey.asc
_______________________________________________
CentOS-devel mailing list
CentOS-devel@centos.org
http://lists.centos.org/mailman/listinfo/centos-devel
 
Old 01-04-2012, 03:50 PM
Les Mikesell
 
Default custom iso spin

On Wed, Jan 4, 2012 at 10:29 AM, Karanbir Singh <mail-lists@karan.org> wrote:
>
> the original plan was also to get a public facing buildsystem

Who are you, and what have you done with the CentOS team? :-)

--
Les Mikesell
lesmikesell@gmail.com
_______________________________________________
CentOS-devel mailing list
CentOS-devel@centos.org
http://lists.centos.org/mailman/listinfo/centos-devel
 

Thread Tools




All times are GMT. The time now is 01:23 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org