Regenerate or move postfix queue
Hi. I'm running out of space for my postfix's spool directory and I'm planning to create a new 30GB partition and mount it over the current spool dir (/var/spool/postfix). How do I re-generate the queue after mounting the new partition and having an emtpy /var/spool/postfix/ ? In squid, as an example, exists squid -Z which recreates postfix's queue. There is something similar in postfix? Maybe I should check CentOS postfix's post-install scripts instead (/etc/postfix/post-install)? Another option would be (after stopping postfix), move the old queue contents to the new queue, but I'm not sure if that would be OK (in qmail, it couldn't be done because each message in the queue depends on the fs i-node). Thanks. PS: # ls -ld /var/spool/postfix/ drwxr-xr-x 16 root root 4096 oct 1 2009 /var/spool/postfix/ # ls -l /var/spool/postfix/ total 1736 drwx-- 2 postfix root 32 jun 21 09:27 active drwx-- 2 postfix root 4096 jun 21 06:54 bounce drwx-- 2 postfix root 4096 ago 14 2008 corrupt drwx-- 18 postfix root 4096 jul 2 2010 defer drwx-- 18 postfix root 4096 jul 2 2010 deferred drwx-- 2 postfix root 4096 ago 14 2008 flush drwx-- 2 postfix root 4096 ago 14 2008 hold drwx-- 2 postfix root 761856 jun 21 09:25 incoming drwx-wx--- 2 postfix postdrop 16384 jun 21 09:25 maildrop drwxr-xr-x 2 rootroot 4096 jul 2 2010 pid drwx-- 2 postfix root 4096 may 26 12:11 private drwx--x--- 2 postfix postdrop 4096 may 26 12:11 public drwx-- 2 postfix root 4096 ago 14 2008 saved drwx-- 2 postfix root 4096 ago 14 2008 trace
Re: Question about address verification in MX2 when primary MX is down...
Yes, that's what the docs say. 450 = default, defer mail if the address can't be verified. 250 = if the address can't be verified, accept it anyway. Not recommended. So, summarizing. (And, please, correct me before doing a wrong change in my config file): My current server now is a backscatter source, because it accepts mail to ANY recipient address for the domains listed in relay_domains (domains I'm work as a secondary MX for). By adding the following to my main.cf, I'll check RCPT TO addresses against primary MX, except when PRIMARY MX doesn't answer. In that case, I'll accept any destination for my relay_domains list, just like I was doing before adding those lines: address_verify_map = btree:/var/lib/postfix/verify address_verify_positive_refresh_time = 14d unverified_recipient_defer_code = 250 smtpd_recipient_restrictions = permit_mynetworks, permit_sasl_authenticated, (...) reject_unverified_recipient, permit If the above is true, I'm in a better state than before: when the primary MX works, I reject non existing accounts, and when it does not work, I accept ALL (as I was doing). Is that right? Thanks.
Re: Question about address verification in MX2 when primary MX is down...
Hi, Quoting the documentation[1]: The unverified_recipient_defer_code parameter (default 450) specifies the numerical Postfix SMTP server reply code when a recipient address probe fails with some temporary error. Some sites insist on changing this into 250. NOTE: This change turns MX servers into backscatter sources when the load is high. So, do you mean that changing this parameter to 250 would make postfix to accept the email? Thanks a lot.
Re: Question about address verification in MX2 when primary MX is down...
If you want this behavior, do not use reject_unverified*. Instead, use a relay_recipient_maps that can be checked locally. Hi. This server is a secondary MX server for our customers. Those customers have their own private primary MX servers, so It's not possible for me to have a local database of existing accounts. That's why I wanted to use reject_unverified_recipient, to let postfix guess if an account is valid or not using RCPT TO. And this behaviour is perfect, except when primary MX doesn't answer. It would be really perfect to be able to force postfix to accept the incoming emails when the dest address cannot be validated... Unless you have a really good reason, you'd be much better off just losing the MX2, Customers paying for MX BACKUP SERVER service is a good reason to not loose MX2 :-) Really, reject_unverified_recipient feature is very nice, but rejecting all mail when primary MX doesn't answers breaks it for us :( Any idea? :?
Re: PATCH: Possible reasons for qmgr loading the system?
To apply this patch, cd into the Postfix-2.5.* top-level source directory and execute: $ patch thismessage We were able to reproduce the scheduler looping problem, and it does not recur with the patched version A question ... what' the way to make this patch to be included in Ubuntu Server postfix packages? I mean, should I submit your message+patch to the package maintainers of Ubuntu / Debian / Redhat so that new postfix packages with the bug corrected are released as updates for users? Or ... you just publish the patch / bug somewhere and then the package maintainers update their sources automatically without we or you needing to contact them? :? I can patch postfix's sources, but then I loose Ubuntu package security updates and will force me to maintain postfix from sources since this moment. The best way would be your patch to be integrated in postfix and new security postfix packages to be released by package maintainers, but I don't know how to force that. Thanks. -- Santiago Romero
Re: PATCH: Possible reasons for qmgr loading the system?
Gerard escribió: In a perfect world, the program maintainers would know about the patch and take steps to correct their package/port or whatever. You might want to contact the maintainer of Postfix for your Distro and see if they are planning on updating the package/port. Usually, they do get a little annoyed if you start bugging them 5 seconds after the patch is released. Some of them actually have day jobs Well, I'm not planning to bug them with the patch. I don't know if the integration of the patch with the current package versions is automatic or author / bug discoverers must or should notify them to package maintainers... That's what I was asking: if the process is automatic or should I notify / help in any way. -- Santiago Romero
Re: PATCH: Possible reasons for qmgr loading the system?
Wietse Venema wrote: You might want to repeat your precise Postfix version at this point, and which queue manager version is configured in your master.cf. Current Postfix versions have (qmgr=new, oqmgr=old) in master.cf. Older Postfix versions have (nqmgr=new, qmgr=old) instead. The programs are the same except for the job selection algorithm. r...@egeo:~# postconf mail_version mail_version = 2.5.1 r...@egeo:~# grep -i qmgr /etc/postfix/master.cf qmgr fifo n - n 300 1 qmgr #qmgr fifo n - - 300 1 oqmgr If you are using the new queue manager, it is worthwhile to see if the problem persists when you switch to the old queue manager. It seems I'm using the new one... OK, leave the above settings and see if this helps (Postfix 2.5 or later). I have not been able to reproduce the problem, but there was some bogosity with the handling of _destination_rate_delay. diff --exclude=man --exclude=html --exclude=README_FILES --exclude=.indent.pro --exclude=Makefile.in -cr src/qmgr/qmgr_entry.c- src/qmgr/qmgr_entry.c Well, I'm using postfix's ubuntu package, so it's not compiled from source code because I need all my ~=100 Linux machines to be easily updatable (apt-get update apt-get upgrade). In this case, I'm going to recompile .deb source package including your patch to see if that solves the problem ... Please, allow me a couple of days to recompile / install it (it's a production system, I need to find a working window with customers). I'll inform you in this list if the problem happens again or if the patch seemed to fix the problem. Do you want any kind of aditional change / logging / config to make the problem more easy to happen? (I mean, setting rate_ values higher or lower so that the problem reproduces again faster, because it passed 5 days between the last 2 times qmgr ate the CPU...). Thanks. -- Santiago Romero
Re: PATCH: Possible reasons for qmgr loading the system?
Please wait for an updated patch, we believe we have identified the cause and reproduced the symptoms (in that order). I have a candidate patch, but I expect Wietse will send an updated more polished version in the not too distant future. Ok, I'll wait for it. I'm going to roll back to ubuntu packages (I already applied the patch and was testing it). The original 2.5.x code is correct for oqmgr, but not for qmgr (aka nqmgr), which requires additional internal state adjustments when destinations are blocked and unblocked I've changed to oqmgr in master.cf for the machine that uses that special slow transport. Would I notice any difference in postfix behaviour because of using oqmgr instead of qmgr (less performance or something like that)? Thanks. -- Santiago Romero
Re: Possible reasons for qmgr loading the system?
Wietse Venema escribió:
Santiago Romero:
I case it happens again ... Where or what should I take a look? At OS
level (disk or network I/O, processes...) I didn't see anything before
the postfix restart...
Try ``strace -o filename -p pid'' or the equivalent for your OS.
Hi.
Today happened again in 2 new machines. The last one:
top - 09:44:25 up 19:39, 2 users, load average: 4.68, 4.87, 4.76
Tasks: 154 total, 6 running, 148 sleeping, 0 stopped, 0 zombie
Cpu(s): 30.7%us, 49.2%sy, 0.0%ni, 11.7%id, 1.3%wa, 1.0%hi, 6.1%si,
0.0%st
PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+
COMMAND
26926 postfix 20 0 5840 2552 1792 R 43 0.3 276:51.22 qmgr
The problem was never appeared in those machines until, yesterday, I
added the following to postfix configuration:
/etc/postfix/master.cf
slow unix - - - - - smtp
-o syslog_name=postfix-slow
/etc/postfix/main.cf
# Special slow transport:
slow_destination_recipient_limit=1
slow_destination_concurrency_limit=1
slow_destination_rate_delay=5
Stracing qmgr process for a while (before restarting postfix), showed
lots of lines like:
time(NULL) = 1236156322
epoll_ctl(8, EPOLL_CTL_DEL, 128, {EPOLLIN, {u32=128,
u64=13252642876283682944}}) = 0
fcntl64(128, F_GETFL) = 0x802 (flags O_RDWR|O_NONBLOCK)
fcntl64(128, F_SETFL, O_RDWR) = 0
ioctl(128, FIONREAD, [10]) = 0
poll([{fd=128, events=POLLIN, revents=POLLIN}], 1, 360) = 1
read(128, status\\0\0, 4096) = 10
gettimeofday({1236156322, 508869}, NULL) = 0
close(128) = 0
epoll_ctl(8, EPOLL_CTL_DEL, 129, {EPOLLIN, {u32=129,
u64=13252642876283682945}}) = 0
fcntl64(129, F_GETFL) = 0x802 (flags O_RDWR|O_NONBLOCK)
fcntl64(129, F_SETFL, O_RDWR) = 0
ioctl(129, FIONREAD, [10]) = 0
poll([{fd=129, events=POLLIN, revents=POLLIN}], 1, 360) = 1
read(129, status\\0\0, 4096) = 10
gettimeofday({1236156322, 510488}, NULL) = 0
close(129) = 0
alarm(333) = 333
socket(PF_FILE, SOCK_STREAM, 0) = 13
fcntl64(13, F_GETFL)= 0x2 (flags O_RDWR)
fcntl64(13, F_SETFL, O_RDWR|O_NONBLOCK) = 0
connect(13, {sa_family=AF_FILE, path=private/slow}, 110) = 0
gettimeofday({1236156322, 513893}, NULL) = 0
fcntl64(13, F_DUPFD, 128) = 128
close(13) = 0
epoll_ctl(8, EPOLL_CTL_ADD, 128, {EPOLLIN, {u32=128,
u64=13834671851822907520}}) = 0
time(NULL) = 1236156322
socket(PF_FILE, SOCK_STREAM, 0) = 13
fcntl64(13, F_GETFL)= 0x2 (flags O_RDWR)
fcntl64(13, F_SETFL, O_RDWR|O_NONBLOCK) = 0
connect(13, {sa_family=AF_FILE, path=private/slow}, 110) = 0
gettimeofday({1236156322, 515731}, NULL) = 0
fcntl64(13, F_DUPFD, 128) = 129
close(13) = 0
epoll_ctl(8, EPOLL_CTL_ADD, 129, {EPOLLIN, {u32=129,
u64=13834671851822907521}}) = 0
time(NULL) = 1236156322
ioctl(3, FIONREAD, [100]) = 0
time(NULL) = 1236156322
My problem seems to be related to my new slow transport. I don't know
what I'm doing wrong, because I followed your advice and postfix
manuals... but that's happening since I added my slow transport ...
I'm using postfix-2.5.1-2ubuntu1.2.
--
Santiago Romero
Possible reasons for qmgr loading the system?
Hi. Today I had a load average issue in a postfix mail server (only runs postfix service). Suddenly, load average started to raise and qmgr process appeared on top of top taking 20-30% of CPU. top - 18:19:54 up 7 days, 2:03, 2 users, load average: 4.94, 3.96, 4.02 Tasks: 144 total, 6 running, 138 sleeping, 0 stopped, 0 zombie Cpu(s): 48.3%us, 50.7%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 1.0%si, 0.0%st Mem: 1035280k total, 64k used,35316k free, 149072k buffers Swap: 750696k total, 88k used, 750608k free, 599308k cached PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND 23665 postfix 20 0 5880 2628 1792 S 20.3 0.3 68:11.18 qmgr 23662 root 20 0 5392 1732 1400 R 6.0 0.2 20:49.46 master Network traffic was low and we had the normal throughput of emails. Queue had only 73 emails in it when the problem happened (just like now, they are all deferred emails). Doing postfix stop / postfix start solved the problem. I case it happens again ... Where or what should I take a look? At OS level (disk or network I/O, processes...) I didn't see anything before the postfix restart... Thanks. -- Santiago Romero
Re: Limit rate/concurrency to a given domain
That's right, the logs show the program name (smtp) not the transport name; you can't tell which transport called smtp. You can add something like -o syslog_name=postfix-slow to the master.cf slow transport entry to differentiate the logging. That's it. Postfix is awesome and very well designed. Such kind of change would need 723435 patches in qmail (and that's why I'm migrating all my qmail servers to postfix). Thanks a lot. -- Santiago Romero
Accepting messages only for valid users in a secondary MX server
Hi. I have a secondary MX server with qmail that I'm migrating to postfix. Currently, my qmail server checks RCPT TO addresses against a plain text file that contains all the valid email accounts for some of the domains that is making MX-backup for. That plain-text file is scp'ed from the main server. As I'm migrating it to postfix, I wonder if it's possible to do the same in postfix. To summarize it, currently I have 2 files called: valid_accounts.txt: a list of valid accounts in the primary MX. domains_to_check_user.txt: Holds a list of domains. Server only checks RCPT against valid_accounts.txt for the domains present in this file. When a new email arrives, if the destinatary domain is in domains_to_check_user.txt, then I check the RCPT TO against valid_accounts.txt (and return NO SUCH USER or ACCEPT the email). If the domain is not in domains_to_check_user.txt, I accept it (if it's in qmail's rcpthosts's, of course). This way, I'm rejecting thousands of email messages directed to non-existent accounts in our main domains and sent directly to our MX2 server (as it cannot check if the account exists without this method). Is there any way of doing something similar in postfix (maintaining domains and accounts in 2 different files would be nice)? Thanks a lot. -- Santiago Romero
Re: Accepting messages only for valid users in a secondary MX server
Postfix calls domains that it accepts mail for but delivers elsewhere (such as MX backups) relay_domains. You can use a plain text file or any supported postfix map type. The list if valid recipients in those domains is specified in relay_recipient_maps. Specify one or more map files listing the valid recipients; all other recipients are rejected. http://www.postfix.org/postconf.5.html#relay_recipient_maps My question is : Can I have domains in relay_domains for which I check relay_recipient_maps and domains for which I don't check it? Example: domain1.com - My main domain, I know accounts in the primary MX customer.com - I work as MX backup for it, I don't know their accounts relay_domains = domain1.com, customer.com relay_recipient_maps = hash:/etc/postfix/valid_relay_accounts If I define N (let's say 100) accounts for @domain1.com in valid_relay_accounts and 0 accounts for @customer.com, what would postfix do with with @customer.com emails? Would postfix reject or accept it (no accounts defined in relay_recipient_maps por it). My problem is that I have knowledge of accounts of SOME of the domains I act as MXBackup for... and I want to check rcpt to only for those domains, while accepting any RCPT TO for the others. Thanks. -- Santiago Romero
Re: Limit rate/concurrency to a given domain
Wietse Venema escribió: default_destination_rate_delay (default: 0s) The default amount of delay that is inserted between individual deliv- eries to the same destination; with per-destination recipient limit 1, a destination is a domain, otherwise it is a recipient. .. NOTE: THE DELAY IS ENFORCED BY THE QUEUE MANAGER. ... The delay is NOT implemented by the smtpd process. I finally was setting: /etc/postfix/master.cf: slow inet n - - - - smtp /etc/postfix/transports: domain1.comslow: /etc/postfix/main.cf: slow_destination_recipient_limit = 1 slow_destination_concurrency_limit = 1 slow_destination_rate_delay = 2 Do you mean (sorry If I didn't understood it) that I can use: slow_destination_recipient_limit = 1 slow_destination_concurrency_limit = 1 but no: slow_destination_rate_delay = 2 ? The logfile shows in any way that I'm sending a give email with the slow transport instead of the standard smtp transport? (To verify if my config is working correctly and check if emails are going out by the right transport). Thanks for your help. -- Santiago Romero
Strange problem with pickup process (maybe just a coincidence)
Hi. I have a strange problem monitoring the pickup process: we have a monitoring system that, sometimes, warns us with pickup process not in memory (master and qmgr seems to continue running). When we enter the machine, we notice that pickup is really in memory, but after that alarm, every monitoring cycle (every 180 seconds) tells us that pickup is not present in memory as a process. Starting with the first alarm reported by the monitoring tool, pickup process is reported as not in memory in each monitoring cycle, until we do a postfix restart. Then it works perfectly again for a undeterminated amount of time (days, weeks, months). I can't find any error in the logs... and my master.cf shows: # grep pickup /etc/postfix/master.cf pickupfifo n - n 60 1 pickup I noticed that pickup wakes up every 60 seconds, and my monitoring system checks processes every 180 seconds. Maybe it's just synchronization and my monitoring system performs the checking just when postfix is restarting pickup? Does the wake up restart the process itself? The docs just say: Wake up time (default: 0) Automatically wake up the named service after the specified number of seconds. The wake up is imple- mented by connecting to the service and sending a wake up request. A ? at the end of the wake-up time field requests that no wake up events be sent before the first time a service is used. Specify 0 for no automatic wake up. But I don't now if wake up means a signal or an o.s. kill + new process (which could explain my monitoring incidence). (if it's that, I can just change 60 to 70 seconds, and that way the ps auxwww | grep pickup won't synchronize with pickup restart). Is it safe to raise those 60 seconds to a more higher value, such as 600 or so? Am I right with the synchronization hypotesis or could be something different? Thanks a lot. -- Santiago Romero
Re: Strange problem with pickup process (maybe just a coincidence)
Bastian Blank escribió: On Wed, Feb 11, 2009 at 09:00:14AM +0100, Santiago Romero wrote: I have a strange problem monitoring the pickup process: we have a monitoring system that, sometimes, warns us with pickup process not in memory What is the meaning of this message? This one (this morning!): truth:~# date mie feb 11 09:52:04 CET 2009 b...@truth:/usr/local/bb/ext$ ps auxwww | grep pickup bb 12674 0.0 0.0 1332 432 pts/0S09:50 0:00 grep pickup b...@truth:/usr/local/bb/ext$ ps auxwww | grep pickup bb 12692 0.0 0.0 1332 432 pts/0S09:50 0:00 grep pickup b...@truth:/usr/local/bb/ext$ ps auxwww | grep pickup bb 12705 0.0 0.0 1332 432 pts/0S09:50 0:00 grep pickup b...@truth:/usr/local/bb/ext$ ps auxwww | grep pickup bb 12712 0.0 0.0 1332 432 pts/0S09:50 0:00 grep pickup truth:~# /etc/init.d/postfix restart Shutting down postfix: postfix/postfix-script: stopping the Postfix mail system Starting postfix: postfix/postfix-script: starting the Postfix mail system truth:~# ps auxwww | grep pickup postfix 13427 0.1 0.0 2864 976 ?S09:51 0:00 pickup -l -t fifo -u root 13560 0.0 0.0 1752 732 pts/0S09:51 0:00 grep pickup Pickup process just disappears from memory, and no info about that is shown in log files :-? -- Santiago Romero
Re: smtpd banner problem
Marco Tchi Hong escribi: Hello, In main.cf I have : smtpd_banner = $myhostname ESMTP $mail_name (DATA TELECOM SERVICE) But when I do : telnet myserver.tld 25 from another server I get : 220 ** I don't find why I don't get the good banner. That sounds like a CISCO PIX / ASA firewall filtering your SMTP traffic with the MAILGUARD feature. Ask your firewall administrator to disable that HORRIBLE and EVIL feature, it will cause more problems than benefits. When your fw admin disable MAILGUARD, smtp clients will connect directly to your port 25 and you'll see your nice banner :) -- Santiago Romero
Re: Upgrading from 2.5.1 to 2.5.4 (sasl error????).
Santiago Romero: make makefiles CCARGS=-DUSE_SASL_AUTH -DUSE_CYRUS_SASL -lsasl make See the INSTALL file. Also on-line as http://www.postfix.org/INSTALL.html See also the SASL_README file for SASL-specific command syntax. Ok, I see it: make makefiles CCARGS=-DUSE_SASL_AUTH -DUSE_CYRUS_SASL AUXLIBS=-lsasl Thanks a lot :) -- Santiago Romero
Upgrading from 2.5.1 to 2.5.4 (sasl error????).
Hi. I tried to upgrade from a perfectly running postfix system (2.5.1 + SASL1) to 2.5.4, and got an strange error. I compiled 2.5.1 (tar.gz from postfix's website) 3 months ago with: make makefiles CCARGS=-DUSE_SASL_AUTH -lsasl make make install (answered the install questions and installed postfix in /postfix/ directory) It's been working nicely since then, but due to CVE-2008-2936 I downloaded 2.5.4 (tar.gz from postfix's website) and wrote: tar xvzf postfix-2.5.4.tar.gz cd postfix-2.5.4 make makefiles CCARGS=-DUSE_SASL_AUTH -lsasl make /etc/init.d/postfix stop make upgrade /etc/init.d/postfix start Telnetting port 25 results in (mail.log): postfix/smtpd[8368]: warning: unsupported SASL server implementation: cyrus postfix/smtpd[8368]: fatal: SASL per-process initialization failed postfix/master[28601]: warning: process /postfix/usr/libexec/postfix/smtpd pid 8368 exit status 1 postfix/master[28601]: warning: /postfix/usr/libexec/postfix/smtpd: bad command startup -- throttling Going back to /root/sources/postfix-2.5.1 and remaking a make upgrade solved the problem temporary. Now I'm trying to know what I'm doing wrong, because I'm using the same configure/make setup and the same main.cf/master.cf files... # postconf -n | grep -i sasl | grep -v authenticated broken_sasl_auth_clients = yes smtpd_sasl_auth_enable = yes smtpd_sasl_path = smtpd # cat /etc/postfix/sasl/smtpd.conf pwcheck_method: pwcheck #mech_list: PLAIN LOGIN # dpkg -l | grep -i sasl ii libsasl-dev1.5.27-3.1wood Development files for authentication abstrac ii libsasl-module 1.5.27-3.1wood Basic Pluggable Authentication Modules for S ii libsasl7 1.5.27-3.1wood Authentication abstraction library. ii sasl-bin 1.5.27-3.1wood Programs for manipulating the SASL users dat Any idea? What I'm doing wrong? Thanks for any help. -- Santiago Romero
Re: Upgrading from 2.5.1 to 2.5.4 (sasl error????).
CCARGS='-DUSE_SASL_AUTH \ -DUSE_CYRUS_SASL' When Dovecot authentication was introduced the arguments were changed. Now you have to use -DUSE_CYRUS_SASL explicitely in order to compile support for Cyrus sasl in. It does not compile this way: (...) gcc -Wmissing-prototypes -Wformat -DUSE_SASL_AUTH -DUSE_CYRUS_SASL -DNO_EPOLL -DHAS_PCRE -g -O -I. -I../../include -DLINUX2 -o smtpd smtpd.o smtpd_token.o smtpd_check.o smtpd_chat.o smtpd_state.o smtpd_peer.o smtpd_sasl_proto.o smtpd_sasl_glue.o smtpd_proxy.o smtpd_xforward.o smtpd_dsn_fix.o smtpd_milter.o ../../lib/libmaster.a ../../lib/libtls.a ../../lib/libdns.a ../../lib/libxsasl.a ../../lib/libmilter.a ../../lib/libglobal.a ../../lib/libutil.a -lpcre -ldb -lnsl -lresolv ../../lib/libxsasl.a(xsasl_cyrus_server.o): In function `xsasl_cyrus_server_init': /root/sources/postfix/postfix-2.5.4/src/xsasl/xsasl_cyrus_server.c:235: undefined reference to `sasl_server_init' /root/sources/postfix/postfix-2.5.4/src/xsasl/xsasl_cyrus_server.c:236: undefined reference to `sasl_errstring' (...) But 2.5.1 compiles and works perfectly without -DUSE_CYRUS_SASL, and: # postconf -a cyrus dovecot (in my 2.5.1 without the -DUSE_CYRUS_SASL) Any idea? -- Santiago Romero
Re: Upgrading from 2.5.1 to 2.5.4 (sasl error????).
At the moment I am scratching my head. Something is apparently different in the sasl implementation. I assume that you compile both versions in the same environment? Yes. Same machine: truth:~/sources/postfix# ls -l total 6188 drwxr-xr-x 16 postfix postfix 4096 ago 20 10:03 postfix-2.5.1 drwxr-xr-x 16 root root 4096 ago 20 11:28 postfix-2.5.4 -rw-r--r--1 postfix postfix 3153629 feb 16 2008 postfix-2.5.1.tar.gz -rw-r--r--1 root root 3157713 ago 14 08:13 postfix-2.5.4.tar.gz # dpkg -l | grep -i sasl ii libsasl-dev1.5.27-3.1wood Development files for authentication abstrac ii libsasl-module 1.5.27-3.1wood Basic Pluggable Authentication Modules for S ii libsasl7 1.5.27-3.1wood Authentication abstraction library. ii sasl-bin 1.5.27-3.1wood Programs for manipulating the SASL users dat Y compile 2.5.1 with: make makefiles CCARGS=-DUSE_SASL_AUTH -lsasl make And SASL works. The same make sentences with 2.5.4 compiles and after the make upgrade it gives the sasl error in the logs. If I add the -DUSE_CYRUS_SASL, 2.5.4 does not compile. Thanks. Did you start the compilation from a clean extracted tarball? make clean sometimes wasn't enough to get rid of some previous build remains. Yes, just after the tar xvzf... -- Santiago Romero
Re: Upgrading from 2.5.1 to 2.5.4 (sasl error????).
Santiago Romero wrote: I compile 2.5.1 with: make makefiles CCARGS=-DUSE_SASL_AUTH -lsasl make And SASL works. The same make sentences with 2.5.4 compiles and after the make upgrade it gives the sasl error in the logs. And compiled postfconf says: truth:~/sources/postfix/postfix-2.5.4# ./bin/postconf -a dovecot It seems I need a -D flag to use SASL1 ... but that you gave me gives linking errors ... :? -- Santiago Romero
Re: Upgrading from 2.5.1 to 2.5.4 (sasl error????).
Are you absolutely sure that you need SASL1 and not SASL2? Please check what versions of sasl.h are installed on your system. It could be that an incompatible version is used during compilation. Yes, I need it. I don't have available SASL2 and when I tried to download and compile sasl2 in such an old system I had real problems with other sasl-compiled applications. I must continue using SASL1... Is that a RedHad or Fedora system? Debian Woody (quite old, Debian 2.2). -- Santiago Romero
Re: Upgrading from 2.5.1 to 2.5.4 (sasl error????).
make makefiles CCARGS=-DUSE_SASL_AUTH -DUSE_CYRUS_SASL -lsasl make That is not the correct syntax. See the INSTALL file. What's wrong? The -lsasl statement? In the INSTALL file I see you use single quotation marks instead of double. Besides of that, what I'm doing wrong? Thanks. PS: It compiled and worked with the -DUSE_SASL_AUTH -DUSE_CYRUS_SASL -lsasl ... just luck? -- Santiago Romero
