" Maynard) (11/18/89)
I've run through this stuff so many times it's confusing me.
Which user id should unshar the C news sources?
Which user id should own the programs?
Which user id should run build?
I ran into problems doing doit.bin as myself, and specifying -i didn't
help: it got so far, then blew up because it couldn't change a file.
Then I su'd to root, ran find . -exec chown bin {} \; , and tried it
again...and again...and again...only to have this %&^$*$^%#$#%@
Microbug...er...Microport shell dump core while trying to build
doit.bin. Argh!
On top of all this, I've lost count of the times I've had to abort build
because I forgot to tell it that I don't have mkdir(), or that my chown
is /bin/chown, or... Can't build be set up to remember what it did last
time? (Yes, Henry, I'll make the changes if you'd like.)
Finally, when I find a copy of dbz 1.9 (I thought I'd saved it, but
can't find it now), am I going to have to go through all of this again?
--
Jay Maynard, EMT-P, K5ZC, PP-ASEL | Never ascribe to malice that which can
jay@splut.conmicro.com (eieio)| adequately be explained by stupidity.
{attctc,bellcore}!texbell!splut!jay +----------------------------------------
Shall we try for comp.protocols.tcp-ip.eniac next, Richard? - Brandon Allberyespo@bpa.BELL-ATL.COM (Bob Esposito) (11/19/89)
In article <3054@splut.conmicro.com> jay@splut.conmicro.com (Jay "you ignorant splut!" Maynard) writes: > >On top of all this, I've lost count of the times I've had to abort build >because I forgot to tell it that I don't have mkdir(), or that my chown >is /bin/chown, or... Can't build be set up to remember what it did last >time? (Yes, Henry, I'll make the changes if you'd like.) > >Finally, when I find a copy of dbz 1.9 (I thought I'd saved it, but >can't find it now), am I going to have to go through all of this again? > Where can I get a copy of dbz 1.9 ??? The latest copy I have is 1.5 which came with the C-news distribution. You can respond via E-mail to espo@bpa.BELL-ATL.COM -- Bob Esposito uucp: espo@bpa.bell-atl.com, {rutgers|bellcore}!bpa!espo Bell of Pennsylvania inet: espo@phlsun.prepnet.com Philadelphia, PA. phone: +1 215 466 6831 packet: N3CTA @ N3CTA 44.80.0.93 ===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===
henry@utzoo.uucp (Henry Spencer) (11/19/89)
In article <3054@splut.conmicro.com> jay@splut.conmicro.com (Jay "you ignorant splut!" Maynard) writes: >Which user id should unshar the C news sources? >Which user id should own the programs? >Which user id should run build? The generic answer is "it depends on what you want". On utzoo, the answer is the same for all three: "bin". You should definitely run build, and the programs it creates, as someone who has permission to write in the source directories (e.g., the uid that unsharred the sources). It is convenient to have the programs (except the two setuid ones) owned by the source owner. If there is no uid that has permission to write on both the source directories and the programs, you will have to compile as one user and then do the installation as another. (The current build warns you about this.) General paranoia suggests using a source/program uid that is not the one the news subsystem will run under, i.e. is not "news" or your equivalent. We're old-fashioned and prefer to work as bin to avoid the hazards of making mistakes while running as root. Some people running NFS prefer to make everything root-owned, in the misguided belief that this provides some extra degree of security. >On top of all this, I've lost count of the times I've had to abort build >because I forgot to tell it that I don't have mkdir(), or that my chown >is /bin/chown, or... Can't build be set up to remember what it did last >time? ... This is coming. Just to clarify: this will *not* be a "configuration file" that you can edit, it will merely be a way to have build use your last set of answers as the defaults for a new run. Making the former work right is very difficult, while the latter is not too hard (although it requires some overhaul of build, so don't expect it next week -- dbz has priority). -- A bit of tolerance is worth a | Henry Spencer at U of Toronto Zoology megabyte of flaming. | uunet!attcan!utzoo!henry henry@zoo.toronto.edu
" Maynard) (11/20/89)
In article <1989Nov19.001714.25018@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes: >>Which user id should unshar the C news sources? >>Which user id should own the programs? >>Which user id should run build? >The generic answer is "it depends on what you want". On utzoo, the answer >is the same for all three: "bin". You should definitely run build, and >the programs it creates, as someone who has permission to write in the >source directories (e.g., the uid that unsharred the sources). It is >convenient to have the programs (except the two setuid ones) owned by >the source owner. If there is no uid that has permission to write on >both the source directories and the programs, you will have to compile >as one user and then do the installation as another. (The current build >warns you about this.) I finally wound up: find . -exec chown bin {} \; build su doit.root su bin sh; unset _; doit.bin (because of a bug in Microport make) ^d^d su usenet sh; unset _; doit.news ^d^d again.root ...which ran everything as expected. I ignored the "can't change foo" messages from build, since they'd already been changed before. (I couldn't run build as bin because it'd dump core. argh.) >This is coming. Just to clarify: this will *not* be a "configuration file" >that you can edit, it will merely be a way to have build use your last set >of answers as the defaults for a new run. That's all I'm asking for - remember the last answers as the defaults for the new answers, a la Larry Wall's Configure stuff. BTW, it seems to work well with dbz 1.9 (I found my copy - in /usr/spool/news, of all places) and no INCORE defined (per the comment about 16 bit systems). -- Jay Maynard, EMT-P, K5ZC, PP-ASEL | Never ascribe to malice that which can jay@splut.conmicro.com (eieio)| adequately be explained by stupidity. {attctc,bellcore}!texbell!splut!jay +---------------------------------------- Shall we try for comp.protocols.tcp-ip.eniac next, Richard? - Brandon Allbery
gnb@bby.oz (Gregory N. Bond) (11/20/89)
In article <3054@splut.conmicro.com> jay@splut.conmicro.com (Jay "you ignorant splut!" Maynard) writes: On top of all this, I've lost count of the times I've had to abort build because I forgot to tell it that I don't have mkdir(), or that my chown is /bin/chown, or... Can't build be set up to remember what it did last time? (Yes, Henry, I'll make the changes if you'd like.) Well, the n-thousandth time I ran build, I hacked in a new feature: a shell function for read (yes, I know, non-portable) that, given stdin from a tty just did a read, otherwise did an echo and a line number. You can the say tee input | ./build first time round, and from then on ./build < input The line numbers in the output from build help in correcting the mistakes in the input file. Yes. This is ugly. Insert near the top of build: if test -t 0 ; then read=read else read=my_read lineno=0 my_read () { read inp lineno=`expr $lineno + 1` echo $inp " [line $lineno]" eval $1='"$inp"' } fi Then replace all occurences of /^[ \t]*read/ with $read. When run, it gives an output like: What user id should be used for news files [news]? news [line 1] What group id should be used for news files [news]? news [line 2] What user id should be used for news programs [bin]? bin [line 3] What group id should be used for news programs [bin]? staff [line 4] Do the C News sources belong to bin [yes]? y [line 5] You can fire up vi (unless you spilled jelly on the keyboard!) and edit the input file until it works. Henry, have you considered using lwall's configure suite? -- Gregory Bond, Burdett Buckeridge & Young Ltd, Melbourne, Australia Internet: gnb@melba.bby.oz.au non-MX: gnb%melba.bby.oz@uunet.uu.net Uucp: {uunet,pyramid,ubc-cs,ukc,mcvax,prlb2,nttlab...}!munnari!melba.bby.oz!gnb
jeffrey@algor2.algorists.com (Jeffrey Kegler) (11/20/89)
In article <3054@splut.conmicro.com> jay@splut.conmicro.com (Jay "you ignorant splut!" Maynard) writes: >On top of all this, I've lost count of the times I've had to abort build >because I forgot to tell it that I don't have mkdir(), or that my chown >is /bin/chown, or... Can't build be set up to remember what it did last >time? (Yes, Henry, I'll make the changes if you'd like.) What I did as a workaround is create a prompt-less version of build (build.algor2) with all my answers hacked into it. To make a minor change in the C news configuration, I hack build.algor2. I always have the option of falling back to the build script. I have suggested to Henry by Email that he create an editable configuration file, build.out, so the process looks something like: build --> build.out --> doit.*, again.root --> ... Henry is reluctant to do this because keeping the installer from editing build.out into garbage (or producing warnings when he does) would be difficult and I guess he does not want to be associated with a approach that lacks these checks. I have also suggested that a shell script that checked permissions on all C News files would help installers. I do not think it would be difficult, but don't have the time to do it myself right now :-). -- Jeffrey Kegler, Independent UNIX Consultant, Algorists, Inc. jeffrey@algor2.ALGORISTS.COM or uunet!algor2!jeffrey 1762 Wainwright DR, Reston VA 22090
davidsen@crdos1.crd.ge.COM (Wm E Davidsen Jr) (11/20/89)
In article <1989Nov20.120629.28412@algor2.algorists.com> jeffrey@algor2.ALGORISTS.COM (Jeffrey Kegler) writes: | I have suggested to Henry by Email that he create an editable | configuration file, build.out, so the process looks something like: | build --> build.out --> doit.*, again.root --> ... Some other programs build a file of defaults, so that when rebuilding the previous *user input* is the default. This is reasonably convenient, although it takes a bit of though for programs which have some input as multiline data. -- bill davidsen (davidsen@crdos1.crd.GE.COM -or- uunet!crdgw1!crdos1!davidsen) "The world is filled with fools. They blindly follow their so-called 'reason' in the face of the church and common sense. Any fool can see that the world is flat!" - anon
henry@utzoo.uucp (Henry Spencer) (11/21/89)
In article <GNB.89Nov20152916@baby.bby.oz> gnb@bby.oz (Gregory N. Bond) writes: >Henry, have you considered using lwall's configure suite? Yes. We're not impressed by the way it crashes and burns on systems that are BSD/SysV hybrids, especially since many modern systems are such. It has this ingrained notion that the world is divided into 4BSD and System V and your system *must* be one or the other. More generally, it tries to be very clever and consequently has a lot of wired-in assumptions, and it fails badly when those assumptions fail. Our stuff needs a lot more hand-holding but is more portable. -- A bit of tolerance is worth a | Henry Spencer at U of Toronto Zoology megabyte of flaming. | uunet!attcan!utzoo!henry henry@zoo.toronto.edu
mark@jhereg.Minnetech.MN.ORG (Mark H. Colburn) (11/21/89)
In article <1989Nov20.183239.1809@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes: >Yes. We're not impressed by the way it crashes and burns on systems that >are BSD/SysV hybrids, especially since many modern systems are such. It >has this ingrained notion that the world is divided into 4BSD and System V >and your system *must* be one or the other. More generally, it tries to >be very clever and consequently has a lot of wired-in assumptions, and >it fails badly when those assumptions fail. Our stuff needs a lot more >hand-holding but is more portable. While it is true that some of the assumptions in the currently distributed scripts are not correct, I would like to point out that it is possible to (somewhat easily) change these assumptions. Each of the assumptions for a particular area (such as directory library icnlude file) is encapsulated in a particular "unit". Each unit has a specific structure which allows the ultimate configure script to be built from it. The package implementor can go through and modify the units to represent better assumptions, making the configure script more robust. And while configure does get some things wrong, it handles a fair number of cases correctly. It has also been getting better about it's "the world is either BSD or USG assumptions." It may be that using it would be more pain than its worth, but you might at least take a quick look at it. Also, but the number of times it gets suggested, it looks like most people have had good experiences with it in the past. -- Mark H. Colburn mark@Minnetech.MN.ORG Open Systems Architects, Inc.
jbuck@epimass.EPI.COM (Joe Buck) (11/23/89)
In article <GNB.89Nov20152916@baby.bby.oz> gnb@bby.oz (Gregory N. Bond) writes: >>Henry, have you considered using lwall's configure suite? In article <1989Nov20.183239.1809@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes: >Yes. We're not impressed by the way it crashes and burns on systems that >are BSD/SysV hybrids, especially since many modern systems are such. It >has this ingrained notion that the world is divided into 4BSD and System V >and your system *must* be one or the other. I can only conclude that you haven't used the Configure scripts Larry is producing these days (as opposed to rn, which, after all, came out in 1984) and that you haven't seen metaconfig, since it most emphatically doesn't do that. Generally, I have pretty good results with Configure on a Masscomp, which is a hybrid system. The generated scripts don't assume a library function is there because it's a Sys V; it runs nm on the C library and finds the routine. For known nonportabilities that affect the program operation, a test program is generated. There is some leftover cruft that goes back to the days when Larry was making some of the mistakes you're talking about. And it's far from perfect; the test to decide whether a system has terminfo as opposed to termcap fails on Ultrix systems, for example. But your main criticism is no longer valid, and Larry continually takes feedback and improves the system. -- -- Joe Buck, just visiting/consulting at Entropic -- write me at: jbuck@janus.berkeley.edu ...!{uunet,ucbvax}!janus.berkeley.edu!jbuck