Postfix problems after update

One more thing to add to my last post:

After the update, I also cannot send email. The error logs show this:

Oct 25 11:55:19 mailhost postfix/smtpd[10671]: warning: SASL authentication failure: cannot connect to Courier authdaemond: Permission denied
Oct 25 11:55:19 mailhost postfix/smtpd[10671]: warning: unknown[xx.xx.xx.xx]: SASL LOGIN authentication failed: generic failure

With a quick google I found a solution:

chmod o+x /var/spool/authdaemon

That solved it for me!

Courier SSL problems after update

I posted this message as a comment to the HOWTO I used to configure my mail server:
http://www.howtoforge.com/fedora_virtual_postfix_mysql_quota_courier

I've been running a mail server built using this HOWTO for a while now. I recently updated the entire server with a "yum update". Email clients could no longer connect to the server via POP3 or IMAP if SSL was enabled. I was getting errors like this in the error log:

Oct 23 13:19:32 mailhost pop3d-ssl: couriertls: connect: error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version number
Oct 24 10:36:13 mailhost imapd-ssl: couriertls: connect: error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version number

I was able to fix this by editing the following files:

/usr/lib/courier-imap/etc/imapd-ssl
/usr/lib/courier-imap/etc/pop3d-ssl

I changed the TLS_PROTOCOL setting from SSL3 to SSL23 in both of these files:

TLS_PROTOCOL=SSL23

Then, I restarted courier-authlib and courier-imap and things were working again:

service courier-authlib restart
service courier-imap restart

The following commands were helpful in testing things out:

openssl s_client -connect mailhost:993 -state -debug
openssl s_client -connect mailhost:995 -state -debug
openssl s_client -ssl2 -connect mailhost:993 -state -debug
openssl s_client -ssl3 -connect mailhost:993 -state -debug
openssl s_client -ssl2 -connect mailhost:995 -state -debug
openssl s_client -ssl3 -connect mailhost:995 -state -debug

I hope this helps someone else, as I spent way too much time trying to solve it.

Installing and configuring BIND/named

This Configuring DNS HOWTO was very helpful for installing a new bind server.

Also, their Linux firewall/iptables HOWTO was helpful as well.

Set up Apache as a reverse proxy

Since my client's VPS doesn't have enough memory to run a servlet engine with their app, and we don't have time to move to a bigger VPS, I'm looking for interim solutions. One idea is to use their Apache server as a proxy server to an external server.

Here's the situation. Their website has an SSL certificate with www.company.com in the domain. We can't move their site, and the SSL cert couldn't be used with a subdomain. So, if I set up a server somewhere else at say app.company.com, I could add the following to their SSL site's VirtualHost:

ProxyRequests Off

Order deny,allow
Allow from all

ProxyPass /app http://app.company.com/app
ProxyPassReverse /app http://app.company.com/app

This seems to work, but I haven't tested it fully yet. I am having issues with image paths and such, but that is to be expected.

Apache provides details of using mod_proxy.

There are also details about other options for connecting to Tomcat with various means, including using iptables, mod_jk2, and mod_proxy.

Finding memory usage in Virtuozzo VPS

I have a client who has a VPS at iPowerWeb. I can't say that I'm very thrilled with iPowerWeb, especially after finding javascript trojans scattered on pages throughout their site.

Anyway, I needed to figure out how much memory is available to their VPS. I found some information here about it. I've consolidated the pertinent information below:

Assuming your VPS provider is using UBC memory managment instead of SLM, use this command to get memory details:
cat /proc/user_beancounters

It's not the version, it depends on if your provider is using SLM or UBC memory management for your VPS. If SLM you'll see virtual memory available to your VPS, if UBC you'll see the memory available to the entire node. In this case, the VPS is using UBC (user_beancounters would have some parameters set to unlimited if using SLM).

privvmpages 102169 102687 131072 139264 150550
vmguarpages 0 0 67584 2147483647 0

This means you have 264MB guaranteed memory, 512MB burstable memory. You get these by dividing the number by 1024 (to convert to MB) and multiplying by 4 (as they're measured in 4KB pages on VZ). You should be concerned about the 150550 failcnt in the privvmpages parameter. This means that your VPS is running out of memory.

Here's my client's output:

[root@localhost conf]# cat /proc/user_beancounters
Version: 2.5
uid resource held maxheld barrier limit failcnt
377: kmemsize 4721767 4740068 16384000 18022400 0
lockedpages 0 0 4096 4096 0
privvmpages 63893 63930 262144 292912 1
shmpages 5935 5935 131072 131072 0
dummy 0 0 0 0 0
numproc 49 49 400 400 0
physpages 19182 19188 0 2147483647 0
vmguarpages 0 0 36864 2147483647 0
oomguarpages 19182 19188 18432 2147483647 0
numtcpsock 18 18 600 600 0
numflock 11 11 200 210 0
numpty 1 1 48 48 0
numsiginfo 0 0 512 512 0
tcpsndbuf 225836 225836 4300800 6144000 0
tcprcvbuf 351884 351884 4300800 6144000 0
othersockbuf 11180 11180 3072000 5529600 0
dgramrcvbuf 0 0 524288 524288 0
numothersock 16 16 600 600 0
dcachesize 175522 177878 4192304 4317184 0
numfile 2041 2050 8192 8192 0
dummy 0 0 0 0 0
dummy 0 0 0 0 0
dummy 0 0 0 0 0
numiptent 14 14 128 128 0


So, I calculate that the VPS has 1024MB of burstable memory and only 144MB of guaranteed memory. Not nearly enough to run apache, mysql, and a java servlet engine...

Now, what I don't know for sure is which of those numbers shows the current memory usage.