> 
> Now that I've got it so my machine can be telnet'd to I decided to get it
> up and running and leave it online so I could work on it from work today.
> I (being the curious type) decided to run dt.  This was a big big big big
> big (I think you get my drift) mistake.  Here's what happened and some
> explanation as to why I think it happened.  I have only a 14.4 bps modem so
> the connection is slow.  For somereason it either lagged out so bad loading
> dt or dt just doesn't work from telneting that I lost my telnet session.
> When I tenet'd back in though I noticed that dt was still running... so I
> think I made another big big (ok I'm not going to do this again) mistake
> (hey that's part of learning making mistakes) I killed dt not realizing
> that killing dt would leave its children processes running.  When I did
> this it behaved like any good process and died, but when I did a w it still
> showed up 2 of the dt terminals as being dt-1.0.3:2 and dt-1.0.3:3, but
> neither of these showed up as processes.  This continued to be the case
> until I got home and was able to reboot the machine.  I have several
> questions that have spawned because of this.
> 
> 1) Is it possible to telnet in and use dt on a faster connection or does dt
> not like telnet?

dt does not like telnet. It talks directly to the video and the keyboard,
which doesn't work over a telnet session (plus you didn't telnet in from
a mac running NetBSD as you'd have run dt there).

> 2) When I was doing this it was suggested to logout and log back in as root
> only to kill off all of my processes being run under my username to take
> care of this.  However whenever I tried to telnet in as root it said
> something to the lines that it was prohibited on the terminal I was on.  Is
> there anyway to fix this and why does it do this?

It does this as logging in as root over the net IS VERY VERY BAD.
Passwords go over the net as clear text. So anyone with an ethernet
card in "promiscuous" mode can watch ALL the trafic and steal your
password. It's a favorite cracker trick. Plus if you log in as root,
there's no log of who you are. If you log in as you and the su to root,
there's a log entry.

There are (at least) two ways to do better about trans-net security:
ssh and kerberos. Kerberos is a whole security suite, and is good
for centralized setups like computing clusters or universities. ssh
is a shell, a login daemon, and a file-copy command.

Kerberos re-wrote a lot of UN*X commands and made the work with a
trusted server model. To start, you validate yourself to the server
(the command asks for a response which is encrypted by your password.
If it decrypts right, you typed the right password). Then you get
tickets you can use to talk to other servers (like computers to which
you want to log in). It's kinda like a drivers licence. Many businesses
trust the DMV. Likewise the other servers trust the authorization
server.

ssh took a different approach. It trusts no one. It uses public-key
encryption. There are a lot of ways of using it, but the one I use is:
to start, you generate an identity. There's a publick key with this
identity. You then get the identity into the authorized_hosts file for
the account to which you want to ssh. Then you ssh there. The sshd
decides to give you a try, and starts talking to you in packets
encrypted with your public key. If you're not you, it's useless.

Which is better? Both. They each have advantages. Kerberos scales better,
whereas ssh requires less administrative overhead. I use both.

> 3) When I rebooted my mac in NetBSD I did so in single-user mode and ran
> fsck and everything checked out ok.  Is there anything that I did through
> this fun experimenting that could have damaged anything?

Probably not, assuming you shutdown cleanly.

> I believe that's it but I'm sure I'll come up with more.  Oh by the way
> when I got home and logged in only with root there were no processes
> running under the username so I needed to reboot in order to kill the
> process because as far as I know there's no way of killing processes that
> don't show up under a ful list of ps -aux and I even tried to kill -9 dt
> and it said no job existing like that.

I think you just learned about utmp garbage. When you type "w", it looks in
/var/run/utmp to see who's there. It does NOT look at running processies.

When you fired up utmp, the shells lived long enough to insert
themselves into utmp, but died before they could remove themselves.

I gather rebooting clears utmp.

If you don't see a process with ps aux, then either you've been cracked
(broken into, not likely here) or it doesn't exist.

Take care,

Bill