From: Digestifier To: Linux-Admin@senator-bedfellow.mit.edu Reply-To: Linux-Admin@senator-bedfellow.mit.edu Date: Fri, 3 Sep 93 18:13:31 EDT Subject: Linux-Admin Digest #34 Linux-Admin Digest #34, Volume #1 Fri, 3 Sep 93 18:13:31 EDT Contents: Re: Printing to switched off printer (Michael K. Johnson) Re: SLS 1.03 networking (Dave Davey) News FAQ Lack of tcpip support. (BARRY TITMARSH) [HELP] tar and compression Long shadow passwords less secure than normal ones? (Bernd Meyer) Re: Long shadow passwords less secure than normal ones? (Tim Miller) Re: Another printing problem (Was Re: "lpd" won't run) (Jay Freeman) X using unix sockets (Was Re: Another printing problem (Was Re: "lpd" won't run)) (Bob Rusk) Re: [Q]: eliminating hostname before 'login:' with MCC (Steven Whitlatch) Re: SLS 1.03 networking (Richard Kooijman) ---------------------------------------------------------------------------- From: johnsonm@calypso.oit.unc.edu (Michael K. Johnson) Subject: Re: Printing to switched off printer Date: 02 Sep 1993 23:48:36 GMT In article <1993Sep2.115013.4254@kf8nh.wariat.org> bsa@kf8nh.wariat.org (Brandon S. Allbery) writes: In article rogerb@x.co.uk (Roger Binns) writes: >I have managed to setup lpr & lpc & lpd correctly so that I can print >(including postscript) to my deskjet printer. The only problem is that >the kernel is quite happy for me to print to /dev/lp1 even if the printer is >switched off! > >MS-Dos can detect if it is turned off, so it is possible. Any answers/ >experiences anyone? MS-DOS also won't print to some printers because it thinks they're always off or are on only until the printer actually prints something... there appear to be some standards problems in the area of flow control signaling. I saw this on several PCs including a true IBM XT. Of course, not being the author of the parallel driver, I don't know if that's actually related. Being one of the authors of the parallel driver, I can say that is likely to be exactly the problem. The driver does the error detection it does because it made it least likely to completely fail on the largest number of cards. I spent a lot of time tracking down little inconsistancies from one card to another. Unfortunately, parallel port designers have tended towards the most minimally standard and minimally functional design they can get away with. YUCK! If you don't like the way it works, you will have to edit lp.c and re-work the error checking so that you can tell if you are off. The names of the bits are in lp.h, and the rest will have to be done by trial and error, and then you can make a diff that you can apply to each set of kernel source you get. Since it will screw some people over, please don't ask to have it in the standard distribution... :-/ Best of luck! michaelkjohnson ------------------------------ From: daved@cortex.physiol.su.oz.au (Dave Davey) Subject: Re: SLS 1.03 networking Date: Fri, 3 Sep 1993 02:19:59 GMT In wayne@rose.cs.odu.edu (C Wayne Huling) writes: > I have upgraded from SLS 1.01 to SLS 1.03 because it seemed to make >a lot of changes that I was making manually. Anyhow, the net-2 >software doesn't seem to communicate with the rest of the network at >any level? Does anyone have any suggestions as to why the network is >unreachable from the newly upgraded machine, but the other machines on >the network that are still SLS 1.01 can ping the upgraded machine? No >other network communication works (telnet, ftp, rsh, rlogin). I found that in the SLS 1.03 distribution /etc/rhosts, the code: if [ "$IPADDR" != "" ]; then if [ "" != "$ROUTER" ]; then ROUTERPARM="gw $ROUTER"; fi set up ROUTERPARM if the router line was uncommented in /etc/hosts, but ROUTERPARM was never used. Adding: route add default $ROUTERPARM after route add $NET $IPDEV seemed to fix the problem. ------------------------------ Date: Fri, 3 Sep 1993 07:28:15 CET From: BARRY TITMARSH Subject: News FAQ Lack of tcpip support. This is some feed back to Vince Skahan's News Howto / FAQ for me it lacks some usefull notes hints on howto configure NNTP/News over TCPIP connections. Most of the books that are avaiable are also very bad In that there is only info on how to setup news feeds via UUCP Since a lot of us are Internet connected, it makes no sence for me to contact my local UUCP partner for config help. I dont have one, Contacts via the news groups so far has been a wast of time. again mostly one only gets silly RTFM replies. Not a lot of help. So. Many thanks for the FAQ on mail... I have read RTFM on NNTP all the availiable man pages Your news faq the Creaig Hunt Book I still cant figure out how to configure Cnews with NNTP-1.5.11 Im useing SLS - 103 base + TIN I can post with TIN i can read with TIN I can connect with TCPIP socket 119 and do IHAVE I can also do POST all works.. But if i do NEWNEWS date-time distr I get an error bad distr. If i do the same but with out distr eg. NEWNEWS ampr 920101 010000 GMT I get Instant session closed. ?? WHY ??? RTFM is fine but its not in the FM. nntpd does a core dump.? Also if another system calls askes for newnews it sometimes sends the newnews follows etc . dot cos i have no new news. the other system tries to send i have and this results in QUIT. WHY ?? not in C.Hunt book or FAQ's Sometimes Ihave is met with 350 OK. and then never askes for the ARTICLE. just goes direct to 250 Thanks. also i cant figure out how to get the nntp server to post news down stream OK this is in the FM but all biased to UUCP and not a thing on tcpip soc 119 connects. I do use the sample.crontab I have lots more FQ's that are not in the FM (RTFM) or any FAQ. Can you help or tell me who might.? the news nntp groups have not given help at all except RTFM's Im sick of haveing stupid replys saying RTFM etc. I HAVE. MFBM Ok thats my feed back on your FAQ for news/mail So any offers of help ?? Im sure there must be some systems on Internet tcpip i cant believe that You Lot on this group are ALL UUCP nodes. Na.. maybe ...? Barry. ------------------------------ Crossposted-To: comp.os.linux From: karel@icce.rug.nl () Subject: [HELP] tar and compression Date: Fri, 3 Sep 1993 07:18:41 GMT Hi Wizzes: I know that my question is not relevant to Linux, but please help me out if you can. I failed to find a suitable (unmoderated) newsgroup for GNU utilities or for GNU Tar. The question is this. I'm using GNU Tar 1.11.2, and I don't seem to be able to get the compression working when making tape backups to a remote unit (i.e., across the net, indirectly using rsh which is started by tar). The typical error messages are, "can't close device (128,-1)" or "IO error". Another distressing one is "tar (child): archive at EOF not at block boundary". Any suggestions? The strange thing is, that backups without compression seem to work ok.. but whenever attempting compression with either -z (gzip) or -Z (compress), the child program tar, which reads the data back from the compression program, seems to go haywire (or for that matter, possibly the compression program goes haywire). Any suggestions are welcome - Karel. -- The ICCE usenet account providing access to usenet news for the ICCE Experience _WERKEN_AAN_DE_GRENZEN_VAN_HET_KUNNEN_ ------------------------------ From: root@umibox.hanse.de (Bernd Meyer) Subject: Long shadow passwords less secure than normal ones? Date: Thu, 2 Sep 1993 20:42:55 GMT Hi, I recently looked through the source of the shadow-packet and discovered that, given a password longer than 8 characters, the routine pw_encrypt simply splits it into two parts, one being the first 8 characters, the other being the rest. These get encrypted separatly, and the result is stored separatly. This looks like an invitation for a security hole to me - most people (me included) tend to think "A long password is a good password". And, as we all know, a password should containn some punctuation and some non-letters. Now lets say I take "RecEiver:9@" as my password. This will be an easy one for Crack. One part that is encrypted is just some variation of "receiver", the other one is only three characters long. So the long passwords in the current shadow implementation look more like two passwords to Crack, one of which can probably broken by brute force (even the second part of a 13 character password could be found within a couple of hours), the other one probably less obscured by digits/punctuation than a standard one. My advice for system administrators thus seems to be: "Either force your users to use REALLY long words and make sure that they know the way the passwords are encrypted, or recompile the shadow stuff without the option for long passwords enabled." Bernie -- We both know that the earth is round | Bernd Meyer, EE-student So we can't see the way before us to its end | "Nobody is a failure who has We walk on this way, hand in hand, | friends" (from: isn't it a And I hope you are still with me behind the horizon| wonderful life?" ------------------------------ From: tem1@Isis.MsState.Edu (Tim Miller) Subject: Re: Long shadow passwords less secure than normal ones? Date: 3 Sep 93 13:06:42 GMT root@umibox.hanse.de (Bernd Meyer) writes: >Hi, >I recently looked through the source of the shadow-packet and discovered >that, given a password longer than 8 characters, the routine pw_encrypt >simply splits it into two parts, one being the first 8 characters, the other >being the rest. These get encrypted separatly, and the result is stored >separatly. >This looks like an invitation for a security hole to me - most people (me >included) tend to think "A long password is a good password". And, as we all >know, a password should containn some punctuation and some non-letters. Now >lets say I take "RecEiver:9@" as my password. This will be an easy one for >Crack. One part that is encrypted is just some variation of "receiver", the >other one is only three characters long. >[Rest deleted] If I remeber the purpose of shadow passwords correctly, the shadow password file is root read only (the regular passwd file is still there, but passwords are in separate file). No one else could read it. So, unless someone makes the blatant goof of making it world readable, there should be no problem. No one could get the file to crack it. Tim Miller ============================================================================== Tim Miller | "The only thing we have to fear, is fear | tem1@Ra.MsState.Edu | itself" | | "Within each of us lies the power of our | Mississippi State University | consent to health and to sickness, to riches | Major: Chemistry/Physics | and to poverty, to freedom and to slavery. | Minor: Computer Science | It is we who control these, and not another" | | ---Illusions, by Richard Bach | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ------------------------------ From: freeman@eagle.sangamon.edu (Jay Freeman) Subject: Re: Another printing problem (Was Re: "lpd" won't run) Date: 3 Sep 1993 14:03:05 GMT J.H.M. Dassen (dassen@sthp.wi.leidenuniv.nl) wrote: > > lpc stat gives: > lp: > queuing is enabled > printing is enabled > no entries > no daemon present This is normal if there is no job currently being printed, at least in my experience with Sparcstations and an HP9000. Jay -- ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ + Jay Freeman, WT9S Packet: wt9s@w9yci.il.usa.noam + + internet: freeman@eagle.sangamon.edu + ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ ------------------------------ From: rrusk@ssd.csd.harris.com (Bob Rusk) Subject: X using unix sockets (Was Re: Another printing problem (Was Re: "lpd" won't run)) Date: 03 Sep 1993 14:56:05 GMT Reply-To: rrusk@ssd.csd.harris.com In article <1993Sep2.213123.26202@mnemosyne.cs.du.edu> zevans@nyx.cs.du.edu (Zack Evans) writes: >In article , >Erik Stenvall wrote: >>to get my lpd working. When I recompiled the kernel without TCP I >>found that lpd now worked quite OK. The sad thing is that a kernel >>without TCP is not OK since X wont run. I'm no socket-guru so I >>haven't looked deeper into it though. >X runs fine using unix sockets instead of TCP - you do not need networking >support to run X. It might be worth mentioning here that at least some versions of Xfree require the -pn option in order to start up without TCP present. I've been told that -pn is the default with Xfee86 1.3, but I haven't verified it. You use it like: xinit -- -pn (or startx -- -pn) -- Bob Rusk rrusk@ssd.csd.harris.com My thoughts, probably not Harris'. ------------------------------ From: swhitlat@nmt.edu (Steven Whitlatch) Subject: Re: [Q]: eliminating hostname before 'login:' with MCC Date: 3 Sep 93 15:27:18 GMT In article mackinla@cs.curtin.edu.au (Pat Mackinlay) writes: >roland@cac.washington.edu (Liem Bahneman) writes: > >>How do I eliminate the 'hostname login:' and restore to just 'login:' on >>incoming telnet connections? MCC's getty doesn't have an /etc/gettydefs or >>/etc/gettytab file, so I'm wondering where do I change this and how? > >After a brief look at the source to the MCC distribution's getty (agetty), >I can say that you can't get rid of the hostname without recompiling the >source. Fair enough? > >-- >Pat -- "There's only one thing left to do Mama, I got to ding a ding dang > my dang a long ling long" (Jesus Built My Hotrod -- Ministry) >GCS d* -p+ c++ l++ m--- s+/- !g w- t- r OK, well, how does one change the default prompt for the MCC distribution, .99pl10? It looks like this 23:26:09>. It's the time and I'd like mine to show what directory I'm in, like this: host>etc>docs>. And then when I move up one directory level, I want it to show host>etc>. This is more useful than always being told what time it is, to the second. Thanks in advance Steve Whitlatch swhitlat@prism.nmt.edu ------------------------------ From: richard@dutepp13.et.tudelft.nl (Richard Kooijman) Subject: Re: SLS 1.03 networking Date: Fri, 03 Sep 1993 17:35:15 GMT wayne@rose.cs.odu.edu (C Wayne Huling) writes: > I have upgraded from SLS 1.01 to SLS 1.03 because it seemed to make >a lot of changes that I was making manually. Anyhow, the net-2 >software doesn't seem to communicate with the rest of the network at >any level? Does anyone have any suggestions as to why the network is >unreachable from the newly upgraded machine, but the other machines on >the network that are still SLS 1.01 can ping the upgraded machine? No >other network communication works (telnet, ftp, rsh, rlogin). Same problems over here. But we solved them. There is a weird problem with ifconfig. You must provide a broadcast address with 0's. ifconfig automatically define 255's. So change the ifconfig line in rc.net to: ifconfig eth0 130.161.145.230 up netmask 255.255.0.0 broadcast 130.161.0.0 So explicitly state those 0's in broadcast. After this the regular route commands should follow: route add 130.161.0.0 130.161.145.230 route add default gw 130.161.180.25 metric 1 Insert your own network numbers of course. Hope this helps. Richard. ------------------------------ ** 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 ******************************