11:26 a.m.
[ Sorry, I'm on the digests, so this response won't thread correctly. ]
16. Fedora Goals (Rahul Sundaram)
From: Rahul Sundaram <sundaram(a)redhat.com>
Hi
We now have a roadmap page that describes project goals for Fedora Core
5. More information should be added about other major things like say
the SELinux MLS plans or the per user /tmp work , under a security
overview (potentially reorganised into layers ) depending on the amount
of indepth details that could be provided. Its a wiki page so everyone
including developers working on the major sub systems could pitch in
with their ideas and comments there.
http://www.fedoraproject.org/wiki/FC5Future
If there are things that is planned for the next release or split up
across versions , new "future" pages for FC5+x could be added to the
wiki. This is just a broad overview of things that is planned to be done
and not necessarily core stuff or code related. If there isnt enough to
time to complete it within the current release, one could always push it
to the next one. It would help the community understand the plans and
serve as a work list for developers.
Thanks to everyone who worked on this
I'm a long-time lurker (and long-time general annoyance) to many, but I
would _love_ to start to tackle a fully LSB-compliant/ideal init with
dependency checking, etc... for FC5+. I probably force bash (and even
legacy Bourne sh on non-Linux) far more than I should (although I'll
break out the Perl and, gasp, C when needbe), so I think this is right
up my part-time (maybe 10 hours/week) alley if I could be any
assistance to the team.
I'm sure some code could already be leveraged from SuSE's dependency
init approach. When in doubt on anything, LSB and then legacy Red Hat
is the final consideration (i.e., I won't just be blindly forcing SuSE's logic).
I have haven't checked if it's under GPL, but I seriously doubt Novell
hasn't made it such (I'll make sure).
Another option to consider is an "optional" rcS.d directory, which wouldn't
be used by default, but is available for packages that want to drop in
scripts before the run-levels start. It would be a nice option for those
coming from Solaris, SuSE and others that have it. But, again, this is
just an idea to create such an option for dropping scripts (tell me to
shelve the idea if its not a good idea right now).
-- Bryan
P.S. You don't know how many times I've wanted to kill portmapper and
tire of bash statements like: ;->
# service nfs stop && service nfslock stop && service portmap restart
&& service nfslock start && service nfs start
And that's assuming I'm not running even more RPC services! @-p
So damn I'll go ahead put my ass out and get it going! As I said before,
I'm used to forcing bash (as well as legacy Bourne sh on non-Linux
platforms) to do lots of things C/Perl coders roll their eyes at me for.
So count me in (and who's currently working on this?)!
--
Bryan J. Smith mailto:b.j.smith@ieee.org
3:55 p.m.
Bryan J. Smith <b.j.smith(a)ieee.org> (thebs413(a)earthlink.net) said:
I'm a long-time lurker (and long-time general annoyance) to many,
but I
would _love_ to start to tackle a fully LSB-compliant/ideal init with
dependency checking, etc... for FC5+. I probably force bash (and even
legacy Bourne sh on non-Linux) far more than I should (although I'll
break out the Perl and, gasp, C when needbe), so I think this is right
up my part-time (maybe 10 hours/week) alley if I could be any
assistance to the team.
Well, there are some plans here. They don't usually involve bash,
though, and generally consist of migrating to a completely different
framework, with support for legacy installation concerns such
as LSB compatibility and the current init-style scripts.
So count me in (and who's currently working on this?)!
No one, just yet. :)
Bill
4:27 p.m.
On Mon, 2005-06-06 at 16:55 -0400, Bill Nottingham wrote:
Bryan J. Smith <b.j.smith(a)ieee.org> (thebs413(a)earthlink.net)
said:
> I'm a long-time lurker (and long-time general annoyance) to many, but I
> would _love_ to start to tackle a fully LSB-compliant/ideal init with
> dependency checking, etc... for FC5+. I probably force bash (and even
> legacy Bourne sh on non-Linux) far more than I should (although I'll
> break out the Perl and, gasp, C when needbe), so I think this is right
> up my part-time (maybe 10 hours/week) alley if I could be any
> assistance to the team.
Well, there are some plans here. They don't usually involve bash,
though, and generally consist of migrating to a completely different
framework, with support for legacy installation concerns such
as LSB compatibility and the current init-style scripts.
> So count me in (and who's currently working on this?)!
No one, just yet. :)
Well we do have the session work somewhat done in an experimental stage.
We are targeting the session for dependency loading of session services
a) to make the session startup stuff more robust and b) to see if the
idea will fly for more complex situations such as a replacement for
init. I gave a short 5 minute talk on it at GUADEC. You can check out
the video here:
http://stream.fluendo.com/archive/6uadec/Lightning_Talks.ogg
Mine is 32 minutes and 30 seconds in.
Basically while most of the code can't be reused (glib dependencies)
the methods and policies created here will be able to be transported to
a system wide service framework.
--
John (J5) Palmieri
Associate Software Engineer
Desktop Group
Red Hat, Inc.
Blog: http://martianrock.com
8:24 a.m.
On Mon, 2005-06-06 at 16:55 -0400, Bill Nottingham wrote:
Well, there are some plans here. They don't usually involve bash,
Well, I'm half-way decent at system-level C (even some real-time
experience), as well as Perl, but no Python though (one of these
days).
though, and generally consist of migrating to a completely different
framework, with support for legacy installation concerns such
as LSB compatibility and the current init-style scripts.
So the base won't be traditional System-V init?
--
Bryan J. Smith b.j.smith(a)ieee.org
---------------------------------------------------------------------
It is mathematically impossible for someone who makes more than you
to be anything but richer than you. Any tax rate that penalizes them
will also penalize you similarly (to those below you, and then below
them). Linear algebra, let alone differential calculus or even ele-
mentary concepts of limits, is mutually exclusive with US journalism.
So forget even attempting to explain how tax cuts work. ;->
11:10 a.m.
Bryan J. Smith (b.j.smith(a)ieee.org) said:
On Mon, 2005-06-06 at 16:55 -0400, Bill Nottingham wrote:
> Well, there are some plans here. They don't usually involve bash,
Well, I'm half-way decent at system-level C (even some real-time
experience), as well as Perl, but no Python though (one of these
days).
> though, and generally consist of migrating to a completely different
> framework, with support for legacy installation concerns such
> as LSB compatibility and the current init-style scripts.
So the base won't be traditional System-V init?
Correct. (Well, the core *init* under everything may or may not
change; but it certainly won't be the same interface from userland.)
Bill
1:05 p.m.
Bill Nottingham wrote:
Bryan J. Smith (b.j.smith(a)ieee.org) said:
>On Mon, 2005-06-06 at 16:55 -0400, Bill Nottingham wrote:
>
>
>>though, and generally consist of migrating to a completely different
>>framework, with support for legacy installation concerns such
>>as LSB compatibility and the current init-style scripts.
>>
>>
>So the base won't be traditional System-V init?
>
>
Correct. (Well, the core *init* under everything may or may not
change; but it certainly won't be the same interface from userland.)
Bill
I hate to be the bad guy over here, but what about something similar
with SMF from Solaris. It's by far the best thing for what we need, and
it's already there and functional. It provides dependancy checking, and
any other feature you can think of. It should be easy to combine with
SELinux knowing all that information that is provided in the service xml
files. Let's try not to reinvent the wheel due to political issues
between Sun Microsystems and Red Hat.
Best regards,
Razvan
P.S. for a short presentation with enough information to get you excited
about this check out
http://www.filibeto.org/aduritz/truetrue/solaris10/sol-smf.pdf and
http://mediacast.sun.com/share/lianep/t-smf-general-march-2005.pdf .
1:15 p.m.
Bill Nottingham wrote:
Razvan Corneliu C.R. Vilt (razvan.vilt(a)linux360.ro) said:
>I hate to be the bad guy over here, but what about something similar
>with SMF from Solaris.
>
>
License?
Bill
Good point. But based on the docs on the internet, we could implement
something similar in functionality. They kinda had the same problems
that we are facing right now. I suspect that it should be soon covered
by the CDDL Licence, provided the imminent OpenSolaris release. Although
not GPL, I think that it's good enough to be included in Fedora Core,
due to it's Mozilla Public Licence heritage diff at
http://www.sun.com/cddl/CDDL_MPL_redline.pdf and FAQ at
http://www.opensolaris.org/faq/licensing_faq.html and licence at
http://www.opensolaris.org/license/cddl_license.txt.
Cheers,
Razvan
1:17 p.m.
Razvan Corneliu C.R. Vilt (razvan.vilt(a)linux360.ro) said:
Good point. But based on the docs on the internet, we could implement
something similar in functionality. They kinda had the same problems
that we are facing right now. I suspect that it should be soon covered
by the CDDL Licence, provided the imminent OpenSolaris release. Although
not GPL, I think that it's good enough to be included in Fedora Core,
due to it's Mozilla Public Licence heritage diff at
http://www.sun.com/cddl/CDDL_MPL_redline.pdf and FAQ at
http://www.opensolaris.org/faq/licensing_faq.html and licence at
http://www.opensolaris.org/license/cddl_license.txt.
No, CDDL (like ASPL, actually) isn't a viable license for Fedora code.
Bill
1:20 p.m.
On Tue, 2005-06-07 at 14:17 -0400, Bill Nottingham wrote:
Razvan Corneliu C.R. Vilt (razvan.vilt(a)linux360.ro) said:
> Good point. But based on the docs on the internet, we could implement
> something similar in functionality. They kinda had the same problems
> that we are facing right now. I suspect that it should be soon covered
> by the CDDL Licence, provided the imminent OpenSolaris release. Although
> not GPL, I think that it's good enough to be included in Fedora Core,
> due to it's Mozilla Public Licence heritage diff at
> http://www.sun.com/cddl/CDDL_MPL_redline.pdf and FAQ at
> http://www.opensolaris.org/faq/licensing_faq.html and licence at
> http://www.opensolaris.org/license/cddl_license.txt.
No, CDDL (like ASPL, actually) isn't a viable license for Fedora code.
Bill
Bill,
Specifics?
-edge
1:55 p.m.
Edginton, Brian (GE Healthcare) (Brian.Edginton(a)ge.com) said:
> No, CDDL (like ASPL, actually) isn't a viable license for
Fedora code.
Specifics?
Just the hazy memory of a conversation I had. I'll try to dig up
some.
It's GPL-incompatible, of course.
What could be done with it is the same thing that's done with
launchd; look at the docs/manauls, see the general way it works,
and go from there. But looking at the code and trying to reimplement
it that way is right out.
Bill
2:21 p.m.
Bill Nottingham wrote:
Edginton, Brian (GE Healthcare) (Brian.Edginton(a)ge.com) said:
>>No, CDDL (like ASPL, actually) isn't a viable license for Fedora code.
>>
>>
> Specifics?
>
>
Just the hazy memory of a conversation I had. I'll try to dig up
some.
It's GPL-incompatible, of course.
What could be done with it is the same thing that's done with
launchd; look at the docs/manauls, see the general way it works,
and go from there. But looking at the code and trying to reimplement
it that way is right out.
Bill
That reminds me. What are we to do regarding the network scripts? Bug
145464 (gre scripts) springs in my mind right now. We have two separate
issues. The lack of network scripts for stuff like gre/ipip and many
others. How should this be integrated in the new init stuff. Like a
service or lower-level (rc.sysinit style but in the new init would
probably be in C) ?
I purpose that a new wiki page should be set-up for this. It's the only
place where only the ideas remain and not the eventual flames that a
thread might contain. As a bonus it can be better organised, thus easier
to read than the email archives.
Razvan
2:23 p.m.
That reminds me. What are we to do regarding the network scripts? Bug
145464 (gre scripts) springs in my mind right now. We have two
separate issues. The lack of network scripts for stuff like gre/ipip
and many others. How should this be integrated in the new init stuff.
Like a service or lower-level (rc.sysinit style but in the new init
would probably be in C) ?
I purpose that a new wiki page should be set-up for this. It's the
only place where only the ideas remain and not the eventual flames
that a thread might contain. As a bonus it can be better organised,
thus easier to read than the email archives.
Razvan
Geez, are you people fast. You've already set-up the wiki.
2:32 p.m.
Razvan Corneliu C.R. Vilt wrote:
> That reminds me. What are we to do regarding the network scripts? Bug
> 145464 (gre scripts) springs in my mind right now. We have two
> separate issues. The lack of network scripts for stuff like gre/ipip
> and many others. How should this be integrated in the new init stuff.
> Like a service or lower-level (rc.sysinit style but in the new init
> would probably be in C) ?
>
> I purpose that a new wiki page should be set-up for this. It's the
> only place where only the ideas remain and not the eventual flames
> that a thread might contain. As a bonus it can be better organised,
> thus easier to read than the email archives.
>
> Razvan
>
Geez, are you people fast. You've already set-up the wiki.
...and Bill has already prettied it up a bit. ;-)
--
Patrick "The N-Man" Barnes
nman64(a)n-man.com
www.n-man.com
--
2:38 p.m.
Razvan Corneliu C.R. Vilt (razvan.vilt(a)linux360.ro) said:
That reminds me. What are we to do regarding the network scripts? Bug
145464 (gre scripts) springs in my mind right now. We have two separate
issues. The lack of network scripts for stuff like gre/ipip and many
others. How should this be integrated in the new init stuff. Like a
service or lower-level (rc.sysinit style but in the new init would
probably be in C) ?
Eventually?
All the networking scripts go away and are replaced with calls
into NetworkManager. :)
Bill
2:55 p.m.
On Tue, 2005-06-07 at 15:38 -0400, Bill Nottingham wrote:
Eventually?
All the networking scripts go away and are replaced with calls
into NetworkManager. :)
Thank god. But... Where does that leave the gre bug? Not to mention
that, although it's quite a nice thing, NetworkManager screwed up
totally for me a couple of times. It started the dhcp daemon instead of
taking that damned static ip address. But those are bugs and will be
solved by the time we actually do this.
Bill
Razvan
2:57 a.m.
On Wednesday 08 June 2005 04:05, "Razvan Corneliu C.R. Vilt"
<razvan.vilt(a)linux360.ro> wrote:
I hate to be the bad guy over here, but what about something similar
with SMF from Solaris. It's by far the best thing for what we need, and
Is this the Solaris feature that so many people complain about because it
makes changes to a binary file on every boot?
--
http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/ Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/ My home page
10:24 a.m.
On Fri, 10 Jun 2005, Russell Coker wrote:
On Wednesday 08 June 2005 04:05, "Razvan Corneliu C.R.
Vilt"
<razvan.vilt(a)linux360.ro> wrote:
> I hate to be the bad guy over here, but what about something similar
> with SMF from Solaris. It's by far the best thing for what we need, and
Is this the Solaris feature that so many people complain about because it
makes changes to a binary file on every boot?
There's an /etc/svc/repository.db that's a transactional db which gets
updated continuously as svc state changes, including at system boot as
svcs start up. There's also a backup of that db made at every boot,
/etc/svc/repository-boot-$timestamp, since if you corrupt
/etc/svc/repository.db you're in trouble (you'll crash down to single-user
at boot and have to restore / regenerate)
I'm not aware of the updating of that file being a cause for major
complaint amongst Solaris types though ;-)
later,
chris
1:23 p.m.
On Tue, 7 Jun 2005, Bill Nottingham wrote:
Bryan J. Smith (b.j.smith(a)ieee.org) said:
> On Mon, 2005-06-06 at 16:55 -0400, Bill Nottingham wrote:
> > Well, there are some plans here. They don't usually involve bash,
>
> Well, I'm half-way decent at system-level C (even some real-time
> experience), as well as Perl, but no Python though (one of these
> days).
>
> > though, and generally consist of migrating to a completely different
> > framework, with support for legacy installation concerns such
> > as LSB compatibility and the current init-style scripts.
>
> So the base won't be traditional System-V init?
Correct. (Well, the core *init* under everything may or may not
change; but it certainly won't be the same interface from userland.)
Is this going to be based on / similar to anything existing, or something
new entirely?
So far, everything you've said is sounding a *lot* like the redone
services stuff in Solaris 10. The main difference would just be the use of
D-BUS for communication rather than the Solaris-specific stuff SMF
uses (svc.startd, mainly)....
See <http://docs.sun.com/app/docs/doc/817-1985/6mhm8o5n0?a=view> for an
overview of svcs, svcadm, svccfg, etc
As an added benefit, the architecture Sun has for all this really has
drastically reduced boot times (which I know is always a complaint people
seem to have on Linux for some reason). Solaris 9 -> Solaris 10 went from
~3 minutes to ~25 seconds to boot (from the OBP to login prompt) on one of
my workstations, for example
later,
chris
2:16 p.m.
Chris Ricker wrote:
On Tue, 7 Jun 2005, Bill Nottingham wrote:
>Bryan J. Smith (b.j.smith(a)ieee.org) said:
>
>
>>On Mon, 2005-06-06 at 16:55 -0400, Bill Nottingham wrote:
>>
>>
>>>Well, there are some plans here. They don't usually involve bash,
>>>
>>>
>>Well, I'm half-way decent at system-level C (even some real-time
>>experience), as well as Perl, but no Python though (one of these
>>days).
>>
>>
>>
>>>though, and generally consist of migrating to a completely different
>>>framework, with support for legacy installation concerns such
>>>as LSB compatibility and the current init-style scripts.
>>>
>>>
>>So the base won't be traditional System-V init?
>>
>>
>Correct. (Well, the core *init* under everything may or may not
>change; but it certainly won't be the same interface from userland.)
>
>
Is this going to be based on / similar to anything existing, or something
new entirely?
So far, everything you've said is sounding a *lot* like the redone
services stuff in Solaris 10. The main difference would just be the use of
D-BUS for communication rather than the Solaris-specific stuff SMF
uses (svc.startd, mainly)....
See <http://docs.sun.com/app/docs/doc/817-1985/6mhm8o5n0?a=view> for an
overview of svcs, svcadm, svccfg, etc
As an added benefit, the architecture Sun has for all this really has
drastically reduced boot times (which I know is always a complaint people
seem to have on Linux for some reason). Solaris 9 -> Solaris 10 went from
~3 minutes to ~25 seconds to boot (from the OBP to login prompt) on one of
my workstations, for example
later,
chris
It will probably be a new implementation, but might contain code or
ideas from existing projects.
See the (new) wiki page at http://fedoraproject.org/wiki/FCNewInit for
an outline of what's on the table.
--
Patrick "The N-Man" Barnes
nman64(a)n-man.com
www.n-man.com
--
2:21 p.m.
Hi
It will probably be a new implementation, but might contain code or
ideas from existing projects.
See the (new) wiki page at http://fedoraproject.org/wiki/FCNewInit for
an outline of what's on the table.
Err, thats just a copy of the email from Bill that I posted into the
wiki for reference
regards
Rahul
2:30 p.m.
Rahul Sundaram wrote:
Hi
>
> It will probably be a new implementation, but might contain code or
> ideas from existing projects.
>
> See the (new) wiki page at http://fedoraproject.org/wiki/FCNewInit for
> an outline of what's on the table.
Err, thats just a copy of the email from Bill that I posted into the
wiki for reference
regards
Rahul
It's a good starting point at least. It quite well sums up the overall
results of this discussion thus far.
--
Patrick "The N-Man" Barnes
nman64(a)n-man.com
www.n-man.com
--
4:54 p.m.
Bryan J. Smith <b.j.smith(a)ieee.org> wrote:
[ Sorry, I'm on the digests, so this response won't thread
correctly. ]
16. Fedora Goals (Rahul Sundaram)
From: Rahul Sundaram <sundaram(a)redhat.com>
>Hi
>We now have a roadmap page that describes project goals for Fedora Core
>5. More information should be added about other major things like say
>the SELinux MLS plans or the per user /tmp work , under a security
>overview (potentially reorganised into layers ) depending on the amount
>of indepth details that could be provided. Its a wiki page so everyone
>including developers working on the major sub systems could pitch in
>with their ideas and comments there.
>http://www.fedoraproject.org/wiki/FC5Future
>If there are things that is planned for the next release or split up
>across versions , new "future" pages for FC5+x could be added to the
>wiki. This is just a broad overview of things that is planned to be done
>and not necessarily core stuff or code related. If there isnt enough to
>time to complete it within the current release, one could always push it
>to the next one. It would help the community understand the plans and
>serve as a work list for developers.
>Thanks to everyone who worked on this
>
>
I'm a long-time lurker (and long-time general annoyance) to many, but I
would _love_ to start to tackle a fully LSB-compliant/ideal init with
dependency checking, etc... for FC5+. I probably force bash (and even
legacy Bourne sh on non-Linux) far more than I should (although I'll
break out the Perl and, gasp, C when needbe), so I think this is right
up my part-time (maybe 10 hours/week) alley if I could be any
assistance to the team.
I'm sure some code could already be leveraged from SuSE's dependency
init approach. When in doubt on anything, LSB and then legacy Red Hat
is the final consideration (i.e., I won't just be blindly forcing SuSE's logic).
I have haven't checked if it's under GPL, but I seriously doubt Novell
hasn't made it such (I'll make sure).
Another option to consider is an "optional" rcS.d directory, which wouldn't
be used by default, but is available for packages that want to drop in
scripts before the run-levels start. It would be a nice option for those
coming from Solaris, SuSE and others that have it. But, again, this is
just an idea to create such an option for dropping scripts (tell me to
shelve the idea if its not a good idea right now).
-- Bryan
P.S. You don't know how many times I've wanted to kill portmapper and
tire of bash statements like: ;->
# service nfs stop && service nfslock stop && service portmap restart
&& service nfslock start && service nfs start
And that's assuming I'm not running even more RPC services! @-p
So damn I'll go ahead put my ass out and get it going! As I said before,
I'm used to forcing bash (as well as legacy Bourne sh on non-Linux
platforms) to do lots of things C/Perl coders roll their eyes at me for.
So count me in (and who's currently working on this?)!
--
Bryan J. Smith mailto:b.j.smith@ieee.org
I think many of the ideas for an improved init system sound awesome, but
perhaps you could expand the scope and draw more assistance. Consider
creating a project at SourceForge and involving members from other
distributions. This will help garner support for the methods you use
(instead of creating a Fedora-only solution), increase the number of
volunteers to help you out, provide a full project space to work in, and
will provide a larger forum for feedback. Make sure you come back here
and let us know once your project is created, though. I'm sure several
people here will be interested in your efforts.
--
Patrick "The N-Man" Barnes
nman64(a)n-man.com
www.n-man.com
--
6931
days inactive
3285
days old
22 comments
10 participants
participants (10)
-
Bill Nottingham -
Bryan J. Smith <b.j.smith＠ieee.org> -
Bryan Smith -
Chris Ricker -
Edginton, Brian (GE Healthcare) -
John (J5) Palmieri -
Patrick W. Barnes -
Rahul Sundaram -
Razvan Corneliu C.R. "d3vi1" VILT -
Russell Coker