Re: telnet logins
From: Randy (yates_at_ieee.org)
Date: 01/12/05
- Next message: Randy: "Re: telnet logins"
- Previous message: Vlad Grama: "Re: Good ideas what Sun could do but won't be done until h*ll freezes / was: Re: How to make a file immutable in Solaris?"
- In reply to: Boyd Adamson: "Re: telnet logins"
- Next in thread: Darren Dunham: "Re: telnet logins"
- Reply: Darren Dunham: "Re: telnet logins"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: 12 Jan 2005 06:07:05 -0800
> "Randy" <y...@ieee.org> writes:
>
> >> Randy <y...@ieee.org> wrote:
> >> > Is it conventional to exclude the x-client directory (on my
system
> >> > its /usr/openwin/bin) from the path when logging in over a
telnet
> >> > session?
> >>
> >> *exclude*, no. However it's pretty common to not have it in the
> >> default path, but add it when logging in via a graphical
interface,
> >> or when starting X windows.
> >
> > Semantics. Are we "excluding" or "choosing not to add"?
>
> It may be semantics, but it accurately describes what happens.
I presume you mean that in the system login scripts the path is never
modified by subtraction, i.e., by forming a path and then taking away
components. Rather, it is built by choosing what to add by
accretion. Is this correct?
> >> > The problem I'm having is that I often like to telnet into my
unix
> >> > account from my pc in order to start up an x-client, usually an
> >> > xterm. However, on our system the xclient directory is not
> >> > concatenated to the path when the source of login is via telnet.
> >>
> >> But with telnet, you don't have any display.
> >
> > Wrong. I have an x-display server running on my pc.
> >
> >> So you're already having to set up your DISPLAY variable.
> >
> > You mean interactively? Maybe. Then again maybe I've created a
login
> > script segment that automatically extracts it from my session info
and
> > assigns DISPLAY.
>
> The telnet protocol allows clients to send environment variable
settings
> to the server. Many clients use this to send the DISPLAY variable. I
> can't remember if Solaris' is one of them, since it's so long since I
> used telnet.
I don't know either.
> >> If you can do that, you can add the path to the X clients, right?
> >
> > I can rewrite the solaris operating system instead of using what's
> > already available too. Does that mean I should do it?
>
> Changing your PATH in a login file is a standard configuration
> operation. If I responded like that to you telling me how to change
the
> desktop colour on my Windows machine it would be just as
inappropriate a
> response.
>
> "Right click?? Dialog box?? Why don't I just re-write the OS!"
Your judgements are in error, in my opinion.
This is a matter of structure. We don't duplicate modules in software
for some very good reasons. Similarly it doesn't make sense to ask
users to make changes to their path for common usage options. One of
the reasons we don't is that it becomes a maintenance problem. Another
reason is that it is common sense: Why ask N users to make changes to
their path when 1 sysadmin can do it in the system login script?
Even if this is a simple one-line change to the user's login script,
this logic still holds. To argue otherwise is to invite chaos.
> > Consider the following scenarios:
> >
> > 1. I'm at home on the pc. I remotely telnet (or ssh - I get the
same
> > problem in having an incomplete path either way) to my machine at
> > work so that I don't have any other access to my unix machine. Now
> > I want to start an xterm. Where were those darned binaries? Let's
> > see - /home/... - no. /apps/... - no. /usr/bin - no. /usr/X - no.
> > etc., etc., etc.
>
> So put the directories in your PATH when you know where they are,
then
> you don't _have_ to remember.
See reasons why this is not a good idea above.
> > 2. I memorized my x-client path to be /abc/xyz. The sysadmin
changes
> > things and doesn't bother to tell me (nor should he/she need to).
> > Next time I login it's not where I expected it. Goto scenario 1.
>
> Firstly, I'd be surprised if your admin moved xterm somewhere
> else. Secondly, if the admin is moving programs that users are using
> from place to place then they should indeed be either:
> - notifying users, or
> - putting symlinks in place, or
> - updating the system default path to reflect the new location.
> Probably all three.
Why is this preferable to simply establishing the paths in the login
scripts? That way these band-aids aren't required.
> >> If you use ssh with X forwarding, not only do you prevent clear
text
> >> over the wire, you automatically set up (an encrypted) DISPLAY and
a
> >> proper PATH.
> >>
> >> > If this startup behavior for telnet logins is conventional, then
> >> > how do folks typically start xclients on a remote machine? It
seems
> >> > unreasonable to require people to know where these applications
are
> >> > kept (i.e., in order to specify a fully-qualified path to the
> >> > x-clients).
> >>
> >> So change your default PATH.
> >
> > That's a hack. See scenario 2 above. The proper thing to do is
> > set it up in the system login files, is it not? If not, why not?
>
> There is an argument that says that on a text login, like telnet, the
> path shouldn't include directories that are only useful with an X
> server.
Why does a telnet login imply there is no X server associated with the
agent logging in?
> I'm not saying it's right, but it is the default on Solaris.
If it isn't right, then let's stop doing it.
> It's not a hack. It's normal.
It may be normal, but it's still a hack if it doesn't make sense.
--RY
- Next message: Randy: "Re: telnet logins"
- Previous message: Vlad Grama: "Re: Good ideas what Sun could do but won't be done until h*ll freezes / was: Re: How to make a file immutable in Solaris?"
- In reply to: Boyd Adamson: "Re: telnet logins"
- Next in thread: Darren Dunham: "Re: telnet logins"
- Reply: Darren Dunham: "Re: telnet logins"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
