System-config Reworking Proposal

[Arthur Pemberton]

I have expressed my ideas[1] to add and rework some of the
functionality of the system-config tools with the hope of making them
a bit more innovative and useful.

Please comment on the idea.

I am personally interested in pursuing the implementation in Python.

[1] http://fedoraproject.org/wiki/SystemConfig/ProposalVConsole

Arthur Pemberton

-- 
Fedora 7 : sipping some of that moonshine
( www.pembo13.com )

[Tim Waugh]

On Mon, 2007-11-19 at 01:18 -0600, Arthur Pemberton wrote:
>  Please comment on the idea. 
I'd like to know whether you are considering system-config-printer to be
part of this scheme.  CUPS configuration is quite different from other
configuration tools, and a method based on altering configuration files
would be a big regression.

Tim.
*/

[Nils Philippsen]

On Mon, 2007-11-19 at 11:12 +0000, Tim Waugh wrote:
>  On Mon, 2007-11-19 at 01:18 -0600, Arthur Pemberton wrote:
>  > Please comment on the idea.
>  
>  I'd like to know whether you are considering system-config-printer to be
>  part of this scheme.  CUPS configuration is quite different from other
>  configuration tools, and a method based on altering configuration files
>  would be a big regression. 
For my tools (-date, -nfs, -samba, -services, -users), just being able
to edit files is also not sufficient. Often these tools don't edit files
themselves but use e.g. chkconfig or libuser, partly it isn't even known
whether local files are changed or some objects in an LDAP directory.

In my eyes, we first need to get UI, logic and privileged operations
cleanly separated. Then we can think about additional stuff like logging
of operations (would be put between UI and logic) or move stuff from
using usermode to PolicyKit.

Nils
-- 
     Nils Philippsen    /    Red Hat    /    nphilipp(a)redhat.com
"Those who would give up Essential Liberty to purchase a little Temporary
 Safety, deserve neither Liberty nor Safety."  --  B. Franklin, 1759
 PGP fingerprint:  C4A8 9474 5C4C ADE3 2B8F  656D 47D8 9B65 6951 3011

working with gnome project/other distros together on system tools (was: Re: System-config Reworking Proposal)

[Thorsten Leemhuis]

On 19.11.2007 14:49, Nils Philippsen wrote:
>  On Mon, 2007-11-19 at 11:12 +0000, Tim Waugh wrote:
> > On Mon, 2007-11-19 at 01:18 -0600, Arthur Pemberton wrote:
> >> Please comment on the idea.
> > I'd like to know whether you are considering system-config-printer to be
> > part of this scheme.  CUPS configuration is quite different from other
> > configuration tools, and a method based on altering configuration files
> > would be a big regression.
>  In my eyes, we first need to get UI, logic and privileged operations
>  cleanly separated. Then we can think about additional stuff like logging
>  of operations (would be put between UI and logic) or move stuff from
>  using usermode to PolicyKit. 
Just wondering: Why don't we work towards getting some sane config tools
(seperated in UI, logic, ...) close to Gnome (and KDE, should there be
interest)? Sure, that way other distros will benefit from out work as
well, but on the other hand having stuff as de-facto part of Gnome and
used by other distros afaics lead to better tools and a better user
experience, which overall leads to a better "Linux".

Take gnome-power-manager as example -- until not that long ago each
distro had there own black- and whitelists for the workarounds that make
suspend simply work. That worked not to bad, but not perfectly and much
man-hours were wasted as each distro had to maintain their own lists.
Now we have gnome-power-manager as common upstream, which gets used by
Fedora, OpenSuse, Ubuntu and some others -- all those help getting the
data improved which really improved the situation a lot afaics, as
everyone benefits from the work.

PackageKit seems to be the next area where lots of distributions did
their own thing for a long time and now work together. I'm really
wondering how long it will take until PackageKit and its tools will
replace pup and pirut. So maybe both tools that were developed not that
long ago might vanish and become history over the next two years.

CU
knurd

working with gnome project/other distros together on system tools (was: Re: System-config Reworking Proposal)

[Nils Philippsen]

On Mon, 2007-11-19 at 15:06 +0100, Thorsten Leemhuis wrote:

>  Just wondering: Why don't we work towards getting some sane
> config tools
>  (seperated in UI, logic, ...) close to Gnome (and KDE, should there be
>  interest)? Sure, that way other distros will benefit from out work as
>  well, but on the other hand having stuff as de-facto part of Gnome and
>  used by other distros afaics lead to better tools and a better user
>  experience, which overall leads to a better "Linux". 
AFAIK, some stuff, e.g. date and time setting via the time applet,
creating users, is already worked on for GNOME. Whether these will cover
all aspects (e.g. also server specific stuff), I don't know. Whether
these should cover non-desktop aspects at all can also be disputed ;-).

Certainly, once UI and logic of the existing tools are sufficiently
separated the logic could be used from applets/tools more tightly
integrated into the desktop environment of choice if there's the need.

Nils
-- 
     Nils Philippsen    /    Red Hat    /    nphilipp(a)redhat.com
"Those who would give up Essential Liberty to purchase a little Temporary
 Safety, deserve neither Liberty nor Safety."  --  B. Franklin, 1759
 PGP fingerprint:  C4A8 9474 5C4C ADE3 2B8F  656D 47D8 9B65 6951 3011

working with gnome project/other distros together on system tools (was: Re: System-config Reworking Proposal)

[Matthias Clasen]

On Mon, 2007-11-19 at 16:37 +0100, Nils Philippsen wrote:
>  On Mon, 2007-11-19 at 15:06 +0100, Thorsten Leemhuis wrote:
>  
>  > Just wondering: Why don't we work towards getting some sane config tools
>  > (seperated in UI, logic, ...) close to Gnome (and KDE, should there be
>  > interest)? Sure, that way other distros will benefit from out work as
>  > well, but on the other hand having stuff as de-facto part of Gnome and
>  > used by other distros afaics lead to better tools and a better user
>  > experience, which overall leads to a better "Linux".
>  
>  AFAIK, some stuff, e.g. date and time setting via the time applet,
>  creating users, is already worked on for GNOME. Whether these will cover
>  all aspects (e.g. also server specific stuff), I don't know. Whether
>  these should cover non-desktop aspects at all can also be disputed ;-).
>  
>  Certainly, once UI and logic of the existing tools are sufficiently
>  separated the logic could be used from applets/tools more tightly
>  integrated into the desktop environment of choice if there's the need. 
Might be worthwhile to point out that there is prior art in this area
with gnome-system-tools. They already have the ui/mechanism split and
are moving towards adopting PolicyKit. The traditional complaint about
them has been that they have no distro adoption, but I recently learned
that probably at least Debian/Ubuntu, Gentoo and FreeBSD are using them
nowadays.

There are admittedly a few warts:
- the backends used to be written in perl (not sure if that is still the
case)
- they follow the kitchen-sink approach of keeping everything in a
single system-tools-backends package 

If we are talking about cross-distro collaboration for traditional
system-config tools, that may be the leading contender. 

What we in the desktop team want to push a little further in F9 is to
move some system configuration tasks into the regular tools where that
makes sense. An early example of that is the time+timezone setting
inside the clock applet, other examples to follow will be a "Use these
settings system-wide" button for the power management preferences and
some other areas where it makes sense. Access to this will be controlled
via PolicyKit as well.


Matthias

working with gnome project/other distros together on system tools (was: Re: System-config Reworking Proposal)

[David Zeuthen]

On Mon, 2007-11-19 at 15:06 +0100, Thorsten Leemhuis wrote:
>  Just wondering: Why don't we work towards getting some sane
> config tools
>  (seperated in UI, logic, ...) close to Gnome (and KDE, should there be
>  interest)? Sure, that way other distros will benefit from out work as
>  well, but on the other hand having stuff as de-facto part of Gnome and
>  used by other distros afaics lead to better tools and a better user
>  experience, which overall leads to a better "Linux". 
This is actually what we've been working on in the RH/Fedora desktop
team for quite some time. The mantra here, as you point out, is both
"upstream", proper separation of the user interface and the mechanism,
access control and, ideally, integration with directory services such as
the Fedora Directory Server.

Actually for home/consumer desktop use, there is not much need for any
of the system-config-* tools any more; for example for F9, intlclock
will replace system-config-date and Søren's work on xrandr UI will
probably be able to replace most of system-config-display. The former,
at least, is getting merged into upstream GNOME as we speak. The latter,
I believe, will be proposed for GNOME as well. Søren?

As for server use... e.g. s-c-httpd and friends I'm not sure. I've
always found it rather odd to use an UI for this in the first place but
I do acknowledge that some of our users find this useful. It's
definitely something that is on the check-list of many system
administrators especially those from the Windows world.

In my opinion, the most important thing to fix with our remaining
system-config-* tools is to get upstream buy-in (ideally merge it into
GNOME/KDE/freedesktop.org/whatever), properly separate the UI from the
mechanism and use things like PolicyKit for access control. Notably, Tim
is doing a pretty good job here with s-c-printer; that's why Ubuntu got
the best printing support on the planet :-) [1]

      David

[1] : I'm being sarcastic because space boy doesn't always give credit
where credit is due. Sources have told me that someone is working on
"fixing" this problem though

working with gnome project/other distros together on system tools

[Thorsten Leemhuis]

On 19.11.2007 18:28, David Zeuthen wrote:
>  On Mon, 2007-11-19 at 15:06 +0100, Thorsten Leemhuis wrote:
> > Just wondering: Why don't we work towards getting some sane config tools
> > (seperated in UI, logic, ...) close to Gnome (and KDE, should there be
> > interest)? Sure, that way other distros will benefit from out work as
> > well, but on the other hand having stuff as de-facto part of Gnome and
> > used by other distros afaics lead to better tools and a better user
> > experience, which overall leads to a better "Linux".
>  This is actually what we've been working on in the RH/Fedora desktop
>  team for quite some time. The mantra here, as you point out, is both
>  "upstream", proper separation of the user interface and the mechanism,
>  access control and, ideally, integration with directory services such as
>  the Fedora Directory Server. 
Thx for this (and your work), and yeah, I was aware of that -- but from
the current discussion around the system-config-tools on this list I got
the impression that other people in Fedora-land work towards a different
direction.

>  [...]
>  In my opinion, the most important thing to fix with our remaining
>  system-config-* tools is to get upstream buy-in (ideally merge it into
>  GNOME/KDE/freedesktop.org/whatever), properly separate the UI from the
>  mechanism and use things like PolicyKit for access control. Notably, Tim
>  is doing a pretty good job here with s-c-printer; that's why Ubuntu got
>  the best printing support on the planet :-) [1] 
+1, especially for the s-c-printer part

Cu
knurd

working with gnome project/other distros together on system tools (was: Re: System-config Reworking Proposal)

[Nils Philippsen]

On Mon, 2007-11-19 at 12:28 -0500, David Zeuthen wrote:
>  On Mon, 2007-11-19 at 15:06 +0100, Thorsten Leemhuis wrote:
>  > Just wondering: Why don't we work towards getting some sane config tools
>  > (seperated in UI, logic, ...) close to Gnome (and KDE, should there be
>  > interest)? Sure, that way other distros will benefit from out work as
>  > well, but on the other hand having stuff as de-facto part of Gnome and
>  > used by other distros afaics lead to better tools and a better user
>  > experience, which overall leads to a better "Linux".
>  
>  This is actually what we've been working on in the RH/Fedora desktop
>  team for quite some time. The mantra here, as you point out, is both
>  "upstream", proper separation of the user interface and the mechanism,
>  access control and, ideally, integration with directory services such as
>  the Fedora Directory Server.
>  
>  Actually for home/consumer desktop use, there is not much need for any
>  of the system-config-* tools any more; for example for F9, intlclock
>  will replace system-config-date 
... as the tool that is launched when you click on your (GNOME) panel
clock -> "Adjust Date & Time". I don't see s-c-date going away
anytime
soon (as the maintainer I'm a bit biased), at least as long as the DE
specific tools are full replacements.

>   and Søren's work on xrandr UI will
>  probably be able to replace most of system-config-display. The former,
>  at least, is getting merged into upstream GNOME as we speak. The latter,
>  I believe, will be proposed for GNOME as well. Søren?
>  
>  As for server use... e.g. s-c-httpd and friends I'm not sure. I've
>  always found it rather odd to use an UI for this in the first place but
>  I do acknowledge that some of our users find this useful. It's
>  definitely something that is on the check-list of many system
>  administrators especially those from the Windows world.
>  
>  In my opinion, the most important thing to fix with our remaining
>  system-config-* tools is to get upstream buy-in (ideally merge it into
>  GNOME/KDE/freedesktop.org/whatever), properly separate the UI from the
>  mechanism and use things like PolicyKit for access control. Notably, Tim
>  is doing a pretty good job here with s-c-printer; that's why Ubuntu got
>  the best printing support on the planet :-) [1] 
Well, the idea of "whatever upstream" is most appealing to me as that
can as well be us ;-). Mind that as configuration tools aren't only
interesting to desktop users we should be careful under which umbrella
(if one) we put them. I'm with you as far as UI <-> logic <-> privileged
ops separation is concerned.

Nils
-- 
     Nils Philippsen    /    Red Hat    /    nphilipp(a)redhat.com
"Those who would give up Essential Liberty to purchase a little Temporary
 Safety, deserve neither Liberty nor Safety."  --  B. Franklin, 1759
 PGP fingerprint:  C4A8 9474 5C4C ADE3 2B8F  656D 47D8 9B65 6951 3011

working with gnome project/other distros together on system tools (was: Re: System-config Reworking Proposal)

[David Zeuthen]

On Tue, 2007-11-20 at 10:47 +0100, Nils Philippsen wrote:
>  > Actually for home/consumer desktop use, there is not much need
> for any
>  > of the system-config-* tools any more; for example for F9, intlclock
>  > will replace system-config-date
>  
>  ... as the tool that is launched when you click on your (GNOME) panel
>  clock -> "Adjust Date & Time". I don't see s-c-date going away
> anytime
>  soon (as the maintainer I'm a bit biased), at least as long as the DE
>  specific tools are full replacements. 
I'm pretty sure that Rawhide intlclock launches code shipped with
intlclock when you press "Adjust Date and Time". If it doesn't that's a
bug. FWIW, this is what it looks like

 http://people.freedesktop.org/~david/intlclock-change-time.png

Yes, this is in contrast to previous Fedora releases where s-c-d was
used.

>  Well, the idea of "whatever upstream" is most appealing to
> me as that
>  can as well be us ;-).  
Certainly. Keep in mind that Red Hat / Fedora are already upstream for a
lot of important key projects

 http://fedoraproject.org/wiki/RedHatContributions

So.. the key to participating in upstream projects is just that..
participating. Integrating features into where it makes sense; e.g. for
GNOME the clock applet and NetworkManager for the NTP bits.

Ideally the mechanism used by intlclock is independent of the UI
(intlclock will probably switch to fd.o system tools [1]) so it's easy
for people from KDE, XFCE, etc. to write their own UI shells. And, heck,
why the hell not a TUI version too. All using the same mechanism. All
benefiting from a huge pool of contributors across the free software OS
landscape; not just Linux, also OpenSolaris.

Which is, and sorry if this comes across as a flame, in contrast to
having a stand-alone monolith e.g. system-config-date.

[1] : Formerly (and sorta kinda still) known as gnome system tools

>  Mind that as configuration tools aren't only
>  interesting to desktop users we should be careful under which umbrella
>  (if one) we put them.  
It's not like anyone suggesting that s-c-d is going away. The change
here is that it's not likely to be in the default desktop install.
People can still install it and build spins around it and so forth.

>  I'm with you as far as UI <-> logic <-> privileged
>  ops separation is concerned. 
Sounds good.

       David

[Arthur Pemberton]

On Nov 19, 2007 7:49 AM, Nils Philippsen <nphilipp(a)redhat.com&gt; wrote:
>  For my tools (-date, -nfs, -samba, -services, -users), just being
> able
>  to edit files is also not sufficient. Often these tools don't edit files
>  themselves but use e.g. chkconfig or libuser, partly it isn't even known
>  whether local files are changed or some objects in an LDAP directory. 
Well I was considering that the doCommand, doCommandWait to take care
of that. Am I underestimating that need?

>  In my eyes, we first need to get UI, logic and privileged operations
>  cleanly separated. Then we can think about additional stuff like logging
>  of operations (would be put between UI and logic) or move stuff from
>  using usermode to PolicyKit. 
Seems like something that can be in parallel as part of the reworking.

-- 
Fedora 7 : sipping some of that moonshine
( www.pembo13.com )

[Nils Philippsen]

On Mon, 2007-11-19 at 10:33 -0600, Arthur Pemberton wrote:
>  On Nov 19, 2007 7:49 AM, Nils Philippsen <nphilipp(a)redhat.com&gt;
> wrote:
>  > For my tools (-date, -nfs, -samba, -services, -users), just being able
>  > to edit files is also not sufficient. Often these tools don't edit files
>  > themselves but use e.g. chkconfig or libuser, partly it isn't even known
>  > whether local files are changed or some objects in an LDAP directory.
>  
>  Well I was considering that the doCommand, doCommandWait to take care
>  of that. Am I underestimating that need? 
That would work for chkconfig, but not libuser. I won't resort to
calling luser{add,mod,del} ;-).

Nils
-- 
     Nils Philippsen    /    Red Hat    /    nphilipp(a)redhat.com
"Those who would give up Essential Liberty to purchase a little Temporary
 Safety, deserve neither Liberty nor Safety."  --  B. Franklin, 1759
 PGP fingerprint:  C4A8 9474 5C4C ADE3 2B8F  656D 47D8 9B65 6951 3011

[Arthur Pemberton]

On Nov 19, 2007 5:12 AM, Tim Waugh <twaugh(a)redhat.com&gt; wrote:
>  On Mon, 2007-11-19 at 01:18 -0600, Arthur Pemberton wrote:
>  > Please comment on the idea.
>
>  I'd like to know whether you are considering system-config-printer to be
>  part of this scheme.  CUPS configuration is quite different from other
>  configuration tools, and a method based on altering configuration files
>  would be a big regression. 

I'm not familiar with how system-config-printer works, if it uses port
631, then no I didn't consider yet at all. And I'm definetly not
considering it going through text configs first - that was just the
most obvious target so I considered it first.


-- 
Fedora 7 : sipping some of that moonshine
( www.pembo13.com )

[Lubomir Kundrak]

Hi,

On Mon, 2007-11-19 at 01:18 -0600, Arthur Pemberton wrote:
>  I have expressed my ideas[1] to add and rework some of the
>  functionality of the system-config tools with the hope of making them
>  a bit more innovative and useful.
>  
>  Please comment on the idea. 
>  Rework (not a total rewrite) system-config tools use a common virtual
> console which abstracts away local and remote console usage. Anticipated benefits:
>  
>      * transparently handle local or remote console (via ssh)
>            o allow configuration of remote services 
this is possible now:
ssh -X my.server system-config-httpd

>            o possible allow for OS independent usage (example:
> system-config-httpd could be used from Windows XP) 
You can do the very same thing from Windows XP.

>            o allow for those who prefer not to run server tools with a
> X server installed to make use of the system-config tools  
None of the system-config-* tools depends on X server except for
system-config-display.

>      * allows for centrally logging system-config actions (audit
> trail)
>      * standardize routines/functionality commonly used by system-config tools  
These seem to be a good ideas to me.

Regards,
-- 
Lubomir Kundrak (Red Hat Security Response Team)

[Thorsten Leemhuis]

On 19.11.2007 14:07, Lubomir Kundrak wrote:
>  On Mon, 2007-11-19 at 01:18 -0600, Arthur Pemberton wrote:
> > Rework (not a total rewrite) system-config tools use a common virtual console which
> abstracts away local and remote console usage. Anticipated benefits:
> >     * transparently handle local or remote console (via ssh)
> >           o allow configuration of remote services
>  this is possible now:
>  ssh -X my.server system-config-httpd 
Wile at it: For me as heavy sudo user it does not work properly:
https://bugzilla.redhat.com/show_bug.cgi?id=142648
https://bugzilla.redhat.com/show_bug.cgi?id=164671

CU
knurd

[Lubomir Kundrak]

On Mon, 2007-11-19 at 14:24 +0100, Thorsten Leemhuis wrote:
>  On 19.11.2007 14:07, Lubomir Kundrak wrote:
>  > On Mon, 2007-11-19 at 01:18 -0600, Arthur Pemberton wrote:
>  >> Rework (not a total rewrite) system-config tools use a common virtual console
> which abstracts away local and remote console usage. Anticipated benefits:
>  >>     * transparently handle local or remote console (via ssh)
>  >>           o allow configuration of remote services
>  > this is possible now:
>  > ssh -X my.server system-config-httpd
>  
>  Wile at it: For me as heavy sudo user it does not work properly:
>  https://bugzilla.redhat.com/show_bug.cgi?id=142648
>  https://bugzilla.redhat.com/show_bug.cgi?id=164671 
It can be fixed easily by dumping sudo.

-- 
Lubomir Kundrak (Red Hat Security Response Team)

[Rahul Sundaram]

Lubomir Kundrak wrote:
>  On Mon, 2007-11-19 at 14:24 +0100, Thorsten Leemhuis wrote:
> > On 19.11.2007 14:07, Lubomir Kundrak wrote:
> >> On Mon, 2007-11-19 at 01:18 -0600, Arthur Pemberton wrote:
> >>> Rework (not a total rewrite) system-config tools use a common virtual console
> which abstracts away local and remote console usage. Anticipated benefits:
> >>>     * transparently handle local or remote console (via ssh)
> >>>           o allow configuration of remote services
> >> this is possible now:
> >> ssh -X my.server system-config-httpd
> > Wile at it: For me as heavy sudo user it does not work properly:
> > https://bugzilla.redhat.com/show_bug.cgi?id=142648
> > https://bugzilla.redhat.com/show_bug.cgi?id=164671
>  
>  It can be fixed easily by dumping sudo. 
What? Why would we be dumping sudo?

Rahul

[Steve Grubb]

On Monday 19 November 2007 10:10:16 am Rahul Sundaram wrote:
>  > It can be fixed easily by dumping sudo.
>
>  What? Why would we be dumping sudo? 
We won't be. Its not his decision to make.

-Steve

[Nils Philippsen]

On Mon, 2007-11-19 at 10:33 -0500, Steve Grubb wrote:
>  On Monday 19 November 2007 10:10:16 am Rahul Sundaram wrote:
>  > > It can be fixed easily by dumping sudo.
>  >
>  > What? Why would we be dumping sudo?
>  
>  We won't be. Its not his decision to make. 
As all security people he may be a little bit adverse to stuff carrying
around a setuid bit ;-). </ObNotFriday>

Nils
-- 
     Nils Philippsen    /    Red Hat    /    nphilipp(a)redhat.com
"Those who would give up Essential Liberty to purchase a little Temporary
 Safety, deserve neither Liberty nor Safety."  --  B. Franklin, 1759
 PGP fingerprint:  C4A8 9474 5C4C ADE3 2B8F  656D 47D8 9B65 6951 3011

[Lubomir Kundrak]

On Mon, 2007-11-19 at 20:40 +0530, Rahul Sundaram wrote:
>  Lubomir Kundrak wrote:
>  > On Mon, 2007-11-19 at 14:24 +0100, Thorsten Leemhuis wrote:
>  >> On 19.11.2007 14:07, Lubomir Kundrak wrote:
>  >>> On Mon, 2007-11-19 at 01:18 -0600, Arthur Pemberton wrote:
>  >>>> Rework (not a total rewrite) system-config tools use a common virtual
> console which abstracts away local and remote console usage. Anticipated benefits:
>  >>>>     * transparently handle local or remote console (via ssh)
>  >>>>           o allow configuration of remote services
>  >>> this is possible now:
>  >>> ssh -X my.server system-config-httpd
>  >> Wile at it: For me as heavy sudo user it does not work properly:
>  >> https://bugzilla.redhat.com/show_bug.cgi?id=142648
>  >> https://bugzilla.redhat.com/show_bug.cgi?id=164671
>  > 
>  > It can be fixed easily by dumping sudo.
>  
>  What? Why would we be dumping sudo? 
I'm not saying we are. It was just a good friendly advise. Other
question would be -- why use it? Only use that can't be replaced by
other existing (and better) tools is to give untrusted users access to
privileged tools that weren't designed in security with mind.

-- 
Lubomir Kundrak (Red Hat Security Response Team)

[Rahul Sundaram]

Lubomir Kundrak wrote:

>  I'm not saying we are. It was just a good friendly advise. Other
>  question would be -- why use it? Only use that can't be replaced by
>  other existing (and better) tools is to give untrusted users access to
>  privileged tools that weren't designed in security with mind. 
If it was advise, it didn't sound quite like it. There are several 
hundreds of thousands of users using sudo regularly. Our tools should 
work with them regardless of whatever imperfections you perceive with 
using sudo. Having said that, if you have better alternatives to 
suggest, then it would make it a more complete advise.

Rahul

[Arthur Pemberton]

On Nov 19, 2007 7:24 AM, Thorsten Leemhuis <fedora(a)leemhuis.info&gt; wrote:
>  On 19.11.2007 14:07, Lubomir Kundrak wrote:
>  > On Mon, 2007-11-19 at 01:18 -0600, Arthur Pemberton wrote:
>  >> Rework (not a total rewrite) system-config tools use a common virtual console
> which abstracts away local and remote console usage. Anticipated benefits:
>  >>     * transparently handle local or remote console (via ssh)
>  >>           o allow configuration of remote services
>  > this is possible now:
>  > ssh -X my.server system-config-httpd
>
>  Wile at it: For me as heavy sudo user it does not work properly:
>  https://bugzilla.redhat.com/show_bug.cgi?id=142648
>  https://bugzilla.redhat.com/show_bug.cgi?id=164671 

Wel the idea was that the virtual console would be able to execute (or
not as the case might be) through sudo if that is what the system used


-- 
Fedora 7 : sipping some of that moonshine
( www.pembo13.com )

[Steve Grubb]

On Monday 19 November 2007 11:29:06 am Arthur Pemberton wrote:
>  > Wile at it: For me as heavy sudo user it does not work
> properly:
>  > https://bugzilla.redhat.com/show_bug.cgi?id=142648
>  > https://bugzilla.redhat.com/show_bug.cgi?id=164671
>
>  Wel the idea was that the virtual console would be able to execute (or
>  not as the case might be) through sudo if that is what the system used 
The above mentioned bz is against RHEL4. Sudo in F7/8 has env_keep with 
XAUTHORITY in the default config.  So, I think F9 sudo+system-config should 
work correctly.

-Steve

[Bruno Wolff III]

On Mon, Nov 19, 2007 at 14:07:13 +0100,
  Lubomir Kundrak <lkundrak(a)redhat.com&gt; wrote:
>  
>  None of the system-config-* tools depends on X server except for
>  system-config-display. 
You can actually use system-config-display without X running if you use
a --set- option. I had need of this after upgrading to F8 to get a base
xorg.conf file I could work with, as I am not comfortable writing one from
scratch and X didn't work without one because it used an invalid mode.

[Arthur Pemberton]

On Nov 19, 2007 7:07 AM, Lubomir Kundrak <lkundrak(a)redhat.com&gt; wrote:
>  Hi,
>
>  On Mon, 2007-11-19 at 01:18 -0600, Arthur Pemberton wrote:
>  > I have expressed my ideas[1] to add and rework some of the
>  > functionality of the system-config tools with the hope of making them
>  > a bit more innovative and useful.
>  >
>  > Please comment on the idea.
>
>  > Rework (not a total rewrite) system-config tools use a common virtual console which
> abstracts away local and remote console usage. Anticipated benefits:
>  >
>  >     * transparently handle local or remote console (via ssh)
>  >           o allow configuration of remote services
>
>  this is possible now:
>  ssh -X my.server system-config-httpd 
One question: I know about this method, but have never tried it myself
- doesn't it require an xserver on the host?

One comment: The crowd that really love the system-config tools would
like prefer not to be doing x forwarding via SSH


>  >           o possible allow for OS independent usage (example:
> system-config-httpd could be used from Windows XP)
>
>  You can do the very same thing from Windows XP. 
I was thinking more in terms of the user just running system-config-*
on Fedora|Windows|* and just enter in a host and passkey|user+pass and
make changes to the target system

>  >           o allow for those who prefer not to run server tools
> with a X server installed to make use of the system-config tools
>
>  None of the system-config-* tools depends on X server except for
>  system-config-display. 
True, but you do generally need a GUI to make use of the GUI system-config tools

>  >     * allows for centrally logging system-config actions (audit
> trail)
>  >     * standardize routines/functionality commonly used by system-config tools
>
>  These seem to be a good ideas to me.
>
>  Regards,
>  --
>  Lubomir Kundrak (Red Hat Security Response Team)
>
>  --
>  fedora-devel-list mailing list
>  fedora-devel-list(a)redhat.com
>  https://www.redhat.com/mailman/listinfo/fedora-devel-list
>  


-- 
Fedora 7 : sipping some of that moonshine
( www.pembo13.com )

[Steve Grubb]

Hi,

I kind of missed the beginning of this thread...too many things going on, but 
this needs some discussion in my opinion.

>      * allows for centrally logging system-config actions (audit
> trail) 
The audit trail we are currently maintaining is set in the audit system. 
Whatever anyone designs needs to work correctly with the audit system since 
it will be watching a lot of the config files. When someone is remotely 
configuring a machine, the loginuid will need to be set correctly for the 
remote user. Libaudit also has logging functions (with Python bindings) that 
ensures all the important information is recorded in the audit trail. Besides 
creating an audit trail, you also need a way to search for information in the 
audit trail. The audit system already has the needed reporting tools and is 
getting new GUI based tools in F9.

Thanks,
-Steve

[David Zeuthen]

On Mon, 2007-11-19 at 12:01 -0500, Steve Grubb wrote:
>  The audit system already has the needed reporting tools and is 
>  getting new GUI based tools in F9. 
Haven't seen a feature page for this yet; do you have on handy? I guess
without knowing how it works my only comment at this point would be that
we want to avoid writing X11 applications that run as root.

       David

[Steve Grubb]

On Monday 19 November 2007 12:16:48 pm David Zeuthen wrote:
>  > The audit system already has the needed reporting tools and is
>  > getting new GUI based tools in F9.
>
>  Haven't seen a feature page for this yet; do you have on handy? 
Nope. Not everything we do has been big enough to be called a feature.

>  I guess without knowing how it works my only comment at this point
> would be
>  that we want to avoid writing X11 applications that run as root. 
Agreed.

-Steve

[Lubomir Kundrak]

On Mon, 2007-11-19 at 10:27 -0600, Arthur Pemberton wrote:
>  On Nov 19, 2007 7:07 AM, Lubomir Kundrak <lkundrak(a)redhat.com&gt;
> wrote:
>  > Hi,
>  >
>  > On Mon, 2007-11-19 at 01:18 -0600, Arthur Pemberton wrote:
>  > > I have expressed my ideas[1] to add and rework some of the
>  > > functionality of the system-config tools with the hope of making them
>  > > a bit more innovative and useful.
>  > >
>  > > Please comment on the idea.
>  >
>  > > Rework (not a total rewrite) system-config tools use a common virtual console
> which abstracts away local and remote console usage. Anticipated benefits:
>  > >
>  > >     * transparently handle local or remote console (via ssh)
>  > >           o allow configuration of remote services
>  >
>  > this is possible now:
>  > ssh -X my.server system-config-httpd
>  
>  One question: I know about this method, but have never tried it myself
>  - doesn't it require an xserver on the host? 
It does not. Why would it?

>  One comment: The crowd that really love the system-config tools
> would
>  like prefer not to be doing x forwarding via SSH 
Why? Wasn't it the reason why X forwarding was born? Well, he can do
that without the forwarding, by just setting DISPLAY, with no obvious
benefits :)

>  > >           o possible allow for OS independent usage
> (example: system-config-httpd could be used from Windows XP)
>  >
>  > You can do the very same thing from Windows XP.
>  
>  I was thinking more in terms of the user just running system-config-*
>  on Fedora|Windows|* and just enter in a host and passkey|user+pass and
>  make changes to the target system 
Well, it needs some fixes in Windows upstream. Until it happens,
cygwin/X is comfortable enough.

>  > >           o allow for those who prefer not to run server
> tools with a X server installed to make use of the system-config tools
>  >
>  > None of the system-config-* tools depends on X server except for
>  > system-config-display.
>  
>  True, but you do generally need a GUI to make use of the GUI system-config tools 
Will the proposed changes make me use the tools without a graphical
interface? Is the proposal about providing a TUI for each tool?

-- 
Lubomir Kundrak (Red Hat Security Response Team)

[Harald Hoyer]

Arthur Pemberton wrote:
>  On Nov 19, 2007 7:07 AM, Lubomir Kundrak <lkundrak(a)redhat.com&gt;
> wrote:
> > Hi,
> >
> > On Mon, 2007-11-19 at 01:18 -0600, Arthur Pemberton wrote:
> >> I have expressed my ideas[1] to add and rework some of the
> >> functionality of the system-config tools with the hope of making them
> >> a bit more innovative and useful.
> >>
> >> Please comment on the idea.
> >> Rework (not a total rewrite) system-config tools use a common virtual console
> which abstracts away local and remote console usage. Anticipated benefits:
> >>
> >>     * transparently handle local or remote console (via ssh)
> >>           o allow configuration of remote services
> > this is possible now:
> > ssh -X my.server system-config-httpd
>  
>  One question: I know about this method, but have never tried it myself
>  - doesn't it require an xserver on the host?
>  
>  One comment: The crowd that really love the system-config tools would
>  like prefer not to be doing x forwarding via SSH
>  
>  
> >>           o possible allow for OS independent usage (example: system-config-httpd
> could be used from Windows XP)
> > You can do the very same thing from Windows XP.
>  
>  I was thinking more in terms of the user just running system-config-*
>  on Fedora|Windows|* and just enter in a host and passkey|user+pass and
>  make changes to the target system
>  
> >>           o allow for those who prefer not to run server tools with a X server
> installed to make use of the system-config tools
> > None of the system-config-* tools depends on X server except for
> > system-config-display.
>  
>  True, but you do generally need a GUI to make use of the GUI system-config tools 
not true.. GUI, TUI, CMD

/usr/sbin/system-config-network
/usr/sbin/system-config-network-cmd
/usr/sbin/system-config-network-tui