HDTenEightyP/NetNews huggingface dataset:
From: toddi@mav.com (Todd Inch)
Subject: Re: No Directory! Logging in with HOME=/
Organization: Maverick International Inc.
Date: Fri, 09 Oct 92 20:34:03 GMT

In article <1992Sep28.122323.5736@cc.ic.ac.uk> cmaae47@cc.ic.ac.uk writes:
>In article <1992Sep25.000434.23008@citec.oz.au>, sgccpxb@citec.oz.au (Paul Brown 2245719) writes:
>- 
>- We have a database machine that users don't need a home directory for.
>- Because it has the same passwd file as other machines, that require you 
>- to have a home directory, we can't just edit out the field in passwd.

If you can make linked directories on this version of Unix, you could
actually have a directory for each user which are all actually links to
somewhere.  Of course, that requires creating a link whenever you add
another user.

Or, you could have everyone have the same HOME and then the main login
script could redefine it as necessary only on those machines that
actually have them.  I would guess that in most cases everyone's HOME
should be known directory prefixed with the users login name.  Is there
any software that reads the users HOME from passwd other than upon login?
Xref: sparky comp.unix.admin:5712 comp.sys.mac.system:12829 comp.sys.mac.misc:17853
From: paulwo@informix.com (Paul Wolmering)
Newsgroups: comp.unix.admin,comp.sys.mac.system,comp.sys.mac.misc
Subject: Mac to Unix Printer
Date: 16 Oct 92 15:32:40 GMT
Organization: Informix Software, Inc.
Originator: paulwo@cheetah

hi,
 i need the ability to have a MAC print to a unix postscript printer over
 ethernet. the unix postscript printer is attached to a sun. 
 
 is there any public domain software out there that works well?

 if not, any suggestions for $$$$ packages?

thanks,
paul
From: sp_pm@space.alcbel.be (Paul Moore)
Newsgroups: comp.unix.admin
Subject: How to print ASCII files on a postscript printer
Date: 8 Oct 92 18:31:35 GMT
Article-I.D.: space.9210081631.AA02216
X-Received: by usenet.pa.dec.com; id AA23616; Thu, 8 Oct 92 13:56:37 -0700
X-Received: by inet-gw-1.pa.dec.com; id AA19743; Thu, 8 Oct 92 13:54:33 -0700
X-Received: from ub4b.buug.be by mcsun.EU.net with SMTPid AA27176 (5.65b/CWI-2.179); Thu, 8 Oct 1992 21:54:11 +0100
X-Received: from alcbel.UUCP by ub4b.buug.be (5.65c/ub4b_02)id AA04268; Thu, 8 Oct 1992 21:54:13 +0100
X-Received: from se.alcbel.be by alcbel.be (4.1/SMI-4.1)id AA13912; Thu, 8 Oct 92 17:27:47 +0100
X-Received: by se.alcbel.be (5.57/SE_04)id AA14891; Thu, 8 Oct 92 17:32:23 +0100
X-Received: from btmpjw.space by space.alcbel.be (4.1/SMI-4.0)id AA02216; Thu, 8 Oct 92 17:31:35 +0100
X-To: comp.unix.admin.usenet


Hello,

We have several Brother HL-8PS printer here. They can be configured to work either in Postscript mode or in HP LaserJet III mode of operation, by means
of front-panel selectable options.

This means that we have to change the mode of operation at the printer's front panel in order to go from Postscript mode to HP LaserJet mode, and vice versa. Is there any way, such as by means of using a printer filter or some such (I don't know anything about printer filters), to be able to print both ASCII text files and Postscript files?

Please respond by email, as I don't have access to the News.

Thanks, Paul

---
email: sp_pm@space.alcbel.be
From: greep@Speech.SRI.COM (Steven Tepper)
Newsgroups: comp.unix.admin
Subject: Re: WANTED: Unix administration horror stories !
Date: 12 Oct 92 04:17:13 GMT
Organization: SRI International

This may not exactly fit the "administration horror story" category, but...

At one place where I worked, someone had set up cron to delete any
file named "core" more than a few days old, since disk space was
always tight and most users wouldn't know what core files were or care
about them.  Unfortunately not everyone knew about this and one user
lost a plain text file (a project proposal) he'd spent a one lot of
time working on because he called it "core".  This was around 1976,
when Unix was still considered exotic and before bookstores carried
entire sections of Unix books.

-greep
Newsgroups: comp.unix.admin
From: root@trebor.uucp (Bob Stockler)
Subject: Re: EXABYTE Tape costs
Organization: Bob Stockler
Date: Fri, 09 Oct 1992 23:06:31 GMT

gpb@gpb-mac. (greg berryman ) writes:

>Did you ever notice the word "certified" on a data-grade tape?  This means
>that the tape has been tested for dropouts and the like.  Takes time and
>hardware not needed for video grade tapes.

I donno.  Mebe make 'em all on the same line(s), take a stastically valid
sample of a run, test 'em, and if it passes shoot them in the direction of
the packaging that markets them as "certified".  Sorta like making resistors,
some of which end up with a gold stripe, some a silver, etc.

I will never believe that any ONE particular "certified" tape has been
individually tested.  (And the requirements for video tapes are not all
that shabby either.)

Newsgroups: comp.unix.admin
From: fitz@wang.com (Tom Fitzgerald)
Subject: Re: Pros/Cons: simple vs. fully-qualified name for workstation?
Organization: Wang Labs, Lowell MA, USA
Date: Sat, 10 Oct 92 06:25:14 GMT

jc@minya.UUCP (John Chambers) writes:

> You will eventually have some "gateway" machines that are on more than one
> network.  This happens if you use SLIP, for instance. Such machines
> will of course have two or more IP addresses, one per network
> attachment, and each address will be a different fully-qualified
> "host" in your host table. If the hostname is the same as one of
> these, you will find your software (e.g., email) advertising the wrong
> domain on at least one of these networks.

I've never heard of anyone using a scheme like this.  You tie the domain
names to the physical network?  Do you change a system's domain name when
it moves to a different LAN?  Why do you do it?  This sounds like it would
be an amazingly painful arrangement.

> The result will be a lot of
> "network not reachable" failures.

Why isn't the mail simply routed at the IP layer to the other interface?

> The correct way to do it, if you can
> figure out how to get your software to do it right, is to have the
> software add the right domain to the hostname, depending on which
> network is being used for a given connection. But this ain't easy.

Even if it were easy, it would be crazy.  Why should the mailer care about
which ethernet interface the mail is leaving through?

> Also, I've seen mailers do things like take a hostname such as
> host.dom.ain, and add the domain to it, giving host.dom.ain.dom.ain.
> This does a marvelous job of confusing a lot of recipient software.

Unfortunately, there are even more mailers that fail to add the current
domain to unqualified addresses leaving the domain....

> A couple years back, I tried digging through the RFCs to answer the
> question by discovering the rules as to what is allowed in a hostname.
> I found one RFC that said clearly that only letters, digits and
> hyphens are allowed. I found another RFC that said that dots are also
> allowed.

I suspect these two were talking about different things; the "short"
hostname, which must not contain dots, versus the fqdn.  Or, perhaps, the
first RFC predated the domain name system (RFCs do supercede each other, so
you can't treat a 1978 RFC as state-of-the-art gospel).

> I just thought I'd warn you that appealing to the RFCs as an authority
> won't get you very far.

???  There are *no* other authorities.  If you violate a (non-superceded)
RFC in traffic leaving your site at any layer, you will be righteously
criticized.

But this issue of whether the "hostname" command returns a short name or
the fqdn is a different, site-specific, non-standardized thing.  Personally
I vote for fqdn, but things can be made to work either way.

-- 
Tom Fitzgerald   Wang Labs       fitz@wang.com   "I went to the universe today;
1-508-967-5278   Lowell MA, USA                   It was closed...."
Newsgroups: comp.unix.admin
From: tzs@stein.u.washington.edu (Tim Smith)
Subject: Re: WANTED: Unix administration horror stories !
Organization: University of Washington, Seattle
Date: Fri, 9 Oct 1992 10:04:44 GMT

I was working on a line printer spooler, which lived in /etc.  I wanted
to remove it, and so issued the command "rm /etc/lpspl."  There was only
one problem.  Out of habit, I typed "passwd" after "/etc/" and removed
the password file.  Oops.

I called up the person who handled backups, and he restored the password
file. 

A couple of days later, I did it again!  This time, after he restored it,
he made a link, /etc/safe_from_tim.

About a week later, I overwrote /etc/passwd, rather than removing it.

After he restored it again, he installed a daemon that kept a copy of
/etc/passwd, on another file system, and automatically restored it if
it appeared to have been damaged.

Fortunately, I finished my work on /etc/lpspl around this time, so we
didn't have to see if I could find a way to wipe out a couple of
filesystems...

--Tim Smith
Xref: sparky comp.unix.admin:5722 alt.folklore.computers:15217
From: rslade@cue.bc.ca (Rob Slade)
Newsgroups: comp.unix.admin,alt.folklore.computers
Subject: Re: WANTED: Unix administration horror stories !
Date: 17 Oct 92 00:04:56 GMT
Organization: Computer Using Educators of B.C., Canada

Hope this fits.

I had a job one time teaching Pascal at a "visa school".  The machine was a
multi-user micro that ran UNIX.  I have enough stories from that one course
to keep a group of computer educators in stitches for at least half an hour.

The finale of the course was on the last day of classes.  When I showed up
and powered up the system, it refused to boot.  Since all the students' term
projects and papers were in the computer, it was fairly important.  After
a few hours of work, and consultation with the other teacher, who did the
sysadmin and maintenance, we were finally informed that the new admin
assistant around the place had decided that the layout of the computer lab
was unsuitable.  (I had noticed that all the desk were repositioned: I thought
the other teacher had done it, he thought I had.)  The AA had, the night
before, moved all the furniture, including the terminals and the micro.  She
did not know anything about parking hard disks.

We knew now, that we were in trouble, but we didn't realize how much until 
we started reading up on emergency procedures.  For some unknown reason, 
booting the micro from the original system disks would automatically reformat
the hard disk.

(The visa school refunded the tuition for all the students in that course.)
From: sam@bsu-cs.bsu.edu (B. Samuel Blanchard)
Newsgroups: comp.unix.admin
Subject: Re: WANTED: Unix administration horror stories !
Date: 12 Oct 92 20:10:18 GMT
Organization: Dept. of CS Ball State University Muncie IN


Oh yea, I recalled 2 more

kill -1 1  on an Altos SV box is not good.  I pulled this one trying to show
off.  No more gettys appeared when uses logged off.  When I went to the console,
I calmly typed 0 to the Run Level request prompt.  2 would have been nice?
It was my first SystemV like box, and it seemed to have such nice berkley
commands.

a control-s on a Sequent S27 console can cause processes to hang waiting to
write to the console.  Unfortunatly, su is one such process.  No real problem
since I don't blindly reboot on request  ;-)

-- 
B. Sam Blanchard        sam@bsu-cs.bsu.edu
418 Winfield Dr         (317) 284-7131   work
Greenfield, IN 46140
From: tjm@hrt213.brooks.af.mil (Tim Miller)
Newsgroups: comp.unix.admin
Subject: Re: WANTED: Unix administration horror stories !
Date: 13 Oct 92 21:04:23 GMT
Article-I.D.: hrt213.9210132104.AA02841
Organization: AL/HRTI, Brooks AFB


	This one qulaified for Stupid Act of the Month:

	All this happened on my sparcII...

	I was making room on / because I needed to to test run something
(which was using a tmp file in, of all places, /var/tmp.  I could have
recompiled the application to use more memory and/or /tmp, but I'm too
lazy for that), so I figure "I'll just compress this, and this, and
this..."  One of those "this'" was vmunix.

	Well, of course the application crashes the machine, and stupid
me had forgotten that I'd compressed vmunix, so the damn thing won't
boot.  checksum: Bad value or some such error.  Took me most of the day
to figure out just what I'd done to the dang thing.  8)

	Moral(s):

	1) Never, ever, EVER play with vmunix.
	2) Always keep a log of what you do to the root file system.
	
-- Cerebus <tjm@hrt213.brooks.af.mil>
"'Course, being military, it's difficult to get myself fired..."
Newsgroups: comp.unix.admin
From: hirai@cc.swarthmore.edu (Eiji Hirai)
Subject: Re: WANTED: Unix administration horror stories !
Organization: Information Services, Swarthmore College, Swarthmore, PA, USA
Date: Tue, 13 Oct 1992 16:00:28 GMT

rik.harris@fcit.monash.edu.au writes:
> I'll mount it in /tmp

Though this may strike most sane sysadmins as bad practice, SunOS (3.4 or so
- my memory is vague) shipped a command called "on".  If you were logged on
machine A and wanted to execute a command on machine B, you said "on B
command", sort of like rsh.

However, A would mount B's disks under some invokations of "on" and it would
mount it in /tmp!  Of course, lots of folks got bitten by this stupid
command and it was taken out after a long delay by Sun.

Anyone remember the details?  I've blocked out my memory of pre-4.0 SunOS.
Am I just hallucinating?

--
hirai@cc.swarthmore.edu (Eiji Hirai)    :     :    :   :  : :: ::: :::: :::::
Unix Geek for Swarthmore College        :     :    :   :  : :: ::: :::: :::::
Information Services, Swarthmore, PA, US.       Copyright 1992 by Eiji Hirai.
I don't speak for Swarthmore College.                    All Rights Reserved.

Newsgroups: comp.unix.admin
From: dbrillha@dave.mis.semi.harris.com (Dave Brillhart)
Subject: Re: WANTED: Unix administration horror stories !
Date: Thu, 8 Oct 1992 11:54:04 GMT
X-Newsreader: TIN [version 1.1 PL6]
Reply-To: dbrillha@dave.mis.semi.harris.com
Organization: Harris Semiconductor

Arne Asplem (aras@multix.no) wrote:
: I'm the program chair for a one day conference on Unix system
: administration in Oslo in 3 weeks, including topics like network
: management, system admininistration tools, integration, print/file-servers,
: securitym, etc. 
: 
: I'm looking for actual horror stories of what have gone wrong because
: of bad system administration, as an early morning wakeup.        

We can laugh (almost) about it now, but...

Our operations group, a VMS group but trying to learn UNIX, was assigned
account administration. They were cleaning up a few non-used accounts
like they do on VMS - backup and purge. When they came across the
account "sccs", which had never been accessed, away it went. The
"deleteuser" utility fom DEC asks if you would like to delete all
the files in the account. Seems reasonable, huh?

Well, the home directory for "sccs" is "/". Enough said :-(

--
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
 Dave Brillhart                              Harris Semiconductor
 dbrillha@dave.mis.semi.harris.com           Mail Stop 62A-024
 Voice: (407) 729-5430                       P.O. Box 883
 Fax:   (407) 724-7486                       Melbourne, FL 32902-0883
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Newsgroups: comp.unix.admin
From: npm@dale.cts.com (Nancy Milligan)
Subject: Re: WANTED: Unix administration horror stories !
Organization: Titan Linkabit
X-Newsreader: TIN [version 1.1 PL6]
Date: Thu, 15 Oct 1992 00:21:15 GMT

Eiji Hirai (hirai@cc.swarthmore.edu) wrote:
> rik.harris@fcit.monash.edu.au writes:
> > I'll mount it in /tmp
> 
> Though this may strike most sane sysadmins as bad practice, SunOS (3.4 or so
> - my memory is vague) shipped a command called "on".  If you were logged on
> machine A and wanted to execute a command on machine B, you said "on B
> command", sort of like rsh.
> 
> However, A would mount B's disks under some invokations of "on" and it would
> mount it in /tmp!  Of course, lots of folks got bitten by this stupid
> command and it was taken out after a long delay by Sun.
> 
> Anyone remember the details?  I've blocked out my memory of pre-4.0 SunOS.
> Am I just hallucinating?

No you aren't hallucinating, I remember this one VERY well.  Fortunately
the Sun kernel had to be patched in order to allow root to touch anything
on an NFS file system, so when the "find /tmp/. -mtime +3 -exec rm {} \;"
command ran, it couldn't do anything on the NFS system.  Scared me witless
when I saw what it was doing, until I realized that "nobody" feature
protected us.  

But those poor devils that patched their kernels so that root could access
an NFS disk (which we did later)...  I think that was one of the dumbest 
things I ever saw come from Sun.

--
Nancy P. Milligan 				npm@dale.cts.com
Titan Linkabit					cts!dale!npm
3033 Science Park Road
San Diego, CA 92121
Newsgroups: comp.unix.admin
From: jimh@pacdata.uucp (Jim Harkins)
Subject: Re: EXABYTE Tape costs
Organization: Pacific Data Products
Date: Thu, 8 Oct 1992 19:20:59 GMT

How about cleaning tapes?  I'm going to need more cleaning tapes in the next
few months, who's got the best price?

jim

-- 
I will not refer to the ideologicaly challenged as 'braindead.'
--------------------------------------------------------------
Jim Harkins                         [ucsd|uunet]!pacdata!jim
Pacific Data Products               jim@pacdata.com
--------------------------------------------------------------

Xref: sparky comp.unix.admin:5614 comp.unix.ultrix:7591 comp.sys.sgi:15044 comp.unix.wizards:4308
From: olson@anchor.esd.sgi.com (Dave Olson)
Newsgroups: comp.unix.admin,comp.unix.ultrix,comp.sys.sgi,comp.unix.wizards
Subject: Re: DAT tape compatability (DEC <-> SGI)
Keywords: DAT, DEC, Ultrix, SGI, Indigo, IRIX
Date: 14 Oct 92 05:53:25 GMT
Organization: Silicon Graphics, Inc.  Mountain View, CA

In <flint.718961720@marsh> flint@cs.curtin.edu.au (Daniel Baldoni) writes:
| Recently, a friend of mine asked if we could provide a transfer service
| for her.  She had a couple of very large TIFF images (approx 16Mb each)
| on a QIC-150 cartridge and she needed them on a DAT tape (both source and
| target were tar'd).  No problem, we've got both forms of tape drive here
| and I've yet to see a UNIX without a tar (or equivalent).
| 
| So, extract the two files using a SPARCstation and they appear fine (view
| them and they come up fine).  Next, write them to the DAT on an Indigo
| running IRIX 4.0.1.  Just to make sure the tape is fine, I read the files
| back and did a byte-by-byte comparison - all okay.
| 
| The following day, I get a call telling me the files aren't coming off
| correctly.  Of the ~32Mb tar file, only about the first 2Mb were being
| read by her DAT drive (connected to a DECstation which was running
| Ultrix - sorry version unavailable) then the "tar x ..." was just
| stopping.
| 
| Second try: I compress'd the two files and wrote them to the device (with
| no rewind) using dd.  Again, I read them both back and did a byte-by-byte
| comparison with no problems.
| 
| This time, the extraction read only about 137Kb before stopping.  In neither
| case were any errors reported; the read (via tar or dd) would just stop (I
| was there for subsequent attempts).

You might want to try writing them in fixed block mode (/dev/rmt/tps0d#ns)
to see if that helps.  The default fixed block size for all DAT drives
I've seen is 512, and that may be somewhat more portable.  Even if DEC
defaults to variable (and provides no way to use it in fixed mode, which
seems unlikely), it can still be read in variable mode with 512 byte reads
(i.e., a tar blocking factor of 1).
--
Let no one tell me that silence gives consent,  |   Dave Olson
because whoever is silent dissents.             |   Silicon Graphics, Inc.
    Maria Isabel Barreno                        |   olson@sgi.com
Newsgroups: comp.unix.admin
From: johnd@cortex.physiol.su.oz.au (John Dodson)
Subject: Re: WANTED: Unix administration horror stories !
Organization: Department of Physiology, University of Sydney, NSW, Australia
Date: Thu, 15 Oct 1992 22:34:59 GMT

Some years ago when we went from Version 7 Unix on a PDP11 to a flavour of BSD
on a Vax, I was working on the Vax in my home directory & came across a file
that I had no permission on (I'd created it as root) so the following ensued...

	$ /bin/su -
	Password:
	# chown -R me *

	mmmmm this seems to be taking a long time !
	kill.
	# ls -l

	the result was that I was in / after the su !
	(good old V7 su used to leave you in the current directory ;-)

It took me quite a while to restore all the right ownerships to /bin /etc & /dev
(especially the suid/sgid files)
I'd managed to kill it before it got off the root filesystem.

not quite rm -fr / but...

johnd@physiol.su.oz.au
From: mre1@itri.bton.ac.uk (Mark Evans)
Newsgroups: comp.unix.admin
Subject: Summary: Detecting logout of User
Date: 9 Oct 92 09:29:13 GMT
Reply-To: mre1@itri.bton.ac.uk
Organization: ITRI, University of Brighton, UK

Thank you for all the replies. Some of the most useful were:

You didn't give the O/S version, so it's pretty hard to get
that answer.  About the best you can do is find the login shell
entry in the /etc/utmp file and wait for it to disappear.  That
isn't an easy trick in a windowing environment.  On the other
hand you could take the conservative approach and just use

	if [ `who | grep $USER | wc -l` -eq 0 ] ; then
		sort your files
	fi

John F. Haugh II      

--------------------------------------------------------------

In your .logout

if ('tty' == console) then
	.......
endif

Joe Minieri

--------------------------------------------------------------


> In your /etc/profile put:  
>
> trap "......" 0
>
> Where ....... is a command or script file, stick this at the top of
> your /etc/profile and document it so the next guy knows what you're
> up to.

Jerry Rocteur

This won't for for shells that don't use /etc/profile.  (Of which
there are very many)  Plus this will be totally useless under many
windowing systems that may spawn multiple login shells.  (xterm -ls)

Dave Barr

--------------------------------------------------------------

Thank you again for everybodies help.

Regards,

Mark

+-------------------------------------------------------------+
|                                                             |
| Mark Evans                     e-mail: mre1@itri.bton.ac.uk |
|                                uucp:   uknet!itri!mre1      |
| ITRI, Univeristy of Brighton,  Tel:    +44 273 642915       |
| Lewes Road, Brighton,          Fax:    +44 273 606653       |
| E. Sussex, BN2 4AT, UK.                                     |
|                                                             |
+-------------------------------------------------------------+
Newsgroups: comp.unix.admin