zjat02@apctrc.trc.amoco.com (Jon A. Tankersley) (05/25/89)
The subject says it all. This requires /usr/games to be mounted rw. I can understand things like hack and the like that keep usage information but does fortune really need this? I strip out most of the games, but fortune has kinda universal approval. Would it be better to have it try the rw open and not try to write if it has ro access? Inquiring minds want to know. -tank- #include <std/disclaimer.h> /* nobody knows the trouble I .... */ tank@apctrc.trc.amoco.com ..!uunet!apctrc!tank
hans@duttnph.UUCP (Hans Buurman) (05/25/89)
It's more strange than that. We have sun3 and sun4 clients all running SunOS 4.0.1. All have /usr/games read-only. On the sun3's, this works fine. On sun4's, you get a message: /usr/games/lib/fortunes.dat: Read-only file system There are no other differences between the two fortunes. ----------------------------------------------------------------------------- Hans Buurman | hans@duttnph.UUCP Pattern Recognition Group | Faculty of Applied Physics | mcvax!hp4nl!dutrun!duttnph!hans Delft University of Technology | tel. 31 - (0) 15 - 78 46 94
jik@athena.mit.edu (Jonathan I. Kamens) (05/26/89)
In article <883@apctrc.UUCP> zjat02@trc.amoco.com (Jon A. Tankersley) writes: >The subject says it all. This requires /usr/games to be mounted rw. >I can understand things like hack and the like that keep usage information >but does fortune really need this? I strip out most of the games, but >fortune has kinda universal approval. Would it be better to have it >try the rw open and not try to write if it has ro access? The fortune program doesn't really return a "random" fortune each time it is run. Instead, it goes through the fortunes.dat file sequentially, and each time the program is run it prints out the next appropriate fortune. In order to keep track of where it is in the file, it has to write its current location to the file after each time it reads a fortune. I've looked at the code for a few minutes and it's a bit obscure (to me at least), but this is the general idea of what occurs. Anybody know more details (like the format of the binary data at the beginning of the .dat files, for example)? Jonathan Kamens USnail: MIT Project Athena 410 Memorial Drive, No. 223F jik@Athena.MIT.EDU Cambridge, MA 02139-4318 Office: 617-253-4261 Home: 617-225-8218
jeff@quark.WV.TEK.COM (Jeff Beadles) (05/27/89)
In article <730@dutrun.UUCP> hans@duttnph.UUCP (Hans Buurman) writes: > >It's more strange than that. We have sun3 and sun4 clients all running >SunOS 4.0.1. All have /usr/games read-only. On the sun3's, this works fine. >On sun4's, you get a message: >/usr/games/lib/fortunes.dat: Read-only file system > >There are no other differences between the two fortunes. This is due to the way that you have /usr/games mounted. There are two different styles of /etc/exports (on the server)that I know of. They look like: /usr2 host1 host2 or /usr2 -rw=tango:packrat:pong:vanuatu:abacus If you have the second, make sure that it's mounted rw, and not '-access=' If that does not work, look in /etc/fstab on the client. (I don't have a sun, so I can't be overly specific here...) The reason that fortune writes to the data file is to keep track of the last fortune sent. It's part of how it keeps spitting out random-looking fortunes. Hope it helps, -Jeff -- Jeff Beadles Utek Sustaining Engineering, Tektronix Inc. jeff@quark.WV.TEK.COM
hans@duttnph.UUCP (Hans Buurman) (05/29/89)
In article <3433@orca.WV.TEK.COM> jeff@quark.WV.TEK.COM (Jeff Beadles) writes: >In article <730@dutrun.UUCP> hans@duttnph.UUCP (Hans Buurman) writes: >>It's more strange than that. We have sun3 and sun4 clients all running >>SunOS 4.0.1. All have /usr/games read-only. On the sun3's, this works fine. >>On sun4's, you get a message: >>/usr/games/lib/fortunes.dat: Read-only file system >>There are no other differences between the two fortunes. > >This is due to the way that you have /usr/games mounted. (suggestion to look in /etc/exports on server) Sorry Jeff, but I can't find any differences. grep exec /etc/exports /export/exec/sun3 -ro,access=clients /export/exec/sun4 -ro,access=clients >If that does not work, look in /etc/fstab on the client. mizar grep exec /etc/fstab duttnph:/export/exec/sun3 /usr nfs ro 0 0 antares grep exec /etc/fstab duttnph:/export/exec/sun4 /usr nfs ro 0 0 mizar df /usr/games/fortune Filesystem kbytes used avail capacity Mounted on duttnph:/export/exec/sun3 84928 61587 14848 81% /usr antares df /usr/games/fortune Filesystem kbytes used avail capacity Mounted on duttnph:/export/exec/sun4 84928 71671 4764 94% /usr mizar /usr/games/fortune A rock pile ceases to be a rock pile the moment a single man contemplates it, bearing within him the image of a cathedral. -- Antoine de Saint-Exupery antares /usr/games/fortune /usr/games/lib/fortunes.dat: Read-only file system And, on the server: ls -l /export/exec/sun[34]/games/lib/fortunes.dat -rw------- 1 daemon 348056 Apr 9 1988 /export/exec/sun3/games/lib/fortunes.dat -rw------- 1 daemon 348056 May 29 09:25 /export/exec/sun4/games/lib/fortunes.dat (Of course, the server is a sun4 and has /usr/games r/w !). >Jeff Beadles Utek Sustaining Engineering, Tektronix Inc. >jeff@quark.WV.TEK.COM Both architectures are running SunOs 4.0.1 Export. Anybody out there with source ? Hans ----------------------------------------------------------------------------- Hans Buurman | hans@duttnph.UUCP Pattern Recognition Group | Faculty of Applied Physics | mcvax!hp4nl!dutrun!duttnph!hans Delft University of Technology | tel. 31 - (0) 15 - 78 46 94
zjat02@cra2.uucp (Jon A. Tankersley) (05/31/89)
They all break with 4.0.3. Sigh. Seems that someone didn't trust random() very much. Or any of his brothers()/sisters() :-). I wrote my own for a 3b2 and it worked just fine, but then I didn't look for long/short/obscene fortunes, but still. Don't look for an early fix. Since it is a game (or is it?) it won't be a high priority problem. An alternative would be to have fortune aliased to fortune with a file spec. Progress! -tank- #include <std/disclaimer.h> /* nobody knows the trouble I .... */ tank@apctrc.trc.amoco.com ..!uunet!apctrc!tank
guy@auspex.auspex.com (Guy Harris) (06/01/89)
>They all break with 4.0.3. Sigh. Seems that someone didn't trust random() >very much. "fortune" antedates "random"; I think the "someone" is the (aforementioned) Ken Arnold, and I'm told the reason why it does what it does is that, in fact, he didn't like "rand()" (which is not, I think, one of the best random number generators in the world). >Don't look for an early fix. Since it is a game (or is it?) it won't be >a high priority problem. An alternative would be to have fortune aliased >to fortune with a file spec. It's been mentioned to people at Berkeley, and will probably get fixed at some point (however, since it's in "/usr/games", I don't know how high-priority an item it is). Sun, and other vendors, may pick that up when it comes out, or may fix it themselves.