Linux installation: Second Ethernet interface ...

[John Chambers]

| From: Jerry Feldman <gaf at mediaone.NET>
| On 28 Jun 98, at 16:26, Mike Bilow <mikebw at bilow.bilow.uu.ids.net> wrote:
| > Interesting.  I guess Red Hat has changed a few things since I last tried
| > it. I am not sure how much I would trust GUI network configuration,
| > especially since all it would do is write text configuration files.  I
| > remember the tool for this on SCO, and I used to give up fairly quickly
| > and just edit the text files to get the job done faster.  The problem is
| > usually that the GUI tool has to be able to read the text configuration
| > files to determine the currently configured state, and it only understands
| > so much.
|
| The world is changing to GUI. Fortunately, everything in Unix can be done by 
| editing configuration files with emacs or vi.

In a sense, this has always been true.  I recall  'way  back  in  the
early  days  of  Unix,  one of the frequent explanations of its rapid
spread (despite having no commercial support)  was:   All  the  other
systems  at the time had a lot of packages, each of which had its own
complex config program, usually using the closest thing to a  GUI  at
the  time:   full-screen  ascii or ebcdic screens.  The actual config
files were universally binary "for efficiency", so you couldn't  edit
them.  You just had to learn a new config tool for every new package.
Then along came Unix, with the radical idea that all the config files
would  be plain text.  To configure things, all you had to master was
one editor. It made life much easier, and you could run these systems
without  having  full-time  staff  experts  in all the complex config
tools.

The popularity of GUIs today is just another form of the same  thing.
And it has exactly the same problem as this approach always has.  But
it looks flashier, and impresses people who  don't  have  to  use  it
much.

In recent years, I've read a number  of  articles  that  suggest  you
watch  the  behavior  of  people  whose  job  it  is to keep networks
running. They'll all show you these flashy, GUI-based tools that look
pretty.   But  when  something  goes  wrong,  what they usually do is
immediately open up a  command  window  and  start  typing.   They've
learned  from  experience  that  all the fancy GUI network management
packages are good at is impressing management.  But if  you  want  to
actually  find  out  what's  wrong  and  fix  it,  you want a command
interface.

There does seem to be a move afoot to add lots of fancy GUI tools  to
linux.   It's probably a good idea to have them if you are faced with
impressing management.  If you want signoffs on linux vs NT, you need
pretty  pictures.   Unfortunately,  there  are also a lot of FAQs and
HOWTOs that suggest using the GUI tools,  too,  and  don't  tell  you
what's going on behind the scene.

My immediate problem can perhaps be summarized:  Redhat 5.1 has  this
fancy  Network  Configurator  that  claims  to  be  creating  an eth1
interface. But eth1 never appears. Why not?  The GUI tool thinks that
all's  fine  and  eth1 is active.  Time to revert to the command line
approach, I guess.  I wonder if someone has  documented  just  how  a
linux network interface comes into existence? I don't seem to find it
in the HOWTOs, which tell me that the GUI tool will take care of  it.
There's  probably  some  little  config  file  somewhere that needs a
trivial change.  I wonder what it is?

--
When puns are outlawed, only outlaws will be punished.