Notes for setting up a new virtual server at 1&1

Been a long time 1 and 1 customer, moving off a creaky old dedicated machine to a VPS. It’s not quite all configured to work out of the box. This is CentOS 7 & Plesk 12.5. Things to do:

• Modify 1&1 firewall to open port 8447 (needed for Plesk). Open up other ports you need. Probably at least 587 for SMTP submission
• Set the machine name (not clear to what though…I used 1&1’s name as that seemed like a safe choice)
• Add the PTR record (from the cloud network panel) to match the above
• Add a SPF record to the DNS for the IP addresses and machine name (just to cover all the bases)
• Spamhaus picked up on the mail server EHLO name mismatch right away (as I didn’t realize it right away) so check for blacklists (as well as you never know who had the IP before you)
• Install Plesk migration tool (as I was moving from a different machine so needed this to move the domains)
• Decided to only allow FTPS (or SFTP as left SSH open as well)
• vhosts.conf may not have transferred, check it
• Older Gallery 2 install that was migrated to the new system broke in move due to permissions (turn on Gallery debug in it’s conf file to diagnose). Was permissions problem on gdata
• System won’t have gcc, etc. See http://www.scalescale.com/tips/nginx/install-gcc-development-tools-centos-7/
• mailman is 2.1.15 which lacks a workaround for the (awful) DMARC that some big sites run. Looking to install current mailman 2.1.23. python-devel is needed (along with normal gcc, etc.)
  • Upgrade directions: https://wiki.list.org/DOC/4.80%20How%20do%20I%20upgrade%20from%20Mailman%202.1.x%20to%20a%20later%20Mailman%202.1.y%3F
  • Build directions: https://www.gnu.org/software/mailman/mailman-install/building.html
  • Build new mailman

  • ./configure --prefix=/usr/lib/mailman --with-var-prefix=/var/lib/mailman --with-cgi-gid=apache

    • the gid would seem to need to be apache, even though in the older install from Plesk I see files  owned by root. Not sure I understand exactly who’s doing what, but if gid is root you get an error saying the script is being run as apache. The defaul uid is mailman, which is correct for this install.

  • make

  • (stop mailman)

  • make install

  • (start mailman)
  • and it dies on use: IOError: [Errno 13] Permission denied: ‘/var/lib/mailman/logs/error’
  • change that file owner to apache, and later I just made it o+rw as at this point who cares. But fails still IOError: [Errno 13] Permission denied: ‘/var/lib/mailman/lists/list-test/config.pck
  • and there’s still something not right, though the admin interface worked for a bit. Looks like the list dirs in /var/lib/mailman/lists are the cause, but not clear what the answer is. On the old system the dirs are chown root and the files are chown mailman, but that was Plesk 11. But cgi-id of root is definitely wrong. Tried this SELinux related fix but no difference: https://wiki.list.org/DOC/SELinux%20errors%20after%20upgrade%20-%20RedHat
  • anyhow, just run mailman’s check_perms -f to fix the stuff.

gmail and TLS problem with qmail or postfix on Plesk systems

I fixed this once in June but never wrote it down. It seems to have broken again.  Here’s the original notes I had below.

(and an additional reminder: most ISPs are going to block port 25 so you need to telnet from some place with a real internet connection)

Bit of self followup to the original post below.

Testing via telent:
ehlo foo.com
250-u########.com
250-AUTH=LOGIN CRAM-MD5 PLAIN
250-AUTH LOGIN CRAM-MD5 PLAIN
250-STARTTLS
250 8BITMIME
starttls
454 4.3.3 TLS not available

In looking for answers one common theme was that /var/qmail/control/servercert.pem must be “bad” but as noted below changing it didn’t make a difference. I’ve now also noted that *removing* it doesn’t make a difference either, and qmail doesn’t seem to create any error messages.

My system is totally stock. So it seems like the default Plesk install of qmail has a broken TLS implementation? Seems unlikely. I have no idea where problem might be.

========================================================================================
About 3 weeks ago I started noticing that email from gmail users was not making it through the server. I think it’s some sort of TLS problem but I’m not clear as to what changed and/or how to fix it.

Plesk 10.2.0 with psa-qmail 1.03-cos5.build1011110330.18

My server reports:
250-AUTH=LOGIN CRAM-MD5 PLAIN
250-AUTH LOGIN CRAM-MD5 PLAIN
250-STARTTLS
250 8BITMIME

but if I trace the the google/qmail exchange I see this:
30811] select mask – CLT-RCV CLT-SND SRV-RCV
30811] >Client: 454 4.3.3 TLS not available

after some searching I found this:
http://www.google.com/support/forum/p/gm…f1789f768&hl=en

and following the same steps as in that post it would appear /var/qmail/control/servercert.pem has a problem as when I try
openssl verify servercert.pem
I get
error 20 at 0 depth lookup:unable to get local issuer certificate

Following the references to here to create a new one:
http://forum.parallels.com/showthread.php?t=7113

but when I test SSL on port 25 it I still get the same error message:
8982:error:140770FCSL routinesSL23_GET_SERVER_HELLO:unknown protocol:s23_clnt.c:475:

And how did I fix it? GFQ, as the only notes I made was:

I switched from qmail to postfix as the MTA. However the same TLS problem was showing up. However, unlike qmail, with postfix I could actually figure out how to shut off TLS.

So now I seem to need to fix it again, and this time I’ll make a note about what postfix file you edit to disable TLS. I suspect an upgrade of Plesk changed some settings, that seems to happen sometimes…and I forgot to backup /etc before starting this last time around.

Just for the record, same problem as before:

ehlo foo.com
250-u######.com
250-SIZE 10240000
250-ETRN
250-STARTTLS
250-AUTH PLAIN LOGIN DIGEST-MD5 CRAM-MD5
250-XFORWARD NAME ADDR PROTO HELO SOURCE
250-ENHANCEDSTATUSCODES
250-8BITMIME
250 DSN
starttls
454 4.3.3 TLS not available

Some links on the topic:
http://serverfault.com/questions/129771/how-to-disable-tls-in-postfix
http://www.postfix.org/TLS_README.html

so in main.cf find/edit this section:

smtpd_tls_security_level = none # was may
smtpd_use_tls = yes
smtp_tls_security_level = may
smtp_use_tls = no

Don’t buy Watchguard products

Call it a review, call it opinion, call it the truth…

Overpriced pieces of steaming dung they be…yes, I’m running on a “old” Firebox but I’ve finally hit my limit with them…whole reason we bought was because they promised software upgrades. Soooo when we needed to upgrade to add QoS the answer was “you need to buy new hardware, we don’t support those (2 year old) ones!”

And today I spent lots of time baffled as to why one system all of the sudden lost connectivity outside of the local area. Answer – the firebox “user” count is based on every address it’s ever handed out, and that went over 12 users so it just shuts off any “new” user. WTF it shouldn’t even limit just plain old NAT – I always thought the user limit was something tied to the VPN use.

And their VPN sucks. So no other way to describe it.

So while it all looked good on paper, the reality is they are a bad deal.

So when some says Watchguard just so no.

Verizon picture quality TBS

While watching the Red Sox get beat up bad by the Rays the past two days, I can’t help but notice how absolutely awful the (standard def) picture quality is with Verizon FIOS (viewed on a 42″ Westinghouse LCD).  Most of the time I’m only slightly bothered by the bad quality, but for whatever reason (maybe it’s TBS?) the artifacts from an overcompressed picture are just off the scale.  Unfortunately it’s not being broadcast OTA so I can’t compare.

Some of the later games seemed better. Still the quality isn’t anywhere near what “digital” quality should be.