From: Digestifier To: Linux-Admin@senator-bedfellow.mit.edu Reply-To: Linux-Admin@senator-bedfellow.mit.edu Date: Sat, 11 Sep 93 10:13:13 EDT Subject: Linux-Admin Digest #51 Linux-Admin Digest #51, Volume #1 Sat, 11 Sep 93 10:13:13 EDT Contents: Re: SHADOW 3.2.2 PASSWD DANGER!!! (Eric Kasten) NFS performance (Mike Schwartz) Re: SLS 1.03 and tcp/ip (Andrew Ukrainec) Re: [Summary] /etc/shutdown by non-root (Mike Schwartz) CRC ERROR!! when booting from floopy (Sukumar Patel) Problems connecting a terminal (Daniel Garcia) Colorado tapesSummary: (J.J. Paijmans) Re: Enough SLS bashing (Re: Install on a ARC Pentium) (Olaf Titz) ---------------------------------------------------------------------------- From: tigger@tigger.cl.msu.edu (Eric Kasten) Subject: Re: SHADOW 3.2.2 PASSWD DANGER!!! Date: 10 Sep 1993 23:41:00 GMT Reply-To: tigger@tigger.cl.msu.edu (Eric Kasten) OUTTA HERE! (aehall@calvin.seattleu.edu) wrote: : I just found something very dangerous with the passwd command that : I compiled from the shadow 3.2.2 package. : Observe: : #root:[51]/> passwd root : Changing password for root : Enter the new password (minimum of 5 characters) : Please use a combination of upper and lower case letters and numbers. : New Password: : Re-enter new password: : Sep 10 15:35:41 calmar passwd[361]: changed password for `root' : #root:[52]/> exec login : login: root : Password: : and now I'm logged in correctly... i.e.: NO PASSWORD!! : Surely this is a bug, not a feature. I suspect that the only user you will find that can do this is root. Root can override the passwd restrictions, and enter just about anything. Actually I find this rather usefull on my system at home to which noone external to my immediate family really has any access (ie, all users are trusted), under those circumstance I often set my passwds to nothing. -- Eric Kasten Michigan State University tigger@tigger.cl.msu.edu My opinions, with out a doubt, are all mine. ------------------------------ From: mykes@shell.portal.com (Mike Schwartz) Subject: NFS performance Date: Sat, 11 Sep 1993 02:30:51 GMT I'm a fairly experienced linux user. I go back to the days of the pl4 kernel... Anyhow, I have been struggling with NFS performance since those days. My original installation was SLS, but I figured out how many problems it had pretty quick and did a new installation. I started with the HLU boot/root disk and partitioned my hard drive. I then copied stuff from the HLU disk to the hard drive (sbin, bin, etc.). I then copied term binaries to the drive and used it to download much of prep.ai.mit.edu, as well as the gcc/linux stuff and the kernel. So, basically, I built my entire system by hand from scratch. I offer this info in case it helps someone with the answer to my question, and to show that I as a unix weenie (2 weeks total unix/sls experience n my life) could do this kind of install :-) I have a Sun3 running sunOS 4.1.1, an Amiga 3000 running Amiga NetBSD, and my 486 running Linux all on the same network. The only three machines on the network (for purposes of this post, anyhow). The 486 has an SMC Elite (wd8013) card in it. Now, to be specific to my problem... I had been running the old net software until I changed to the pl10 kernel. Using the old net software, my nfs performance was terrible, and I was never able to mount my linux drives from the other machines on the net. After installing the net-2 bins, my performance was still terrible, and I still couldn't mount the linux drives. I'll detail the performance issue in a bit. Something that had bugged me since I installed the net-2 stuff was _how_ I installed it... I had unpacked the .tgz files into /tmp and moved stuff by hand into /etc and /usr/etc and didn't make a /conf tree. And it took me a long time to get the net-2 stuff working that way - but I did :-) But the performance problem and the inability to mount had me thinking I had mixed old and new binaries (daemons) or something... SO I decided to do a reinstall of net-2 and followed the install FAQ to the letter. I backed up my /lib and my /etc and my /usr/etc to a different partition. THen I made a /etc/save and a /usr/etc/save subdir and moved all the networking and config files to those subdirs. This ensured that I was installing and running the new bins and config files. Surprisingly enough, I got the network stuff up and running in an hour! And I had made myself a pot of coffee and had decided I wouldn't sleep until I got it working :-) Now, to get to some of the problems I had with the install. I use the sysvinit from bootsys* package. And this caused me no end of grief! I spent about 4 hours debugging through the rc scripts to figure out why I couldn't remote mount linux partitions from the other machines. Software developers (of the net-2 stuff) take note: the sysv init does a kill -HUP to the daemons. I added 'ps -aux' to the rc.inet2 script at the end and it showed them all running (daemons: portmap in particular). But after init switched to multiuser, those daemons were gone. As I said, it took me 4 hours to figure out _why_ the daemons went away... I finally ran the daemon (portmap) by hand and then sent it a HUP by hand, and it disappeared! So I had to modify the rc.inet2 script to do: # Start the SUN RPC Portmapper. if [ -f ${NET}/rpc.portmap ] then echo -n "portmap " /bin/nohup ${NET}/rpc.portmap >/dev/null &1 fi And sure enough, I was now able to nfs mount my linux partitions from all the other machines! Now, let's get to the performance issue. Again, I have three machines involved in this test. Amiga runnint netbsd, sun, and linux. So, here's a df output of all three machines: sun% df Filesystem kbytes used avail capacity Mounted on dell:/ 10276 8481 1282 87% /dell sun% {amiga0:7}df Filesystem 512-blks used avail capacity Mounted on sun:/u2 1290704 840126 321506 72% /u2 {amiga0:8} {dell.sf-bay.org:27}df Filesystem 1024-blocks Used Available Capacity Mounted on sun:/u2 645352 420063 160753 72% /u2 {dell.sf-bay.org:28} Here's sample timed NFS activity to demostrate the performance issue: {dell.sf-bay.org:49}time cp vmunix /u2 0.00u 5.37s 1:08.68 7.8% {dell.sf-bay.org:50} That was copy from linux to sun over nfs, using linux shell. 1 minute 8 seconds! (bad bad bad) {dell.sf-bay.org:50}time cp /u2/vmunix . 0.02u 4.36s 0:12.51 35.0% {dell.sf-bay.org:51} copy the other way in 12 seconds! sun# ls -l vmunix -rwxr-xr-x 1 root 1240050 May 19 19:47 vmunix sun# time cp vmunix /dell/tmp 0.0u 1.4s 0:07 20% 0+112k 2+152io 26pf+0w sun# time cp /dell/tmp/vmunix . 0.0u 0.8s 0:02 42% 0+104k 5+33io 13pf+0w sun# Copy from sun to linux in 7 seconds, copy from linux to sun in 2! This is from the sun's comamnd shell. {amiga0:14}time cp vmunix /u2 0.0u 1.3s 0:13.25 10.0% 0+0k 0+0io 0pf+0w {amiga0:15}time cp /u2/vmunix . 0.0u 1.4s 0:03.39 41.8% 0+0k 0+0io 0pf+0w {amiga0:18} Copy from amiga to sun in 13 seconds, from sun to amiga in 3 seconds. So, linux copies to the sun in 1:08, vs amiga to sun in 13. That's what I call a performance problem! And it is clear from my presentation here that linux<->sun is not limited by hardware. Is anyone having the same performance problem? Is there a solution? Cheers. ------------------------------ Crossposted-To: comp.os.linux.help From: ukrainec@nimios.eng.mcmaster.ca (Andrew Ukrainec) Subject: Re: SLS 1.03 and tcp/ip Date: Sat, 11 Sep 1993 03:11:00 GMT In article <1993Sep9.161811.16134@super.org> becker@super.org (Donald J. Becker) writes: >Andrew Ukrainec wrote: >>Also, the autodetection does not work for my WD card, and I had to >>hard coded into the appropriate kernel file. All in all, I would say >>that the networking on SLS 1.03, as it is distributed, is pretty messed up. > >What was the problem with the WD autodetection? And why did you need >to hard-code your value and make a new kernel? There are directions >on the SLS LILO boot screen on how to explicitly specifying every >parameter for the WD ethercards. From the CONFIG file in /linux/net/inet: # Note: for most WD (SMC) cards, the AutoProbe doesn't work. You have # to force those cards into operation, by specifying the I/O add- # ress (EI8390=xxx), the IRQ (EI8390_IRQ=xxx) and the address of # the shared memory (WD_SHMEM=xxxx). All other supported cards # behave like they should, you can leave the values to 0. -FvK I've installed the SLS 1.02 distribution, and except for the shortcomings of the networking at that time, it autodetected the card, and worked fine. As far as the LILO boot screen goes, that is only for installation. Once you boot off of hardisk, you will need to modify the kernel before most WD cards will work. The problem is that it gives you the impression that it has autodetected the card, and that everything is going to work fine. If there was just a simple statement that you must configure the card manually, I wouldn't complain. >The real SLS usually has the latest ethercard code. I don't >consider it to be "pretty messed up", and I don't know where you would >find a better version. (This statement doesn't apply to the >fly-by-night disk copiers that sell potentially old or buggy copies of >"SLS"). The code itself is great! Its the bundling of the distribution and documentation that is the problem. For example, if you look at the questions being asked on the net about networking, it usually because folks don't realize that /etc/networks is symbolically linked to /conf/net/networks, which doesn't exist. Several other configuration files are also symbolically linked to this non-existent directory. When I manually upgraded the SLS 1.02 to the NET2 code, I had no problems, even though it was a little tricky to configure. But what were the SLS guys thinking when they bundled the distribution with key networking files missing? I think that Linux and the SLS distribution is the best thing since sliced bread, but I'd hope that someone would at least do a cursory check of the operation of the distribution before it gets released. -- Andrew Ukrainec ukrainec@nimios.eng.mcmaster.ca < (*) > / \ < (*) > Communications Research Laboratory McMaster Univ, Hamilton, Ontario ------------------------------ Crossposted-To: comp.unix.admin From: mykes@shell.portal.com (Mike Schwartz) Subject: Re: [Summary] /etc/shutdown by non-root Date: Sat, 11 Sep 1993 01:22:24 GMT C M Brough (cmb@epcc.ed.ac.uk) wrote: : A while back I wrote the following: : > I have a standalone Unix workstation (Linux, as it happens) at home. : > This is used by me, and by my generally computer-illiterate flatmate. : > While I can cope with becoming root and invoking /etc/shutdown to : > bring the system down properly, I don't want to give my flatmate the : > root password! (Nor the hassle of a complicated procedure, which he'll : > screw up...) : > : > Is there anyway of setting things up so that a non-root user can bring : > the system down cleanly? Run /etc/shutdown setuid? Have a setuid : > "wrapper" program that calls /etc/shutdown only with the halt option? : > Other solutions? What are the issues and dangers? : > : > Responses by e-mail preferred, though I'll try and follow any : > discussion that takes place here. If there is sufficient interest I'll : > summarise and post. : Thanks to all who responded - sorry its taken me so long to get round : to posting this summary. I got a lot of responses, most of which : mentioned one of 4 different approaches. : The most popular was the creation of a 'shutdown' user, whose shell is : /etc/shutdown. This is what I have used on my machine, and it is : working smoothly. To get it working, add an entry to /etc/passwd : something like this: : : shutdown::0:0:shutdown system from login prompt:/:/etc/shutdown : (I think I actually made the 'shell' a wrapper script or program that : runs shutdown with the -h (halt) option, rather than causing a : reboot... But I'm at work just now and can't check.) Well, I think you may want to put a password on this account :-) Or perhaps a "sync" user that runs /etc/sync would be better (perhaps, perhaps). Then you could login as sync a few times and then power off or reset your machine. Without a password on the shutdown account, wouldn't any arbitrary person be able to dial into your linux box (assuming you have a modem) or telnet to it over term or ethernet and shutdown the machine while you're working? :-) ------------------------------ From: syvsp@tjuvm.tju.edu (Sukumar Patel) Subject: CRC ERROR!! when booting from floopy Date: 10 Sep 93 13:37:06 GMT Hi, I just installed SLACKWARE 1.0.3 on a Comtrade EISA/VLB 486/66 with 2 ide drives, Mitsumi CD-ROM drive and Sound blaster 16 card. I did a full install of everything and the boot floppy was created. But when I boot from this floppy I get: Loading..................................... Uncompressing Linux CRC Error System Halted I have rebooted from the distribution "bootdisk" and successfully mounted the partitions created on the ide drives during the installation process. Everything on the ide drive partitions seems ok. I also tried to run lilo to enable booting from the hard disk instead of the floppy but I get: can't open device: /tmp/dev.0 There is a block device created dev.0. What, if anything, can I do to fix this problem. Thanks very much for any assistance. Sukumar Patel -- ------------------------------ From: kender@esu.edu (Daniel Garcia) Subject: Problems connecting a terminal Date: 10 Sep 93 02:36:44 GMT Reply-To: kender@esu.edu I have an old burroughs terminal (that has a psuedo-vt100 compatability mode it looks like) that I'd like to use on my roommate's linux box. It's a 486/33 running .99pl9. I know the terminal will work with his setup, because we had it running last year (He took the computer, i took the terminal for the summer). However, we cannot get the terminal to run now. I have hooked up the terminal to an external modem, and confirmed that it still works. Some notes: 1) Yes, we DO have a null modem, this is our setup: terminal-nullmodem-cable-computer 2) We are using 3 (out of 4) comports, here are the setups: comport1 (ttys0), irq 4 - mouse comport2 (ttys1), irq 5 - internal 14.4 modem comport4 (ttys3), irq 3 - terminal 3) The computer is recieving FROM the termial, i.e. we can connect kermit to ttys3, and read what is typed on the terminal, but we cannot send stuff to the terminal. 4) We had this problem last year, but can't remember what we did to get around it. Please help - we need this terminal setup, it makes life a helluva lot easier for us. D -- Daniel Garcia------------ooOO Kender@esu.edu OOoo--------------Comp Sci Student Coram Deo These views belong to Daniel Garcia, any flames belong to /dev/null GCS/MU d--() -p+ c++(c+) l++ u+ e+(*) m++(*) s !n h f+ !g w+ t++(--) r+ !y ------------------------------ Crossposted-To: comp.os.linux.misc,comp.os.linux.help From: paai@kub.nl (J.J. Paijmans) Subject: Colorado tapesSummary: Date: Sat, 11 Sep 93 09:53:09 GMT Hi. I have seen fleeting allusions to the use of Colorado tape drives on this thread, but I don't seem to be able to find my answers among them. The question is: "is it possible to use my colorado-clone, using DC2120 tapes in QIC-80 format and connected to the floppy-controler, under Linux? (and how to go about it)" Don't flame immediatly: I already tried to find the answers in FAQs etc... Paai. ------------------------------ From: uknf@rzstud1.rz.uni-karlsruhe.de (Olaf Titz) Subject: Re: Enough SLS bashing (Re: Install on a ARC Pentium) Date: 11 Sep 1993 13:27:11 GMT I've just yesterday re-installed my system from SLS 1.03 and have a few comments to add, unfortunately they fall all under "cons" too. I think SLS is a nice thing, it is a big benefit especailly for those not on the Internet, but some rather minor fixes simply would be needed. In article <1993Sep10.163412.15661@anl433.uucp>, Iain Lea wrote: > o Install is broken > We just use the good old doinstall /dev/... doinstall and sysinstall are broken too. For the latter, you can live with it, i.e. you just have to *know* that the options listed as help page have to be given from bottom up, and the correct spelling for "-special" is "-series" (this stupid typo bug is there since the first version ever, has really nobody noticed?) sysinstall lacks the ability to skip one disk. More important, sysinstall (a) does not add the necessary /install subdirs if not present, and (b) it does not always handle symlinks right, you get many warnings and have to check them manually. > o Software packages in varying states of disarray Especially the recent kernel/loadkeys disasters - two or three (?) versions which had non-matching loadkeys packages and caused system crashes. (Linus, if you're listening, I think the loadkeys stuff should be integrated into the kernel source tree, this could avoid such confusion.) > Various packages have no manpage, incorrect permissions, old version > and various filesystem paths within the package are wrong. The incorrect permissions are a major headache. After re-installing from scratch, I ended up with ALL directories on my new disk WORLD-WRITABLE! The "sysperms" script did not correct these, at least not all of them. Moreover, SLS still knows no "uucp" and "news" users (at least not the latter), which breaks the larger part of the mail/news system. I think it the time has come to standardize UIDs once and for all... While we're at the manpages issue... I have no idea where the SLS version of "man" originated, I just see that it doesn't work right. I have successfully switched to "adam" (which I recently grabbed from one of the sources groups) - it's flexible, functional, and (almost) complete. Delivering pre-formatted manpages only complicates things, IMHO. We should better stick with sources. There is a [ntg]roff replacement especially for manpages, just I forgot the name... When I last checked (I don't know if this got fixed meanwhile), the docs for elm were preformatted with the wrong macro package and therefore unusable (critical words missing). This seems to be a common error with elm as I have seen it on other systems too. Another reason for delivering [nt]roff stuff in source - it is not much bigger and has the additional advantage that you can conveniently print it out on *your* paper format... > o Maintainer lacks feedback and responsiveness > SLS maintainer has invalid mail address This is something I understand - he doesn't want his mailbox to be stuffed like c.o.l.help :-) What really would be needed is a proper version numbering. Now we have at least (?) three different 1.03s... > I now take sls to be a very rough base system (ie. a grunt in army speak). > I maintain my own bug list and have a ChangeLog that I constantly update > as I polish my heavily modified system to meet mine & my users needs. This seems to be necessary. :-( Now, I also have heavily criticized SLS, but please look at this as suggestions for improvement, no flame. Repeat: I think the SLS release is a nice thing which nevertheless needs some fixes. Olaf -- olaf titz o olaf@bigred.ka.sub.org praetorius@irc comp.sc.student _>\ _ s_titz@ira.uka.de LINUX - the choice karlsruhe germany (_)<(_) uknf@dkauni2.bitnet of a GNU generation what good is a photograph of you? everytime i look at it it makes me feel blue ------------------------------ ** FOR YOUR REFERENCE ** The service address, to which questions about the list itself and requests to be added to or deleted from it should be directed, is: Internet: Linux-Admin-Request@NEWS-DIGESTS.MIT.EDU You can send mail to the entire list (and comp.os.linux.admin) via: Internet: Linux-Admin@NEWS-DIGESTS.MIT.EDU Linux may be obtained via one of these FTP sites: nic.funet.fi pub/OS/Linux tsx-11.mit.edu pub/linux sunsite.unc.edu pub/Linux End of Linux-Admin Digest ******************************