[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: and yet another zdnet "article" re: Lnx



>>Not neccesarily true.  98.44% of people can get the sendmail
>>functionality they want by spending 15 seconds in Linuxconf.  Are you
>>saying sendmail is simple? :)
>Sendmail is most definitely not simple.  It has features I will most likely
>never use in my lifetime.  Do I need to know every little detail about how to
>configure.  NO.  Is it immoral to use Linuxconf to get the functionality I
>need.  NO.  But, what if I need the results of linuxconf where I can not use
>it.

The "correct" way to configure sendmail is to generate the file via M4
scripts (described in my Sendmail presentation) but this is certainly not
simple (but easier than editing sendmail.cf).  But it does avoid loosing
configuration parameters between  version upgrades.

>>How about looking in /proc?  Or running strace, fuser, or lsof?
>>>editing when they do it.  A big difference to me between Linux and MS is that
>>>windows is a mystery, Linux is an open book.  I'd like the new people trying to
>>>use Linux see the book through gui.  Lets say I'm in Linuxconf and I just
>>>changed something in sendmail.  I would really like it if it told me what file
>>>it changed what the original file was renamed to and give me the option to see a
>>>result of a diff command between the two.  They also could have more
>>>explanations.  Assume you don't understand something, url to an explanation on
>>>the web somewhere.  I know what your thinking, Join the linuxconf team then.  OK
>>>I'm a hypocrite.
>> But Linuxconf does exactly this:  Just pick View Changes.
>>> Everything is clear if known.
>Once again I will say everything is clear if known.
>So I'll try it again.  What I wanted to do was administer a machine via a slow
>dialup connection.  I wanted to change the ip addresses that sendmail would
>accept mail from on the remote machine.  It is "easy" (interpret known) to do
>this using linuxconf.  Linuxconf was not installed on the remote machine or I
>couldn't run an X client through the slow connection.  (of course now I know
>that you can run linuxconf --text) I could however run linuxconf on a local
>machine and try to see what config files it was changing.
>tripwire filesystem check.  But I'll try it your way now just to see.  Looking
>for "View Changes" in linuxconf was to no avail.  Maybe I am running a different
>version, but I could find no option.  I tried both the text and the X linuxconf
>program looking for "view changes" and failed.

What version are you running?

I have 1.25r7.  I pick Updates->Log Window and it lists files modified as
it updates them.

>Now the strace option.  I ran linuxconf (gui) like so
>strace linuxconf > file 2>&1
>then I assumed the file that would be edited would be a sub somewhere of etc and
>that a system call of write would be performed.
>cat file | grep write | less
>then search (using / search command in less) the file for etc and low and behold
>I could have found the answer this way.  /etc/mail/ip_allow was indeed edited.
>Looking at a M$ administrator coming into this environment I can understand
>their frustration from a personal experience as well as a philosophical stand
>point.  Lets look at what needed to be easy (interpret known).

I could counter with the point that you can't run NT/Exchange without a
GUI.  And how about ANY command line administration over a low-speed
connection? But that is really ducking the issue, and not answering the
challenge.


The strace method is indeed "too hard".

>1 What strace is.
>2 How to use the bash shell to redirect the output both standard and error to a
>file.

Isn't this the same as in the Windows shell?

>3 That the file edited would be a sub of etc (an assumption, SWAG if you will)

Knowledge of the FSSTD, this counts as at least one.  One also need to
know how to restart sendmail,  which included knowledge of init scripts.

>4 cat and less and grep (do I count this as three things)

Yes that is three things (at least).

>5 how to search for the string "etc" in vi or less

Other editors are much more user friendly.

>That's alot from point and click to this I'd say.  I'm not complaining.  I can
>appreciate the elegance of this kind of method.  The use of multiple tools to
>chisel away at a problem has a very strong appeal.  It's still a mile away from
>point and click.  At least the problem was solveable without rebooting or
>reinstalling.

It is hard to have point-n-click without a GUI.  One might install iXvnc
and use Tridia VNC for a nice compressesed X session if GUI tools are
imperitive.  The RedHat VNC packages available from Red Carpet can do
this,  I don't know if they come with RH itself.

>So there is more than one way to skin a cat if I had not been brain cramping at
>the moment.  I could have made the change to some searchable ip address like
>193.123.75. and then executed
>grep -r '193\.123\.75\.' /etc
>but brain cramps do occur.

Or in my case, frequent paralysis.

>Running tripwire just sort of happend because It
>runs every night on that machine and I gave up on that after a half an hour or
>so.  Then I got the mail from tripwire and it just sort of clicked.
>OK so what is the point here.  Umm.  Oh yes I remember, an administrator going
>from windows to linux.  Are the gui's a help or a hinderance.  I still want to
>see linuxconf tell me what was changed.  Right now it just tells me what
>services it will restart.  I don't see why every time I changed the ip_allow it
>tells me I need to restart lpd and xfs.

lpd and xfs?  That doesn't make any sense.

-- 
-----------------------------------------------------------
Ximian GNOME, Evolution, LTSP, and RedHat Linux + LVM & XFS
-----------------------------------------------------------