[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Work MachineZ - Part3



> -----Original Message-----
> From: Paul Jones [mailto:pjones@metalab.unc.edu]
> Sent: Wednesday, May 31, 2000 6:09 PM
> To: Joshua Drake
> Cc: Jeremy D. Zawodny; Gregory Leblanc; 
> ldp-discuss@lists.linuxdoc.org;
> ldp-discuss@lists.debian.org
> Subject: Work MachineZ - Part3
> 
> First let me say that these are wonderful problems to be discussing.
> having several machines and plenty of disks and enthusiastic 
> people is a
> great thing. thanks for your good work, joshua!

Definately sounds like a great deal of fun to me, I love my job as a network
admin.  :)

> we tackle some very similar set up problems at metalab. 
> here's what we do:
> 
> we have a "work machine" which allows logins for our various 
> maintainers
> of archives etc. there folks can compile, script etc to their hearts'
> content. we even allow telnet and ftp into that machine--not 
> that i want
> to; like joshua i would require ssh etc in an ideal situation.

Hmm, guess I'm used to thinking on a really slim budget.  I don't put two
machines where 1 would do, since I can't afford one in the first place.
Splitting things up for these reasons (as both you and Poet suggested),
sounds great to me.  

> The files are shared in the most part with the web/ftp 
> server. root on the
> web/ftp server owns the files (not root on the work machine) 
> for security
> reasons. the web/ftp server is only accessible by ssh and 
> only to certain
> ids (about 3).
> 
> if the work machine dies, the server keeps on cooking. 
> changes to files on
> the work machine are accessible to the web/ftp server without any file
> transfer or other updates (unless you want to be a bit more careful).
> 
> this arrangement has worked pretty well for the past 5 years and i
> recommend it. still a completely standalone set up is a fine way to go
> too.

Sounds great to me.  I think I deleted the original specs that Josh posted,
but I'll go dig the archives.

> about sparc linux: it didn't run on the enterprise 1000s when last i
> looked, but we'll be glad to try it out if i'm out of date or simply
> wrong. in fact, we'll be freeing up an enterprise 1000e in 
> the next few
> weeks on which we can try to run sparc linux (i was talking 
> to jem about
> this one the way home today).

I don't know how good S/Linux is on Ultras, but I have to say that it pretty
much bites on my SPARCstation20 at home.  The only reason that I still run
it is because the console support on Solaris sucks.  As for exactly what
sucks on S/Linux (can't call it SPARC Linux, SPARC International doesn't
like that), hardware support.  Much of the Sun/SPARC hardware isn't
supported, and what is supported is sometimes not that good.  My SCSI bus is
maxed at 3MegaBytes/sec under S/linux, I can get 7.5 from a single disk
under Solaris.  It IS true that on 32-bit SPARC, the on-board network is
FASTER than local disks.  Anyway, Paul, I've been doing SPARC linux for a
while, so if you've got general questions, you can ask me.  There are
several good developers who actively read the sparc-linux list on vger, so
that's another great place for info.  The 2.4.x kernels should improve
hardware support sifignantly, BTW.  Thanks!
	Greg


--  
To UNSUBSCRIBE, email to ldp-discuss-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org


mirror server hosted at Truenetwork, Russian Federation.