Re: /var/log/messages not world-readable anymore?
On Wed, 9 Jul 1997, Joey Hess wrote: Will Lowe: Well, here's an example of where it could be: I use diald to dial up an ISP account. Diald calls chat to execute a login-and-start-ppp script. Chat writes all of it's send/waitfor pairs to /var/log/messages. So anyone who can read /var/log/messages can also find my login and password for my ISP (in my case, my university). Not a problem here, becuase I use \q in the right places in my chat script to make the password not be shown. Any more examples of why this could be a security hole? I'm not sure why it is or isn't a security hole, but I think it might be a change in the new(er) version of sysklogd. I upgraded that package yesterday, and manually rotated my logs today, and voila! I could no longer tail -f my logs. Bummer. Pete Templin [EMAIL PROTECTED] -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: How to find out if sendmail has queued mail to forward.
The command mailq should be on your system. It essentially runs sendmail -bp which prints the queue. You may wish to use mailq | head or mailq | less depending on the size of the current queue. Hint: read up on sendmail timeouts and how to move mail to a separate queue. I had to test my strategies this weekend when master.debian.org was unreachable and I had 1400 mail messages stored on my machine (I'm the first MX for debian.org after master.debian.org). Pete Templin [EMAIL PROTECTED] On 30 Jun 1997, Chris Brown wrote: I am trying to test some portions of an email system and want to determine weather one of my mail servers is picking up mail to forward. The recieving host is currently off and there is a MX route to my server so mail should be queued there right now. All I need to do is check the queue. What is the appropriat means of doing this for mail to be forwarded? -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Why is pine so slow?
Ah, the wonders of sendmail. In the out-of-the-box configuration of sendmail, it passes mail along in background mode. One might think that this means it does everything in the background. Not so, for a few small details. Sendmail in background mode checks the validity of the destination address through a DNS lookup before returning control to the sending program (i.e. pine). If you don't mind either some delay in actually sending your mail or an increased load on your host, you can make some changes to your sendmail configuration to take advantage of deferred delivery mode (something I use on my host, which is the backup Debian list server, so that I don't get slowness during list processing). In your /etc/mail/sendmail.cf: # default delivery mode O DeliveryMode=background becomes # default delivery mode O DeliveryMode=deferred In your /etc/init.d/sendmail: Q=30m becomes Q=1m or whatever interval you'd like. I run a variant of this on my mailing list server at 3 seconds, but this can get out of hand very quickly unless you use other sendmail tricks to keep sendmail from swamping your machine. I've spent quite some time playing with sendmail, so feel free to ask further questions. I haven't used smail whatsoever, so I doubt I'd be able to help much. Pete Templin [EMAIL PROTECTED] On Wed, 25 Jun 1997, Paul Wade wrote: On Wed, 25 Jun 1997, Shaya Potter wrote: On Wed, 25 Jun 1997, Leandro Asnaghi-Nicastro wrote: I use Debian 1.2/Linux 2.0.29 and the Pine 3.96 package. But, when I send mail with it, it is very slow (it takes about 1 ou 2 minutes to send a message). Could it be that the connection with the mail server is slow? If you are on a dial-up and you are using POP3, depending on the speed of your connection, the mail server will take it's sweet time. I'm not so sure, I am using sendmail on my linux box, and pine is slow with it. I get the same with smail and I'm not using a smarthost. I think it could be an smail or pine config thing, because you would think that smail would accept the mail right away and pine would continue. Makes me think that it makes an initial delivery attempt at the time. I know that when I have mail in the retry spool, pine runs normally. -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Why is pine so slow?
On Fri, 27 Jun 1997, Joost Kooij wrote: # default delivery mode O DeliveryMode=background becomes # default delivery mode O DeliveryMode=deferred Hmm, this one might be the answer for me. The thing about reverse dns lookups certainly rings a bell here, because my last mail on this topic took unusually long to get sent - and it had a rather largish list of cc:'-ed addresses. It's the reason (although I doubt the above would fix it) that sendmail takes a while to launch on a diald-connected machine. I would strongly suggest the sendmail book for anyone who uses sendmail (which is a hot topic on these lists some days!), along with the companion desktop reference. The reference can provide some neat insights that otherwise get lost in the large book. The book itself is daunting when first viewed, but I found it to be quite readable. I bought and read it during my senior year here at Bucknell, and read through it cover to cover straight through in about two weeks (that was the first edition) _while_ taking classes. I caught up on the second edition while in Pittsburgh on a training seminar (Micro$oft SMS, and you though sendmail was complex!)in a few nights. The initial spark for my performance tuning of sendmail while handling Debian list mail came from an article on mailing lists and ~/.forward (p. 293 first edition, not explained but mentioned on p. 422 second edition). Enough ranting...hope you've learned at least something. Pete Templin [EMAIL PROTECTED] -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Netscape bug: Newbies using root
It's also important not to use Netscape as root (or other mail tools as root) when sending mail to the Debian mailing lists. I get lots of posts that don't go through, because the sender is root or another system user that Smartlist recognizes. Pete -- Peter J. Templin, Jr. Client Services Analyst Computer Communication Services tel: (717) 524-1590 Bucknell University [EMAIL PROTECTED] On 20 Jun 1997, John Goerzen wrote: It is stated very clearly in documentation all over that you should run as root as little as possible... Besides, it is common sense. When I first taught myself Unix, this was impressed on me very clearly. The Linux NAG and SAG mention it, I'm sure, as do some various HOWTOs. -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Big Bad Bug - adduser truncating files from /etc/skel.
I reported this a few weeks ago. Adduser v3.3 should fix this, and should be forthcoming from Guy Maor. Pete -- Peter J. Templin, Jr. Client Services Analyst Computer Communication Services tel: (717) 524-1590 Bucknell University [EMAIL PROTECTED] On Sat, 21 Jun 1997, Dave Cinege wrote: I finally had the need to add some users to my brand new 1.3.0 server. Using adduser everything copied from /etc/skel to /home/[user] gets hacked down to one line. Don't seem like a 'feature' to me -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: /etc/securetty problem
On Sat, 21 Jun 1997 [EMAIL PROTECTED] wrote: I've done that a hundred times you [EMAIL PROTECTED] It doesn't work I'm still on the damned list. For those who wish to know, Sean.Seaman did contact [EMAIL PROTECTED] once to request unsubscription. There are no seans from anywhere within rutgers on the lists, and the other rutgers subscribers are too ambiguous to guess at their removal. Sean has not contacted me by direct e-mail to request removal whatsoever. Hopefully he will soon get the proper message. -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: striping, etc.
On Fri, 20 Jun 1997, Rick Hawkins wrote: They will go on a machine with 3 200m ide drives, which will be a poor-man's server. My current thinking is to mount / on the first controller, and use the other pair as /usr on the second interface. /usr will be NFS exported. Or would I be better off putting the two /usr drives on separate controllers? I'd think it was better to mount them across separate controllers. With seperate control and data lines, the kernel can issue two simultaneous requests and get data from both at the same time. My understanding with IDE (and EIDE) is that a single controller can only access a single drive at a time and must wait for that request to finish before issuing another. The reason i'm hesitating to put them on separate controllers is that / is also on the first controller. Everything that gets nfs exported will come off /usr, and my concern is that massive hits to the portion that was slaved could leave / unaccesable to the host. Assuming you don't plan to add an ISA IDE/EIDE controller (I've seen them, and I think someone is running Debian with one (giving them three or even four IDE controllers)), I would suggest running both disks on the second controller and using linear, although that's merely a guess, not a result of actual testing. I had a 2x3.1GB RAID0 md array, with both disks as slaves. I had 2x120M swap areas, one on each of the masters. If mirror was running, it was trying to access the (slave) array while swapping to the (master) swap area(s). Horrible performance! Don't think about putting / on md...without a non-md partition, you can't read the kernel, and without the kernel you can't load the md stuff. _DO_ compile md into the kernel, it'll be much easier to use than if it is modularized. One bad note to put forth: Concurrent with a local storm and power failure (though I don't think it was related), my Linux host choked. Upon reboot, fsck on the md array failed (some sort of internal error). With my limited knowledge of filesystems, I couldn't fix it and was forced to rebuild my data. As a result, I chose to remove the md array and downgrade my disk usage (I had a mirror on it, so I just had to give up breathing room and Debian 1.1, only weeks before the release of 1.3 so I wasn't too bummed). In doing so, I rearranged partitions so that / and /usr were on different controllers, swap was on the same disk as /, and got much better performance than before. Very well worth it, but too many changes (and too many other space commitments) to possibly restore the md array and see how performance was after the repartitioning. Sorry I can't verify that speed. And, make sure your drives DON'T spin down ever (I used hdparm -S 0 I think to stop that behavior). HTH, Pete -- Peter J. Templin, Jr. Client Services Analyst Computer Communication Services tel: (717) 524-1590 Bucknell University [EMAIL PROTECTED] -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
