Sun-Spots Digest, v6n243
William LeFebvre
Sun-Spots-Request at Rice.edu
Sat Oct 1 05:32:34 AEST 1988
SUN-SPOTS DIGEST Thursday, 29 September 1988 Volume 6 : Issue 243
Today's Topics:
Re: Force periodic password changes (3)
Re: How do I tell what version of SunOS is running
Re: NGROUPS problems on SunOS 4.0
Re: Problems with VME address spaces
Saving client disk space under SunOS 4.0
"NFS cache bug"
SunOS 4.0 Fortran Concatenation Problem
SunOS 4.0 vs. QIC
ANSI-C Support
need help getting a program to run on SUNS
copying frame buffers over ethernet?
Send contributions to: sun-spots at rice.edu
Send subscription add/delete requests to: sun-spots-request at rice.edu
Bitnet readers can subscribe directly with the CMS command:
TELL LISTSERV AT RICE SUBSCRIBE SUNSPOTS My Full Name
Recent backissues are available via anonymous FTP from "titan.rice.edu".
For volume X, issue Y, "get sun-spots/vXnY". They are also accessible
through the archive server: mail the request "send sun-spots vXnY" to
"archive-server at rice.edu" or mail the word "help" to the same address
for more information.
----------------------------------------------------------------------
Date: Tue, 27 Sep 88 09:41:15 EDT
From: Skip Montanaro <steinmetz!montnaro at uunet.uu.net>
Subject: Force periodic password changes (1)
Reference: v6n235
In v6n235, Peter Ho writes and wnl responds:
> Does anyone out there have software to force users to change password
> every so often on a SUN?
> ...
> [[ Is this even possible without rewriting "/bin/login"? --wnl ]]
I don't think rewriting /bin/login is necessary. You can get by with a
daemon which maintains user/password/date/shell tuples and monitors changes
to /etc/passwd or the passwd yp database. When a user's password expires, it
changes that user's shell to a program that prompts for a new password. When
a new password is entered, the password monitor daemon can be signalled to
replace the user's shell and reset its user/password/date/shell tuple, then
the user's real shell can be exec'd. Exiting the password change program
without changing the password leaves everything alone.
This isn't really a Sun-specific problem, but is generic to all (?) versions
of UNIX. Perhaps followups should go to the unix-wizards list(s).
Skip Montanaro (montanaro at sprite.steinmetz.ge.com, montanaro at ge-crd.arpa)
------------------------------
Date: Mon, 26 Sep 88 11:15:09 EDT
From: smb at research.att.com
Subject: Re: Force periodic password changes (2)
There's a simple hack that will do it without touching a line of Sun's
code... Write a script that uses awk to extract the userid and password
from /etc/passwd, and stores them in a file. Periodically, run the same
script, and see who's password hasn't changed. Send them a nastygram or
take other appropriate action...
To be sure, this scheme has some drawbacks. It doesn't guard against
folks changing to the same password, and its granularity is determined by
how often you run the script. But it's simple, and will work on most
UNIX(r) systems.
--Steve Bellovin
------------------------------
Date: 27 Sep 88 00:10:29 GMT
From: felix!arcturus!dav at hplabs.hp.com (David L. Markowitz)
Subject: Force periodic password changes (3)
> [[ Is this even possible without rewriting "/bin/login"? --wnl ]]
To which I reply a unqualified Yes! I have done exactly that, using an
approach which fits in between login and the user's shell (by changing
the passwd shell field). It enforces periodic changes, validates
prospective passwords against the on-line dictionary and a few other
obvious guesses, checks for minimum length passwords, and many other
good things. It can be compiled to provide autogeneration of passwords
ala VMS (we don't use this feature anymore - I don't believe in it).
It works in a YP environment and replaces both yppasswd and yppasswdd
(reasonably transparently).
This software belongs to my employer, so I will have to check on its
availability. We are requiring it here on every Unix installation.
David L. Markowitz Rockwell International
...!sun!sunkist!arcturus!dav dav at arcturus.UUCP
[[ Still seems like a bit of a kludge, but it is probably the best you can
do without altering /bin/login. It is clever, tho! --wnl ]]
------------------------------
Date: 26 Sep 88 18:31:42 GMT
From: mkhaw at teknowledge-vaxc.arpa (Mike Khaw)
Subject: Re: How do I tell what version of SunOS is running
Reference: v6n235
> In real BSD UNIX there are a couple of defines in sys/param.h along
> the lines of:
>
> #define BSD 43
> #define BSD4_3 1
>
> which allows one to determine what version of the OS is being used. My
> questions is, "Is there an equivalent for SunOS?"
I don't have SunOS sources, so the best I can say is that /sys/OBJ/vers.o
on my 3.5 system contains the string "Sun Unix 4.2 Release 3.5". I tried
"find /usr/include -name '*.h' -exec fgrep Release {} \;", but got no
matches.
Mike Khaw
--
internet: mkhaw at teknowledge.arpa
uucp: {uunet|sun|ucbvax|decwrl|uw-beaver}!mkhaw%teknowledge.arpa
hardcopy: Teknowledge Inc, 1850 Embarcadero Rd, POB 10119, Palo Alto, CA 94303
------------------------------
Date: 26 Sep 88 18:37:40 GMT
From: mkhaw at teknowledge-vaxc.arpa (Mike Khaw)
Subject: Re: NGROUPS problems on SunOS 4.0
Reference: v6n236
Dan Trinkle (trinkle at cs.purdue.edu):
> Sun decided to increase NGROUPS from 8 to 16 with SunOS 4.0....I could
> Sun saying to hell with other vendors...
Ultrix 2.x changed it from 8 to 64 (or was it 32?), and supports NFS and
yp, so you can accuse DEC of saying to hell with other vendors too (:)).
Mike Khaw
--
internet: mkhaw at teknowledge.arpa
uucp: {uunet|sun|ucbvax|decwrl|uw-beaver}!mkhaw%teknowledge.arpa
hardcopy: Teknowledge Inc, 1850 Embarcadero Rd, POB 10119, Palo Alto, CA 94303
------------------------------
Date: 26 Sep 88 16:16 EST
From: JARMOLOWSKI%ESDSDF.decnet at ge-crd.arpa
Subject: Re: Problems with VME address spaces
Reference: v6n236
We are accessing a device from A SUN 4 using a24d32 addressing with no
problems. I will try out a a24d16 board and try to remember to report it
to the net.
Tom Jarmolowski
------------------------------
Date: Mon, 26 Sep 88 11:22:15 PDT
From: eggert at sm.unisys.com (Paul Eggert)
Subject: Saving client disk space under SunOS 4.0
Jean-Francois Lamy's note in Sun-Spots 6:234 on sharing roots under SunOS
4.0 prompts me to suggest a simpler way of solving the same problem. Just
share the files /vmunix, /kadb, and /sbin/* by using hard links on the
server. As usual, the clients must have the same architecture, and if the
clients are not identical, the shared /vmunix must be configured to handle
all the clients. If your /etc/exports looks like this:
/export/root/client1 -root=client1,access=client2
...
/export/root/clientN -root=clientN,access=clientN
then you can do the change by executing the following commands:
# Halt clients 2 through N first!
cd /export/root
# Link client1's files to client2.
rm -f client2/kadb client2/vmunix client2/sbin/*
ln client1/kadb client1/vmunix client2
ln client1/sbin/* client2/sbin
# Repeat the above, replacing client2 with client3, ..., clientN.
This solution is simpler than Lamy's because you don't have to create all
those symbolic links and directories, you don't have to fiddle with
/etc/rc.single and /etc/exports, and you don't have to change the clients'
/etc/fstab files. It eases maintenance: for example, if you decide to run
statd, you don't have to remember to add /etc/sm, /etc/sm.bak, and
/etc/state to the list of files to relink symbolically. Sharing just
/vmunix, /kadb, and /sbin/* saves the bulk of the disk space: about a
megabyte per client. The rest of the files that are sharable amount to
just 0.05 megabytes per client, but you can share them too if you're
compulsive.
The main disadvantage of this scheme is that clients must trust each
other, because a client root user can modify the shared files. But if
your clients can be trusted, this is an easy way to save a few megabytes.
------------------------------
Date: Mon, 26 Sep 88 15:56:59 EDT
From: Alexander Dupuy <dupuy at columbia.edu>
Subject: "NFS cache bug"
[Kevin J. Maciunas describes a bug where, when root can't read an NFS file
due to permissions, cp fails on the destination, and leaves a 1-page file
of zeros there anyhow]
The reason that cp is failing on the destination, rather than the source,
is that it no longer uses read() to get at the contents of the file. The
new cp uses mmap() to map in the pages, and then uses write() to write
them out. Unfortunately, the mmap call isn't properly checking read
access the the file, and instead, the Permission denied error is being
given when the write call tries to get the data to be written.
The bug may be in the mmap() call, or it may be in the NFS caching code.
What would happen if the first access to the mapped page were not a system
call which could return EPERM? Would you get a segmentation fault?
@alex
------------------------------
Date: 26 Sep 88 17:08:00 EDT
From: John Stewart <WAPJAS at CARLETON.BITNET>
Subject: SunOS 4.0 Fortran Concatenation Problem
An earlier message in Sunspots noted that the following program does not
function correctly under SunOS 4.0 and suggested that the problem was with
the concatenation operator.
program s4bug
character*80 string
10 format (a)
100 write(6,*) 'ENTER STRING: '
read(5,10, err=100) string
ilast = index(string,' ')
string = string(1:ilast - 1) // ' and more string!'
write(6,*) 'ilast: ', ilast
write(6,*) 'string: ', string
GO TO 100
stop
end
The REAL problem is that the assignment statement
string = string(1:ilast - 1) // ' and more string!'
is not permissable according to the Fortran 77 standard. The standard
states that where you have a character assignment
v = e
the character positions in v that are being assigned to MAY NOT be
accessed by the expression e.
To demonstrate that this was in fact the problem, I modified the program
so that a new variable, string2, was assigned to instead of string and
then string2 was assigned to string. The program no longer violated the
Fortran 77 standard and worked correctly.
This isn't a particularily nice restriction to have in Fortran. Most
Fortran users are probably not aware of this restriction. On some
machines the statement will execute properly so the problem may not
appear, as it did in this case, until the program is ported to another
machine.
I believe that this restriction is eliminated in the draft Fortran 8X
standard. It will then be the responsibility of the compiler to determine
that character positions being assigned to MAY also be referenced by the
right hand side expression. If this is the case the compiler will have to
assign the expression to a temp and then assign the temp to the character
variable, which exactly what my modifications to the program did.
Regards.. jas <WAPJAS at CARLETON.BITNET>
------------------------------
Date: Mon, 26 Sep 88 12:26:42 CDT
From: natinst!brian at cs.utexas.edu (Brian H. Powell)
Subject: SunOS 4.0 vs. QIC
Not too long ago, I posted a message asking for help with my QIC tape
drive on a Sun 3/160. Seems that it stopped working when we moved from
SunOS 3.2 to 4.0. Sun insisted we had hardware problems, including a
subtle, almost off-hand remark that mentioned that there were known
problems with "downrev" hardware and SunOS 4.0. ("downrev" == old)
To make an excruciatingly long story short, Sun was right. They made some
software changes in SunOS 4.0 that outdated their older SCSI boards. Near
as I can tell, "older" is defined as up to early 1988. We replaced our
SCSI board with a new one, and things seem to be working fine. New SCSI
boards cost about $1300, by the way.
The merits of using "features" of software to sell hardware could probably
long be debated. The Sun hotline was of very little help, other than
saying that it wasn't a software problem. They were not able to even
describe which SCSI boards were outdated; only a field $ervice engineer
could do that. Fortunately, some of the Sun-Spots readers were able to
point me in the right direction. (Thanks again to everybody who
responded.)
Brian H. Powell
------------------------------
Date: Mon, 26 Sep 88 11:36:55 PDT
From: daven at prost.llnl.gov (David Nelson)
Subject: ANSI-C Support
Is gcc the only source of a (draft) ANSI C compiler for the Sun? When
will Sun support same? (Or does 4.0 support ANSI extensions, and I just
haven't heard?)
daven
------------------------------
Date: 26 Sep 88 16:01:28 GMT
From: wouk at romeo.cs.duke.edu (Arthur Wouk)
Subject: need help getting a program to run on SUNS
I am a user of Fix2, a unix spelling checker system who is faced with
trying to make it run on SUN UNIX. Previously it has run successfully on
BSD 4.2/3 Gould UTX/32 with no problems. However it compiles but aborts
with Segmentation Faults on SUNOS 4.2. [[ That was quick! When did Sun
announce version 4.2? Last I checked they were only up to 4.0.1. --wnl ]]
Has anyone found a list of the needed changes in the source to permit
running on SUNs? Alternatively has anyone developed an equivalent system
for SUNs? Here is the beginning of the manual entry for FIX2 to help you
in responding:
FIX2(1) USER COMMANDS FIX2(1)
NAME
Fix2: Correct spelling errors interactively.
SYNOPSIS
fix2 [-cu] [-s speller] [-h histfile] [-f typofile] textfile [ ... ]
fix2 [-h histfile] -e typofile
DESCRIPTION
Fix2 facilitates the correction of misspellings in a text
file. It operates in two stages. If typofile is not given,
fix2 will run a spelling program to generate a list of
errors. Wrong words are presented one at a time, for quick
previewing. At this time they may be deleted from the error
list, or a "global" substitution pattern may be specified.
A question mark causes a list of the available commands to
be printed.
In the second stage, lines containing the remaining words
are presented, with the suspected word enclosed in square
braces. ([ ]). The user may enter replacement text, type a
newline, (leaving the word unchanged), or type a colon fol-
lowed by a special command. All words matching an erroneous
word will be corrected as specified.
...
After this, the document is corrected and a personal dectionary updated.
------------------------------
Date: 26 Sep 88 20:02 +0100
From: PETITPIERRE Dominique <@relay.cs.net:petitp at cui.uucp>
Subject: copying frame buffers over ethernet?
Problem: we would like to demonstrate a software on the monochrome screen
of a 3/60, and duplicate the displayed image on the screen of another 3/60
on the same network, so that more people can see. Is there a program to
do that?
We have investigated the hardware solution (Y shaped video cable + two
monitors) but it seems that for monochrome displays it cannot be bought of
the shelf, so we would have to build it ourselves. Bad news + expensive!
A software solution seems much better since we have many workstations on
the same network. I have tried a very simple hack:
file a:
while true
do
screendump -c
done
file b:
while true
do
screenload
done
executing 'a | rsh remotehost b &' will do the trick. The refresh rate is
quite slow though. And I wondered if somebody had written a program that
copy directly the frame buffer from the source host to the target host.
Mr. Dominique Petitpierre |EAN, BITNET, EARN, MHS, X.400: petitp at cui.unige.ch
ISSCO, University of Geneva |UUCP: mcvax!cernvax!cui!petitp , petitp at cui.uucp
54 route des Acacias |JANET: petitp%cui.unige.ch at ean-relay.ac.uk
CH-1227 GENEVA (Switzerland)|CSNET, ARPA: petitp%cui.unige.ch at csnet-relay.csnet
Tel: 0041/22/20 93 33 extension 2117
------------------------------
End of SUN-Spots Digest
***********************
More information about the Comp.sys.sun
mailing list