HDTenEightyP/NetNews huggingface dataset:
From: ccsis@sunlab1.bath.ac.uk (Icarus Sparry)
Newsgroups: comp.unix.admin
Subject: Re: Set a password from a shell script?
Date: 27 Jan 93 13:17:12 GMT
Organization: Bath University Computing Services, UK

In the referenced article, duffiem@wl.com (Mark Duffield) writes:
>I am looking for a program (c, shell, perl) that will allow me to
>set a users password from a shell script.  This program will only be run from
>root.  As you probably know, passwd(1) won't let you do this.  I have alot
>of users to create and I don't want to:

You don't say if you are using a BSD based system, but if you are then
you should get the 'pty' program from a comp.sources.unix archive.

When you do, you will find your statement that passwd(1) will not allow
you to set passwords is false. 'pty' even has an example script which
shows you how to do it. 'pty' is a very useful program - get it!
Newsgroups: comp.unix.admin
From: ghg@en.ecn.purdue.edu (George Goble)
Subject: Re: Tape drives (was Re: Dumping a Gigabyte)
Organization: Purdue University Engineering Computer Network
Date: Sat, 23 Jan 93 15:19:46 GMT

In article <1jhhuvINN4ei@lynx.unm.edu> sfreed@hydra.unm.edu (Steve Freed) writes:
>In article <1993Jan17.210451.14999@siemens.com> aad@siemens.com (Anthony Datri) writes:
>
>> While DAT drives have certain appealing features, the fact remains that
>> they're often abysmally slow.  The Archive Python, for example, has a 
>> *peak* write speed of 183 K/s.
>
>Someone also mentioned that a minus was the low capacity (1.2 Gig.). I
>recently saw one advertised that did 8 Gig. I'm not sure what the write
>speed was, but I'm guessing it would be somewhere above 1 M/s based on
>the above number. (It all depends on your compression ratio)
>
>I prefer DAT because 1) There is more than one manufacturer, I like
>competition (the price is lower, more than one source), 2) Access speeds
>are *much* quicker. (access as in "mt fsf 4" and "mt rew")
>

The "8 Gig" DAT, was probably from HP.  It is advertised to be 2GB
without compression.  I tested one of those in compression mode.
I repeatedly dd'd (51200 byte records), the system disk (420MB), system
binaries + user files, no images or large areas of "zero" blocks,
to the tape. The 8gig Dat held 3.1gig, and transfer rate was
18 meg/min.  That was the long tape also (90m?).

An Exabyte 8500, with a "screen door" (Peripheral Vision Co.)
compression system, held 8.9GB (dumping the same disk), and
had a transfer rate of around 60 meg/min.  I know which one
I am going to use.

--ghg
From: donr@sadis05.kelly.af.mil (DONALD G. RUEBENSON II - SCST)
Newsgroups: comp.unix.admin
Subject: Re: Dumping a Gigabyte
Date: 21 Jan 93 23:34:22 GMT
Organization: 1923CCSG/SC Kelly AFB, San Antonio, TX

Some very good information in this thread.  Sorry I missed the original
posting.  One issue that has not been addressed: what about mirroring
filesystems and backing up from a offline mirror when necessary?  Yes,
this is expensive (disk space $ * 2) but cheap compared to corrupt
backups when you need them, and would reduce the likelyhood of needing
the backups in the first place significantly.  performance is usually
better on the read side as well, depending on the mirroring
configuration (full spindles preferred), by eliminating head contention
during the backup operation.  However, few if any tape subsystems I have
had the pleasure of working with could take advantage of the
improvement.  NOTE: if the mirrored disk is being used as storage for a
database (ala ORACLE, UNIFY) care should be taken to shut down the
database engine prior to taking the mirror partition offline for backup
or the above claims of data integrity are null and void.  Once the
mirrored piece is offline the datbase can be restarted immediately and
can run during the backup operation.  There is also no reason to halt
the database to reattach the mirrored piece - it will 'catch up'
automatically.

We run a Pyramid MIS-4/4, but the above behavior has been noted from
other platforms as well.

	-- donr
Newsgroups: comp.unix.admin
From: senturia@bio4.csuohio.edu (J B Senturia)
Subject: Re: Login Name Administration & Conventions
Organization: Cleveland State University, Biology Dept
X-Newsreader: TIN [version 1.1 PL6]
Distribution: usa
Date: Thu, 21 Jan 1993 20:23:09 GMT

Unix system V "requires" (read enforces) an EIGHT character login name.
Unix system V also "requires" a minimum of SIX and a MAXIMUM of EIGHT
     significant characters for passwords (although root may override)
     --override the lower limit that is--
Machine names have been traditionally limited to SIX characters -- why?
  UUCP names?

--
Jerome B. Senturia		| uucp: {uunet}!cwjcc!ncoast!csubio!senturia
Department of Biology 		| Internet: senturia@bio4.csuohio.edu
Cleveland State University	| Telephone: (216)687-2411
Cleveland, Ohio 44115		| "I didn't do it and I won't do it again."
Newsgroups: comp.unix.admin
From: vanepp@fraser.sfu.ca (Peter Van Epp)
Subject: Re: Dumping a Gigabyte
Organization: Simon Fraser University, Burnaby, B.C., Canada
Date: Fri, 22 Jan 1993 16:11:12 GMT

donr@sadis05.kelly.af.mil (DONALD G. RUEBENSON II - SCST) writes:

>Some very good information in this thread.  Sorry I missed the original
>posting.  One issue that has not been addressed: what about mirroring
>filesystems and backing up from a offline mirror when necessary?  Yes,
>this is expensive (disk space $ * 2) but cheap compared to corrupt
>backups when you need them, and would reduce the likelyhood of needing
>the backups in the first place significantly.  performance is usually
>better on the read side as well, depending on the mirroring
>configuration (full spindles preferred), by eliminating head contention
>during the backup operation.  However, few if any tape subsystems I have
>had the pleasure of working with could take advantage of the
>improvement.  NOTE: if the mirrored disk is being used as storage for a
>database (ala ORACLE, UNIFY) care should be taken to shut down the
>database engine prior to taking the mirror partition offline for backup
>or the above claims of data integrity are null and void.  Once the
>mirrored piece is offline the datbase can be restarted immediately and
>can run during the backup operation.  There is also no reason to halt
>the database to reattach the mirrored piece - it will 'catch up'
>automatically.

>We run a Pyramid MIS-4/4, but the above behavior has been noted from
>other platforms as well.

>	-- donr

We run a (home grown) system like this on our Auspex NFS file server. I am
curious about what you mean about the tape subsystem not taking advantage 
of it. How would a tape drive take advantage of it (ours dumps the mirror
volume)? 
	There is a possible additional restore advantage here too, you can
use dd to dump the mirror instead of backup and avoid the time it takes 
restore to create directories on a full restore (you just dd the tape back
to a new disk and fsck). Since (at least on Exabyte 8200s and an Auspex)
you are limited by tape speed, the is no time cost to single file restores
either, you just dd the tape to the mirror drive, fsck it and mount it 
read only somewhere, and all the files on the backup volume are availible
for the users to pick and choose (and they can remain there until the 
next full backup). I have code that both locks /etc/dumpdates (so multiple
dump streams work correctly) and lies through its teeth about what partition
just got dumped (since it is always the mirror volume not the real volume)
so that dump/restore incrementals without mirrors work as well. While I was
at it, I also added labels to the tapes (and the code to check them in the
dump scripts) so that we are sure that the correct partition got dumped to
the correct tape (and it is an ascii file so that it can be dumped with 
dd from the tape if the tape label falls of).

Peter Van Epp / Operations and Technical Support 
Simon Fraser University, Burnaby, B.C. Canada
Newsgroups: comp.unix.admin,comp.unix.programmer,comp.unix.wizards,comp.unix.questions
From: wl@cypress.com (Wilbur Luo/COMM)
Subject: >> Need HELP recovering tar data!
Originator: wl@coast
Organization: Cypress Semiconductor
Date: Tue, 26 Jan 1993 01:38:51 GMT

I need some help recovering data on a tape. Here's what happened.

A user was trying to read from a tape with tar data (and it wasn't write 
protected), and inadvertently issues a tar cf /dev/tapeblah filea
command. There was no file named "filea" but it looks like the header
on the tape was overwritten anyway.

We know the data is still on the tape, but it's inaccessible. I tried
mt, dd, tarx,etc.. and tried to forward over the bad stuff and dump the
data to no avail.

Does anyone know how to recover the data or point me to a program that
will?

Thanks much!

-W
wl@cypress.com
From: farrow@ucsu.Colorado.EDU (J. Scott Farrow)
Subject: Re: Dumping a Gigabyte
Organization: University of Colorado, Boulder
Date: Thu, 21 Jan 1993 20:13:33 GMT

aad@siemens.com (Anthony Datri) writes:

>>I believe their capacity is also lower. I've only seen them go up to a
>>gig per tape, whereas you can get 10 gig on an exabyte.

>Unless I've missed something, an Exabyte 8500 has a raw capacity of around 5G.
>10G would be with compression, and you can get compression on DAT drives as
>well.  A 60m DAT will get you ~1.6G; a 90m DAT ~2G.

>-- 

We've been testing an HP 35480A SCSI DAT drive recently. This drive uses
an enhanced DAT format called Digital Data Storage (DDS).

Here are the HP supplied specs:

(for a 90m tape)

Capacity: 8 Gigabytes (with compression)
Data Transfer Rate: 11 Mg/min (~183 Kb/s) 
	("sustained data transfer rate to and from tape")


We haven't timed it, but I think we've been able to get up to 6 Gigabytes 
on a tape.


Scott

--
------------------------------------------------------------------------------
J. Scott Farrow-Student SysAdmin/Programmer, University of Colorado at Boulder
Computing & Network Services, Boulder, Colorado, USA, phone: (303) 492-4428
Internet: farrow@spot.colorado.edu, farrow@cs.colorado.edu
Newsgroups: comp.unix.admin
From: les@chinet.chi.il.us (Leslie Mikesell)
Subject: Re: Wanted: TSR LPD for DOS
Organization: Chinet - Public Access UNIX
Date: Fri, 22 Jan 1993 21:18:32 GMT

In article <1993Jan21.122732.3849@unipalm.co.uk> steven@unipalm.co.uk (Steven Vincent) writes:

>I don't like the truth as I know it.  I am seriously looking into
>writing a simple TSR to emulate the HPJetDirect cards or a terminal
>servers reverse connection serial port. If the Unix box spools the 
>job and feeds it out over a raw TCP connection the PC does not need
>to do anything more complicated than pass the data out the port and 
>handshake the TCP connection.

Has anyone done this yet?   How about full terminal server support
so you could hang a couple of modems off a PC anywhere on the network
and access them from anywhere else?   Or simple printer pass-through
using a netbios connection instead of TCP on the PC end?  It seems
to me like this could be done with an option to let the PC send
it's jobs directly to the LPT port instead of over the network and
back, using a simple timeout to interleave jobs.

Les Mikesell
  les@chinet.chi.il.us

Newsgroups: comp.unix.admin
From: aad@siemens.com (Anthony Datri)
Subject: Re: Dumping a Gigabyte
Organization: Siemens Corporate Research, Princeton (Plainsboro), NJ
Date: Wed, 20 Jan 1993 23:55:55 GMT

>A full backup every week takes, say, 8 tapes for the full, and 5 tapes for
>the incrementals (8 FULL+(1 INC*5days)=13tapes.  Spreading that through the
>month makes the formual (8 FULL+(1 INC*20 days)=28.

Well, not really.  From the man page:

     0-9  The "dump level." All files in the filesystem that have
          been modified since the last dump at a lower dump level
          are copied to the volume.

The usual scheme is to run daily incrementals at the same arbitrary level
every day.  Thus, if one did a level 0 monthly, one'd do a level 1 (or 5,
or whatever) daily.  Restoration 20 days (months have 20 days?) after the
full would involve the full dump and only the most recent incremental.

Of course, doing those incrementals sucks tapes, and toward the end of the
month they're likely going to rival the fulls in size anyway.

Has anyone ever actually used the infamous "tower of hanoi" scheme, or is it
just someone's cruel joke?

>2) Like most large shops, we run 7 by 24.  The only time when we have even a
>hope of getting clean backups is between 11:00pm and 7:00 am.  

I've always marveled when people say that they go single-user for backups.
When people run three-week-long jobs, it's tough enough to even schedule a
fastboot

>3) DATS.  Well, that's one I hadn't thought of.  On the other hand, my
>personal experience with them is that they are slower than the exabytes

The Archive Python has a peak write rate of 183k/s.  On an SS2 with a huge
user-mode blocking factor I got about 150 with dump; about half that with
tar.  The HP-supplied drives that I've used on HP's seem to be *much* faster,
but I have no numbers.

-- 

======================================================================8--<
Newsgroups: comp.unix.admin
From: vanepp@fraser.sfu.ca (Peter Van Epp)
Subject: Re: Backups and filesystem activity (was: Re: Dumping a Gigabyte)
Keywords: rc.single, automatic dumps, filesystem consistency
Organization: Simon Fraser University, Burnaby, B.C., Canada
Date: Fri, 22 Jan 1993 16:38:46 GMT

op@holmes.acc.Virginia.EDU (Olaf  Pors) writes:

>>How reliable (or unreliable) are the backups made from active
>>file-systems? 

< data removed>

>  This is an answer based on experience, but I'd like to
>hear from anyone who has a definite answer based on knowledge
>of the backbyinode source.

The paper "Torture-testing Backup and Archive Programs: Things You Ought To
Know But Probably Would Rather Not" by Elizabeth Zwicky in the Usenix
LISA V proceedings (and the associated test program that is availible via
ftp, but whose name I forget) should make interesting reading. Dump didn't
do as well as was expected (or hoped) when some types of filesystem changes
were made while it was running. Interesting (and scary if you don't have a 
mirrored backup system) reading.

Peter Van Epp / Operations and Technical Support 
Simon Fraser University, Burnaby, B.C. Canada
Newsgroups: comp.unix.admin
From: lnosek@ux4.cso.uiuc.edu (Luke Nosek)
Subject: Mirroring files on two systems
Organization: University of Illinois at Urbana
Date: Thu, 21 Jan 1993 04:36:25 GMT

	 What (*free*) software that would allow me to "mirror" (if a file
/x/y/z is modified or created on one system it will be similarly modified or
created on the other) the contents of directories on two systems?
							Luke Nosek
Newsgroups: comp.unix.admin
From: steven@unipalm.co.uk (Steven Vincent)
Subject: Re: Wanted: TSR LPD for DOS
Cc: hennie@nuustak.csir.co.za, ccowboy@seer.gentoo.com 
Organization: Unipalm Ltd., 216 Cambridge Science Park, Cambridge CB4 4WA, UK
Date: Thu, 21 Jan 1993 12:27:32 GMT


>In article <hennie.727432803@nuustak> hennie@nuustak.csir.co.za (Hennie Rautenbach) writes:
>>Hi
>>
>>I'm looking for a utility that gets loaded into TSR on a DOS PC transforming
>>it into a Print Server to which UNIX "lpr" jobs can be spooled to accross an
>>ethernet network.
>>
>>Has anyone seen or come accross such a utility ? If so, where can I find it ?
>>
>>Please mail me directly as I'm not a frequent reader of this group.

>Please mail this newsgroup w/ any information as some of us are frequent
>readers of this group.

This is frequently discussed in comp.protocols.tcp-ip.ibmpc. Several 
companies (inc PC-NFS and BW-TCP) produce such programs. My experience
of them so far is that it is not a good idea. The limitations on DOS
TSRs is such that only very limited functionality is possible and these
LPDs have very finite limits as to how many connection they can safely
accept at time (apparently 1 Sun is max!). In addition filters are not
generally supported and the DOS performance for the foreground app suffers
badly. For our own in House purposes we either use an old PC as a dedicated
printserver (low Use - accounts wide dot matrix) or 386SX boxes running OS/2
and FTP's PC/TCP for OS/2. In all cases the print jobs are routed through 
the LPD of one SUN so that the PC's receive the jobs as a single stream.
This also has the administration advantage that if a printer is moved only
one printcap file needs to be changed rather than 60 + PC's running different
software, 2 Vaxen and 12+ Unix boxes of different Flavours.

Supporting DOS based TCP/IP products I get at least 1 call a week on
the use of PCs as printservers while being used for other apps.

I don't like the truth as I know it.  I am seriously looking into
writing a simple TSR to emulate the HPJetDirect cards or a terminal
servers reverse connection serial port. If the Unix box spools the 
job and feeds it out over a raw TCP connection the PC does not need
to do anything more complicated than pass the data out the port and 
handshake the TCP connection. This should be much simpler and
impose far less load on the single-tasking DOS box, I shall also find
out if the rumors I heard a few years back about the PC's Parellel 
port and IRQs being broken are true (something about the original
design using Edge triggered and the BIOS checking for level triggering
of IRQs).  If HPJetdirect cards and Spider Terminal servers can 
support printers this way it I feel that PC support would be useful.

Comments Please. 

================================================
Steven Vincent,             steven@unipalm.co.uk
Unipalm Ltd.                (44) 0223-420002
Cambridge,
England.
================================================

servers can work this wayy
From: senturia@bio4.csuohio.edu (J B Senturia)
Newsgroups: comp.unix.admin
Subject: Re: Login Name Administration & Conventions
Date: 21 Jan 93 20:35:07 GMT
Distribution: usa
Organization: Cleveland State University, Biology Dept
X-Newsreader: TIN [version 1.1 PL6]

In my last post I said UNIX SYSV requires 8 char login name I should have said
limits login name to EIGHT CHARACTERS MAXIMUM.

sorry,
--
Jerome B. Senturia		| uucp: {uunet}!cwjcc!ncoast!csubio!senturia
Department of Biology 		| Internet: senturia@bio4.csuohio.edu
Cleveland State University	| Telephone: (216)687-2411
Cleveland, Ohio 44115		| "I didn't do it and I won't do it again."
Newsgroups: comp.unix.admin
From: glover@credit.erin.utoronto.ca (Mike Glover)
Subject: Re: Errors on SCO UNIX v3.2.4 reading tapes
Organization: University of Toronto, Erindale Campus
Date: Mon, 25 Jan 1993 01:36:45 GMT

In article <1993Jan23.034856.9489@plains.nodak.edu!midkemia> cooper%midkemia@plains.nodak.edu (Jeff Cooper) writes:
[Questions deleted]

I don't know if this will help any but I had this happen once or twice.  I 
couldn't recover everything,  but I did get most.  What I did was used dd to
dump the contents of the tape to a file.  (you need lots-o-room for this 
manouver)  then I untarred the dd file.  You have to tweak the dd switches as
I remember to be able to do this.  This may or may not work but it is one way
I recovered as much as I could.  I hope this helps.  :)

ttfn,
	Mike

-- 
===============================================================================
glover@credit.erin.utoronto.ca  | Diplomacy is saying nice doggie,  while
Mike Glover                     | kicking in the dirt for a rock.
===============================================================================
Newsgroups: comp.unix.admin
From: john@elsouth.uucp (John White)
Subject: Hey! Wot's all this FTP then?
Summary: I need FTP capability. What do I buy to get it?
Keywords: FTP TCP/IP
Organization: Electrical South Inc
Date: Wed, 27 Jan 1993 17:33:25 GMT

I'm the sysadmin on a AT&T Starserver E (SysV R4.0 V3.0). I keep
running into posts about this "anonymous ftp" thing. Can someone
give me the basics. I'd like to be able to take advantage of it,
but my standard tech support is playing dumb on this one. Sorry
if this is an INCREDIBLY common question which is misposted.

-john (john%elsouth@concert.net)
-- 
-john (john%elsouth@concert.net)
From: aad@siemens.com (Anthony A. Datri)
Newsgroups: comp.unix.admin
Subject: Re: Dumping a Gigabyte
Date: 22 Jan 93 23:21:04 GMT
Organization: Siemens Corporate Research, Princeton (Plainsboro), NJ

>We've been testing an HP 35480A SCSI DAT drive recently. This drive uses
>an enhanced DAT format called Digital Data Storage (DDS).

As I understand it, DDS is really just a structuring format for how the
blocks/error counts/etc go onto the tape.  I believe that Sony (?) has/had
a competing format that never had much success.

>(for a 90m tape)

>Capacity: 8 Gigabytes (with compression)

That's 4x -- I'll bet it's a "peak" capacity.

-- 

======================================================================8--<
From: hendrick@ctron.com (James R. Hendrick)
Newsgroups: comp.unix.admin
Subject: Backup Advice Wanted !!
Date: 25 Jan 93 18:21:50 GMT
Distribution: comp
Organization: Cabletron Systems Inc.


Hello All,
	We are in the process of re-vamping our strategy for performing
backups. Currently, we have slightly less than 5G at one site, somewhat
less at another two sites that must be done each night. In addition, we
perform as-requested backups of many other areas during the day. As
you can well imagine, this is getting a bit out of hand.

	What I would like from you all is recommendations/warnings
about what hardware (stackers, carousels, R/W Optical devices, etc)
and software you have knowledge about. I am NOT looking for blatant
sales pitches, but UNBIASED responses from folks that have to live
with the stuff.

Thanks in advance,

Jim

P. S. I'll summarize if it seems warranted

--
###########################################################################
### Jim Hendrick (hendrick@ctron.com)   ###                             ###
### Cabletron Systems Inc.              ###   " My opinions, etc are    ###
### P. O. Box 5005                      ### exclusively the property    ###
### Rochester, NH 03867-5005            ### of nobody in particular."   ###
### (603) 337-7572                      ###                             ###
### fax:(603)337-7370                   ###                             ###
###########################################################################
Newsgroups: comp.unix.admin
From: aad@siemens.com (Anthony Datri)
Subject: Re: Dumping a Gigabyte
Organization: Siemens Corporate Research, Princeton (Plainsboro), NJ
Date: Thu, 21 Jan 1993 00:00:43 GMT

>I believe their capacity is also lower. I've only seen them go up to a
>gig per tape, whereas you can get 10 gig on an exabyte.

Unless I've missed something, an Exabyte 8500 has a raw capacity of around 5G.
10G would be with compression, and you can get compression on DAT drives as
well.  A 60m DAT will get you ~1.6G; a 90m DAT ~2G.

-- 

======================================================================8--<
Xref: sparky comp.unix.admin:7258 comp.unix.questions:16000