HDTenEightyP/NetNews huggingface dataset:
From: jfh@rpp386.lonestar.org (John F. Haugh II)
Newsgroups: comp.unix.admin
Subject: Re: temparary superuser
Date: 16 Oct 92 12:36:05 GMT
Reply-To: jfh@rpp386.cactus.org (John F. Haugh II)
Distribution: usa
Organization: River Parishes Programming, Austin, Republic of Texas

In article <1992Oct14.141628.7491@bilver.uucp> bill@bilver.uucp (Bill Vermillion) writes:
>I have seen several small SCO Xenix systems set up that way.   And all
>the users log in as root!
>
>I told them NOT to do that but they did anyway.
>
>Then they can't figure why no terminals would work.
>
>SCO in it's boot mode with a line that says something like "Press
>control-D for system startup, or system password for maintenance."
>
>And someone not reading the screen presses enter and they are instantly
>in single user mode.  They go about their work and everyone else
>complains that their terminals aren't working.  So they reboot the
>system and it all works - and then they curse "that damn Xenix!".
>
>Some people just don't want to be helped. 

If this is still a client of yours, you might want to get ... The Shadow
Password Suite ... and compile "sulogin" from it with a few minor hacks.

The other issue about SCO Xenix is that it doesn't use a real System V
init, so you can't configure the system to go straight to multiuser mode.
-- 
John F. Haugh II                  [  TSAKC  ] !'s: ...!cs.utexas.edu!rpp386!jfh
Ma Bell: (512) 251-2151           [ DoF #17 ]        @'s: jfh@rpp386.cactus.org
Newsgroups: comp.unix.admin
From: vidya@akshay.csd.sgi.com (Vidya Alankar)
Subject: Re: Sticky-Bits and Group IDs in DIRECTORIES?
Organization: Silicon Graphics, Inc.
Date: Tue, 13 Oct 1992 19:26:17 GMT

Please read 'man chmod' - excerpts :
     The sticky bit is so named for historical reasons. It currently has no
     effect on any regular file.  If a directory is writable and has the
     sticky bit set, files within that directory can be removed only if one or
     more of the following are true [see unlink(2)]:

          the user owns the file
          the user owns the directory
          the file is writable by the user
          the user is the super-user.

     If the  set-group-ID flag is set on a directory, then files created in
     that directory will have their group ID set to the group ID of the
     directory, otherwise the group ID of the file is set to the effective
     group ID of the creating process [see chmod(2)].

Vidya

In article <1992Oct13.110046@iphase.com>, plarkin@iphase.com (Patrick Larkin) writes:
|>  
|> First of all, what is the purpose/benefit of setting a sticky-bit on a DIRECTORY?!?!?
|> 
|> Secondly, why do all files created take on the group id of its parent directory and 
|> ignore the group id of the user?
Newsgroups: comp.unix.admin
From: stehman%citron.cs.clemson.edu@hubcap.clemson.edu (Jeff Stehman)
Subject: Re: WANTED: Unix administration horror stories !
Reply-To: stehman%citron.cs.clemson.edu@hubcap.clemson.edu
Organization: Clemson University
Date: Wed, 14 Oct 1992 12:43:24 GMT

From article <3965@wzv.win.tue.nl>, by rob@wzv.win.tue.nl (Rob J. Nauta):
> 
> But the stories told now are more folklore than real horror. Having read
> 2 Stephen Kings this weekend I beg everyone to tell more interesting
> stories, about demons, the system clock running backwards, old files
> reappearing etc !
 

Hmmm.  Maybe this is a little closer to what you're looking for...

Many years ago a tiny little college in the middle of nowhere purchased an
NCR tower, then a newfangled contraption.  A half-dozen of us were using it
for an assembly class.  The prof should have made his warnings about TRAP a
little more clear.  One student runs his program and it suddenly begans
spawning processes, rapidly filling the machine.  The prof came in, amused,
logged on as superuser, and killed a process.  Another process was
immediately spawned.  The prof tried again.  He was ignored.  He was also no
longer amused.  After several minutes he gave up and turned off the box.
The tower didn't even flinch.  He pulled the plug.  Nothing.  He ripped the
back off the box and dug around.  Finally he found the fuse and pulled it,
killing the machine.  Some of us later claimed we heard laughter as it went
down.

(Many times since then I have wished other computers came with a backup
battery as standard issue.)

--
Jeff Stehman			Systems Staff, G-18A Jordan
stehman@cs.clemson.edu		Dept. of Computer Science
(803)656-2639			Clemson University
Newsgroups: comp.unix.admin,comp.sys.sun.admin
From: mjarriel@atria.srg (Michael Jarriel x4751)
Subject: Admin/User Ratio
Organization: SRG, Arinc Research Corp., Annapolis, MD
Date: Wed, 14 Oct 92 21:19:08 GMT

I am looking for statistics or ratios that correlate
users to system administrators in a Unix based network.

10:1 20:1: 50:1 or such.  

How many would be sufficient to survive?

How many would be sufficient to be comfortable?

Are there any good articles that discuss this
topic?  If so where?

I am doing another nasty justification to management
to justify resources and could use help.

Currently we have about a 50:1 ratio and are
surviving.  I would like to get to a 25:1 position. 

Feel free to email answers to uunet!srg!mjarriel
or post if you feel it is appropriate.

I will be happy to summarize the results.

Thanks for the help.


--
Mike Jarriel
ARINC Research Inc                   mjarriel%srg@uunet.uu.net
SRG, Mail Stop 5-230                 uunet!srg!mjarriel
2551 Riva Road, Annapolis, MD 21401  410-266-4751
Newsgroups: comp.unix.admin
From: djm@eng.umd.edu (David J. MacKenzie)
Subject: Re: xargs (was: Re: WANTED: Unix administration horror stories !)
Date: Thu, 15 Oct 92 05:56:54 GMT
Organization: Project GLUE, University of Maryland
	<FISCHER.92Oct12004045@steiner.iesd.auc.dk> <168.28180@incc.com>
	<SIMON.92Oct13141339@liasg2.epfl.ch>
	<1992Oct15.025959.5659@pony.Ingres.COM>

   >    - xargs is not on all systems
   >
   >Yeah, well, neither is find I assume.  And there's always GNU xargs...

   Out of curiousity, I got out my Version 6 and Version 7 manuals.
   "find" is in both of them.  And thus it is probably in virtually every
   UNIX variant available today.  Out of curiousity too, does anyone know
   of any exceptions?

I'm sure every AT&T derived system has find.  Maybe Minix 1.0 or early
Coherents didn't (I don't know), but those are the only possible
exceptions I can imagine.

Now, some of those systems have pretty bare-bones or broken versions
of find (see comp.unix.solaris), but that's another story . . . .
Newsgroups: comp.unix.admin,comp.unix.ultrix,comp.sys.sgi,comp.unix.wizards
From: flint@cs.curtin.edu.au (Daniel Baldoni)
Subject: DAT tape compatability (DEC <-> SGI)
Keywords: DAT, DEC, Ultrix, SGI, Indigo, IRIX
Organization: Curtin University of Technology
Date: Tue, 13 Oct 1992 07:35:20 GMT

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).

I'd like to know if anybody out there has seen a similar problem.  Better yet,
can anybody solve it for me, please?  We've got other methods of transferring
this data but they're not as "pleasant" (e.g. a 2400bps link overnight).

One final note, we've successfully exchanged DAT tapes with other sites and
so has my friend's company.  So, can anybody help me help her please (it'd
do wonders for my ego <grin>)?

--
		Daniel Baldoni

--------------------------------------------+----------------------------------
Phone:    +61-9-351-7667                    | School of Computing,
InterNet: flint@cs.curtin.edu.au            | Curtin University of Technology,
--------------------------------------------+ GPO Box U1987, Perth,
#include <std/disclaimer.h>                 | Western Australia, 6001
--------------------------------------------+----------------------------------
"Depression is not a state of mind ... it's the state of Victoria!"
  - A very one-eyed Eagles' fan (me)
Xref: sparky comp.unix.admin:5663 comp.terminals:1240
From: rsoc@doc.ic.ac.uk (Rob O'Connor)
Newsgroups: comp.unix.admin,comp.terminals
Subject: Re: Leaving terminals on
Keywords: terminals
Date: 15 Oct 92 08:59:06 GMT
Organization: Department of Computing, Imperial College, University of London, UK.
NNTP-Posting-Host: swan.doc.ic.ac.uk

In article <ldkpm9INN4ho@lovelady.cs.utexas.edu> tomfox@cs.utexas.edu (Thomas Y.C. Woo) writes:
>
>I have a question regarding terminals. I have noticed that most
>terminals are always left on around the clock. I want to
>know if this is in fact better for the terminals, instead of
>turning them on and off every time they are used. By better,
>I mean for them to last longer.

The argument of whether to leave terminals on or off can be repeated ad nauseum.Speaking with modest experience, I'd say on average terminals switched off over-
night last considerably longer than ones which aren't. I'll always switch my
terminal off now. I'd also say that laser printers which are switched off over-
night need less servicing than ones which aren't.

Rob.
-- 
Internet: rsoc@doc.ic.ac.uk   Tel: +44 71 589 5111 x5070   Fax: +44 71 581 8024
Newsgroups: comp.unix.admin
From: aras@multix.no (Arne Asplem)
Subject: WANTED: Unix administration horror stories !
Organization: Multix A.S
Date: Wed, 7 Oct 1992 12:02:46 GMT

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.        

I'll summarise to the net if there is any interest.

  -- Arne
-- 
//  Arne Asplem    //  Office:    Gjerdrums vei 12, N-0486 Oslo, Norway  //
//  Multix A/S     //  Phone/fax: +47-2-950800 / 950790                  //
//                 //  Email:     aras@multix.no                         //
//  NUUG Chairman  //  Email:     aras@nuug.no                           //
Newsgroups: comp.unix.admin
From: jd@mars.nwc.navy.mil (John de la Garrigue)
Subject: Re: How do I stop an annoying user?
Reply-To: jd@mars.nwc.navy.mil
Organization: Science Applications International Corporation
Date: Thu, 15 Oct 1992 16:41:00 GMT

In article 6487@zoo.bt.co.uk, gah@zoo.bt.co.uk (Geoff Hopson) writes:
>A little help from you system admin men is required.
>
>I am suffering with a user who keeps logging onto my machine and playing around. Short of giving him a good kick up the arse,

Not a bad way of handling the problem, but try to be a little more diplomatic first :)

> is there anything I can do to prevent him logging on. This user has been on a Sun system administrators course, and has been told various ways of logging onto other peoples machines. 

There's not much worse than someone with a little knowledge, and no common sense.
I assume you have root access to your machine?  If so, you could try a cron job that
looks for this clown's user id (ps -auxww | grep <loginid>, or a variation) on a 
periodic basis.  Or, look for him when you notice the system acting funny.  Once
you find him, kill all his processes.  Ftp a copy of "cops" and run it on your
system - this will show you where potential security holes are, and you can decide
whether or not to plug them up.  Change your password frequently, particularly if
this individual is getting in to root (what a nightmare!).  Document every instance
of this person breaking in to your system, and send an appropriate memo for record
to him, the system administrator, your boss, his boss, the director of data processing,
his boss, etc.  I would suggest you not treat this as a minor annoyance - this
person can potentially cause your system/data great damage, which could have
devastating consequences (depending on the nature of your job, of course).  Also, if 
this person is breaking in, you are open to other, potnetially more damaging, attacks.
This is not a complete list, but I'm sure others will chime in soon.

>Our system manager says there is no way to stop a determined user.

Your system manager is correct, in a sense; however, since you know who this guy is,
and you work at the same place, your management should be able to take appropriate
sanctions.  Tell your system manager to get off his butt and do something!

> There must be a way to stop him. He has been logged on as a root user, on as me, etc etc. I have tried .rhosts, /etc/hosts.equiv,
>passwd entries, all to no avail.
>
>I assume I will need a script or program of some description. Hints, tips and general advice gratefully received.
>
>Please e-mail.
>
>Thanks in advance
>
>"Annoyed"

Hope this helps a little.  Good luck.

---
John de la Garrigue - SAIC   ||  Obligatory disclaimer:
jd@archimedes.nwc.navy.mil   ||   "I have no clear recollection of
                             ||    the events you are referring to."

Newsgroups: comp.unix.admin,comp.sys.sun.admin
From: walt@diusys.cms.udel.edu (Walt Dabell)
Subject: TIMEZONE Question
Keywords: timezone
Reply-To: walt@diusys.cms.udel.edu
Organization: U of Delaware, College of Marine Studies / Lewes
Date: Tue, 13 Oct 1992 21:24:15 GMT

Got a quick question to which I need a quick reply...

I am going to be using a machine in one timezone and need to coordinate the
updates to a db (ingres) on a machine in another timezone. I was going to
put them both on GMT, but after reading some documentation I have come to
the assumption I dont need to, that UNIX will take care of timezone conversions
for the file creation dates. Is this right or should I put them both on GMT??? 

If it makes any difference, one machine will be in Australia and the other
in Delaware (ie. international date line crossing).

---
         __________________________________________________________
         Walt Dabell  KD3GS (302)645-4225  walt@diusys.cms.udel.edu  
                  U of Delaware / College of Marine Studies
                      700 Pilottown Rd. Lewes, DE 19958

Newsgroups: comp.unix.admin
From: root@trebor.uucp (Bob Stockler)
Subject: Re: EXABYTE Tape costs
Organization: Bob Stockler
Date: Wed, 07 Oct 1992 02:07:15 GMT

fmt@mbf.UUCP (Mike Trimberger) writes:

>                            And yes, as described previously in these
>hallowed halls of Usenet, there is a manufacturing difference in both
>the case and the tape itself between Video- and Data-grade tapes.  

I'm not a natural born cynic, but the "manufacturing difference" that makes
the most sense, from the manufacturer's point of view, is that different
packages should be used to contain the *same* basic product.

Consider making 3.5" diskettes.  Isn't it more economical to produce one
category of media, and then enclose it in squares of plastic with an extra
hole or not, according to the volume of one or the other type required to
supply forecast sales demand?

Disclaimer:  this only applies to manufactures as enlightened as I am.

Newsgroups: comp.unix.admin
From: root@rulcvx.LeidenUniv.nl (root)
Subject: Re: WANTED: Unix administration horror stories !
Organization: CRI, institute for telecommunication and computerservices.
Date: Thu, 15 Oct 92 15:40:30 GMT

In article <64@ocdis01.UUCP> robjohn@ocdis01.UUCP (Contractor Bob Johnson) writes:
>Another horror story (mine this time)...

>Cleaning out an old directory, I did 'rm *', then noticed several files
>that began with dot (.profile, etc) still there.  So, in a fit of obtuse
>brilliance, I typed...

>    rm -rf .* &

Well, waddya know...  Some half hour ago, coming back from root (I was
installing m4 on our system) [Shit, all my neato emacs tricks won't
work.  Damn, damn, damn kill, kill, KILL] to my own userid, I got this
little message: "Can't find home directory /mnt0/crissl." and an
other: "Can't lstat .".  [Grrrrr, ^S and ^Q haven't been remapped...]

Guess what happened, not an hour ago...  A collegue of mine was emptying
some directories of computer-course accounts.  As I did a "ps -t" on
his tty, what did I see?  "rm -rf .*"

Well, I'm not alone, he got sixteen other homedirectories as well.
And guess what filesystems we don't make incremental backups of...
And why not?  Beats me...

I haven't killed him yet, he first has to restore the lot.

And for those "touch \-i" fans out there: you wouldn't have been
protected...

Boy, am I MAD. :-)  (Bitten by the bug I, too, once released.)

Stefan "where can I find a well-equipped torture chamber" Linnemann
-- 
Newsgroups: comp.unix.admin,alt.folklore.computers
From: peter@NeoSoft.com (Peter da Silva)
Subject: Re: WANTED: Unix administration horror stories !
Organization: NeoSoft Communications Services -- (713) 684-5900
Date: Mon, 12 Oct 1992 11:54:15 GMT

Well, we had one system on which you couldn't log in on the console for a
while after rebooting, but it'd start working sometimes. What was happening
was that the manufacturer had, for some idiot reason, hardcoded the names
of the terminals they wanted to support into getty (this manufacturers own
terminals, that I can understand, but also a handful of common types like
adm3a) so getty could clear the screen properly (I guess hacking that into
gettydefs was too obvious or something). If getty couldn't recognise the
terminal type on the command line, it'd display a message on the console
reading "Unknown terminal type pc100". We ignored this flamage, which was
a pity. Cos that was the problem.

It did this *before* opening the terminal, so if it happened to run between
the time rc completed and the getty on the console started the console got
attached to some random terminal somewhere, so when login attempted to open
/dev/tty to prompt for a password it failed.

Moral: always deal with error messages even when you *know* they're bogus.
Moral: never cry wolf.
-- 
Peter da Silva.  <peter@sugar.neosoft.com>.
 `-_-'   "Segodnja volka obnimal?"
  'U`  
Dette kan umulig vaere mitt rom, eftersom jeg ikke puster ammoniakk.
Xref: sparky comp.unix.admin:5626 alt.folklore.computers:15121
From: dvsc-a@minster.york.ac.uk
Newsgroups: comp.unix.admin,alt.folklore.computers
Subject: Re: WANTED: Unix administration horror stories !
Date: 14 Oct 92 10:20:41 GMT
Reply-To: dvsc-a@minster.york.ac.uk (DWJ Stringer-Calvert )
Organization: Department of Computer Science, University of York, England

I remember my first (and only, so far) major mistake in unix
admin:

I was changing the UIDs of a few users on one of our major
servers, due to a clash with some machines newly connected to the
net. Fine, edit /etc/passwd then chown all their files to the new
UID. So, rather than just assume that all files owned by "fred"
live in /home/machine/fred I did this:

machine# find / -user old_uid -exec chown username {} \;

This was fine... except it was late at night and I was tired, and
in a hurry to get home. I had six of these commands to type, and
as they would take a long time I'd just let them run in the
background over night.....

So, you come in the next morning and a user compains... I can't
login to the 4/490 - it says "/bin/login: setgid: not owner". 

Okay.... naive user problem no?

rlogin machine -l root
/bin/login: setgid: not owner

machine console
login: root
/bin/login: setgid: not owner

Okay - I REALLY can't get in... lets reboot single user and see
whats on... this worked. /bin/login is owned (and setuid to) one
of the users whos UID I changed the previous day... infact ALL
FILES in the ENTIRE filesystem are owned by this user..problem!

We `only' lost about 200 man hours through my little typing 
mistake: the moral of the story..  beware anything recursive
when logged in as root!

find / -exec chown user {} \;

Oh dear...


Dave
From: sam@bsu-cs.bsu.edu (B. Samuel Blanchard)
Newsgroups: comp.unix.admin
Subject: Re: Limiting the use of specific commands
Date: 12 Oct 92 20:01:31 GMT
Organization: Dept. of CS Ball State University Muncie IN

In article <59@ocdis01.UUCP> robjohn@ocdis01.UUCP (Contractor Bob Johnson) writes:
>>We would like to be able to limit the usage of specific commands on the
>>Brenda Parsons

>We create a group that contains the users who can access that program,
>[..]AT&T-type unix, the user will have [..] to do a newgrp
>Bob Johnson

I have created scripts in /usr/local/bin which issue the newgrp and then the
program with all args.  This has worked well but some may complain about
efficiency.  You could exec the command but I never did.


-- 
B. Sam Blanchard        sam@bsu-cs.bsu.edu
418 Winfield Dr         (317) 284-7131   work
Greenfield, IN 46140
Xref: sparky comp.unix.admin:5460 comp.unix.shell:4253
From: friedman@gnu.ai.mit.edu (Noah Friedman)
Newsgroups: comp.unix.admin,comp.unix.shell
Subject: Re: Rm protection (was: Why I am glad I know perl)
Date: 9 Oct 92 05:02:52 GMT
	<1992Oct7.165640.22661@news.eng.convex.com>
	<1992Oct8.005319.12539@Princeton.EDU>
Followup-To: comp.unix.admin
Organization: Free Software Foundation, 675 Mass Ave. Cambridge, MA 02139
In-reply-to: spencer@phoenix.Princeton.EDU's message of 8 Oct 92 00:53:19 GMT

Incidentally, for you bash fanatics out there, I wrote some stuff to
emulate the `rmstar' feature in tcsh.  I haven't tested this too much
because I don't use it---I'm of the philosophy that you simply shouldn't
use rm carelessly.  However, other people might find it useful. 

To use this, you have to load it (because of the unusual nature of this
implementation, autoloading it doesn't work) AND you have to set the
`rmstar' shell variable.  Unsetting it will turn off checking again.

Enjoy.

# rmstar, 15-Jul-92 Noah Friedman <friedman@prep.ai.mit.edu>
# bash version
#
# Public domain.
#

# TODO: finish documenting

#:docstring rmstar:
# I highly recommend people not use this. 
#:end docstring:

alias rm='flags="$-"; set -f; rmstar "${flags}"'

function rmstar ()
{
 local flags="$1"
 local arg

    shift;
   
    # Only re-enable globbing if it was enabled before. 
    if [ "$(set +f; echo $-)" = "${flags}" ]; then
       set +f
    fi

    if [ "${rmstar+set}" = "set" ]; then
       for arg in "$@" ; do
          if [ "z${arg##*/}" = "z*" ]; then
             dir=${arg%/*};
             if [ "${dir}" = "${arg}" ]; then
                dir="current directory"
             fi
             if ! y_or_n_p "Remove all files in ${dir} (y/n)? "
             then
                echo "rm aborted: no files deleted." 1>&2
                return 1
             fi
          fi
       done
   fi

   command rm $*
}

#:docstring y_or_n_p:
# Usage: y_or_n_p QUERY
#
# Print QUERY on stderr, then read stdin for a y-or-n response.  Actually,
# user may type anything they like, but first character must be a `y' or
# `n', otherwise the question is repeated until such an answer is obtained. 
# Return value is 0 if y, 1 if n. 
#:end docstring:
function y_or_n_p ()
{
 local ans

    if [ -t 0 ]; then
       while : ; do
          echo -n "$*" 1>&2
          read ans
          case "${ans}" in
             y* | Y* )
                return 0
               ;;
             n* | N* )
                return 1
               ;;
             *)
                echo 'Please answer "y" or "n"' 1>&2
               ;;
          esac
       done
    else
       return 1
    fi
}

Newsgroups: comp.unix.admin