Re: Bug#276217: postfix: random SIGSEGV in smtp processes
On Tuesday 12 October 2004 22.49, Emmanuel Lacour wrote: On Tue, Oct 12, 2004 at 07:33:36PM +0200, Adrian 'Dagurashibanipal' von Bidder wrote: No other strange log messages, no mail being lost that I know of. Add -v option for smtpd in master.cf to view the full log (lots of log, be carefull) Will try. I did run apt-get upgrade, but I can't say what packages were upgraded (grr. Why doesn't dpkg write a log!?!?!?) apt-get upgrade -u ^^^ That still doesn't get me a log. The system is mostly testing with bits of stable and unstable mixed in. Why stable packages in testing??? Because stable has security support. I try to use the stable version of any package if it works for me. Unfortunately, things like php and subversion pull in a LOT of testing because libc6 upgrade is needed, so the system now is mostly testing. greetings -- vbi (No need for CC:s, thanks. Please respect Debian list policy) -- Oops pgp4dFwBNaocK.pgp Description: PGP signature
Re: Can we build a proper email cluster? (was: Re: Why is debian.org email so unreliable?)
On Wed, 13 Oct 2004 20:42, Steinar H. Gunderson [EMAIL PROTECTED] wrote: On Wed, Oct 13, 2004 at 01:05:26PM +1000, Russell Coker wrote: http://www.umem.com/16GB_Battery_Backed_PCI_NVRAM.html If you want to use external journals then use a umem device for it. The above URL advertises NV-RAM devices with capacities up to 16G which run at 64bit 66MHz PCI speed. Such a device takes less space inside a PC than real disks, produces less noise, has no moving parts (good for reliability) and has ZERO seek time as well as massive throughput. Out of curiosity; approximately how much does such a thing cost? I can't find prices on it anywhere. Last time I got a quote the high-end model had 1G of storage and was 33MHz 32bit PCI. It cost around $700US. I would expect that the high-end model costs around that price nowadays, but if you want one you'll just have to apply for a quote. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#276217: postfix: random SIGSEGV in smtp processes
On Wed, Oct 13, 2004 at 09:45:22AM +0200, Adrian 'Dagurashibanipal' von Bidder wrote: On Tuesday 12 October 2004 22.49, Emmanuel Lacour wrote: That still doesn't get me a log. It shows you which packages will be upgraded. Because stable has security support. I try to use the stable version of any package if it works for me. Unfortunately, things like php and subversion pull in a LOT of testing because libc6 upgrade is needed, so the system now is mostly testing. humm, I prefer running stable with some backports (mine or from www.backports.org)... It's easy for subversion, a little bit more difficult for php4, but not impossible. Regards, -- Emmanuel Lacour Easter-eggs 44-46 rue de l'Ouest - 75014 Paris - France - Métro Gaité Phone: +33 (0) 1 43 35 00 37- Fax: +33 (0) 1 41 35 00 76 mailto:[EMAIL PROTECTED] -http://www.easter-eggs.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#276217: postfix: random SIGSEGV in smtp processes
This one time, at band camp, Adrian 'Dagurashibanipal' von Bidder said: On Tuesday 12 October 2004 22.49, Emmanuel Lacour wrote: On Tue, Oct 12, 2004 at 07:33:36PM +0200, Adrian 'Dagurashibanipal' von I did run apt-get upgrade, but I can't say what packages were upgraded (grr. Why doesn't dpkg write a log!?!?!?) apt-get upgrade -u ^^^ That still doesn't get me a log. Totally unrelated to your real question, but for this one: [EMAIL PROTECTED]:~$ cat usr/local/sbin/apt-get #!/bin/bash if [ ! -d /var/log/apt-get ]; then mkdir -p /var/log/apt-get fi filename=/var/log/apt-get/$(date +%Y%m%d%H%M%S) echo $0 $@ $filename echo --- $filename /usr/bin/apt-get -q $@ 21 | tee --append $filename Works nicely. Putting it in /usr/local/sbin makes it come first in root's default path, and has the advantage of being outside of regular user's path's so they can still 'apt-get source' without getting a permission denied on the log file. -- - | ,''`.Stephen Gran | | : :' :[EMAIL PROTECTED] | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - pgpSJvax5GMHu.pgp Description: PGP signature
this thread moved (was: Can we build a proper email cluster?)
Note: this thread was moved from debian-private to here. As soon as I have the okay from all previous posters, I will make the other posts available... -- Please do not CC me when replying to lists; I read them! .''`. martin f. krafft [EMAIL PROTECTED] : :' :proud Debian developer, admin, and user `. `'` `- Debian - when you have better things to do than fixing a system Invalid/expired PGP subkeys? Use subkeys.pgp.net as keyserver! signature.asc Description: Digital signature
Re: Can we build a proper email cluster?
On Thu, Oct 14, 2004 at 12:20:07AM +1000, Russell Coker wrote:
On Wed, 13 Oct 2004 23:23, Wouter Verhelst [EMAIL PROTECTED] wrote:
For instance, my /etc/default/libnss-db contains the following lines:
ETC = /root/stage
DBS = passwd group shadow
shadow is part of the passwd setup. group does no good on most systems (on my
system /etc/group is only 70 lines and the database gives no benefit).
The point was that at home, I'm not using libnss-db for its performance
gain (which would be silly). In the case of group, it's because I want
to avoid having to concatenate multiple files (which is messy) and
because I want to maintain certain groups in the centralized database.
AFAIK, it's not possible to use 'compat' in /etc/nsswitch.conf with
multiple passwd (and friends) files, so that's not an option.
I also have a script which creates (incomplete (as in, without system
users)) files /root/stage/{passwd,shadow,group} containing just the user
and group records that are in LDAP. Next, /etc/nsswitch.conf contains
the following:
passwd: db compat
group: db compat
shadow: db compat
So what's the point of having LDAP if you are going to manually copy flat
files around?
First, I'm not manually copying flat files around. Every host generates
its own version of the flat file, which allows me to apply filters based
on the time, the host name, etc; this way, I can give a guest a
time-limited account on just *one* of my machines. pam_mkhomedir helps
in that I don't have to create the home directory, either.
Second, having stuff in LDAP allows my users to update certain
attributes connected to their user object in the directory (such as,
e.g., loginShell). This would also be possible using NIS (which I simply
don't like) or, provided I'm up to maintaining a gross and error-prone
hack, a flat file on a file server which is maintained through a bunch
of access-checking SetUID programs, but I very much prefer doing it this
way.
The implementation in Linux is fairly poor however, it doesn't even
stat /etc/passwd to see if it's newer than the db.
That's a feature, not a bug. Unless you want it to check 'the passwd
file' as it is defined in /etc/default/libnss-db (or another
configuration file), in which case it would indeed be a good idea.
If you want the database to be in sync with the flat file and be usable
without gross hacks as it is in AIX then it's a serious bug.
The flat files are updated by a cron job, which looks like this:
#!/bin/bash
/root/stage/passwd-gen
cd /var/lib/misc
make
I understand how it is problematic if you have to remember to regenerate
the database files every time you modify something vaguely related to a
user; but that is not the case, so in my situation the fact that stuff
isn't automatigically updated is a feature, not a bug. Moreover, if
libnss-db would be modified to suddenly update the .db files if
/etc/passwd (and friends) change, that would completely break my setup.
The performance gain isn't as good as you would expect either.
Been there, done that.
IME, doing this kind of thing is *way* faster than using libnss-ldap.
Way faster than a non-local LDAP. But not significantly faster than flat
files unless you have 10,000 users (which isn't the case for Debian).
Oh, that's what you mean. Misunderstood you then, sorry.
--
EARTH
smog | bricks
AIR -- mud -- FIRE
soda water | tequila
WATER
-- with thanks to fortune
signature.asc
Description: Digital signature
Re: High volume mail handling architecture
On Fri, Oct 08, 2004 at 10:07:15AM +0100, John Hedges wrote: On Fri, Sep 10, 2004 at 05:34:07PM +, Gerrit Pape wrote: On Fri, Sep 10, 2004 at 09:49:27AM +0200, Adrian 'Dagurashibanipal' von Bidder wrote: Herre is what happens: A spammer uses my email address as the sender address in spam frequently. So, that's my plea to everybody with big mail installations: make your frontend machines aware of what mail they are supposed to accept, so that you never need to bounce. (Ok, some cases will still bounce: disk full, procmail script errors etc., but these are a very small proportion.) And the other plea is, of course, get rid of qmail and other products which accept all mail by default. As far as my experience goes, pleas or complaints against other people doesn't help much if you want to see something changed. Better help yourself. I suggest to instruct your mail user agent to make use of the (apparently almost forgotten) fact that the sender's addresses in the envelope and in the header can be different. Most today's mail transfer agents should support address extensions. If your address is used as envelope sender in unsolicited mail, it's your public one. Use a non-public address as envelope sender of mail you send, and simply change it in case it gets abused; only bouncers should send mail to this address, and they usually do within two weeks. Now you can configure your MTA to outright reject delivery notifications solely based on the information in the envelope. Sorry to reopen such an old thread. I'd saved this mail for reference as I too get a lot of bounces for spam with forged mail headers. A fresh run of spam that some wanker has initiated in my name has made my inbox unbearable this last few days so I need to do something about it. It's not because of forged headers but forged envelopes, your address is used as envelope sender in SMTP (MAIL FROM:[EMAIL PROTECTED]). It's the envelope sender address where delivery notifications, such as bounces, are sent; and those delivery notifications usually have an empty envelope sender (MAIL FROM:). Replies and followups are sent to an address specified in the headers of the mail (From: John [EMAIL PROTECTED], or Reply-To:), and have a non-empty envelope sender. If john starts to send all his mails with the envelope sender address [EMAIL PROTECTED] and still uses the same headers, communication with the recipients will not change, but delivery notification will go to [EMAIL PROTECTED]. His public, well known, unchangeable mail address [EMAIL PROTECTED] now no longer receives delivery notification for mail john himself has sent; he now can safely reject or disregard mails sent with an empty envelope sender to the envelope recipient [EMAIL PROTECTED], solely based on the envelope information, without looking at the headers or the body of the mail. Would it be possible for you, Gerrit, to expand a little on your setup? My personal setup is done with the qconfirm package, specifically, I send mails through the qconfirm-inject program which adjusts the envelope sender, and so requests bounces to go to a different address than my public one. This is qmail specific, and you need shell access to the mail server. I currently use fetchmail to get my mail from a catchall mailbox at my ISP. Can I use the envelope sender trick in this case as I can't see an easy way to differentiate between bounces and normal email once the messages reach my box? Most of the bounces are sent with an empty envelope sender (), I'm not sure whether fetchmail preserves the envelope information, it might get lost; look for Return-Path:. Although it might work with your setup, sorting out the bounces better should be done on the mail exchanger I think. Regards, Gerrit. -- Open projects at http://smarden.org/pape/. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Can we build a proper email cluster? (was: Re: Why is debian.org email so unreliable?)
On Thu, 14 Oct 2004 01:47, Henrique de Moraes Holschuh [EMAIL PROTECTED] wrote: On Wed, 13 Oct 2004, Russell Coker wrote: On Wed, 13 Oct 2004 07:29, Henrique de Moraes Holschuh [EMAIL PROTECTED] wrote: We have a lot of resources, why can't we invest some of them into a small three or four machine cluster to handle all debian email (MLs included), A four machine cluster can be used for the entire email needs of a 500,000 user ISP. I really doubt that we need so much hardware. Including the needed redundancy (two MX at least), and a mailing list processing facility that absolutely has to have AV and AntiSPAM measures at least on the level gluck has right now? The Debian email isn't that big. We can do it all on a single machine (including spamassasin etc) with capacity to spare. Yes, one machine that is just a MTA, without AV or Antispam should be able to push enough mail for @d.o. One machine should be able to do it with AV and antispam. Four AV/antispam machines can handle the load for an ISP with almost 1,500,000 users, one should do for Debian. But we really should have two of them (in different backbones), with the same priority as MX. Why? It would be nice to have a third MTA with less priority and heavier anti-spam machinery installed. Bad idea. OK, having a single dedicated mail server instead of a general machine like master makes sense. Two so that we have some redundancy, please. IMHO email is important enough in Debian to deserve two full MX boxes (that never forward to one another). As long as the machine is fixed within four days of a problem we don't need more than one. Email can be delayed, it's something you have to get used to. U320 is not required. I don't believe that you can demonstrate any Required? No. Nice to have given the hardware prices available, probably. If the price difference is that big, U160 is more than enough. But top-notch RAID hardware nowadays is always U320, so unless the hotswap U160 enclosures and disks are that much cheaper... and the price difference from a non top-notch HW RAID controller that is still really good, and a a top-notch one is not that big. We don't need high-end hardware. Debian's email requirements are nothing compared to any serious ISP. http://www.umem.com/16GB_Battery_Backed_PCI_NVRAM.html How much? It certainly looks very good. If you want to buy one then you have to apply for a quote. I've run an ISP with more than 1,000,000 users with LDAP used for the back-end. The way it worked was that mail came to front-end servers which did LDAP lookups to determine which back-end server to deliver to. The I meant LDAP being used for the MTA routing and and rewriting. That's far more than one lookup per mail message :( Yes, I've done all that too. It's really no big deal. Lots of Debian developers have run servers that make all Debian's servers look like toys by comparison. back-end server had Courier POP or IMAP do another LDAP lookup. It worked fine with about 5 LDAP servers for 1,000,000 users. Well, we are talking MTA and not mail stores. The LDAP workload on a MTA is usually quite different for the one in a mail store. Yes, it should be less load because you don't have POP or IMAP checks. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
vsftpd and virtual users with different home directories
Hello all, Does anybody know if it's possible to setup vsftpd with virtual users who are chrooted to different home directories? I've gone through all the documentation, and I don't see anything saying that it is or is not possible. I'm using Debian sarge and running vsftpd with a MySQL authentication backend. Thanks, Stephen Le -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
