linuxcoe-devel — LinuxCOE development discussion

[Linuxcoe-devel] Thaughts on LinuxCOE

[Bouchard, L. <Lou...@hp...>]

Hi everyone,

This is highly philosophical content.  So if you don't feel like wasting
your time reading through this, I won't be offended.

In early February I came about the LinuxCOE project, following a brief
encounter with BryanG & LeeM at the OSLO Tech Tour 2007.  I'm starting
to have a rough idea on how things are working, evolving, being
constructed in the LinuxCOE project.

I don't intend to give lessons, to teach anything to anyone. I just want
to share my newcomer's perspective on a successful project which has
everything that needs to become even bigger. I originally thought of
posting this on my blog, but this list is better since opening a
discussion is what I'm hoping for.

Driving to work this morning, I was listening to Brian Behlendorf's
TuxTalk (http://opensource.professions.hp.com/tuxtalks/200706/). He was
talking about open source teams, how they worked, what made them
successful, etc. I found in his description many of the things I found
when joining the LinuxCOE group :

- Collaboration
- Cooperation
- Respect
- friendship team spirit

All of that I had already sensed when I met with B&L in Fort Collins.
The rest from our weeklies & IRC encounters confirmed my beliefs.

All of these are the strong foundations on which LinuxCOE is being
built.  This is good since LinuxCOE is, in my view, the first real
example of Open Source in Action within HP. It's also a very good
example of "eat your own dog food" for HP.  So I guess that this strong
foundation can affort to question itself on a few questions that keeps
poping up in my mind.

Can LinuxCOE exist outside of HP ?

Of course it can. We have the sf.net environment, website, public IRC,
mailing list, etc. Though I sometime think that it is still mostly an
internal HP effort. I might be wrong, but it still  is not much of an
issue, really.

Can LinuxCOE exist without HP ?

It would be tough.  My guess is that a lot of what's required to keep
LinuxCOE alive relies on HP hardware. This is fine since the project is
heavily used internally. But if this was to change for a reason,
LinuxCOE might be faced with the need to find its own house.

Can LinuxCOE integrate participants from the outside world ?

Sure it can. But a lot of LinuxCOE's life is within HP (i.e. the
internal #linuxcoe).  This is not a problem right now, but it might
become one when more outside world participants will join the team. This
is why I'm now auto-joining the public #linuxcoe.

Where is LinuxCOE common knowledge ?

In many people's head I'm afraid. A lot of functional information lies
in the Admin docs, and a few other files. A lot of stuff is in the
CVS/SVN repo. But discussions, architectural details, stuff like that
might be somewhere I don't know of. You might know where I'm heading :
do we need a wiki or something similar to that ? For example, where do I
document the thinks I'm setting up in order to build the packages
(rpmlint, lsb-rpmchk, custom scripts, process) ,

Does LinuxCOE needs a name change ?

I don't think so, Tony. At least, it is not something that will change a
lot in how things are doing now.  But I do think that LinuxCOE fits in
something bigger : dploy.org.

The main problem with dploy.org is that it will not have a life as easy
as LinuxCOE does withing HP. It might collide with products marketed by
HP, namely RDP & Control Tower.  So my guess is that if rdeploy is to
succeed, it will need to be a separate project that make use of
LinuxCOE. It will also have to go through the OSRB as a separate
project.

I hope that these few questions can trigger a discussion or at least be
useful in sharing a newcomer's view of the LinuxCOE project.

Regards,


Caribou

--=20
Louis Bouchard, Linux Support Engineer
EMEA Linux Competency Center,
Linux Ambassador, HP

HP Services                       1 Ave du Canada
HP France                         Z.A. de Courtaboeuf
lou...@hp...             91 947 Les Ulis
http://www.hp.com/go/linux        France
http://www.hp.com/fr

Re: [Linuxcoe-devel] Good afternoon

[Bryan G. <Bry...@HP...>]

Juan,

On Wed, Jul 04, 2007 at 08:27:27PM +0000, Juan Carlos Nu?ez Frayre wrote:
> 
> Thnks for respond
> 
> So this is my ip of machine of test
> 
> http://200.57.146.67/systemdesigner/

Ah, thanks, that speaks volumes for me.

> Systemdesigner its up
> 
> but i'm search more information, to creation of images, of distributions, Desing a system and create a network installation boot disk, create a system profile, retrofit an existing system.

Okay, so you have successfully completed the first step, the application
appears to be installed and running.  However, you need to carry on
a bit to make this useful.  As noted in the  Admin Guide (last Note
section):

  http://linuxcoe.sourceforge.net/docs/guides/admin_guide.html#Snapshots

you now need to download and install some of the other modules.  I'd
suggest you start with the "systemdesigner-docs" overlay and get that
installed.  When you do, your links on your home page to Documentation
should be working.  And you will have a feel for how to install the
other modules (which you can freely pick and choose from).

One word of note, though, if you pick NLD,RHEL,SLES as a starting point,
you will not see them show up in the Distro, Rev, Arch pick list without
further configuration.  Please refer to this section of the Admin Guide
to "enable those" (once you have the "docs" installed):

  http://200.57.146.67/systemdesigner/docs/guides/admin_guide.html#Add_Distro_Rev_Arch_Option

You will see comments in the referenced files that will help guide you
farther.

> the administration guide don't understand for point before mentioned, i am working partner of HP Mexico, and this project it's interesting and i'm test for maybe implementation.

Hope that helps, and let us know if you have further questions,

bryang

Re: [Linuxcoe-devel] Good afternoon

[Bryan G. <Bry...@HP...>]

Juan,

On Tue, Jul 03, 2007 at 11:11:39PM +0000, Juan Carlos Nu?ez Frayre wrote:
> Sorry bunt, i dont understand administration guide.

Any particular part?

> Apache web its run linuxcoe its run, but i dont understand why creation of images.
> the administration guide its confused i need more documentation of the project, for a test LinuxCOE.

Sorry, but I am not really sure what you are asking, but we would be
glad to help get you started.  Can you give us a list of what issues
need clarifying or what specific questions you have, please?

bryang

[Linuxcoe-devel] Good afternoon

[<jcf...@ho...>]

Sorry bunt, i dont understand administration guide.Apache web its run linux=
coe its run, but i dont understand why creation of images.the administratio=
n guide its confused i need more documentation of the project, for a test L=
inuxCOE.thnks for all.=0A=
 =0A=
=0A=
J.C
_________________________________________________________________
Expr=E9sate - dise=F1a tu p=E1gina de inicio de Live.com como m=E1s te gust=
e.
http://www.live.com/getstarted=

Re: [Linuxcoe-devel] feedback: systemdesigner V4 - snapshot part 2

[Bryan G. <Bry...@HP...>]

FYI,

> > Bouchard, Louis said on Tue, Jun 26, 2007 at 06:10:55PM +0200:
> > 
> >>> 1. It was unclear what to download
> >>>   systemdesigner-4 ? systemdesigner-opensuse-4 ? both ?

As per the docs (see the Admin Guide), the required package is
systemdesigner, with each of the other module packages adding
more functionality.  The core systemdesigner, while it can
be installed standalone, would not provide anything visibily
useful.

> >>> sugestion:
> >>> 	call it systemdesigner-4 and  addon-4-opensuse
> >> On this issue, I'm also interested since I need to make a difference
> >> between the SystemDesigner RPM and rpms for the overlays.

I'd be open to the "addon" moniker, but would prefer to have
the systemdesigner name still appear, if nothing for the "grouping"
effect it would have on (later) packaged installs.

> >> So far, I've used this :
> >>
> >> 	- systemdesigner for the main SystemDesigner RPM
> >> 	- sysdes-overlay-{distro} for the overlays
> >>
> >> This is only a working choice for me, so I'm open to any suggestion but
> >> it is indeed an issue that needs to be adressed.
> > 
> > Maybe it's time for naming conventions ;-)
> > 
> > Looking at the repositories, I would suggest first that the version be
> > removed from the name (it's part of the version field, not the name
> > field, except for compatibility issues, but the tendency is then to
> > rename the old one, e.g. apache => apache1 and/or apache2). Also I think
> > that version should follow a more traditional numbering schema, such as
> > 4.0 for the lastest one, rather than 4 alone (as in fedora ;-)
> 
> i agree :)
> is there any reason to start with 4 ?

Actually yes re: 4 (since this project has been under development for
over 7 years, we really are at version 4).  And as for the standard
numbering schema, it was always intended to become 4.0, at least when
we offer packaged versions.  And for subsequent minor revs, 4.1, ...,
etc.

> > I'd agree with Louis that the main program package should be named
> > systemdesigner (even if being an old Unix guy I prefer shorter name such
> > as sysdes). As long as it doesn't conflict with other existing packages
> > in distro, it's fine:

Heh, I have toggled many times with the sysdes vs. systemdesigner
thinking.  As I could find no legitimate limits specified either in
rpm or deb packaging guidelines, I have currently opted for the
longer name.  And I have searched for both namespaces as widely
as I could, and found no conflict on either.

> > [root@eurolinux ~]# locate .rpm | wc -l
> > 1350237
> > [root@eurolinux ~]# locate .deb | wc -l
> > 301768
> > [root@eurolinux ~]# locate sysdes | grep rpm
> > [root@eurolinux ~]#
> > 
> > Now even if I like short names, maybe it would be interesting to avoid
> > any future ambiguity by prefixing with linuxcoe ?
> > So linuxcoe-sysdes-4.0.noarch.rpm ?

Interesting idea, as there may soon be some functionality beyond
systemdesigner, in the LinuxCOE project umbrella.

> sysdes -> SYStemDEScription ? no joke this was may first idea on this
> 
> here my 2 cents (after asking google)
> 
> sysdesign -> some companie with that name
> sysdesigner -> even software with that name (unrelated)
> systemdesigner -> even here some more
> 
> 
> for the more adventures:
> Linux-System-Designer for-> LSD4
> and the addons:
> 	4-rhel-lsd
> 	4-fedora-lsd
> 	4-suse-lsd
> 	4-....

Still, I prefer to have a common prefix for all the packages, again
to make listing the components "more coherent and recognizable".
And according to debian policy, package names must be lower case:

    http://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-Package

which prompted our recent migration from SystemDesigner to the current
one.

> > For other packages, as they concern distributions why not
> > linuxcoe-distrib-rhel-4.0.noarch.rpm,
> > linuxcoe-distrib-fedora-4.0.noarch.rpm, ...

Perhaps, you might be confusing what the modules are for.  They
essentially provide the data/configuration to vend a particular
distribution.  This is irregardless of what distribution you
install SystemDesigner on.  So it's not like you would grab the
fedora overlay to host it on Fedora, but rather if you wish to
vend Fedora installations.

> > I'm not sure the term overlay is obvious for everybody.
> > 
> > BTW, I'll need them very soon now ;-)

We are actively working on packages, that will cleanly install
across as many distributions as we can.  Until we are happy
with the results (and various checking tools are too), we
won't publish the packages.  However, you are free to checkout
the "packaging" module, and try to create some packages with
the current artifacts.  Feedback is more than welcome,

bryang

Re: [Linuxcoe-devel] feedback: systemdesigner V4 - snapshot part 2

[walter h. <wh...@bf...>]

Bruno Cornec wrote:
> Hello,
> 
> Bouchard, Louis said on Tue, Jun 26, 2007 at 06:10:55PM +0200:
> 
>>> 1. It was unclear what to download
>>>   systemdesigner-4 ? systemdesigner-opensuse-4 ? both ?
>>>
>>> sugestion:
>>> 	call it systemdesigner-4 and  addon-4-opensuse
>> On this issue, I'm also interested since I need to make a difference
>> between the SystemDesigner RPM and rpms for the overlays.
>>
>> So far, I've used this :
>>
>> 	- systemdesigner for the main SystemDesigner RPM
>> 	- sysdes-overlay-{distro} for the overlays
>>
>> This is only a working choice for me, so I'm open to any suggestion but
>> it is indeed an issue that needs to be adressed.
> 
> Maybe it's time for naming conventions ;-)
> 
> Looking at the repositories, I would suggest first that the version be
> removed from the name (it's part of the version field, not the name
> field, except for compatibility issues, but the tendency is then to
> rename the old one, e.g. apache => apache1 and/or apache2). Also I think
> that version should follow a more traditional numbering schema, such as
> 4.0 for the lastest one, rather than 4 alone (as in fedora ;-)
> 

i agree :)
is there any reason to start with 4 ?


> I'd agree with Louis that the main program package should be named
> systemdesigner (even if being an old Unix guy I prefer shorter name such
> as sysdes). As long as it doesn't conflict with other existing packages
> in distro, it's fine:
> 



> 
> [root@eurolinux ~]# locate .rpm | wc -l
> 1350237
> [root@eurolinux ~]# locate .deb | wc -l
> 301768
> [root@eurolinux ~]# locate sysdes | grep rpm
> [root@eurolinux ~]#
> 
> Now even if I like short names, maybe it would be interesting to avoid
> any future ambiguity by prefixing with linuxcoe ?
> So linuxcoe-sysdes-4.0.noarch.rpm ?
> 

sysdes -> SYStemDEScription ? no joke this was may first idea on this

here my 2 cents (after asking google)

sysdesign -> some companie with that name
sysdesigner -> even software with that name (unrelated)
systemdesigner -> even here some more


for the more adventures:
Linux-System-Designer for-> LSD4
and the addons:
	4-rhel-lsd
	4-fedora-lsd
	4-suse-lsd
	4-....


re,
 wh

> For other packages, as they concern distributions why not
> linuxcoe-distrib-rhel-4.0.noarch.rpm,
> linuxcoe-distrib-fedora-4.0.noarch.rpm, ...
> 
> I'm not sure the term overlay is obvious for everybody.
> 
> BTW, I'll need them very soon now ;-)
> 
> WDYT ?
> Bruno.

Re: [Linuxcoe-devel] feedback: systemdesigner V4 - snapshot part 2

[Bruno C. <Bru...@hp...>]

Hello,

Bouchard, Louis said on Tue, Jun 26, 2007 at 06:10:55PM +0200:

> > 1. It was unclear what to download
> >   systemdesigner-4 ? systemdesigner-opensuse-4 ? both ?
> >=20
> > sugestion:
> > 	call it systemdesigner-4 and  addon-4-opensuse
>=20
> On this issue, I'm also interested since I need to make a difference
> between the SystemDesigner RPM and rpms for the overlays.
>=20
> So far, I've used this :
>=20
> 	- systemdesigner for the main SystemDesigner RPM
> 	- sysdes-overlay-{distro} for the overlays
>=20
> This is only a working choice for me, so I'm open to any suggestion but
> it is indeed an issue that needs to be adressed.

Maybe it's time for naming conventions ;-)

Looking at the repositories, I would suggest first that the version be
removed from the name (it's part of the version field, not the name
field, except for compatibility issues, but the tendency is then to
rename the old one, e.g. apache =3D> apache1 and/or apache2). Also I think
that version should follow a more traditional numbering schema, such as
4.0 for the lastest one, rather than 4 alone (as in fedora ;-)

I'd agree with Louis that the main program package should be named
systemdesigner (even if being an old Unix guy I prefer shorter name such
as sysdes). As long as it doesn't conflict with other existing packages
in distro, it's fine:


[root@eurolinux ~]# locate .rpm | wc -l
1350237
[root@eurolinux ~]# locate .deb | wc -l
301768
[root@eurolinux ~]# locate sysdes | grep rpm
[root@eurolinux ~]#

Now even if I like short names, maybe it would be interesting to avoid
any future ambiguity by prefixing with linuxcoe ?
So linuxcoe-sysdes-4.0.noarch.rpm ?

For other packages, as they concern distributions why not
linuxcoe-distrib-rhel-4.0.noarch.rpm,
linuxcoe-distrib-fedora-4.0.noarch.rpm, ...

I'm not sure the term overlay is obvious for everybody.

BTW, I'll need them very soon now ;-)

WDYT ?
Bruno.
--=20
Linux Profession Lead EMEA  / Open Source Evangelist \        HP C&I EMEA I=
ET
http://www.mondorescue.org / HP/Intel Solution Center \  http://hpintelco.n=
et
Des infos sur Linux?  http://www.HyPer-Linux.org      http://www.hp.com/lin=
ux
La musique ancienne?  http://www.musique-ancienne.org http://www.medieval.o=
rg

Re: [Linuxcoe-devel] feedback: systemdesigner V4 - snapshot part 2

[walter h. <wh...@bf...>]

hi louis,
IMHO it is important to show the difference between a
base package (must have) and a support package (nice to have).
I think there is a consensus calling the base package "systemdesigner".
(btw: does it contain a skeleton dist package ? )

I would call the rest "addon" this is that *I* would looking for, like
the addon's for firefox/mozilla/... etc. The word "overlay" is problematic
IMHO because *I* know that only in conjunction with graphics.

re,
 wh



Bouchard, Louis wrote:
> Hi Chris & Al,
> 
>> 1. It was unclear what to download
>>   systemdesigner-4 ? systemdesigner-opensuse-4 ? both ?
>>
>> sugestion:
>> 	call it systemdesigner-4 and  addon-4-opensuse
> 
> On this issue, I'm also interested since I need to make a difference
> between the SystemDesigner RPM and rpms for the overlays.
> 
> So far, I've used this :
> 
> 	- systemdesigner for the main SystemDesigner RPM
> 	- sysdes-overlay-{distro} for the overlays
> 
> This is only a working choice for me, so I'm open to any suggestion but
> it is indeed an issue that needs to be adressed.
> 
> Regards,
> 
> ...Louis
> 

Re: [Linuxcoe-devel] feedback: systemdesigner V4 - snapshot part 2

[Bouchard, L. <Lou...@hp...>]

Hi Chris & Al,

> 1. It was unclear what to download
>   systemdesigner-4 ? systemdesigner-opensuse-4 ? both ?
>=20
> sugestion:
> 	call it systemdesigner-4 and  addon-4-opensuse

On this issue, I'm also interested since I need to make a difference
between the SystemDesigner RPM and rpms for the overlays.

So far, I've used this :

	- systemdesigner for the main SystemDesigner RPM
	- sysdes-overlay-{distro} for the overlays

This is only a working choice for me, so I'm open to any suggestion but
it is indeed an issue that needs to be adressed.

Regards,

...Louis

--=20
Louis Bouchard, Linux Support Engineer
EMEA Linux Competency Center,
Linux Ambassador, HP

HP Services                       1 Ave du Canada
HP France                         Z.A. de Courtaboeuf
lou...@hp...             91 947 Les Ulis
http://www.hp.com/go/linux        France
http://www.hp.com/fr

Re: [Linuxcoe-devel] feedback: systemdesigner V4 - snapshot part 2

[Chris S. <ch...@in...>]

Hi Walter,

I'm forwarding these two messages on to the folks who do the development 
of LinuxCOE.

Thanks for the feedback!

Chris


walter harms wrote:
> hi chris,
> i run into a problem since my linuxcoerc was broken. ntl the cgi should
> cry or drop a a decent default if it can not find that file. (no it creates
> an empty select box).
> While looking for bugs i found:
> File does not exist: /srv/www/htdocs/overlib.js, referer: http://corleone/systemdesigner-cgi-bin/coe_bootimage
> you do not provide them.
>
>
> so i installed the docs. the docs need to be installed into the same
> dir as everything else. the configure create a systemdesigner-doc
>
> something like:
> prefix = /usr/local/systemdesigner/4
> is more reasonable.
>
>
> i tried to fix the linuxcoerc but was unable to get a distro requester, no idea why.
>
> re,
>  wh
>
>
>
>   

hi chris,
i was just trying your latest version, here my first impressions:

1. It was unclear what to download
  systemdesigner-4 ? systemdesigner-opensuse-4 ? both ?

sugestion:
	call it systemdesigner-4 and  addon-4-opensuse

btw for you own good call the snapshot systemdesigner-2007-06-22, something like that.
It is nice to know to what version the bug reports relates  :) 
Do not forget to write: "get systemdesigner and at least 1 addon"

2. Intalldir

in systemdesigner/Makefile
	prefix = /usr/local/systemdesigner/4

in systemdesigner-opensuse-4
	prefix = /opt/systemdesigner-opensuse/4

Is it intentional to have someparts in /opt some in /usr/local ? i personaly prefer the same dir
is the /4 intentional ? i had the impression that it is short for "for" ?

3. post-actions
The post-actions script stalled because i broke some variables (accidently), it can be improved
by [ -f $CONFIG_SITE ] && . $CONFIG_SITE making sure that variables are realy set.
(it would be nice to have a full path in CONFIG_SITE)


4. config.site

here is my config.site it should basicly work with all newer suse releases.

##
# Site Customization file config.site
#	these variables can be set via the command line as
#		./configure httpdcfgdir=/SomeValue ...
#	or all at once by editing this configuration file and then
#		export CONFIG_SITE=./config.site && ./configure
##

# APACHE Web Services
  # From httpd.conf (or equiv)
  # replace value of httpdcfgdir to match web server location
  # for directory of included module-specific configuration files
  if test "x${httpdcfgdir}" = x; then
    httpdcfgdir=/etc/apache2/sysconfig.d
  fi

  # From httpd.conf (or equiv)
  # replace value of docrootdir to match web server location
  # eg. DocumentRoot /var/www -> docrootdir=/var/www
  # so, the directory seen when you point a web browser at
  # http://YourSite/ and will be populated to become http://YourSite/@PACKAGE_NAME@
  if test "x${docrootdir}" = x; then
    docrootdir=/srv/www
  fi

  # For your particular web service
  # replace value of httpd_user with the UID or user name running the process
  if test "x${httpd_user}" = x; then
    httpd_user=wwwrun
  fi

  # For your particular web service
  # replace value of httpd_group with the GID or group name running the process
  if test "x${httpd_group}" = x; then
    httpd_group=www
  fi

# SUDO Services
  # For your particular sudo implementationftp service
  # replace value of sudo config file sudoers_cfg with your reference location
  # so the httpd_user can perform mount/manipulate/umount operations on
  # the generated boot images
  if test "x${sudoers_cfg}" = x; then
    sudoers_cfg=/etc/sudoers
  fi

Re: [Linuxcoe-devel] LinuxCOE 'replay' feature

[Bruno C. <Bru...@hp...>]

Mayes, Lee said on Tue, Jun 19, 2007 at 12:15:31PM -0400:

> I need to find a good home for that in our tree.
> Bryang, any preference?  It's a standalone perl script you can run
> anywhere, it contacts a sysdes instance over HTTP via wget/Perl LWP.

Maybe time to create a contrib subdir ?

Bruno.
-- 
Linux Profession Lead EMEA  / Open Source Evangelist \        HP C&I EMEA IET
http://www.mondorescue.org / HP/Intel Solution Center \  http://hpintelco.net
Des infos sur Linux?  http://www.HyPer-Linux.org      http://www.hp.com/linux
La musique ancienne?  http://www.musique-ancienne.org http://www.medieval.org

Re: [Linuxcoe-devel] LinuxCOE 'replay' feature

[Mayes, L. <lee...@hp...>]

FWIW, I finished it on the plane coming back from CA last week, and
integrated Dan's serial number file batch'er into the SuSE and Debian
backends as well.  It's all checked in now except for the script you
call it with :), I need to find a good home for that in our tree.
Bryang, any preference?  It's a standalone perl script you can run
anywhere, it contacts a sysdes instance over HTTP via wget/Perl LWP.

Lee=20

-----Original Message-----
From: Cornec, Bruno (Linux Consultant)=20
Sent: Tuesday, June 19, 2007 12:07 PM
To: Mayes, Lee
Cc: lin...@li...
Subject: Re: [Linuxcoe-devel] LinuxCOE 'replay' feature

Mayes, Lee said on Wed, Jun 06, 2007 at 07:26:38PM -0400:

>   Does it look useful? =20

Yes. In fact it's an easy way also for me to do a derivative from a
master configuration. Example, I create the master for what we want as a
standard RHEL4U5 install, and then the infrastructure team just needs to
derive that image for other install. With replay, it's very easy at the
CLI.

> Anything missing? =20

Can we report bugs on a non committed work ;-)

> It's a trivial change to the
> back-ends, and when it's all ready we'll check-in the lot along with=20
> Dan's SIM changes.

Great ! I'm sure other people will find a way to use it as well that you
do not even planned (beauty of FLOSS :-)

Bruno.
--=20
Linux Profession Lead EMEA  / Open Source Evangelist \        HP C&I
EMEA IET
http://www.mondorescue.org / HP/Intel Solution Center \
http://hpintelco.net
Des infos sur Linux?  http://www.HyPer-Linux.org
http://www.hp.com/linux
La musique ancienne?  http://www.musique-ancienne.org
http://www.medieval.org

Re: [Linuxcoe-devel] LinuxCOE 'replay' feature

[Bruno C. <Bru...@hp...>]

Mayes, Lee said on Wed, Jun 06, 2007 at 07:26:38PM -0400:

>   Does it look useful?  

Yes. In fact it's an easy way also for me to do a derivative from a
master configuration. Example, I create the master for what we want as a
standard RHEL4U5 install, and then the infrastructure team just needs to
derive that image for other install. With replay, it's very easy at the
CLI.

> Anything missing?  

Can we report bugs on a non committed work ;-)

> It's a trivial change to the
> back-ends, and when it's all ready we'll check-in the lot along with
> Dan's SIM changes.

Great ! I'm sure other people will find a way to use it as well that you
do not even planned (beauty of FLOSS :-)

Bruno.
-- 
Linux Profession Lead EMEA  / Open Source Evangelist \        HP C&I EMEA IET
http://www.mondorescue.org / HP/Intel Solution Center \  http://hpintelco.net
Des infos sur Linux?  http://www.HyPer-Linux.org      http://www.hp.com/linux
La musique ancienne?  http://www.musique-ancienne.org http://www.medieval.org

Re: [Linuxcoe-devel] LinuxCOE 'replay' feature

[Lee M. <lee...@hp...>]

Daniel Miles wrote:
> On Wednesday 06 June 2007 5:26:38 pm Mayes, Lee wrote:
>   
>>   Does it look useful?  Anything missing?  It's a trivial change to the
>> back-ends, and when it's all ready we'll check-in the lot along with
>> Dan's SIM changes.
>>     
>
> ...Maybe I'm missing the point but I'm not clear about what this modification 
> does that "cp" doesn't do. Are the ISOs that replay generates different from 
> eachother?
>   
Exactly.  We have mass deployments in data centers that do not allow PXE 
or DHCP.   I know that sounds odd, but that's where it's at.  If you 
feed replay the same file, you'll get the same ISO.  But you can tweak 
this file for things like hostname/IP and re-toss it, vs. walking 
through the GUI for each unique ISO you need to generate.   That's the 
main attraction and feature IMO.   There's a sample use-case on the web 
page.

Best Regards,

Lee

Re: [Linuxcoe-devel] LinuxCOE 'replay' feature

[Daniel M. <dan...@hp...>]

On Wednesday 06 June 2007 5:26:38 pm Mayes, Lee wrote:
>   Does it look useful?  Anything missing?  It's a trivial change to the
> back-ends, and when it's all ready we'll check-in the lot along with
> Dan's SIM changes.

...Maybe I'm missing the point but I'm not clear about what this modification 
does that "cp" doesn't do. Are the ISOs that replay generates different from 
eachother?

[Linuxcoe-devel] LinuxCOE 'replay' feature

[Mayes, L. <lee...@hp...>]

Hello All,

  One thing I (and others) have been thinking about for a while is a
'replay' feature for System Designer.  While 100% unrelated to dploy,
some of the API's could be exploited.  It's also a different slice on
Dan Mile's multi-serial number SIM patch (which is almost ready to check
in, preseed is giving me a bit of a fit).

  I called this replay, though it's probably not the best name for it.
I've got a little page up for you to look at,
comments/criticisms/feedback in general appreciated:

http://mayeses.com/temp/replay/

  Does it look useful?  Anything missing?  It's a trivial change to the
back-ends, and when it's all ready we'll check-in the lot along with
Dan's SIM changes.

Best Regards,

Lee
--
Lee Mayes
Portfolio Delivery Engineering - Infrastructure Services / LinuxCOE
Atlanta, GA=20

Re: [Linuxcoe-devel] =?iso-8859-1?q?=5BPATCH=5D_patches_for_multiple-?= =?iso-8859-1?q?serial_numbers_SIM=09installs?=

[Daniel M. <dan...@hp...>]

On Tuesday 05 June 2007 11:44:09 am Lee Mayes wrote:
> Hi Daniel,
>
>   I have a couple of questions for you.  I've incorporated your patches
> in my upstream here to start testing but have not checked anything in
> yet.  A few questions/observations:
>
>   When your code is in play, I noticed you can no longer enter a single
> serial number (but of course you could create a file with a single s/n
> in it).  Is this the desired behavior or should I change things to allow
> either single serial number or a file of serial numbers?

Technically I suppose it was desired behavior, but I'm not opposed to allowing 
both.

>
>   Looking at the changes in nph-coe_image (kickstart generator
> back-end), I see you load the file into an array (@serial), pop the
> first value off of it for the initial generation, then basically symlink
> the rest of the results based on data values from the file.  I'm going
> to add some defensive code here, as someone nasty could for example use
> ../../../../../etc/passwd as a serial # in the file and the code would
> attempt to crush that file.  Granted standard unix perms would prevent
> that one, but any file the apache user could write to is portentially
> vulnerable.

Ooh, good catch... I didn't allow users to name their own files when they 
uploaded them, but I never thought about this one.

Do you think it'd be appropriate to just add code that checked for ".." in the 
line, and refused to create the file if it finds it?

Re: [Linuxcoe-devel] [PATCH] patches for multiple-serial numbers SIM installs

[Lee M. <lee...@hp...>]

Daniel Miles wrote:
> Hi, everybody.
>
> I've attached some patches that I think might be fun to get into the LinuxCOE 
> repository.
>
> coe_bootimage.in.patch changes the Serial Number field to accept a file, and 
> handles the upload. Each line in the updated file is read as a string and 
> interpreted as a serial number.
>
> nph-coe_image.in.patch changes the rpm-based image creation to behave 
> correctly given an uploaded file instead of a single serial number
>
> nph-debian_image.in.patch does the same thing for debian (patches for other 
> distros are in the works)
>
> LinuxCOE-SystemDesigner.conf.in.patch adds the AddType text/html .shtml and 
> AddOutputFilter INCLUDES .shtml directives because I think they should be in 
> there. I know it's a matter of preference, so I won't be overly disappointed 
> if this one doesn't make it in. :)
>
> tests.patch contains what I hope will be the first and the most crude 
> unit-test using the CGI::Test cpan module.
>   
> ------------------------------------------------------------------------
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys-and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> ------------------------------------------------------------------------
>
> _______________________________________________
> Linuxcoe-devel mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linuxcoe-devel
>   
Hi Daniel,

  I have a couple of questions for you.  I've incorporated your patches 
in my upstream here to start testing but have not checked anything in 
yet.  A few questions/observations:

  When your code is in play, I noticed you can no longer enter a single 
serial number (but of course you could create a file with a single s/n 
in it).  Is this the desired behavior or should I change things to allow 
either single serial number or a file of serial numbers?

  Looking at the changes in nph-coe_image (kickstart generator 
back-end), I see you load the file into an array (@serial), pop the 
first value off of it for the initial generation, then basically symlink 
the rest of the results based on data values from the file.  I'm going 
to add some defensive code here, as someone nasty could for example use 
../../../../../etc/passwd as a serial # in the file and the code would 
attempt to crush that file.  Granted standard unix perms would prevent 
that one, but any file the apache user could write to is portentially 
vulnerable.

  I haven't looked at pressed or autoyast back-ends yet.

  There's also a new System Designer feature under development I'm 
calling 'replay' for lack of a better term.  What this allows you to do 
is essentially toss a file at the back-end that answers all the 
front-end questions and have the back-ends do their thing.   Today I 
leave that file on every install under /etc/opt/LinuxCOE/replay, I'm 
going to start working on the 'catcher' part of it soon.   It'll be 
another way to create lots of distinct (or near-identical) images as well.

Best Regards,

Lee

Re: [Linuxcoe-devel] [PATCH] patches for multiple-serial numbers SIM installs

[Daniel M. <dan...@hp...>]

In order to make life easier for anybody trying to review these patches, I'm 
submitting them again in a more sane, complete format.

My goal in making these changes is to allow the "SIM integration" work that's 
already been done to respond to more than one machine. In other words, to 
allow an administrator to specify multiple serial numbers. Eventually I hope 
this will be useful to help LinuxCOE couple with more complete manageability 
solutions like SIM so that a user can select a machine or group of machines 
in SIM and SIM can pass the list of serials to LinuxCOE.

The actual change is to change the Serial Number field in Step1 of 
coe_bootimage to accept a file containing multiple serial numbers (one serial 
per line). Then I had to make small changes to each of nph-coe_image, 
nph-debian_image and nph-suse_image to have them upload and parse the 
uploaded file instead of getting a single serial from POST. I set them to use 
one of the serials as the "real" directory and create symlinks to it for all 
of the other serial numbers in $simdir. That also meant that I had to change 
the $simdir/$serial/$serial file to something more generic, I chose 
$simdir/$serial/CUSTOM_SETTINGS. This will require a change in SSSTK.

The other files in here are some CGI::Test scripts that provide regression 
tests for the new functionality I've provided. I've also included some tests 
in test_coe_bootimage.pl for functionality I did not provide, hoping it will 
make a good rally point so that whatever unit tests other people develop will 
be similar. I've included a README file that describes how to run the tests 
for the time being, but I intend to write a wrapper to execute and tally all 
of the tests.

Re: [Linuxcoe-devel] [PATCH] patches for multiple-serial numbers SIM installs

[Daniel M. <dan...@hp...>]

On Wednesday 04 April 2007 3:23 pm, Daniel Miles wrote:
> On Wednesday 04 April 2007 2:57 pm, Bryan Gartner wrote:
> > > tests.patch contains what I hope will be the first and the most crude
> > > unit-test using the CGI::Test cpan module.
> >
> > This is an excellent find and would have saved me many hours of
> > walking the WebUI looking for issues.  BTW, is there any chance
> > you might consider making this a somewhat self generated script,
> > in that it could use the SystemDesigner libraries to read the
> > various config files, and then create a script to ensure the
> > WebUI elements are present (and that the resulting image/profile/retrofit
> > script are as expected?
>
> I'm glad you asked that question, I've already gone half-way there in a
> revision to the test script (patch attached, along with a shell script to
> invoke it). It uses the LinuxCOE.pm module to get the SIM directory,
> $db->def('SIM'). I think it should be quite easy to write a script that
> checks for the web UI elements and determines pass/fail based on all the
> various config files. It's not exactly what you were asking for, but I
> suspect it will serve the same purpose. Let me work up an example of what
> I'm talking about and it might be more clear.

Ok, I created and attached a starter for something that I think might do what 
you were asking about.

Re: [Linuxcoe-devel] [PATCH] patches for multiple-serial numbers SIM installs

[Daniel M. <dan...@hp...>]

On Wednesday 04 April 2007 2:57 pm, Bryan Gartner wrote:
> > tests.patch contains what I hope will be the first and the most crude
> > unit-test using the CGI::Test cpan module.
>
> This is an excellent find and would have saved me many hours of
> walking the WebUI looking for issues.  BTW, is there any chance
> you might consider making this a somewhat self generated script,
> in that it could use the SystemDesigner libraries to read the
> various config files, and then create a script to ensure the
> WebUI elements are present (and that the resulting image/profile/retrofit
> script are as expected?

I'm glad you asked that question, I've already gone half-way there in a 
revision to the test script (patch attached, along with a shell script to 
invoke it). It uses the LinuxCOE.pm module to get the SIM directory, 
$db->def('SIM'). I think it should be quite easy to write a script that 
checks for the web UI elements and determines pass/fail based on all the 
various config files. It's not exactly what you were asking for, but I 
suspect it will serve the same purpose. Let me work up an example of what I'm 
talking about and it might be more clear.

>
> Have you created an sf.net user yet, so that we could add you
> to the development team?

Yep, just went out and did it, my SF id is 'milesd'

>
> bryang

Re: [Linuxcoe-devel] [PATCH] patches for multiple-serial numbers SIM installs

[Bryan G. <Bry...@HP...>]

Daniel,

> I've attached some patches that I think might be fun to get into the LinuxCOE 
> repository.

These is great thinking, and expands our current SIM interoperability
in a way that doesn't compromise the current use case.

> coe_bootimage.in.patch changes the Serial Number field to accept a file, and 
> handles the upload. Each line in the updated file is read as a string and 
> interpreted as a serial number.
> 
> nph-coe_image.in.patch changes the rpm-based image creation to behave 
> correctly given an uploaded file instead of a single serial number
> 
> nph-debian_image.in.patch does the same thing for debian (patches for other 
> distros are in the works)

It may take us a few days to completely digest the changes suggested,
and ensure compatibility with current functions.  Besides our lead
coder is currently on vacation, and I would definitely like to
have him review these as well before implementation.

> LinuxCOE-SystemDesigner.conf.in.patch adds the AddType text/html .shtml and 
> AddOutputFilter INCLUDES .shtml directives because I think they should be in 
> there. I know it's a matter of preference, so I won't be overly disappointed 
> if this one doesn't make it in. :)

Heh, I have debated this issue over time, and as soon as I can do some
more distribution testing, will probably implement "just do it".

> tests.patch contains what I hope will be the first and the most crude 
> unit-test using the CGI::Test cpan module.

This is an excellent find and would have saved me many hours of
walking the WebUI looking for issues.  BTW, is there any chance
you might consider making this a somewhat self generated script,
in that it could use the SystemDesigner libraries to read the
various config files, and then create a script to ensure the
WebUI elements are present (and that the resulting image/profile/retrofit
script are as expected?

Have you created an sf.net user yet, so that we could add you
to the development team?

bryang

Re: [Linuxcoe-devel] Mandriva support

[Lee M. <lee...@hp...>]

Bruno Cornec wrote:
> Hello Lee,
>
> As I'm maybe more concerned than you by this support, do you think you
> could put under CVS what you already have for Mandriva support ?
>
> that would allow me to look at it and give feedback.
> TIA,
> Bruno.
>   
Hi Bruno,

  Ok, here's where I'm at.  The script creates viable auto_inst.cfg 
files that follow the same convention as our others 
(preseed/kickstart/autoyast) to invoke our post-processing environment 
to install and configure yum and optionally bundles.   However, I have 
had *NO* luck creating a 'standalone' ISO to install from.  The 
following methods work:

1) Custom ISO + Floppy (containing auto_inst.cfg)
2) Custom ISO + Web vended auto_inst.cfg (if hosted in INSTALL TREE)
3) 2 floppy install (network.img with auto_inst.cfg  in it + 
network_driver.img)

Here's a sample of the config file with LinuxCOE post processing enabled:

http://mayeses.com/temp/auto_inst.cfg.txt

The installing box was pulling this file from my webserver via this in 
isolinux.cfg:

label install
  kernel alt0/vmlinuz
  append initrd=alt0/all.rdz kickstart=auto_inst.cfg 
automatic=met:http,interface:eth0,ser:192.168.1.5,dir:/LinuxCOE/Mandrake/2007.0/i586,netw:static,ip:192.168.1.181,netm:255.255.255.0,gat:192.168.1.5,dns:192.168.1.5 
vga=788 splash=silent

What I need is a way to reference auto_inst.cfg on the bootable ISO!  It 
tried creating an ISO out of network.img, but I just get 'boot error'.  
Even *before* I add the config file, I did this with:

mkdir iso
cp network.img iso
mkisfs -o test.iso -b network.img iso/

It appears that Mandriva's auto install process can only find the 
auto_inst.cfg file in 2 locations:

1) Floppy (literally, /dev/fd0).
2) On a path on your install source based on method.

AutoYast, kickstart, etc. have a little more configurability in their 
isolinux/syslinux.cfg, you can use directives like:

kickstart=file:///path/filename (look in initrd)
kickstart=cdrom:///path/filename (look in root of CD)
kickstart=http://server/url (look here, not in install tree)
etc.

If that's available on Mandriva, I'm missing it.  If you can take the 
auto_inst.cfg file referenced above and embedded it in a bootable ISO 
that references it, I'll be happy to reverse engineer what you send me 
and codify it.  For now, when I finish, I will offer the following options:

1) ISO + Floppy
2) 2 Floppy (network.img + network_driver.img)

FWIW, the current code is checked in at 
SystemDesigner/cgi-bin/nph-mandriva_image.in.  I'll work with byrang to 
create a SystemDesigner-Mandriva to house the needed data/boot/etc. stuff.

Best Regards,

Lee

Re: [Linuxcoe-devel] Mandriva support

[Bruno C. <Bru...@hp...>]

Hello Lee,

As I'm maybe more concerned than you by this support, do you think you
could put under CVS what you already have for Mandriva support ?

that would allow me to look at it and give feedback.
TIA,
Bruno.
-- 
Linux Profession Lead EMEA  / Open Source Evangelist \        HP C&I EMEA IET
http://www.mondorescue.org / HP/Intel Solution Center \  http://hpintelco.net
Des infos sur Linux?  http://www.HyPer-Linux.org      http://www.hp.com/linux
La musique ancienne?  http://www.musique-ancienne.org http://www.medieval.org

Re: [Linuxcoe-devel] Installation of LinuxCOE

[Bruno C. <Bru...@hp...>]

Hello !

Bryan Gartner said on Fri, Mar 09, 2007 at 09:20:10AM -0700:

> FWIW, I have the tools to create this, but don't distribute this by
> default (since I know you can serve the html file, and can also view
> it, but can't be so sure of pdf, albeit that is very likely in this
> day/age).  In the docs/guides subdir, you could do:
> 
> 	make -f Makefile.transform

Ok.

> 	make -f Makefile.transform html
> Only caveat, is that you may have to change the XSLSTYLE parameter to
> match your system's location of that file.

Doesn't work (no rules to make target). As you said, I had to adapt the
docbook.xls location, in order for it to generate something useful.

> 	make -f Makefile.transform pdf

OK. But after that  ? It created the pdf.in files (which are html files
btw) but I don't see what to make from them ?

> That said, if you think I should distribute the PDF version, I would be happy
> to include it, moving forward.

Maybe ;-) 


Ok, as I do not like to stay on a failure, I used my mondo method which
worked without issue for that case :

docbook2pdf file.dkb 

Simple no ;-)
I now have the guides I can send to the customer (admin and user guides)

Thanks !
Bruno.
-- 
Linux Profession Lead EMEA  / Open Source Evangelist \        HP C&I EMEA IET
http://www.mondorescue.org / HP/Intel Solution Center \  http://hpintelco.net
Des infos sur Linux?  http://www.HyPer-Linux.org      http://www.hp.com/linux
La musique ancienne?  http://www.musique-ancienne.org http://www.medieval.org