From: Digestifier To: Linux-Admin@senator-bedfellow.mit.edu Reply-To: Linux-Admin@senator-bedfellow.mit.edu Date: Tue, 31 Aug 93 04:13:13 EDT Subject: Linux-Admin Digest #26 Linux-Admin Digest #26, Volume #1 Tue, 31 Aug 93 04:13:13 EDT Contents: Re: Let's collect KNOWN BUGS (Macy Hallock) Re: Why use shadow? (Michael Will) Where's Ross Biro ? (was Re: Let's collect KNOWN BUGS) (Paul Gortmaker) Re: Where's Ross Biro ? (was Re: Let's collect KNOWN BUGS) (Arnt Gulbrandsen) Re: Where's Ross Biro ? (was Re: Let's collect KNOWN BUGS) (Arnt Gulbrandsen) Re: Rnews problem in UUCP (Remco Treffkorn) "lpd" won't run (Chris Marriott) ---------------------------------------------------------------------------- From: macy@telemax.com (Macy Hallock) Subject: Re: Let's collect KNOWN BUGS Reply-To: macy@telemax.com Date: Mon, 30 Aug 1993 14:17:57 GMT In article <1993Aug29.233539.6106@colorado.edu> drew@juliet.cs.colorado.edu (Drew Eckhardt) writes: >A clearing house for bug reports would be extremely useful for the developers >and users. A moderated newsgroup would be useful for this purpose. The only drawback I can think of is: the knowledgable person who moderates would have less time to track down and fix the bugs. On the other hand, independant confirmation and documentation of a bug is a very useful contribution... Other ideas? -- Macy Hallock N8OBG Voice:+1.216.723.3030 Fax:+1.216.723.3223 macy@telemax.com Telemax Inc. and F M Systems Inc. 152 Highland Drive Medina, Ohio 44256 USA ------------------------------ Crossposted-To: alt.security From: michaelw@desaster.hanse.de (Michael Will) Subject: Re: Why use shadow? Date: Mon, 30 Aug 1993 15:56:42 GMT ranger@twain.ucs.umass.edu (Net Ranger) writes: >: So, there are two possibilities. Either make sure users use >very< >: hard to guess passwords (like "UUwb3QbN") or use /etc/shadow, and just >HEY! how'd you find out my password!!!! better go change it...... *grin* Well, this must not neccessary be a joke... The sco or interactive (I do not remember) used to generate passwords for users which where easy to remember, but rather guaranteed not to find in a dictionary. (diskipa or similar things) However, they are generated by an algorythm, so some hacker targeting such a system could generate a database of these passwords, could he not? So it would be very unsecure to use these seemingly secure passwords... Maybe we should take this to alt.security, though. Cheers, Michael Will -- Michael Will Linux - share and enjoy :-) Life is not there if you can't share it... Hazel'O'Connor Breaking Glass Happily using Linux 0.99p12 with X11R5, \LaTeX, cnews/nn/uucp and: PGP! >>> Ask for Linux and / or pgp-Information <<< ------------------------------ From: rcopg@minyos.xx.rmit.OZ.AU (Paul Gortmaker) Subject: Where's Ross Biro ? (was Re: Let's collect KNOWN BUGS) Date: 31 Aug 1993 03:53:58 GMT drew@juliet.cs.colorado.edu (Drew Eckhardt) writes: >In article <1993Aug29.105820.750@depeche.toppoint.de> kai@depeche.toppoint.de (Kai Voigt) writes: >>Hello, >> >>to collect a list called "KNOWN BUGS". This list should be [...] [Drew's 5 valid points deleted] [...] >>I'd like everyone who detected a bug (no matter if severe or >>not) to follow up to this article or mail the description of >>the bug to me. I will maintain this list and post it >>frequently to comp.os.linux.announce. I'd also like to see [...] >>What does the rest of you think about it? >It's definately a good idea, but the implementation needs some work. >A clearing house for bug reports would be extremely useful for the developers >and users. It could weed out non-bugs, and insure that all bug reports had >enough information to reproduce the bugs. It could then mail the bugs out to >the appropriate people, and could maintain a public list as well. Developers >would have concise bug reports with a high-signal-to-noise ratio, making >problems easier to fix. Users would have a better chance of getting their >bugs fixed, and would know about what bugs to expect. ...hey, wait a minute! What happened to Ross Biro's setup! Did it just die silently? This is the exact purpose that he wanted it to serve! THe idea was that people could mail linux-support@sunsite.unc.edu and if their problem wasn't a user error, then a *very descriptive* bug report would be sent to the appropriate people. Geez, that sure sounds pretty similar to me. Here is the posting announcing the support from (gasp) almost *three* months ago. Paul. =========================================================================== Paul Gortmaker c/o Microelectronics and Materials Technology Centre. Royal Melbourne Institute of Technology, GPO Box 2476V, Melbourne 3001, Victoria, Australia. Ph (61) 3 660 2601. FAX (61) 3 662 1921. e-mail: paul@cain.mmtc.rmit.oz.au rcopg@minyos.xx.rmit.oz.au =========================================================================== Newsgroups: comp.os.linux Path: escargot!monu6!bruce.cs.monash.edu.au!munnari.oz.au!news.Hawaii.Edu!ames!agate!headwall.Stanford.EDU!nntp.Stanford.EDU!bir7 From: bir7@leland.Stanford.EDU (Ross Biro) Subject: REPOST: Free Email Support for Linux Message-ID: <1993Jun3.180450.25231@leland.Stanford.EDU> Summary: mail linux-support@sunsite.unc.edu Sender: news@leland.Stanford.EDU (Mr News) Organization: DSG, Stanford University, CA 94305, USA Date: Thu, 3 Jun 93 18:04:50 GMT Lines: 184 The address is now officially linux-support@sunsite.unc.edu although linux-bugs@sunsite.unc.edu will continue to work for some time. I'm reposting the whole announcement with the new address in case people missed it the first time by. SAVE THIS! SAVE THIS! It contains important instructions. The Linux Email Support System is now ready for general use. It is not bug free, and there will be delays and other teething problems for a while. Purpose: The purpose of the Linux Email Support System is to provide a forum for people to ask questions without worrying about being flamed for a non-Linux specific question or for asking a FAQ. Who Should Use it? The Linux Email Support System is for anyone who is having a problem with Linux. It is not intended to replace comp.os.linux[.announce] or the mailing lists, but rather to supplement them with a forum designed specifically to deal with the volume of questions on comp.os.linux which are easily answered. Why Use It? If you send a question to the Linux Email Support System, it will be routed to a single individual who will take responsibility for answering it. If that individual can't answer it, (s)he will forward it to someone that may be able to. Everyone is likely to benefit because there will be less traffic in comp.os.linux, and each question will get a single individual to deal with it, rather than many people answering one question while a second question is ignored. When Should I use It? This is a tough question, and is really a judgement call. If you believe your question is interesting or otherwise very current, you should probably post it directly. However if you are having problems with a common program or subsystem, you should probably use the Linux Email Support System based on the philosophy that if it really worked that poorly, everyone would be screaming about it. Also if you don't have much experience with Unix in general you should read the FAQ from comp.unix.questions and use the Linux Email Support System until you feel more confident (or get asbestos underwear 8-). How do I know the answer I got is correct? There is no guarantee of the correctness of any given answer. However to help prevent the distribution of misinformation, all answers (The first time they are answered only) are sent to the appropriate channel of the mailing list. That way many people see the answer, and if it is incorrect, someone will probably say something. You are also free to ask the question again in a more public forum such as comp.os.linux and point out why you think the answer as in error. SAVE THIS PART !!!! How do I use It? You just mail your question to linux-support@sunsite.unc.edu There is one caveat; however, the Linux Email Support System has been designed to be easy for the software maintainers and volunteers to use. The net affect is that there is a reasonably rigid format. Every message must contain the following fields. Keywords: Summary: Program: Kernel: Hardware: Description: Expected: The order is not important; but ALL the fields must be present in ALL problem-reports, or the software will return the question to you. The format purpose of each of the fields is Keywords: Single line. Used to try to see if this is a FAQ and can be auto answered by machine. Proper use of this field will greatly increase the number of messages which can be handled per day. Summary: Single Line. Quick summary of the problem. Also used by the software to see if it's a FAQ. And makes it easier for the Volunteer to answer it. Program: Single Line. Program and Version number that is causing problems. This should be included whenever possible; even if you think it is a general problem as it makes things easier to reproduce and track down. Kernel: Multi Line. This is kernel version number and options configured in. You should also include where you got it (compiled it yourself, SLS, ...) in case it turns out to be a kernel problem and a system map file is needed. Hardware: Multi Line. This is the hardware you are experiencing the problem on. It is not always relevant, but it is often hard to tell, and should be as complete as possible. Especially include things like the type of hard drive controller etc. Description: Multi Line. This is a complete description of the problem; including how to reproduce it. Include transcripts generated via the script program, dejagnu scripts, or xterm whenever possible. Expected: Multi Line. This is mostly for cases when something happens that is different from what you expect; i.e. select alters the timeout value. It should also be included when you are asking about features that you don't think are present in Linux, or need to be emulated. If you can include a portion of a man page or other documentation which backs up the behavior you wish, it would be helpful. You can also leave this field blank in cases of programs simply crashing, or if you feel the Description is enough. Here is an example ====== mail linux-support@sunsite.unc.edu ~Subject: problem with gcc Keywords: gcc link ld math library Summary: Math externals not linked in. Program: gcc -lm foo.c Kernel: .99 pl9 from SLS with tcp/ip and ipc_delta patches Hardware: 386-20 8M ram ESDI hard drive Description: gcc -lm foo.c can't find floor. Script started on Mon May 31 12:22:25 1993 gcc -lm foo.c elaine30-[1> gcc -lm foo.c foo.o: Undefined symbol _floor referenced from text segment elaine30-[2> exit exit script done on Mon May 31 12:22:36 1993 --- foo.c -- #include main () { int x; x = floor (12.30); } --- end of foo.c --- Expected: . ===== End Example. This is great how can I help? If you would like to help, there are many things you can do. If you feel capable, you can volunteer to answer questions. You can fix problems with the software. Donating resources (hard drive space etc.) might also be useful. You could combine our scripts with GNATS for an incredibly powerful bug tracking system. If you would like to help mail bir7@leland.stanford.edu and tell me what you would like to do. Who do we have to thank for this? You should thank all the volunteers as well as the sunsite admins, especially jem@sunsite.unc.edu, and Ted. Currently the volunteers are (group by category they intend to answer questions about.) Jacques Gelinas,dthumim@athena.mit.edu,Edward T. Shiobara, Matthew D. Stock ,Michael K. Johnson, Peter F. Couvares, Andrew Tridgell:,probreak@matt.ksu.ksu.edu,Eric Johnson, John Turnbull,Brian E. Gallew,Joeri van Ruth,John Henders, Matt Welsh,Philip Copeland,Richie Lai,Erik Troan, Arnt Gulbrandsen,Mitchum Dsouza,Ross Biro,Jeff Grills, Michael Oreilly,Darren Stadler?,Thomas Dunbar,Andreas Neubacher Ian Jackson,Johannes Grosen,Nick Holloway,Onnei ?,Jeremy Bettis, Paul Gover,David Hoelzer,H. Peter Anvin,Kevin Cummings, Scott A. Laird. Send comments to bir7@leland.stanford.edu Ross Biro bir7@leland.stanford.edu Member League for Programming Freedom (LPF) mail lpf@uunet.uu.net to protect your Freedom ------------------------------ From: agulbra@nvg.unit.no (Arnt Gulbrandsen) Subject: Re: Where's Ross Biro ? (was Re: Let's collect KNOWN BUGS) Date: 31 Aug 1993 05:06:36 GMT In article <25ui0m$o6d@aggedor.rmit.oz.au>, Paul Gortmaker wrote: >...hey, wait a minute! What happened to Ross Biro's setup! Did it just >die silently? Ross' robot first tries to match every question to a FAQ, replies automatically if any FAQ fits and forwards the question to a human (me or someone else) if it doesn't. The human's answer is then entered into the FAQ database. It works, kinda, I get a question now and then, and since their code numbers keep rising I assume the robot answers a lot of questions from the FAQ database. Very few, maybe no questions are real, new, bugs worth submitting bug reports for. Generally they seem to be already reported on the activists lists or fixed-but-not-in-SLS type problems. Typical examples are someone who has an unsupported chipset and wants to use X, or someone who has an old ftpd and can't get mget to work. All this is IMHO and from my experience, naturally. -- Arnt Gulbrandsen, agulbra@nvg.unit.no The perpetual double-sig newbie. -- Arnt Gulbrandsen, agulbra@nvg.unit.no The perpetual double-sig newbie. ------------------------------ From: agulbra@nvg.unit.no (Arnt Gulbrandsen) Subject: Re: Where's Ross Biro ? (was Re: Let's collect KNOWN BUGS) Date: 31 Aug 1993 05:19:44 GMT In article <25ui0m$o6d@aggedor.rmit.oz.au>, Paul Gortmaker wrote: >...hey, wait a minute! What happened to Ross Biro's setup! Did it just >die silently? Ross' robot first tries to match every question to a FAQ, replies automatically if any FAQ fits and forwards the question to a human (me or someone else) if it doesn't. The human's answer is then entered into the FAQ database. It works, kinda, I get a question now and then, and since their code numbers keep rising I assume the robot answers a lot of questions from the FAQ database. Very few, maybe no questions are real, new, bugs worth submitting bug reports for. Generally they seem to be already reported on the activists lists or fixed-but-not-in-SLS type problems. Here's a typical question: > Keywords: Increasing swap > Summary: I have a 20 meg swap partition and need linux to use it all > Program: Kernel > Kernel: .99pl9 soon to be pl10 > Hardware: 486dx-33, 8meg Ram, 240meg IDE, Actix 32 SVGA > Description: I once saw an article explaining how to increase the > arbitary 16Meg swap partition limit. I unfortunatly didn't save it. > Expected: And my reply was that you can't, you define another swap partition in the same manner as the first (only I used four lines, not two). All this is IMHO and from my experience, naturally. -- Arnt Gulbrandsen, agulbra@nvg.unit.no The perpetual double-sig newbie. -- Arnt Gulbrandsen, agulbra@nvg.unit.no The perpetual double-sig newbie. ------------------------------ Crossposted-To: comp.os.linux.help From: root@hip-hop.suvl.ca.us (Remco Treffkorn) Subject: Re: Rnews problem in UUCP Date: Mon, 30 Aug 1993 21:50:09 GMT andreas@knobel.knirsch.de (Andreas Klemm) writes: : swwynen@undergrad.math.uwaterloo.ca (Steve W. Wynen) writes: : : >Hello Everybody; : : >Hope you can help. I am trying to set up a UUCP site to receive email : >and news. i have got the UUCP faq, the recommended reading, and this : >one still escapes me. : : Why don't you say what kind of Linux version you are running ? : Would be fine, too, if you would mention, which uucp version you : run ... : : >I have the UUCP feed mostly working, can send and receive email, but : >i cannot get my news to come in properly, it gets sent over , : >but then seems to dissappear into the bit bucket. : >In the file /usr/spool/uucp/.Log/joesys I get many many messages like: : : Strange, which kind of uucp logginf report do you use ? : SLS comes with HDB and taylor compiled in, but is setup to use : HDB kind (Honey Dan Beer) of config/spooling/logging .... : : >Executing X.joesysX0ctr (rnews) : >ERROR: Execution: Exit Status 1 : >Execution failed (X.joesysX0ctr) : : Could it be the case, that your rnews isn't found by uux ? : Check your local config files in /usr/local/lib/uucp : (Permissions is a good start) if your news feed is permitted : to run the rnews program .... : : >I have done everything that the Cnews README said to do but, it doesnt work. : >Any suggestions would be appreciated. : : Why can't your newsfeed help ?! He has obviously a running system ?! : I think you aren't experienced in configuring uucp/news/mail ?! : Then your newsfeed should help you in this - general - points : of questions .... : -- : /-\ Andreas Klemm +-----------------+ : |@|########################################################-@ "pay for it !" | : \-/ 41469 Neuss Germany phone +49/ 2137 12609 +-----------------+ Lighten up Andreas :-) You are making many assumptions about what Steve did not do to get help elsewhere. "Der moralische Zeigefinger" does not help! In virtually all the cases I have seen in the past the permissions were indeed the culprit. I have seen the exact symptoms Steve mentioned and it took me three days to find the problem. Turned out to be bad *permissions* on ..... taataa : /tmp. After restoring my root partition from tape I did not have 1777 any more. The only symptom: no news! Well, maybe there would have been others, but I like to login as root. (THIS IS *MY* 'PUTER!) The return status of 1 from rnews suggests that rnews was found an run. Check the scripts. So it is almost guaranteed the permissions. But there are so many, ach ... ;-) Cheers, Remco remco@hip-hop.suvl.ca.us (DC2XT) ------------------------------ From: chris@chrism.demon.co.uk (Chris Marriott) Subject: "lpd" won't run Reply-To: chris@chrism.demon.co.uk Date: Mon, 30 Aug 1993 18:40:10 +0000 Forgive me if you've already seen this post in "comp.os.linux", but I've just discovered that this new hierarchy exists, and this is the place where the question should have gone originally. I've just installed the SLS 1.03 linux implementation on my 486/33. I'm trying to get printing working, following the instructions in the FAQ. I have a printer on LPT1: which works - I can copy a file to /dev/lp1 and it prints fine. My problem is that the printer daemon "lpd" refuses to run. If I run it, it terminates with no error messages immediately (exit code 0, if that helps). When I try to print through "lpr" I get the message "job queued, but no daemon present". When I run the printer control program lpc and give the "restart" command I get the message: lp: cannot open lock file lp: lpc: connect: No such file or directory couldn't start daemon I've edited the "printcap" file to simply say: lp:\ :lp=/dev/lp1:\ :sd=/usr/spool/lp1:\ :mx#0: I've create the directory "/usr/spool/lp1". This is getting VERY fraustrating. If anyone can help me with this problem, I'd really appreciate it! Thanks! Chris -- ========================================================================== | Chris Marriott | chris@chrism.demon.co.uk | | Warrington, UK | 100113.1140@compuserve.com | | Save the whales. Collect the whole set. | CompuServe: 100113,1140 | ========================================================================== ------------------------------ ** FOR YOUR REFERENCE ** The service address, to which questions about the list itself and requests to be added to or deleted from it should be directed, is: Internet: Linux-Admin-Request@NEWS-DIGESTS.MIT.EDU You can send mail to the entire list (and comp.os.linux.admin) via: Internet: Linux-Admin@NEWS-DIGESTS.MIT.EDU Linux may be obtained via one of these FTP sites: nic.funet.fi pub/OS/Linux tsx-11.mit.edu pub/linux sunsite.unc.edu pub/Linux End of Linux-Admin Digest ******************************