[SERVER UPDATE] Moving clang, clang-analyzer, libcxxabi, libcxx ... websites to new server

All,

The following websites will be moving to a new web server in the next few days:
clang.llvm.org
clang-analyzer.llvm.org
compiler-rt.llvm.org
dragonegg.llvm.org
klee.llvm.org
libclc.llvm.org
libcxx.llvm.org
libcxxabi.llvm.org
lldb.llvm.org
lld.llvm.org
openmp.llvm.org
polly.llvm.org
vmkit.llvm.org

Please note that llvm.org proper is NOT moving at this time. Therefore SVN, Bugzilla, ViewVC, and all the llvm.org/* webpages will remain on that server. I will be updating on this in a separate email.

How does this impact you?
You may see a very short downtime (< 1 hour) when the switch is made. This is most likely due to the DNS switch. I will notify the list when all websites listed have been moved. Since this does not involve SVN, the downtime is hopefully tolerable.

Are you fixing the SSL problem?
Yes. The new server will have SSL support for all websites and have an updated certificate.

What about the website auto-update?
Currently, the web sites all automatically update via post-commit hook for SVN. We have temporarily set up an alternative method and websites will update every 30 minutes.

What about website documentation generation?
There are 3 scripts that generate documentation on the web server. For doxygen, it will continue to update daily. For sphinx documentation, it will update every hour instead of immediately after a commit.

In order to increase visibility into the server, these scripts have been enhanced to now email a list to indicate success or failure. You can either subscribe to the list or check the archives if you have concerns about documentation not being updated:
http://lists.llvm.org/cgi-bin/mailman/listinfo/www-scripts

Why are you doing this?
We want to increase the reliability, stability, and speed of the LLVN services. The current machine is outdated and is not set up for our current needs.

If you have any questions, please do not hesitate to ask.

Thank you,
Tanya

All,

The following websites will be moving to a new web server in the next few days:
clang.llvm.org
clang-analyzer.llvm.org
compiler-rt.llvm.org
dragonegg.llvm.org
klee.llvm.org
libclc.llvm.org
libcxx.llvm.org
libcxxabi.llvm.org
lldb.llvm.org
lld.llvm.org
openmp.llvm.org
polly.llvm.org
vmkit.llvm.org

Please note that llvm.org proper is NOT moving at this time. Therefore SVN, Bugzilla, ViewVC, and all the llvm.org/* webpages will remain on that server. I will be updating on this in a separate email.

How does this impact you?
You may see a very short downtime (< 1 hour) when the switch is made. This is most likely due to the DNS switch. I will notify the list when all websites listed have been moved. Since this does not involve SVN, the downtime is hopefully tolerable.

Are you fixing the SSL problem?
Yes. The new server will have SSL support for all websites and have an updated certificate.

Hi Tanya,

Are there more changes planned for the llvm.org web server? HTTPS is broken, and this is affecting users of the Go bindings: https://groups.google.com/d/msg/golang-nuts/cJE-HrH91vk/jgw7wkdxEwAJ

Cheers,
Andrew

All,

The following websites will be moving to a new web server in the next few days:
clang.llvm.org
clang-analyzer.llvm.org
compiler-rt.llvm.org
dragonegg.llvm.org
klee.llvm.org
libclc.llvm.org
libcxx.llvm.org
libcxxabi.llvm.org
lldb.llvm.org
lld.llvm.org
openmp.llvm.org
polly.llvm.org
vmkit.llvm.org

Please note that llvm.org proper is NOT moving at this time. Therefore SVN, Bugzilla, ViewVC, and all the llvm.org/* webpages will remain on that server. I will be updating on this in a separate email.

How does this impact you?
You may see a very short downtime (< 1 hour) when the switch is made. This is most likely due to the DNS switch. I will notify the list when all websites listed have been moved. Since this does not involve SVN, the downtime is hopefully tolerable.

Are you fixing the SSL problem?
Yes. The new server will have SSL support for all websites and have an updated certificate.

Hi Tanya,

Are there more changes planned for the llvm.org web server? HTTPS is broken, and this is affecting users of the Go bindings: https://groups.google.com/d/msg/golang-nuts/cJE-HrH91vk/jgw7wkdxEwAJ

This will happen soon. Its never worked except for SVN and bugzilla though.

-Tanya

Is there any plan to make the migrated sites SSL-only? That is, have
http://clang.llvm.org/** only serve a redirect to
https://clang.llvm.org/** instead
of serving content over http.

If not, that'd be a great thing to add to the plans. :slight_smile:

I’m curious: why?
I understand that you want anything authenticated (bugzilla, …) or the binary/source download, but what’s the reason to use SSL for looking up doxygen or LangRef? (Easier to setup or get it right could be a reason, I don’t know)

Well, sure, that's one reason: it's much easier to ensure that everything
that matters is properly protected, if you always protect everything. You
don't have to think about it anymore, and you won't mess up and
accidentally allow unencrypted binary downloads, which puts users at
unnecessary risk of tampering when they forget to explicitly type https.

Also: do you really want your site's visitors to be running the random
javascript that Comcast injects into it? Using https avoids that, too.

But beyond that: there's no downside. Why should *anyone* continue to serve
http traffic? It's just all around better and safer to require https, for
everything, always.

I think it's easier to simply enforce the redirect and have everything be served over TLS. Once you do that, there's never any danger of parts that require TLS not actually getting it.

E.g., in nginx, I've got

server {
        listen 80 default_server;
        listen [::]:80 default_server;
        server_name my.fqdn.here;
        return 301 https://$server_name$request_uri;
}

and then I know everything is using TLS. (It seems llvm.org is using apache, but I imagine the apache directives are equally simple.) It seems significantly easier to maintain than needing to serve different content using HTTP vs. HTTPS.

As an added benefit, every connection tests your TLS configuration meaning that it's much easier to find problems such as expired certs. For example, https://llvm.org is using a cert with SHA-1 which it absolutely should not be doing in 2017. This shows up as insecure for me in Chrome.

(One can also make arguments about how all Internet traffic should be authenticated at the least, but I think the pure engineering argument that it's easier to just enforce it everywhere is the better argument.)

This is one reason why blindly redirecting http to https is a bad idea. Unless you can be sure that everything everywhere is done correctly, you put clients through extra pain for content that doesn’t need the extra protection. (Note, I’m not arguing for or against this particular change … only pointing out that it isn’t free of consequences.)

Jim Rowan
jmr@codeaurora.org
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by the Linux Foundation

Seems like the pain that you only got once, though. And one that is
worth bearing at least once.

--renato

I take you haven't tried to use WiFi at UK airports or coaches recently?
There are a lot of other places with completely broken "transparent"
proxies and forcing HTTPS (especially in combination with HTST) makes
the network unusable.

Joerg

No, I haven't had the pleasure recently, so I'm not aware of what you're talking about.

But, whatever the case is there, I don't think that's an argument for continuing to serve http, especially for a small site like llvm. At this point, almost all of the major/popular sites on the internet (facebook.com, google.com, amazon.co.uk, wikipedia.org, github.com, yahoo.com, ...), already force https.

So, if UK airport WiFi doesn't work with https, and therefore doesn't work with a majority of the popular sites, well...I hardly see how they can claim to be providing WiFi service at all, at this point. Any such network is going to be, in the eyes of most users, simply useless and broken.

You said there is no downside. I've demonstrated a situation people can
face right now where it can make a website unusable. Don't handwave away
the cost of forcing HTTPS, it adds overhead for all involved parties.
Don't get me wrong, I'm all for properly supporting HTTPS everywhere,
but it is not without downsides.

Joerg

Hi,
I know this thread is quite old, however, I am about to start working on: https://bugs.llvm.org/show_bug.cgi?id=39309 and I couldn’t quite tell if there was any real consensus reached in this thread? Are folks okay with me changing the Apache configs to force a redirect to HTTPS for all of the llvm.org landing pages? Honestly, just from an administration standpoint it would be much easier if I could make everything work the same way. I understand it will incur some overhead processing costs for some people and I’m sorry for any inconvenience. I feel, in this case, the simplicity of maintaining a single configuration outweighs the the burden of connecting over HTTPS. Thoughts?

Thanks,
Mike

Hi,
I know this thread is quite old, however, I am about to start working on: https://bugs.llvm.org/show_bug.cgi?id=39309 and I couldn't quite tell if there was any real consensus reached in this thread? Are folks okay with me changing the Apache configs to force a redirect to HTTPS for all of the llvm.org landing pages? Honestly, just from an administration standpoint it would be much easier if I could make everything work the same way. I understand it will incur some overhead processing costs for some people and I'm sorry for any inconvenience. I feel, in this case, the simplicity of maintaining a single configuration outweighs the the burden of connecting over HTTPS. Thoughts?

+1

Not sure what you mean by landing pages, but I think all http
requests, to any resource under llvm.org or its subdomains, should
redirect to https.

Thanks,
Hans

Hi,
I know this thread is quite old, however, I am about to start working on: https://bugs.llvm.org/show_bug.cgi?id=39309 and I couldn't quite tell if there was any real consensus reached in this thread? Are folks okay with me changing the Apache configs to force a redirect to HTTPS for all of the llvm.org landing pages? Honestly, just from an administration standpoint it would be much easier if I could make everything work the same way. I understand it will incur some overhead processing costs for some people and I'm sorry for any inconvenience. I feel, in this case, the simplicity of maintaining a single configuration outweighs the the burden of connecting over HTTPS. Thoughts?

+1

Not sure what you mean by landing pages, but I think all http
requests, to any resource under llvm.org or its subdomains, should
redirect to https.

I meant exactly what you just said, only I said it poorly. I shouldn’t comment late at night. :slight_smile: