Brent Fox wrote:
On Wed, 2003-10-29 at 10:11, Will Backman wrote:
Some of the redhat-config-* tools have a tui version. Any rumors of a tui version of the user manager?
It's the first request I've had for a TUI for redhat-config-users, so I have no plans for this at the moment. I had always imagined that the command line tools were good enough for those who didn't use the GUI. Maybe you can explain what you'd like to see from a TUI that the command line tools don't provide?
I know that it's probably a pretty dramatic bit of recoding in most cases, but I'd like to see TUI versions for _all_ the redhat-config* stuff (shudder - sudden flashback to linuxconf). The issue is that I get used to the GUI stuff (read: crutch - I'll admit it) and, well, forget bits and pieces of the command line stuff at times. That, coupled with the fact that the GUI tools are doing multiple tasks in many cases (like the network and user tools) make it attractive to me. In a way it's your fault - you guys have made the GUI tools too nice :) But worth the effort? Well, that's up to you guys @ RH or one of the masses now on Fedora to decide.....
My $.02 Don
On Wed, 2003-10-29 at 15:30, Vanco, Don wrote:
The issue is that I get used to the GUI stuff (read: crutch - I'll admit it) and, well, forget bits and pieces of the command line stuff at times.
This just made me think of something. I don't know how many of you are familiar with AIX, but it has a very nice sysadmin tool called "SMIT" which is kinda-sorta like the redhat-config-* applications. One thing I always liked about SMIT was that if you needed it (or were just curious), you could ask it to display the equivalent command-line for whatever you'd just done through the GUI.
If I were to RFE this in Bugzilla, do you think it'd have a chance of ever being implemented in redhat-config-* ? I think it'd be especially helpful for budding sysadmins.
On Wed, 2003-10-29 at 15:01, Ben Steeves wrote:
On Wed, 2003-10-29 at 15:30, Vanco, Don wrote:
The issue is that I get used to the GUI stuff (read: crutch - I'll admit it) and, well, forget bits and pieces of the command line stuff at times.
This just made me think of something. I don't know how many of you are familiar with AIX, but it has a very nice sysadmin tool called "SMIT" which is kinda-sorta like the redhat-config-* applications. One thing I always liked about SMIT was that if you needed it (or were just curious), you could ask it to display the equivalent command-line for whatever you'd just done through the GUI.
If I were to RFE this in Bugzilla, do you think it'd have a chance of ever being implemented in redhat-config-* ? I think it'd be especially helpful for budding sysadmins.
Hmm...I don't know. It's not the sort of thing I'd like to expose non-sysadmin users to, but I can understand how it would be useful as a teaching tool. How did SMIT expose this option in the user interface?
Cheers, Brent
On Wed, 2003-10-29 at 16:12, Brent Fox wrote:
On Wed, 2003-10-29 at 15:01, Ben Steeves wrote:
you could ask it to display the equivalent command-line for whatever you'd just done through the GUI.
Hmm...I don't know. It's not the sort of thing I'd like to expose non-sysadmin users to, but I can understand how it would be useful as a teaching tool. How did SMIT expose this option in the user interface?
I normally used smitty (the TTY version of SMIT), in which it was mapped to a function key. In the graphical version, it was a button labelled "Command". The nearest equivalent keeping in-line with the UI of the redhat-config-* tools would probably be a window tab. Perhaps one that's only visible when running with root privileges, and/or toggled by a setting somewhere.
Mind you, SMIT's implementation wasn't perfect. Since the commands were built programmatically (SMIT is essentially a front end that runs the appropriate commands (or scripts)), they were sometimes less than optimal or needlessly pedantic (putting in parameters for flags that would be assumed as defaults, that sort of thing). Still, it was very reassuring (for a seasoned sysadmin because you knew exactly what was going on, and for a newbie because you could learn).
On Wed, Oct 29, 2003 at 04:26:27PM -0400, Ben Steeves wrote:
Mind you, SMIT's implementation wasn't perfect. Since the commands were built programmatically (SMIT is essentially a front end that runs the appropriate commands (or scripts)), they were sometimes less than optimal or needlessly pedantic (putting in parameters for flags that would be assumed as defaults, that sort of thing). Still, it was very reassuring (for a seasoned sysadmin because you knew exactly what was going on, and for a newbie because you could learn).
I think that the fact that SMIT had to do this was an indication that the whole configuration process was wrongheaded from the start in AIX. I have always felt that keeping a database and then overwriting a set of functionally write-only config files was the worst combination of possibilities available. (Yes, I was an AIX admin at one time, I'm not just spouting off.)
But then, I don't write config tools for Red Hat any more, that was my old job back when I re-wrote netconfig for the first time. :-)
michaelkjohnson
"He that composes himself is wiser than he that composes a book." Linux Application Development -- Ben Franklin http://people.redhat.com/johnsonm/lad/
On Wed, 2003-10-29 at 17:43, Michael K. Johnson wrote:
On Wed, Oct 29, 2003 at 04:26:27PM -0400, Ben Steeves wrote:
Mind you, SMIT's implementation wasn't perfect. Since the commands were built programmatically (SMIT is essentially a front end that runs the appropriate commands (or scripts)), they were sometimes less than optimal or needlessly pedantic (putting in parameters for flags that would be assumed as defaults, that sort of thing). Still, it was very reassuring (for a seasoned sysadmin because you knew exactly what was going on, and for a newbie because you could learn).
I think that the fact that SMIT had to do this was an indication that the whole configuration process was wrongheaded from the start in AIX.
I don't disagree with you :-) Nonetheless, the ability to "pull back the curtain" is one of the things that sets Linux apart from Those Other Operating Systems. I would never advocate mimicing anything about how SMIT or AIX configuration in general work, but for configuration, as any true Linux geek will tell you, nothing beats the command line. GUI tools are really convenient, but I know I always feel better when doing my thing I'm backstage :-)
(Yes, I was an AIX admin at one time, I'm not just spouting off.)
I feel your pain :-) Thankfully Linux saved us both :)
On Wed, Oct 29, 2003 at 08:26:13PM -0400, Ben Steeves wrote:
On Wed, 2003-10-29 at 17:43, Michael K. Johnson wrote:
On Wed, Oct 29, 2003 at 04:26:27PM -0400, Ben Steeves wrote:
Mind you, SMIT's implementation wasn't perfect. Since the commands were built programmatically (SMIT is essentially a front end that runs the appropriate commands (or scripts)), they were sometimes less than optimal or needlessly pedantic (putting in parameters for flags that would be assumed as defaults, that sort of thing). Still, it was very reassuring (for a seasoned sysadmin because you knew exactly what was going on, and for a newbie because you could learn).
I think that the fact that SMIT had to do this was an indication that the whole configuration process was wrongheaded from the start in AIX.
I don't disagree with you :-) Nonetheless, the ability to "pull back the curtain" is one of the things that sets Linux apart from Those Other Operating Systems.
Yeah, and the reason there was a curtain to begin with on AIX was their keeping all the configuration in a binary database and regenerating the config files blindly every time you sneezed.
With Linux, we can generally just not have that curtain to begin with, and with textual configuration files, often commented, often documented, and sometimes both, you do not have the formidable barrier to management that I recall on AIX...
I would never advocate mimicing anything about how SMIT or AIX configuration in general work, but for configuration, as any true Linux geek will tell you, nothing beats the command line. GUI tools are really convenient, but I know I always feel better when doing my thing I'm backstage :-)
Yeah, but a lot of what config tools do is modify config files rather than run SMIT-like touch-my-database-and-blindly-regenerate-my-config-files commands so it's apples and oranges.
(Yes, I was an AIX admin at one time, I'm not just spouting off.)
I feel your pain :-) Thankfully Linux saved us both :)
Heh. Well, I learned Linux before AIX (back in the days when we didn't have init, getty, or login...) but worked with all sorts of commercial Unix to pay the bills before Linux had significant commercial success.
michaelkjohnson
"He that composes himself is wiser than he that composes a book." Linux Application Development -- Ben Franklin http://people.redhat.com/johnsonm/lad/
On Wed, 29 Oct 2003, Michael K. Johnson wrote:
I think that the fact that SMIT had to do this was an indication that the whole configuration process was wrongheaded from the start in AIX. I have always felt that keeping a database and then overwriting a set of functionally write-only config files was the worst combination of possibilities available. (Yes, I was an AIX admin at one time, I'm not just spouting off.)
I'm curious about your take on redhat-config-printer, then ;-)
I'll agree AIX configuration sucks. One thing SMIT does which is nice, though. You can have it show command-lines which it is running behind the scenes. Some aspects of SMC (Sun's java admin crapplet) are the same way. That's a nice feature in GUI admin tools for newbies b/c it lets them slowly learn the right way to do something if they want to migrate to the command line.
later, chris
On Thu, Oct 30, 2003 at 02:34:14AM -0500, Chris Ricker wrote:
On Wed, 29 Oct 2003, Michael K. Johnson wrote:
I think that the fact that SMIT had to do this was an indication that the whole configuration process was wrongheaded from the start in AIX. I have always felt that keeping a database and then overwriting a set of functionally write-only config files was the worst combination of possibilities available. (Yes, I was an AIX admin at one time, I'm not just spouting off.)
I'm curious about your take on redhat-config-printer, then ;-)
As I said, I haven't been responsible for config tools at Red Hat for years. Yes, Crutcher and I had arguments about redhat-config-printer. :-)
However, there's one issue we had there that really overrides my arguments: until FC1, we were trying to support two very different print systems from one tool, including migrating configurations. So it's not necessarily the wrong decision in this particular case.
At least it doesn't regen the config files every time you sneeze, and you *can* choose to configure by hand if you like and not have your files overridden at all; that's a huge difference from SMIT.
I'll agree AIX configuration sucks. One thing SMIT does which is nice, though. You can have it show command-lines which it is running behind the scenes. Some aspects of SMC (Sun's java admin crapplet) are the same way. That's a nice feature in GUI admin tools for newbies b/c it lets them slowly learn the right way to do something if they want to migrate to the command line.
But so much is NOT "run this command" but instead "edit this configuration file"...
michaelkjohnson
"He that composes himself is wiser than he that composes a book." Linux Application Development -- Ben Franklin http://people.redhat.com/johnsonm/lad/
On Thu, Oct 30, 2003 at 10:12:45AM -0500, Michael K. Johnson wrote:
As I said, I haven't been responsible for config tools at Red Hat for years. Yes, Crutcher and I had arguments about redhat-config-printer. :-)
However, there's one issue we had there that really overrides my arguments: until FC1, we were trying to support two very different print systems from one tool, including migrating configurations. So it's not necessarily the wrong decision in this particular case.
At least it doesn't regen the config files every time you sneeze, and you *can* choose to configure by hand if you like and not have your files overridden at all; that's a huge difference from SMIT.
IMHO, redhat-config-printer should be replaced by a tool that just changes the CUPS configuration files when you want it to. The whole 'editing a look-aside configuration file and periodically writing out the real configuration files from it' thing was useful for LPRng->CUPS migration by chance alone: I still needed to write code to import queues from the configuration files because of the CUPS web interface.
The current situation just stifles its functionality. The new tool should look roughly the same of course, and be at least as scriptable as the current one (so that kudzu can add print queues).
With CUPS of course there really is the possibility of providing a list of command lines to run (lpadmin).
Tim. */
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Wed, Oct 29, 2003 at 04:01:03PM -0400, Ben Steeves wrote:
This just made me think of something. I don't know how many of you are familiar with AIX, but it has a very nice sysadmin tool called "SMIT" which is kinda-sorta like the redhat-config-* applications. One thing I always liked about SMIT was that if you needed it (or were just curious), you could ask it to display the equivalent command-line for whatever you'd just done through the GUI.
If I were to RFE this in Bugzilla, do you think it'd have a chance of ever being implemented in redhat-config-* ? I think it'd be especially helpful for budding sysadmins.
This RFE was submitted near the end of the limbo(?) beta cycle. It's still open, but there hasn't been a lot of action recently.
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=71647
- -- Matt Brodeur RHCE MBrodeur@NextTime.com http://www.NextTime.com
"Disbelief should be suspended, not hung by the neck until dead." -- Judith Merril
On Wed, 29 Oct 2003, Ben Steeves wrote:
On Wed, 2003-10-29 at 15:30, Vanco, Don wrote:
The issue is that I get used to the GUI stuff (read: crutch - I'll admit it) and, well, forget bits and pieces of the command line stuff at times.
This just made me think of something. I don't know how many of you are familiar with AIX, but it has a very nice sysadmin tool called "SMIT" which is kinda-sorta like the redhat-config-* applications. One thing I always liked about SMIT was that if you needed it (or were just curious), you could ask it to display the equivalent command-line for whatever you'd just done through the GUI.
My thought pre-dates yours by 14 months. :)
Add your comments here:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=71647
Dax Kelson Guru Labs
On Wed, 2003-10-29 at 14:30, Vanco, Don wrote:
I know that it's probably a pretty dramatic bit of recoding in most cases, but I'd like to see TUI versions for _all_ the redhat-config* stuff (shudder - sudden flashback to linuxconf).
It wouldn't be too bad from a coding perspective. Most of the tools that I've worked on have a relatively clean line between the backend that contains all the intelligence and a GUI front end. The idea was that we could write other kinds of interfaces in the future without rewriting the entire tool. We concentrated on GUIs for the most part because that's what we felt was needed by the widest audience. Now that we have a decent set of GUI tools, maybe we can come back and look at doing TUIs for some of the tools that don't have them.
I've been working on a TUI for firstboot for Fedora Core 2, so there will need to be a TUI to create users. I don't know about creating a TUI equivalent of all the things that redhat-config-users allows, but maybe there's a subset that would make sense to do.
Cheers, Brent
The issue is that I get used to the GUI stuff (read: crutch - I'll admit it) and, well, forget bits and pieces of the command line stuff at times. That, coupled with the fact that the GUI tools are doing multiple tasks in many cases (like the network and user tools) make it attractive to me. In a way it's your fault - you guys have made the GUI tools too nice :) But worth the effort? Well, that's up to you guys @ RH or one of the masses now on Fedora to decide.....
My $.02 Don
-- fedora-test-list mailing list fedora-test-list@redhat.com http://www.redhat.com/mailman/listinfo/fedora-test-list
On Wed, Oct 29, 2003 at 03:08:58PM -0500, Brent Fox wrote:
It wouldn't be too bad from a coding perspective. Most of the tools that I've worked on have a relatively clean line between the backend that contains all the intelligence and a GUI front end. The idea was that we could write other kinds of interfaces in the future without rewriting the entire tool. We concentrated on GUIs for the most part because that's what we felt was needed by the widest audience. Now that we have a decent set of GUI tools, maybe we can come back and look at doing TUIs for some of the tools that don't have them.
It would be great to formalize the interface between front-end and back-end, so that everything that is done could be captured in a script log. Doing this can be orthogonal to "transactions"; the point being that it should be to copy the script to restore the filesystem (/etc, in particular) to its previous state, and run a script with something like
#!/usr/sbin/redhat-config-foo -f <script-log contents> ...
and achieve the same result. With some light editing/parameterization, I could then do the same thing across a network of machines. I could also check the log contents into a revision control system, along with /etc. Getting the tools to use "arch" for revision control would also be a win. :-)
Regards,
Bill Rugolsky