From: Digestifier To: Linux-Admin@senator-bedfellow.mit.edu Reply-To: Linux-Admin@senator-bedfellow.mit.edu Date: Sun, 29 Aug 93 20:13:19 EDT Subject: Linux-Admin Digest #24 Linux-Admin Digest #24, Volume #1 Sun, 29 Aug 93 20:13:19 EDT Contents: Re: Linux bbs software? (Andreas Fatum) Making a bootdisk/rootdisk combo (Harvey J. Stein) fsck and partitioning. (Harvey J. Stein) Setting passwords (Michael Plate) Re: Getty Spasms (Greg Patten) Re: Getty Spasms (Brandon S. Allbery) Let's collect KNOWN BUGS (Kai Voigt) denial of service attacks (Michael P. Sperry) restricting newsgroups (Michael P. Sperry) Re: Linux bbs software? (Christopher Mauritz) Re: Let's collect KNOWN BUGS (Drew Eckhardt) Re: denial of service attacks (Drew Eckhardt) ---------------------------------------------------------------------------- From: ace@acelab.ruhr.de (Andreas Fatum) Subject: Re: Linux bbs software? Date: Sat, 28 Aug 93 22:34:01 GMT In jrmt@argonaut.com (Jon Thackray) writes: >I'm looking for one which supports Internet mail and news. The only one >to do this is 'mbox' - but alas, it is all in German. (well it has some >English support, but there's still some German text I can't get rid of). Of course you can! The complete source is included so you only have to translate some stuff. I compiled/installed the program last nite and I think that Volker Schuermann did a great job on that one. It is fully configurable on a per-level basis; you can restrict email to local email only, allow mails to some given domains (uucp-neighbours, e.g.) etc, the same with news. Online-games, file-sections, chat-system and other goodies are also included. It compiles nearly out of the box. Bye, Andreas --- Andreas Fatum InterNet : ace@acelab.ruhr.de (Internet BBS) postmaster@re.open.de (City-Router) SubNet : ace@acelab.ruhr.sub.org UUCP/Bang!: ..!uunet!germany.eu.net!acelab!ace ------------------------------ Subject: Making a bootdisk/rootdisk combo From: hjstein@sunrise.huji.ac.il (Harvey J. Stein) Date: 29 Aug 93 12:18:00 How does one make a bootdisk/rootdisk combo, or a bootable root disk? I'm asking because I'd like to have an emergency stand-alone boot disk which doesn't rely on the hard disk. I can't use SLS disk a1 because it hangs when it probes my cheap NE2000 ethernet clone board (both versions 1.02 and 1.03). Whenever I need to boot without mounting my hard disk, I have to yank out the ethernet card. If I can make my own bootable root disk, then I won't have to yank the ethernet card each time. Thanks. -- Harvey Stein Department of Mathematics Hebrew University hjstein@math.huji.ac.il ------------------------------ Subject: fsck and partitioning. From: hjstein@sunrise.huji.ac.il (Harvey J. Stein) Date: 29 Aug 93 12:31:39 I posted about a week ago, asking about the proper procedure for using fsck. I wanted to run it from /etc/rc, but I only have one linux partition, the root partition, which has to be mounted before the program can be run (since the program is on that partition, of course). Juha Laiho (Wolf, jlaiho@ichaos.nullnet.fi), said to look at the bootutils package (bootutils-9.1.tar.tz). So I did. However, I don't understand exactly how it works. It's README says that it mounts the root filesystem readonly, runs fsck, and then if there are no problems it remounts the root and mounts the other filesystems. However, what if there is a problem? If the root file system has been damaged, how can this fsck fix it if the root was mounted readonly? Does it write directly to the device file in /dev? What should I do when fsck finds an error? The README also gives an example code fragment for running fsck in /etc/rc. Here's the example: # Check the integrity of all filesystems /bin/fsck -A -a # If there was a failure, drop into single-user mode. if [ $? -gt 1 ] ; then echo fsck failed. Please reboot. sh fi So, after a crash, if there's a disk problem, the system will drop immediately into a shell and tell me to reboot. Do I need to run sync first? Can I run fsck again at this point to make sure everything is ok? Should I reboot with the shutdown command or should I just hit the power switch? Also, according to one UNIX book that I looked at, one can run fsck from single user mode. How can I get linux into single user mode? Can I run fsck from this mode? What is the procedure? Thanks. -- Harvey Stein Department of Mathematics Hebrew University hjstein@math.huji.ac.il ------------------------------ From: plate@hrz.uni-kassel.de (Michael Plate) Subject: Setting passwords Date: 28 Aug 1993 08:45:51 GMT Hi, I have a problem with creating some user-accounts. Creating and setting up them with useradd is no problem, but I don't know how to handle the following: Normally, a user gets a dummy-password, like 23ycbf or so. When he logs in the first time, he types user and the dummy-password. After this, he should get a message to change his password and the usual procedure for changing (automatically). I know that's possible, I have seen this on some systems, e.g. AIX. But the guy I asked didn't know, they use a motif-based tool for this .. (aaaaarrrrrgggggghhhhh). Now, how to play with passwd and useradd to get it go ? Please reply by e-mail. Michael Plate ------------------------------ From: s936079@minyos.xx.rmit.OZ.AU (Greg Patten) Subject: Re: Getty Spasms Date: 29 Aug 1993 13:20:02 GMT bsa@kf8nh.wariat.org (Brandon S. Allbery) writes: >In article <25ocqf$83d@aggedor.rmit.OZ.AU> s936079@minyos.xx.rmit.OZ.AU (Greg Patten) writes: >>bazyar@mrcnext.cso.uiuc.edu (Jawaid Bazyar) writes: >>>I had to reinstall getty from the SLS disks, at which point the system >>>started working again. >> >>Probably because it was using the old getty and not getty_ps. >Peter modified the SLS version of getty_ps to accept them in either order. >He's posted that before. Well why on earth was it reporting: "Getty: (9600) cannot open connect line" then? From that I would guess (though I haven't been into the code) that it's trying to open a line called '9600'. I had this problem and solved it by putting the tty where the man told me it should be. As far as I can see this appears to be the problem...What do you think it is? -- _-_|\ Greg Patten. / \ \_.-.*/ <--Melbourne, Australia. v email: s936079@minyos.xx.rmit.oz.au ------------------------------ From: bsa@kf8nh.wariat.org (Brandon S. Allbery) Subject: Re: Getty Spasms Date: Sun, 29 Aug 1993 15:54:00 GMT In article <25qae2$cat@aggedor.rmit.OZ.AU> s936079@minyos.xx.rmit.OZ.AU (Greg Patten) writes: >bsa@kf8nh.wariat.org (Brandon S. Allbery) writes: >>In article <25ocqf$83d@aggedor.rmit.OZ.AU> s936079@minyos.xx.rmit.OZ.AU (Greg Patten) writes: >>>bazyar@mrcnext.cso.uiuc.edu (Jawaid Bazyar) writes: >>>>I had to reinstall getty from the SLS disks, at which point the system >>>>started working again. >>> >>>Probably because it was using the old getty and not getty_ps. > >>Peter modified the SLS version of getty_ps to accept them in either order. >>He's posted that before. > >Well why on earth was it reporting: >"Getty: (9600) cannot open connect line" then? Because, as the poster originally reported, he had grabbed the original getty_ps sources and recompiled it. For that matter, I don't think the sources in the "s" series are prepatched, either. Read, please. I *did* check that before posting. ++Brandon -- Brandon S. Allbery kf8nh@kf8nh.ampr.org bsa@kf8nh.wariat.org "MSDOS didn't get as bad as it is overnight -- it took over ten years of careful development." ---dmeggins@aix1.uottawa.ca ------------------------------ From: kai@depeche.toppoint.de (Kai Voigt) Subject: Let's collect KNOWN BUGS Date: Sun, 29 Aug 1993 10:58:20 GMT Hello, on a networking congress here in Kiel some German Linuxers decided to create a Linux workshop. One of our ideas was to collect a list called "KNOWN BUGS". This list should be mainly an index to bugs in the SLS distribution, i.e its single packages. The SLS is great, no question, but there are some security lacks, some programs don't work etc. 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 possible fixes for the bugs in this list. Another entry for each bug might be a classification of the bug: severe, akzeptable, not-a-real-bug or something like this. What does the rest of you think about it? Kai -- Kai Voigt, Werftstrasse 2, 24148 Kiel, Germany, +49 431 7297514 no .signature is good .signature ------------------------------ From: sperry@well.sf.ca.us (Michael P. Sperry) Subject: denial of service attacks Date: Sun, 29 Aug 1993 20:27:22 GMT Hi, While reading the excellent _Practical Unix Security_ by Garfinkel and Spafford (published by O'reilly & associates), I was made aware of denial of service attacks. One of the best ways to prevent such attacks I subsequently found out, was to force limits on the user via the ulimit command. After doing a 'ulimit -a' however, I realized that I do not know what constitutes reasonable limits. Does anyone else? Here are my current unacceptble limits: core file size unlimited # this I could change to say, 2 MB data seg size unlimited # I know what a data seg is but what's normal? max file size unlimited # stack size unlimited # cpu time unlimited # pipe size 7 # I have no clue what this one is open files 32 # This one seems ok The users will be mostly reading news and mail, I don't expect heavy compilations, etc. Mike sperry@well.sf.ca.us ------------------------------ From: sperry@well.sf.ca.us (Michael P. Sperry) Subject: restricting newsgroups Date: Sun, 29 Aug 1993 20:32:41 GMT I would like to offer certain infamous newsgroups to my users (a.b.p.e). However, I would like to be able to have people under age eighteen on my system. Does anyone know a method whereby I could prevent children from receving these newsgroups (besides not letting them on my system)? I was trying to work out a way using Unix groups, but this is more of a C-news type problem. Mike sperry@well.sf.ca.us ------------------------------ Subject: Re: Linux bbs software? From: ritz@ritz.mordor.com (Christopher Mauritz) Date: Sun, 29 Aug 93 10:32:22 -0400 Andreas Fatum (ace@acelab.ruhr.de) wrote: : In jrmt@argonaut.com (Jon Thackray) writes: : >I'm looking for one which supports Internet mail and news. The only one : >to do this is 'mbox' - but alas, it is all in German. (well it has some : >English support, but there's still some German text I can't get rid of). : Of course you can! The complete source is included so you only have to : translate some stuff. I compiled/installed the program last nite and I : think that Volker Schuermann did a great job on that one. It is fully : configurable on a per-level basis; you can restrict email to local : email only, allow mails to some given domains (uucp-neighbours, e.g.) : etc, the same with news. Online-games, file-sections, chat-system and : other goodies are also included. It compiles nearly out of the box. Perhaps, what the linux world needs then is a clever, bi-lingual and extremely kind person to translate the docs? Cheers, Chris -- "Now about the numbers. People like you always complain about the numbers. Why is the black score so low. The reason - they are more intelligent!" Rikiya Asano (ra01+@andrew.cmu.edu) ------------------------------ From: drew@juliet.cs.colorado.edu (Drew Eckhardt) Subject: Re: Let's collect KNOWN BUGS Date: Sun, 29 Aug 1993 23:35:39 GMT In article <1993Aug29.105820.750@depeche.toppoint.de> kai@depeche.toppoint.de (Kai Voigt) writes: >Hello, > >on a networking congress here in Kiel some German Linuxers >decided to create a Linux workshop. One of our ideas was >to collect a list called "KNOWN BUGS". This list should be >mainly an index to bugs in the SLS distribution, i.e its single >packages. The SLS is great, no question, but there are some >security lacks, some programs don't work etc. 1. It's my experience that many "bugs" aren't bugs and stem from users not understanding the correct behavior and what they need to do to get it (ie, boards jumpered right, etc). You need to screen bugs for false reports. 2. SLS is not Linux. As a collection of the linux kernel and various linux programs, it often lags begined the current state-of-the-art, and many bugs will be fixed in newer versions of things that aren't yet integrated with SLS. So, some of the bug reports here are going to be useless. 3. The development versions of various pieces of code (ie, many of the Linux SCSI drivers, the networking code, XFree86, etc) usualyl fix many current bugs (and introduce others) but are only available to a limited subset of the Linux users. So, bug reports on publically available versions of the code may be of limited usefulness. 4. I often get "bug reports" from users who fail to specify their configuration, what version they're using, and other important details. In cases like this, it is impossible to track down the bug. To prevent these problems, you should use a bug report form (use the MIT Xconsortium bug report form as an example) that gives enough information to track the bug down. It's also very hard to tell what's relevant, so some of the information will be extraneous. Along similar lines, this is what I said (after a list of know bugs that have been fixed in newer versions) in the SCSI FAQ : QUESTION: What do I do if I find a bug that still looks like a bug after I've read the FAQ? ANSWER: Your best bet is to send it to the SCSI channel of the mailing list, where it will be seen by all of the people who've contributed to the SCSI drivers. In your bug report, please provide as much information as possible regarding your hardware configuration, and all of the messages that Linux prints when it boots. If possible, try to isolate the bug to a specific function or line of code. Your chances of getting the bug fixed increase exponentially with the amount of information provided. The bottom line is that if we can't reproduce your bug, and you can't point at us what's broken, it won't get fixed. 5. Finally, many Linux bugs aren't Linux bugs, but GCC bugs, Xfree bugs, bugs in things that run under Linux but aren't necessarily Linux. Many of these packages have their own bug alias that should be mailed, as is the case with X, GCC, etc. You should probably post these bugs on a Linux community group incase it's something Linux specific (ie, in the 'C' library or kernel, or something that's POSIX rather than the BSD way the code expected), but they should also end up with the developers who are familiar with the package. >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 >possible fixes for the bugs in this list. Another entry for >each bug might be a classification of the bug: severe, akzeptable, >not-a-real-bug or something like this. > >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. -- Boycott USL/Novell for their absurd anti-BSDI lawsuit. | Condemn Colorado for Amendment Two. | Drew Eckhardt Use Linux, the fast, flexible, and free 386 unix | drew@cs.Colorado.EDU Will administer Unix for food | ------------------------------ From: drew@juliet.cs.colorado.edu (Drew Eckhardt) Subject: Re: denial of service attacks Date: Sun, 29 Aug 1993 23:59:09 GMT In article sperry@well.sf.ca.us (Michael P. Sperry) writes: >Hi, > While reading the excellent _Practical Unix Security_ by Garfinkel and >Spafford (published by O'reilly & associates), I was made aware of denial >of service attacks. One of the best ways to prevent such attacks I >subsequently found out, was to force limits on the user via the ulimit >command. After doing a 'ulimit -a' however, I realized that I do not know >what constitutes reasonable limits. Does anyone else? > Here are my current unacceptble limits: >core file size unlimited # this I could change to say, 2 MB It all depends on what your users are trying to do. Debugging programs like GCC and the X server, which can often eat 4M of memory, would be impossible with a low limit like that. I'd be inclined to pick a worst case scneario with your users usage, make that the hard limit, and put a lower soft limit for the normal case, 0 for users not doing development, in the system wide startupfiles. >data seg size unlimited # I know what a data seg is but what's normal? Again, it depends on the users. I've seen older versions of GCC chomp 32M of memory when grinding on initialized arrays, and I heard of one instance where a user was buying a > gigabyte drive for swap because they're application used over a gigabyte of memory. BSD has a default hard limit of 16M, soft limit of 8M. I've only seen problems with the soft limit when running GCC. >max file size unlimited # >stack size unlimited # A limited stack size will prevent runaway recursion, BSD has a default soft limit 512K and hard limit of 16M. I haven't seen any problems with it. >cpu time unlimited # >pipe size 7 # I have no clue what this one is The buffer size used for pipes, expressed in 512 byte blocks. Linux sets up a 4095 byte buffer for each pipe, which rounds down to 7 512 byte blocks. This is not adjustable. >open files 32 # This one seems ok Inodes are dynamically allocated, so it isn't as much of a problem under Linux as it is with other systems that have a fixed size inode table. > The users will be mostly reading news and mail, I don't expect heavy >compilations, etc. See above. I ran a lab of mostly BSD machines with the hard/soft limits outlined above, and my users didn't have any problems. -- Boycott USL/Novell for their absurd anti-BSDI lawsuit. | Condemn Colorado for Amendment Two. | Drew Eckhardt Use Linux, the fast, flexible, and free 386 unix | drew@cs.Colorado.EDU Will administer Unix for food | ------------------------------ ** 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 ******************************