This item is for system announcements (new computer equipment on Grex, 
system upgrades, Grex meetings, etc.).  Personal announcements should go 
back in item 2; Grex system *problems* belong in the next item (#4). 

68 responses total.

Right.

Didn't it say you belonged in the *next* item?

Your mom belongs in the next compartment.

Nominations are now open for December's Grex Board of Directors
election.  See Item 25 in the Coop conference (item:coop,25) for
details and to make nominations.

Thanks remmers.

When I use PuTTY to ssh to Grex, I do not see the "last login/failed
attempts", the "password will expire in X days" or the "you have new/unread/no
mail" announcements.  

Why don't those announcements show up?  Can I make ssh show them to me?

ditto

Me too.  I assumed this was a difference between how ssh and telnet requests
get handled by Grex.  I too would like to know how to get those messages via
ssh.

It's a long-standing problem with ssh.  There are two possible fixes
that I can think of:  (1) modify the ssh source code (not a pretty
prospect), or (2) a workaround:  Somebody writes a program to display the
missing information, and ssh users invoke that program from their .login
or .profile files.

Can the default .login and .profile be modified to include something 
along the lines of:

if ssh then echo messages

Possibly.  I imagine that the user's connection method is known to
the system by the time the user's startup files are processed.

This response has been erased.

And what are those environment variables?

This response has been erased.

A bigger problem is that if your password expires, ssh will not let you
in.  You have to telnet in to set the password, which means the new
password gets sent in cleartext across the network.

This response has been erased.

This response has been erased.

This response has been erased.

This response has been erased.

After we get to the openBSD machine, why don't we scrap the
password expiration system altogether?

Here on Grex, when connected via ssh, I have SSH_CLIENT and SSH_TTY
environment variables set.

This response has been erased.

the problem with sshd is that it believes it knows how to process a
login.  the authors found that not all systems would even allow sshd to
do what it tries to do, so the arrogant fools were forced into providing
a method whereby the system login program can be invoked -- this via
`uselogin yes'.

Though you have to be careful.  A fair fraction of the security holes in
ssh were related to the use of "uselogin yes".

This response has been erased.

As I'm not all that knowledgable about the fine points of ssh,
please explain what "uselogin yes" is.  Am I reading correctly
that it's a configuration option that, among other things, would
cause the same info to be displayed to the user on login that 
would be displayed with a telnet login?

This response has been erased.

But does this have the effect I asked about?

This response has been erased.

        I thought grex had more lines?  What is with the busy signals
on -3000?
        Where was the announcement here about the dial-in lines
being disconnected?
        Does any staff care anymore about the trunk hunt not working?
Again, an item 3 or 4 response would be nice if it is the process 
of being fixed.

The dial-in cancellation was mentioned in the coop conference.  I have not
had any problems but I dial 5041.

Sorry, TIm, you're right - I should have posted here.  We are now down to 4
dialin lines: 761-3000, 5041, 3411, and 3451.  Are you saying that the trunk
hunt isn't working at all, or just that all four lines were busy when you
tried to call?

BTW, we should figure out which modems are no longer connected and unplug
them.

I called Ameritech this morning to get them to fix the hunting on our lines.
(I was afraid that if I called on the weekend, I'd get someone who would
make the problem worse.)  I spoke with a gentleman named Jim, who checked
and found that all our numbers *except* 761-3000 had been programmed to
hunt.  He sent a request down to the programming department to fix things,
and they should be better in a few hours.  Please post here or send me mail
if there continue to be problems.

        Thank you for attention in getting this fixed.
I just dialed into -3000, any easy way to find if I did hunt down?

        I am currently on ttytf, but that might tell us if we hunted down
from -3000

who | grep 216.93.104.37
will give a list of people currently dialed in, and from there you can guess
whether you successfully trunk-hunted.

Or you can dial 761-3000 with one phone, and dial it again with another.

All my items are almost new again - they start at response 6, for instance,
instead of 38.  I am typing in 38 to go to the end.  What might have caused
this?

- Backtalk version 1.3.30 - Copyright 1996-2006, Jan Wolter and Steve Weiss