was there an advertised ETA for the next beta?

[Robert P. J. Day]

  no, i'm not just asking when the next beta is.  more specifically,
i vaguely recall some mention of mid-august for a renewed beta.
was there such a hint somewhere?

rday

[Gerry Tool]

Robert P. J. Day wrote:
>    no, i'm not just asking when the next beta is.  more
> specifically,
>  i vaguely recall some mention of mid-august for a renewed beta.
>  was there such a hint somewhere?
>   
The published schedule said the second beta would be available 8/18/2003.

Gerry

[Robert P. J. Day]

On Mon, 11 Aug 2003, Gerry Tool wrote:

>  Robert P. J. Day wrote:
>  >   no, i'm not just asking when the next beta is.  more specifically,
>  > i vaguely recall some mention of mid-august for a renewed beta.
>  > was there such a hint somewhere?
>  > 
>  The published schedule said the second beta would be available 8/18/2003. 
ok, that's the info i was after, thanks.

rday

[Gerry Tool]

Robert P. J. Day wrote:
>    no, i'm not just asking when the next beta is.  more
> specifically,
>  i vaguely recall some mention of mid-august for a renewed beta.
>  was there such a hint somewhere?
>   
Now that I read your message more carefully, perhaps you're asking about 
updates to the current beta.  I remember a statement that updates would 
likely be made available to at least check the up2date process. 
However, it vaguely said something like "this week" or "next week"
which 
  would make it due sometime this week.

Gerry

[M A Young]

On Mon, 11 Aug 2003, Robert P. J. Day wrote:

>    no, i'm not just asking when the next beta is.  more
> specifically,
>  i vaguely recall some mention of mid-august for a renewed beta.
>  was there such a hint somewhere? 
A timetable was on the rhl site http://rhl.redhat.com/ before they closed
it to rework it. Note that it has been rumoured on the list that this
timetable may slip by a couple of weeks to allow gnome 2.4 to be
incorporated.

	Michael Young

[Rik van Riel]

On Mon, 11 Aug 2003, M A Young wrote:

>  A timetable was on the rhl site http://rhl.redhat.com/ before they
> closed
>  it to rework it. Note that it has been rumoured on the list that this
>  timetable may slip by a couple of weeks to allow gnome 2.4 to be
>  incorporated. 
If you have other cool ideas on what should be included,
don't hesitate to let us know ;)

-- 
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it." - Brian W. Kernighan

APT? [WAS: was there an advertised ETA for the next beta?]

[Jared Smith]

Is apt going to make it, or just yum?  (Or, in other words, am I really
gonna have to break down and learn yum?)

Jared Smith


On Mon, 2003-08-11 at 15:07, Rik van Riel wrote:
>  On Mon, 11 Aug 2003, M A Young wrote:
>  
>  > A timetable was on the rhl site http://rhl.redhat.com/ before they closed
>  > it to rework it. Note that it has been rumoured on the list that this
>  > timetable may slip by a couple of weeks to allow gnome 2.4 to be
>  > incorporated.
>  
>  If you have other cool ideas on what should be included,
>  don't hesitate to let us know ;)

APT? [WAS: was there an advertised ETA for the next beta?]

[Robert P. J. Day]

On 11 Aug 2003, Jared Smith wrote:

>  Is apt going to make it, or just yum?  (Or, in other words, am I
> really
>  gonna have to break down and learn yum?) 
on a more philosophical note, is it necessary to have made an iron-clad
decision to include a package in the next official release for it to 
be in the beta?

using the above as an example, is it feasible to include apt, and
use the next beta period as a shakedown?  if anything goes amiss,
yank it out of the official release.  if all goes well with apt, it
stays.

is this workable?  adding something to the upcoming beta would seem
a good way of identifying any bugs in a hurry.

rday

APT, Yum and Red Carpet

[Hans Deragon]

> >Is apt going to make it, or just yum?  (Or, in other words, am I
> really
> >gonna have to break down and learn yum?) 
IMHO, we should stick with one upgrade system only.  Lets take the best 
and support it.  The last thing I want is a community with full of 
repositories, half apt and half yum.  Its time to make a standard for 
package distribution within Red Hat and we should use one system wisely. 
  I do not care which one it is, as long as it is the best.

It would be very couterproductive for my grandma to have to use apt for 
installing one appl, and yum for installing another.  Imagine that she 
has to first browse the list of apps available through apt, do not find 
the software and then browse through the list of apps on yum.  Not very 
intuitive.  Not the way to go.  This is one case where competition is 
not welcomed, but a standard is.

However, apt has synaptic available as GUI.  I am not aware of a GUI for 
yum.  For a desktop machine, a GUI is a must.

There is also ximian's red carpet that could do the work.

BTW, I joined the mailing list a week ago.  I presume that the debate of 
yum vs apt has already been done.  Sorry if I repeat info here again.


Best regards,
Hans Deragon
--
Consultant en informatique/Software Consultant
Deragon Informatique inc.         Open source:
http://www.deragon.biz            http://swtmvcwrapper.sourceforge.net
mailto://[e-mail]         http://autopoweroff.sourceforge.net

APT, Yum and Red Carpet

[Panu Matilainen]

Quoting Hans Deragon <hans(a)deragon.biz&gt;:

>  >>Is apt going to make it, or just yum?  (Or, in other words,
> am I really
>  >>gonna have to break down and learn yum?)
>  
>  IMHO, we should stick with one upgrade system only.  Lets take the best 
>  and support it.  The last thing I want is a community with full of 
>  repositories, half apt and half yum.  Its time to make a standard for 
>  package distribution within Red Hat and we should use one system wisely. 
>    I do not care which one it is, as long as it is the best.
>  
>  It would be very couterproductive for my grandma to have to use apt for 
>  installing one appl, and yum for installing another.  Imagine that she 
>  has to first browse the list of apps available through apt, do not find 
>  the software and then browse through the list of apps on yum.  Not very 
>  intuitive.  Not the way to go.  This is one case where competition is 
>  not welcomed, but a standard is.
>  
>  However, apt has synaptic available as GUI.  I am not aware of a GUI for 
>  yum.  For a desktop machine, a GUI is a must.
>  
>  There is also ximian's red carpet that could do the work.
>  
>  BTW, I joined the mailing list a week ago.  I presume that the debate of 
>  yum vs apt has already been done.  Sorry if I repeat info here again. 
The big thing here is to get all the updaters support a common repository
metadata format, once that's done everybody gets to choose their favorite
updater/installer. It's being talked about but there's a long way to go...

    - Panu -

APT, Yum and Red Carpet

[seth vidal]

>  The big thing here is to get all the updaters support a common
> repository
>  metadata format, once that's done everybody gets to choose their favorite
>  updater/installer. It's being talked about but there's a long way to go...
It'd go faster if _certain people_ would respond to emails ;)
<wink><wink>

-sv

APT, Yum and Red Carpet

[Peter Backlund]

>  > However, apt has synaptic available as GUI.  I am not aware of a
> GUI for
>  > yum.  For a desktop machine, a GUI is a must. 
Are there any plans for supporting yum in redhat-config-packages?

/Peter

APT, Yum and Red Carpet

[seth vidal]

On Tue, 2003-08-12 at 09:01, Peter Backlund wrote:
>  > > However, apt has synaptic available as GUI.  I am not aware
> of a GUI for
>  > > yum.  For a desktop machine, a GUI is a must.
>  
>  Are there any plans for supporting yum in redhat-config-packages?
>   
If all the repository metadata are in the same format then there is no
need for special 'support of yum in r-c-p'. It will just work.

That would be the goal.
-sv

APT, Yum and Red Carpet

[Jos Vos]

On Tue, Aug 12, 2003 at 08:36:34AM -0400, Hans Deragon wrote:

>  IMHO, we should stick with one upgrade system only.  Lets take the
> best 
>  and support it.  The last thing I want is a community with full of 
>  repositories, half apt and half yum.  Its time to make a standard for 
>  package distribution within Red Hat and we should use one system wisely. 
>    I do not care which one it is, as long as it is the best. 
Well, if life was that easy... then we just could choose "the best"
of everything.  But that's not the reality.  There are advantages
and disadvantages, different tastes, etc.

>  It would be very couterproductive for my grandma to have to use apt
> for 
>  installing one appl, and yum for installing another.  Imagine that she 
>  has to first browse the list of apps available through apt, do not find 
>  the software and then browse through the list of apps on yum.  Not very 
>  intuitive.  Not the way to go.  This is one case where competition is 
>  not welcomed, but a standard is. 
Expect for that fact that a repository could easily support both APT
and Yum (both are just a set of additional files on the webserver),
I would not want my grandma to install software of any repository ;-).

>  However, apt has synaptic available as GUI.  I am not aware of a GUI
> for 
>  yum.  For a desktop machine, a GUI is a must. 
It depends on the type of use.  For centrally maintained systems,
no non-command-line interface is needed.  Although I admit that
it would be nice if a system supports both worlds.

>  There is also ximian's red carpet that could do the work. 
Well... ;-)

>  BTW, I joined the mailing list a week ago.  I presume that the debate
> of 
>  yum vs apt has already been done.  Sorry if I repeat info here again. 
Do you really think there is a conclusion drawn? ;-)

-- 
--    Jos Vos <jos(a)xos.nl&gt;
--    X/OS Experts in Open Systems BV   |   Phone: [phone]
--    Amsterdam, The Netherlands        |     Fax: [phone]

APT, Yum and Red Carpet

[James Olin Oden]

On Tue, 12 Aug 2003, Jos Vos wrote:

>  On Tue, Aug 12, 2003 at 08:36:34AM -0400, Hans Deragon wrote:
>  
>  > IMHO, we should stick with one upgrade system only.  Lets take the best 
>  > and support it.  The last thing I want is a community with full of 
>  > repositories, half apt and half yum.  Its time to make a standard for 
>  > package distribution within Red Hat and we should use one system wisely. 
>  >   I do not care which one it is, as long as it is the best.
>  
>  Well, if life was that easy... then we just could choose "the best"
>  of everything.  But that's not the reality.  There are advantages
>  and disadvantages, different tastes, etc.
>  
>  > It would be very couterproductive for my grandma to have to use apt for 
>  > installing one appl, and yum for installing another.  Imagine that she 
>  > has to first browse the list of apps available through apt, do not find 
>  > the software and then browse through the list of apps on yum.  Not very 
>  > intuitive.  Not the way to go.  This is one case where competition is 
>  > not welcomed, but a standard is.
>  
>  Expect for that fact that a repository could easily support both APT
>  and Yum (both are just a set of additional files on the webserver),
>  I would not want my grandma to install software of any repository ;-).
>  
Once a common metadata format is decided upon this will be even more easy,
as the repositories will store one metadata format, and all the same
rpms.

Cheers...james

APT, Yum and Red Carpet

[Hoyt]

On Tuesday 12 August 2003 10:10, James Olin Oden wrote:
>  Once a common metadata format is decided upon this will be even more
> easy,
>  as the repositories will store one metadata format, and all the same
>  rpms. 
Rather than common metadata, how about a common app that creates the necessary 
metadata in all formats? That may not be as elegant, but it would address the 
problem a lot faster than it would ever be possible to get everyone to agree 
to a common format.  

-- 
Hoyt

APT, Yum and Red Carpet

[seth vidal]

On Tue, 2003-08-12 at 11:07, HoytDuff wrote:
>  On Tuesday 12 August 2003 10:10, James Olin Oden wrote:
>  > Once a common metadata format is decided upon this will be even more easy,
>  > as the repositories will store one metadata format, and all the same
>  > rpms.
>  
>  Rather than common metadata, how about a common app that creates the necessary 
>  metadata in all formats? That may not be as elegant, but it would address the 
>  problem a lot faster than it would ever be possible to get everyone to agree 
>  to a common format.   
it hurts mirror maintainers. I don't want to carry around 4 copies of
the same data.

-sv

APT, Yum and Red Carpet

[Hoyt]

On Tuesday 12 August 2003 11:08, seth vidal wrote:

>  it hurts mirror maintainers. I don't want to carry around 4 copies of
>  the same data. 
True, but the metadata is small in comparison to the aggregate size of other 
files. It's only an interim solution, but one that could happen quicker than 
an agreement on a shared format.

-- 
Hoyt

APT, Yum and Red Carpet

[seth vidal]

On Tue, 2003-08-12 at 12:38, HoytDuff wrote:
>  On Tuesday 12 August 2003 11:08, seth vidal wrote:
>  
>  >
>  > it hurts mirror maintainers. I don't want to carry around 4 copies of
>  > the same data.
>  
>  True, but the metadata is small in comparison to the aggregate size of other 
>  files. It's only an interim solution, but one that could happen quicker than 
>  an agreement on a shared format. 

When your drives are already near capacity then 'small in comparison to 
the total size' is not terribly small.

-sv

APT? [WAS: was there an advertised ETA for the next beta?]

[seth vidal]

On Mon, 2003-08-11 at 17:18, Jared Smith wrote:
>  Is apt going to make it, or just yum?  (Or, in other words, am I
> really
>  gonna have to break down and learn yum?) 
You know you could just grab apt from any of a number of places and use
it with the next beta release. I'm sure freshrpms and/or fedora will
have apt packages available for it.

Having said that, yum really isn't very hard to learn.

-sv

[David Woodhouse]

On Mon, 2003-08-11 at 22:07, Rik van Riel wrote:
>  On Mon, 11 Aug 2003, M A Young wrote:
>  
>  > A timetable was on the rhl site http://rhl.redhat.com/ before they closed
>  > it to rework it. Note that it has been rumoured on the list that this
>  > timetable may slip by a couple of weeks to allow gnome 2.4 to be
>  > incorporated.
>  
>  If you have other cool ideas on what should be included,
>  don't hesitate to let us know ;) 
http://www.lysator.liu.se/fsh/

-- 
dwmw2

[Daniel Veillard]

On Mon, Aug 11, 2003 at 05:07:21PM -0400, Rik van Riel wrote:
>  On Mon, 11 Aug 2003, M A Young wrote:
>  
>  > A timetable was on the rhl site http://rhl.redhat.com/ before they closed
>  > it to rework it. Note that it has been rumoured on the list that this
>  > timetable may slip by a couple of weeks to allow gnome 2.4 to be
>  > incorporated.
>  
>  If you have other cool ideas on what should be included,
>  don't hesitate to let us know ;) 
 You asked for it :-)

 I would like to add xmlsec ...
  Web site is at:
    http://www.aleksey.com/xmlsec/

 This library is an extension to libxml2 core implementing the
W3C XML Digital Signature, Encryption and Canonical representation
standards.
 It does not implement cryptography algorithms directly but reuses
the ones found in OpenSSL and other libraries like GnuTLS and NSS
if those are found at compile time.
 I don't know any open source project using those at the moment, but
it is in my opinion an important part of the XML platform that we can
provide to business oriented users.
  I think the library is already in production use from the feedback
I got from Aleksey Sanin (main developper) and looking at their list
archive. The library is known to be the fastest public implementation
of those algorithms, the code looks good, and is compliant to the spec.
The licence is MIT, like libxml2 and libxslt.

  Rpm packages are part of the source distribution, once commented out
the part about the NSS package in the spec file, they built cleanly on
my RH9 laptop and produced the following packages:
    -rw-rw-r--    1 veillard www        574061 Aug  3 14:06
/u/veillard/rpms/RPMS/i386/xmlsec1-1.0.4-1.i386.rpm
    -rw-rw-r--    1 veillard www        609486 Aug  3 14:06
/u/veillard/rpms/RPMS/i386/xmlsec1-devel-1.0.4-1.i386.rpm
    -rw-rw-r--    1 veillard www       1048090 Aug  3 14:06
/u/veillard/rpms/SRPMS/xmlsec1-1.0.4-1.src.rpm

  Alesey code is usually portable and without maintainance troubles
(I integrated part of his work directly on libxml2), so I'm confident
that there shouldn't be any maintainance or portability problem with
this package.

Daniel


-- 
Daniel Veillard      | Red Hat Network https://rhn.redhat.com/
veillard(a)redhat.com  | libxml GNOME XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/

[Kyle Maxwell]

On Mon, 2003-08-11 at 16:07, Rik van Riel wrote:
>  If you have other cool ideas on what should be included,
>  don't hesitate to let us know ;) 
Now *there's* a question sure to generate traffic...

I'd really like to see Tripwire (or AIDE) back in. I think a host-based
IDS like this with a reasonable default would be a nice addition. I
understand that it was yanked due to developer resource constraints, but
maybe this is where the community involvement comes in.
-- 
Kyle Maxwell <kylem(a)xwell.org&gt;

AIDE/Tripwire (was: Re: was there an advertised ETA for the next beta?)

[Michael Schwendt]

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

On Mon, 11 Aug 2003 17:40:07 -0500, Kyle Maxwell wrote:

>  I'd really like to see Tripwire (or AIDE) back in. I think a
> host-based
>  IDS like this with a reasonable default would be a nice addition. I
>  understand that it was yanked due to developer resource constraints, but
>  maybe this is where the community involvement comes in. 
Packaging mhash and AIDE wouldn't be a problem. 

But what is your experience with AIDE? I have it on my watch-list for
some time, as a replacement for Tripwire (which doesn't seem to be
actively maintained for a long time, last release March 3rd, 2001).
Based on my first try and various reports on the net (e.g. Debian's), I
think AIDE has quite some bugs and there may be more sleeping ones.
IIRC, I also tried a rebuilt rpm from Mandrake Contrib and got
unexpected errors upon running "aide -check" (I think, open_dir() failed
on lots of files below /usr/share). Additionally, the Debian package
includes several fixes as well as helper scripts in several languages.
Raises the question, how much package enhancement would be desired? And
what helper scripts would the average user want/need?

Concerning Tripwire, if it still compiles, probably the most work would
go into creating a default policy file that covers all or at least the
most important parts of the distribution. I don't know how Red Hat have
created the default file, but it *might* be an idea to automate it based
on the files listed in rpmdb-redhat.

- -- 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.2 (GNU/Linux)
>
> iD8DBQE/OHoP0iMVcrivHFQRAgILAJ9c31KLCIFHj3ZpJS+oAmW+lXxNQACeI0Bv
> P42xZqvHbVZpsIgd1l52UNY=
> =T0A6
> -----END PGP SIGNATURE-----

AIDE/Tripwire (was: Re: was there an advertised ETA for the next beta?)

[Leonard den Ottolander]

Hi Michael,

>  I don't know how Red Hat have
>  created the default file, but it *might* be an idea to automate it based
>  on the files listed in rpmdb-redhat. 
 You don't really need the rpmdb. Just finding all files in the 
relevant directories and generating the twpol from that is quite easy 
to accomplish and causes less overhead than using the rpmdb. Something 
like

for dr in /bin /sbin /usr/bin /usr/sbin /lib 
do
  find /bin -type f -exec echo -e "  {}\t\t\t-> \$(SEC_CRIT2) ;" >> 
twpol.tmp \;
done

(/etc is a bit more difficult than this of course.)

Bye,
Leonard.

--
How clean is a war when you shoot around nukelar waste?
Stop the use of depleted uranium ammo!
End all weapons of mass destruction.

AIDE/Tripwire (was: Re: was there an advertised ETA for the next beta?)

[Michael Schwendt]

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

On Tue, 12 Aug 2003 11:22:30 +0200, Leonard den Ottolander wrote:

>  > I don't know how Red Hat have
>  > created the default file, but it *might* be an idea to automate it based
>  > on the files listed in rpmdb-redhat.
>  
>   You don't really need the rpmdb. Just finding all files in the 
>  relevant directories and generating the twpol from that is quite easy 
>  to accomplish and causes less overhead than using the rpmdb. 
That would require a complete installation.

In both cases, using rpmdb or find, it would require extra logic to
sort the found files into different security categories in order to
make a default Tripwire installation usable. One of the scripts to
drop non-existant files from the policy config should be included,
too.

- -- 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.2 (GNU/Linux)
>
> iD8DBQE/OO1k0iMVcrivHFQRAggyAJ9UfDYHn5q80ktPeLVUew+Bstbg+gCcDiKZ
> 1UZL23EDQQjPbPXnDZ+hHn8=
> =eRRJ
> -----END PGP SIGNATURE-----

AIDE/Tripwire

[Tommy McNeely]

Leonard den Ottolander wrote:

> Hi Michael,
>
>   
>
> >I don't know how Red Hat have
> >created the default file, but it *might* be an idea to automate it based
> >on the files listed in rpmdb-redhat.
> >    
> >
>
>  You don't really need the rpmdb. Just finding all files in the 
> relevant directories and generating the twpol from that is quite easy 
> to accomplish and causes less overhead than using the rpmdb. Something 
> like
>
> for dr in /bin /sbin /usr/bin /usr/sbin /lib 
> do
>   find /bin -type f -exec echo -e "  {}\t\t\t-> \$(SEC_CRIT2) ;" >> 
> twpol.tmp \;
> done
>
> (/etc is a bit more difficult than this of course.)
>
>   
>  
Maybe just setup a magic policy directory (ala /etc/tripwire.d ) .. that 
each RPM can drop its "specs" into and have the policy generated 
automatically or something.. ofcourse i am showing my nievity with 
tripwire.. I think you need like 7 passwords to generate a policy, but 
something along these lines would be nice.

Tommy


-- 
Tommy McNeely   --   Tommy.McNeely(a)Sun.COM
Sun Microsystems   --   IT CTO
Phone/Fax: x51837 / 303-395-3361

AIDE/Tripwire

[Leonard den Ottolander]

Hi Tommy,

>  Maybe just setup a magic policy directory (ala /etc/tripwire.d ) ..
> that
>  each RPM can drop its "specs" into and have the policy generated
>  automatically or something.. 
 Hm. This would require either rpm to be extensively modified to 
catch/generate these specs on (de)installation of every package or 
every single rpm to be rebuild to dump it's specs in /etc/tripwire.d. 
Not an easy solution, not to say infeasible (oops now I said it :).

Bye,
Leonard.

--
How clean is a war when you shoot around nukelar waste?
Stop the use of depleted uranium ammo!
End all weapons of mass destruction.

AIDE/Tripwire

[Mr. Adam ALLEN]

On Wed, 2003-08-13 at 13:13, Leonard den Ottolander wrote:
>  Hi Tommy,
>  
>  > Maybe just setup a magic policy directory (ala /etc/tripwire.d ) .. that
>  > each RPM can drop its "specs" into and have the policy generated
>  > automatically or something..
>   
 
I think it's dangerous to automatically rebuild the database, but
something like: 

 - get the rpm to dump into /etc/tripwire.d
 - alert the user that they should run something like (or aide)
	tripwire --rebuild --parse-specs
 - it would probably be a safe idea to have RH sign the spec file, with
the same key used to sign the RPM, and the only process files out of
/etc/tripwire.d which can have their digital signatures verified. Users
might trust the /etc/tripwire.d contents too much- which is why I think
this step might be necessary.

Need to be really careful that my rpm doesn't drop in a new /etc/passwd.
Since the specfile would list /etc/passwd as a file- would this instruct
tripwire to re-calculate the checksums on /etc/passwd. (Which may have
all the accounts deleted).

Just a quick not-really thought through pitfalls that might exist.


-- 
Regards,
Adam Allen.

adam(a)dynamicinteraction.co.uk
pgp
http://search.keyserver.net:11371/pks/lookup?op=vindex&search=adam%40...

AIDE/Tripwire

[Michael Schwendt]

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

On 13 Aug 2003 14:11:56 +0100, Mr. Adam ALLEN wrote:

>  > > Maybe just setup a magic policy directory (ala
> /etc/tripwire.d ) .. that
>  > > each RPM can drop its "specs" into and have the policy generated
>  > > automatically or something.. 
  
>  I think it's dangerous to automatically rebuild the database,
I think nobody has suggested to rebuild the database automatically.

The question I have raised earlier is whether to ship a default
policy file that covers a full install of the distribution? And in
case this is desired, whether and how to create it manually or
automatically? Especially Tripwire uses policy directives which
sort files into different security levels.

Users of Tripwire and Red Hat Linux moan about a default policy file
that covers files which are not installed actually. This creates
security reports which include many "file does not exist" warnings.
The tools to drop such files from the config are not included. You
can create a rough Perl script yourself or try to find an existing
one via Google. But that only shows that the package is incomplete
and needs enhancement.

Tommy McNeely's suggestion to tie RPM to the IDE by using a ``magic
policy directory (ala /etc/tripwire.d ) .. that each RPM can drop
its "specs" into'' is ridiculous IMHO. Just note, that a) the
Tripwire project page looks abandoned for a long time, that b)
the information in those tripwire.d files is very likely not
different from what is contained within the rpmdb-redhat already,
and that c) nobody would maintain extra information which could
not be extracted from src.rpms/rpmdb automatically.

Every solution which requires additional maintenance is out of
question.

Red Hat have dropped Tripwire due to resource constraints. Resource
constraints are not specific to Red Hat. A community packager is
also affected by resource constraints. 

- -- 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.2 (GNU/Linux)
>
> iD8DBQE/OlUe0iMVcrivHFQRAihEAJ9Qq7sMxPmVUDVc0gT8sQP6tX6IbwCfUc09
> B6Tx6ZNjsrZF+ThGnztGWVA=
> =wtpd
> -----END PGP SIGNATURE-----

AIDE/Tripwire

[Mr. Adam ALLEN]

On Wed, 2003-08-13 at 16:11, Michael Schwendt wrote:
>  On 13 Aug 2003 14:11:56 +0100, Mr. Adam ALLEN wrote:  
>  > I think it's dangerous to automatically rebuild the database,
>
>  I think nobody has suggested to rebuild the database automatically. 
No nobody has, but a logical next step I guessed might be that if we
have the files that rpm modified (/etc/tripwire.d) then why not just
take care of it automatically.

>  The question I have raised earlier is whether to ship a default
>  policy file that covers a full install of the distribution? And in
>  case this is desired, whether and how to create it manually or
>  automatically? Especially Tripwire uses policy directives which
>  sort files into different security levels. 
The closest to an answer I have is to create the a full policy- shipped
with a small perl(or your favourite language) script to remove files not
installed on the system before feeding that list to tripwire. Though
this list would of course need to be maintained as you point out. 


>  Tommy McNeely's suggestion to tie RPM to the IDE by using a
> ``magic
>  policy directory (ala /etc/tripwire.d ) .. that each RPM can drop
>  its "specs" into'' is ridiculous IMHO. Just note, that a) the
>  Tripwire project page looks abandoned for a long time, that b)
>  the information in those tripwire.d files is very likely not
>  different from what is contained within the rpmdb-redhat already,
>  and that c) nobody would maintain extra information which could
>  not be extracted from src.rpms/rpmdb automatically.
>   
If on an upgrade of apache the new files are listed in
/etc/tripwire.d/apache then the updates the tripwire database using this
information as a template- that could make it easier to just update the
upgraded files. 

Of course, all that is really needed is the name of the rpm that has
been upgraded, the spec file really isn't required.

>  Every solution which requires additional maintenance is out of
>  question. 
I can see the usefulness of it- though the implementation details needs
careful thought. Of course, just having the files listed in the rpm
isn't good enough since log files need to be identified from binaries.

If it's worth development time- is another question.

-- 
Regards,
Adam Allen.

adam(a)dynamicinteraction.co.uk
pgp
http://search.keyserver.net:11371/pks/lookup?op=vindex&search=adam%40...

AIDE/Tripwire

[Michael Schwendt]

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

On 13 Aug 2003 16:45:02 +0100, Mr. Adam ALLEN wrote:

>  > > I think it's dangerous to automatically rebuild the
> database,
>  >
>  > I think nobody has suggested to rebuild the database automatically.
>  
>  No nobody has, but a logical next step I guessed might be that if we
>  have the files that rpm modified (/etc/tripwire.d) then why not just
>  take care of it automatically. 
Because rebuilding the database should be a manually executed
process which is controlled (=verified) by the admin _as long as_
installed files can be modified once they are installed. Another
level of security is good. RPM installs signed packages and can
verify integrity of installed files. But who checks that RPM itself
and its database don't get modified?

Building a default policy file -- paranoid defaults ;) -- and
stripping down unneeded entries can be automated, though, at least
partially.

- -- 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.2 (GNU/Linux)
>
> iD8DBQE/O7eM0iMVcrivHFQRAqVDAKCGKiLys+kIC56h5tT3f5oGogE8NQCbBxpH
> nChm7oAckIyulhjfMkmyG2E=
> =3ff3
> -----END PGP SIGNATURE-----

AIDE/Tripwire

[Tommy McNeely]

Michael Schwendt wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 13 Aug 2003 14:11:56 +0100, Mr. Adam ALLEN wrote:
>
>   
>
> >>>Maybe just setup a magic policy directory (ala /etc/tripwire.d ) .. that
> >>>each RPM can drop its "specs" into and have the policy generated
> >>>automatically or something..
> >>>        
> >>>
>   
>   
>
> >I think it's dangerous to automatically rebuild the database
> >    
> > 
> I think nobody has suggested to rebuild the database automatically.
>  
I sortof did, but that's obviously not really a good idea ;)

> The question I have raised earlier is whether to ship a default
> policy file that covers a full install of the distribution? And in
> case this is desired, whether and how to create it manually or
> automatically? Especially Tripwire uses policy directives which
> sort files into different security levels.
>
> Users of Tripwire and Red Hat Linux moan about a default policy file
> that covers files which are not installed actually. This creates
> security reports which include many "file does not exist" warnings.
> The tools to drop such files from the config are not included. You
> can create a rough Perl script yourself or try to find an existing
> one via Google. But that only shows that the package is incomplete
> and needs enhancement.
>
> Tommy McNeely's suggestion to tie RPM to the IDE by using a ``magic
> policy directory (ala /etc/tripwire.d ) .. that each RPM can drop
> its "specs" into'' is ridiculous IMHO. Just note, that a) the
> Tripwire project page looks abandoned for a long time, that b)
> the information in those tripwire.d files is very likely not
> different from what is contained within the rpmdb-redhat already,
> and that c) nobody would maintain extra information which could
> not be extracted from src.rpms/rpmdb automatically.
>  
was just a random thought :) .. and by "specs" I meant simply a small 
piece of the text based (or possibly Red Hat signed and encrypted) twpol 
file that contains the files that should be in the policy for the 
specific package.. not the rpm spec :)

Although maybe a solution is to build the *initial* policy directly from 
the rpmdb (not -redhat, as that contains everything, right?) using a 
python or similar script that can semi-intelligently determine whether a 
file is a binary/config/log/other (based on location?) .. directly after 
the user completes the install (if they check the "build my default 
tripwire for me" box?). I suggest we stray away from including a text 
version of the config file due to the reason mentioned above.. if the 
user decides not to install "everything" then they get all the file not 
found stuff. If we are going to parse rpmdb to find out what files 
should be taken out of the default everything policy, why not just parse 
the db to figure out what to put into it.. less maint. I think?

For maintaining the policy, that could require extra "intellegence"  .. 
or possibly script kiddies.. just installing an RPM or modifying rpm or 
its database somehow to trip up the tripwire policy "generator" .. or 
like you say.. listing /etc/passwd because you have added an account, 
but meanwhile someone else has added another "root" account or deleted 
all the others.. and you magically OK that file beign changed because it 
was "supposed to"

> Every solution which requires additional maintenance is out of
> question.
>  
heh, any solution is going to require extra maint.. it just depends on 
how much and who does it :)

> Red Hat have dropped Tripwire due to resource constraints. Resource
> constraints are not specific to Red Hat. A community packager is
> also affected by resource constraints. 
>  
tripwire by name may not be what we need to persue.. maybe aide? or some 
other tool.. but the generating default policy and maintaining it are 
still going to be a problem


> - -- 
> > -----BEGIN PGP SIGNATURE-----
> > Version: GnuPG v1.2.2 (GNU/Linux)
> >
> > iD8DBQE/OlUe0iMVcrivHFQRAihEAJ9Qq7sMxPmVUDVc0gT8sQP6tX6IbwCfUc09
> > B6Tx6ZNjsrZF+ThGnztGWVA=
> > =wtpd
> > -----END PGP SIGNATURE----- 
>
> --
> Rhl-beta-list mailing list
> Rhl-beta-list(a)redhat.com
> http://www.redhat.com/mailman/listinfo/rhl-beta-list
>   
>  
-- 
Tommy McNeely   --   Tommy.McNeely(a)Sun.COM
Sun Microsystems   --   IT CTO
Phone/Fax: x51837 / 303-395-3361

AIDE/Tripwire

[Tommy McNeely]

Mr. Adam ALLEN wrote:

> On Wed, 2003-08-13 at 13:13, Leonard den Ottolander wrote:
>   
>
> >Hi Tommy,
> >
> >    
> >
> >>Maybe just setup a magic policy directory (ala /etc/tripwire.d ) .. that
> >>each RPM can drop its "specs" into and have the policy generated
> >>automatically or something..
> >>      
> >>
>  
> I think it's dangerous to automatically rebuild the database, but
> something like: 
>
>  - get the rpm to dump into /etc/tripwire.d
>  - alert the user that they should run something like (or aide)
> 	tripwire --rebuild --parse-specs
>  - it would probably be a safe idea to have RH sign the spec file, with
> the same key used to sign the RPM, and the only process files out of
> /etc/tripwire.d which can have their digital signatures verified. Users
> might trust the /etc/tripwire.d contents too much- which is why I think
> this step might be necessary.
>  
Agreed.. you dont want anyone just dropping stuff into there

> Need to be really careful that my rpm doesn't drop in a new /etc/passwd.
> Since the specfile would list /etc/passwd as a file- would this instruct
> tripwire to re-calculate the checksums on /etc/passwd. (Which may have
> all the accounts deleted).
>
> Just a quick not-really thought through pitfalls that might exist.
>   
>  
Such are the pitfalls of trying to make this "easy" .. tripwire may no 
be a feasable solution, but I was trying to suggest something that 
reminded me of "logrotate.d"

>   
>  
-- 
Tommy McNeely   --   Tommy.McNeely(a)Sun.COM
Sun Microsystems   --   IT CTO
Phone/Fax: x51837 / 303-395-3361

[Rik van Riel]

On Mon, 11 Aug 2003, Kyle Maxwell wrote:
>  On Mon, 2003-08-11 at 16:07, Rik van Riel wrote:
>  > If you have other cool ideas on what should be included,
>  > don't hesitate to let us know ;)
>  
>  Now *there's* a question sure to generate traffic...
>  
>  I'd really like to see Tripwire (or AIDE) back in. 
>  I understand that it was yanked due to developer resource
> constraints,
>  but maybe this is where the community involvement comes in. 
*ding ding ding ding*

You correctly guessed the follow-up question.  Now is the time
to start creating your favorite RPMs for Severn, other people
should be able to install them using some update mechanism
(once we know which one is preferred).

I don't know what the distribution people are planning, but
personally I wouldn't mind if the next version after Severn
actually shrank the core distribution and simply had all of
the luxury/extra packages available from extra repositories.

That's just my uninformed opinion, though.
Blame me if it turns out to be practically impossible
for the distribution people ;)

-- 
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it." - Brian W. Kernighan

[seth vidal]

>  > I understand that it was yanked due to developer resource
> constraints,
>  > but maybe this is where the community involvement comes in.
>  
>  *ding ding ding ding*
>  
>  You correctly guessed the follow-up question.  Now is the time
>  to start creating your favorite RPMs for Severn, other people
>  should be able to install them using some update mechanism
>  (once we know which one is preferred).
>  
>  I don't know what the distribution people are planning, but
>  personally I wouldn't mind if the next version after Severn
>  actually shrank the core distribution and simply had all of
>  the luxury/extra packages available from extra repositories.
>   
HERE HERE!!
I'd like to add my recommendation that this happen too.

shrink core rhl. add more repositories oriented around certain
tasks/programs/services.

-sv

[Michael Schwendt]

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

On Mon, 11 Aug 2003 17:40:07 -0500, Kyle Maxwell wrote:

>  Now *there's* a question sure to generate traffic...
>  
>  I'd really like to see Tripwire (or AIDE) back in. I think a host-based
>  IDS like this with a reasonable default would be a nice addition. I
>  understand that it was yanked due to developer resource constraints, but
>  maybe this is where the community involvement comes in. 
Yesterday I tested AIDE a bit more. I used the 0.9 version, later
tried fixes from CVS and also had a look at enhancements done by the
Debian folks.

Well, does anybody *really* use AIDE?

It fails for me for simple config lines such as 

  =/home   p+u+g

which tells it to check permissions and ownership of the /home
directory but not process child directories. Creating and installing
the database works. But as soon as I run aide --check, it recurses
into /home and prints "open_dir():Not a directory:" for every file
name it finds.

Same for the example

  =/   p+u+g

which processes the entire file-system contrary to what is written
in the manual.

I also saw that there is a package for Mandrake Linux. Those folks
have a line

  =/lost+found   DIR

with "DIR" being a macro for p+u+g plus inode check and number of
links check. However, the path names in aide.conf are regular
expressions. Hence for directory /lost+found to match, the config
line would need to be

  =/lost\+found   DIR

And they also include a "=/home DIR" rule. Might be that AIDE
doesn't build correctly on Red Hat Linux only. But with issues like
these, I don't think AIDE is ready to be deployed.

- -- 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.2 (GNU/Linux)
>
> iD8DBQE/QMr40iMVcrivHFQRApp1AJ4wGxki38/DVlBVUy5rLAdQWmDjoACeM8gu
> 1Ca2JaLL87LtQDs3K8hVXr4=
> =VSU9
> -----END PGP SIGNATURE-----

[Havoc Pennington]

On Mon, Aug 11, 2003 at 05:07:21PM -0400, Rik van Riel wrote:
>  On Mon, 11 Aug 2003, M A Young wrote:
>  
>  > A timetable was on the rhl site http://rhl.redhat.com/ before they closed
>  > it to rework it. Note that it has been rumoured on the list that this
>  > timetable may slip by a couple of weeks to allow gnome 2.4 to be
>  > incorporated.
>  
>  If you have other cool ideas on what should be included,
>  don't hesitate to let us know ;) 
Maybe this should be qualified with "for the next release, if you are
going to volunteer to work on it" ;-)

Fudging the release date slightly to align with a large open source
project is one thing, but totally blowing the feature freeze out of
the water is not really the idea... in fact that kind of slippery
slope is much of the reason people were questioning the gnome 2.4
inclusion in the first place.

Havoc

[Rik van Riel]

On Mon, 11 Aug 2003, Havoc Pennington wrote:

>  > If you have other cool ideas on what should be included,
>  > don't hesitate to let us know ;)
>  
>  Maybe this should be qualified with "for the next release, if you are
>  going to volunteer to work on it" ;-) 
You are absolutely right, of course.  From now on I'll try
to read all my emails before sending them, I can see how
my mail must have gotten misinterpreted by some people.

In fact, I can see quite an impressive thread illustrating
that.  On the plus side, it's good to see that the community
is alive ;)

-- 
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it." - Brian W. Kernighan

mhash in php [was: Re: was there an advertised ETA for the next beta?]

[Leonard den Ottolander]

Hello Rik,

>  If you have other cool ideas on what should be included,
>  don't hesitate to let us know ;) 
 mhash support built into php. Basics to build a libmhash rpm can be 
found at http://home.hetnet.nl/~ottolander/mhash/libmhash.html .

Bye,
Leonard.

--
How clean is a war when you shoot around nukelar waste?
Stop the use of depleted uranium ammo!
End all weapons of mass destruction.

mhash in php [was: Re: was there an advertised ETA for the next beta?]

[Jared Smith]

>   mhash support built into php. Basics to build a libmhash rpm can be
>
>  found at http://home.hetnet.nl/~ottolander/mhash/libmhash.html .
>  
>  Bye,
>  Leonard.
>   
I second this one

Jared Smith

mhash in php [was: Re: was there an advertised ETA for the next beta?]

[Leonard den Ottolander]

Hi Jared,

>  I second this one 
 and I second tripwire back into the distro ;-) .

Bye,
Leonard.

--
How clean is a war when you shoot around nukelar waste?
Stop the use of depleted uranium ammo!
End all weapons of mass destruction.

[Patrick]

On Mon, 2003-08-11 at 23:07, Rik van Riel wrote:
>  If you have other cool ideas on what should be included,
>  don't hesitate to let us know ;) 
Thanks for the invitation! Here it goes:
Bluefish html editor (http://bluefish.openoffice.nl)

Regards,
Patrick

[Robert P. J. Day]

On Tue, 12 Aug 2003, Patrick wrote:

>  On Mon, 2003-08-11 at 23:07, Rik van Riel wrote:
>  > If you have other cool ideas on what should be included,
>  > don't hesitate to let us know ;)
>  
>  Thanks for the invitation! Here it goes:
>  Bluefish html editor (http://bluefish.openoffice.nl) 
what about the possibility of an extra "productivity" CD, like the
old days?

rday

[Ravi Shekhar]

> If you have other cool ideas on what should be included,
> don't hesitate to let us know ;)
>  
Is anyone considering Python2.3 for the next beta or the next final? Or 
would it be too much because it must be made sure all the tools and 
modules are still properly compatible?

Ravi

[Bill Nottingham]

Ravi Shekhar (rxs141(a)cwru.edu) said: 
>  Or 
>  would it be too much because it must be made sure all the tools and 
>  modules are still properly compatible? 
Correct.

Bill

[Michael K. Johnson]

On Mon, Aug 11, 2003 at 09:31:49PM -0400, Robert P. J. Day wrote:
>  what about the possibility of an extra "productivity" CD,
> like the
>  old days? 
There are two answers to this.

The first is that this is the kind of thing that the "external
repository" goal is supposed to address -- we're trying to make
it easy to do this without having to coordinate both ways so
much as would have been necessary before.

The second is that if the packages are going to be well-maintained
and have appropriate licenses etc. ad nauseum they will become
candidates for the distro.

michaelkjohnson

 "He that composes himself is wiser than he that composes a book."
 Linux Application Development                     -- Ben Franklin
 http://people.redhat.com/johnsonm/lad/

[Patrick]

On Mon, 2003-08-11 at 23:07, Rik van Riel wrote:
>  If you have other cool ideas on what should be included,
>  don't hesitate to let us know ;) 
#1 add the ATI Radeon AGP enhancements from 2.4.22-rc2-ac1

#2 add nforce2 support to lm_sensors (module lives in cvs) so nforce2
based mobo owners can monitor the temps, fans etc.

#3 profit!

Regards,
Patrick

[Féliciano Matias]

Le lun 11/08/2003 à 23:07, Rik van Riel a écrit :
>  If you have other cool ideas on what should be included,
>  don't hesitate to let us know ;) 
Sorry for my poor English.

I would like to see RHLP to be more open and more visible.

I don't talk about license. I am talking about communication.

For example i was surprised by the adding of yum and samba 3.0 without
any communication from RedHat. I would like something better than
checking rawhide.
Something that Taroon already has :
http://www.redhat.com/archives/taroon-beta-list/2003-August/msg00123.html
A "what's new" web page ?

Also, RedHat have closed the rhl.redhat.com website and nobody knows why
and nobody knows what is currently going on.

Perhaps Redhat can create the "RedHat weekly news" as Debian do :
http://www.debian.org/News/weekly/

I don't know if this is currently possible but I would a mailing-list
that report events from bugzilla. Mostly new bugs and status change (not
only of my own bugs).

A better communication can make the project more exciting and can bring
back more users/testers/hackers.

Now that RHL is a project, I hope there will be more rawhide users. I
appreciate if RedHat keeps the two or three last rpm of each packages in
case if something goes wrong. At least the src.rpm.

Right now I don't want to ask for more packages. RedHat can't handle all
projects and I want RHL to be a solid distribution (the unix way) rather
than an "all in one" distribution that sucks. Especially since
freshrpms, fedora and some other does a really good job. But i am
disappointed to don't see ACL in the kernel. ACL are in beta RH8.0 and
9. Now that they are in a productive state ACL is only in RHE. I know
that ACL is not in the upstream. But can you consider to bring it back ?
Please :-) Or it's a too big job since ACL will be in 2.6 and
cambridge++ ?

The last but not least, and it's the third request without any reply,
can you provide +user+ mailing-list for none English speakers ?


-- 
Féliciano Matias <feliciano.matias(a)free.fr&gt;

[Havoc Pennington]

On Tue, Aug 12, 2003 at 05:44:12AM +0200, Féliciano Matias wrote: 
>  I would like to see RHLP to be more open and more visible.
>  
>  I don't talk about license. I am talking about communication. 
Yes, this is one of our highest priorities. I think this (and building
infrastructure for external contributors) has to take precedence over
new features and packages to a large extent, especially once Cambridge
is released.
 
>  Also, RedHat have closed the rhl.redhat.com website and nobody knows
> why
>  and nobody knows what is currently going on. 
This will get resolved, just hang in there.

>  Perhaps Redhat can create the "RedHat weekly news" as
> Debian do :
>  http://www.debian.org/News/weekly/ 
I'd like to see someone external contribute this (once we have
the web site back and some other basics).

>  I don't know if this is currently possible but I would a
> mailing-list
>  that report events from bugzilla. Mostly new bugs and status change (not
>  only of my own bugs). 
Newer versions of bugzilla may have this feature - I remember seeing
something like it on bugzilla.mozilla.org.

>  Now that RHL is a project, I hope there will be more rawhide users.
> I
>  appreciate if RedHat keeps the two or three last rpm of each packages in
>  case if something goes wrong. At least the src.rpm. 
That seems like a useful idea. I don't know how hard it would be
(there are mirrors, scripts, etc. to think about).

>  The last but not least, and it's the third request without any
> reply,
>  can you provide +user+ mailing-list for none English speakers ? 
This is a good idea, we just need someone to do it. I think we need to
find a speaker of each language to moderate/own the mailing list.  We
may have some people willing inside Red Hat; I don't know if we are
set up to allow external list owners on listman.redhat.com or not.

Havoc

[Paul Iadonisi]

On Tue, 2003-08-12 at 00:01, Havoc Pennington wrote:
>  On Tue, Aug 12, 2003 at 05:44:12AM +0200, Féliciano Matias wrote: 
[snip]

>  > Now that RHL is a project, I hope there will be more rawhide
> users. I
>  > appreciate if RedHat keeps the two or three last rpm of each packages in
>  > case if something goes wrong. At least the src.rpm.
>  
>  That seems like a useful idea. I don't know how hard it would be
>  (there are mirrors, scripts, etc. to think about). 
  How about just moving the old revs into a rawhide-old directory?  You
could periodically prune the rawhide-old directory to only have two or
three revs.  This way, at least mirrors can forgo mirroring the
rawhide-old directory if they want to save space and it only
(theoretically) requires changing one 'rm' command to an 'mv' command
(not including the pruning).  You could do the pruning in the same
script, but I'm just proposing something that may reduce the chances
that you break an existing process.

Just my $0.02 worth.
-- 
-Paul Iadonisi
 Senior System Administrator
 Red Hat Certified Engineer / Local Linux Lobbyist
 Ever see a penguin fly?  --  Try Linux.
 GPL all the way: Sell services, don't lease secrets

[Bill Nottingham]

Paul Iadonisi (pri.rhl1(a)iadonisi.to) said: 
>    How about just moving the old revs into a rawhide-old directory? 
> You
>  could periodically prune the rawhide-old directory to only have two or
>  three revs. 
This still implies *we* want to carry around that much space. :)
Seriously, rawhide is already 11GB+, and it will get bigger once
we actually start adding debuginfo packages.

Bill

[Paul Iadonisi]

On Tue, 2003-08-12 at 00:39, Bill Nottingham wrote:
>  Paul Iadonisi (pri.rhl1(a)iadonisi.to) said: 
>  >   How about just moving the old revs into a rawhide-old directory?  You
>  > could periodically prune the rawhide-old directory to only have two or
>  > three revs.
>  
>  This still implies *we* want to carry around that much space. :)
>  Seriously, rawhide is already 11GB+, and it will get bigger once
>  we actually start adding debuginfo packages. 
  Of course.  You need to decide that first.  But as another suggestion
(mentioned earlier in this thread), nuke the old binary rpms.  Yes, that
*could* mean that you may have src rpms that won't build on any current
version or rawhide system, but we're only talking about a convenience
here.  Not a 'must work' kind of thing.  Of course, I'm well aware of
the types of people who feel that EVERYTHING must work at all times,
even essentially unreleased code :-).
  I think it's great that Red Hat has opened up it's development process
as much as it has and look forward to seeing this community develop. 
However, I don't envy the position you guys at Red Hat are in, trying to
make the decisions you must, knowing full well that there are going to
be a few noisy people who complain about anything.  I'll try not to be
one of those people ;-).
-- 
-Paul Iadonisi
 Senior System Administrator
 Red Hat Certified Engineer / Local Linux Lobbyist
 Ever see a penguin fly?  --  Try Linux.
 GPL all the way: Sell services, don't lease secrets

[seth vidal]

On Tue, 2003-08-12 at 00:39, Bill Nottingham wrote:
>  Paul Iadonisi (pri.rhl1(a)iadonisi.to) said: 
>  >   How about just moving the old revs into a rawhide-old directory?  You
>  > could periodically prune the rawhide-old directory to only have two or
>  > three revs.
>  
>  This still implies *we* want to carry around that much space. :)
>  Seriously, rawhide is already 11GB+, and it will get bigger once
>  we actually start adding debuginfo packages. 
mental note:
get larger disks for mirror.

<sigh>

:)
-sv

[Daniel Veillard]

On Tue, Aug 12, 2003 at 02:03:09AM -0400, seth vidal wrote:
>  On Tue, 2003-08-12 at 00:39, Bill Nottingham wrote:
>  > Paul Iadonisi (pri.rhl1(a)iadonisi.to) said: 
>  > >   How about just moving the old revs into a rawhide-old directory?  You
>  > > could periodically prune the rawhide-old directory to only have two or
>  > > three revs.
>  > 
>  > This still implies *we* want to carry around that much space. :)
>  > Seriously, rawhide is already 11GB+, and it will get bigger once
>  > we actually start adding debuginfo packages.
>  
>  mental note:
>  get larger disks for mirror.
>  
>  <sigh> 
parse error: end of entity reached in tag 'sigh'

mental note:
purchase more hardware.

<sigh/>

what do you do with your smaller disks ?

Daniel

-- 
Daniel Veillard      | Red Hat Network https://rhn.redhat.com/
veillard(a)redhat.com  | libxml GNOME XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/

[seth vidal]

>  mental note:
>  purchase more hardware.
>  
>  <sigh/> 
thppt

>  
>  what do you do with your smaller disks ? 
normally they either go into other machines to serve other purposes or
they're dead :)

-sv

[Leonard den Ottolander]

Hello Bill,

>  This still implies *we* want to carry around that much space. :)
>  Seriously, rawhide is already 11GB+, and it will get bigger once
>  we actually start adding debuginfo packages. 
 This can be solved quite easily. Just drop all old rpms, both source 
and binary, and just make old spec files available (of course they 
would need to be versioned). As long as all the patches are still in 
the latest src rpm and the base sources didn't change you can rebuild 
old rpms by installing the new src rpm and replacing the spec file. Of 
course src rpms containing different source code verions c/should be 
kept availble (for a while).

Bye,
Leonard.

--
How clean is a war when you shoot around nukelar waste?
Stop the use of depleted uranium ammo!
End all weapons of mass destruction.

[Bill Nottingham]

Leonard den Ottolander (leonardjo(a)hetnet.nl) said: 
>  Hello Bill,
>  
>  > This still implies *we* want to carry around that much space. :)
>  > Seriously, rawhide is already 11GB+, and it will get bigger once
>  > we actually start adding debuginfo packages.
>  
>   This can be solved quite easily. Just drop all old rpms, both source 
>  and binary, and just make old spec files available (of course they 
>  would need to be versioned). 
Or, perhaps, a CVS repository of specs & patches.

Bill

[Jared Smith]

>  Or, perhaps, a CVS repository of specs & patches.
>  
>  Bill 
Ooooh... now that's a good idea.  (Especially for people like me who are
just learning the secret art of writing good spec files.)

Jared

Re[2]: was there an advertised ETA for the next beta?

[Dmitry Tweritin]

Hello,

BN> Or, perhaps, a CVS repository of specs & patches.

It would be just great. Especially with a web interface (viewcvs or
something) and RSS feeds (thanks, Alan) using
http://laughingmeme.org/cvs2rss/


-- 
 snaky

[Féliciano Matias]

Le mar 12/08/2003 à 18:02, Bill Nottingham a écrit :
>  Or, perhaps, a CVS repository of specs & patches.
>   
Or subversion and its cheap branching and tagging.

Here is a possible layout :
/
        README
        trunk/ (also known as RawHide)
                a2ps
                abiword
                ...
        tags/
                9.0.93 - Severn beta1/
                9 - Shrike/
        branches/
                9 - Shrike/
                        updates/



The subversion repository : http://svn.collab.net/

>  Bill 
-- 
Féliciano Matias <feliciano.matias(a)free.fr&gt;

[Féliciano Matias]

Le mar 12/08/2003 à 06:39, Bill Nottingham a écrit :
>  Paul Iadonisi (pri.rhl1(a)iadonisi.to) said: 
>  >   How about just moving the old revs into a rawhide-old directory?  You
>  > could periodically prune the rawhide-old directory to only have two or
>  > three revs.
>  
>  This still implies *we* want to carry around that much space. :)
>  Seriously, rawhide is already 11GB+, and it will get bigger once
>  we actually start adding debuginfo packages.
>   
Perhaps this issue could be answered in the client computer.
I see that up2date provides rollback feature.
Currently i use a little shell script to keep old packages (see
attachment for those interesting in. I am not a good shell coder).

I think this issue could be addressed in the rawhide FAQ (if any).

>  Bill
>   
-- 
Féliciano Matias <feliciano.matias(a)free.fr&gt;

[Féliciano Matias]

Le mar 12/08/2003 à 06:01, Havoc Pennington a écrit :
>  On Tue, Aug 12, 2003 at 05:44:12AM +0200, Féliciano Matias wrote: 
>   
>  > Also, RedHat have closed the rhl.redhat.com website and nobody knows why
>  > and nobody knows what is currently going on.
>  
>  This will get resolved, just hang in there. 
This is the "problem". Please, don't wait that every thing are in place
to talk us about what is going on. This is not an "open process".
I am sure that a few people here have some good ideas for you.

>  Havoc
>   
-- 
Féliciano Matias <feliciano.matias(a)free.fr&gt;

[seth vidal]

>  > Also, RedHat have closed the rhl.redhat.com website and nobody
> knows why
>  > and nobody knows what is currently going on.
>  
>  This will get resolved, just hang in there. 
out of curiosity - will we ever learn _why_ it was taken down?
That'd do a lot to show us that red hat is trying to operate in an open
manner.

The questions about the website have gotten a lot of the "red
wall-of-nda'd-silence". Kinda irritating: 'yes, we'd like to be more
open'. 'no, we can't tell you why we took a website down'.


>  I'd like to see someone external contribute this (once we have
>  the web site back and some other basics). 
that sounds like a good idea.


>  > Now that RHL is a project, I hope there will be more rawhide
> users. I
>  > appreciate if RedHat keeps the two or three last rpm of each packages in
>  > case if something goes wrong. At least the src.rpm.
>  
>  That seems like a useful idea. I don't know how hard it would be
>  (there are mirrors, scripts, etc. to think about). 
It might be worthwhile to talk to the mirrors-list and see if there
would be some merit in changing the layout of the ftp site some. Maybe
make a separation b/t the RHLP-type files and the RHEL-type files.

I can imagine a lot more sites being interested in carrying RHLP-type
files but not as interested in the RHEL-type files. (like the betas for
RHEL, and the other misc files) For example - a 17GB Taroon beta was
touch excessive ;)

I was talking to someone on irc the other day and they asked why didn't
red hat make RHLP a semi-external project like openoffice.org is to sun.

I honestly didn't have an answer. Why not do that?

thoughts?
-sv

[seth vidal]

>  out of curiosity - will we ever learn _why_ it was taken down?
>  That'd do a lot to show us that red hat is trying to operate in an open
>  manner.
>  
>  The questions about the website have gotten a lot of the "red
>  wall-of-nda'd-silence". Kinda irritating: 'yes, we'd like to be more
>  open'. 'no, we can't tell you why we took a website down'. 
I wanted to  add a note here.

I realize that none of the developers are at fault for being bound by an
nda. I'm not upset with anyone about that. I understand that this is a
job and you have certain rules you have to follow. I was just hoping
that the info regarding the status of the rhl.redhat.com wasn't
protected by the nda.

so no malice intended in the cited section above.

-sv

[Daniel Veillard]

On Tue, Aug 12, 2003 at 01:37:20AM -0400, seth vidal wrote:
>  It might be worthwhile to talk to the mirrors-list and see if there
>  would be some merit in changing the layout of the ftp site some. Maybe 
  Merit or not, only if forced due to a very serious problem...
  Do NOT break URLs !

>  I can imagine a lot more sites being interested in carrying
> RHLP-type
>  files but not as interested in the RHEL-type files. (like the betas for
>  RHEL, and the other misc files) For example - a 17GB Taroon beta was
>  touch excessive ;) 
  rsync --exclude-from we all know this works...

Daniel

-- 
Daniel Veillard      | Red Hat Network https://rhn.redhat.com/
veillard(a)redhat.com  | libxml GNOME XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/

[Stephen Smoogen]

Oh lord not another reorg :). I knew I should have moved arch higher up.
[2 months of people sending emails about LANG/PROJECT/ARCH over
ARCH/PROJECT/LANG or PROJECT/LANG/ARCH]

On Tue, 2003-08-12 at 07:17, Daniel Veillard wrote:
>  On Tue, Aug 12, 2003 at 01:37:20AM -0400, seth vidal wrote:
>  > It might be worthwhile to talk to the mirrors-list and see if there
>  > would be some merit in changing the layout of the ftp site some. Maybe
>  
>    Merit or not, only if forced due to a very serious problem...
>    Do NOT break URLs !
>  
>  > I can imagine a lot more sites being interested in carrying RHLP-type
>  > files but not as interested in the RHEL-type files. (like the betas for
>  > RHEL, and the other misc files) For example - a 17GB Taroon beta was
>  > touch excessive ;)
>  
>    rsync --exclude-from we all know this works...
>  
>  Daniel 
-- 
Stephen John Smoogen		smoogen(a)lanl.gov
Los Alamos National Labrador  CCN-5 Sched 5/40  PH: 4-0645 (note new #)
Ta-03 SM-1498 MailStop B255 DP 10S  Los Alamos, NM 87545
-- So shines a good deed in a weary world. = Willy Wonka --

[Havoc Pennington]

On Tue, Aug 12, 2003 at 01:37:20AM -0400, seth vidal wrote:
>  > > Also, RedHat have closed the rhl.redhat.com website and
> nobody knows why
>  > > and nobody knows what is currently going on.
>  > 
>  > This will get resolved, just hang in there.
>  
>  out of curiosity - will we ever learn _why_ it was taken down?
>  That'd do a lot to show us that red hat is trying to operate in an open
>  manner.
>  
>  The questions about the website have gotten a lot of the "red
>  wall-of-nda'd-silence". Kinda irritating: 'yes, we'd like to be more
>  open'. 'no, we can't tell you why we took a website down'. 
Yeah, I know. What the site says at the moment is really an accurate
answer, fwiw.
 
>  I was talking to someone on irc the other day and they asked why
> didn't
>  red hat make RHLP a semi-external project like openoffice.org is to sun.
>  
>  I honestly didn't have an answer. Why not do that?
>  
>  thoughts? 
What do you mean by "semi-external"?  Our general idea _is_ to make
this like openoffice.org is to Sun, I think, at least in many ways.

Havoc

[Rik van Riel]

On Tue, 12 Aug 2003, Havoc Pennington wrote:
>  On Tue, Aug 12, 2003 at 01:37:20AM -0400, seth vidal wrote: 
>  > The questions about the website have gotten a lot of the
> "red
>  > wall-of-nda'd-silence". Kinda irritating: 'yes, we'd like to be
> more
>  > open'. 'no, we can't tell you why we took a website down'.
>  
>  Yeah, I know. What the site says at the moment is really an accurate
>  answer, fwiw. 
While I cannot (right now) tell you the exact answer, I can
give you a vague hint to figure it out for yourself.

The original rhl.redhat.com web site answered the questions
raised by developers, since it is a development project.

However, it did not answer questions raised by some other
(unspecified) categories of people who interact with Red Hat.
Those questions need to be answered, in detail.

Discussions about development of packages and about the 
development process that people would like to see can still
go on though, hopefully on the rhl-devel-list.

-- 
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it." - Brian W. Kernighan

[seth vidal]

>  While I cannot (right now) tell you the exact answer, I can
>  give you a vague hint to figure it out for yourself.
>  
>  The original rhl.redhat.com web site answered the questions
>  raised by developers, since it is a development project.
>  
>  However, it did not answer questions raised by some other
>  (unspecified) categories of people who interact with Red Hat.
>  Those questions need to be answered, in detail.
>   
So I guess I'm still a touch confused - you have a site with useful
information on it.

however, it doesn't have information for everyone.

so instead of working on adding the information so the site is useful to
everyone you take down the whole site so there is no information
available that is useful to anyone.

I know there are universes where this logic makes sense but I don't ever
want to live in them.

:)

-sv

[Keith Sharp]

On Tue, 2003-08-12 at 05:01, Havoc Pennington wrote:
>  On Tue, Aug 12, 2003 at 05:44:12AM +0200, Féliciano Matias wrote: 
>  > Now that RHL is a project, I hope there will be more rawhide users. I
>  > appreciate if RedHat keeps the two or three last rpm of each packages in
>  > case if something goes wrong. At least the src.rpm.
>  
>  That seems like a useful idea. I don't know how hard it would be
>  (there are mirrors, scripts, etc. to think about). 
On the topic of Rawhide could I suggest a rawhide-announce mailing list
that indicates when a new version of a package has been made available. 
Thanks,

Keith.

[Panu Matilainen]

Quoting Keith Sharp <kms(a)passback.co.uk&gt;:

>  On Tue, 2003-08-12 at 05:01, Havoc Pennington wrote:
>  > On Tue, Aug 12, 2003 at 05:44:12AM +0200, Féliciano Matias wrote: 
>  > > Now that RHL is a project, I hope there will be more rawhide users. I
>  > > appreciate if RedHat keeps the two or three last rpm of each packages
>  in
>  > > case if something goes wrong. At least the src.rpm.
>  > 
>  > That seems like a useful idea. I don't know how hard it would be
>  > (there are mirrors, scripts, etc. to think about).
>  
>  On the topic of Rawhide could I suggest a rawhide-announce mailing list
>  that indicates when a new version of a package has been made available.  
Ouch, that'd be one heavy-traffic list :) Especially since updates in rawhide
often consist stuff like "fix typo in description" or "fix blah for S/390
build"
for which you might not really want to download the newer version. Having daily
changelog deltas for updated packages available somewhere, or something like
that would be nice though. 

-- 
    - Panu -

[Bill Nottingham]

Keith Sharp (kms(a)passback.co.uk) said: 
>  On the topic of Rawhide could I suggest a rawhide-announce mailing
> list
>  that indicates when a new version of a package has been made available. 
>  Thanks, 
Daily changes for rawhide should be coming soon; it will coincide
with the debuginfo stuff coming available, and a couple of other
rawhide tweaks.

Bill

[Stephan Schutter]

Will these changes be available via apt-get or up2date then?

On Tue, 12 Aug 2003, Bill Nottingham wrote:

>  Keith Sharp (kms(a)passback.co.uk) said: 
>  > On the topic of Rawhide could I suggest a rawhide-announce mailing list
>  > that indicates when a new version of a package has been made available. 
>  > Thanks,
>  
>  Daily changes for rawhide should be coming soon; it will coincide
>  with the debuginfo stuff coming available, and a couple of other
>  rawhide tweaks.
>  
>  Bill
>  
>  
>  --
>  Rhl-beta-list mailing list
>  Rhl-beta-list(a)redhat.com
>  http://www.redhat.com/mailman/listinfo/rhl-beta-list
>

[Bill Rugolsky Jr.]

On Tue, Aug 12, 2003 at 12:01:17AM -0400, Havoc Pennington wrote:
>  On Tue, Aug 12, 2003 at 05:44:12AM +0200, Féliciano Matias wrote: 
>  > I don't know if this is currently possible but I would a mailing-list
>  > that report events from bugzilla. Mostly new bugs and status change (not
>  > only of my own bugs).
>  
>  Newer versions of bugzilla may have this feature - I remember seeing
>  something like it on bugzilla.mozilla.org. 
That would be great, particularly if there were extra headers to indicate
the package and other meta-data for easy searching (like using "limit" in
mutt).
It ought to be intermixed with package commit info.

Bugzilla could really benefit from the ability to display the RPM changelog
when reporting a bug against a package.  Right now the method is

	1. Find a bug
	2. Do one or more of the following:
	     a. Go to rpmfind.net and read the Changelog for the package in Rawhide,
	        to see whether the bug has been fixed.
	     b. Download the SRPM/RPM and look/test
	     c. Search Bugzilla.
	3. Report the bug.

The process can definitely be streamlined.  bugs.debian.org does a good job of
integrating
this information for individual packages.

Regards,

	Bill Rugolsky

[Féliciano Matias]

Le mar 12/08/2003 à 06:01, Havoc Pennington a écrit :
>  On Tue, Aug 12, 2003 at 05:44:12AM +0200, Féliciano Matias wrote: 
>  > The last but not least, and it's the third request without any reply,
>  > can you provide +user+ mailing-list for none English speakers ?
>  
>  This is a good idea, we just need someone to do it. I think we need to
>  find a speaker of each language to moderate/own the mailing list.  We
>  may have some people willing inside Red Hat; I don't know if we are
>  set up to allow external list owners on listman.redhat.com or not.
>   
If you have the opportunity, just add a pointer to an external resource.
For example i found a French forum dedicated to RedHat :
news:alt.fr.os.redhat

At the present time it's a very low traffic forum. With the help of some
"publicity" by RedHat this could change.



>  Havoc
>  
>  
>  
>  --
>  Rhl-beta-list mailing list
>  Rhl-beta-list(a)redhat.com
>  http://www.redhat.com/mailman/listinfo/rhl-beta-list 
-- 
Féliciano Matias <feliciano.matias(a)free.fr&gt;

[Alan Cox]

>  Something that Taroon already has :
>  http://www.redhat.com/archives/taroon-beta-list/2003-August/msg00123.html
>  A "what's new" web page ? 
Thats under discussion and ideas like "newest packages" RSS feeds have
been kicked around.

>  Also, RedHat have closed the rhl.redhat.com website and nobody knows
> why
>  and nobody knows what is currently going on. 
Watch this space.

>  Perhaps Redhat can create the "RedHat weekly news" as
> Debian do :
>  http://www.debian.org/News/weekly/ 
That is a very good suggestion. The question being whether it should be
an RH thing or a shared thing with community people - since we won't make
all the news eventually. Obviously right now we mostly do.

>  I don't know if this is currently possible but I would a
> mailing-list
>  that report events from bugzilla. Mostly new bugs and status change (not
>  only of my own bugs). 
The technology exists although I don't think those asking comprehend the
volume of traffic they would get 8)

>  disappointed to don't see ACL in the kernel. ACL are in beta
> RH8.0 and
>  9. Now that they are in a productive state ACL is only in RHE. I know
>  that ACL is not in the upstream. But can you consider to bring it back ?
>  Please :-) Or it's a too big job since ACL will be in 2.6 and
>  cambridge++ ? 
One of the big issues there is reliability and amount of time to
make something reliable. The two projects are on different time scales
The other is the desire to get the RHPL closer to mainstream.

>  The last but not least, and it's the third request without any
> reply,
>  can you provide +user+ mailing-list for none English speakers ? 
Symud da iawn yw e  8) [Thats a very good idea]

I'm not sure if it is something that makes sense to be at Red Hat or
on national Linux sites. I've added it to my list of stuff for internal
discussions.

[Paul Iadonisi]

On Tue, 2003-08-12 at 07:19, Alan Cox wrote:
>  > Something that Taroon already has :
>  > http://www.redhat.com/archives/taroon-beta-list/2003-August/msg00123.html
>  > A "what's new" web page ?
>  
>  Thats under discussion and ideas like "newest packages" RSS feeds have
>  been kicked around. 
  Ooh, how about an ECHO feed?

/me ducks

-- 
-Paul Iadonisi
 Senior System Administrator
 Red Hat Certified Engineer / Local Linux Lobbyist
 Ever see a penguin fly?  --  Try Linux.
 GPL all the way: Sell services, don't lease secrets

UML (was: Re: was there an advertised ETA for the next beta?)

[M A Young]

On Mon, 11 Aug 2003, Rik van Riel wrote:

>  On Mon, 11 Aug 2003, M A Young wrote:
>
>  > A timetable was on the rhl site http://rhl.redhat.com/ before they closed
>  > it to rework it. Note that it has been rumoured on the list that this
>  > timetable may slip by a couple of weeks to allow gnome 2.4 to be
>  > incorporated.
>
>  If you have other cool ideas on what should be included,
>  don't hesitate to let us know ;) 
Since you ask (and I hope you are taking note of all the replies your
question is generating), I would like to see support for user mode linux
back in rhl (following a brief appearence in RHL 8.0). However since that
might imply changes in the kernel, and possibly better anaconda support, I
was viewing this more as a Cambridge++ project.

	Michael Young

UML (was: Re: was there an advertised ETA for the next beta?)

[Michael K. Johnson]

On Tue, Aug 12, 2003 at 10:10:58AM +0100, M A Young wrote:
>  Since you ask (and I hope you are taking note of all the replies
> your
>  question is generating), I would like to see support for user mode linux
>  back in rhl (following a brief appearence in RHL 8.0). However since that
>  might imply changes in the kernel, and possibly better anaconda support, I
>  was viewing this more as a Cambridge++ project. 
I also think it's a Cambridge++ project, and yes we are interested,
though we're not committing, blah blah blah.  :-)

Have you played with qemu?

michaelkjohnson

 "He that composes himself is wiser than he that composes a book."
 Linux Application Development                     -- Ben Franklin
 http://people.redhat.com/johnsonm/lad/

UML (was: Re: was there an advertised ETA for the next beta?)

[Rik van Riel]

On Tue, 12 Aug 2003, Michael K. Johnson wrote:

>  I also think it's a Cambridge++ project, and yes we are
> interested,
>  though we're not committing, blah blah blah.  :-) 
In my opinion it would be best if all the UML luxury
packages were somewhere in a 3rd party repository, where
the people who are really dedicated to UML can give these
packages the attention they deserve.

The changes to the core distribution don't need to be
big.

>  Have you played with qemu? 
QEMU cannot yet run under itself, while the 2.6 UML can
run recursively.  Also, UML has gotten way more secure
and efficient with some support in the 2.6 kernel.

-- 
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it." - Brian W. Kernighan

UML (was: Re: was there an advertised ETA for the next beta?)

[Rik van Riel]

On Tue, 12 Aug 2003, M A Young wrote:

>  Since you ask (and I hope you are taking note of all the replies
> your
>  question is generating), I would like to see support for user mode linux
>  back in rhl (following a brief appearence in RHL 8.0). However since that
>  might imply changes in the kernel, and possibly better anaconda support, I
>  was viewing this more as a Cambridge++ project. 
It would require two things which I can see:

1) support for anaconda to install into a disk image
   somewhere inside an already installed system

2) a kernel configured for user mode linux, which
   should be easy with the 2.6 kernel

In order for UML to be fun to use, it would need some
additional things:

3) a smaller default installation, for people who want
   multiple virtual machines

4) scripts to make it easier to set up networking between
   the virtual machines and the rest of the world

5) maybe scripts to clone virtual machines ?
   install them from scratch ?
   ... ?

For these it would be very good if people from the community
volunteered to start development.  If we get support for user
mode linux somewhere beyond severn, IMHO we should do it right.

Of course the "we" here refers to the community ;)

-- 
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it." - Brian W. Kernighan

UML (was: Re: was there an advertised ETA for the next beta?)

[M A Young]

On Tue, 12 Aug 2003, Rik van Riel wrote:

>  On Tue, 12 Aug 2003, M A Young wrote:
>
>  > Since you ask (and I hope you are taking note of all the replies your
>  > question is generating), I would like to see support for user mode linux
>  > back in rhl (following a brief appearence in RHL 8.0). However since that
>  > might imply changes in the kernel, and possibly better anaconda support, I
>  > was viewing this more as a Cambridge++ project.
>
>  It would require two things which I can see:
>
>  1) support for anaconda to install into a disk image
>     somewhere inside an already installed system 
You can almost do this already (see http://linuxhacker.ru/uml/ ), though
we would need an appropriate kernel, preferably native support in anaconda
for ubd filesystems, and possibly a wrapper script to create an initial
empty disk and generally make the process much more friendly.

>  2) a kernel configured for user mode linux, which
>     should be easy with the 2.6 kernel 
and possibly have the skas patch applied to the main kernel, as uml should
run much faster in skas mode rather than tt mode. This is another reason
to wait for cambridge++ (applying either the skas patch or the main uml
patch to RedHat's 2.4 kernels is highly messy).

>  In order for UML to be fun to use, it would need some
>  additional things:
>
>  3) a smaller default installation, for people who want
>     multiple virtual machines 
A smaller minimal installation would make more than just those people
trying UML happier.

>  4) scripts to make it easier to set up networking between
>     the virtual machines and the rest of the world
>
>  5) maybe scripts to clone virtual machines ?
>     install them from scratch ?
>     ... ?
>
>  For these it would be very good if people from the community
>  volunteered to start development.  If we get support for user
>  mode linux somewhere beyond severn, IMHO we should do it right. 
One of my reasons for posting was to guage interest. I was hoping that
when the rhl website came back there would be scope for proposing and
co-ordinating projects like this.

	Michael Young

UML (was: Re: was there an advertised ETA for the next beta?)

[Michael K. Johnson]

On Wed, Aug 13, 2003 at 03:44:53PM +0100, M A Young wrote:
>  One of my reasons for posting was to guage interest. I was hoping
> that
>  when the rhl website came back there would be scope for proposing and
>  co-ordinating projects like this. 
That's very strongly our intent.  I think that this would make an
excellent project.  I would suggest starting out by building a
web page and yum repository with a set of packages to support
this.  Building off Arjan's 2.6 kernel rpms would probably be the
best way to go.  I'd suggest discussing it on rhl-devel-list
rather than starting a new list, unless/until traffic gets very
high.  (Others here might have better suggestions; that's just
my first though.)  Does this sound interesting to you?

michaelkjohnson

 "He that composes himself is wiser than he that composes a book."
 Linux Application Development                     -- Ben Franklin
 http://people.redhat.com/johnsonm/lad/

UML (was: Re: was there an advertised ETA for the next beta?)

[M A Young]

On Wed, 13 Aug 2003, Michael K. Johnson wrote:

>  On Wed, Aug 13, 2003 at 03:44:53PM +0100, M A Young wrote:
>  > One of my reasons for posting was to guage interest. I was hoping that
>  > when the rhl website came back there would be scope for proposing and
>  > co-ordinating projects like this.
>
>  That's very strongly our intent.  I think that this would make an
>  excellent project.  I would suggest starting out by building a
>  web page and yum repository with a set of packages to support
>  this. 
Okay, I will try to get this project started by creating an initial web
page along the lines of what has been discussed in this thread.

	Michael Young