Bug report for 10.3.5 [consolidated]

[cepheid]

To continue the tradition of having a common place for bug reports in PPCP, here is the current list of known bugs in 10.3.5 that we users are strongly recommending be fixed (either with hotfix or in the next version). If you have a specific bug, please post here or PM me and I will include it. If you have a workaround/fix for the bug, even better.

(New) Bugs for 10.3.5:

1. SSL certificate-signing request (CSR) generation for server fails with error: "Required field(s) missing : Key Length, Validity period." For server-wide CSR, these fields do not exist, and the CSR can therefore not be generated via the control panel. (See this thread for discussion.)

WORKAROUND: Use genkey to manually create a key and CSR, as follows:

Insert code here

Recommendation to Parallels: Include Key Length and Validity Period fields in the server-wide SSL CSR generation page.

[cepheid]

(Legacy) Bugs from 10.3.4 not yet fixed:

A. (Added 17 Apr. 2009) After the upgrade, /var/lib/mysql is owned by root, causing problems for phpMyAdmin. /var/lib/mysql must be owned by user 'mysql' for proper functioning of phpMyAdmin. With the current version of mysql, root ownership of /var/lib/mysql is not required for security; users are prevented from adding databases via circumvention of the control panel through the mysql permissions granted to the user (specifically, users do not have "create" permissions). (See this thread for more discussion.) (N.B. Parallels reports that this did not seem to be a problem during testing... I'll mark this as "fixed" when I receive confirmation.)

FIX: Run the following while logged in as root:

replace "root.mysql" "mysql.mysql" -- /etc/init.d/mysqld_app_init
service mysqld restart

Recommendation to Parallels: Ensure that /var/lib/mysql is owned by user 'mysql.'


B. (Added 20 Apr. 2009) Link and logo on the control panel login page point back to Parallels' website and are not customizable; links/logos should be customizable by the user (e.g. to include user logo and point back to user's website).

WORKAROUND: If desired, turn off display of Parallels' logo and link via:

echo "table.login-header{display:none;}" >> /usr/lib/ensim/frontend/static/css/login.css

Recommendation to Parallels: Allow admins to replace BOTH link and logo with custom entries.


C. (Added 17 May 2009) SSL directives may be missing from httpd conf file for new sites, so SSL does not work. (Note: this is unconfirmed; some users report success, some do not.) This may be caused by Parallels incorporating a buggy fix for the "CP redirect to hostname instead of IP" bug (see this thread), but that's just a guess.

WORKAROUND: Manually edit /etc/httpd/conf/virtual/siteN to include SSL directives, but this is lost after editing a site.
WORKAROUND 2: Create an editVirtDomain.sh that edits the appropriate /etc/httpd/conf/virtual/siteN to include the SSL directives.
WORKAROUND 3: Create /usr/lib/ensim-python/site-packages/vh3/custom/openssl.py with appropriate commands to add the SSL directives back in.


D. (Added 18 May 2009) A python bug prevents the importing of certain sites on systems with python 2.4, purportedly because of filename collisions between the imported site and the default FST.

FIX: Patch python as follows:

cd /tmp
wget http://bugs.python.org/file2369/tarfile.patch
cd /usr/lib/python2.4/
patch -p0 < /tmp/tarfile.patch

Recommendation to Parallels: Distribute and apply patch (or patched version of python) with future upgrades on systems that use python 2.4.


E. (Added 12 August 2009) On the "Generate SSL Certificate" page, PPCP disallows commas, hyphens, and other punctuation from the City, State, Company, and Organization fields. This is incorrect - the SSL standard allows certain punctuation characters in these fields. If you need to input characters into these fields that are disallowed by PPCP, the certificate and/or CSR must be generated manually. (See discussion in this thread.)

WORKAROUND: Manually generate the CSR and self-signed SSL certificate... you must do this as root:

# replace "domain.com" with the appropriate domain for your site.
cd /home/virtual/domain.com/etc/httpd/conf/
# Generate the secret server key - do NOT include a passphrase
openssl genrsa –des3 –out ssl.key/server.key 1024
# Generate the CSR - do NOT include a passphrase
# Note that "Common Name" must be your domain, e.g. domain.com or www.domain.com
openssl req –new –key ssl.key/server.key –out ssl.csr/server.csr 
# Generate a self-signed certificate good for 5 years
openssl x509 -req -days 1825 -in ssl.csr/server.csr -signkey ssl.key/server.key -out ssl.crt/server.crt
service httpd restart

Recommendation to Parallels: Fix the control panel to allow all allowable characters; do not restrict characters that are allowed.


F. (Added 12 August 2009) On the "Generate SSL Certificate" page, PPCP incorrectly labels the Company and Organization fields. Per the SSL/CSR standard, the field labeled "Company" corresponds to the [O] (Organization) field; the field labeled "Organization" corresponds to the [OU] (Organizational Unit) field. (See discussion in this thread.)

WORKAROUND: None. Just be aware of what each field means, so you know what information to put where.

Recommendation to Parallels: Rename Company and Organization fields to Organization and Organizational Unit. Alternatively, flesh out the Help files to make this distinction clear.


G. (Added 13 August 2009) Even if there is a catch-all mail alias defined, mail sent to any daemon user listed in /etc/passwd is delivered to /var/spool/mail/<daemonuser> (e.g. mail to mail@domain is delivered to /var/spool/mail/mail, even if the catch-all alias is defined). Since no "real" user exists - these are just daemons - those mail spools go unmaintained and thus can grow to large sizes entirely unnoticed, unless one knows to look for it. (See full discussion in this thread.) For the workarounds below, none will actually bounce the mail; they will simply ensure that the mail is tossed or delivered someplace so the spool files can't grow unmonitored.

WORKAROUND: Create aliases for all daemon users that point to postmaster, site-blackhole, catch-all (if defined), or anywhere else desired.
WORKAROUND 2: In /var/spool/mail for each site, remove offending mailboxes and symlink to /dev/null; for example:

# As the _domain_ admin:
cd /var/spool/mail
rm mail
ln -s /dev/null mail

Recommendation to Parallels: Modify sendmail configuration to ensure that mail is delivered only to users and aliases defined in the control panel (including catch-all, if defined). Mail to daemon users should be treated like mail to a non-existent user: bounced or delivered to catch-all (if defined).


H. (Added 13 August 2009) Server-wide SSL certificates for HTTPS browsing do not automatically propagate to PPCP's custom apache browser (for interacting with the control panel). Even after installing the SSL certificate via the server admin control panel, the appliance (control panel) does not use that certificate.

WORKAROUND: Manually symlink the valid (purchased) SSL certificates into the appliance's httpd conf directory. If the SSL cert includes an intermediate (chain) cert, the conf file template must also be manually modified:

# As root, do:
cd /usr/lib/ensim/frontend/httpd/conf
ln -sf /etc/pki/tls/private/localhost.key server.key
ln -sf /etc/pki/tls/certs/localhost.crt server.crt
# If you have an intermediate cert too, then run the following 2 commands:
ln -sf /etc/pki/tls/certs/intermediate.crt server-chain.crt
# Make sure to *INCLUDE* the newline in the following command - it is MANDATORY
replace 'conf/server.key' 'conf/server.key
 SSLCertificateChainFile conf/server-chain.crt' -- eplhttpd.conf.template
service epld restart

WORKAROUND 2: Manually edit the appliance httpd conf file to point to the valid (purchased) SSL certificates in their original directory:

# As root, do:
cd /usr/lib/ensim/frontend/httpd/conf
replace 'conf/server.crt' '/etc/pki/tls/certs/localhost.crt' -- eplhttpd.conf.template
replace 'conf/server.key' '/etc/pki/tls/private/localhost.key' -- eplhttpd.conf.template
# If you have an intermediate cert too, then:
# Make sure to *INCLUDE* the newline in the following command - it is MANDATORY
replace 'private/localhost.key' 'private/localhost.key
 SSLCertificateChainFile /etc/pki/tls/certs/intermediate.crt' -- eplhttpd.conf.template
service epld restart

Recommendation to Parallels: Implement workaround #2 permanently, or implement workaround #1 automatically via the control panel. Either way, make it so that an SSL certificate added via the control panel (whether imported or self-generated) also works for the appliance.


I. (Added 13 August 2009) Server-wide SSL certificates for HTTPS browsing do not automatically propagate to the IMAP/POP daemon or to sendmail. Even after installing the SSL certificate via the server admin control panel, IMAP/POP/sendmail will use either no certificate or whatever was there before.

WORKAROUND: Manually copy the web SSL certificates to the PEM files used by IMAP/POP/sendmail; they will need to be concatenated into PEM format:

# As root, do:
cd /etc/pki/tls/certs
cat ../private/localhost.key localhost.crt > imapd.pem
# If you have an intermediate cert, ALSO do:
cat intermediate.crt >> imapd.pem
chmod 600 imapd.pem
ln -sf imapd.pem ipop3d.pem
ln -sf imapd.pem sendmail.pem
service xinetd restart
service sendmail restart
service saslauthd restart

Recommendation to Parallels: Implement this workaround permanently, so that SSL certificates added via the control panel automatically propagate to IMAP/POP/sendmail.

[cepheid]

J. (Added 13 August 2009) imapd/ipopd and sendmail cannot recognize per-site SSL certificates; they only recognize the server-wide SSL certificates in /etc/pki/tls/certs. This means that IMAP/POP/sendmail accessed via hosted domains (e.g. via mail.hosteddomain.com) will return a security error, since the Common Name of the SSL certificate will not match the domain hostname used to access IMAP/POP/sendmail.

WORKAROUND: Accept the security error, which does not affect actual functionality; or
WORKAROUND 2: Access mail through the server domain name, not through the hosted domain name. This will require logging in with the fully-qualified username, user@domain.com or user#domain.com and therefore breaks the "standalone domain" paradigm... however, this will prevent the security error since the server name matches the certificate.

Recommendation to Parallels: Find a way to alter the site-specific IMAP/POP and sendmail configuration files so they can use the site-specific SSL certificates, if available. Obviously, this will work only for IP-based sites, but since name-based site users must already log in with their fully-qualified name, they don't have to worry about the "standalone domain" paradigm interface issue. Since each site already has a site-specific sendmail config file (and I presume also an imap/ipop config file), this should hopefully be easy to implement by simply inserting the appropriate commands into those config files.


K. (Added 2 February 2011) When sending mail out through IP-based domains using the individual domain (e.g. SMTP server is domain.com or mail.domain.com), sendmail's SMTP HELO uses the server name (e.g. server.serverdomain.com); this can cause some mail to be blocked by intermediate and/or receiving mailservers, because it appears that domain.com's mail is being open-relayed through serverdomain.com. It can also cause spam blocklist problems because ANY spammy domain on the server will cause mail from all domains on the server to be blocked (because they are all identified as coming from serverdomain.com, not the individual domains). (See discussion in this thread.)

WORKAROUND: None.

Recommendation to Parallels: For IP-based domains (i.e. where there is a proper reverse DNS entry for domain.com), sendmail should identify itself (during SMTP HELO) as domain.com, not serverdomain.com. Thus, any IP-based domain would appear to have its own mailserver and would not be affected by relaying issues or spam from other domains on the same server. (This solution cannot apply to name-based domains, but it's still acceptable.)


L. (Added 2 February 2011) The SSL directive "SSLCACertificateFile" for individual sites is not utilized properly. When adding an SSL certificate with an intermediate certificate to an individual domain, PPCP uses SSLCACertificateFile to point to the intermediate certificate; this is not correct. The intermediate certificate should be referred by the SSLCertificateChainFile directive, while SSLCACertificateFile should point to the CA root bundle. (See discussion in this thread.)

WORKAROUND: None at this time - possibly creating an editVirtDomain.sh script that will replace the directives, but this has not been tested.

Recommendation to Parallels: Use the correct SSL directives (per above) when referring to the intermediate certificate and the CA root bundle. (The CA root bundle directive should always be present, and should always point to the CA root bundle; the ChainFile directive should be present only when an intermediate certificate exists.)


M. (Added 2 February 2011) Logwatch files include a huge number of "unmatched entries" for certain logs, particularly ipop3d, proftpd, and saslauthd. These fill up Logwatch emails but provide essentially no useful information. ("Unmatched" entries for sshd do provide useful info, but it would be nice to see them cleaned up into a proper reporting format.) (See, for example, this thread.

WORKAROUND: None at this time - the Logwatch rules would need to be edited, but it is unknown and untested as to how to properly do this at this time.

Recommendation to Parallels: Update the Logwatch rules to ignore or at least properly parse these entries into a more compact format.


O. (Added 2 February 2011) Converting an IP-based site with SSL certificates into a Name-Based site (without SSL) does not automatically remove the SSL certificates and therefore apache thinks the site is still an SSL site. This is a waste of resources and could cause potential problems if converting the site back to an IP-based site. (See this thread for more discussion.)

WORKAROUND: Remove the SSL certificate/key files from the affected site, here called "domain.com":

# NOTE: run as root for domain 'domain.com'
rm /home/virtual/domain.com/etc/httpd/conf/ssl.*/*

The site admin can also manually remove these files, with the path modified appropriately (/etc/httpd/conf/ssl.*/* for high-security chroot environments).

Recommendation to Parallels: Automatically delete these SSL files when a site is converted from IP-based to Name-Based.


P. (Added 23 February 2011) Accessing "tilde user" URLs (e.g. mydomain.com/~myuser) betrays the /users/myuser redirect that Apache is doing. This is primarily cosmetic but can cause issues for search engine page ranking. (See this thread for more discussion.)

WORKAROUND: The appropriate RewriteRule in /etc/httpd/conf/virtual/site* can be rewritten to an AliasMatch rule using custom services configuration files (e.g. usr/lib/ensim-python/site-packages/vh3/custom/apache.py & openssl.py). The virtual/site* files can be edited manually for each site, but this will be overwritten when the sites are edited. (No *.py solution has yet been generated; it will be posted here if/when one exists.)

Recommendation to Parallels: Permanently replace the appropriate RewriteRule line with an appropriate AliasMatch rule - as given in the discussion thread - in the apache.pyc and openssl.pyc files.

[cepheid]

- Reserved for future use -

[tulaweb]

Here's what I did as my workaround for 10.3.5 bug #1

yum install crypto-utils
genkey serverhostname.com
cd /etc/pki/tls/private
mv localhost.key localhost.key.bkup
cp serverhostname.com.key localhost.key
cd /etc/pki/tls/certs/
mv localhost.crt localhost.crt.bkup

Use the CSR to get a cert from the authority of your choice.
Import it through the control panel.
follow one of the workarounds from Item "G" in (Legacy) Bugs from 10.3.4

[cepheid]

Here's what I did as my workaround for 10.3.5 bug #1

It's not necessary to install a new package... you can generate the CSR by an appropriate call to openssl, the same way that PPCP does it. I just need to get around to finding that command.

[tulaweb]

It's not necessary to install a new package... you can generate the CSR by an appropriate call to openssl, the same way that PPCP does it. I just need to get around to finding that command.

See the workaround for bug E above for another way. I did it the way I did because I had the instructions laying around and it works but there are several ways to skin the cat.

[Penguin-uk]

SinuP, I personally wouldn't consider this to be a bug at this stage (from the subject of this thread) without knowing how it was caused. I've upgraded about 30 servers to 10.3.5 and not seen this happen on any of them. I've answered your other copy of this post in the other thread however.

[cepheid]

From reading the release notes, it would appear that bugs 1, F, L, and P were fixed in 10.3.6. Can someone who has upgraded please verify this? In particular, a poster in this thread seems to think Bug #1 is still around in 10.3.6.

I'm going to start a new consolidated buglist for 10.3.6, and it'd be nice to know which ones from here were actually fixed. I'm guessing 1, F, L, and P from the release notes, but would like confirmation from someone who's installed it (I haven't).

Also, can people verify that Exchange clients (e.g. Outlook) no longer have issues checking/sending mail, as they did under 10.3.4?

Thanks!

[SeanieR]

Seems like 1 and F are fixed anyway. Here is a screenshot of the Server SSL cert page to generate.
Created the CSR no problem for me.

Seanie

[SeanieR]

Just noticed something in 10.3.6 and have never come across it in previous versions.
When I applied the SSL Cert and Interm Cert on the CP Server Interface, the cert didnt look like it saved, although it said it did.
Looking at /etc/pki/tls/certs/ There is a localhost.crt file with a timestamp of when I created the CSR and now a localhost.crt.new with timestamp of when i applied the cert.
renaming localhost.crt.new to localhost.crt and restarting httpd and all fine now, but this never happened in previous versions.
Anyone else seeing this?

oh, and may have been reported before , but you need to save the cert and interm cert Twice as, the first time it gives and error about the interm ssl config and then works second time straight after.

Seanie

[cepheid]

Here is a screenshot of the Server SSL cert page to generate.
Created the CSR no problem for me.

Is this for a site, or for the server as a whole? I understood it was fixed for sites but not for the server. Can you confirm?

[SeanieR]

Hi
That screenshot was for the server, not a site.

Seanie

[cepheid]

Can anyone else verify whether L and P were fixed, and/or any other bugs?
Thanks.