Remote administration

Remote administration

Post by Renato Weine » Fri, 27 Mar 1998 04:00:00



Hi All,

Anyone has tips/links about remote administration in Linux ?? I mean not
only
telnet to the Linux box, but some other tool. Also, general tips/links of
how to
reboot the server and make sure that it comes back alive....

I will really appreciate any help.
Thanks
Renato, Brazil.

 
 
 

Remote administration

Post by Rick W. Purdo » Fri, 27 Mar 1998 04:00:00



> Hi All,

> Anyone has tips/links about remote administration in Linux ?? I mean not
> only
> telnet to the Linux box, but some other tool. Also, general tips/links of
> how to
> reboot the server and make sure that it comes back alive....

> I will really appreciate any help.
> Thanks
> Renato, Brazil.

   There is a very good tool called webmin which I use to admin my
linux boxes over an intranet/www connect.

 
 
 

Remote administration

Post by Roy Stogn » Fri, 27 Mar 1998 04:00:00



Quote:>Anyone has tips/links about remote administration in Linux ?? I mean
>not only telnet to the Linux box, but some other tool. Also, general
>tips/links of how to reboot the server and make sure that it comes
>back alive....

You can run X apps over the network, so if you have a speedy
connection that becomes an option - between that and telnet, you have
the ability to run basically any app over the network.  What more do
you want?

If you're adminning a large group of Linux boxes, look into Simple
Network Management Protocol - SNMP.
---
Roy Stogner

 
 
 

Remote administration

Post by Barry O'Nei » Sat, 28 Mar 1998 04:00:00



says...

Quote:> Hi All,

> Anyone has tips/links about remote administration in Linux ?? I mean not
> only
> telnet to the Linux box, but some other tool. Also, general tips/links of
> how to
> reboot the server and make sure that it comes back alive....

Go to: http://www.xnet.com/~blatura/linapps.shtml

Look for a util called Webmin.  Remote admin via your web browser.

regards,

Barry
--
"Humour is *such* a subjective thing, don't you think Mollari?" - Emperor
Cartagia, Babylon 5

 
 
 

Remote administration

Post by Andrzej Fili » Sat, 28 Mar 1998 04:00:00



> Anyone has tips/links about remote administration in Linux ?? I mean not
> only telnet to the Linux box, but some other tool.

Use shh with X proxy.
You will have telnet+XWindows access over ENCRYPTED tcp connection.
 
 
 

Remote administration

Post by Bill Stege » Sat, 28 Mar 1998 04:00:00




>> Anyone has tips/links about remote administration in Linux ?? I mean not
>> only telnet to the Linux box, but some other tool.

>Use shh with X proxy.
>You will have telnet+XWindows access over ENCRYPTED tcp connection.

Of course a 28k8 modem connection will not quite be up to the traffic this
will generate. Better get a T1/E1 instead if you can.

--

PGP-key available at a public key server near you      Powered by Linux 2.0

 
 
 

Remote administration

Post by Jason Ear » Sat, 28 Mar 1998 04:00:00





> >> Anyone has tips/links about remote administration in Linux ?? I mean not
> >> only telnet to the Linux box, but some other tool.

> >Use shh with X proxy.
> >You will have telnet+XWindows access over ENCRYPTED tcp connection.

> Of course a 28k8 modem connection will not quite be up to the traffic this
> will generate. Better get a T1/E1 instead if you can.

X, we don't need no stinking X.  Linux is ideal for remote
administration because you don't need more than a 14.4 modem for
remote administration.  I have a fax server that I dial into all the
time on a 14.4 connection, and this is just fine for a text only
terminal connection.  Better yet, you can do everything that you need
to this way.

Now, X is very spiffy, don't get me wrong, there is nothing like a
network aware GUI interface for making Wintel and Mac users stand
there like stunned fish, but you can do everything you need to do from
the command line with a 14.4 connection.

 
 
 

Remote administration

Post by Eric Lee Gre » Sun, 29 Mar 1998 04:00:00



Quote:>Anyone has tips/links about remote administration in Linux ?? I mean not
>only
>telnet to the Linux box, but some other tool. Also, general tips/links of

Some nice tools, either supplied with Red Hat Linux or freely available
elsewhere:

NIS/NIS+/NYS: maintain a central password file for all of the Linux machines
on your LAN. Does not work very well on a WAN, alas.

NFS: The Computer Is The Network. Put your home directory and work
directories on the network using NFS, use NIS to distribute the
password data to the workstations, then your users can walk to any
workstation and log in. If a workstation goes down, just plug another
pre-configured workstation in its place and not a single byte of data
has been lost (except maybe any clutter left around in /tmp).  The
only problem at the moment: NFS-mounting your EMAIL data doesn't work
at the moment because the Linux NFS server and client do not properly
implement locking. Using a dedicated EMAIL server and a POP/IMAP-aware
EMAIL client is probably the best work-around for now.

rdist: distribute software updates etc. to all the machines on your LAN/WAN
in a semi-automated fashion. Note that rdist requires a bit of a security
breach on the remote machines.

Python/FTP: I wrote a swift script in Python which uses the built-in
Python FTP library to do software updates using plain old "ftp". That
way at least I have to provide a user name and password, rather than
having the system be wide open the way it is with 'rdist'. Once the
update tarball is ftp'ed over to the correct directory, then a "site
exec unpacker <update-tarball-name>" command is sent to the ftp
server, which then calls the unpacker (a su'ed wrapper which does some
security checking to make sure it's not a tarball from Jack The
Ripper, then unpacks the tarball and optionally executes some
initialization/installation scripts included in the tarball). Note
that there's a good reason I didn't use rpm -- I originally wrote the
unpacker under SCO Unix prior to discovering Linux in order to unpack
updates sent via UUCP (via uux actually, for those of you with long
memories... had to add the unpacker to the HoneyDamber Permissions
list of every *y machine we had in the field, but boy, was it
worth it).

ssh: you can do encrypted rdist-like stuff with ssh, without the
security problems of rdist (rdist requires that the "master" machine
be in each "slave"'s host.equiv file -- a security problem on an open
Intranet). see http://www.veryComputer.com/ for a Red Hat .rpm file, Debian
.deb file, and for precompiled binaries for other Linuxes.

pgp is nice if you get confused by ssh. Being able to "sign" your
messages (or your tarball, in my case) is often critical to your
security when you're otherwise wide-open.

Kerberos is most often used as an authentification method, but you can
also specify that you want your rlogin, rsh and rcp connections to be
encrypted.  The nice thing about Kerberos is that once you check out
your ticket, then rsh and rcp work the same way as in un-authenticated
"straight" BSD Unix, meaning you don't have to totally re-write your
scripts to use some other command (you'll want to give their rsh and
rcp the encryption arguments, of course). If you don't want the
slowdown of encryption, the Kerberos rsh and rcp are quite happy to
serve simply as an authentication method. The biggest problem with

cloak-and-dagger friends in Washington, D.C. who won't allow Americans
to put out a pre-compiled package on the Internet to make things
easier.

ftp, rcp, rsh, are your friends. You can put them in scripts (either
shell scripts or for ftp, Python scripts are nicest) and send data
hither and fro. I could not keep my clients updated in the field
without the automated scripts I've accumulated for that purpose -- I
can transmit the latest update package to every school district
central office that we serve with less than ten keystrokes.

As for making sure the system comes back up from a reboot, the easy answer
there is, "Don't reboot" :-). I have some systems out in the field
running Red Hat 3.0.3 that have not been rebooted in two years. As the saying
goes, "If it ain't broke, don't fix it." (These systems are not connected
to the Internet, so they ain't broke).

--

   Linux & Educational Administration computer solutions