From linux-bogus-owner@cs.unc.edu Sat Jul 30 10:31:49 1994 Return-Path: Message-Id: <199407300824.EAA03396@localhost> X-Authentication-Warning: cis-ts3-slip4.cis.brown.edu: Host localhost didn't use HELO protocol From: Mark_Weaver@brown.edu To: linux-bogus@cs.unc.edu Subject: Suggestions, bug reports and comments Reply-to: Mark_Weaver@brown.edu Date: Sat, 30 Jul 1994 04:24:38 -0400 Sender: linux-bogus-owner@cs.unc.edu Precedence: bulk Status: RO The /tmp, /var/tmp, and /var/spool/mail directories should have the sticky bit set so that people can't muck with each other's files. Many of the groff programs (gnroff, gtbl, geqn, gneqn, grefer, etc) should have hard links to programs with the "g" removed, for compatibility. /etc/hosts.equiv is the same as /etc/hosts.lpd, so the comments are wrong. The install.all script fails if any of the binary packages are missing. May I suggest that each call to pms be replaced by a shell function call, where the function checks to see if the file exists, and installs it if so? I installed bogus, and IMHO it was the best (by far) distribution for Linux yet. It was almost good enough to make me switch from NetBSD, but not quite. Here are a few specific bugs I found. Many of these should really be reported on the linux-activists channels, but those are very high volume lists for someone who doesn't even run Linux, so I'll post them here. rsh should ignore switches after the command name. In other words, you should be able to type "rsh host ls -l -g" without rsh interpreting the -l and -g as switches. This is the way it works on virtually all other systems. rsh doesn't work properly to Solaris 2.3. If I type "rsh host ls -l -g", where "host" is a Solaris machine, it only gives me part of the output, and then exits with exit code 0. Sometimes it's just part of the first line, sometimes it's several lines. This is over a 14.4kbps slip connection with an MTU of 296 bytes. Needless to say, this doesn't happen when rsh'ing from other systems, including Solaris, SunOS or NetBSD. It also doesn't happen when rsh'ing from Linux to SunOS 4.1.3. ytalk doesn't work when trying to talk to machines running the old talk daemon (e.g. SunOS and Solaris). It always reports errors "recv failed". The last time I tried Linux (in February), I tried to port ytalk myself and had the same problem. This time I've found the same behavior with the ytalk that comes with bogus. This time around I compiled xarchie, and it reports the exact same error when I try to make a query. All of this is over a slip link too. xon doesn't work for me. The exact same command works from NetBSD, but under Linux it just returns a 0 result code and does nothing noticable. At first I thought this was related to the rsh problem, since xon uses rsh, but xon doesn't work to either Solaris or SunOS, but rsh works on SunOS. I'll try Linux again in another couple of months. The drivers are superior to those in NetBSD, and Linux is noticably faster and thrashes less easily. Unfortunately, the network support isn't quite there yet, and that's very important for me. Mark -------------------------------------------------------------------- Email: Mark_Weaver@brown.edu | Brown University PGP Key: finger mhw@cs.brown.edu | Dept of Computer Science From linux-bogus-owner@cs.unc.edu Mon Aug 1 16:48:35 1994 Return-Path: Date: Mon, 1 Aug 1994 10:38:11 -0400 From: Rik Faith Message-Id: <199408011438.KAA00838@proteus.cs.unc.edu> To: Stephen Turnbull Cc: linux-bogus@cs.unc.edu Subject: Re: Japanese extensions for BOGUS In-Reply-To: [Stephen Turnbull ] Mon 1 Aug 94 16:40:44 JST References: <9408010740.AA07201@shako.sk.tsukuba.ac.jp> Sender: linux-bogus-owner@cs.unc.edu Precedence: bulk Status: RO On Mon 1 Aug 94 16:40:44 JST, Stephen Turnbull wrote: > (1) Does anyone know of such a package? There is "JE" for SLS, for > example. BOGUS does not currently contain a JE package. > (2) How hard would it be to port an SLS distribution (ie, of JE) to > use pms? I don't have the time or desire to do the thorough checking > to propose that it be made an "official" BOGUS extension package, but > would like to make it possible for others to avoid reinventing the > wheel. I haven't looked at JE and can't evalutate this. It would probably be best if someone who is familiar with the Japanese language does the port. From linux-bogus-owner@cs.unc.edu Mon Aug 1 09:53:48 1994 Return-Path: Date: Mon, 1 Aug 94 16:40:44 JST From: Stephen Turnbull Message-Id: <9408010740.AA07201@shako.sk.tsukuba.ac.jp> To: linux-bogus@cs.unc.edu Subject: Japanese extensions for BOGUS Sender: linux-bogus-owner@cs.unc.edu Precedence: bulk Status: RO I recently installed the Slackware distribution of Linux, but in view of the description of BOGUS in the announcement on col.announce, and Mark Weaver's comments on linux-bogus, I am strongly considering installing BOGUS instead. I have two questions related to Japanese language extensions for BOGUS. (1) Does anyone know of such a package? There is "JE" for SLS, for example. (2) How hard would it be to port an SLS distribution (ie, of JE) to use pms? I don't have the time or desire to do the thorough checking to propose that it be made an "official" BOGUS extension package, but would like to make it possible for others to avoid reinventing the wheel. +-----------------------------------------------------------------------+ | Stephen Turnbull | | University of Tsukuba, Institute of Socio-Economic Planning | | Tennodai 1-chome 1--1, Tsukuba, Ibaraki 305 JAPAN | | Phone: +81 (298) 53-5091 Fax: +81 (298) 55-3849 | | Email: turnbull@shako.sk.tsukuba.ac.jp | | | | Founder and CEO, Skinny Boy Associates | | Mechanism Design and Social Engineering | | REAL solutions to REAL problems of REAL people in REAL time! REALLY. | | Phone: +81 (298) 56-2703 | +-----------------------------------------------------------------------+ From linux-bogus-owner@cs.unc.edu Sat Jul 30 15:49:42 1994 Return-Path: Date: Sat, 30 Jul 1994 09:42:26 -0400 From: Rik Faith Message-Id: <199407301342.JAA21592@proteus.cs.unc.edu> To: Mark_Weaver@brown.edu Cc: linux-bogus@cs.unc.edu Subject: Re: Suggestions, bug reports and comments In-Reply-To: [Mark_Weaver@brown.edu ] Sat 30 Jul 1994 04:24:38 -0400 References: <199407300824.EAA03396@localhost> Sender: linux-bogus-owner@cs.unc.edu Precedence: bulk Status: RO Thanks very much for your comments. We'd like to encourage others to post similar comments to this mailing list. Patches are also welcome. [BTW, when BSD utilities are linked with GNU getopt, there are often problems parsing command line options. The long-term fix is to link with BSD getopt. The short term fix is to use "--" to mark the end of the real options: "rsh proteus -- ls -l -g" works fine, for example.] From linux-bogus-owner@cs.unc.edu Wed Aug 3 09:42:46 1994 Return-Path: Message-Id: <199408030733.DAA15778@localhost> X-Authentication-Warning: cis-ts3-slip5.cis.brown.edu: Host localhost didn't use HELO protocol From: Mark_Weaver@brown.edu To: linux-bogus@cs.unc.edu Subject: My comparison of Linux and NetBSD Reply-to: Mark_Weaver@brown.edu Date: Wed, 03 Aug 1994 03:33:40 -0400 Sender: linux-bogus-owner@cs.unc.edu Precedence: bulk Status: RO First of all, let me say that I genuinely love Linux, FreeBSD and NetBSD. It seems like so many people have to take sides on the flame war between Linux and NetBSD, but I don't see why. There seems to be a shortage of unbiased people who have given both systems a good shot. I've primarily been a NetBSD user, although I've tried Linux periodically, including for all of February this year using Slackware. I must warn you that there might well be some misinformation here. I'm just doing the best I can to give a reasonably unbiased comparison between the two systems based on my experience. If you must give this message out to people, please give it out in its entirety. DRIVERS ------- When it comes to drivers, Linux kicks NetBSDs ass big time. This makes sense, since Linux has been around for a lot longer than an Intel port of BSD. Console driver: Linux's is great. Support for 132x44 on my ATI GUP, vt100 (almost vt220?) emulation, scrollback, multiple VTs. NetBSD's sucks. The original "pccons" doesn't have multi-VTs nor does it support vt100. In fact, no unix box anywhere (except for *BSD) has a termcap entry for the braindead emulation. This means if you telnet anywhere, you won't be able to easily run emacs or any curses based program. Syscons (standard in FreeBSD now) has multiple VTs, but still doesn't emulate a vt100, and doesn't have things like scrollback or 132 column emulation (at least the last time I checked). PCVT, which will be in NetBSD 1.0, is the most promising yet, because it supports multi-VTs, vt220 emulation, and 132-column support on some cards (not mine :-( ), but it still isn't nearly as sexy and Linux's. IDE driver: Until recently, the IDE driver in NetBSD was completely unreliable. Now it's reliable for most drives, but some badly designed drives may still not work right. SCSI: SCSI works very well in NetBSD, and has for a long time. However, BSD will do its best to bypass the geometry remapping in the controller, and if you have an Ultrastor 34F (among others perhaps), NetBSD won't share that drive with anything else. This is because NetBSD bypasses the geometry remapping, but there's no way to turn off the BIOS remapping. Serial: Linux's serial driver is much better at dealing with slower serial chips on slow hardware. Also, if you have a serial mouse, Linux's mouse will move much more smoothly, because it sets the FIFO trigger much lower if you're using a slow baud rate. This is an easy fix on NetBSD, but I haven't gotten around to it yet. Sound: NetBSD doesn't have much for sound except for Soundblaster support. Even a PAS won't work presently, because a PAS needs some preconfiguration before it is Soundblaster compatible. FreeBSD has incorporated Linux's sound driver (which is great), but NetBSD won't because it doesn't want GPL'd stuff in the kernel, and because the Linux sound driver doesn't use Berkeley semantics. FPU emulator: Linux's is great, NetBSD's sucks big time. Clock: Believe it or not, the last time I checked, NetBSD doesn't even know how to set the hardware clock. You can set the time, but it won't keep across reboots. Floppies: The floppy driver on NetBSD works, but I don't have a great deal of faith in it. It also won't format floppies yet, although you can find patches to do this in various places. COMPATIBILITY ------------- NetBSD has Linux beat big time here. It's not Linux's fault; it just so happens that BSD has been around for a long time, and almost everything out there will compile cleanly on NetBSD. Furthermore, NetBSD is pretty close to POSIX.1 right now, and yet retains BSD compatibility just about everywhere except where BSD conflicts with POSIX.1. The problem is, it is will be LONG time before most applications are POSIX clean. It's amazing how many companies still haven't switched over the ANSI C yet! If you don't mind getting hacked up source code, or binaries, then this isn't a big problem. Enough people use Linux that just about everything has already been ported. I'm personally fanatical about having my system be "clean". I like to compile packages from source myself, and I like to get the source from the official distribution of the package (from the maintainer). Maybe this is silly, but that's just the way I am. That's one of the things I really like about BOGUS -- Virtually all the packages are gotten from the official source and the patches are shown in the notes files. This gives me a comforting feeling. Compare this to Slackware, which has a relatively messy source tree, much of which was hacked by many different people, and I don't even know who these people are. NEATNESS -------- Many people may not care about this, but I definitely do. I want my system to be a neat, well thought out distribution, without extra files all over the place and buggy programs. This has been probably my biggest beef with Linux distributions in the past. That's why I like BOGUS so much. It's a very neat source tree. It seems to me like BOGUS was created by starting with an empty tree and adding whatever was necessary to make it work and be a complete system. Contrast this to Slackware, which looks to me like Patrick took his machine at home and carved it up into packages. No matter how careful he is, there are bound to be duplicates of files and old programs which haven't been tested in a long time. Furthermore, for any given package, it's not known who's hacked on it. The *BSD's neatness is quite good. Although it hasn't been built from the ground up (like BOGUS) in a long time, there is a lot of attention to detail in the NetBSD group. SPEED ----- Linux seems quite a bit faster than NetBSD to me, although I haven't done any benchmarks. The shared library implementation in Linux is faster and has smaller executables due to fundamental differences in design, although NetBSD's shared libs are much easier to maintain from a developer's standpoint. I personally agree with the Linux philosophy here. Linux's scheduler is different. It's hard to say which one is better. It really depends on what you're doing. When I switch to Linux I think "wow, this is a better scheduler", but then when I switch back, I think the same thing for different cases. For whatever reason, on my 16meg machine, Linux seems to thrash MUCH less. I guess Linux makes better use of the machine's memory. The fact that most of the Linux filesystems write out inode changes asynchronously by default makes Linux much more responsive for certain things. Doing an "rm -rf" on a large directory, for instance, is usually MUCH faster on Linux. However, if there is a power failure during this operation, you may well be screwed. More on this later. MULTI-PLATFORM -------------- Not much to say here but the facts. NetBSD has a unified source tree (even the kernel) that currently has working ports for the i386, amiga, hp300, pc532, and sparc. There are also ports for the Mac, da30, pmax, sun3, and vax underway. Just about everything which isn't fundamentally machine specific is unified. All of the nasty big-endian/little-endian problems have been dealt with. It's hard for me to say that this changes my life all that much, but it somehow makes me feel better to know that I can recommend NetBSD to many of my friends who don't own intel hardware. NETWORKING ---------- It's a shame that the USL/BSDI lawsuit cast such a dark cloud over all the BSD code, but I can honestly say that over now. Anyway, I understand why the BSD networking code wasn't used for Linux, but it's a shame. Some say that the BSD networking code isn't all that great. At least one reputable person has said that the BSD networking code is more modularized and more cleanly layered than the Linux code. I really don't know myself. That's not all that relevant though. I've tried Linux three times, and I've watched the network code improve dramatically. From what I see now, it is stable and efficient. The only problem is that some programs still don't work as they should. Like I mentioned in an earlier post, rsh doesn't work properly to Solaris machines, and I've still had no luck getting ytalk or xarchie to work. Ytalk is very important to me, because it's the only client I know of that will let me talk to someone on a SunOS or Solaris machine (running the old talk daemon). Since I go to a school that uses Suns, this is important for me. I'm really not sure whether this is even Linux's fault. It may well be that ytalk and xarchie depend on the undocumented semantics on the BSD networking code. In a way, this makes Linux a good thing, because it will force people to write cleaner code. On the other hand, it's more of a pain for me, because I'd rather spend my time writing new software as opposed to porting old software. Anyway, the remaining "problems" in the net code probably fall into the compatibility category. I'm sure they'll be fixed. FILE SYSTEM LAYOUT ------------------ In my view, this is a big problem with Linux. It's great that what the file system standard committee is doing, but it'll probably be some time before all the software is updated to reflect this. One of the things missing in the BOGUS distribution was mail software. I got the official Sendmail 8.6.9 distribution, which conveniently came with a makefile for Linux. A comment at the top said something around the lines of "Linux doesn't really have a standard place to put things, so you'll have to edit this for whatever distribution you have". I was unable to find the FSSTND document, so I got some configuration files that other people had made up. Some people put the mailboxes in /usr/spool/mail and others put them in /var/spool/mail. This is not the worst of it. BSD has a long history and a relatively stable file system layout. This is important to me. Linux's multiple distributions has been a good thing for the most part, I think. However, the lack of consistency in file system layout between distributions has been very crippling for certain things (like mail software). FILE SYSTEMS ------------ The Berkeley Fast File System is fantastic. It is actually quite fast, considering that is makes a rather serious speed compromise in the name of reliability. BSD's fsck has been VERY carefully put together. Someone with a lot of spare time enumerated every possible file system corruption that could take place in the event of a system crash, and provided a way to fix every single of them correctly. It was found that this could only be done reliably if inode changes were written out sychronously. In other words, any system call that changes an inode blocks the calling process until the actual write to disk takes place. If you don't enforce this, then a random power failure or crash might cause serious damage that fsck cannot deterministically fix. I've had much less luck with e2fsck. Back in February, I had several file system corruptions that e2fsck couldn't fix, although most were minor. I looked through the e2fsck code and found and fixed several bugs. They may well have been fixed by now; unfortunately I lost my fixes accidentally while switching back to NetBSD. The ext2fs has an option to write out the inodes synchronously, which is a good thing, although they have noticed that it slows things down quite a bit. I dunno, it depends if you want to live on the edge or not. I keep a lot of stuff on my computer, and I am (grudgingly) willing to trade speed for safety. On BSD, it is time honored tradition to run fsck every time the system boots, and I feel safer that way. I tried configuring my system to run e2fsck every time, but found it intolerable. That's because e2fsck is SIGNIFICANTLY slower than BSD fsck with the same number of files. BSD takes about 2 minutes to check my 1.2 gig drive, and e2fsck takes about 15 minutes. On the Linux side -- Linux co-exists much better with other OSes. Linux uses the standard MSDOS partition table, where BSD uses its own disklabel stored elsewhere. Furthermore, BSD uses the drive's native geometry when possible rather than the BIOS-friendly translated geometry. On IDE drives, it doesn't have a choice, but on many SCSI systems it does. If NetBSD's notion of drive geometry doesn't match up with another OSes notion, you're going to have one hell of a time trying to get them on the same drive. Of course, using the native drive geometry can help BSD ffs place files intelligently, but I'm not sure this outweighs the disadvantages. Also, BSD 4.4 (integrated into NetBSD) has some nifty virtual filesystem features that I'm not aware of in Linux (although I might be wrong). 1. BSD allows union-mounting of filesystems, so you can mount a filesystem onto a non-empty directory and see files from both filesystems in the same directory. (Linux might well have this one) 2. BSD allows you to mount a mirror of one directory into another. For example, you could mount a mirror of /usr/src into a directory that's accessable via anonymous ftp, even if /usr/src isn't on it's own partition. Note that you couldn't do this with symlinks. 3. BSD allows you to mount an overlay filesystem such that all changes will be made to one of the file systems. For instance, you could overlay some hard disk space on top of a cdrom, and then make changes to what's there. Only the changes would be stored on the hard disk. 4. BSD can treat any file as if it's a volume. This indirectly supports swap files, since you can use any volume as a swap partition. 5. BSD can mount a partition with a translation table for user/group ids. So if you need to mount a drive that was used on another system with a different passwd file, no problem. There's probably more that I'm forgetting. Some of these things could be easily implemented in Linux, but some might not be easily done without changing the virtual filesystem interface. I'm really not sure, but BSD 4.4 supports the notion of file system layers. Don't ask me what that is, because I'm not entirely sure, but I know that it's a fairly new idea that might well have been developed at Berkeley. BOOT LOADER ----------- LILO is the king of boot loaders. What else need be said? I wish NetBSD had something that came even close. SECURITY -------- NetBSD is based on BSD 4.4, and one of the things that Berkeley did for 4.4 was to carefully re-evaluate the entire security framework. This gives me more faith somehow, although I admit it may be completely unfounded. Also, BSD has been using shadow passwords for some time now, and all the utilities work properly with them. This is very important, because nowadays it isn't all that hard to crack a passwd file. The publicly readable password file has had '*'s in every password entry since day one of 386BSD, so we were never susceptable to things like the rsh problem that struck certain Linux distributions a few months ago. AUTOMATIC MAINTENANCE --------------------- Most real unix systems have three cron jobs that are normally installed: daily, weekly, and monthly. Daily does the most work. On NetBSD, daily does the following key things: 1. Deletes old files in /tmp that haven't been touched for a couple of days. 2. Rotates the log files -- gzip's the current one, tells the kernel or whatever program to open up a fresh one, and takes it from there. 3. Does a security check of the whole system -- checks for changes to setuid programs or devices, checks permissions on certain key files and directories, looks for errors in root's setup files, looks for errors in /etc/passwd, etc, and mails a report to root. Every day. 4. Searches for possible core files, fsck's all file systems (although doesn't fix anything by default) checks the outgoing mail spool, etc and mails a report to root. I've gotten very used to this sort of thing, and I haven't found a Linux distribution that has it so far. It doesn't belong all that high on the priority list, but I always miss it when I try out Linux. POPULARITY ---------- MANY more people run Linux than FreeBSD. Quite a few more people run FreeBSD than NetBSD. There is a definite advantage to sticking with the crowd. First of all, there's more man-power working on Linux. Second, because it's a bigger market, there's much more likely to be commercial software available for Linux than for NetBSD. For instance, Doom. Actually, the same guy who's doing the Linux port of Doom offered to port it to NetBSD if someone let him borrow a NetBSD machine for a month or so. Unfortunately, there were no takers. :-( In any case, this is a big advantage. Not that I'm not a free software nut, but I like Doom too! :-) SUMMARY ------- I can only speak for myself here, and you may have a different set of priorities -- in fact, I'm a bit odd-ball, and you probably do. But, to summarize: When I run Linux, I love the speed, hardware support, console driver, etc. I also feel like I'm part of a much bigger community, and in many ways a more friendly community. Also, I really like the fact that Linux has been written from scratch. On the other hand, I usually get frustrated very quickly having to port so many programs to Linux. I also am a HEAVY user of networking stuff, and miss things like ytalk and xarchie. I simply can't deal without a working rsh. I can easily imagine myself switching to Linux one day. Part of it is that I have a love/hate relationship with the NetBSD team. On one hand, they are extremely competent and knowledgeable people with a perfectionist nature about the code they put into NetBSD. They generally won't accept code that is badly written, even if it works. I like this. On the other hand, sometimes it pisses me off that they'll leave important things out because no one has done a good job writing them yet. Also, if a certain problem with NetBSD isn't important to one of the core team, it often gets ignored for a while. Of course, there's nothing stopping me from having my own private patches to the tree, and I have my own set of patches that they won't except. Every time I sup (system update protocol) a new version (usually every 2-3 days), I remove my patches first, sup the changes, then re-apply my patches. The bottom line is that although there are problems with both systems, the problems with Linux affect me much more often than the problems with NetBSD. And the problems with NetBSD are probably more easily fixable. My major problem with Linux is, sadly, it's lack of compatibility with BSD. If I could just port most of Linux's drivers to NetBSD, I'd probably have the perfect system for my needs. In fact, I periodically dream about having enough time to put together such a distribution. :-) Mark -------------------------------------------------------------------- Email: Mark_Weaver@brown.edu | Brown University PGP Key: finger mhw@cs.brown.edu | Dept of Computer Science From linux-bogus-owner@cs.unc.edu Thu Aug 4 12:59:57 1994 Return-Path: Message-Id: <199408041244.MAA00753@bbj.ibp.fr> Subject: Re: My comparison of Linux and NetBSD To: Mark_Weaver@brown.edu Date: Thu, 4 Aug 1994 12:44:30 +0000 () Cc: linux-bogus@cs.unc.edu In-Reply-To: <199408030733.DAA15778@localhost> from "Mark_Weaver@brown.edu" at Aug 3, 94 03:33:40 am X-Mailer: ELM [version 2.4 PL23beta2] Content-Type: text Content-Length: 9689 Sender: linux-bogus-owner@cs.unc.edu Precedence: bulk Status: RO Hi, > First of all, let me say that I genuinely love Linux, FreeBSD and > NetBSD. It seems like so many people have to take sides on the > flame war between Linux and NetBSD, but I don't see why. There > seems to be a shortage of unbiased people who have given both systems > a good shot. Agreed. I have both FreeBSD and Linux on my PC myself. > I've primarily been a NetBSD user, although I've tried Linux > periodically, including for all of February this year using Slackware. > > I must warn you that there might well be some misinformation here. > I'm just doing the best I can to give a reasonably unbiased comparison > between the two systems based on my experience. OK. I must at least reply to the filesystem comparison. I only want to raise technical points, I don't want to start a flame war :-) > FILE SYSTEMS > ------------ > The Berkeley Fast File System is fantastic. It is actually quite > fast, considering that is makes a rather serious speed compromise > in the name of reliability. Agreed. > BSD's fsck has been VERY carefully put together. Someone with a > lot of spare time enumerated every possible file system corruption > that could take place in the event of a system crash, and provided > a way to fix every single of them correctly. It was found that > this could only be done reliably if inode changes were written out > sychronously. In other words, any system call that changes an > inode blocks the calling process until the actual write to disk > takes place. If you don't enforce this, then a random power failure > or crash might cause serious damage that fsck cannot deterministically > fix. Hmmm, there has been a discussion one or two months ago in the newgroups about the BSD fsck problems. Let's try to summarize. By writing meta-data (inodes, directory entries, bitmaps) sychronously, the BSD FS tries to ensure that they (the meta-data) are consistent for fsck but it does not enforce the data consistency. Let's take an example: - you remove a file A => A's directory entry, A's inode and bitmaps are written to the disk, - you create a new file B and write data to it, blocks previously allocated to A are allocated to B => B's directory entry, B's inode and bitmaps are written to the disk but data is only written in the buffer cache copy of the blocks, - the system crashes before update does a sync, - fsck runs and is perfectly happy with the FS even if the blocks allocated to B still contain A's data (since they have not been written to the disk). So you end up with data corruption (and security problems since you can access data previously contained in a deleted file) and BSD fsck does not correct the problem. > I've had much less luck with e2fsck. Back in February, I had several > file system corruptions that e2fsck couldn't fix, although most were > minor. I looked through the e2fsck code and found and fixed several > bugs. They may well have been fixed by now; unfortunately I lost my > fixes accidentally while switching back to NetBSD. Back in February, Linux was using my version of e2fsck which was quite slow and inefficient (and the source code had become a big mess :-). We have now switched to a new rewritten version of e2fsck: Theodore T'so has spent lots of time studying FS problems and has come with a very good FS checker (basically, he was inspired by a Usenix paper describing some extensions added to BSD fsck; we don't know if the extensions described in this paper made their way in the standard BSD fsck). > The ext2fs has an option to write out the inodes synchronously, > which is a good thing, although they have noticed that it slows > things down quite a bit. I dunno, it depends if you want to live > on the edge or not. I keep a lot of stuff on my computer, and I > am (grudgingly) willing to trade speed for safety. I have added synchronous writes to ext2fs as an option just to tell BSD people "we have it too" :-))) You're right: its awfully slow but you can restrict it to a subset of files (via file attributes). This way, you can select files on which synchronous writes apply and this helps in speed terms. Please, also note that in Linux 1.1.x, the kernel assigns a priority to buffers. Buffers containing meta-data have a high priority and are written back to the disk before buffers containing data (usually 5 seconds after they have been modified). This allows Linux to approach synchronous writes without some of their disadvantages (for instance, if you delete 10 files in the same directory block, BSD writes the directory block 10 times, Linux writes it only one time). > On BSD, it is time honored tradition to run fsck every time the > system boots, and I feel safer that way. I tried configuring my > system to run e2fsck every time, but found it intolerable. That's > because e2fsck is SIGNIFICANTLY slower than BSD fsck with the same > number of files. BSD takes about 2 minutes to check my 1.2 gig > drive, and e2fsck takes about 15 minutes. OLD versions of e2fsck (my versions :-) are very slow. Ted's version (the standard one now) is much faster and should be as fast as BSD's one. BTW, I think that the clean flag used by the FS kernel code and fsck to avoid unecessary checks is planned for inclusion in BSD :-) At least, the FreeBSD people plan to integrate it and 4.4BSD's superblock definition contains: /* * Super block for a file system. */ struct fs { ... char fs_clean; /* file system is clean flag */ ... }; The fs_clean field seems to be reserved for this feature (but it does not seem to be used in 4.4BSD). > On the Linux side -- Linux co-exists much better with other OSes. > Linux uses the standard MSDOS partition table, where BSD uses its > own disklabel stored elsewhere. Furthermore, BSD uses the drive's > native geometry when possible rather than the BIOS-friendly translated > geometry. On IDE drives, it doesn't have a choice, but on many > SCSI systems it does. If NetBSD's notion of drive geometry doesn't > match up with another OSes notion, you're going to have one hell > of a time trying to get them on the same drive. > > Of course, using the native drive geometry can help BSD ffs place > files intelligently, but I'm not sure this outweighs the disadvantages. Modern drives tend to be optimized for sequential reads and writes. Using the physical geometry in the FS to try to optimize files placement may not be the best thing to do on these drives. If the FS only tries to allocate contiguous blocks for files (like ext2fs does by using preallocation), the disk may make a better optimization (without the overhead in the kernel code). > Also, BSD 4.4 (integrated into NetBSD) has some nifty virtual filesystem > features that I'm not aware of in Linux (although I might be wrong). > > 1. BSD allows union-mounting of filesystems, so you can mount a > filesystem onto a non-empty directory and see files from > both filesystems in the same directory. (Linux might well > have this one) > 2. BSD allows you to mount a mirror of one directory into another. > For example, you could mount a mirror of /usr/src into a > directory that's accessable via anonymous ftp, even if /usr/src > isn't on it's own partition. Note that you couldn't do this > with symlinks. > 3. BSD allows you to mount an overlay filesystem such that all changes > will be made to one of the file systems. For instance, you could > overlay some hard disk space on top of a cdrom, and then make > changes to what's there. Only the changes would be stored on the > hard disk. > 4. BSD can treat any file as if it's a volume. This indirectly > supports swap files, since you can use any volume as a swap > partition. > 5. BSD can mount a partition with a translation table for user/group > ids. So if you need to mount a drive that was used on another > system with a different passwd file, no problem. I think that Linux has some of these (3 looks like IFS to me for instance) but it lacks other ones. Anyway, I'll check the 4.4BSD FS code and see if some of these can be added to Linux :-) > There's probably more that I'm forgetting. Some of these things > could be easily implemented in Linux, but some might not be easily > done without changing the virtual filesystem interface. I'm really > not sure, but BSD 4.4 supports the notion of file system layers. > Don't ask me what that is, because I'm not entirely sure, but I > know that it's a fairly new idea that might well have been developed > at Berkeley. OK. I'll have to look at this :-) > [...] > > The bottom line is that although there are problems with both > systems, the problems with Linux affect me much more often than > the problems with NetBSD. And the problems with NetBSD are probably > more easily fixable. My major problem with Linux is, sadly, it's > lack of compatibility with BSD. If I could just port most of > Linux's drivers to NetBSD, I'd probably have the perfect system > for my needs. In fact, I periodically dream about having enough > time to put together such a distribution. :-) An my major problem with BSD is its lack of compatibility with Linux :-) I also dream of porting BSD features to Linux. I am currently studying 4.4BSD-Lite FS code and I have already integrated some new features into ext2fs but they are not part of the standard kernel yet. > > Mark > -------------------------------------------------------------------- > Email: Mark_Weaver@brown.edu | Brown University > PGP Key: finger mhw@cs.brown.edu | Dept of Computer Science > Remy From linux-bogus-owner@cs.unc.edu Tue Aug 9 02:53:03 1994 Return-Path: Date: Mon, 8 Aug 1994 20:43:46 -0400 From: John Rhoades Message-Id: <199408090043.UAA00649@medusa.cs.unc.edu> To: linux-bogus@cs.unc.edu Subject: INSTALL instructions location Sender: owner-linux-bogus@cs.unc.edu Precedence: bulk Status: RO Perhaps the INSTALL file should be put at the top level of the ftp archive. I had trouble finding it. Hint: boot with the boot disk and then do "less INSTALL". From linux-bogus-owner@cs.unc.edu Mon Aug 8 23:36:17 1994 Return-Path: Message-Id: <199408082123.RAA28743@localhost> X-Authentication-Warning: cis-ts3-slip5.cis.brown.edu: Host localhost didn't use HELO protocol From: Mark_Weaver@brown.edu To: linux-bogus@cs.unc.edu Subject: Re: My comparison of Linux and NetBSD In-reply-to: Your message of "Thu, 04 Aug 1994 12:44:30 -0000." <199408041244.MAA00753@bbj.ibp.fr> Reply-to: Mark_Weaver@brown.edu Date: Mon, 08 Aug 1994 17:23:36 -0400 Sender: owner-linux-bogus@cs.unc.edu Precedence: bulk Status: RO Remy.Card@masi.ibp.fr writes: > Hmmm, there has been a discussion one or two months ago in the > newgroups about the BSD fsck problems. Let's try to summarize. By writing > meta-data (inodes, directory entries, bitmaps) sychronously, the BSD FS tries > to ensure that they (the meta-data) are consistent for fsck but it does not > enforce the data consistency. Let's take an example: > - you remove a file A => A's directory entry, A's inode and bitmaps are > written to the disk, > - you create a new file B and write data to it, blocks previously > allocated to A are allocated to B => B's directory entry, B's inode > and bitmaps are written to the disk but data is only written in the > buffer cache copy of the blocks, > - the system crashes before update does a sync, > - fsck runs and is perfectly happy with the FS even if the blocks > allocated to B still contain A's data (since they have not been > written to the disk). > > So you end up with data corruption (and security problems since you can > access data previously contained in a deleted file) and BSD fsck does not > correct the problem. Sure, you have a data corruption, but at least the meta-data is intact so you won't suffer catastrophic loss of data. There is no known way to protect all data from corruption without serious loss of speed (like the log-based methods in database systems). I'd just like to avoid having the directory structure get corrupted from a crash. Then at least I can feel safe about files that weren't being written during the crash. > Back in February, Linux was using my version of e2fsck which was quite > slow and inefficient (and the source code had become a big mess :-). We have > now switched to a new rewritten version of e2fsck Great! (scribbles off one item on my list of Linux cons :) > Please, also note that in Linux 1.1.x, the kernel assigns a priority > to buffers. Buffers containing meta-data have a high priority and are writte > n > back to the disk before buffers containing data (usually 5 seconds after they > have been modified). This allows Linux to approach synchronous writes withou > t > some of their disadvantages (for instance, if you delete 10 files in the > same directory block, BSD writes the directory block 10 times, Linux writes i > t > only one time). This is nice, and I definitely notice a major speed advantage to Linux when doing things that modify a large number of inodes (like rm -rf). What would you say is the reliability of ext2fs now? If I'm doing heavy file manipulation (including meta-data manipulation), and the system crashes, can I feel safe that I won't lose files that weren't being written at the time? This is very important to me. > OLD versions of e2fsck (my versions :-) are very slow. Ted's version > (the standard one now) is much faster and should be as fast as BSD's one. Very cool. > > [list of BSD virtual file system features deleted] > > I think that Linux has some of these (3 looks like IFS to me for > instance) but it lacks other ones. Anyway, I'll check the 4.4BSD FS code > and see if some of these can be added to Linux :-) I'm sure that Linux will overtake NetBSD in this area at some point. Based on what I've seen, I feel that I will eventually switch to Linux. Some day, when Linux's BSD compatibility has improved and when more software is POSIX clean, I will have no more reasons to use NetBSD and plenty of reasons to use Linux. In fact, I will probably install Linux on my smaller hard drive and work on solving some of the problems I have with it. Also, if I could get more proficient at porting programs to Linux, the BSD compatibility may be less important to me. In fact, right now there are really only three things keeping me from running Linux: 1. Networking problems with certain programs (e.g. ytalk and xarchie) 2. No strong adherence to a file system standard yet 3. Trouble porting various programs to Linux Mark -------------------------------------------------------------------- Email: Mark_Weaver@brown.edu | Brown University PGP Key: finger mhw@cs.brown.edu | Dept of Computer Science From linux-bogus-owner@cs.unc.edu Fri Aug 26 06:43:06 1994 Return-Path: Date: Fri, 26 Aug 1994 00:31:08 -0400 From: "Guy W. Hulbert" Message-Id: <199408260431.AAA02232@aries.yorku.ca> To: linux-bogus@cs.unc.edu Subject: Add Ons Sender: owner-linux-bogus@cs.unc.edu Precedence: bulk Status: RO Hi again. I have now downloaded the TAR_FILES and NOTES directories to a machine on which I am sysadmin. I will move everything to my own PC as soon as I get an ethernet card. This may take a while. In the meantime, I notice that bogus does not seem to include: f2c (FORTRAN) ftape (QIC-80 Tapes) both of which I want. I have source for both so I will try to learn enough about pms to write "Notes" files for these two things when I install them. I will do f2c as soon as I get bogus installed and ftape a little later. Is anyone else interested in or working on these? --GH guy@aries.phys.yorku.ca From linux-bogus-owner@cs.unc.edu Wed Aug 24 22:26:07 1994 Return-Path: Date: Wed, 24 Aug 1994 15:33:28 -0400 (EDT) From: Brian Hughes Subject: Re: vi: elvis vs. VIM To: linux-bogus@cs.unc.edu In-Reply-To: <199408241856.OAA18750@localhost> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII content-length: 1012 Sender: owner-linux-bogus@cs.unc.edu Precedence: bulk Status: RO I've been an elvis user for a few years now just because it's what came with whatever distribution I happened to be running. I tried VIM once and found that elvis' '==' command was missing (to wrap a long line into a paragraph), so I switched back to elvis. In all honesty, I wish I hadn't become so dependent on elvis' features. All the Sun machines around here run Sun's implementation of vi (I assume- I don't know what it actually is, but I'm sure it's not elvis) and don't support ==. I think we should use the most "kosher" vi clone we can find so we don't have to worry about implementation specific features and options. (It's another compatibility issue...) There's my 2 cents- see you later! - - - - - - - -Brian Hughes- - - - - - - Systems Engineer email: bhu@amherst.com phone: (716)631-0610 Amherst Systems, Inc. bwh8918@rit.edu fax: (716)631-0629 - - - - - - - -- -- - - - - - - From linux-bogus-owner@cs.unc.edu Wed Aug 24 21:11:46 1994 Return-Path: Message-Id: <199408241856.OAA18750@localhost> X-Authentication-Warning: cis-ts3-slip4.cis.brown.edu: Host localhost didn't use HELO protocol From: Mark_Weaver@brown.edu To: Rik Faith cc: linux-bogus@cs.unc.edu Subject: Re: vi: elvis vs. VIM In-reply-to: Your message of "Wed, 24 Aug 1994 13:22:49 EDT." <199408241722.NAA06905@proteus.cs.unc.edu> Reply-to: Mark_Weaver@brown.edu Date: Wed, 24 Aug 1994 14:56:52 -0400 Sender: owner-linux-bogus@cs.unc.edu Precedence: bulk Status: RO Rik Faith writes: > For those of you who use vi, and who have tried both VIM and Elvis, do you > think one is better? Is there another vi clone that provides better vi > emulation? I'm most interested in compatibility and stability. Thanks for > your input. [No editor flame-wars allowed, this is a very specific > technical question about vi clones :-)]. I'm a heavy vi user, and my strong preference is nvi. Nvi was written by Keith Bostic for BSD 4.4, and it's extremely vi compatible, and has some advanced features as well. Some advanced features I like are: 1. Infinite undo 2. Multiple buffers 3. Arbitrary split screens nvi can be gotten at ftp.cs.berkeley.edu:ucb/4bsd, and it includes Linux support. The only slight drag is that it uses curses, and the gnu curses library doesn't do much optimization. In particular, scrolling seems to degrade to full screen redraws. Mark -------------------------------------------------------------------- Email: Mark_Weaver@brown.edu | Brown University PGP Key: finger mhw@cs.brown.edu | Dept of Computer Science From linux-bogus-owner@cs.unc.edu Wed Aug 24 19:51:11 1994 Return-Path: Date: Wed, 24 Aug 1994 13:22:49 -0400 From: Rik Faith Message-Id: <199408241722.NAA06905@proteus.cs.unc.edu> To: linux-bogus@cs.unc.edu Subject: vi: elvis vs. VIM Sender: owner-linux-bogus@cs.unc.edu Precedence: bulk Status: RO For those of you who use vi, and who have tried both VIM and Elvis, do you think one is better? Is there another vi clone that provides better vi emulation? I'm most interested in compatibility and stability. Thanks for your input. [No editor flame-wars allowed, this is a very specific technical question about vi clones :-)]. From linux-bogus-owner@cs.unc.edu Sat Aug 20 01:05:44 1994 Return-Path: Message-Id: <199408192248.SAA00289@localhost> From: Mark_Weaver@brown.edu To: linux-bogus@cs.unc.edu Subject: Re: NetKits In-reply-to: Your message of "Fri, 19 Aug 1994 12:02:32 EDT." <199408191602.MAA13380@localhost> Reply-to: Mark_Weaver@brown.edu Date: Fri, 19 Aug 1994 18:48:36 -0400 Sender: owner-linux-bogus@cs.unc.edu Precedence: bulk Status: RO Mark_Weaver@brown.edu writes: > By the way, this version changes domainname to dnsdomainname. > Furthermore, since both were links to hostname, and hostname no longer > recognizes domainname when it is run, domainname will break when you > install this version. If you want to maintain compatibility, you'll > have to put a little shell script in place of domainname. Here's mine: > > ---------------------------------------- > #!/bin/sh > > exec dnsdomainname > ---------------------------------------- Actually, a more appropriate one would be: ---------------------------------------- #!/bin/sh exec /bin/dnsdomainname "$@" ---------------------------------------- Mark -------------------------------------------------------------------- Email: Mark_Weaver@brown.edu | Brown University PGP Key: finger mhw@cs.brown.edu | Dept of Computer Science From linux-bogus-owner@cs.unc.edu Fri Aug 19 18:26:54 1994 Return-Path: Message-Id: <199408191602.MAA13380@localhost> From: Mark_Weaver@brown.edu To: linux-bogus@cs.unc.edu Subject: Re: NetKits In-reply-to: Your message of "Fri, 19 Aug 1994 08:48:29 EDT." <199408191248.IAA11843@proteus.cs.unc.edu> Reply-to: Mark_Weaver@brown.edu Date: Fri, 19 Aug 1994 12:02:32 -0400 Sender: owner-linux-bogus@cs.unc.edu Precedence: bulk Status: RO Rik Faith writes: > Even newer NetKits have appeared on Linus' machine in the last 24 hours: > NetKit-A-0.06.tar.gz > NetKit-B-0.05.tar.gz I've already made up a Notes file for NetKit-A-0.06.tar.gz. Here it is. It builds, installs, and seems to work fine, although I haven't tested it extensively yet. Note that bind and wu-ftp are no longer in there, and the nfs.5 man-page seems to have disappeared. Also, there is no longer a net.conf file. Now rc.net does everything manually. This also includes fixes for some bugs I found in version 0.04. I have reported the bugs to the appropriate people. By the way, this version changes domainname to dnsdomainname. Furthermore, since both were links to hostname, and hostname no longer recognizes domainname when it is run, domainname will break when you install this version. If you want to maintain compatibility, you'll have to put a little shell script in place of domainname. Here's mine: ---------------------------------------- #!/bin/sh exec dnsdomainname ---------------------------------------- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Networking Kit A: Basic Linux-specific utilities %n NetKit-A %v 0.06 %c * %l * %b * %d * %f nic.funet.fi:/pub/OS/Linux/PEOPLE/Linus/net-source/NetKit %t NetKit-A-0.06.tar.gz %w utils %% # Copyright 1994 Mark Weaver # All rights reserved. # See the BOGUS.LICENSE file for distribution restrictions. # # Derived from NetKit-A-0.04 Notes file by Rickard E. Faith, # Kevin E. Martin, and Doug L. Hoffman %setup patch -p1 -s << 'PATCH_EOF' && *** NetKit-A-0.06/etc/hosts.equiv.mhw1 Fri Aug 5 18:52:31 1994 --- NetKit-A-0.06/etc/hosts.equiv Thu Aug 18 17:41:41 1994 *************** *** 1,5 **** # ! # hosts.lpd This file describes the names of the hosts which are # to be considered "equivalent", i.e. which are to be # trusted enought for allowing rsh(1) commands. # --- 1,5 ---- # ! # hosts.equiv This file describes the names of the hosts which are # to be considered "equivalent", i.e. which are to be # trusted enought for allowing rsh(1) commands. # *** /dev/null Tue Aug 16 09:27:47 1994 --- NetKit-A-0.06/etc/issue.net Thu Aug 18 17:52:53 1994 *************** *** 0 **** --- 1,3 ---- + + Welcome to HOSTNAME, an HOSTTYPE running SYSTEM VERSION + *** NetKit-A-0.06/etc/rc.net.mhw1 Thu Aug 11 09:27:19 1994 --- NetKit-A-0.06/etc/rc.net Thu Aug 18 17:55:34 1994 *************** *** 30,37 **** # Start the NAMED/BIND name server. Enable this, if you want to use this # PC as a name *server*. You don't need it, if you use only other computers # as name servers. ! #if [ -x /etc/named ]; then ! # /etc/named #fi # Start the printer daemon. --- 30,37 ---- # Start the NAMED/BIND name server. Enable this, if you want to use this # PC as a name *server*. You don't need it, if you use only other computers # as name servers. ! #if [ -x /usr/sbin/named ]; then ! # /usr/sbin/named #fi # Start the printer daemon. *** NetKit-A-0.06/ytalk-3.0.1/Imakefile.mhw1 Tue Jul 26 08:18:35 1994 --- NetKit-A-0.06/ytalk-3.0.1/Imakefile Thu Aug 18 17:46:15 1994 *************** *** 1,64 **** ! #### Imakefile for YTalk version 3.0 #### ! # ! # NOTICE ! # ! # Copyright (c) 1990,1992,1993 Britt Yenne. All rights reserved. ! # ! # This software is provided AS-IS. The author gives no warranty, ! # real or assumed, and takes no responsibility whatsoever for any ! # use or misuse of this software, or any damage created by its use ! # or misuse. ! # ! # This software may be freely copied and distributed provided that ! # no part of this NOTICE is deleted or edited in any manner. ! # ! ! ################################### ! ## CONFIGURATION (The Fun Part) ## ! ################################### ! # ! # If your machine does not support TERMIOS (example: any NeXT running ! # NeXTStep up to and including version 3.1), then uncomment the following ! # line. ! #TDEFS = -DUSE_SGTTY ! # ! # If you are running an older Sun OS using YP (now known as NIS), you might ! # need to uncomment the next line if ytalk asks you "Who are you?" ! ! #SLIBS = -lsun ! ! # ! # If you are on a sun running solaris 2.* you might need to uncomment the ! # following line. ! ! #SLIBS = -lnsl -lsocket ! ! # ! # If your machine has a 64-bit architecture or uses 64-bit 'long's, then you ! # will need to uncomment the following line. ! ! #BDEFS = -DY64BIT ! ! # ! # If you have (or want) a system-wide .ytalkrc file, uncomment the next ! # line and set it to the correct pathname. The backslashes must remain ! # before each double-quote. ! ! #RCDEF = -DSYSTEM_YTALKRC=\"/usr/local/etc/ytalkrc\" ! ! # ! # If you plan to install ytalk on your system, you may want to modify ! # the following lines. Y_BINDIR is where the binary will be placed. ! # Y_MANDIR is where the manpage will be placed. Y_BINDIR = /usr/local/bin Y_MANDIR = /usr/local/man/man1 ! ############################################################ ! ## Past this point, you shouldn't need to modify anything ## ! ############################################################ LIB = -lcurses -ltermcap $(SLIBS) $(XLIB) DEFINES = -DUSE_X11 -I/usr/local/include $(TDEFS) $(BDEFS) $(RCDEF) LDFLAGS = $(LDOPTIONS) --- 1,75 ---- ! /* ! * ### Imakefile for YTalk version 3.0 #### ! * ! * NOTICE ! * ! * Copyright (c) 1990,1992,1993 Britt Yenne. All rights reserved. ! * ! * This software is provided AS-IS. The author gives no warranty, ! * real or assumed, and takes no responsibility whatsoever for any ! * use or misuse of this software, or any damage created by its use ! * or misuse. ! * ! * This software may be freely copied and distributed provided that ! * no part of this NOTICE is deleted or edited in any manner. ! * ! */ ! ! /* ! * ################################### ! * ## CONFIGURATION (The Fun Part) ## ! * ################################### ! * ! * If your machine does not support TERMIOS (example: any NeXT running ! * NeXTStep up to and including version 3.1), then uncomment the following ! * line. ! */ ! /* TDEFS = -DUSE_SGTTY */ ! /* ! * If you are running an older Sun OS using YP (now known as NIS), you might ! * need to uncomment the next line if ytalk asks you "Who are you?" ! */ ! ! /* SLIBS = -lsun */ ! ! /* ! * If you are on a sun running solaris 2.* you might need to uncomment the ! * following line. ! */ ! ! /* SLIBS = -lnsl -lsocket */ ! ! /* ! * If your machine has a 64-bit architecture or uses 64-bit 'long's, then you ! * will need to uncomment the following line. ! */ ! ! /* BDEFS = -DY64BIT */ ! ! /* ! * If you have (or want) a system-wide .ytalkrc file, uncomment the next ! * line and set it to the correct pathname. The backslashes must remain ! * before each double-quote. ! */ ! ! /* RCDEF = -DSYSTEM_YTALKRC=\"/usr/local/etc/ytalkrc\" */ ! ! /* ! * If you plan to install ytalk on your system, you may want to modify ! * the following lines. Y_BINDIR is where the binary will be placed. ! * Y_MANDIR is where the manpage will be placed. ! */ Y_BINDIR = /usr/local/bin Y_MANDIR = /usr/local/man/man1 ! /* ! * ############################################################ ! * ## Past this point, you shouldn't need to modify anything ## ! * ############################################################ ! */ LIB = -lcurses -ltermcap $(SLIBS) $(XLIB) DEFINES = -DUSE_X11 -I/usr/local/include $(TDEFS) $(BDEFS) $(RCDEF) LDFLAGS = $(LDOPTIONS) *************** *** 72,78 **** $(CC) $(LDFLAGS) -o $(PRG) $(OBJ) $(LIB) ytalk.cat: ytalk.1 ! nroff -man ytalk.1 > ytalk.cat start: Imakefile sed 's/^DEFINES.*X11/CFLAGS =/' < Imakefile > Makefile --- 83,89 ---- $(CC) $(LDFLAGS) -o $(PRG) $(OBJ) $(LIB) ytalk.cat: ytalk.1 ! gnroff -man ytalk.1 > ytalk.cat start: Imakefile sed 's/^DEFINES.*X11/CFLAGS =/' < Imakefile > Makefile *** NetKit-A-0.06/dip337d-uri/Makefile.mhw1 Thu Aug 18 05:36:59 1994 --- NetKit-A-0.06/dip337d-uri/Makefile Thu Aug 18 18:27:17 1994 *************** *** 54,64 **** (cd /usr/sbin; ln -sf dip diplogin) install -m644 man/dip.8 /usr/man/man8/ (cd /usr/man/man8; ln -sf dip.8 diplogin.8) - if [ ! -f ~root/sample.dip ]; then \ - install -m600 samples/conf/net/dip/sample.dip \ - ~root/sample.dip; fi - if [ ! -f /etc/diphosts ]; then \ - install -m644 samples/conf/net/diphosts /etc; fi clean: rm -f core *.o *.a dip --- 54,59 ---- *** NetKit-A-0.06/net-tools-1.1.38/lib/slip.c.mhw1 Fri May 6 10:28:42 1994 --- NetKit-A-0.06/net-tools-1.1.38/lib/slip.c Thu Aug 18 17:40:36 1994 *************** *** 51,57 **** static int SLIP_set_encap(int fd, int encap) { ! if (ioctl(fd, SIOCSIFENCAP, encap) < 0) { fprintf(stderr, "SLIP_set_encap(%d): %s\n", encap, strerror(errno)); return(-errno); } --- 51,57 ---- static int SLIP_set_encap(int fd, int encap) { ! if (ioctl(fd, SIOCSIFENCAP, &encap) < 0) { fprintf(stderr, "SLIP_set_encap(%d): %s\n", encap, strerror(errno)); return(-errno); } *** NetKit-A-0.06/net-tools-1.1.38/Makefile.mhw1 Thu Aug 18 05:51:27 1994 --- NetKit-A-0.06/net-tools-1.1.38/Makefile Thu Aug 18 18:26:11 1994 *************** *** 31,40 **** all: config.h version.h $(PROGS) install: all ! install -s hostname /bin ! install -s ifconfig netstat route /sbin ! install -s arp rarp slattach plipconfig /usr/sbin/ ! install -s hostname /usr/bin/dnsdomainname install -m644 man/hostname.1 man/dnsdomainname.1 /usr/man/man1/ install -m644 man/arp.8 man/ifconfig.8 man/netstat.8 \ man/rarp.8 man/route.8 man/slattach.8 man/plipconfig.8 \ --- 31,40 ---- all: config.h version.h $(PROGS) install: all ! install -s hostname netstat /bin ! (cd /bin; ln -sf /bin/hostname dnsdomainname) ! install -s arp ifconfig route /sbin ! install -s rarp slattach plipconfig /usr/sbin/ install -m644 man/hostname.1 man/dnsdomainname.1 /usr/man/man1/ install -m644 man/arp.8 man/ifconfig.8 man/netstat.8 \ man/rarp.8 man/route.8 man/slattach.8 man/plipconfig.8 \ *** NetKit-A-0.06/net-tools-1.1.38/pathnames.h.mhw1 Sat Jan 15 23:35:38 1994 --- NetKit-A-0.06/net-tools-1.1.38/pathnames.h Thu Aug 18 18:23:38 1994 *************** *** 10,16 **** /* Pathnames of base-level NET programs. */ #define _PATH_BIN_NETSTAT "/bin/netstat" #define _PATH_BIN_HOSTNAME "/bin/hostname" ! #define _PATH_BIN_DOMAINNAME "/bin/domainname" #define _PATH_BIN_IFSETUP "/sbin/ifsetup" #define _PATH_BIN_IFCONFIG "/sbin/ifconfig" #define _PATH_BIN_ROUTE "/sbin/route" --- 10,16 ---- /* Pathnames of base-level NET programs. */ #define _PATH_BIN_NETSTAT "/bin/netstat" #define _PATH_BIN_HOSTNAME "/bin/hostname" ! #define _PATH_BIN_DOMAINNAME "/bin/dnsdomainname" #define _PATH_BIN_IFSETUP "/sbin/ifsetup" #define _PATH_BIN_IFCONFIG "/sbin/ifconfig" #define _PATH_BIN_ROUTE "/sbin/route" *************** *** 39,45 **** /* Pathnames of some customizable files. */ #define _PATH_ETC_DIPHOSTS "/etc/diphosts" ! #define _PATH_DIP_PID "/etc/dip.pid" #define _PATH_LOCKD "/var/spool/uucp" /* lock files */ --- 39,45 ---- /* Pathnames of some customizable files. */ #define _PATH_ETC_DIPHOSTS "/etc/diphosts" ! #define _PATH_DIP_PID "/var/run/dip.pid" #define _PATH_LOCKD "/var/spool/uucp" /* lock files */ PATCH_EOF make # Copy all of the documentation %doc README ChangeLog * export DOCDIR=$ROOTDIR/usr/doc/$WHERE/$NAME-$VERSION * if [ ! -e $DOCDIR/config ]; then mkdir $DOCDIR/config; fi * cp -p dip337d-uri/samples/conf/net/diphosts $DOCDIR/config * cp -p etc/inetd.conf $DOCDIR/config * cp -p etc/issue.net $DOCDIR/config * cp -p etc/printcap $DOCDIR/config * cp -p etc/protocols $DOCDIR/config * cp -p etc/rpc $DOCDIR/config * cp -p etc/services $DOCDIR/config * cp -p etc/exports $DOCDIR/config * cp -p etc/host.conf $DOCDIR/config * cp -p etc/hosts $DOCDIR/config * cp -p etc/hosts.allow $DOCDIR/config * cp -p etc/hosts.deny $DOCDIR/config * cp -p etc/hosts.equiv $DOCDIR/config * cp -p etc/hosts.lpd $DOCDIR/config * cp -p etc/networks $DOCDIR/config * cp -p etc/rc.net $DOCDIR/config * cp -p etc/resolv.conf $DOCDIR/config * cp -p etc/slip.hosts $DOCDIR/config * cp -p etc/slip.login $DOCDIR/config * cp -p dip337d-uri/README $DOCDIR/README.dip337d-uri * cp -p net-tools-1.1.38/README $DOCDIR/README.net-tools-1.1.38 * cp -p net-tools-1.1.38/README.hostname $DOCDIR/README.hostname.net-tools-1.1.38 * cp -p net-tools-1.1.38/COPYING $DOCDIR/COPYING.net-tools-1.1.38 * cp -p nfs-server-2.0/COPYING $DOCDIR/COPYING.nfs-server-2.0 * cp -p nfs-server-2.0/ChangeLog $DOCDIR/ChangeLog.nfs-server-2.0 * cp -p nfs-server-2.0/INSTALL $DOCDIR/INSTALL.nfs-server-2.0 * cp -p nfs-server-2.0/NEWS $DOCDIR/NEWS.nfs-server-2.0 * cp -p nfs-server-2.0/README $DOCDIR/README.nfs-server-2.0 * cp -p nfs-server-2.0/TODO $DOCDIR/TODO.nfs-server-2.0 * cp -p pidentd-2.2/CREDITS $DOCDIR/CREDITS.pidentd-2.2 * cp -p pidentd-2.2/INSTALL $DOCDIR/INSTALL.pidentd-2.2 * cp -p pidentd-2.2/README $DOCDIR/README.pidentd-2.2 * cp -p pidentd-2.2/TODO $DOCDIR/TODO.pidentd-2.2 * cp -p pidentd-2.2/WHATSNEW $DOCDIR/WHATSNEW.pidentd-2.2 * cp -p tcp_wrapper-6.3/BLURB $DOCDIR/BLURB.tcp_wrapper-6.3 * cp -p tcp_wrapper-6.3/CHANGES $DOCDIR/CHANGES.tcp_wrapper-6.3 * cp -p tcp_wrapper-6.3/DISCLAIMER $DOCDIR/DISCLAIMER.tcp_wrapper-6.3 * cp -p tcp_wrapper-6.3/README $DOCDIR/README.tcp_wrapper-6.3 * cp -p traceroute-4.4BSD/README $DOCDIR/README.traceroute-4.4BSD * cp -p ytalk-3.0.1/README $DOCDIR/README.ytalk-3.0.1 * make install %i echo 'To complete the networking installation you need to:' %i echo %i echo ' 1. Copy the networking configuration files from' %i echo ' /usr/doc/utils/NetKit-A-0.06/config' %i echo ' to' %i echo ' /etc' %i echo %i echo ' 2. Edit them for your network setup.' exit %% * bin/dnsdomainname * bin/hostname * bin/netstat * sbin/arp * sbin/ifconfig * sbin/route * usr/bin/ytalk * usr/sbin/dip * usr/sbin/diplogin * usr/sbin/in.identd * usr/sbin/plipconfig * usr/sbin/rarp * usr/sbin/rpc.mountd * usr/sbin/rpc.nfsd * usr/sbin/safe_finger * usr/sbin/showmount * usr/sbin/slattach * usr/sbin/tcpd * usr/sbin/traceroute * usr/sbin/try * usr/sbin/try-from * usr/include/log_tcp.h * usr/lib/libwrap.a * usr/man/man1/dnsdomainname.1 * usr/man/man1/hostname.1 * usr/man/man1/ytalk.1 * usr/man/man5/exports.5 * usr/man/man5/hosts_access.5 * usr/man/man8/arp.8 * usr/man/man8/dip.8 * usr/man/man8/diplogin.8 * usr/man/man8/ifconfig.8 * usr/man/man8/in.identd.8 * usr/man/man8/netstat.8 * usr/man/man8/plipconfig.8 * usr/man/man8/rarp.8 * usr/man/man8/route.8 * usr/man/man8/rpc.mountd.8 * usr/man/man8/rpc.nfsd.8 * usr/man/man8/showmount.8 * usr/man/man8/slattach.8 * usr/man/man8/tcpd.8 * usr/man/man8/traceroute.8 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Mark -------------------------------------------------------------------- Email: Mark_Weaver@brown.edu | Brown University PGP Key: finger mhw@cs.brown.edu | Dept of Computer Science From linux-bogus-owner@cs.unc.edu Thu Aug 18 05:21:30 1994 Return-Path: Message-Id: <199408180307.XAA09889@localhost> From: Mark_Weaver@brown.edu To: linux-bogus@cs.unc.edu Subject: xon fix Reply-to: Mark_Weaver@brown.edu Date: Wed, 17 Aug 1994 23:07:47 -0400 Sender: owner-linux-bogus@cs.unc.edu Precedence: bulk Status: RO Here's a little fix for xon: diff -c usr/X386/bin/xon.mhw1 usr/X386/bin/xon *** usr/X386/bin/xon.mhw1 Thu Jul 21 19:47:25 1994 --- usr/X386/bin/xon Wed Aug 17 23:06:41 1994 *************** *** 25,30 **** --- 25,33 ---- :*) fullname=`hostname` hostname=`echo $fullname | sed 's/\..*$//'` + if [ $fullname = $hostname ]; then + fullname=`hostname`.`domainname` + fi if [ $hostname = $target -o $fullname = $target ]; then DISPLAY=$DISPLAY rcmd="sh -c" Mark -------------------------------------------------------------------- Email: Mark_Weaver@brown.edu | Brown University PGP Key: finger mhw@cs.brown.edu | Dept of Computer Science From linux-bogus-owner@cs.unc.edu Wed Aug 17 23:51:14 1994 Return-Path: Date: Wed, 17 Aug 1994 17:35:36 -0400 From: Kevin Martin Message-Id: <199408172135.RAA20435@genome.cs.unc.edu> To: Peter Clements CC: linux-bogus@cs.unc.edu In-reply-to: Subject: Re: Converting. Sender: owner-linux-bogus@cs.unc.edu Precedence: bulk Status: RO Peter Clements writes: > > In order to install BOGUS from source, you need to have the BOGUS binaries > > installed so that you can compile and install the source code. We have > > never tried to bootstrap BOGUS from the umsdos filesystem, and our boot > > disks do not include the driver for the umsdos filesystem. > > By BOGUS binaries, do you mean you have to install the DIST directory, > or is enough supplied on the BOOT disks to allow a build of the source > files? The BOOT disks do not contain all of the binaries necessary to build the entire BOGUS system. You also do not need to have the entire DIST directory installed to build the entire system; you need a subset. We have not had time to figure out all of the dependencies and the correct build ordering to minimize the set of required binaries to re-build BOGUS, but if you have time to figure this out, it would be _very_ useful information to pass along to the rest of the list. Kevin ___ Kevin E. Martin University of North Carolina at Chapel Hill martin@cs.unc.edu Department of Computer Science From linux-bogus-owner@cs.unc.edu Wed Aug 17 23:41:28 1994 Return-Path: Message-Id: From: Peter Clements Subject: Re: Converting. To: Rik Faith Date: Wed, 17 Aug 1994 22:16:45 +0100 (BST) Cc: linux-bogus@cs.unc.edu In-Reply-To: <199408171931.PAA25872@proteus.cs.unc.edu> from "Rik Faith" at Aug 17, 94 03:31:40 pm X-Mailer: ELM [version 2.4 PL21] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 445 Sender: owner-linux-bogus@cs.unc.edu Precedence: bulk Status: RO > In order to install BOGUS from source, you need to have the BOGUS binaries > installed so that you can compile and install the source code. We have > never tried to bootstrap BOGUS from the umsdos filesystem, and our boot > disks do not include the driver for the umsdos filesystem. By BOGUS binaries, do you mean you have to install the DIST directory, or is enough supplied on the BOOT disks to allow a build of the source files? Peter C. From linux-bogus-owner@cs.unc.edu Wed Aug 17 21:46:43 1994 Return-Path: Date: Wed, 17 Aug 1994 15:31:40 -0400 From: Rik Faith Message-Id: <199408171931.PAA25872@proteus.cs.unc.edu> To: "Guy W. Hulbert" Cc: linux-bogus@cs.unc.edu Subject: Re: Converting. In-Reply-To: ["Guy W. Hulbert" ] Wed 17 Aug 1994 14:26:45 -0400 References: <199408171826.OAA00444@aries.yorku.ca> Sender: owner-linux-bogus@cs.unc.edu Precedence: bulk Status: RO On Wed 17 Aug 1994 14:26:45 -0400, "Guy W. Hulbert" wrote: > but there are a few > things from SLS that I find convenient, particularly the virtual consoles. How are SLS's virtual consoles different from the standard virtual consoles in the Linux kernel? > I would prefer to install bogus piecewise and compile everything myself. > > Would it be possible to do this using SLS to bootstrap the process? We bootstrap BOGUS with BOGUS. The binary distribution of BOGUS was built by first installing the binary distribution on a virgin system, and then using pms to rebuild (and repackage) all of the programs in the BOGUS source tree. I have never used SLS and have no idea if it is sufficient to bootstrap BOGUS. Each package can be compiled independently (using pms, the "Notes" file, and the source code). However, if you try to bootstrap the complete BOGUS system under SLS, you will probably have problems because of various incompatibilities with SLS (missing files, different versions of key software, different file system layout, etc.). > Is it possible to install bogus from source and boot disks with only MS-DOS > on the hard-drive (I find it convenient to have an ms-dos partition in order > to transfer stuff on floppies). In order to install BOGUS from source, you need to have the BOGUS binaries installed so that you can compile and install the source code. We have never tried to bootstrap BOGUS from the umsdos filesystem, and our boot disks do not include the driver for the umsdos filesystem. From linux-bogus-owner@cs.unc.edu Wed Aug 17 20:43:22 1994 Return-Path: Date: Wed, 17 Aug 1994 14:26:45 -0400 From: "Guy W. Hulbert" Message-Id: <199408171826.OAA00444@aries.yorku.ca> To: linux-bogus@cs.unc.edu Subject: Converting. Sender: owner-linux-bogus@cs.unc.edu Precedence: bulk Status: RO Hi all... I'm currently running SLS 1.03 on a 486/66 with 16M Ram and 1G SCSI disk. I've upgraded to Xfree 2.0 and version 1.0 of the kernel because my video card is not supported by Xfree 1.3. I'd like to convert to bogus so that I have a system put together completely from source code (by myself so I know what is there) but there are a few things from SLS that I find convenient, particularly the virtual consoles. The main problem I have with SLS is that there is a lot of junk I don't really want (emacs works differently under X and not) but I have installed some programs and libraries from FORTRAN source code and I'd like them to still work if I switch. I would prefer to install bogus piecewise and compile everything myself. Would it be possible to do this using SLS to bootstrap the process? Is it possible to install bogus from source and boot disks with only MS-DOS on the hard-drive (I find it convenient to have an ms-dos partition in order to transfer stuff on floppies). Thanks, Guy W. Hulbert Address: 246 Petrie, York University 4700 Keele Street North York, Ontario, M3J 1P3 (416) 736-2100 ext. 33603,33834 E-Mail: guy@aries.phys.yorku.ca From linux-bogus-owner@cs.unc.edu Wed Aug 17 18:43:20 1994 Return-Path: Message-Id: <199408171622.MAA13184@localhost> From: Mark_Weaver@brown.edu To: arlie@thepoint.com (Arlie Davis) Cc: linux-bogus@cs.unc.edu Subject: Re: More suggestions/fixes In-reply-to: Your message of "Wed, 17 Aug 1994 12:05:25 EDT." <9408171605.AA06012@thepoint.com> Reply-to: Mark_Weaver@brown.edu Date: Wed, 17 Aug 1994 12:22:48 -0400 Sender: owner-linux-bogus@cs.unc.edu Precedence: bulk Status: RO arlie@thepoint.com (Arlie Davis) writes: > > 1. /tmp, /var/tmp, and /var/spool/mail should all be mode 1777 > > /var/spool/mail should definitely not be world writeable, whether > or not it is sticky. Consider: > [...] This is a well known problem, but it is limited to denial-of-service attacks. Unix in general can't protect well against these kinds of attacks, so people usually don't sweat over it. Many systems have a "mail" group, so the /var/spool/mail directory is only group writable, although this means you have more setgid programs lying around. When you run a public system with irresponsible users, you clearly have to worry about these issues. But for the most part I'm not sure this is worth changing by default. If we want to concentrate on security issues, I'd start with getting shadow passwords working. > /tmp is a separate filesystem on my (public) systems, in order to > minimize damage from stupid users decoding alt.binaries.pictures > all day, or from malice. I don't envy you. :-) > For a private development machine, of course, it's not that big of > a deal, but robustness is always important. The only reason I don't think it should be changed is that it has a corresponding disadvantage: more setgid programs out there. Although I don't feel strongly about it one way or the other. Mark -------------------------------------------------------------------- Email: Mark_Weaver@brown.edu | Brown University PGP Key: finger mhw@cs.brown.edu | Dept of Computer Science From linux-bogus-owner@cs.unc.edu Wed Aug 17 18:23:25 1994 Return-Path: Date: Wed, 17 Aug 1994 12:05:25 -0400 From: arlie@thepoint.com (Arlie Davis) Message-Id: <9408171605.AA06012@thepoint.com> To: linux-bogus@cs.unc.edu Subject: Re: More suggestions/fixes Content-Type: text Content-Length: 1370 Sender: owner-linux-bogus@cs.unc.edu Precedence: bulk Status: RO > 1. /tmp, /var/tmp, and /var/spool/mail should all be mode 1777 /var/spool/mail should definitely not be world writeable, whether or not it is sticky. Consider: ls -l /var/spool/mail/schmuck /var/spool/mail/schmuck: No such file or directory >/var/spool/mail/schmuck chmod 660 /var/spool/mail/schmuck Depending on how the rest of the system works, the user who executes the above commands may be able to read mail delivered for user schmuck. Even if this (tiny) hole is plugged, it still leaves open a lot of other problems. And, I don't like the idea of ANY world- writeable files -- what if a user did dd if=/dev/zero of=/var/spool/mail/... in order to fill the partition that mail, and probably a lot of other crucial spools, are kept on? Any user could cripple a system. /tmp is a separate filesystem on my (public) systems, in order to minimize damage from stupid users decoding alt.binaries.pictures all day, or from malice. For a private development machine, of course, it's not that big of a deal, but robustness is always important. -- Arlie Davis | The Point: Inexpensive, high-quality public Internet -- | access. Flat rate: $20/month. 20G storage online. -- System administrator | Dial direct at (812)246-8032, or over Internet. -- E Pluribus UNIX | FTP: ftp.thepoint.com HTTP: http://www.thepoint.com From linux-bogus-owner@cs.unc.edu Wed Aug 17 15:31:38 1994 Return-Path: Message-Id: <199408171320.JAA01110@localhost> From: Mark_Weaver@brown.edu To: linux-bogus@cs.unc.edu Subject: Re: rsh fix In-reply-to: Your message of "Wed, 17 Aug 1994 09:08:10 EDT." <199408171308.JAA01034@localhost> Reply-to: Mark_Weaver@brown.edu Date: Wed, 17 Aug 1994 09:20:52 -0400 Sender: owner-linux-bogus@cs.unc.edu Precedence: bulk Status: RO Mark_Weaver@brown.edu writes: > Anyway, setting the POSIXLY_CORRECT environment variable disables > the permuting "feature". Also, starting the option string (in the > program) disables it as well. That's what I did to rsh. ^ with a "+" Mark -------------------------------------------------------------------- Email: Mark_Weaver@brown.edu | Brown University PGP Key: finger mhw@cs.brown.edu | Dept of Computer Science From linux-bogus-owner@cs.unc.edu Wed Aug 17 13:47:18 1994 Return-Path: Message-Id: <199408171136.HAA00413@localhost> From: Mark_Weaver@brown.edu To: linux-bogus@cs.unc.edu Subject: forgot one Reply-to: Mark_Weaver@brown.edu Date: Wed, 17 Aug 1994 07:36:17 -0400 Sender: owner-linux-bogus@cs.unc.edu Precedence: bulk Status: RO Also, it would be nice if yacc was a link to byacc. Mark -------------------------------------------------------------------- Email: Mark_Weaver@brown.edu | Brown University PGP Key: finger mhw@cs.brown.edu | Dept of Computer Science From linux-bogus-owner@cs.unc.edu Wed Aug 17 15:18:18 1994 Return-Path: Message-Id: <199408171308.JAA01034@localhost> From: Mark_Weaver@brown.edu To: linux-bogus@cs.unc.edu Subject: rsh fix Reply-to: Mark_Weaver@brown.edu Date: Wed, 17 Aug 1994 09:08:10 -0400 Sender: owner-linux-bogus@cs.unc.edu Precedence: bulk Status: RO Gee, that was easier than I thought. I didn't need to relink with the BSD getopt after all. The GNU getopt has two modes of operation, one where it ignores options after a non-option, and one where it permutes the arguments to move option arguments first. For some reason, even though the source says the ignoring them is the standard unix way, and is the posix way, the GNU getopt permutes by default. I guess they decided it was a cool feature. Anyway, setting the POSIXLY_CORRECT environment variable disables the permuting "feature". Also, starting the option string (in the program) disables it as well. That's what I did to rsh. diff -c NetKit-B-0.03/rsh/rsh.c.mhw1 NetKit-B-0.03/rsh/rsh.c *** NetKit-B-0.03/rsh/rsh.c.mhw1 Mon May 23 05:09:40 1994 --- NetKit-B-0.03/rsh/rsh.c Wed Aug 17 08:56:29 1994 *************** *** 117,128 **** #ifdef KERBEROS #ifdef CRYPT ! #define OPTIONS "8KLdek:l:nwx" #else ! #define OPTIONS "8KLdek:l:nw" #endif #else ! #define OPTIONS "8KLdel:nw" #endif while ((ch = getopt(argc - argoff, argv + argoff, OPTIONS)) != EOF) switch(ch) { --- 117,128 ---- #ifdef KERBEROS #ifdef CRYPT ! #define OPTIONS "+8KLdek:l:nwx" #else ! #define OPTIONS "+8KLdek:l:nw" #endif #else ! #define OPTIONS "+8KLdel:nw" #endif while ((ch = getopt(argc - argoff, argv + argoff, OPTIONS)) != EOF) switch(ch) { Mark -------------------------------------------------------------------- Email: Mark_Weaver@brown.edu | Brown University PGP Key: finger mhw@cs.brown.edu | Dept of Computer Science From linux-bogus-owner@cs.unc.edu Wed Aug 17 14:04:10 1994 Return-Path: Message-Id: <199408171130.HAA00321@localhost> From: Mark_Weaver@brown.edu To: linux-bogus@cs.unc.edu Subject: More suggestions/fixes Reply-to: Mark_Weaver@brown.edu Date: Wed, 17 Aug 1994 07:30:30 -0400 Sender: owner-linux-bogus@cs.unc.edu Precedence: bulk Status: RO Well, I decided to give BOGUS another try, just in case there was any question that I was "on the fence". :-) Here's my current list of bugs, some of which should be sent to a developer channel. I'll be joining some linux-activists groups soon. 1. /tmp, /var/tmp, and /var/spool/mail should all be mode 1777 2. /usr/spool should be a link to /var/spool, because xbiff looks in /usr/spool/mail, and also many other programs out there that claim to be conformant to fsstnd look in /usr/spool/mail. 3. /etc/rc specifically does a "chmod 777 /tmp". This should be changed to 1777. 4. /bin/ping should be setuid root. Some other net programs (like netstat) might want to be also, but I haven't investigated the possible security problems. 5. Many of the groff programs (gnroff, gtbl, geqn, gneqn, grefer, etc) should have links to programs with the "g" removed, for compatibility. 6. net.conf has a whole lot of defaults that really should be commented out (IMHO). Like "iface eth0 metallica ...", "gw ...", "route uwalt", "exec /conf/net/dns", etc. 7. The commented out sendmail line in net.conf looks for sendmail in the wrong place. No big whoop, but I'm a stickler. 8. hosts.equiv isn't quite as bad as I thought. It's not identical to hosts.lpd. The description of the file in the comments are right. Nonetheless the name is still wrong. 9. It would be nice if libl.a was a symlink to libfl.a, and lex to flex. 10. getpgid (a new system call I submitted before Linux 1.0), exists in libc.a, and works if statically linked, but it won't link dynamically. I assume this is some problem with the DLL table files or something. 11. /etc/rc talks about the single-user security hole, and tells you to create /etc/securesingle to make it prompt for a password, but creating that file doesn't do anything as far as I can tell. 12. xon doesn't work because the command it sends includes a hostname which doesn't include the domainname. I don't know why I'm reporting that here though, since I'm on the XFree86 team. :-) 13. rsh parses args incorrectly. As Rik pointed out, it probably should be linked with BSD getopts. 14. slattach man page is hopelessly incomplete. Missing all the neat options it has. 15. There's a bug in slattach that causes it to set the encapsulation incorrectly. Here's the fix: diff -c NetKit-A-0.04/net/lib/slip.c.mhw1 NetKit-A-0.04/net/lib/slip.c *** NetKit-A-0.04/net/lib/slip.c.mhw1 Fri May 6 10:28:42 1994 --- NetKit-A-0.04/net/lib/slip.c Wed Aug 17 07:06:25 1994 *************** *** 51,57 **** static int SLIP_set_encap(int fd, int encap) { ! if (ioctl(fd, SIOCSIFENCAP, encap) < 0) { fprintf(stderr, "SLIP_set_encap(%d): %s\n", encap, strerror(errno)); return(-errno); } --- 51,57 ---- static int SLIP_set_encap(int fd, int encap) { ! if (ioctl(fd, SIOCSIFENCAP, &encap) < 0) { fprintf(stderr, "SLIP_set_encap(%d): %s\n", encap, strerror(errno)); return(-errno); } Incidentally, while playing around with my own slip handling program, I was also setting it incorrectly since I assumed the above code was correct at first. After several attempts to get my program working, on one attempt the kernel reported the following when I first tried to send packets across the slip link: Aug 17 06:32:07 excelsior linux: Unable to handle kernel NULL pointer dereference at kernel address 00000000 Aug 17 06:32:07 excelsior linux: current->tss.cr3 = 0074e000, %cr3 = 0074e000 Aug 17 06:32:07 excelsior linux: *pde = 00102027 Aug 17 06:32:08 excelsior linux: *pte = 00000027 I must say that I'm quite impressed the system didn't go down, but I rebooted soon after just for good measure. :-) That's it for now. Mark -------------------------------------------------------------------- Email: Mark_Weaver@brown.edu | Brown University PGP Key: finger mhw@cs.brown.edu | Dept of Computer Science From linux-bogus-owner@cs.unc.edu Mon Aug 29 02:42:47 1994 Return-Path: Date: Sun, 28 Aug 1994 20:32:06 -0400 From: Rik Faith Message-Id: <199408290032.UAA20733@proteus.cs.unc.edu> To: linux-bogus@cs.unc.edu Subject: [damien@b63519.student.cwru.edu] Sendmail 8.6.9 + deliver 2.0p11 Notes files Sender: owner-linux-bogus@cs.unc.edu Precedence: bulk Status: RO ------- Start of forwarded message ------- From: "Damien P. Neil" Subject: Sendmail 8.6.9 + deliver 2.0p11 Notes files Date: Sun, 28 Aug 1994 16:46:05 -0400 (EDT) Here are Notes files for sendmail 8.6.9 and deliver 2.0p11. All standard disclaimers apply...if you get into trouble you're on your own, etc. etc. I advise getting the sendmail m4 configuration package from ftp.cs.berkeley.edu to generate a sendmail.cf file. If you don't want to do this, I have a sample one up for FTP from my machine. (b63519.cwru.edu) I also have completed packages generated with these Notes at the same location. - Damien #!/bin/sh # This is a shell archive (produced by shar 3.50) # To extract the files from this archive, save it to a file, remove # everything above the "!/bin/sh" line above, and type "sh file_name". # # made 08/28/1994 20:44 UTC by damien@b63519 # Source directory /home/damien/bogus/NOTES # # existing files will NOT be overwritten unless -c is specified # # This shar contains: # length mode name # ------ ---------- ------------------------------------------ # 4310 -rw-r--r-- deliver-2.0p11.bin.Notes # 3005 -rw-r--r-- sendmail.8.6.9.misc.bin.Notes # # ============= deliver-2.0p11.bin.Notes ============== if test -f 'deliver-2.0p11.bin.Notes' -a X"$1" != X"-c"; then echo 'x - skipping deliver-2.0p11.bin.Notes (File already exists)' else echo 'x - extracting deliver-2.0p11.bin.Notes (Text)' sed 's/^X//' << 'SHAR_EOF' > 'deliver-2.0p11.bin.Notes' && `Deliver' -- a mail delivery agent %n deliver %v 2.0p11 %c gcc 2.5.8 %l libc 4.5.26 %b dpn2@po.cwru.edu %d * %f1 gatekeeper.dec.com:/pub/usenet/comp.sources.unix/volume20/deliver2.0 %f2 gatekeeper.dec.com:/pub/usenet/comp.sources.unix/volume23/deliver2.0pch %t deliver-2.0p11.tar.gz Note: You will need to repackage the shar archives and patches as a tar.gz X file manually. %w usr.bin %% %setup patch -p1 -s << 'PATCH_EOF' && diff -u --recursive deliver-orig/Makefile deliver/Makefile - --- deliver-orig/Makefile Sun Aug 28 15:43:32 1994 +++ deliver/Makefile Sun Aug 28 16:02:22 1994 @@ -61,11 +61,12 @@ X COPY = cp X SHAR = shar X CC = cc - -CFLAGS = -O +CFLAGS = -O2 X LDFLAGS = -i - -LIBS = -lx +LIBS = X LINT = lint -x X BIN = /usr/bin +MAN = /usr/man X DELSHAR = deliver.sh X X # @@ -123,12 +124,9 @@ X echo "Sorry! You must be root to install deliver."; \ X exit 1; \ X fi - - $(COPY) deliver $(BIN)/deliver - - chgrp root $(BIN)/deliver - - chown root $(BIN)/deliver - - chmod 4711 $(BIN)/deliver - - $(COPY) header $(BIN)/header - - chmod 755 $(BIN)/header + install -m 4711 deliver $(BIN)/deliver + install -m 755 header $(BIN)/header + install -m 644 deliver.8 $(MAN)/man8/deliver.8 X X # X # How to compile and link the program. diff -u --recursive deliver-orig/config.h deliver/config.h - --- deliver-orig/config.h Sun Aug 28 15:43:33 1994 +++ deliver/config.h Sun Aug 28 15:50:27 1994 @@ -47,6 +47,8 @@ X * X */ X +#define USG + X /*---------------------------------------------------------------------- X * SCO Xenix System V compilers define M_SYSV, which implies USG. X */ @@ -64,7 +66,7 @@ X * are given the root password. Beware! X */ X - -#define TRUSTED_USERS "root" +#define TRUSTED_USERS "root", "toor" X X /*---------------------------------------------------------------------- X * Signal function type. @@ -128,12 +130,8 @@ X * ML_LOCKING lock with locking(LK_LOCK) (Xenix systems only) X */ X - -#ifdef M_XENIX - -#define ML_DOTMLK - -#define ML_LOCKING - -#else +#define ML_FCNTL X #define ML_DOTLOCK - -#endif X X /*---------------------------------------------------------------------- X * Maximum filename length. @@ -244,7 +242,7 @@ X #ifdef BSD X #define SAFEPATH "/bin:/usr/ucb:/usr/bin" X #else - -#define SAFEPATH "/bin:/usr/bin" +#define SAFEPATH "/bin:/usr/bin:/usr/local/bin:/sbin:/usr/sbin:/usr/local/sbin" X #endif X X /*---------------------------------------------------------------------- @@ -290,16 +288,9 @@ X * Define MBX_UNDEL to the mailbox for undelivered mail. X */ X - -#if defined(USG) && !defined(M_XENIX) - -/* #define MBX_NAME "mbox" */ - -#define MBX_DIR "/usr/mail" +#define MBX_DIR "/var/spool/mail" X #define MBX_MODE 0660 X #define MBX_GROUP "mail" - -#else - -/* #define MBX_NAME "mbox" */ - -#define MBX_DIR "/usr/spool/mail" - -#define MBX_MODE 0600 - -#endif X X #define MBX_UNDEL "Undel.mail" X @@ -320,9 +311,9 @@ X * USER_DELIVER user delivery file (in user's home directory) X */ X - -#define SYS_DELIVER "/usr/local/lib/deliver.sys" - -#define POST_DELIVER "/usr/local/lib/deliver.post" - -#define ERR_DELIVER "/usr/local/lib/deliver.err" +#define SYS_DELIVER "/usr/lib/deliver.sys" +#define POST_DELIVER "/usr/lib/deliver.post" +#define ERR_DELIVER "/usr/lib/deliver.err" X #define USER_DELIVER ".deliver" X X /*---------------------------------------------------------------------- @@ -333,9 +324,9 @@ X * Define LOGLOCK to be the temp file controlling access to log files. X */ X - -#define LOG "/usr/adm/deliver.log" - -#define ERRLOG "/usr/adm/deliver.errlog" - -#define LOGLOCK "/tmp/dl.loglock" +#define LOG "/var/adm/deliver.log" +#define ERRLOG "/var/adm/deliver.errlog" +#define LOGLOCK "/var/lock/dl.loglock" X X /*---------------------------------------------------------------------- X * Environment variables passed to child processes. Only in deliver: deliver diff -u --recursive deliver-orig/deliver.h deliver/deliver.h - --- deliver-orig/deliver.h Sun Aug 28 15:43:34 1994 +++ deliver/deliver.h Sun Aug 28 15:50:49 1994 @@ -47,6 +47,7 @@ X #include X #include X #include +#include X X #include "config.h" X #include "misc.h" PATCH_EOF make * make install exit %% * usr/bin/deliver * usr/bin/header * usr/man/man8/deliver.8 SHAR_EOF chmod 0644 deliver-2.0p11.bin.Notes || echo 'restore of deliver-2.0p11.bin.Notes failed' Wc_c="`wc -c < 'deliver-2.0p11.bin.Notes'`" test 4310 -eq "$Wc_c" || echo 'deliver-2.0p11.bin.Notes: original size 4310, current size' "$Wc_c" fi # ============= sendmail.8.6.9.misc.bin.Notes ============== if test -f 'sendmail.8.6.9.misc.bin.Notes' -a X"$1" != X"-c"; then echo 'x - skipping sendmail.8.6.9.misc.bin.Notes (File already exists)' else echo 'x - extracting sendmail.8.6.9.misc.bin.Notes (Text)' sed 's/^X//' << 'SHAR_EOF' > 'sendmail.8.6.9.misc.bin.Notes' && The sendmail mail transport agent. %n sendmail %v 8.6.9 %c gcc 2.5.8 %l libc 4.5.26 %b dpn2@po.cwru.edu %d * %f ftp.cs.berkeley.edu:/ucb/sendmail %t sendmail.8.6.9.base.tar.Z %w usr.sbin %% # Untar X if [ ! -d $BUILDDIR ]; then mkdir -p $BUILDDIR; fi cd $BUILDDIR rm -rf $NAME-$VERSION mkdir $NAME-$VERSION cd $NAME-$VERSION tar xvzf $SRCTARDIR/$TARFILE X # This makes the diff much smaller. X cp -f src/Makefile.Linux src/Makefile X # If you like your source directories to be writable, uncomment the next line: # chmod u+w -R . X # Patch X patch -p1 -s << 'PATCH_EOF' && diff -u --recursive sendmail-8.6.9-orig/src/Makefile sendmail-8.6.9/src/Makefile - --- sendmail-8.6.9-orig/src/Makefile Sat Aug 27 20:15:58 1994 +++ sendmail-8.6.9/src/Makefile Sat Aug 27 19:58:45 1994 @@ -15,7 +15,7 @@ X # X X # use O=-O (usual) or O=-g (debugging) - -O= -O +O= -O2 X X # define the database mechanisms available for map & alias lookups: X # -DNDBM -- use new DBM @@ -32,19 +32,19 @@ X # see also conf.h for additional compilation flags X X # include directories - -INCDIRS=-I/usr/local/include +INCDIRS= X X # library directories - -LIBDIRS=-L/usr/local/lib +LIBDIRS= X X # libraries required on your system - -LIBS= -lndbm +LIBS= -ldbm X X # location of sendmail binary (usually /usr/sbin or /usr/lib) X BINDIR= ${DESTDIR}/usr/sbin X X # location of sendmail.st file (usually /var/log or /usr/lib) - -STDIR= ${DESTDIR}/etc +STDIR= ${DESTDIR}/var/adm X X # location of sendmail.hf file (usually /usr/share/misc or /usr/lib) X HFDIR= ${DESTDIR}/usr/lib @@ -67,7 +67,7 @@ X X LINKS= ${DESTDIR}/usr/bin/newaliases ${DESTDIR}/usr/bin/mailq X BINOWN= root - -BINGRP= kmem +BINGRP= mail X BINMODE=6555 X X ALL= sendmail aliases.0 mailq.0 newaliases.0 sendmail.0 @@ -84,7 +84,7 @@ X echo "#include " > dirent.h X echo "#define dirent direct" >> dirent.h X - -NROFF= nroff +NROFF= gnroff X X aliases.0: aliases.5 X ${NROFF} -mandoc aliases.5 > aliases.0 diff -u --recursive sendmail-8.6.9-orig/src/conf.h sendmail-8.6.9/src/conf.h - --- sendmail-8.6.9-orig/src/conf.h Sun Apr 17 10:06:09 1994 +++ sendmail-8.6.9/src/conf.h Sat Aug 27 19:57:44 1994 @@ -76,12 +76,12 @@ X **********************************************************************/ X X # define LOG 1 /* enable logging */ - -# define UGLYUUCP 1 /* output ugly UUCP From lines */ - -# define NETUNIX 1 /* include unix domain support */ +/*# define UGLYUUCP 1 /* output ugly UUCP From lines */ +/*# define NETUNIX 1 /* include unix domain support */ X # define NETINET 1 /* include internet support */ X # define SETPROCTITLE 1 /* munge argv to display current status */ X # define MATCHGECOS 1 /* match user names from gecos field */ - -# define XDEBUG 1 /* enable extended debugging */ +/*# define XDEBUG 1 /* enable extended debugging */ X # ifdef NEWDB X # define USERDB 1 /* look in user database (requires NEWDB) */ X # endif PATCH_EOF X (cd src; make) X * (cd src; make install) X %doc FAQ X exit %% * usr/sbin/sendmail * usr/bin/newaliases * usr/bin/mailq * var/adm/sendmail.st * usr/lib/sendmail.hf SHAR_EOF chmod 0644 sendmail.8.6.9.misc.bin.Notes || echo 'restore of sendmail.8.6.9.misc.bin.Notes failed' Wc_c="`wc -c < 'sendmail.8.6.9.misc.bin.Notes'`" test 3005 -eq "$Wc_c" || echo 'sendmail.8.6.9.misc.bin.Notes: original size 3005, current size' "$Wc_c" fi exit 0 ------- End of forwarded message ------- From linux-bogus-owner@cs.unc.edu Mon Aug 29 02:41:29 1994 Return-Path: Date: Sun, 28 Aug 1994 20:30:27 -0400 From: Rik Faith Message-Id: <199408290030.UAA20725@proteus.cs.unc.edu> To: linux-bogus@cs.unc.edu Subject: [damien@b63519.student.cwru.edu] Vixie cron Notes Sender: owner-linux-bogus@cs.unc.edu Precedence: bulk Status: RO ------- Start of forwarded message ------- From: "Damien P. Neil" Subject: Vixie cron Notes Date: Sun, 28 Aug 1994 20:06:01 -0400 (EDT) Here's a notes file for Paul Vixie's cron, version 3.0pl1. Note that the permissions on /var/spool/cron are wrong and dangerous: just rmdir it and cron will create it the first time it is started. (Actually, pretty much all of /var/spool has utterly wrong permissions. /var/spool/mail, for example, should be mode 775, owner root, group mail. Oh, and /tmp and /var/tmp should be 1777, not 777. And while I'm thinking about permissions problems, /bin/netstat's permissions of 744 make no sense -- it should, of course, be 755. Anyway, without further ado, here's the cron Notes file. All standard dislaimers apply, of course. (Actually, one bit of ado: assuming anyone is actually using these, which format do you find easier to use, shar or plain text? I packaged the sendmail Notes as a shar because there were two different files in it. I'm packaging this one as a shar, because that preserves the filename, and it's easier to use than snipping bits out of a mail message. But other people's opinions on what's easy to use may, of course, vary...) - Damien #!/bin/sh # This is a shell archive (produced by shar 3.50) # To extract the files from this archive, save it to a file, remove # everything above the "!/bin/sh" line above, and type "sh file_name". # # made 08/29/1994 00:04 UTC by damien@b63519 # Source directory /home/damien # # existing files will NOT be overwritten unless -c is specified # # This shar contains: # length mode name # ------ ---------- ------------------------------------------ # 2521 -rw------- cron3.0pl1.bin.Notes # # ============= cron3.0pl1.bin.Notes ============== if test -f 'cron3.0pl1.bin.Notes' -a X"$1" != X"-c"; then echo 'x - skipping cron3.0pl1.bin.Notes (File already exists)' else echo 'x - extracting cron3.0pl1.bin.Notes (Text)' sed 's/^X//' << 'SHAR_EOF' > 'cron3.0pl1.bin.Notes' && Paul Vixie's cron daemon %n cron %v 3.0pl1 %c gcc 2.5.8 %l libc 2.5.26 %b dpn2@po.cwru.edu %d * %f tsx-11.mit.edu:/pub/linux/sources/sbin %t cron3.0pl1.tar.gz %w usr.sbin %% if [ ! -e $BUILDDIR ]; then mkdir -p $BUILDDIR; fi cd $BUILDDIR rm -rf $NAME$VERSION tar xvzf $SRCTARDIR/$TARFILE cd $NAME$VERSION X patch -p1 -s << 'PATCH_EOF' && diff -u cron3.0pl1-orig/Makefile cron3.0pl1/Makefile - --- cron3.0pl1-orig/Makefile Mon Feb 28 21:39:12 1994 +++ cron3.0pl1/Makefile Sun Aug 28 19:28:05 1994 @@ -50,22 +50,22 @@ X DESTROOT = $(DESTDIR)/usr X DESTSBIN = $(DESTROOT)/sbin X DESTBIN = $(DESTROOT)/bin - -DESTMAN = $(DESTROOT)/share/man +DESTMAN = $(DESTROOT)/man X #<> X INCLUDE = -I. X #INCLUDE = X #<> X LIBS = X #<> - -#OPTIM = -O - -OPTIM = -g +OPTIM = -O2 +#OPTIM = -g X #<> X # (ATT untested) X #COMPAT = -DATT X #(BSD is only needed if does not define it, as on ULTRIX) X #COMPAT = -DBSD X # (POSIX) - -#COMPAT = -DPOSIX +COMPAT = -DPOSIX X #<> X LINTFLAGS = -hbxa $(INCLUDE) $(COMPAT) $(DEBUGGING) X #<> @@ -78,7 +78,7 @@ X #INSTALL = installbsd X INSTALL = install X #<> - -LDFLAGS = +LDFLAGS = -s X #################################### end configurable stuff X X SHELL = /bin/sh diff -u cron3.0pl1-orig/config.h cron3.0pl1/config.h - --- cron3.0pl1-orig/config.h Mon Feb 28 21:39:15 1994 +++ cron3.0pl1/config.h Sun Aug 28 19:28:31 1994 @@ -29,7 +29,7 @@ X */ X X #ifndef DEBUGGING - -#define DEBUGGING 1 /* 1 or 0 -- do you want debugging code built in? */ +#define DEBUGGING 0 /* 1 or 0 -- do you want debugging code built in? */ X #endif X X /* diff -u cron3.0pl1-orig/pathnames.h cron3.0pl1/pathnames.h - --- cron3.0pl1-orig/pathnames.h Mon Feb 28 21:39:19 1994 +++ cron3.0pl1/pathnames.h Sun Aug 28 19:29:30 1994 @@ -28,7 +28,7 @@ X * to; SPOOL_DIR, ALLOW_FILE, DENY_FILE, and LOG_FILE X * are all relative to this directory. X */ - -#define CRONDIR "/var/cron" +#define CRONDIR "/var/spool/cron" X #endif X X /* SPOOLDIR is where the crontabs live. @@ -49,7 +49,7 @@ X */ X #define ALLOW_FILE "allow" /*-*/ X #define DENY_FILE "deny" /*-*/ - -#define LOG_FILE "log" /*-*/ +/* #define LOG_FILE "log" /*-*/ X X /* where should the daemon stick its PID? X */ PATCH_EOF make %doc README FEATURES MAIL CONVERSION THANKS * make install exit %% * usr/sbin/cron * usr/bin/crontab * usr/man/man1/crontab.1 * usr/man/man8/cron.8 * usr/man/man5/crontab.5 SHAR_EOF chmod 0600 cron3.0pl1.bin.Notes || echo 'restore of cron3.0pl1.bin.Notes failed' Wc_c="`wc -c < 'cron3.0pl1.bin.Notes'`" test 2521 -eq "$Wc_c" || echo 'cron3.0pl1.bin.Notes: original size 2521, current size' "$Wc_c" fi exit 0 ------- End of forwarded message ------- From linux-bogus-owner@cs.unc.edu Mon Aug 29 03:23:32 1994 Return-Path: Date: Sun, 28 Aug 1994 21:14:25 -0400 From: Rik Faith Message-Id: <199408290114.VAA20827@proteus.cs.unc.edu> To: linux-bogus@cs.unc.edu CC: damien@b63519.student.cwru.edu Subject: Re: [damien@b63519.student.cwru.edu] Vixie cron Notes In-Reply-To: [Rik Faith ] Sun 28 Aug 1994 20:30:27 -0400 References: <199408290030.UAA20725@proteus.cs.unc.edu> Sender: owner-linux-bogus@cs.unc.edu Precedence: bulk Status: RO [damien@b63519.student.cwru.edu] wrote: > (Actually, one bit of ado: assuming anyone is actually using these, > which format do you find easier to use, shar or plain text? I packaged > the sendmail Notes as a shar because there were two different files in it. Plaintext would be ok as long as the tabs and spaces are preserved exactly correctly in the diffs. However, I think that trailing whitespace is sometimes changed by mailers, so uuencoding may be best. (And mailers may do other undesirable stuff, like treat a . in the first column as the end of the message, etc.) From linux-bogus-owner@cs.unc.edu Tue Aug 30 00:21:41 1994 Return-Path: Message-Id: <199408292212.SAA18326@localhost> From: Mark_Weaver@brown.edu To: linux-bogus@cs.unc.edu Subject: Bug fixes Reply-to: Mark_Weaver@brown.edu Date: Mon, 29 Aug 1994 18:11:59 -0400 Sender: owner-linux-bogus@cs.unc.edu Precedence: bulk Status: RO Well, as it turns out, the networking problems I was having with Linux weren't Linux's fault. The rsh problem with Solaris was because rsh was poorly written, in fact I'm surprised it worked at all (even on BSD). The ytalk problem (when trying to talk to otalk machine) was due to a bug in ytalk what BSD didn't happen to exercise. Here are the fixes: - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - diff -u NetKit-B-0.03/rsh/rsh.c.mhw1 NetKit-B-0.03/rsh/rsh.c --- NetKit-B-0.03/rsh/rsh.c.mhw1 Mon May 23 05:09:40 1994 +++ NetKit-B-0.03/rsh/rsh.c Mon Aug 29 17:41:58 1994 @@ -124,7 +124,7 @@ #else #define OPTIONS "8KLdel:nw" #endif - while ((ch = getopt(argc - argoff, argv + argoff, OPTIONS)) != EOF) + while ((ch = getopt(argc - argoff, argv + argoff, "+" OPTIONS)) != EOF) switch(ch) { case 'K': #ifdef KERBEROS @@ -319,6 +319,7 @@ register int cc, wc; register char *bp; fd_set readfrom, rembits; + int rfd2_ok, rem_ok; char buf[BUFSIZ]; FD_ZERO(&rembits); @@ -366,11 +367,14 @@ exit(0); } + rfd2_ok = rem_ok = 1; (void)sigsetmask(omask); - do { + while (rfd2_ok || rem_ok) { FD_ZERO(&readfrom); - FD_SET(rfd2, &readfrom); - FD_SET(rem, &readfrom); + if (rfd2_ok) + FD_SET(rfd2, &readfrom); + if (rem_ok) + FD_SET(rem, &readfrom); if (select(16, &readfrom, 0, 0, 0) < 0) { if (errno != EINTR) { (void)fprintf(stderr, @@ -389,11 +393,10 @@ #endif #endif cc = read(rfd2, buf, sizeof buf); - if (cc <= 0) { - if (errno != EWOULDBLOCK) - FD_CLR(rfd2, &readfrom); - } else + if (cc > 0) (void)write(2, buf, cc); + else if (cc == 0 || errno != EWOULDBLOCK) + rfd2_ok = 0; } if (FD_ISSET(rem, &readfrom)) { errno = 0; @@ -405,13 +408,12 @@ #endif #endif cc = read(rem, buf, sizeof buf); - if (cc <= 0) { - if (errno != EWOULDBLOCK) - FD_CLR(rem, &readfrom); - } else + if (cc > 0) (void)write(1, buf, cc); + else if (cc == 0 || errno != EWOULDBLOCK) + rem_ok = 0; } - } while (FD_ISSET(rem, &readfrom) || FD_ISSET(rfd2, &readfrom)); + } } void - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - diff -u ytalk-3.0.1/socket.c.mhw1 ytalk-3.0.1/socket.c --- ytalk-3.0.1/socket.c.mhw1 Mon Sep 27 08:31:07 1993 +++ ytalk-3.0.1/socket.c Mon Aug 29 15:54:59 1994 @@ -444,9 +444,12 @@ for(d = 1; d <= daemons; d++) if(sel & (1 << talkd[d].fd)) { - out |= (1 << d); - if(recv(talkd[d].fd, errstr, talkd[d].rlen, 0) < 0) - show_error("find_daemon: recv() failed"); + if(recv(talkd[d].fd, errstr, talkd[d].rlen, 0) < 0) { + if (errno != ECONNREFUSED) + show_error("find_daemon: recv() failed"); + } + else + out |= (1 << d); } tv.tv_sec = 0L; - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Mark -------------------------------------------------------------------- Email: Mark_Weaver@brown.edu | Brown University PGP Key: finger mhw@cs.brown.edu | Dept of Computer Science From linux-bogus-owner@cs.unc.edu Fri Sep 2 16:47:08 1994 Return-Path: Date: Fri, 2 Sep 1994 10:23:08 -0400 From: Rik Faith Message-Id: <199409021423.KAA08769@proteus.cs.unc.edu> To: linux-bogus@cs.unc.edu Subject: NFS/pormapper security bug and fix (Linux) - comp.os.linux.announce #2597 Sender: owner-linux-bogus@cs.unc.edu Precedence: bulk Status: RO This bug probably impacts the BOGUS distribution, but I haven't checked. In article , ig25@fg70.rz.uni-karlsruhe.de (Thomas Koenig) writes: |> There is a security bug in Linux NFS implementations. |> |> This problem lets any user on the Internet gain access to file systems |> which can be mounted on the local host. Apparently (from discussions |> on comp.security.unix) it is being actively exploited. |> |> There are two possible fixes to this problem: |> |> - Install a fixed portmapper, which is now available from sunsite.unc.edu, |> and mirrors. For the LSM, see below. |> |> - As an emergency fix, make sure that it's impossible to mount the NFS |> exported directories locally; you'll need to edit /etc/exports for |> this. Try |> |> # mount localhost:/exported/directory /mnt |> |> and |> |> # mount yourhostname:/exported/directory /mnt |> |> to see wether you're vulnerable. For secrity purposes, it is best |> to restrict exporting NFS filesystems to exactly specified hosts |> you trust, even if it's readonly. |> |> Also note that there's a bug in all libc versions up to 4.5.26 (at |> least) which throws the portmapper into a forking loop under some |> conditions. To avoid this, you'll need to use one of the newer kernels |> with the CONFIG_I_AM_A_BROKEN_BSD_WEENIE option, or apply the (binary) |> patch to libc 4.5. 26 contained in portmap_3_rpcfix.shar.gz (to be |> found in sunsite's Incoming). |> |> Begin3 |> Title: portmap |> Version: 3 |> Entered-date: 1994-08-31 |> Description: This is a replacement portmap to fix some security holes |> in the original protocol. Don't install any of the "old" |> portmap versions. It also features access control to |> the portmapper via /etc/hosts.allow and /etc/hosts.deny. |> The *shar files contain source; apply portmap_3.patch |> and compile. You'll also need the libwrap.a from the |> tcp_wrappers package. |> To install the binaries, for which you need libc >= 4.5.26, |> copy portmap_3_bin.tar.gz to /tmp, then do (as root) |> # cd / |> # gzip -c -d /tmp/portmap_3_bin.tar.gz |> Keywords: NFS portmap security patch |> Author: Wietse Venema (wietse@wzv.win.tue.nl) |> Maintained-by: Thomas Koenig (Thomas.Koenig@ciw.uni-karlsruhe.de) |> Primary-site: sunsite.unc.edu /pub/Linux/network/daemons/ |> 24604 portmap_3_bin.tar.gz |> 30737 portmap_3.shar.Z |> 1738 portmap_3.BLURB |> 1932 portmap_3.lsm |> 103443 tcp_wrappers_6.3.shar.Z |> 1230 portmap_3.patch |> 2528 portmap_3_rpcfix.shar.gz |> Alternate-site: tsx-11.mit.edu /pub/linux/sources/sbin |> 24604 /pub/linux/binaries/sbin/portmap_3_bin.tar.gz |> 30737 portmap_3.shar.Z |> 1738 portmap_3.BLURB |> 1932 portmap_3.lsm |> 103443 tcp_wrappers_6.3.shar.Z |> 1230 pormtap_3.patch |> 2528 portmap_3_rpcfix.shar.gz |> Original-site: ftp.win.tue.nl /pub/security/ |> 1738 portmap_3.BLURB |> 30373 portmap_3.shar.Z |> 103443 tcp_wrappers_6.3.shar.Z |> Platform: Linux |> Copying-policy: BSD-Style |> End |> -- |> Thomas Koenig, Thomas.Koenig@ciw.uni-karlsruhe.de, ig25@dkauni2.bitnet. |> The joy of engineering is to find a straight line on a double |> logarithmic diagram. |> |> |> -- |> Send submissions for comp.os.linux.announce to: linux-announce@tc.cornell.edu |> Be sure to include Keywords: and a short description of your software.