Commentary on the seven words

Fri Aug 25 21:59:08 UTC 2006

This list routinely is asked to help with redhat-8 and 9. It is also
routinely asked to help with enabling rsh and telnet. (Now if a person
tells me that "this is just testing", my head says "testing is done
before production"). So if someone is asking me "hey, um, I need to
get downstairs from this 10 story building, which window would be best
to jump out of?", guess what. I will show them the stairs AND the
elevator and keep them away from the windows.

Sorry.

Regards,
Gregory Golin
Systems Administrator

On 8/25/06, Burke, Thomas G. <tg.burke at ngc.com> wrote:
> And this would have been a good way to preface a message on how to turn
> on root access to telnet.
>
> Shoot, I use SSH & all that, but if I wanted to allow it for some
> reason, I'd ask (especially since I've been using ssh so long I don't
> remember how) - but I can think of reasons why I'd maybe want to do this
> - but only from within a firewalled area, or something completely
> disconnected from the outside world.
>
> -----Original Message-----
> From: redhat-list-bounces at redhat.com
> [mailto:redhat-list-bounces at redhat.com] On Behalf Of Bliss, Aaron
> Sent: Friday, August 25, 2006 2:27 PM
> To: Marc Wiatrowski; General Red Hat Linux discussion list
> Subject: RE: Commentary on the seven words
>
> Didn't mean to step on anyone's toes; I was just trying to help; I'm
> sure some people will disagree, but it's generally a better security
> practice not to use clear text protocols such as telnet or ftp whenever
> possible, which why I recommend sftp and ssh...
>
> -----Original Message-----
> From: redhat-list-bounces at redhat.com
> [mailto:redhat-list-bounces at redhat.com] On Behalf Of Marc Wiatrowski
> Sent: Friday, August 25, 2006 2:23 PM
> To: 'General Red Hat Linux discussion list'
> Subject: RE: Commentary on the seven words
>
> When someone going down a dead end road stops and asks for directions,
> do you explain the correct route or help him make a new road the way he
> is headed?
>
> marc
>
> > -----Original Message-----
> > From: darrel barton
> > Sent: Friday, August 25, 2006 2:11 PM
> > To: redhat-list at redhat.com
> > Subject: Commentary on the seven words
> >
> >
> > As a programmer, I routinely turn to guru's for support -- especially
> > for operating system and utility advice and assistance and there are
> > SEVEN words -- seven very unwelcome words that I hear from time to
> > time that
> > drive me up the wall.   Not George Carlin's 7 words but another set:
> >
> > Why Do You Want To Do That?
> >
> > I don't want to seem like I'm attacking anyone here, because I know
> > that almost everyone means well and help, whether it's what we intend
> > or not --
> > is still help.  But there is a danger too.   When someone
> > writes to say
> >
> > 200 PORT command successful. Consider using PASV. Hangs.
> >
> > and the response he gets is "try sftp" there seem to be a hugely
> > missing
> > ingredient:   All we did was give the man a work around to a
> > problem.  Even
> > if there are 400 alternatives ... FTP is SUPPOSED to work and someone
> > should CARE that it doesn't.   Well, sftp helped him and he's
> > on his way
> > and that's great.   The only problem is that, in this case,
> > 'sftp' was
> > merely a workaround to a problem and if people aren't careful, Linux
> > will become wat the original AT&T Unix was -- and that is to say
> > nothing more that a PILE of workarounds.
> >
> > I wrote in with a complaint that Linux will allow a process (like Tar,
>
> > Cpio, DD, etc) to create archives larger than that same system can
> > read
> > back.   Think of it as that elusive Write Only Memory we're all heard
> > about.   Several people contacted me and told me all about
> > Gzip and how to
> > make the archive smaller and other people said it wasn't Linux' fault
> > it
> > was the file's fault and etc., etc., and etc.   I wonder if
> > these same
> > people would be so forgiving of a workaround if the problem was that
> > Linux would allow a process to write to disc blocks in excess of the
> > number of physical blocks without reporting errors?
> >
> > There is a guy that wants to be able to log in to ROOT via Telnet and
> > people write back telling him that he doesn't want to even do
> > that.   Well
> > guess what?   I administrate one system that has 128 clients
> > on it and it's
> > NOT EVEN CONNECTED TO THE INTERNET.   Or .. Intranet.   One
> > server, 128
> > thin clients.   Why can't I log on to Root from one of those
> > clients if I
> > want to without the 262 additional levels of complication that ssh
> > provides?   (OK -- I know that YOU have never ever EVER had a
> > problem with
> > ssh.  Nor anyone you've ever known.  And every ssh client you have
> > ever seen works seamlessly with every ssh server that's ever been
> > written .. but trust me, out there ... once ... back in 1986 .. there
> > WAS a guy who had ssh problems.
> >
> > So when a guy writes to ask about how to enable root login from
> > telnet, can't someone just say "I hope you know that's not as secure
> > as ssh -- but here's how you enable that ...... ?
> >
> > Please just remember that some of us here have been slogging through
> > this stuff for the last 20 years, trying to get an application to run,
>
> > a documented operating system function to actually function -- and
> > occasionally get enough things working that a client actually PAYS
> > us.   We're not always here to hear about the way we coulda, shoulda,
> > woulda restructured the whole process around stuff that some of you
> > guys only invented last week, ok?
> >
> > "Why Do You Want To Do That?"
> >
> > Would be a more fair question if someone needed that answer in order
> > to better understand the request -- but far too often it's not that --
>
> > it's the beginning of someone telling me how THEY think I should be
> > doing my job.
> >
> > So please, folks, the next time we want to do something differently
> > that you think you'd do it if you were in our shoes ... cut us some
> > slack and just help us out, OK?  We'd do the same for you.
> >
> >
> >
> >
> >
> >
> >
> >
> >
>
>
> --
> redhat-list mailing list
> unsubscribe mailto:redhat-list-request at redhat.com?subject=unsubscribe
> https://www.redhat.com/mailman/listinfo/redhat-list
>
>
>
> Confidentiality Notice:
> The information contained in this electronic message is intended for the
> exclusive use of the individual or entity named above and may contain
> privileged or confidential information.  If the reader of this message
> is not the intended recipient or the employee or agent responsible to
> deliver it to the intended recipient, you are hereby notified that
> dissemination, distribution or copying of this information is
> prohibited.  If you have received this communication in error, please
> notify the sender immediately by telephone and destroy the copies you
> received.
>
>
> --
> redhat-list mailing list
> unsubscribe mailto:redhat-list-request at redhat.com?subject=unsubscribe
> https://www.redhat.com/mailman/listinfo/redhat-list
>
> --
> redhat-list mailing list
> unsubscribe mailto:redhat-list-request at redhat.com?subject=unsubscribe
> https://www.redhat.com/mailman/listinfo/redhat-list
>