postmaster@urbana.mcd.mot.com (07/11/89)
The enclosed mail message was addressed to a system which is no longer
in service. We have attempted to forward your mail to the correct
recipient(s). If this is not possible, you will recieve additional
mail at the time of failure.
In the future, please use the system name "urbana.mcd.mot.com" instead.
Please correct any mailing lists or alias files that may reference
any of the following obsolete system names:
xenurus.gould.com
fang.gould.com
fang.urbana.gould.com
vger.urbana.gould.com
ccvaxa.gould.com
ccvaxa.urbana.gould.com
burt.urbana.gould.com
mycroft.urbana.gould.com
If you have any further problems or questions about mail to this site,
please contact postmaster@urbana.mcd.mot.com.
thank you for your cooperation,
postmaster@urbana.mcd.mot.com
Motorola Microcomputer Division, Urbana Design Center
---------- text of forwarded message:
Received: from sem.brl.mil by placebo (5.61/1.34)
id AA01830; Sat, 8 Jul 89 00:54:08 -0500
Received: by SEM.BRL.MIL id aj00393; 8 Jul 89 2:01 EDT
Received: from SEM.BRL.MIL by SEM.brl.MIL id aa06686; 7 Jul 89 3:00 EDT
Received: from sem.brl.mil by SEM.BRL.MIL id aa06644; 7 Jul 89 2:45 EDT
Date: Fri, 07 Jul 89 02:45:24 EST
From: The Moderator (Mike Muuss) <Unix-Wizards-Request@BRL.MIL>
To: UNIX-WIZARDS@BRL.MIL
Reply-To: UNIX-WIZARDS@BRL.MIL
Subject: UNIX-WIZARDS Digest V7#122
Message-Id: <8907070245.aa06644@SEM.BRL.MIL>
UNIX-WIZARDS Digest Fri, 07 Jul 1989 V7#122
Today's Topics:
Re: UUCP to Xenix site (long)
STREAMS splstr()
rsh fails with "accept: too many open files"
chown (was: at files and permissions)
Re: chown (was: at files and permissions)
Re: Troff or pscat ?
Using the uucp daemon (TCP/IP) on System V.3 with TCP/IP
Re: Using the uucp daemon (TCP/IP) on System V.3 with TCP/IP
local test
Re: Do you know about C-Tree ?
Re: at files and permissions
Convert string time into seconds?
Sun calctool
Algorithm needed: reading/writing a large file
Re: Information on `TUNEX' kernel tuning program
Re: Should "ls -R" traverse symlinks?
Re: Environment variables at login
Re: Cartridge tape stuff
Security
-----------------------------------------------------------------
From: "Bruce A. Yanagida" <yanagida@ole.uucp>
Subject: Re: UUCP to Xenix site (long)
Date: 5 Jul 89 19:15:56 GMT
Keywords: UUCP, Xenix
To: unix-wizards@sem.brl.mil
Thanks to all who responded to my problem about connecting from a
Berkeley UNIX site to a Xenix site. I have it working reliably now.
Basically, my problem was that my UUCP defaults to even parity, while
Xenix systems require zero parity. Therefore, all I needed to do was
use P_ZERO in my L.sys line for the Xenix site.
--
Bruce A. Yanagida (UUCP: ...!uw-beaver!sumax!ole!yanagida)
Seattle Silicon Corporation
3075 112th Ave NE
Bellevue, WA 98004 (206)-828-4422
-----------------------------
From: Erik Murrey <erik@mpx2.mpx.com>
Subject: STREAMS splstr()
Date: 6 Jul 89 01:04:45 GMT
To: unix-wizards@sem.brl.mil
I see in streams.h for the 3b2 that splstr() is at spltty(). Does
this mask out calls to timeout() routines? If not, then what is the
appropriate level for a critical section of code that a timer routine
modifies?
I know this is RTFM, but I don't have the $200 set of device driver
guides.
E-mail, please. If anyone else wants to know, then mail me.
Thanks!
... Erik
--
Erik Murrey /| // /~~~~/ | /
MPX Data Systems, Inc. / | / / /____/ |/
erik@mpx.com / / / / /| Data Systems, Inc.
{vu-vlsi, bpa, cbmvax}!mpx1!erik / / / / |====================
-----------------------------
From: Edward Vielmetti <emv@math.lsa.umich.edu>
Subject: rsh fails with "accept: too many open files"
Date: 6 Jul 89 04:04:26 GMT
Sender: usenet@math.lsa.umich.edu
UUCP-Path: {mailrus,umix}!um-math!emv
To: unix-wizards@sem.brl.mil
rsh is dying on me with this error message. It appears to
be a problem on the local end (in this case euterpe) because
no matter where I rsh something the same error message.
(Sun 3/160, SunOS 3.5, and yp master).
/etc/pstat -T shows the 'inodes' at 226/226, so presumably that
has something to do with it; I confess the rest of the output
from pstat is rather uninformative to me. Other things seem
to work fine, and I can telnet and ftp OK.
euterpe% rsh urania echo foo
accept: Too many open files
--Ed
-----------------------------
From: Chris Torek <chris@mimsy.uucp>
Subject: chown (was: at files and permissions)
Date: 6 Jul 89 04:25:38 GMT
To: unix-wizards@sem.brl.mil
>In article <8072@bsu-cs.bsu.edu> dhesi@bsu-cs.bsu.edu (Rahul Dhesi) writes:
>>... BSD allows only root to change file ownership.
In article <4884@ficc.uu.net> peter@ficc.uu.net (Peter da Silva) writes:
>I certainly hope that V.4 doesn't have this *bogus* restriction.
The restriction is not bogus, because the system supports disk quotas.
If you could give away your own files, you could:
mkdir .hide; chmod 700 .hide
chdir .hide
create_huge_file >foo
chown prof1 foo
create_huge_file >bar
chown prof2 bar
create_huge_file >baz
chown prof3 baz
All you need do is find someone with a high quota or no quota (such
as a professor) who does not often check his own usage (such as a
professor) and probably does not care that the disk is 99% full (such
as a, er, well, never mind :-) ), and then give away files as necessary
to keep under your own quota. You can regain ownership of the file by
copying it to another disk partition, removing the original, and copying
it back.
--
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163)
Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris
-----------------------------
From: RAMontante <bobmon@iuvax.cs.indiana.edu>
Subject: Re: chown (was: at files and permissions)
Date: 6 Jul 89 13:22:51 GMT
To: unix-wizards@sem.brl.mil
->>... BSD allows only root to change file ownership.
-
->I certainly hope that V.4 doesn't have this *bogus* restriction.
-
chris@mimsy.UUCP (Chris Torek) <18414@mimsy.UUCP> :
-The restriction is not bogus, because the system supports disk quotas.
- [ . . . ]
-All you need do is find someone with a high quota or no quota (such
-as a professor) who does not often check his own usage (such as a
-professor) and probably does not care that the disk is 99% full (such
There are also many potential problems from hostile users (generally
undergraduates) --- consuming someone else's quota can break their
running program, make them miss an assignment deadline, etc. Putting
obscene or incriminating material in someone else's file system and then
"turning them in" can do some real *major* damage.
Hope I haven't inspired anyone with this...but hey, I prefer BSD anyway.
-----------------------------
From: Peter da Silva <peter@ficc.uu.net>
Subject: Re: chown (was: at files and permissions)
Date: 6 Jul 89 13:48:02 GMT
To: unix-wizards@sem.brl.mil
In article <8072@bsu-cs.bsu.edu> dhesi@bsu-cs.bsu.edu (Rahul Dhesi) writes:
>... BSD allows only root to change file ownership.
In article <4884@ficc.uu.net> peter@ficc.uu.net (Peter da Silva) writes:
>I certainly hope that V.4 doesn't have this *bogus* restriction.
In article <18414@mimsy.UUCP>, chris@mimsy.UUCP (Chris Torek) writes:
> The restriction is not bogus, because the system supports disk quotas.
This assume that disk quotas are not bogus in a production environment.
That is, outside a university... anyway, I'll rephrase my comment:
I certainly hope that V.4 does not impose this bogus restriction if you
choose to not make use of disk quotas. I also hope that V.4 doesn't enforce
the other bogus restrictions I remember from my years at Berkeley.
They didn't call it the "fascist file system" for nothing.
[ Pardon my language, but I just saw Bill and Ted's Excellent Adventure ]
--
Peter da Silva, Xenix Support, Ferranti International Controls Corporation.
Business: peter@ficc.uu.net, +1 713 274 5180. | "Bad K&R! Bad!"
Personal: peter@sugar.hackercorp.com. `-_-' | -- C. Harald Koch
Quote: Have you hugged your wolf today? 'U` | (chk@dciem.dnd.ca)
-----------------------------
From: Doug Gwyn <gwyn@smoke.brl.mil>
Subject: Re: chown (was: at files and permissions)
Date: 6 Jul 89 21:13:19 GMT
To: unix-wizards@sem.brl.mil
In article <18414@mimsy.UUCP> chris@mimsy.UUCP (Chris Torek) writes:
>>In article <8072@bsu-cs.bsu.edu> dhesi@bsu-cs.bsu.edu (Rahul Dhesi) writes:
>>>... BSD allows only root to change file ownership.
>In article <4884@ficc.uu.net> peter@ficc.uu.net (Peter da Silva) writes:
>>I certainly hope that V.4 doesn't have this *bogus* restriction.
>The restriction is not bogus, because the system supports disk quotas.
So now the issue becomes: Is the BSD disk quota system bogus?
Having had it break things I was doing, I hollered loudly enough
that the system administrator who had decided to give me a finite
quota changed it back to infinite. Not only does an enforced
quota suffer from the same problems as the System V "ulimit", but
messages generated by the system to the "appropriate" interactive
terminal to warn you that you're approaching your quota can cause
all sorts of damage, especially if your "terminal" is a
communication channel, not a human-oriented device. (5620 DMD or
630 MTG users should recognize the problem.)
There seem to me to be two valid services that can be performed
by a disk "quota" system. One of them is to prevent runaway disk
consumption such as
cat x >> x
and the other is to keep users from accumulating junk that fills
the available disk. The first problem is dealt with adequately
by a resource limit mechanism a la ulimit, or more reliably by a
"dynamic" quota monitor attached to the specific session. The
second problem can be dealt with administratively, with periodic
use of "du|sort -rn" to find where the problems are. Realistic
long-term storage quotas really have to be negotiated between the
users and the system administrator anyway. These methods of
providing disk quota services do not encounter the scenario that
you described for the UID-based quota scheme when the file owner
is allowed to chown his own file.
Most of my use of "su" on our BSD-based systems is simply to chown
files. That is indicative of a serious deficiency in normal user
services on these systems. I would install a set-UID 0 "chown"
(with appropriate checks) except for the hassle I'd get from the
system admins around here.
-----------------------------
From: Dick Dunn <rcd@ico.isc.com>
Subject: Re: Troff or pscat ?
Date: 6 Jul 89 06:05:45 GMT
To: unix-wizards@sem.brl.mil
In article <2209@astroatc.UUCP>, ttl@astroatc.UUCP (Tony Laundrie) writes:
[troff example input deleted; consider the PostScript output...]
> 2281(a)S
> 2330(test)S
> 2436(of)S
> 2508(the)S
> 2604(emergenc)S <<< How can I prevent this type of word separation
> 2839(y)S <<< from occuring? Is it troff or pscat that is
> 2891(broadcast)S causing the problem?
It's not a problem. Troff is positioning output as it believes it should.
Pscat is gathering the output and turning it into PostScript as best it
can. When pscat finds that after one character is output, the new position
is the same as the explicit position of the next character, it combines the
two characters and outputs them with a single call (ultimately in a single
"show"). This collection goes on as long as the implicit motion from
character widths matches the explicit positioning of characters. The
savings in the size of the PostScript file from this straightforward opti-
mization is enormous--note that the overhead per string is 8 bytes.
It is almost fortuitous (?!) that the coalescing usually joins words back
together--but this is by no means guaranteed. For various reasons, not all
words get rejoined, nor should you expect them to be. If you're trying to
find "words" in the pscat output, you're probably going at things in a very
wrong way--what you're seeing is only character sequences which were caught
by pscat's coalescing algorithm. (The same thing will happen with psroff =
ditroff + psdit, although the circumstances are different.) In particular,
any situation which causes troff to think the natural spacing of characters
should be different from PostScript font widths will cause the splitting
you see. Possible factors (speaking generally) include pair kerning,
differing ideas of character widths in troff and the back end, and rounding
errors in width calculations.
If you need to find "words", look for them far upstream, in the input to
troff.
--
Dick Dunn rcd@ico.isc.com uucp: {ncar,nbires}!ico!rcd (303)449-2870
...Simpler is better.
-----------------------------
From: Jos Vos <jos@idca.tds.philips.nl>
Subject: Using the uucp daemon (TCP/IP) on System V.3 with TCP/IP
Date: 6 Jul 89 06:28:41 GMT
Keywords: UUCP TCP/IP uucpd uucico sockets BSD4.3 SysV.3
To: unix-wizards@sem.brl.mil
Does anybody use the BSD4.3 uucpd daemon on System V.3 systems with some
TCP/IP implementation with sockets (I use Wollongong's implementation) ?
I want to use it for running UUCP (for upwards compatibility) over a
wide-area company TCP/IP network, where remote login can't be done
for security reasons.
Please mail/post experiences with:
- The porting problems (if any) with uucpd from BDS4.3.
- The porting problems with AT&T's V.3 uucico (I know the TCP/IP socket
support is in the code between BSD?? #ifdef's).
- Any other problem I overlooked...
Patches are of course appreciated :-)
--
-- ###### Jos Vos ###### Internet jos@idca.tds.philips.nl ######
-- ###### ###### UUCP ...!mcvax!philapd!jos ######
-----------------------------
From: Hwajin Bae <hwajin@wrswrs.wrs.com>
Subject: Re: Using the uucp daemon (TCP/IP) on System V.3 with TCP/IP
Date: 6 Jul 89 18:28:19 GMT
Keywords: UUCP TCP/IP uucpd uucico sockets BSD4.3 SysV.3
To: unix-wizards@sem.brl.mil
In article <1126@ssp15.idca.tds.philips.nl> jos@idca.tds.PHILIPS.nl (Jos Vos) writes:
>Please mail/post experiences with:
>- The porting problems (if any) with uucpd from BDS4.3.
>- The porting problems with AT&T's V.3 uucico (I know the TCP/IP socket
> support is in the code between BSD?? #ifdef's).
>- Any other problem I overlooked...
HDB UUCP that comes with AT&T V.3.2 UNIX includes support for TLI, TLIS, and
socket interfaces to TCP/IP connections. Using existing TLIS (TLI STREAMS
Based) code, all you need is to set up listener service database to invoke
uucico when a request comes in from a remote TCP/IP host. This is only useful
if you have another machine with TCP/IP, TLI, and equivalent UUCP.
Porting BSD 4.3 UUCP daemon has already been done several times for different
incarnations of TCP/IP implementations for system V Unix's. Unfortunately
none of them are "free" that I know of.
--
Hwa-jin Bae
hwajin@wrs.com ( a.k.a. {uunet,rtech,sun}!wrs!hwajin )
bae@tis.llnl.gov (Internet) 415/832-2926
Wind River Systems, 1351 Ocean Ave, Emeryville, CA 94608 415/428-2623
-----------------------------
From: system@bsu-ucs.uucp
Subject: local test
Date: 6 Jul 89 12:03:42 GMT
To: unix-wizards@sem.brl.mil
local test - I hope.
-----------------------------
From: John Kjellman <kjohn@richsun.uucp>
Subject: Re: Do you know about C-Tree ?
Date: 6 Jul 89 15:35:55 GMT
Expires: 20 Jul 89 05:00:00 GMT
Keywords: c-tree, 1984 FairCom
To: unix-wizards@sem.brl.mil
To all who responded to my C-Tree question:
(uccjcm@ecsvax.uncecs [John McLendon],
jfh@rpp386.Cactus.ORD [John F. Haugh II],
terryn@prcrs [Terry Neely],
benah@adspp [Benjamin A. Hunsberger],
larrydl@killer [Larry Clark],
friedl@vsi [Steve J. Friedl],
hwh@cup.portal.com [Hank Hankins],
jeff@cdp [Jeff ?*],
mgardi@watdcsu [Joe deSousa],
mark@intek01 [Mark McWiggins],
erlebach@utcsri [Beverly Erlebacher],
bmadhyan@doctor [Bharat Madyani],
limonce@pilot.njin.net [Tom Limoncelli],
jb@aablue [John B Scalia])
THANKS A LOT, your efforts are much appreciated !
To summarize the responses:
C-Tree is a B+ Tree file handling package. It has two levels of
interfaces, the low-level B+ Tree stuff and the high level ISAM
method (Indexed Sequential Access Method). Everyone that has used
it loves it (it's fast, highly portable, and comes with source code
for $395). Also available is an SQL interface, a report generator,
and a programmers tool kit. See FairCom for details:
FairCom Corporation
4006 W. Broadway
Columbia Missouri 65203
Tel: (314)445-6833
FAX: (314)445-9698
KJohn
P.S.
Apparently I am the only person on the net that didn't know
what C-Tree is......
P.P.S.
#include <std_disclaimer> /* I am in no way associated with FairCom *
* Corp, just a nosy consultant :-) */
--
| Only /// | #include <std/disclaimer> /*KJohn - The man without an Amiga*/ |
| Amiga \XX/ | kjohn@richp1 or [ purdue | cs.ubc | mcdchg ] ! richp1 ! kjohn |
-----------------------------
From: Peter da Silva <peter@ficc.uu.net>
Subject: Re: at files and permissions
Date: 6 Jul 89 16:13:05 GMT
To: unix-wizards@sem.brl.mil
In article <8092@bsu-cs.bsu.edu>, dhesi@bsu-cs.bsu.edu (Rahul Dhesi) writes:
[no disk quotas in V.3]
> I said:
> ...BSD allows only root to change file ownership.
> In article <4884@ficc.uu.net> peter@ficc.uu.net (Peter da Silva) writes:
> > I certainly hope that V.4 doesn't have this *bogus* restriction.
> I doubt that it will need to.
I hope you're right. But remember that V.4 is supposed to be V.3+BSD.
Does anyone here really know what sort of crud V.4 (not V.3) is going to
have in it? Streams *and* sockets, or so I hear...
--
Peter da Silva, Xenix Support, Ferranti International Controls Corporation.
Business: peter@ficc.uu.net, +1 713 274 5180. | "Arrrrggggh!
Personal: peter@sugar.hackercorp.com. `-_-' | Electronic mail sucks eggs."
Quote: Have you hugged your wolf today? 'U` | -- eugene miya
-----------------------------
From: Uri Blumenthal <uri@arnor.uucp>
Subject: Re: at files and permissions
Date: 6 Jul 89 16:17:56 GMT
To: unix-wizards@sem.brl.mil
From article <8072@bsu-cs.bsu.edu>, by dhesi@bsu-cs.bsu.edu (Rahul Dhesi):
>
> When you discuss a security problem that is specific to System V,
> please be sure to say so clearly, else you may confuse naive users.
First of all, not everybody familiar with System V, knows exactly which
features of BSD (and what version!) it has or has not. So, for example,
I didn't know that you can do "chown" only being root (and I consider it
rather STUPID - System V solved this security hazard a lot nicer: it just
clears all sticky bits!). Even wizards don't have to be familiar with all
the flawors of UNIX (or tomorrow somebody will come up and say, like
"but on my HP/UX it's different", or "on my A/UX", or whatever boo you
can find today.
Uri.
-----------------------------
From: clewis@eci386.uucp
Subject: Re: at files and permissions
Date: 6 Jul 89 20:47:10 GMT
To: unix-wizards@sem.brl.mil
In article <8072@bsu-cs.bsu.edu> dhesi@bsu-cs.bsu.edu (Rahul Dhesi) writes:
>In article <669@lzaz.ATT.COM> hutch@lzaz.ATT.COM (R.HUTCHISON) writes:
>>If I wanted to be sneaky (and if "at" wasn't very smart), I could submit
>>a "nasty" at job, go to the spool directory, and change the file's owner
>>id to a target login and "at" would do the nasty to that login.
>The above problem does not occur in BSD, because BSD allows only root
>to change file ownership.
1) it isn't a problem in SV, 'cause at won't run it. Like he said.
Because, even though you can chown a file away from yourself,
at will insist that the setuid bits are set before believing
the ownership of the file. And, when you chown, the setuid
bits are turned *off*. And you can't turn 'em on once you've
given the file away.
2) BSD *does* allow you to give files away. It turns off the
setuid bits too. If it doesn't work on your system, obviously
someone disabled it for accounting reasons.
>When you discuss a security problem that is specific to System V,
>please be sure to say so clearly, else you may confuse naive users.
It wasn't necessary for him to say so, because it *isn't* a security problem.
"at" needs setuid root permissions so that it can write in the cron/at
spool directories. In SVR3, there's no specific utility to run the "at" jobs,
they seem to be simply shovelled into cron.
--
Chris Lewis, R.H. Lathwell & Associates: Elegant Communications Inc.
UUCP: {uunet!mnetor, utcsri!utzoo}!lsuc!eci386!clewis
Phone: (416)-595-5425
-----------------------------
From: Guy Harris <guy@auspex.auspex.com>
Subject: Re: at files and permissions
Date: 6 Jul 89 22:11:53 GMT
To: unix-wizards@sem.brl.mil
> I doubt that it will need to.
Considering the BSD file system in S5R4 is intended to have support for
disk quotas, then yes, it *will* need to permit you to disallow giving
away files. It will probably be a configuration option.
-----------------------------
From: Doug Toppin <toppin@melpar.uucp>
Subject: Convert string time into seconds?
Date: 6 Jul 89 17:42:44 GMT
Keywords: time
To: unix-wizards@sem.brl.mil
I have a user entered time/date in the format:
yymmddhhmmss
I need to convert this into seconds since the epoch and
can't find a reference anywhere. If anyone knows how
please let me know. I can't change the system time and
then ask it what the time is in seconds.
Doug Toppin
uunet!melpar!toppin
-----------------------------
From: Dominick Samperi <samperi@marob.masa.com>
Subject: Sun calctool
Date: 6 Jul 89 18:16:22 GMT
Keywords: calctool lost
To: unix-wizards@sem.brl.mil
Would somebody please send me a copy of the calctool posting that appeared
recently in comp.sources.sun, or let me know where I can find a copy? I
lost my copy due to a bad backup/restore. (I would have posted this to
comp.sys.sun, but this site has trouble posting to moderated groups.)
Thanks!
--
Dominick Samperi -- ESCC
samperi@marob.masa.com
uunet!hombre!samperi
-----------------------------
From: Jeffrey W Percival <jwp@larry.sal.wisc.edu>
Subject: Algorithm needed: reading/writing a large file
Date: 6 Jul 89 18:16:29 GMT
To: unix-wizards@sem.brl.mil
I am writing a C program (Ultrix, VAXstation 2000) to re-arrange a
large disk file. The file contains a large number of fixed length
records. My current method is this: read through the file, building 2
arrays in memory: array1 is an array of some attribute I want to sort
on, and array2 is just array of ascending integers (record numbers in
the first file). Then I sort array1, with array2 tracking the
movements in array1. I end up with array2 being a mapping of record
numbers between the input file and the sorted file. Finally, I loop
through array2 doing a read on file1, record array2[i] and writing to
file2, record i.
Now, I'm not looking for help in the sorting of array1; my sorting
algorithm is fast and efficient. What is taking a long time are the
quasi-random seeks in file1 as file2 is sequentially built.
I cannot have all of file1 in memory, but can have more than the one
record I am currently using in this shuffle. How can I speed this up?
--
Jeff Percival (jwp@larry.sal.wisc.edu)
-----------------------------
From: Ken Burch <ntm1836@dsacg1.uucp>
Subject: Re: Information on `TUNEX' kernel tuning program
Date: 6 Jul 89 18:59:38 GMT
To: unix-wizards@sem.brl.mil
In article <1144@vsi.COM> friedl@vsi.COM (Stephen J. Friedl) writes:
} The latest IEEE Transactions on Software Engineering (Jul
} 1989) has an article "TUNEX: A Knowledge-Based System for
} Performance Tuning of the UNIX Operating Sysem" by Behrokh Samadi
} from AT&T Bell Labs. [...]
How would one go about getting a copy of this publication?
--
Ken Burch 614-238-5852 | ntm1836@dsacg1.dla.mil
DLA Systems Automation Center | or
Columbus, OH | ...!osu-cis!dsacg1!ntm1836
-----------------------------
From: Doug Gwyn <gwyn@smoke.brl.mil>
Subject: Re: Should "ls -R" traverse symlinks?
Date: 6 Jul 89 21:23:57 GMT
Keywords: symlink, find
To: unix-wizards@sem.brl.mil
In article <12377@bloom-beacon.MIT.EDU> scs@adam.pika.mit.edu (Steve Summit) writes:
>There's no doubt that symlinks are useful, but it's discouraging
>how many propagating difficulties they introduce. ...
>However, for good reasons or ill, it seems that nearly every
>program that calls stat(2) now wants to special-case ST_IFLNK.
Yes -- as a case in point, the BRL UNIX System V emulation for 4.nBSD
initially always traversed symlinks, because System V at the time didn't
have symlinks and the simplest emulation was to treat them transparently.
As I found problems applying the System V utilities with that behavior to
actual instances of symlinks on our systems, I gradually added more and
more special-casing, or in some cases options, to the utilities, just as
you indicated. It's one of the things that led me to conclude that
symlinks weren't sufficiently elegant to include in the "ultimate"
operating system (whatever that may be).
-----------------------------
From: Guy Harris <guy@auspex.auspex.com>
Subject: Re: Environment variables at login
Date: 6 Jul 89 22:25:57 GMT
Keywords: environment login
To: unix-wizards@sem.brl.mil
>And now my question for the wizards: will the problem of setting up an
>uniform process environment for any interactive and/or non-interactive
>use be solved in a more elegant fashion in SysVR5 or in some BSD
>version?
S5R3.1 already has a mechanism to do that - you put entries of the form
VARIABLE=value
in "/etc/TIMEZONE" (a comment in the code says the name should be
changed in S5R4; presumably the name indicates that it was intended to
be used to set TZ, but it can set more than just TZ, so presumably the
intent was to change the name to reflect that) and "init" sets up the
environment of everything it spawns (except, apparently, for the
single-user shell) with those values (max of 6 values, at least in
S5R3.1).
That's what the code seems to do, anyway; try it and see.
-----------------------------
From: Chris Lewis <clewis@eci386.uucp>
Subject: Re: Cartridge tape stuff
Date: 7 Jul 89 00:34:55 GMT
To: unix-wizards@sem.brl.mil
In article <757@mitisft.Convergent.COM> dold@mitisft.Convergent.COM (Clarence Dold) writes:
>in article <1989Jun28.173209.1457@eci386.uucp>, clewis@eci386.uucp (Chris Lewis) says:
>> tar and cpio do not change their formats regardless of the buffer size
>> you give them, they simply use bigger I/O buffers.
>One exception I can think of is EOT on a multi-volume archive.
> cpio -ocvT512k >/dev/rmt0
>and EOT is reached somewhere in the midst of writing a 512K block, the next
>reel will have a repeat of that 512K block.
[And reads with small blocks would get out of sync]
True. Didn't think of that. Mind you, most tar's don't support multi-volume
(and frankly, I simply don't trust cpio multi-volume except *maybe* on
floppies) so the question is moot for tar.
>If a small buffer is used on the outbound side, and a large buffer is used
>to read it, the opposite will happen, even on single reel archives.
>An archive that is 33*512 byte, will come out to an uneven multiple of
>512K, and the restore will fail, unable to read the last, apparently partial
>set of blocks.
H'm, I just tried this with cpio on ISC 1.0.6 and it worked just fine.
try:
cd /etc
cpio -o > /tmp/foo
passwd
inittab
group
<ctrl-D>
cd /tmp
cpio -iC512000 < /tmp/foo
(will say that 10000 blocks read, but will create the files
just perfectly)
(-C is an undocumented cpio argument on ISC, probably AT&T, Microport and
Bell Tech. I belive they (whoever "they" were) replaced cpio with something
called "ncpio" which appears to have been an internal enhanced version of cpio.
This appears to be the only way to get arbitrarily sized buffers specified
to cpio.)
Even if true, on QIC devices you really do need big buffers to get
any sort of reasonable throughput. So you should be able to choose a
reasonable size. Any QIC driver that can't read/write more
than 512 bytes at a time should be junked. Any 1/4" streamer that has
variable length records wouldn't be able to read/write compatible QIC tapes
anyhow.
As a reasonable compromise: use 128K on QIC streamers - large enough to
not have too bad a start-stop hit, not so large that you could run into
severe problems on machines with small amounts of memory or lots of other
users that are trying to get things done ;-). On 9-track, 5K is usually
fine (tar limit), though there are some machines that can only handle 3K
(some 3b's). Once you get above 5K blocks all bets are off as to whether
the hardware can handle real physical blocks that big.
There are a few machines that don't like > 32K or > 64K raw I/O because
of DMA boundaries. 386 UNIX and NCR Towers have it right even though they
have somewhat strange DMA structures. Some older PC UNIXes don't. For
those machines, you might have to limit yourselves to 32K.
Even then, you might be able to fake it:
If your tar doesn't support buffers bigger than 5K, you can always
pipe the output of tar thru dd:
tar cvf - .... | dd bs=<whatever> > /dev/....
[I may be mistaken, but doesn't 386 2.3.1 Xenix dd not support bs > 64K?]
--
Chris Lewis, R.H. Lathwell & Associates: Elegant Communications Inc.
UUCP: {uunet!mnetor, utcsri!utzoo}!lsuc!eci386!clewis
Phone: (416)-595-5425
-----------------------------
From: <cheetah@blake.acs.washington.edu>
Subject: Security
Date: 7 Jul 89 03:01:45 GMT
Keywords: UNIX, VAX/VMS
Posted: Thu Jul 6 20:01:45 1989
To: unix-wizards@sem.brl.mil
I will be bringing a new UUCP site on-line within the next 60 days.
In preparation, I am trying to learn as much as possible about
information system security. The main emphisis is on the UNIX
and VAX/VMS operating systems.
If you are aware of any mailing lists, publications, texts, or other
sources of information on these subjects, please drop me a note.
In an attempt to conserve bandwidth, as well as other obvious reasons,
please Email me directly.
Thank you for your assistence in this matter.
- Steve
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"There are two major products that come out of Berkeley: LSD and UNIX. We
don't believe this to be a coincidence." || - Jeremy S. Anderson
#include <disclaimer.h> cheetah@blake.acs.wahington.edu
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-----------------------------
End of UNIX-WIZARDS Digest
**************************
---------- end of forwarded messagepostmaster@urbana.mcd.mot.com (07/11/89)
The enclosed mail message was addressed to a system which is no longer
in service. We have attempted to forward your mail to the correct
recipient(s). If this is not possible, you will recieve additional
mail at the time of failure.
In the future, please use the system name "urbana.mcd.mot.com" instead.
Please correct any mailing lists or alias files that may reference
any of the following obsolete system names:
xenurus.gould.com
fang.gould.com
fang.urbana.gould.com
vger.urbana.gould.com
ccvaxa.gould.com
ccvaxa.urbana.gould.com
burt.urbana.gould.com
mycroft.urbana.gould.com
If you have any further problems or questions about mail to this site,
please contact postmaster@urbana.mcd.mot.com.
thank you for your cooperation,
postmaster@urbana.mcd.mot.com
Motorola Microcomputer Division, Urbana Design Center
---------- text of forwarded message:
Received: from sem.brl.mil by placebo (5.61/1.34)
id AA04262; Mon, 10 Jul 89 21:30:24 -0500
Received: from SEM.BRL.MIL by SEM.brl.MIL id aa01188; 8 Jul 89 2:57 EDT
Received: from sem.brl.mil by SEM.BRL.MIL id aa01145; 8 Jul 89 2:45 EDT
Date: Sat, 08 Jul 89 02:45:19 EST
From: The Moderator (Mike Muuss) <Unix-Wizards-Request@BRL.MIL>
To: UNIX-WIZARDS@BRL.MIL
Reply-To: UNIX-WIZARDS@BRL.MIL
Subject: UNIX-WIZARDS Digest V7#123
Message-Id: <8907080245.aa01145@SEM.BRL.MIL>
UNIX-WIZARDS Digest Sat, 08 Jul 1989 V7#123
Today's Topics:
Re: at files and permissions
Re: chown (was: at files and permissions)
Re: What kinds of things would you want in the GNU OS?
Re: local test
Re: Using the uucp daemon (TCP/IP) on System V.3 with TCP/IP
Re: SVR4 (was: Re: at files and permissions)
ftruncate(2) for System V.3.2 needed
help needed on ethernet packet access on BSD4.3unix
scsi rll trade off questions?
-----------------------------------------------------------------
From: Rahul Dhesi <dhesi@bsu-cs.bsu.edu>
Subject: Re: at files and permissions
Date: 6 Jul 89 04:52:39 GMT
To: unix-wizards@sem.brl.mil
An AT&T salesman earnestly told me that System V Release 3 does have a
disk quota mechanism. I told him this was news to me. What this has
to do with the following is left as an exercise for the reader.
I said:
...BSD allows only root to change file ownership.
In article <4884@ficc.uu.net> peter@ficc.uu.net (Peter da Silva) writes:
I certainly hope that V.4 doesn't have this *bogus* restriction.
My response:
I doubt that it will need to.
--
Rahul Dhesi <dhesi@bsu-cs.bsu.edu>
UUCP: ...!{iuvax,pur-ee}!bsu-cs!dhesi
-----------------------------
From: Rahul Dhesi <dhesi@bsu-cs.bsu.edu>
Subject: Re: at files and permissions
Date: 7 Jul 89 00:54:13 GMT
To: unix-wizards@sem.brl.mil
In article <228@arnor.UUCP> uri@arnor.UUCP (Uri Blumenthal) writes:
[ objecting to my recommendation "when you discuss a security problem
that is specific to System V, please be sure to say so clearly, else
you may confuse naive users." ]
>First of all, not everybody familiar with System V, knows exactly which
>features of BSD (and what version!) it has or has not. So, for example,
>I didn't know that you can do "chown" only being root...
The problem is easily solved. Don't say (or even imply) "UNIX" at all
unless you are sure you are making a general statement. Just mention
specifically what operating system and revision level you are
discussing (e.g. "System V Release 3" or "4.3BSD").
--
Rahul Dhesi <dhesi@bsu-cs.bsu.edu>
UUCP: ...!{iuvax,pur-ee}!bsu-cs!dhesi
-----------------------------
From: Guy Harris <guy@auspex.auspex.com>
Subject: Re: at files and permissions
Date: 7 Jul 89 06:36:00 GMT
To: unix-wizards@sem.brl.mil
> 2) BSD *does* allow you to give files away.
No, it doesn't - not vanilla 4.xBSD, anyway; you have to be root to
change the ownership of a file. It may allow you to make some limited
changes to the *group* IDs of files you own, but that's a different matter.
>In SVR3, there's no specific utility to run the "at" jobs, they seem to
>be simply shovelled into cron.
Yup, "cron" runs 'em both, and has since S5R2.
-----------------------------
From: Mike Urban <urban@randvax.uucp>
Subject: Re: chown (was: at files and permissions)
Date: 6 Jul 89 15:18:39 GMT
To: unix-wizards@sem.brl.mil
In article <22969@iuvax.cs.indiana.edu> bobmon@iuvax.cs.indiana.edu (RAMontante) writes:
>->>... BSD allows only root to change file ownership. (bogus?)
>-
>There are also many potential problems from hostile users (generally
>undergraduates) --- consuming someone else's quota can break their
>running program, make them miss an assignment deadline, etc. Putting
>obscene or incriminating material in someone else's file system and then
>"turning them in" can do some real *major* damage.
>
There are also many installations that attempt to do cost recovery (or
some bureaucratic imitation thereof) by charging users for disk space.
Allowing users to give away their large and expensive files to other
accounts complicates matters considerably.
Not knowing about SysV's ability to give away files can lead to
unpleasant surprises on some machines when creating a directory
using tar and discovering that the resulting files belong to
someone else.
--
Mike Urban
urban@rand.ORG
-----------------------------
From: "Clifford C. Skolnick" <ccs@lazlo.uucp>
Subject: Re: What kinds of things would you want in the GNU OS?
Date: 7 Jul 89 03:30:04 GMT
To: unix-wizards@sem.brl.mil
In article <214@tnl.UUCP> norstar@tnl.UUCP (Daniel Ray) writes:
|In article <8906272337.AA24210@cscwam.UMD.EDU>, stripes@wam.UMD.EDU writes:
|> ...
|> I would like to see a few extra protection bits in the new Kernal. A bit
|> for append-only (the kernal fseeks to the end of the file before each write).
|
| 1. A new (or new use of a) directory permission bit, such as using SUID/SGID
|or something new, would designate the dir as "append only except edit in
|single user mode". This would apply to root as well. So, audit trails and
|logfiles could not be modified except when the machine was brought down to
|single user mode at the local console. Files in the dir could be appended
|to, however, if the mode on the file permitted writes. Existing data could
|not be modified by anyone in multiuser mode.
If I was the superuser, I could just wipe out the raw disk devices. The
only way this will work is to use an on-line printer. The whole concept
of a super-user is the problem. I wish I had a better solution to offer,
but...
Cliff
--
"I'd rather stay here with all the madmen, than perish with the sad man
roaming free" -- David Bowie
"Life is a test, only a test. If it was real, you would have been given much
better instructions." Clifford C. Skolnick / (716)427-8046 / ccs@lazlo.UUCP
-----------------------------
From: Craig Bruce <craigb@hpqtdla.hp.com>
Subject: Re: local test
Date: 7 Jul 89 07:10:57 GMT
To: unix-wizards@sem.brl.mil
local test ????
I don't know what you define the term 'local' as, but I thought you'd like to
know that your message reached me here in South Queensferry (near Edinburgh).
Yours Helpfully,
Craig.
-----------------------------
From: Jos Vos <jos@idca.tds.philips.nl>
Subject: Re: Using the uucp daemon (TCP/IP) on System V.3 with TCP/IP
Date: 7 Jul 89 10:07:37 GMT
Keywords: UUCP TCP/IP uucpd uucico sockets BSD4.3 SysV.3
To: unix-wizards@sem.brl.mil
In article <656@wrs.wrs.com> hwajin@wrs.UUCP (Hwajin Bae) writes:
>HDB UUCP that comes with AT&T V.3.2 UNIX includes support for TLI, TLIS, and
>socket interfaces to TCP/IP connections. Using existing TLIS (TLI STREAMS
>Based) code, all you need is to set up listener service database to invoke
>uucico when a request comes in from a remote TCP/IP host. This is only useful
>if you have another machine with TCP/IP, TLI, and equivalent UUCP.
The socket code is between BSD42 (or whatever) #ifdef's. Isn't it?
I know about the TCP/IP via TLI(S), but I need to be able to talk
to BSD systems too.
>Porting BSD 4.3 UUCP daemon has already been done several times for different
>incarnations of TCP/IP implementations for system V Unix's. Unfortunately
>none of them are "free" that I know of.
I only need the patches, I have the BSD4.3 uucpd source...
--
-- ###### Jos Vos ###### Internet jos@idca.tds.philips.nl ######
-- ###### ###### UUCP ...!mcvax!philapd!jos ######
-----------------------------
From: Doug Gwyn <gwyn@smoke.brl.mil>
Subject: Re: SVR4 (was: Re: at files and permissions)
Date: 7 Jul 89 13:48:23 GMT
To: unix-wizards@sem.brl.mil
In article <4896@ficc.uu.net> peter@ficc.uu.net (Peter da Silva) writes:
>Does anyone here really know what sort of crud V.4 (not V.3) is going to
>have in it? Streams *and* sockets, or so I hear...
AT&T presented an overview of SVR4 at a BOF session at the Baltimore USENIX.
Therefore lots of people presumably now know what SVR4 will contain and more
or less how it's implemented.
Sockets are emulated; STREAMS is the basic kernel mechanism.
-----------------------------
From: Jos Vos <jos@idca.tds.philips.nl>
Subject: ftruncate(2) for System V.3.2 needed
Date: 7 Jul 89 14:07:29 GMT
To: unix-wizards@sem.brl.mil
I need the ftruncate(2) function from BSD4.3 UNIX on System V.3.2.
For non-BSD-manual-owners, here's the description of ftruncate(2):
* ftruncate (fd, length)
* int fd;
* long length;
*
* Ftruncate causes the file referenced by fd (a file descriptor of an
* file open for writing) to be truncated to at most length bytes in size.
* If the file previously was larger than the size, the extra data is lost.
Hint: I do *not* know the filename of the open file, of course :-)
Because I don't even know if there exists a solution, also a *proof* :-)
that no solution exists will be very helpfull to me (than I can start
rewriting the code around ftruncate() in my application :-( ).
--
-- ###### Jos Vos ###### Internet jos@idca.tds.philips.nl ######
-- ###### ###### UUCP ...!mcvax!philapd!jos ######
-----------------------------
From: "Anoop R. Hegde" <anoop@ECE.ORST.EDU>
Subject: help needed on ethernet packet access on BSD4.3unix
Date: 7 Jul 89 17:37:36 GMT
Sender: usenet@CS.ORST.EDU
To: unix-wizards@sem.brl.mil
( My apologies if this posting is not very relevant to this newsgroup,
but i am sure, some of you have worked on a new protocol implementation)
We have a MicroVax II running BSD4.3 UNIX. I am trying to
develope a new protocol parallel to IP, to be used in the
local ethernet environment. ( to be specific, i would like
to write programs that can receive an ethernet packet carrying
an experimental 'type' field, so that I can set up communication
between this machine and any other machine connected to the same
ethernet) Obviously, this can't be done using sockets, (even raw)
as, they don't allow access below IP level. I would be very much
thankful if someone can provide me with some more info. on this
matter, or atleast a pointer to pursue.
( we have the kernel source code, and it would be of much
help if i know where is packet demultiplexing done and which files
to look into, etc. )
--------------------------------------------------------------------------
Anoop R. Hegde internet: anoop@guille.ece.orst.edu
Dept. of ECE, UUCP : tektronix!orstcs!hegdea
Oregon State University or : hplabs!hp-pcd!orstcs!hegdea
--------------------------------------------------------------------------
-----------------------------
From: "Kevin L. Allred" <allred@ut-emx.uucp>
Subject: scsi rll trade off questions?
Date: 7 Jul 89 21:37:43 GMT
Keywords: scsi rll hard disk compatability
Posted: Fri Jul 7 16:37:43 1989
To: unix-wizards@sem.brl.mil
I'm putting together a low end workstation for my personal use at home.
It will have a 386SX, 4MB memory and monochrome VGA graphics.
Initially I plan to just run MSDOS, but soon I would like to run UNIX.
I currently am considering hard drives in the range of 65 to 80 MB. I
was only considering an RLL drive with 1:1 interleve controller until
I had pointed out to me that Segate has recently started marketing a
low cost SCSI addaptor (ST01 and ST02) suitable for use with its
ST296N 80MB hard disk. This combination reportedly offeres about 750
KB/sec transfer rate, which is comparable to the 1:1 interleve RLL
transfer rate, and it is more cost effective. Apparently the SCSI
addaptor works fine under DOS, but I have already had related to me
that it probably won't work with UNIX because of lack of drivers (I
heard that was a problem common to most SCSI boards even the expensive
intelligent ones like the WD7000). Are the various UNIX vendors
developing drivers, so that I don't need to worry about this, or
should I stick with the RLL controller and disks?
--
Kevin Allred
allred@emx.cc.utexas.edu
allred@ut-emx.UUCP
-----------------------------
End of UNIX-WIZARDS Digest
**************************
---------- end of forwarded messagepostmaster@urbana.mcd.mot.com (07/11/89)
The enclosed mail message was addressed to a system which is no longer
in service. We have attempted to forward your mail to the correct
recipient(s). If this is not possible, you will recieve additional
mail at the time of failure.
In the future, please use the system name "urbana.mcd.mot.com" instead.
Please correct any mailing lists or alias files that may reference
any of the following obsolete system names:
xenurus.gould.com
fang.gould.com
fang.urbana.gould.com
vger.urbana.gould.com
ccvaxa.gould.com
ccvaxa.urbana.gould.com
burt.urbana.gould.com
mycroft.urbana.gould.com
If you have any further problems or questions about mail to this site,
please contact postmaster@urbana.mcd.mot.com.
thank you for your cooperation,
postmaster@urbana.mcd.mot.com
Motorola Microcomputer Division, Urbana Design Center
---------- text of forwarded message:
Received: from sem.brl.mil by placebo (5.61/1.34)
id AA04281; Mon, 10 Jul 89 21:31:41 -0500
Received: by SEM.BRL.MIL id ab10938; 10 Jul 89 14:50 EDT
Received: from SEM.BRL.MIL by SEM.brl.MIL id aa04049; 9 Jul 89 3:20 EDT
Received: from sem.brl.mil by SEM.BRL.MIL id aa04012; 9 Jul 89 2:45 EDT
Date: Sun, 09 Jul 89 02:45:13 EST
From: The Moderator (Mike Muuss) <Unix-Wizards-Request@BRL.MIL>
To: UNIX-WIZARDS@BRL.MIL
Reply-To: UNIX-WIZARDS@BRL.MIL
Subject: UNIX-WIZARDS Digest V7#124
Message-Id: <8907090245.aa04012@SEM.BRL.MIL>
UNIX-WIZARDS Digest Sun, 09 Jul 1989 V7#124
Today's Topics:
Re: Algorithm needed: reading/writing a large file
Re: What kinds of things would you want in the GNU OS?
Quotas in the Real World [TM] (was: Re: chown)
Re: help needed on ethernet packet access on BSD4.3unix
Re: scsi rll trade off questions?
Lots of zombies on HP-UX (2.1, 3.1), all children of remshd
Re: at files and permissions
-----------------------------------------------------------------
From: Rahul Dhesi <dhesi@bsu-cs.bsu.edu>
Subject: Re: Algorithm needed: reading/writing a large file
Date: 7 Jul 89 17:44:49 GMT
To: unix-wizards@sem.brl.mil
In article <205@larry.sal.wisc.edu> jwp@larry.sal.wisc.edu (Jeffrey W
Percival) writes:
[how do I sort a large file that won't fit in memory?]
There are many variations on the merge sort. Here is a simple one:
break up the original file into N smaller files
sort each smaller file
merge them all
--
Rahul Dhesi <dhesi@bsu-cs.bsu.edu>
UUCP: ...!{iuvax,pur-ee}!bsu-cs!dhesi
-----------------------------
From: Steve Harris <vsh@etnibsd.uucp>
Subject: Re: What kinds of things would you want in the GNU OS?
Date: 6 Jul 89 22:55:52 GMT
To: unix-wizards@sem.brl.mil
In article <1549@salgado.Solbourne.COM> dworkin@Solbourne.com (Dieter Muller) writes:
>I'd *really* like a sane tty driver.
Hear hear!! At a former job we talked a lot about how we would rewrite
the tty driver. One idea was to give the user, via ioctl's, access to
the uart (or whatever serial-line multiplexer you have). One ioctl to
get the uart settings (in a bit vector), another to set them, and
another to have the driver(??) send you a signal (for which you would
have to write the appropriate handler) whenever any of the bits changed
(e.g., DTR was deasserted). Standard configurations (handlers) would
be privided in a library. Of course, one would be limited by the
capabilities of the uart, but the design would assume total access to
be possible.
A second idea is "copy-on-write symbolic links" -- I have a symlink:
bar -> foo
When I write to it, a regular file "bar" is created (the symlink is
destroyed), the contents of foo (up to the current file-pointer-offset)
are copied to bar, and the write takes place. I'm not sure what
happens if foo is not a regular file.
--
Steve Harris -- Eaton Corp. -- Beverly, MA -- uunet!etnibsd!vsh
-----------------------------
From: Nick Cuccia <cuccia@yak.sybase.com>
Subject: Quotas in the Real World [TM] (was: Re: chown)
Date: 8 Jul 89 04:32:47 GMT
Sender: news@sybase.sybase.com
Keywords: quotas, filesystems, bsd
To: unix-wizards@sem.brl.mil
In article <4893@ficc.uu.net> peter@ficc.uu.net (Peter da Silva) writes:
>In article <18414@mimsy.UUCP>, chris@mimsy.UUCP (Chris Torek) writes:
>> The restriction is not bogus, because the system supports disk quotas.
>
>This assume that disk quotas are not bogus in a production environment.
>That is, outside a university...
Think about two or more administrative groups divvying up a large disk
partition. (The real solution, of course, is to buy more disks (not
always practical from a financial point-of-view) or to repartition the
existing disk (not always practical, due to either limitations caused
by different vendors or the downtime required to repartition the existing
disk). But I digress...). Under such a system, quotas (or, something
almost like, but not exactly like the BSD or Sun quotas mechanisms) provide
the answer.
The problem that I have with the current quotas implementations is that
they're too limited in scope. For the problem above, the current
implementations are useful--as long as the members of each group are
mutually exclusive (if your groups are beancounters and developers, then
that assumption is probably valid). If, however, you have the more common
situation of users being members of multiple groups (three groups working
on the same application suite: one on front ends, another on servers and
back ends, and the other on networking support. While the first two groups
may have a fairly small intersecting set with each other, they'd each have
quite a bit of intersection with the third), then you fall into the nightmare
of adjusting a user in the intersecting set's quotas so that his quota
doesn't cause any of his groups' quotas to be exceeded.
The fix is conceptually simple: allow for quota-by-group, as well as quota-by-
user.
--Nick
===============================================================================
Some days, you just can't get rid of a bomb...--Batman
Nick Cuccia System Admin/Postmaster, Sybase, Incorporated
cuccia@sybase.com 6475 Christie Av. Emeryville, CA 94608
{sun,lll-tis,pyramid,pacbell}!sybase!cuccia +1 415 596-3500
===============================================================================
-----------------------------
From: terryl@tekcrl.labs.tek.com
Subject: Re: help needed on ethernet packet access on BSD4.3unix
Date: 7 Jul 89 20:53:56 GMT
Followup-To: comp.protocols.tcp-ip
To: unix-wizards@sem.brl.mil
In article <11530@orstcs.CS.ORST.EDU+ anoop@guille.ece.orst.edu (Anoop R. Hegde) writes:
+
+( My apologies if this posting is not very relevant to this newsgroup,
+ but i am sure, some of you have worked on a new protocol implementation)
+
+
+ We have a MicroVax II running BSD4.3 UNIX. I am trying to
+ develope a new protocol parallel to IP, to be used in the
+ local ethernet environment. ( to be specific, i would like
+ to write programs that can receive an ethernet packet carrying
+ an experimental 'type' field, so that I can set up communication
+ between this machine and any other machine connected to the same
+ ethernet) Obviously, this can't be done using sockets, (even raw)
+ as, they don't allow access below IP level. I would be very much
+ thankful if someone can provide me with some more info. on this
+ matter, or atleast a pointer to pursue.
+ ( we have the kernel source code, and it would be of much
+ help if i know where is packet demultiplexing done and which files
+ to look into, etc. )
Having done this exact thing quite a few years back for 4.2, the place
you need to look at is the device driver level. Specifically, you need to
look at two separate places: the output routine for the driver for packets
going out on the ethernet, and the input interrupt routine for packets coming
in from the ethernet.
In the output routine, you key on the sa_family member of a struct
sockaddr; suffice it to say you'll have to examine the code closely to see
what I mean. In the input interrupt routine, you key on the actual ethernet
type field in the packet itself. Again, examine the code.
For VAX stuff, look in vaxif/if_il.c (for an Interlan driver) at the
routines iloutput and ilrint for the output and input interrupt routines,
respectively.
-----------------------------
From: Byron Lunz <byronl@copper.mdp.tek.com>
Subject: Re: scsi rll trade off questions?
Date: 8 Jul 89 03:54:34 GMT
Followup-To: comp.sys.ibm.pc
Keywords: scsi rll hard disk compatability
To: unix-wizards@sem.brl.mil
In article <14978@ut-emx.UUCP> allred@ut-emx.UUCP (Kevin L. Allred) writes:
>I'm putting together a low end workstation for my personal use at home.
>It will have a 386SX, 4MB memory and monochrome VGA graphics.
...
>I was only considering an RLL drive with 1:1 interleve controller until
>I had pointed out to me that Segate has recently started marketing a
>low cost SCSI addaptor (ST01 and ST02) suitable for use with its
>ST296N 80MB hard disk. This combination reportedly offeres about 750
>KB/sec transfer rate, which is comparable to the 1:1 interleve RLL
>transfer rate, and it is more cost effective. Apparently the SCSI
I received my new Gateway 2000 386/20 a few days ago. It arrived with
a Seagate ST296N and SCSI controller (not sure of the model #). Transfer
rate was one of my reasons for purchasing this system, and I was assured
prior to the purchase by the salesperson that I could expect 800KB/sec.
I was quite disappointed when both Spintest and Coretest 2.7 gave me
data transfer rates of 440-460KB/sec! Then, just today Mark Davis
<davis@cs.unc.edu>, reported that some users are seeing transfer
rates of 950KB/sec!
The interesting part is that when I called Gateway, the salesman
immediately began reciting what sounded like a prepared statement to
the effect that Seagate had lied to them! Then he quickly offered
me a ST4096/DTC controller combo as a replacement, with a transfer
rate of 550KB/sec. It's in the mail. If someone out there is
actually seeing transfer rates around or over 800KB/sec, I'd sure
like to hear about it.
P.S. The drive documentation supplied with my system says the
interleave is 1:1. And the access time, rated at 28ms, is measured
at 33.7ms by Coretest.
--
Byron Lunz
Tektronix Logic Analyzer Division
byronl@copper.MDP.TEK.COM
Beaverton, Oregon
-----------------------------
From: Tor Lillqvist <tml@hemuli.atk.vtt.fi>
Subject: Lots of zombies on HP-UX (2.1, 3.1), all children of remshd
Date: 6 Jul 89 09:35:55 GMT
To: unix-wizards@sem.brl.mil
We are experiencing lots of zombie processes on an HP9000 Series 800
running HP-UX 3.1 (the same occurred also in 2.1 and 3.01). They are
all children of remshd (rshd in BSD) processes (which have no other
children). All these remshds are sleeping on selwait. We have a
configuration with a bunch of Series 300 workstations running X
clients on the 840. Right now, for instance, there are 25 of these
zombies when the system has been up for three days, with perhaps ten
active workstation users.
What could be the problem? Is there any cure, except writing a perl
script that scans ps now and then, and kills off remshd processes with
a zombie child?
--
Tor Lillqvist
Technical Research Centre of Finland, Computing Services (VTT/ATK)
tml@hemuli.atk.vtt.fi [130.188.52.2]
-----------------------------
From: Bob Wilber <wilber@alice.uucp>
Subject: Re: at files and permissions
Date: 7 Jul 89 23:11:29 GMT
To: unix-wizards@sem.brl.mil
Chris Lewis writes:
>"at" needs setuid root permissions so that it can write in the cron/at
>spool directories.
Actually, "at" shouldn't have to run setuid to root. A special user (say,
"Mr.At") should be created to own the at spool directory, and "at" should run
setuid to Mr.At. That way if someone discovers a security hole in "at" he only
gains the power to delete other people's at files, he doesn't get to play super
user.
The real reason "at" is run setuid to root on System V is because of the
infamous System V setuid(2) bug, wherein a process with a non-root effective id
is not able to setuid to its real id if that real id is root. Because of this
bug "at" must be run setuid to root so that root can use it.
Bob Wilber
-----------------------------
End of UNIX-WIZARDS Digest
**************************
---------- end of forwarded messagepostmaster@urbana.mcd.mot.com (07/11/89)
The enclosed mail message was addressed to a system which is no longer
in service. We have attempted to forward your mail to the correct
recipient(s). If this is not possible, you will recieve additional
mail at the time of failure.
In the future, please use the system name "urbana.mcd.mot.com" instead.
Please correct any mailing lists or alias files that may reference
any of the following obsolete system names:
xenurus.gould.com
fang.gould.com
fang.urbana.gould.com
vger.urbana.gould.com
ccvaxa.gould.com
ccvaxa.urbana.gould.com
burt.urbana.gould.com
mycroft.urbana.gould.com
If you have any further problems or questions about mail to this site,
please contact postmaster@urbana.mcd.mot.com.
thank you for your cooperation,
postmaster@urbana.mcd.mot.com
Motorola Microcomputer Division, Urbana Design Center
---------- text of forwarded message:
Received: from sem.brl.mil by placebo (5.61/1.34)
id AA04291; Mon, 10 Jul 89 21:32:07 -0500
Received: by SEM.BRL.MIL id al11312; 10 Jul 89 15:26 EDT
Received: from SEM.BRL.MIL by SEM.brl.MIL id aa04939; 10 Jul 89 3:16 EDT
Received: from sem.brl.mil by SEM.BRL.MIL id aa04832; 10 Jul 89 2:45 EDT
Date: Mon, 10 Jul 89 02:45:20 EST
From: The Moderator (Mike Muuss) <Unix-Wizards-Request@BRL.MIL>
To: UNIX-WIZARDS@BRL.MIL
Reply-To: UNIX-WIZARDS@BRL.MIL
Subject: UNIX-WIZARDS Digest V7#125
Message-Id: <8907100245.aa04832@SEM.BRL.MIL>
UNIX-WIZARDS Digest Mon, 10 Jul 1989 V7#125
Today's Topics:
gath
Re: Algorithm needed: reading/writing a large file
ftruncate broken? - Sun-based NFS
Socket Extensibility to non TCP/IP
uucp delivery order?
Re: What kinds of things would you want in the GNU OS?
Re: SLIP compression...
Re: Using the uucp daemon (TCP/IP) on System V.3 with TCP/IP
Re: chown (was: at files and permissions)
Re: Convert string time into seconds?
Re: at files and permissions
Re: chown (was: at files and permissions)
Re: scsi rll trade off questions?
Re: Using the uucp daemon (TCP/IP) on System V.3 with TCP/IP
-----------------------------------------------------------------
From: "barbara.tongue" <bgt@cbnewsh.att.com>
Subject: gath
Date: 8 Jul 89 19:30:28 GMT
Keywords: help!
To: unix-wizards@sem.brl.mil
Folks,
In one of the tools directoryies on my machine, I discovered
the executable "gath." Now, from what I've heard, gath is a
tool which "gathers" files, allows shell execution if lines
are prefaced with ~$, and can be used in combination with
troffed files. Here is my question -
Let's say that I have dynamic flat-file database, whose fields
can be any combination of 17 variables. I want to pipe that
into troff and get out a clean table with the headers correctly
inserted. With definite input, that is no problem; for example,
I've written into my .tbl file what the header names are and
in what file the data is located. The problem occurs when I
want to switch to using $1 as my file name; the command
gath file.tbl file.data
defines $1 as null. (I'm calling $1 from file.tbl; I assume
that in itself is a problem.)
Does anyone know where the source code can be found?
I have no man page for this executable; can anyone help?
Much, much *much* thanks in advance,
--
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%% The Speaking Tongue, AT&T %% C Code. C Code Run. Run, Code, RUN! %%
%% (..!att)!feathers!bgt %% PLEASE!!!! %%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
-----------------------------
From: David Quarles <david@jc3b21.uucp>
Subject: ... HELP HELP ... TROUBLE PRINTING WITH eroff ...
Date: 8 Jul 89 14:29:39 GMT
Keywords: eroff printing more than one page
To: unix-wizards@sem.brl.mil
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
I need some help on getting eroff to print the text (all of it) from a
regular text file on UNIX.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
I have the book "Preparing documents with UNIX" by Brown et.al. but just
cannot figure out how to get the text to print continuously from page to
page. This book covers troff and nroff but not 'eroff'. I had hoped
there would be something in it that would help.
In talking to a couple of others at this site, this 'eroff' is
apparently third party software for UNIX.
What happens is that several lines get left off at the bottom of a page
and then the second page does not have the missing lines but has just
somehow skipped text. ALL I WANT TO DO IS TO TAKE A TEXTFILE AND PRINT
WITH eroff (for our HP Laserjet). This program eroff does a very nice
job with margins and font styles.
ANY IDEAS OUT THERE ?? ANY ADVICE WILL BE GREATLY APPRECIATED !!
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
PLEASE email since our UNIX system purges the news sometimes before I
get a chance to read it ...
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
=-=-= Email: david@jc3b21.UUCP -=-=-=-=-=-=-=-= Dave =-=-=-=-=-=-=-=-=-=-= EOT
-----------------------------
From: Jeffrey Kegler <jeffrey@algor2.uucp>
Subject: Re: Algorithm needed: reading/writing a large file
Date: 9 Jul 89 06:05:41 GMT
To: unix-wizards@sem.brl.mil
In article <207@larry.sal.wisc.edu> jwp@larry.sal.wisc.edu.UUCP (Jeffrey W Percival) writes:
=> Please be careful with your paraphrasing.
I certainly promise to try.
=> My question was about optimizing the process of rearranging a disk file
=> according to a *given* mapping.
Jeffrey P. (no relation) had implemented a suggestion made in the AT&T
Bell Laboratories Technical Journal, by J. P. Linderman, p. 258. He
extracted the keys and record locations of an unsorted file (call it
U), sorted them, and them constructed the sorted file (call it S),
only to find the random seeks involved in the last phase horrifyingly
slow.
=> One helpful person suggested reading sequentially and writing randomly,
=> rather than vice-versa,
That would have been my first thought.
=> and I tried that but it didn't help. I guess
=> the benefit gained from using the input stream buffering was canceled
=> out by the effective loss of the output stream buffering.
Oh well.
As a second try, allocate enough memory for N full length records, and
two arrays to be sorted together of N keys and N record locations. Go
through the sorted keys and find the key and locations in U of the
first N records in the *sorted* file. Sort them by record location in
U, the unsorted file, and read them in, in order by location in U,
writing them in memory in sorted order by key in the array of full
length records. Then write those records out. Repeat until all
records are written. This will involve 1 sequential pass to write
file S, and M/N sequential passes to read file U.
A further improvement is to calculate how many sequential reads cost
the same as a random seek. Call that ratio R. Whenever performing
the algorithm above would require more than R sequential reads (this
is easily determined from the difference in the record locations),
perform a seek.
My guess at R for UNIX is around 2.5 times number of records per block.
Obviously the larger N the better this will work. Note your original
try is this algorithm in the special case where N is 1. If we could
run this algorithm in terms of physical disk block instead of logical
file location, this algorithm could really hum.
Further optimizations suggest themselves, but enough already.--
Jeffrey Kegler, President, Algorists,
jeffrey@algor2.UU.NET or uunet!algor2!jeffrey
1762 Wainwright DR, Reston VA 22090
-----------------------------
From: der Mouse <mouse@mcgill-vision.uucp>
Subject: ftruncate broken? - Sun-based NFS
Date: 9 Jul 89 05:13:16 GMT
To: unix-wizards@sem.brl.mil
The ftruncate() call appears to be broken on at least some systems with
NFS implementations based on Sun's. I've tried this on a Sun-3 with
release 3.5 and on a VAX running mtXinu 4.3+NFS. I also tried it on a
MicroVAX running real 4.3, and it did not exhibit the broken behavior.
But it's not directly an NFS problem, because it happens even when the
file is on a ufs filesystem.
The problem is that ftruncate() fails if the file modes prohibit
writing, even if the file descriptor used does permit writing. For
example, try the following program on a handy Sun. Notice that (unless
you try it as super-user), the ftruncate call fails. Try it on a 4.3
machine, though, and everything's fine.
(I checked the Sun manpage, and there's not even a note in the BUGS
section warning about this, so presumably someone thinks it should
work the way it does on 4.3.)
Anybody have a simple fix? (Patch a couple of bytes to noops somewhere
in the OBJ/ files perhaps?) Will it be fixed in newer releases (4.x)?
I'm about ready to try to work out a fix on the mtXinu system, to which
we have source, but that's not much help on the Suns.
#include <sys/file.h>
int fd;
char junk[8192];
main()
{
unlink("test.file");
fd = open("test.file",O_RDWR|O_CREAT|O_TRUNC,0666);
if (fd < 0)
{ perror("open/create test.file");
exit(1);
}
if (write(fd,&junk[0],8192) != 8192)
{ perror("write #1");
exit(1);
}
if (fchmod(fd,0444) < 0)
{ perror("fchmod");
exit(1);
}
if (write(fd,&junk[0],8192) != 8192)
{ perror("write #2");
exit(1);
}
if (ftruncate(fd,(unsigned long int)16000) < 0)
{ perror("ftruncate");
exit(1);
}
if (close(fd) < 0)
{ perror("close");
exit(1);
}
exit(0);
}
der Mouse
old: mcgill-vision!mouse
new: mouse@larry.mcrcim.mcgill.edu
-----------------------------
From: Paul Hardiman <paul@bcsfse.uucp>
Subject: Socket Extensibility to non TCP/IP
Date: 7 Jul 89 19:34:20 GMT
To: unix-wizards@sem.brl.mil
What is the story on using sockets on more than just TCP/IP.
Like for instance, one of the OSI protocals, MAP or TOP; and
X.25.--
Paul Hardiman ...!uw-beaver!ssc-vax!voodoo!bcsfse!paul
The above views are strictly my own.
============================================================
-----------------------------
From: Jim Rosenberg <jr@amanue.uucp>
Subject: uucp delivery order?
Date: 9 Jul 89 03:27:38 GMT
To: unix-wizards@sem.brl.mil
I asked this question once before & got a thundering silence -- sorry if I
missed any replies, but I *still need to know*. How can I guarantee that uucp
will deliver jobs to a remote system in the order in which they were queued?
More specifically, how can I issue a series of uux requests and be sure that
the uuxqt at the remote end will execute them in the same order? I have HDB
at one end, and by the time the system is in production will have HDB at the
other end too. The system will be Sytem V.3 in production, if that makes any
difference.
My *very strong impression* is that uucico simply uses the ordering you would
get by doing an ls -f C.* on the spool directory. This is not at all
guaranteed to give the same order as ls -rt C.*, which is what I'd like.
If this suspicion is correct, then I could try to solve my problem by filling
up "holes" in the spool directory before issuing the uux request -- *PROVIDED*
I could completely lock any uuoids in the interim which might remove any files
from the spool directory. (I really don't care if some other process sneaks
in "intervening" jobs -- that doesn't matter. The process that will create
the jobs I'm concerned about has its own locking that guarantees only one
instance can run at once.) For old-style uucp this is a dire pain, since all
sites share the same spool directory. That would mean locking uucp across
all sites. But for HDB I could at least lock the site in question, fill up
holes in the spool directory, then unlock the site. Is this good enough? Is
there a simpler way?
Somehow this makes me nervous. Does the cleanup daemon honor a site lock?
Tampering with directory slots like this seems like a real kludge, and there's
no way I can think of to lock the directory in a truly safe way that's
guaranteed to be reliable.
Not to mention the problem that even if I can guarantee that uucico on the
sending end sends jobs in chronological order, I still don't know if uuxqt on
the receiving end will *run* them in the same order! If uuxqt runs jobs in ls
-f order for the receiver's spool directory, then no amount of clever fakery
on the sending end will help one wit. If this is how uuxqt works then I fear
there may simply be no way to do this.
Aargh, am I asking for the impossible? This seems like such a straightforward
thing to want to do, I'd have thought this issue would have been old hat. I
notice news articles all the time where a reply has a lower article number
than the article to which it's replying; I wonder how much of that is from
uucico delivering jobs "out of order".
Any help appreciated.
--
Jim Rosenberg
CIS: 71515,124 decvax!idis! \
WELL: jer allegra! ---- pitt!amanue!jr
BIX: jrosenberg uunet!cmcl2!cadre! /
-----------------------------
From: Andrew Hume <andrew@alice.uucp>
Subject: Re: What kinds of things would you want in the GNU OS?
Date: 9 Jul 89 06:06:43 GMT
To: unix-wizards@sem.brl.mil
In article <1050@etnibsd.UUCP>, vsh@etnibsd.UUCP (Steve Harris) writes:
> In article <1549@salgado.Solbourne.COM> dworkin@Solbourne.com (Dieter Muller) writes:
> >I'd *really* like a sane tty driver.
>
> Hear hear!! At a former job we talked a lot about how we would rewrite
> the tty driver. One idea was to give the user, via ioctl's, access to
> the uart (or whatever serial-line multiplexer you have). One ioctl to
and so on.....
this is plainly false advertising. it is plausible to give complete control
of a uart to a user. it is NOT plausible to do so under the guise
of a sane tty driver. normally, you would implement a new device
(say /dev/uart).
-----------------------------
From: "Steven M. Bellovin" <smb@ulysses.homer.nj.att.com>
Subject: Re: SLIP compression...
Date: 9 Jul 89 12:46:42 GMT
To: unix-wizards@sem.brl.mil
In article <5108@oregon.uoregon.edu>, jqj@oregon.uoregon.edu (JQ Johnson) writes:
> One possible place to put compression is in the modem itself.
The problem with putting compression in the modem is that you're
still limited by the 9.6Kbps or 19.2Kbps pipe from the CPU to the
modem. (Assuming an external modem, of course.)
-----------------------------
From: Cliff Spencer <cspencer@spdcc.com>
Subject: Re: Using the uucp daemon (TCP/IP) on System V.3 with TCP/IP
Date: 9 Jul 89 12:38:08 GMT
Keywords: UUCP TCP/IP uucpd uucico sockets BSD4.3 SysV.3
To: unix-wizards@sem.brl.mil
>>Porting BSD 4.3 UUCP daemon has already been done several times for different
>>incarnations of TCP/IP implementations for system V Unix's. Unfortunately
>>none of them are "free" that I know of.
>
>I only need the patches, I have the BSD4.3 uucpd source...
What's the big mystery? Doesn't the daemon just spawn /usr/lib/uucp/uucico?
-cliff
-----------------------------
From: Barry Shein <bzs@bu-cs.bu.edu>
Subject: Re: chown (was: at files and permissions)
Date: 9 Jul 89 15:38:15 GMT
To: unix-wizards@sem.brl.mil
From: gwyn@smoke.BRL.MIL (Doug Gwyn)
>There seem to me to be two valid services that can be performed
>by a disk "quota" system. One of them is to prevent runaway disk
>consumption such as
> cat x >> x
>and the other is to keep users from accumulating junk that fills
>the available disk. The first problem is dealt with adequately
>by a resource limit mechanism a la ulimit, or more reliably by a
>"dynamic" quota monitor attached to the specific session. The
>second problem can be dealt with administratively, with periodic
>use of "du|sort -rn" to find where the problems are. Realistic
>long-term storage quotas really have to be negotiated between the
>users and the system administrator anyway. These methods of
>providing disk quota services do not encounter the scenario that
>you described for the UID-based quota scheme when the file owner
>is allowed to chown his own file.
No, it can't be dealt with with "du|sort -rn" except on very small
systems where you can probably just say "someone's hogging the disk"
loudly and get the same effect, cause everyone's in the same room
anyhow (ok, I exaggerate, but small systems with perhaps a hundred or
two entries in the password file.) Or, of course, where you charge
hard currency for disk space so the system has built-in feedback which
makes such problems relatively rare (on one system like that at
Harvard I was the "disk hog", but my funds solved the problem simply
enough, they bought me my own washing machine, no tears.)
Consider the system Rob Pike was describing in his recent USENIX talk.
One major component was a large, organization-wide file server. This
is the type of system that easily has tens of thousands of accounts
(that's not unusual, I worked with a non-unix system over the last few
years that had over 15,000 login accounts in the password file.)
You can have dozens if not hundreds of people using more than what was
decided was their fair share of disk every day. So you run this script
and send them mail. So what? So twenty of them went over their fair
share and won't be back for weeks to see your mail (negligently or
otherwise, they may have thought they had a good reason to do whatever
they did) are way over quota and the disk is busting at the seams on
some partitions. Another ten are ignoring you.
Don't tell me, you start moving some of their stuff off to tape. Oh
what fun, let's have about two dozen people to run this system just to
handle sending and answering disk quota mail, putting things to tape,
dealing with irate users who find they were put to tape and are quite
sure you are mistaken and have inconvenienced them (or believe they
can play the political game to make you never do that to them again),
get the stuff off tape, deal with people who are quite sure something
has gone wrong in this restoral not to mention a phone call or two
about how it took so damn long and they now have a dozen people idle
which is costing them about a thousand dollars an hour while you deal
with the others who are being difficult (ie. human), etc etc etc.
Sh*t Doug, I'd own your whole disk farm just by making you do things
by written, signed memo. You'd spend your weekends proposing budgets
for another dozen secretaries.
Obviously little systems don't need quotas very badly (tho, hey, they
solve both problems you describe with one model, why introduce two
systems where one will do?)
The correct answer is that if you personally shouldn't be constrained
to quotas either you should have infinite quotas or access to some
(set[gu]id) program which lets you set your own quotas (so problem #1,
the accidental overrun is still averted, if desirable.)
Disk is a finite, valuable resource. Many organizations must manage
their disk with many users from diverse administrative domains, and
manage it without any realistic chargeback scheme (ie. the disk is
essentially or actually free* as far as any individual user is
concerned.) The simplest, most obvious way to do this is to assign
disk quotas and have the software enforce these quotas automatically
instead of turning some poor sap into your local disk slave heavy.
My suspicion is you've never managed large systems like this or you
wouldn't even dream of suggesting to just send mail to offenders. And
they're not rare (hint: just about every university has at least one,
if not a few dozen, such systems.)
--------------------
* In fact it's often worse than "free" since the disk is being paid
for out of overhead by everyone so anything you can grab for yourself
is a boon to you, kinda like taxes, you actually can win as long as
you're getting more than your fair share and someone else isn't.
Sorry, but that's life, you don't fix it by removing quotas.
--
-Barry Shein
Software Tool & Die, Purveyors to the Trade
1330 Beacon Street, Brookline, MA 02146, (617) 739-0202
Internet: bzs@skuld.std.com
UUCP: encore!xylogics!skuld!bzs or uunet!skuld!bzs
-----------------------------
From: Wayne Krone <wk@hpirs.hp.com>
Subject: Re: Convert string time into seconds?
Date: 7 Jul 89 21:27:09 GMT
To: unix-wizards@sem.brl.mil
> I have a user entered time/date in the format:
> yymmddhhmmss
> I need to convert this into seconds since the epoch and
If you have ANSI C libraries, convert the yymmddhhmmss into a tm struct
and then use mktime() to convert that into seconds since the epoch.
Wayne
-----------------------------
From: "Brandon S. Allbery" <allbery@ncoast.org>
Subject: Re: at files and permissions
Date: 9 Jul 89 15:36:14 GMT
Followup-To: comp.unix.questions
To: unix-wizards@sem.brl.mil
As quoted from <669@lzaz.ATT.COM> by hutch@lzaz.ATT.COM (R.HUTCHISON):
+---------------
| About "at" requiring "root" permission, I guess it needs it to write
| into the "atjobs" directory.
+---------------
at needs root permissions so it can setuid() itself to the owner of the at
job file, so it can execute the job as the user who submitted it.
++Brandon
--
Brandon S. Allbery, moderator of comp.sources.misc allbery@ncoast.org
uunet!hal.cwru.edu!ncoast!allbery ncoast!allbery@hal.cwru.edu
Send comp.sources.misc submissions to comp-sources-misc@<backbone>
NCoast Public Access UN*X - (216) 781-6201, 300/1200/2400 baud, login: makeuser
-----------------------------
From: Bill Carpenter <wjc@ho5cad.att.com>
Subject: Re: chown (was: at files and permissions)
Date: 9 Jul 89 11:44:25 GMT
Sender: bill@cbnewsh.att.com
To: unix-wizards@sem.brl.mil
In article <10501@smoke.BRL.MIL> gwyn@smoke.BRL.MIL (Doug Gwyn) writes:
> So now the issue becomes: Is the BSD disk quota system bogus?
> ...
> second problem can be dealt with administratively, with periodic
> use of "du|sort -rn" to find where the problems are. Realistic
> long-term storage quotas really have to be negotiated between the
> users and the system administrator anyway. These methods of
> providing disk quota services do not encounter the scenario that
> you described for the UID-based quota scheme when the file owner
> is allowed to chown his own file.
My guess is that the reason that quotas are not handled
administratively is because it is too much hassle for some people.
Far be it from me to judge whether automating penalites is justified
on somebody else's system.
However, if I were building a tool to count up how much disk was being
used by various parties, I might just make the owner of a directory
the responsible person for all the blocks in the normal files
immediately under it. Sure, some people leave directories open to
being filled up by sneaky people who want to evade disk quotas, but at
least my scheme would make the directory owner a co-conspirator.
Losing chown to get disk quotas seems about as wise as having an
imposed low ulimit.
--
Bill Carpenter att!ho5cad!wjc or attmail!bill
-----------------------------
From: Tatu Yl|nen <ylo@sauna.hut.fi>
Subject: Re: scsi rll trade off questions?
Date: 9 Jul 89 18:52:30 GMT
Sender: news@santra.uucp
To: unix-wizards@sem.brl.mil
In article <14978@ut-emx.UUCP> allred@ut-emx.UUCP (Kevin L. Allred) writes:
I'm putting together a low end workstation for my personal use at home.
It will have a 386SX, 4MB memory and monochrome VGA graphics.
Initially I plan to just run MSDOS, but soon I would like to run UNIX.
I currently am considering hard drives in the range of 65 to 80 MB. I
was only considering an RLL drive with 1:1 interleve controller until
I had pointed out to me that Segate has recently started marketing a
low cost SCSI addaptor (ST01 and ST02) suitable for use with its
ST296N 80MB hard disk. This combination reportedly offeres about 750
KB/sec transfer rate, which is comparable to the 1:1 interleve RLL
transfer rate, and it is more cost effective. Apparently the SCSI
addaptor works fine under DOS, but I have already had related to me
that it probably won't work with UNIX because of lack of drivers (I
heard that was a problem common to most SCSI boards even the expensive
intelligent ones like the WD7000). Are the various UNIX vendors
developing drivers, so that I don't need to worry about this, or
should I stick with the RLL controller and disks?
I have used a Priam 738 SCSI disk (337 MB, 20ms) with the Seagate
ST-01 controller for about one and a half years now. For the first
half an year I used it under msdos in a slow 16-MHz 386 machine.
Coretest and others reported transfer rates in the range of 750 KB/sec.
(Check that you have the 0WS jumper installed - without it I only got
something like 500 KB/sec).
About an year ago I purchased Microport Unix System V/386, and wrote
a device driver for the controller and the disk. I posted the driver
here about two weeks ago. The driver has been in use on my system and
a couple of other systems for over an year. The driver has proved to be
very reliable (some problems were reported with Seagate ST227N when
using 1KB sectors, but those disappeared by formatting the drive to
use 512 byte sectors). The driver supports multiple drives and partitions.
My disk is partitioned in three partitions: 10 MB /tmp, 20 MB /u2 and
307 MB /u. (BTW, I have never had any problems with large partitions.
Some people have reported problems in the news.)
I cannot give exact transfer rates under unix. With my original driver
I only got something like 160 KB/sec while reading a large (10-20 MB)
file with dd -bs 64k. That with an interleave of 9 and 1 KB sectors (sic!).
I have since optimized the data transfer routines by writing them
in assembly language. This should probably allow interleaves in the
range 1-3. I have not yet been able to test any other interleaves, as I have
not wanted to reformat the entire disk (it takes quite a while to copy
300 megabytes to floppies and back...) Note that when formatting the disk,
it can be helpful to explicitly specify that mkfs does no interleaving
on the file system level as that is already handled by the drive.
As a reference, measured the same way my 40ms 42MB MFM drive gives
40 kB/sec (sic!). I was not able to improve it from that.
The scsi disk was actually so much faster that I copied /bin and /usr/bin
to the scsi disk (/u/bin & /u/usr/bin) and put those in PATH before
/bin and /usr/bin. The difference is very significant.
The biggest problem with the driver is that during heavy disk activity
the serial lines lose incoming characters. But then I hear this is a
general problem with Microport...
BTW, my driver cannot be used to boot from the scsi disk. I use the
42 MB disk that came with the system for booting and swap (luckily I have
10 MB of ram, so the machine hardly ever swaps).
Tatu Ylonen ylo@sauna.hut.fi
-----------------------------
From: George Robbins <grr@cbmvax.uucp>
Subject: Re: Using the uucp daemon (TCP/IP) on System V.3 with TCP/IP
Date: 9 Jul 89 17:34:01 GMT
Keywords: UUCP TCP/IP uucpd uucico sockets BSD4.3 SysV.3
To: unix-wizards@sem.brl.mil
In article <3674@ursa-major.SPDCC.COM> cspencer@ursa-major.spdcc.COM (Cliff Spencer) writes:
> >>Porting BSD 4.3 UUCP daemon has already been done several times for different
> >>incarnations of TCP/IP implementations for system V Unix's. Unfortunately
> >>none of them are "free" that I know of.
> >I only need the patches, I have the BSD4.3 uucpd source...
>
> What's the big mystery? Doesn't the daemon just spawn /usr/lib/uucp/uucico?
Well, yes and no. It plays with sockets doing a listen and opening a
a connection and then simulates a login and finally runs uucico passing
the open sockets as stdin/stdout. If you have a completely functional
socket-emulation package, it shouldn't be a big deal. Also, your uucp
is expected to know that it shouldn't try to do all those terminal
oriented ioctls on sockets...
--
George Robbins - now working for, uucp: {uunet|pyramid|rutgers}!cbmvax!grr
but no way officially representing arpa: cbmvax!grr@uunet.uu.net
Commodore, Engineering Department fone: 215-431-9255 (only by moonlite)
-----------------------------
End of UNIX-WIZARDS Digest
**************************
---------- end of forwarded message