Re: [qmailtoaster] pop3 connection when sending is too slow
hmmm i don't know what is happening. The slow response when sending emails started again. Restarting all services and including the machine did not help. It seems that the problem is intermittent. Can we please try to continue on getting the culprit? Could it be my tcp.smtp? 127.:allow,RELAYCLIENT=,DKSIGN=/var/qmail/control/domainkeys/%/private,RBLSMTPD=,NOP0FCHECK=1,QMAILQUEUE=/var/qmail/bin/simscan :allow,BADMIMETYPE=,BADLOADERTYPE=M,CHKUSER_RCPTLIMIT=50,CHKUSER_WRONGRCPTLIMIT=10,QMAILQUEUE=/var/qmail/bin/simscan,DKSIGN=/var/qmail/control/domainkeys/%/private,NOP0FCHECK=1 Do I really need to add my local address 192.168.0..5 of the server here? Though this is added I'm still connecting using the IP address from the outside connection that uses :allow,BADMIMETYPE=,BADLOADERTYPE=M etc. Thank you again. Tom Eric Shubert wrote: http://wiki.qmailtoaster.com/index.php/Certificate There's a little bit about self signed certs at the end of the page. If you need more than that, there are many web pages about creating a self signed cert. Any one should do. The certificate is the same as would be used by apache. Google is your friend. ;) Tom Manliclic wrote: I'm using Thunderbird. Can you send me a link to follow in doing a self signed certificate if it is required in my setup? Eric Shubert wrote: Jake Vickers wrote: Tom Manliclic wrote: Yes it seem to be responding well now after I did a qmailctl cdb without actually changing anything. But I still have this prompt and smtp slow to respond sometimes but atleast not as slow as before. Could it be that there are several who are trying to connect? How will I be able to check on how many active connections I have for smtp and pop3? You'll need to configure Outlook to not use SSL, or purchase a cert accredited by Outlook. I'm not so sure about that Jake. ;) I've set up Outlook'03 (and '07 I believe) to use SSL with SMTP on the submission (587) port. I presume it's actually doing TLS. The certificate isn't the default localhost cert, but it is essentially a self-signed cert (signed by CA-Cert.org). IIRC I did have to manually add the CA cert chain to each machine though, which might not be practical for some folks. So a self-signed cert can be used with Outlook. A purchased cert is much easier to set up though, especially on anything but a small scale.
Re: [qmailtoaster] pop3 connection when sending is too slow
The first line below, starting with 127.: will be used by any webmail operations on the server. Currently, the next line, starting with only a :, will be used by all other processes. If you want to speed up submission of emails for local clients, you could add a line starting (for example) with 192.128.0.:, otherwise identical to the 127: line, which would allow local clients to send email without any concern to Chkuser for the number of connections at one time, etc. (You would want to add the DKSIGN segment there, so that all outgoing mail gets signed.) But that's making some assumptions about your network topography that I'm not sure are correct. In short, the addresses in tcp.smtp are all about the addresses of other machines connecting to your QMT, not the address of your QMT. Roxanne On May 10, 2008, at 5:51 AM, Tom Manliclic wrote: hmmm i don't know what is happening. The slow response when sending emails started again. Restarting all services and including the machine did not help. It seems that the problem is intermittent. Can we please try to continue on getting the culprit? Could it be my tcp.smtp? 127.:allow,RELAYCLIENT=,DKSIGN=/var/qmail/control/domainkeys/%/ private,RBLSMTPD=,NOP0FCHECK=1,QMAILQUEUE=/var/qmail/bin/ simscan :allow,BADMIMETYPE=,BADLOADERTYPE=M,CHKUSER_RCPTLIMIT=50,CHKUSER _WRONGRCPTLIMIT=10,QMAILQUEUE=/var/qmail/bin/simscan,DKSIGN=/ var/qmail/control/domainkeys/%/private,NOP0FCHECK=1 Do I really need to add my local address 192.168.0..5 of the server here? Though this is added I'm still connecting using the IP address from the outside connection that uses :allow,BADMIMETYPE=,BADLOADERTYPE=M etc. Thank you again. Tom Eric Shubert wrote: http://wiki.qmailtoaster.com/index.php/Certificate There's a little bit about self signed certs at the end of the page. If you need more than that, there are many web pages about creating a self signed cert. Any one should do. The certificate is the same as would be used by apache. Google is your friend. ;) Tom Manliclic wrote: I'm using Thunderbird. Can you send me a link to follow in doing a self signed certificate if it is required in my setup? Eric Shubert wrote: Jake Vickers wrote: Tom Manliclic wrote: Yes it seem to be responding well now after I did a qmailctl cdb without actually changing anything. But I still have this prompt and smtp slow to respond sometimes but atleast not as slow as before. Could it be that there are several who are trying to connect? How will I be able to check on how many active connections I have for smtp and pop3? You'll need to configure Outlook to not use SSL, or purchase a cert accredited by Outlook. I'm not so sure about that Jake. ;) I've set up Outlook'03 (and '07 I believe) to use SSL with SMTP on the submission (587) port. I presume it's actually doing TLS. The certificate isn't the default localhost cert, but it is essentially a self-signed cert (signed by CA-Cert.org). IIRC I did have to manually add the CA cert chain to each machine though, which might not be practical for some folks. So a self-signed cert can be used with Outlook. A purchased cert is much easier to set up though, especially on anything but a small scale. - QmailToaster hosted by: VR Hosted http://www.vr.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[qmailtoaster] No Match for argument: perl-DB_File
I've got some perl conflicts that are giving me transaction check errors when trying to upgrade with qtp-newmodel. If I exclude perl* in my rpmforge repo then qtp-newmodel runs through to completion instead of failing (although I haven't actually done the upgrade yet.) So while it doesn't fail anymore, it does complain about the following (before going on to apparently build everything successfully in the sandbox): No Match for argument: perl-DB_File No Match for argument: perl-Mail-DomainKeys No Match for argument: perl-Mail-SPF-Query No Match for argument: perl-MIME-Base64 No Match for argument: perl-Net-SMTP Nothing to do Can anyone give me an idea about the result of upgrading without these packages? - QmailToaster hosted by: VR Hosted http://www.vr.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [qmailtoaster] pop3 connection when sending is too slow
That's a nice way to explain it, Roxanne. Intermittent problems such as this sure feel like something network related to me. Have you obtained and run Jake's script that checks RBLs periodically? Can you try using port 587 for submitting mails from a client and see if there's slowness there too? If so, that would eliminate RBLs from the picture, and tend to point towards DNS in general. If 587 is not slow, that would likely point to an unresponsive RBL. Roxanne Sandesara wrote: The first line below, starting with 127.: will be used by any webmail operations on the server. Currently, the next line, starting with only a :, will be used by all other processes. If you want to speed up submission of emails for local clients, you could add a line starting (for example) with 192.128.0.:, otherwise identical to the 127: line, which would allow local clients to send email without any concern to Chkuser for the number of connections at one time, etc. (You would want to add the DKSIGN segment there, so that all outgoing mail gets signed.) But that's making some assumptions about your network topography that I'm not sure are correct. In short, the addresses in tcp.smtp are all about the addresses of other machines connecting to your QMT, not the address of your QMT. Roxanne On May 10, 2008, at 5:51 AM, Tom Manliclic wrote: hmmm i don't know what is happening. The slow response when sending emails started again. Restarting all services and including the machine did not help. It seems that the problem is intermittent. Can we please try to continue on getting the culprit? Could it be my tcp.smtp? 127.:allow,RELAYCLIENT=,DKSIGN=/var/qmail/control/domainkeys/%/private,RBLSMTPD=,NOP0FCHECK=1,QMAILQUEUE=/var/qmail/bin/simscan :allow,BADMIMETYPE=,BADLOADERTYPE=M,CHKUSER_RCPTLIMIT=50,CHKUSER_WRONGRCPTLIMIT=10,QMAILQUEUE=/var/qmail/bin/simscan,DKSIGN=/var/qmail/control/domainkeys/%/private,NOP0FCHECK=1 Do I really need to add my local address 192.168.0..5 of the server here? Though this is added I'm still connecting using the IP address from the outside connection that uses :allow,BADMIMETYPE=,BADLOADERTYPE=M etc. Thank you again. Tom Eric Shubert wrote: http://wiki.qmailtoaster.com/index.php/Certificate There's a little bit about self signed certs at the end of the page. If you need more than that, there are many web pages about creating a self signed cert. Any one should do. The certificate is the same as would be used by apache. Google is your friend. ;) Tom Manliclic wrote: I'm using Thunderbird. Can you send me a link to follow in doing a self signed certificate if it is required in my setup? Eric Shubert wrote: Jake Vickers wrote: Tom Manliclic wrote: Yes it seem to be responding well now after I did a qmailctl cdb without actually changing anything. But I still have this prompt and smtp slow to respond sometimes but atleast not as slow as before. Could it be that there are several who are trying to connect? How will I be able to check on how many active connections I have for smtp and pop3? You'll need to configure Outlook to not use SSL, or purchase a cert accredited by Outlook. I'm not so sure about that Jake. ;) I've set up Outlook'03 (and '07 I believe) to use SSL with SMTP on the submission (587) port. I presume it's actually doing TLS. The certificate isn't the default localhost cert, but it is essentially a self-signed cert (signed by CA-Cert.org). IIRC I did have to manually add the CA cert chain to each machine though, which might not be practical for some folks. So a self-signed cert can be used with Outlook. A purchased cert is much easier to set up though, especially on anything but a small scale. - QmailToaster hosted by: VR Hosted http://www.vr.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- -Eric 'shubes' - QmailToaster hosted by: VR Hosted http://www.vr.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [qmailtoaster] No Match for argument: perl-DB_File
Jim Bassett wrote: I've got some perl conflicts that are giving me transaction check errors when trying to upgrade with qtp-newmodel. If I exclude perl* in my rpmforge repo then qtp-newmodel runs through to completion instead of failing (although I haven't actually done the upgrade yet.) So while it doesn't fail anymore, it does complain about the following (before going on to apparently build everything successfully in the sandbox): No Match for argument: perl-DB_File No Match for argument: perl-Mail-DomainKeys No Match for argument: perl-Mail-SPF-Query No Match for argument: perl-MIME-Base64 No Match for argument: perl-Net-SMTP Nothing to do Can anyone give me an idea about the result of upgrading without these packages? These packages are required by the latest spamassassin. qtp-newmodel attempts to yum install them in order to satisfy that requirement. qtp-newmodel isn't very smart about updating dependent packages though. It simply tries to yum install them. If they've been installed with CPAN, yum (rpm actually) doesn't know about that, so having an rpm installed for them may not be absolutely necessary. qtp-newmodel should probably not terminate if installing these modules is not successful, but should only give a warning that the build of spamassassin-toaster might fail. FWIW, dependency checking rightfully belongs in yum, which will be coming with the next (1.4) toaster release. This part of qtp-newmodel will likely just go away in the future, so we haven't spent much time developing it. Bottom Line, as long as spamassassin-toaster builds ok, you should be good to go, and I wouldn't worry about the perl packages. -- -Eric 'shubes' - QmailToaster hosted by: VR Hosted http://www.vr.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [qmailtoaster] Re: Soft Rejections
An update for everyone who may have been following my difficulties with spamassassin and sa-update. I took the time this afternoon to do the rebuild I'd promised myself I would do. I performed the following steps: qmailctl stop rpm -e --nodeps simscan-toaster-1.3.1-1.3.6 rpm -e --nodeps ripmime-toaster-1.4.0.6-1.3.3 rpm -e --nodeps clamav-toaster-0.93-1.3.18 rpm -e --nodeps spamassassin-toaster-3.2.4-1.3.15 rpmbuild --rebuild --with cnt40 /usr/src/redhat/SRPMS/spamassassin- toaster-3.2.4-1.3.15.src.rpm rpm -Uvh /usr/src/redhat/RPMS/i386/spamassassin- toaster-3.2.4-1.3.15.i386.rpm rpmbuild --rebuild --with cnt40 /usr/src/redhat/SRPMS/clamav- toaster-0.93-1.3.18.src.rpm rpm -Uvh /usr/src/redhat/RPMS/i386/clamav-toaster-0.93-1.3.18.i386.rpm rpmbuild --rebuild --with cnt40 /usr/src/redhat/SRPMS/ripmime- toaster-1.4.0.6-1.3.3.src.rpm rpm -Uvh /usr/src/redhat/RPMS/i386/ripmime- toaster-1.4.0.6-1.3.3.i386.rpm rpmbuild --rebuild --with cnt40 /usr/src/redhat/SRPMS/simscan- toaster-1.3.1-1.3.6.src.rpm rpm -Uvh /usr/src/redhat/RPMS/i386/simscan-toaster-1.3.1-1.3.6.i386.rpm I then su'ed to the shell of vpopmail and ran the --lint -D process to see what I could see. It still looked, first, for configuration files in that dratted /var/ tmp/spamassassin-toaster-root/etc/mail/spamassassin When it found none, it then looked in /etc/mail/spamassassin and loaded the files there. So it succeeded in the test. So I started up qmail. Then I checked the log ... and it was giving me that 'unable to find check_mail' error. Which I've seen often enough in the last week to know what it was and how to make it go away. So I copied my *.pre files from /etc/mail/spamassassin to /var/tmp/spamassassin-toaster- root/etc/mail/spamassassin and then checked the log again, and it is now succeeding. But this means that even having successfully cleaned out all (supposedly) remnants of the old system, and then re-installed, somehow it is still maintaining the call for that directory. I'm up and running. But the underlying problem still exists. I'm wondering what I can do to help troubleshoot this. Would it, for instance, be at all useful to see a script recording of the entire process of each build and installation? Are there some things that I should go hunting for after the uninstallation of packages, to be sure that the problem is cleared out before installing again? Looking for advice and suggestions, Roxanne - QmailToaster hosted by: VR Hosted http://www.vr.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [qmailtoaster] 553 sorry, that domain isn't in my list of allowed rcpthosts (#5.5.3 - chkuser)
Negative sir. I added that line to the end, didn't seem to work either. host server.mydomain.com [XXX.XXX.XXX.XXX]: 553 sorry, that domain isn't in my list of allowed rcpthosts (#5.5.3 - chkuser) Could it be an issue with my DNS not working properly maybe? Or a host file hiccup? Glen From: Jake Vickers [mailto:[EMAIL PROTECTED] Sent: Friday, May 09, 2008 5:31 PM To: qmailtoaster-list@qmailtoaster.com Subject: Re: [qmailtoaster] 553 sorry, that domain isn't in my list of allowed rcpthosts (#5.5.3 - chkuser) Glen Vickers wrote: No I just included the part that I had added. Hers' the full tcp.smtp.. 127.:allow,RELAYCLIENT=,DKSIGN=/var/qmail/control/domainkeys/%/private 192.168.:allow,RELAYCLIENT=,DKSIGN=/var/qmail/control/domainkeys/%/privat e 199.104.125.190:allow,RELAYCLIENT=,DKSIGN=/var/qmail/control/domainkeys/% /private :allow,BADMIMETYPE=,BADLOADERTYPE=M,CHKUSER_RCPTLIMIT=50,CHKUSER_WRONG RCPTLIMIT=10,DKSIGN=/var/qmail/control/domainkeys/%/private For fun, try adding this to the end of your allow line: NOP0FCHECK=1 (that's a zero after the P)
Re: [qmailtoaster] Re: Soft Rejections
The /var/tmp/package-name-root directory is used by the rpmbuild process, and should not exist after a successful build. I don't think the fact that spamassassin looks there for the configuration is a problem as long as it ultimately finds it where it is, in /etc/mail/spamassassin. You su'd to Roxanne Sandesara wrote: An update for everyone who may have been following my difficulties with spamassassin and sa-update. I took the time this afternoon to do the rebuild I'd promised myself I would do. I performed the following steps: qmailctl stop rpm -e --nodeps simscan-toaster-1.3.1-1.3.6 rpm -e --nodeps ripmime-toaster-1.4.0.6-1.3.3 rpm -e --nodeps clamav-toaster-0.93-1.3.18 rpm -e --nodeps spamassassin-toaster-3.2.4-1.3.15 Using the version number(s) is not necessary with most installed packages (exception being those which can have multiple versions installed concurrently such as the kernel). You could have simply run: # rpm -e --nodeps simscan-toaster ripmime-toaster clamav-toaster spamassassin-toaster instead. It shouldn't have hurt to do it the way you did though (ttbomk), as long as these were indeed the versions which were installed. rpmbuild --rebuild --with cnt40 /usr/src/redhat/SRPMS/spamassassin-toaster-3.2.4-1.3.15.src.rpm rpm -Uvh /usr/src/redhat/RPMS/i386/spamassassin-toaster-3.2.4-1.3.15.i386.rpm rpmbuild --rebuild --with cnt40 /usr/src/redhat/SRPMS/clamav-toaster-0.93-1.3.18.src.rpm rpm -Uvh /usr/src/redhat/RPMS/i386/clamav-toaster-0.93-1.3.18.i386.rpm rpmbuild --rebuild --with cnt40 /usr/src/redhat/SRPMS/ripmime-toaster-1.4.0.6-1.3.3.src.rpm rpm -Uvh /usr/src/redhat/RPMS/i386/ripmime-toaster-1.4.0.6-1.3.3.i386.rpm rpmbuild --rebuild --with cnt40 /usr/src/redhat/SRPMS/simscan-toaster-1.3.1-1.3.6.src.rpm rpm -Uvh /usr/src/redhat/RPMS/i386/simscan-toaster-1.3.1-1.3.6.i386.rpm These look ok. Personally, I would have used the -ivh options instead of -Uvh, but -Uvh will install them if they don't exist. -ivh would have failed if they already exist, which I would have wanted it to do, to be sure that they had been removed. Not a big deal. On 2nd look though, I checked the man page about --rebuild option, which says: rpmbuild --rebuild|--recompile SOURCEPKG ... When invoked this way, rpmbuild installs the named source package, and does a prep, compile and install. In addition, --rebuild builds a new binary package. When the build has completed, the build directory is removed (as in --clean) and the the sources and spec file for the package are removed. This seems to indicate that the execution of rpm after the rpmbuild is entirely unnecessary, as the rpmbuild does the install as well as building the binary. Hmmm. I obviously never noticed this before. That would explain why the -U instead of -i is necessary. I'll have to do some testing. The question that this brings to mind is, what happens when a package is updated over itself? I don't know off hand, but imagine that it might cause problems with some configuration files (rpmsave files would be replaced twice and the original lost). Other than that, I don't see a problem off hand, but we should keep this in mind (and probably modify the install and newmodel scripts appropriately). I then su'ed to the shell of vpopmail and ran the --lint -D process to see what I could see. You su'ed to vpopmail? That shouldn't be possible on a stock installation, as the vpopmail user should have /sbin/nologin as the login script. sudo'ing would be safer, as that's closer to the way that spamd is run by supervise. I don't know of a reason why su'ing to vpopmail wouldn't work though, although you need to be careful to usually use the '-' flag when using su. Omitting '-' can produce seemingly mysterious results because the target user's environment isn't set up completely without it (and vpopmail doesn't necessarily have one). It still looked, first, for configuration files in that dratted /var/tmp/spamassassin-toaster-root/etc/mail/spamassassin The /var/tmp/spamassassin-toaster-root is used by the rpmbuild process. It should not exist after the build is done. I wouldn't be concerned with this as long as SA finds the appropriate config files, as apparently it subsequently does. When it found none, it then looked in /etc/mail/spamassassin and loaded the files there. So it succeeded in the test. So I started up qmail. Then I checked the log ... and it was giving me that 'unable to find check_mail' error. Which I've seen often enough in the last week to know what it was and how to make it go away. So I copied my *.pre files from /etc/mail/spamassassin to /var/tmp/spamassassin-toaster-root/etc/mail/spamassassin and then checked the log again, and it is now succeeding. You realize that this is not the correct fix though, right? It appears that the environment that spamd runs in (as a result of the -u option, as specified in the /var/qmail/supervise/spamd/run file) is different than what you're
Re: [qmailtoaster] 553 sorry, that domain isn't in my list of allowed rcpthosts (#5.5.3 - chkuser)
Did you perhaps add the domains using vqadmin? Glen Vickers wrote: Hello all. I’m getting the dredded 553 message out of the blue. I am able to send email using squirrel, however if I try to send email to any address on the 3 domains I have on the server, it fails. My tcp.smtp seems fine for the local and the public IP. 127.:allow,RELAYCLIENT=,DKSIGN=/var/qmail/control/domainkeys/%/private 192.168.:allow,RELAYCLIENT=,DKSIGN=/var/qmail/control/domainkeys/%/private XXX.XXX.XXX.XXX:allow,RELAYCLIENT=,DKSIGN=/var/qmail/control/domainkeys/%/private Where X is my public IP. In the SMTP log I get @40004823c9ac0a7515fc CHKUSER accepted sender: from [EMAIL PROTECTED]:: remote out01.mta.ISP.com:unknown:XXX.XXX.XXX.XXX rcpt : sender accepted @40004823c9de3173d7ec CHKUSER rejected relaying: from [EMAIL PROTECTED]:: remote out01.mta. ISP.com:unknown:XXX.XXX.XXX.XXX rcpt [EMAIL PROTECTED] : client not allowed to relay I get this message from any address trying to send to the email addresses on my server. As you can guess, this is an issue. So my question is, should I add the MTA address of my ISP to the tcp.smtp ? or is there something else that would be blocking email from coming in?? Glen -- -Eric 'shubes' - QmailToaster hosted by: VR Hosted http://www.vr.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [qmailtoaster] Re: Soft Rejections
On May 10, 2008, at 8:28 PM, Eric Shubert wrote: The /var/tmp/package-name-root directory is used by the rpmbuild process, and should not exist after a successful build. I don't think the fact that spamassassin looks there for the configuration is a problem as long as it ultimately finds it where it is, in /etc/mail/spamassassin. You su'd to Roxanne Sandesara wrote: An update for everyone who may have been following my difficulties with spamassassin and sa-update. I took the time this afternoon to do the rebuild I'd promised myself I would do. I performed the following steps: qmailctl stop rpm -e --nodeps simscan-toaster-1.3.1-1.3.6 rpm -e --nodeps ripmime-toaster-1.4.0.6-1.3.3 rpm -e --nodeps clamav-toaster-0.93-1.3.18 rpm -e --nodeps spamassassin-toaster-3.2.4-1.3.15 Using the version number(s) is not necessary with most installed packages (exception being those which can have multiple versions installed concurrently such as the kernel). You could have simply run: # rpm -e --nodeps simscan-toaster ripmime-toaster clamav-toaster spamassassin-toaster instead. It shouldn't have hurt to do it the way you did though (ttbomk), as long as these were indeed the versions which were installed. I did rpm -qa | grep toaster to get the numbers, and uninstalled what I found there. They were correctly uninstalled. rpmbuild --rebuild --with cnt40 /usr/src/redhat/SRPMS/spamassassin-toaster-3.2.4-1.3.15.src.rpm rpm -Uvh /usr/src/redhat/RPMS/i386/spamassassin-toaster-3.2.4-1.3.15.i386.rpm rpmbuild --rebuild --with cnt40 /usr/src/redhat/SRPMS/clamav-toaster-0.93-1.3.18.src.rpm rpm -Uvh /usr/src/redhat/RPMS/i386/clamav- toaster-0.93-1.3.18.i386.rpm rpmbuild --rebuild --with cnt40 /usr/src/redhat/SRPMS/ripmime-toaster-1.4.0.6-1.3.3.src.rpm rpm -Uvh /usr/src/redhat/RPMS/i386/ripmime- toaster-1.4.0.6-1.3.3.i386.rpm rpmbuild --rebuild --with cnt40 /usr/src/redhat/SRPMS/simscan-toaster-1.3.1-1.3.6.src.rpm rpm -Uvh /usr/src/redhat/RPMS/i386/simscan- toaster-1.3.1-1.3.6.i386.rpm These look ok. Personally, I would have used the -ivh options instead of -Uvh, but -Uvh will install them if they don't exist. -ivh would have failed if they already exist, which I would have wanted it to do, to be sure that they had been removed. Not a big deal. On 2nd look though, I checked the man page about --rebuild option, which says: rpmbuild --rebuild|--recompile SOURCEPKG ... When invoked this way, rpmbuild installs the named source package, and does a prep, compile and install. In addition, --rebuild builds a new binary package. When the build has completed, the build directory is removed (as in --clean) and the the sources and spec file for the package are removed. This seems to indicate that the execution of rpm after the rpmbuild is entirely unnecessary, as the rpmbuild does the install as well as building the binary. Hmmm. I obviously never noticed this before. That would explain why the -U instead of -i is necessary. I'll have to do some testing. The question that this brings to mind is, what happens when a package is updated over itself? I don't know off hand, but imagine that it might cause problems with some configuration files (rpmsave files would be replaced twice and the original lost). Other than that, I don't see a problem off hand, but we should keep this in mind (and probably modify the install and newmodel scripts appropriately). I can obviously only speak to my own experience. But when I do an rpmbuild --rebuild, the binary RPM is created. It is not subsequently installed until I do the rpm command independently (the next line). I'll gladly run the intermediary commands next time, and record things in an script so that we can be 100% sure. I then su'ed to the shell of vpopmail and ran the --lint -D process to see what I could see. You su'ed to vpopmail? That shouldn't be possible on a stock installation, as the vpopmail user should have /sbin/nologin as the login script. sudo'ing would be safer, as that's closer to the way that spamd is run by supervise. I don't know of a reason why su'ing to vpopmail wouldn't work though, although you need to be careful to usually use the '-' flag when using su. Omitting '-' can produce seemingly mysterious results because the target user's environment isn't set up completely without it (and vpopmail doesn't necessarily have one). Specifically, the command I used - suggested by Jaime earlier in this thread - was: su - vpopmail -s /bin/bash Which doesn't ask me for a password, and takes care of giving me a shell to work with despite the fact that vpopmail isn't allowed to login normally. It still looked, first, for configuration files in that dratted /var/tmp/spamassassin-toaster-root/etc/mail/spamassassin The /var/tmp/spamassassin-toaster-root is used by the rpmbuild process. It should not exist after the build is done. I wouldn't be
