pauld@cs.washington.edu (Paul Barton-Davis) (04/27/91)
Last night, working "off-campus" as they say, I tried to move a bunch
of device driver files, application development directories and other
stuff from one system to another. Problem - company has 2 licenses for
SCO Unix/386, not 3. The intention was to get this new box up as a
replacement for the one the work was originally carried out on, and
then revert the old version back to DROS. Because of this, we had
"re"installed license copy #2 on the new box, figuring that
duplication for a few hours for the purpose of copying out own files
from one disk to another was legitimate. After several diskettes
worth of cpio-ing, we gave up and decided to hook both systems
together on the net, and nfs mount one on the other. Problem - I
should have remembered the posting on this from before.
As a result, I am now intimately familiar with SCO's copy daemon (cpd)
that is a prerequisite to running any network software on an SCO
system. What of source happened, as readers with even moderately short
memories will recall, is that I got a message saying "message detected
from system with duplicate license". Under some circumstances, the box
then locks up.
\begin{Mr. Angry}
What is it with SCO that makes them think they are this special that
they have to intoduce this type of system ? What happened to honor
systems and all that ? This sucks, big big time. Not because we wanted
to violate our license agreement, but because we needed to move from
one box to another (with different drives), I get to spend an extra 4
hours, first figuring out what the f*** was going on, and then doing a
3rd party NFS copy (onto the first licensed system) and back again.
At the place I worked before UW, we used ISC and purchased licenses
for every copy we used. However, we shipped several systems out at at
time to clients, and used dd to do complete disk copies, avoiding the
ridiculous overhead of having to reinstall both Unix and our
applications. Hence, pretty much every system we ever shipped (or used
internally) was derived from *one copy* even though we had licenses
for many more. You can probably see why there is *NO* chance
whatsoever of that company EVER buying SCO. They actually have several
complete Unix root+usr+tmp partitions as dd'ed files on read-write
opticals - wanna new system: just format the disk, and dd the relevant
system straight onto it. Quick, efficient, easy and generally
foolproof.
I understand SCO's desire to restrict copying, but a tcp/ip daemon
that messes with the O/S when it detects multiple licenses is a
disgusting and extremely un-VAR-friendly way to do it. In revenge, I
have contemplated disassembling cpd, patching the binary, and making
this new version available to anyone that asks ... (just kidding, maybe).
Now, of course, the old system is running DOS, the new system (with
the 2nd license) is up and running, and all is well. But boy, do I get
mad at 1am when I have to deal with yet another "SCO value added
extension" whose primary purpose seems to be to question my honesty
and as a side effect, make my life more difficult. If SCO paid the
same attention to security that ISC did to a bug-free TCP/IP, we'd
all be better off. And, yes, you can interpret that last one any way
you want.
\end{Mr. Angry}
--
Paul Barton-Davis <pauld@cs.washington.edu> UW Computer Science Lab
"People cannot cooperate towards common goals if they are forced to
compete with each other in order to guarantee their own survival."sl@wimsey.bc.ca (Stuart Lynne) (04/28/91)
In article <1991Apr26.181047.21554@beaver.cs.washington.edu> pauld@cs.washington.edu (Paul Barton-Davis) writes: }worth of cpio-ing, we gave up and decided to hook both systems >together on the net, and nfs mount one on the other. Problem - I }should have remembered the posting on this from before. } }As a result, I am now intimately familiar with SCO's copy daemon (cpd) }that is a prerequisite to running any network software on an SCO }system. What of source happened, as readers with even moderately short }memories will recall, is that I got a message saying "message detected }from system with duplicate license". Under some circumstances, the box }What is it with SCO that makes them think they are this special that }they have to intoduce this type of system ? What happened to honor }systems and all that ? This sucks, big big time. Not because we wanted This has been complained about before and there is a new cpd hiding in one of the fix disks available from SCO. The new cpd only does it's thing when you boot up. And then it only put's out a polite message on the system console. At least it does for only two copies the same. When I re-installed one of the systems last week I guessed at which serial went with that machine and got it wrong. I guess I should rebrand cpd but it doesn't seem to be a bother with it's polite message the way it is. -- Stuart Lynne Computer Signal Corporation, Canada ...!van-bc!sl 604-937-7785 604-937-7718(fax) sl@wimsey.bc.ca
ralfi@pemcom.pem-stuttgart.de (Ralf U. Holighaus) (04/29/91)
pauld@cs.washington.edu (Paul Barton-Davis) writes: >"re"installed license copy #2 on the new box, figuring that >duplication for a few hours for the purpose of copying out own files >from one disk to another was legitimate. In fact, from the legal point of view, it is NOT legitimate. >opticals - wanna new system: just format the disk, and dd the relevant >system straight onto it. Quick, efficient, easy and generally >foolproof. You could do so with SCO, and then usr /etc/brand for the system speci- fic files to 'brand' the new system to the new serial numbers. >and as a side effect, make my life more difficult. If SCO paid the >same attention to security that ISC did to a bug-free TCP/IP, we'd >all be better off. [...] On the other side: they obviously paid more attention to security than ISC. Or did you read hundreds of news messages concerning 'SCO security bug'? I remember well the 'ISC security bug'... -- PEM Programmentwicklungsgesellschaft | Ralf U. Holighaus fuer Microcomputer mbH | Technical Support PO-Box 810165 D-7000 Stuttgart 80 Germany | holighaus@PEM-Stuttgart.de VOICE: x49-711-713045 FAX: x49-711-713047 | ..!unido!pemcom!ralfi
mju@mudos.ann-arbor.mi.us (Marc Unangst) (04/30/91)
ralfi@pemcom.pem-stuttgart.de (Ralf U. Holighaus) writes: > You could do so with SCO, and then usr /etc/brand for the system speci- > fic files to 'brand' the new system to the new serial numbers. No, you can't. "brand" does just what its name implies -- it brands the file permanently with a serial number. It's impossible to re-brand a file. > On the other side: they obviously paid more attention to security than > ISC. Or did you read hundreds of news messages concerning 'SCO security No, they didn't. They paid more attention to making sure that you can't illegally copy their software, when they should have been paying attention to things like X11R4, Motif 1.1, the BSD FFS, symbolic links, System Vr4.0, a working telnet(1), real HDB UUCP, and commands like su(1) and cron(1) that work the way I expect them to. -- Marc Unangst | mju@mudos.ann-arbor.mi.us | "Bus error: passengers dumped" ...!hela!mudos!mju |
wul@sco.COM (Wu Liu) (05/01/91)
/--mju@mudos.ann-arbor.mi.us (Marc Unangst) said... | ralfi@pemcom.pem-stuttgart.de (Ralf U. Holighaus) writes: | > You could do so with SCO, and then usr /etc/brand for the system speci- | > fic files to 'brand' the new system to the new serial numbers. | | No, you can't. "brand" does just what its name implies -- it brands | the file permanently with a serial number. It's impossible to | re-brand a file. \-- Not quite true. I believe this was the case for Unix 3.2.0, but Unix 3.2v2 and both Open Desktop releases (1.0 and 1.1) allow for rebranding of the system with new, different serial numbers.
erik@gogoman.sf.ca.us (Erik Fortune) (05/01/91)
Marc Unangst writes: >ralfi@pemcom.pem-stuttgart.de (Ralf U. Holighaus) writes: >> You could do so with SCO, and then usr /etc/brand for the system speci- >> fic files to 'brand' the new system to the new serial numbers. > >No, you can't. "brand" does just what its name implies -- it brands >the file permanently with a serial number. It's impossible to >re-brand a file. Curious. The troubleshooting tips in my SCO documentation tell me how to use /etc/brand to rebrand an object file. This is the second inaccurate flame about SCO I've seen today. Do you guys make any attempt to verify the things you bitch about or do you just make this s*it up? -- Erik
larryp@sco.COM (Larry Philps) (05/01/91)
In <91V712w164w@mudos.ann-arbor.mi.us> mju@mudos.ann-arbor.mi.us (Marc Unangst) writes: > ralfi@pemcom.pem-stuttgart.de (Ralf U. Holighaus) writes: > > You could do so with SCO, and then usr /etc/brand for the system speci- > > fic files to 'brand' the new system to the new serial numbers. > > No, you can't. "brand" does just what its name implies -- it brands > the file permanently with a serial number. It's impossible to > re-brand a file. This is untrue! It was the case with Unix 3.2.0, but with Unix 3.2v2 and ODT 1.1 files can be rebranded. The shell script /etc/serialize will rebrand an entire package. > > On the other side: they obviously paid more attention to security than > > ISC. Or did you read hundreds of news messages concerning 'SCO security > > No, they didn't. They paid more attention to making sure that you > can't illegally copy their software, when they should have been paying > attention to things like X11R4, Motif 1.1, the BSD FFS, symbolic > links, System Vr4.0, a working telnet(1), real HDB UUCP, and commands > like su(1) and cron(1) that work the way I expect them to. Gee, I guess all we need for a product marketing department is a single clerk with your phone number! > -- > Marc Unangst | > mju@mudos.ann-arbor.mi.us | "Bus error: passengers dumped" > ...!hela!mudos!mju | --- Larry Philps, SCO Canada, Inc. Postman: 130 Bloor St. West, 10th floor, Toronto, Ontario. M5S 1N5 InterNet: larryp@sco.COM or larryp%scocan@uunet.uu.net UUCP: {uunet,utcsri,sco}!scocan!larryp Phone: (416) 922-1937 Fax: (416) 922-8397
ronald@robobar.co.uk (Ronald S H Khoo) (05/02/91)
mju@mudos.ann-arbor.mi.us (Marc Unangst) writes: > No, you can't. "brand" does just what its name implies -- it brands > the file permanently with a serial number. It's impossible to > re-brand a file. Actually, I think some of the current stuff *can* be re-branded, but even if you couldn't, you can always keep a copy of the unbranded file around, and copy it before branding -- I do this on robobar's customised installation tapes, so that we can ship preconfigured stuff around to our customers without having to worry about installation engineers getting it wrong. Saves time too, and time is money. The branded serial numbers do have problems, but not being able to re-brand *isn't* one of them. -- Ronald Khoo <ronald@robobar.co.uk> +44 81 991 1142 (O) +44 71 229 7741 (H)
sef@kithrup.COM (Sean Eric Fagan) (05/05/91)
In article <91V712w164w@mudos.ann-arbor.mi.us> mju@mudos.ann-arbor.mi.us (Marc Unangst) writes: >X11R4, Mayhap. But SCO didn't do the port of X, Locus did, and people at sco were very unhappy with them. (At least some of the engineers were.) >Motif 1.1, As far as I know, it wasn't out at the time. Or don't you realize that it's somewhat difficult to release something that doesn't exist? >the BSD FFS, Why? The BSD FFS would have been a terrible bitch to port. It was easier to make their own FFS, and later add in long filenames. (When they release 3.2v3, I think I shall post a patch showing how to make the filename limit go from 255 to 266 8-).) >symbolic links, What makes you think they *didn't*? >System Vr4.0, A piece of crap. Buggy as hell, larger than 3.2, slow, ugly. >real HDB UUCP, Gee. I've never had any problems with their uucp, and I used it quite extensively for over two years. >and commands like su(1) and cron(1) that work the way I expect them to. Yeah. You're right. They never did anything about this. And that SLS (available from sco [maybe uunet, too, I don't know]) which is corrects the C2 problems (they only way I notice the c2 stuff anymore is because passwords aren't in /etc/passwd; however, this can be a good thing) therefore doesn't exist. Why don't you try actually seeing what is released instead of being an asshole and complaining? -- Sean Eric Fagan | "I made the universe, but please don't blame me for it; sef@kithrup.COM | I had a bellyache at the time." -----------------+ -- The Turtle (Stephen King, _It_) Any opinions expressed are my own, and generally unpopular with others.
allbery@NCoast.ORG (Brandon S. Allbery KB8JRR/AA) (05/05/91)
As quoted from <1991May04.194857.12216@kithrup.COM> by sef@kithrup.COM (Sean Eric Fagan): +--------------- | In article <91V712w164w@mudos.ann-arbor.mi.us> mju@mudos.ann-arbor.mi.us (Marc Unangst) writes: | >real HDB UUCP, | | Gee. I've never had any problems with their uucp, and I used it quite | extensively for over two years. +--------------- Ever try to talk to an existing system with an eight-character system name and validation turned on? Get rid of the bloody HDB-ized V7 UUCP and port the real thing already. (And lose the stupid dialer programs --- the Dialers file manages to work as intended.) ++Brandon -- Me: Brandon S. Allbery Ham: KB8JRR/AA 10m,6m,2m,220,440,1.2 Internet: allbery@NCoast.ORG (restricted HF at present) Delphi: ALLBERY AMPR: kb8jrr.AmPR.ORG [44.70.4.88] uunet!usenet.ins.cwru.edu!ncoast!allbery KB8JRR @ WA8BXN.OH
larry@nstar.rn.com (Larry Snyder) (05/05/91)
sef@kithrup.COM (Sean Eric Fagan) writes: >>X11R4, >Mayhap. But SCO didn't do the port of X, Locus did, and people at sco were >very unhappy with them. (At least some of the engineers were.) hmm.. that's a good reason why not to ship a product (the engineers at SCO were pissed off with Locus).. >>Motif 1.1, >As far as I know, it wasn't out at the time. Or don't you realize that it's >somewhat difficult to release something that doesn't exist? Motif 1.1 has been available for some time, and it corrects some serious bugs in previous releases >>the BSD FFS, >Why? The BSD FFS would have been a terrible bitch to port. It was easier >to make their own FFS, and later add in long filenames. (When they release >3.2v3, I think I shall post a patch showing how to make the filename limit >go from 255 to 266 8-).) Yes - SCO once again going off and doing their own thing without any consideration for standards - and the way non-SCO applications will run.. >>System Vr4.0, >A piece of crap. Buggy as hell, larger than 3.2, slow, ugly. and 3.2 wasn't buggy when SCO first got their hands on it? Likewise Xenix - I remember the first couple of Xenix releases :) It's a new product with lots of features and enhancements - and regardless if SCO likes it or not, it will soon be the industry standard. All of us know that - and sooner or later SCO will need to jump on the SVR4 bandwagon >Why don't you try actually seeing what is released instead of being an >asshole and complaining? everyone is an asshole since you left sco the sco sales rep calls me on a regular basis checking up on "what unix have we decided to OEM" and telling me over and over that SCO is the industry leader. I asked her if she was including Xenix licenses in her "We have more UNIX licenses out there than all the other vendors combined" line - and she said she didn't know (at least she was honest) -- SCO has a refined product - with good documentation - but I don't like their marketing approach (like car salesmen). Their original quote wanted 10K plus 3.5K per year just for the rights to OEM UNIX (this 10K gave us the installation tools to load UNIX - and didn't include any copies of UNIX). On her next call she asked what I thought - and I told her. The following week, she told me that we didn't need the "Mass Installation Tools". I like Interactives 3.2 the best of all the UNIX products - and Dell for SVR4. Dell will ship hardware with UNIX installed which is a timesaver - but the margins are quite slim (on the hardware - software margins are slim as well, but the product is very reasonably priced).. We shall see - the evualation process continues.. -- Larry Snyder, NSTAR Public Access Unix 219-289-0287/317-251-7391 HST/PEP/V.32/v.32bis/v.42bis regional UUCP mapping coordinator {larry@nstar.rn.com, ..!uunet!nstar.rn.com!larry}
cpcahil@virtech.uucp (Conor P. Cahill) (05/06/91)
I almost didn't respond because you two have gotten down to name calling instead of trying to discuss things reasonably, but I thought I would throw my $.02 in anyway: sef@kithrup.COM (Sean Eric Fagan) writes: >Read my lips: SysVr4 was *not* shipping when SCO shipped 3.2.0. When SCO >started shipping 3.2v2, SysVr4 was shipping from a couple of vendors, but >was still buggy, huge, and slow. (Not that 3.2v2 wasn't buggy, huge, or >slow, but it was somewhat better in all three respects than the SysVr4's >I've seen and played with.) Yes compared to 3.2, 4.0 is huge and buggy (I'm not convinced it is slow). However, when SCO decided to release 3.2, IT was huge and buggy when compared to Xenix, so that reason does not seem to be a show stopper for them. They must have some other reasons like, "it took X $$ to get 3.2 up and running and stable, so we need to stay with 3.2 long enough to make a profit off that $$", or "we came close to loosing alot of customers over that 'dropping Xenix' stuff and we can't do the same thing again, but we don't want to support 3 different OS products" -- Conor P. Cahill (703)430-9247 Virtual Technologies, Inc. uunet!virtech!cpcahil 46030 Manekin Plaza, Suite 160 Sterling, VA 22170
gar@spiff.UUCP (Gordon Runkle) (05/06/91)
In article <1991May04.194857.12216@kithrup.COM> sef@kithrup.COM (Sean Eric Fagan) writes: In article <91V712w164w@mudos.ann-arbor.mi.us> mju@mudos.ann-arbor.mi.us (Marc Unangst) writes: >System Vr4.0, A piece of crap. Buggy as hell, larger than 3.2, slow, ugly. I must take issue with this. I use SCO UNIX, SCO XENIX, and SVR4. SVR4 is far and away the superior product. For example, I can network with BSD machines much better (lp works accross the net), whereas SCO's products require some unfortunate "rsh" (or for SCO, "rcmd") hacks to get an impoverished imitation of network printer services. As far as the 'buggy as hell' assertion, this seems to echo SCO's official position, and is not consistent with reality. I've not encountered any showstoppers in SVR4. (SCO didn't complain when SCO UNIX 3.2v0 was 'buggy as hell'.) The next version of SVR4 (version 3) should fix the few remaining annoyances. Yes, it's larger than 3.2. That's largely because it does more. (Better VM, VFS, etc). Slow? Doesn't look too slow to me, and I'm not even running it on "hot" hardware. Ugly? Seems a pretty subjective statement to me. -=gordon=- -- Gordon A. Runkle, Runkle Research UUCP: uunet!cmi486!spiff!gar INTERNET: gar@spiff.cminc.com PHONE: 703-522-0825 The difference between 'theory' and 'practice' in theory is less than the difference between 'theory' and 'practice' in practice. --Unknown sage
davidsen@sixhub.UUCP (Wm E. Davidsen Jr) (05/08/91)
In article <1991May04.194857.12216@kithrup.COM> sef@kithrup.COM (Sean Eric Fagan) writes: | Why? The BSD FFS would have been a terrible bitch to port. It was easier | to make their own FFS, and later add in long filenames. (When they release | 3.2v3, I think I shall post a patch showing how to make the filename limit | go from 255 to 266 8-).) Be still, my throbbing heart! You, too, can have filenames longer than the files they describe! And create filesystems no one else in the world can read. Is that part of the security package? | >System Vr4.0, | | A piece of crap. Buggy as hell, larger than 3.2, slow, ugly. Hogwash! V.4 has lots of rough edges, but for reliability it seems to be just fine. And unlike ODT you can leave a system without a login for a few days and not have the TCP all go away. SCO got their reputation for reliability with Xenix, which (in standard configurations) has fewer failure modes than a bowling ball. The UNIX has never reached the same level of reliability, although it has lots of new features. It is larger than 3.2, and almost as big as ODT 1.0, the kernel which made us change floppy drives because the production kernel wouln't fit on a 1.2MB floppy. As for slow, you should bite your tongue, I have some lovely database benchmarks which compare V.4, ODT, ISC, and Xenix. You wouldn't want to see them in a magazine article. V.4 has fast and slow points, and is generally very acceptable for performance. | >and commands like su(1) and cron(1) that work the way I expect them to. | | Yeah. You're right. They never did anything about this. And that SLS | (available from sco [maybe uunet, too, I don't know]) which is corrects the | C2 problems (they only way I notice the c2 stuff anymore is because | passwords aren't in /etc/passwd; however, this can be a good thing) | therefore doesn't exist. I have a friend who has a glass eye. He's gotten used to his handicaps, too, and the only way he notices it is when he can't see. I have a little utility which lets you change the password under SCO UNIX. One I never needed with any other vendor's system. It does something SCO never envisioned: it assumes the root user is competent and if he wants to set the password on root to 'x' it will do it, and not tell him it's too short, obvious, or has already been changed recently. This is with the new release of ODT which has been on order for a few months and was delivered yesterday. We didn't install the security SLS because its supposedly there, although I probably will this week. I give SCO a lot of credit, but the security stuff is still there, and still obnoxious, the three year old version of X is still worthless for anything other than a learning tool, and the reliability is still not as good as Xenix, which is why I haven't upgraded. Maybe you should use a little moderation when you start making blanket statements about other vendor's products, and not use terms like "crap" quite so freely. -- bill davidsen - davidsen@sixhub.uucp (uunet!crdgw1!sixhub!davidsen) sysop *IX BBS and Public Access UNIX moderator of comp.binaries.ibm.pc and 80386 mailing list "Stupidity, like virtue, is its own reward" -me
mju@mudos.ann-arbor.mi.us (Marc Unangst) (05/08/91)
sef@kithrup.COM (Sean Eric Fagan) writes: > In article <91V712w164w@mudos.ann-arbor.mi.us> mju@mudos.ann-arbor.mi.us (Mar > >X11R4, > > Mayhap. But SCO didn't do the port of X, Locus did, and people at sco were > very unhappy with them. (At least some of the engineers were.) Glad to hear that SCO was unhappy. But do I have X11R4 yet? > >Motif 1.1, > > As far as I know, it wasn't out at the time. Or don't you realize that it's > somewhat difficult to release something that doesn't exist? It wasn't out when ODT 1.1 was released? Gee, I could have sworn... But, I forgot, Motif 1.1 requires X11R4, so I guess they would have to port that first. > Why? The BSD FFS would have been a terrible bitch to port. It was easier Must have been really hard, seeing as how Everex did it for ESIX (and Everex sells ESIX for a lot less than an ODT system). > >symbolic links, > > What makes you think they *didn't*? Then where are they? Why doesn't "ln -s" work? > Gee. I've never had any problems with their uucp, and I used it quite > extensively for over two years. Try naming your site something with eight characters, and compare the ways HDB and SCO handle it. > >and commands like su(1) and cron(1) that work the way I expect them to. > > Yeah. You're right. They never did anything about this. And that SLS > (available from sco [maybe uunet, too, I don't know]) which is corrects the > C2 problems (they only way I notice the c2 stuff anymore is because > passwords aren't in /etc/passwd; however, this can be a good thing) > therefore doesn't exist. They did do something about it; it just wasn't enough. I still can't log in as root, kill cron, and then restart it. The newuser program I was using for the BBS (it lets a user enter some info about them, and then creates an account) had to be heavily rewritten for SCO's security. SCO doesn't even deign to document most of it. -- Marc Unangst | mju@mudos.ann-arbor.mi.us | "Bus error: passengers dumped" ...!hela!mudos!mju |
larry@nstar.rn.com (Larry Snyder) (05/08/91)
gar@spiff.UUCP (Gordon Runkle) writes: >As far as the 'buggy as hell' assertion, this seems to echo SCO's >official position, and is not consistent with reality. I've not >encountered any showstoppers in SVR4. (SCO didn't complain when SCO >UNIX 3.2v0 was 'buggy as hell'.) The next version of SVR4 (version 3) >should fix the few remaining annoyances. Just about everyone with SCO refers to SVR4 as "buggy as hell" - like I said earlier - I remember my first release of Xenix several years ago (re: "buggy as hell") -- Larry Snyder, NSTAR Public Access Unix 219-289-0287/317-251-7391 HST/PEP/V.32/v.32bis/v.42bis regional UUCP mapping coordinator {larry@nstar.rn.com, ..!uunet!nstar.rn.com!larry}
ralfi@pemcom.pem-stuttgart.de (Ralf U. Holighaus) (05/16/91)
mju@mudos.ann-arbor.mi.us (Marc Unangst) writes: >They did do something about it; it just wasn't enough. I still can't >log in as root, kill cron, and then restart it. The newuser program I Ever heard of the crontab command? That correctly updates the cron tables in the /usr/spool/cron/crontabs directory WITHOUT problems. Thats the clean way. Not the quick'n dirty one. Regards Ralf. -- PEM Programmentwicklungsgesellschaft | Ralf U. Holighaus fuer Microcomputer mbH | Technical Support PO-Box 810165 D-7000 Stuttgart 80 Germany | holighaus@PEM-Stuttgart.de VOICE: x49-711-713045 FAX: x49-711-713047 | ..!unido!pemcom!ralfi
mju@mudos.ann-arbor.mi.us (Marc Unangst) (05/20/91)
ralfi@pemcom.pem-stuttgart.de (Ralf U. Holighaus) writes: > Ever heard of the crontab command? That correctly updates the cron tables > in the /usr/spool/cron/crontabs directory WITHOUT problems. Thats the clean > way. Not the quick'n dirty one. Yes, I've heard of it. I also know that crontab does not work when you've su'd to another user. For example, how do I change the crontab for user "news", which has an unmatchable password (no need to ever log in as news)? I can't log in as "news", and crontab doesn't work if I su to "news" from root. -- Marc Unangst | mju@mudos.ann-arbor.mi.us | "Bus error: passengers dumped" ...!hela!mudos!mju |
shepperd@dms.UUCP (Dave Shepperd) (05/21/91)
From article <1991May21.080236.20551@kithrup.COM>, by sef@kithrup.COM (Sean Eric Fagan): > In article <sZH821w164w@mudos.ann-arbor.mi.us> mju@mudos.ann-arbor.mi.us (Marc Unangst) writes: >>Yes, I've heard of it. I also know that crontab does not work when >>you've su'd to another user. > > You know obsolete facts. > Maybe so, but I can't get su to "work" on my Xenix, Unix and Esix systems either. So I use root's crontab and do a su to news from there (which does work). -- Dave Shepperd. shepperd@dms.UUCP or motcsd!dms!shepperd Atari Games Corporation, 675 Sycamore Drive, Milpitas CA 95035. Nobody knows what I'm saying. I don't even know what I'm saying.
sef@kithrup.COM (Sean Eric Fagan) (05/21/91)
In article <sZH821w164w@mudos.ann-arbor.mi.us> mju@mudos.ann-arbor.mi.us (Marc Unangst) writes: >Yes, I've heard of it. I also know that crontab does not work when >you've su'd to another user. You know obsolete facts. -- Sean Eric Fagan | "I made the universe, but please don't blame me for it; sef@kithrup.COM | I had a bellyache at the time." -----------------+ -- The Turtle (Stephen King, _It_) Any opinions expressed are my own, and generally unpopular with others.
jpm@logixwi.uucp (Jan-Piet Mens) (05/22/91)
sef@kithrup.COM (Sean Eric Fagan) writes: >In article <1248@dms.UUCP> shepperd@dms.UUCP (Dave Shepperd) writes: >>Maybe so, but I can't get su to "work" on my Xenix, Unix and Esix systems >>either. >>So I use root's crontab and do a su to news from there (which does work). >That's pretty interesting, considering that there is nothing in xenix that >would prevent that. >Or are you upset because you can't have other users use crontab? >In which case I would suggest you RTFM. Something I would expect of any >system administrator. BTW, the FM says you should insert the names of all users allowed to use crontab in /usr/lib/cron/cron.allow. 1 per line ;-) I hope that helps. -- Jan-Piet Mens, Logix GmbH jpm@logixwi.UUCP Moritzstr. 50, D-6200 Wiesbaden ...!uunet!mcsun!unido!logixwi!jpm
jdeitch@jadpc.cts.com (Jim Deitch) (05/22/91)
In article <1248@dms.UUCP> shepperd@dms.UUCP (Dave Shepperd) writes: >From article <1991May21.080236.20551@kithrup.COM>, by sef@kithrup.COM (Sean Eric Fagan): >> In article <sZH821w164w@mudos.ann-arbor.mi.us> mju@mudos.ann-arbor.mi.us (Marc Unangst) writes: >>>Yes, I've heard of it. I also know that crontab does not work when >>>you've su'd to another user. >> >> You know obsolete facts. >> > >Maybe so, but I can't get su to "work" on my Xenix, Unix and Esix systems either. >So I use root's crontab and do a su to news from there (which does work). su works just fine under ISC 2.2.1. Jim -- ARPANET: jadpc!jdeitch@nosc.mil INTERNET: jdeitch@jadpc.cts.com UUCP: nosc!jadpc!jdeitch
sef@kithrup.COM (Sean Eric Fagan) (05/22/91)
In article <1248@dms.UUCP> shepperd@dms.UUCP (Dave Shepperd) writes: >Maybe so, but I can't get su to "work" on my Xenix, Unix and Esix systems >either. >So I use root's crontab and do a su to news from there (which does work). That's pretty interesting, considering that there is nothing in xenix that would prevent that. Or are you upset because you can't have other users use crontab? In which case I would suggest you RTFM. Something I would expect of any system administrator. -- Sean Eric Fagan | "I made the universe, but please don't blame me for it; sef@kithrup.COM | I had a bellyache at the time." -----------------+ -- The Turtle (Stephen King, _It_) Any opinions expressed are my own, and generally unpopular with others.
erik@gogoman.sf.ca.us (Erik Fortune) (05/23/91)
In article <sZH821w164w@mudos.ann-arbor.mi.us> mju@mudos.ann-arbor.mi.us (Marc Unangst) writes: >Yes, I've heard of it. I also know that crontab does not work when >you've su'd to another user. For example, how do I change the crontab >for user "news", which has an unmatchable password (no need to ever >log in as news)? I can't log in as "news", and crontab doesn't work >if I su to "news" from root. On ODT 1.1, "crontab -u news" works fine (as root). I just tried it. -- Erik
sef@kithrup.COM (Sean Eric Fagan) (05/23/91)
In article <1991May21.172622.5358@logixwi.uucp> jpm@logixwi.uucp (Jan-Piet Mens) writes: > BTW, the FM says you should insert the names of all users allowed to > use crontab in /usr/lib/cron/cron.allow. 1 per line ;-) Or, alternatively, in /usr/lib/cron/cron.deny. I tend to make an empty file of that name, and remove cron.allow; this lets anyone use cron. -- Sean Eric Fagan | "I made the universe, but please don't blame me for it; sef@kithrup.COM | I had a bellyache at the time." -----------------+ -- The Turtle (Stephen King, _It_) Any opinions expressed are my own, and generally unpopular with others.
peter@ficc.ferranti.com (Peter da Silva) (05/23/91)
In article <1174@pemcom.pem-stuttgart.de> ralfi@pemcom.pem-stuttgart.de (Ralf U. Holighaus) writes: > mju@mudos.ann-arbor.mi.us (Marc Unangst) writes: > >They did do something about it; it just wasn't enough. I still can't > >log in as root, kill cron, and then restart it. The newuser program I > Ever heard of the crontab command? That correctly updates the cron tables > in the /usr/spool/cron/crontabs directory WITHOUT problems. Thats the clean > way. Not the quick'n dirty one. That's nice. Can you change cron's environment, timezone, umask, etc.. that way? Tell it that the system time has changed? Etc... there's lots of reasons to restart cron other than to rescan the crontabs. (and why the hell are those crontabs in spool in SV? They should be in lib) -- Peter da Silva; Ferranti International Controls Corporation; +1 713 274 5180; Sugar Land, TX 77487-5012; `-_-' "Have you hugged your wolf, today?"
shepperd@dms.UUCP (Dave Shepperd) (05/23/91)
From article <1991May21.172622.5358@logixwi.uucp>, by jpm@logixwi.uucp (Jan-Piet Mens): > sef@kithrup.COM (Sean Eric Fagan) writes: > >>In article <1248@dms.UUCP> shepperd@dms.UUCP (Dave Shepperd) writes: >>>Maybe so, but I can't get su to "work" on my Xenix, Unix and Esix systems >>>either. >>>So I use root's crontab and do a su to news from there (which does work). > >>That's pretty interesting, considering that there is nothing in xenix that >>would prevent that. >>Or are you upset because you can't have other users use crontab? >>In which case I would suggest you RTFM. Something I would expect of any >>system administrator. > > BTW, the FM says you should insert the names of all users allowed to > use crontab in /usr/lib/cron/cron.allow. 1 per line ;-) The original subject seems to have been lost. Someone asked (complained?) that is was difficult to use a crontab file on an account that had no interactive login (such as news). Sean suggested that one could su to the subject account and use crontab from there. It is my observation that this does not work on the 3 O/S's that I use regularly. The symptom is that crontab insists on using the original username even after doing an su. The solution I mentioned is how I get around the problem of not being able to add a crontab file for an account that cannot be logged into. BTW: The FM is much more clear on the subject of cron.allow and cron.deny than your comment implies. If a cron.allow does not exist, then cron looks in cron.deny. If neither exists, then everyone can use cron. None of my systems have either cron.allow or cron.deny. This has nothing to do with the problems mentioned in any of the previous postings. -- Dave Shepperd. shepperd@dms.UUCP or motcsd!dms!shepperd Atari Games Corporation, 675 Sycamore Drive, Milpitas CA 95035. Nobody knows what I'm saying. I don't even know what I'm saying.
scotts@qsp.COM (Scott Simpers) (05/24/91)
In article <10@gogoman.sf.ca.us> erik@gogoman.sf.ca.us (Erik Fortune) writes: >On ODT 1.1, "crontab -u news" works fine (as root). I just tried it. > >-- Erik Then SCO must have finally fixed something. On ODT 1.0 crontab -u news gives me an "illegal option" error. Scott Simpers Quality Software Products voice: (213)410-0303 5711 W Slauson Avenue Suite 240 fax: (213)410-0124 Culver City, CA 90230 ...uunet!qsp!scotts
mcr@Sandelman.OCUnix.on.ca (Michael Richardson) (05/24/91)
In article <1251@dms.UUCP> shepperd@dms.UUCP (Dave Shepperd) writes: >From article <1991May21.172622.5358@logixwi.uucp>, by jpm@logixwi.uucp (Jan-Piet Mens): >>>>So I use root's crontab and do a su to news from there (which does work). >> >>>That's pretty interesting, considering that there is nothing in xenix that >>>would prevent that. Ever tried to send mail when su'ed? Notice anything? Ever try 'su - news' ?? Works really nicely. It even sets the 'LOGNAME' variable to 'news' >interactive login (such as news). Sean suggested that one could su >to the subject account and use crontab from there. It is my observation >that this does not work on the 3 O/S's that I use regularly. The A simple 'su' just gives you the uid. An 'su -' gives you the whole shebang. I give news a password and reserve use of the root account to when it really necessary. I guess they don't make sysadmins like they used to. (I know this works under ISC. I believe I did it last week on an ODT, but I can't be certain) -- :!mcr!: | The postmaster never | So much mail, Michael Richardson | resolves twice. | so little time. HOME: mcr@sandelman.ocunix.on.ca Bell: (613) 237-5629 Small Ottawa nodes contact me about joining ocunix.on.ca!
fitz@wang.com (Tom Fitzgerald) (05/24/91)
mju@mudos.ann-arbor.mi.us (Marc Unangst) writes: > For example, how do I change the crontab > for user "news", which has an unmatchable password (no need to ever > log in as news)? Get an airline comfort receptacle ready, here's the trick I used to use: Create ~news/.rhosts containing: localhost <your-name> instead of using "su", use rlogin localhost -l news (that can be in a script if you prefer.) Of course, the best long-term solution is to get the McManus/Bryant "su" which mashes the luid when you run it. Works great. --- Tom Fitzgerald Wang Labs fitz@wang.com 1-508-967-5278 Lowell MA, USA ...!uunet!wang!fitz
sef@kithrup.COM (Sean Eric Fagan) (05/24/91)
In article <1251@dms.UUCP> shepperd@dms.UUCP (Dave Shepperd) writes: >Sean suggested that one could su >to the subject account and use crontab from there. It is my observation >that this does not work on the 3 O/S's that I use regularly. The symptom >is that crontab insists on using the original username even after doing >an su. And it is my observation, after just trying it a) as root su'd to news, b) as root su'd to uucp (which does not have a password), and c) as sef su'd to root, that it works as I have described it. Since I am running a straight SCO UNIX 3.2v2 (with the exception of uucico, which is a sef Special), I fail to see how you can get that error. Perhaps you're thinking of at? -- Sean Eric Fagan | "I made the universe, but please don't blame me for it; sef@kithrup.COM | I had a bellyache at the time." -----------------+ -- The Turtle (Stephen King, _It_) Any opinions expressed are my own, and generally unpopular with others.
det@hawkmoon.MN.ORG (Derek E. Terveer) (06/03/91)
sef@kithrup.COM (Sean Eric Fagan) writes: >In article <1251@dms.UUCP> shepperd@dms.UUCP (Dave Shepperd) writes: >>Sean suggested that one could su >>to the subject account and use crontab from there. It is my observation >>that this does not work on the 3 O/S's that I use regularly. The symptom >>is that crontab insists on using the original username even after doing >>an su. >And it is my observation, after just trying it a) as root su'd to news, b) >as root su'd to uucp (which does not have a password), and c) as sef su'd >to root, that it works as I have described it. Seems to work just fine under Esix 5.3.2-D as well under all three shells: ksh, sh, csh. -- Derek "Tigger" Terveer det@hawkmoon.MN.ORG -- U of MN Women's Lax I am the way and the truth and the light, I know all the answers; don't need your advice. -- "I am the way and the truth and the light" -- The Legendary Pink Dots
rwhite@jagat.uucp (Robert White) (06/04/91)
It is completely effective to su to another accoutn and use crontab to set the crontab entry into place for that (su(ed) account) but keep in mind the following: Crontab uses the user environment to determine who to set the cron-table for. If you "su news; crontab newtable" you will be setting the cron-table for the original logname, not news. The correct method is to "su - news; crontab newtable" so that the all-important ^ setup user environment features take effect! If in doubt, try "crontab -l" on your system after su(ing) to check which table you will be altering. -- Robert C. White Jr. | If you sent me mail and it bounced going rwhite@jagat <Home | through nusdhub, please re-send it if it rwhite@nusdecs <Work | was important. Implementation Details! "Like most endevors, life is seriously over-advertised and under-funded"
sef@kithrup.COM (Sean Eric Fagan) (06/05/91)
In article <1991Jun4.032557.9455@jagat.uucp> rwhite@jagat.uucp (Robert White) writes: >Crontab uses the user environment to determine who to set >the cron-table for. >If you "su news; crontab newtable" you will be setting the >cron-table for the original logname, not news. And, for the third or fourth time, I have, after installing SCO's "C2 SLS," done the following: # su news $ crontab -l > /tmp/out $ vi /tmp/out # edit it $ crontab < /tmp/out $ exit # Don't see an 'su - news' in there. I don't see me playing with the user environment. It all works as normal and expected. -- Sean Eric Fagan | "I made the universe, but please don't blame me for it; sef@kithrup.COM | I had a bellyache at the time." -----------------+ -- The Turtle (Stephen King, _It_) Any opinions expressed are my own, and generally unpopular with others.
wes@harem.clydeunix.com (Barnacle Wes) (06/05/91)
In article <1991May22.184358.91@kithrup.COM>, sef@kithrup.COM (Sean Eric Fagan) writes: > Or, alternatively, in /usr/lib/cron/cron.deny. I tend to make an empty file > of that name, and remove cron.allow; this lets anyone use cron. Have you ever noticed that the term "secure" has opposite meanings for systems and administrators? I.e. "secure" system => "insecure" admin. I take it that Mr. Fagan is not terrified of, or terrorized by, the users on his system. :-) Wes Peters -- #include <std/disclaimer.h> The worst day sailing My opinions, your screen. is much better than Raxco had nothing to do with this! the best day at work. Wes Peters: wes@harem.clydeunix.com ...!sun!unislc!harem!wes
ralfi@pemcom.pem-stuttgart.de (Ralf U. Holighaus) (06/20/91)
mju@mudos.ann-arbor.mi.us (Marc Unangst) writes: >ralfi@pemcom.pem-stuttgart.de (Ralf U. Holighaus) writes: >> Ever heard of the crontab command? That correctly updates the cron tables >> in the /usr/spool/cron/crontabs directory WITHOUT problems. Thats the clean >> way. Not the quick'n dirty one. >Yes, I've heard of it. I also know that crontab does not work when >you've su'd to another user. For example, how do I change the crontab >for user "news", which has an unmatchable password (no need to ever >log in as news)? I can't log in as "news", and crontab doesn't work >if I su to "news" from root. Install Support Level Supplement SLS unx257, and you will succeed with su and crontab. Regards Ralf. -- PEM Programmentwicklungsgesellschaft | Ralf U. Holighaus fuer Microcomputer mbH | Technical Support PO-Box 810165 D-7000 Stuttgart 80 Germany | holighaus@PEM-Stuttgart.de VOICE: x49-711-713045 FAX: x49-711-713047 | ..!unido!pemcom!ralfi