On Sat, Jun 4, 2016 at 12:50 PM, sebb <[email protected]> wrote: > On 4 June 2016 at 17:33, Sam Ruby <[email protected]> wrote: >> On Sat, Jun 4, 2016 at 8:48 AM, sebb <[email protected]> wrote: >>> On 3 June 2016 at 19:33, Sam Ruby <[email protected]> wrote: >>>> This weekend I plan to update the DNS records to make whimsy.apache.org >>>> point to whimsy-vm3 instead of resolving (through the proxy) to whimsy-vm2. >>>> Once those changes are live: >>>> >>>> 1) whimsy2.apache.org can be used to access whimsy-vm2. You will likely >>>> get >>>> a certificate error as the hostname will not match the certificate. >>>> >>>> 2) whimsy.apache.org can be used to access whimsy-vm3. Again there will >>>> likely be a certificate error initially until I go through and re-request a >>>> certificate from letsencrypt. Should I run into problems, I may need to >>>> back the DNS changes out until I resolve the problem. >>> >>> Is there a reason why the hosts use their own specific certificates >>> rather than reusing the generic *.apache.org one? >>> That would work for all the host names. >> >> The infrastructure team tightly controls who has access to the >> wildcard certificate... if it got out, people could create >> man-in-the-middle attacks fairly easily. What this means is that the >> infrastructure team limits who can have sudo access to machines on >> which this certificate exists. While I could argue for to treat >> whimsy-vm* as an exceptional case, I would rather that these machines >> be considered as much as possible as vanilla project vms. > > OK understood. > > I guess that is why some machines use proxies; the proxy hosts can be > carefully controlled whilst still allowing the cert to be used for > less restricted hosts. > > But as we found out, the performance of the proxy is inadequate for > use with Whimsy.
I'm not convinced that it was the proxy's fault. I'm more inclined to blame the subnetwork on which whimsy-vm2 was placed. That subnetwork hosts machines that use high internal bandwidth doing things like backups. Presumably the backup commands deal with things like transient network errors, but higher level applications (e.g., svn, ldap, httpd) don't appear to do so quite as well. What that meant is that we would see dropped packets, which would manifest itself as things like timeouts and errors reported by the proxy server. I'm hopeful that the new server won't see any of these problems, at least not with the frequency that we have been seeing those issues. Time will tell. - Sam Ruby >> There already is a second project VM that is looking into using >> letsencrypt this way: >> >> https://issues.apache.org/jira/browse/INFRA-11960 >> >>>> 3) whimsy3.apache.org will continue to be able to access whimsy-vm3. >>>> >>>> - Sam Ruby >> >> - Sam Ruby
