Project

Profile

Help

Task #2477

closed

Github Pages is causing SSL issues and is being marked as spam

Added by bmbouter over 7 years ago. Updated almost 5 years ago.

Status:
CLOSED - COMPLETE
Priority:
Normal
Assignee:
Category:
-
Sprint/Milestone:
-
Start date:
Due date:
% Done:

0%

Estimated time:
Platform Release:
Groomed:
No
Sprint Candidate:
Yes
Tags:
Pulp 2
Sprint:
Sprint 28
Quarter:

Description

Problem 1

The project homepage is hosted by Github Pages[0] and uses the custom domain pulpproject.org. Github Pages does not support SSL with custom domains[1], but it does support SSL with default domains. SSL is still on which is worse because currently when you browse to https://pulpproject.org/ it looks scary.

Problem 2

Also that site is marked as spam (yikes) [2].

Solution

This task requires bash scripting skills and maybe some Jenkins or Jenkins Job Builder experience. The latter could probably be learned along the way.

We will move the hosting to a dedicated hosted VM just like docs.pulpproject.org is hosted. Ultimately this should serve both the docs and homepage websites, but for now this will just the the main website.

Jenkins will build and publish the site nightly similar to how the docs.pulpproject.org are built on Jenkins. To get this going we need a new Jenkins job defined. The Jenkins job needs to do three things: setup the build environment, build the website, and push it to the the hosted environment.

1. A Jenkins job builder definition that will setup the build environment. This is similar to the docs-builder-* job that performs a similar function for docs.pulpproject.org.

The first thing to do is to clone the website code in the build environment: https://github.com/pulp/pulpproject.org/

In the case of pulpproject.org it just needs to setup the environment similar to what is documented in the Build Locally section. Unlike the docs-builder-* which has to be a template to manage a builder for each x.y version of Pulp, this job can be exactly one job since we have exactly one website, so it doesn't need to be a template. This should make it even simpler.

2. Build the environment. Build it just like you would any Jekyll site.

3. Publish it to the hosted environment that a core dev will create. This should be done with rsync and the -delete option so that old pages are always overwritten. You can see the docs.pulpproject.org doing that here although this is even simpler because there is only one case to handle instead of multiple like the docs builder needs to handle. Just rsync and overwrite from the root of the site everytime.

After JJB is building and publishing content a core dev can take the site live by handling DNS updates.

[0]: https://pages.github.com/
[1]: https://github.com/isaacs/github/issues/156
[2]: https://www.redhat.com/archives/pulp-list/2017-July/msg00016.html

Actions #1

Updated by bmbouter over 7 years ago

@dkliban: one potential issue is that we need to be sure that when users fork this repo that they can still preview the site through their fork.

Actions #2

Updated by mhrivnak over 7 years ago

bmbouter wrote:

We would keep the www.pulpproject.org and pulpproject.org redirects in place so those would continue to work. After this change users could also browse directly to pulp.github.io, but no matter how they arrived their browsers would read as pulpproject.org.

Can you elaborate on "their browsers would read as pulpproject.org"? I don't see how that could work if the SSL cert has a different domain in the CN.

My understanding is that we could redirect from pulpproject.org domains to pulp.github.io, but users would absolutely see pulp.github.io as the domain in their URL. That's not an appealing change.

Actions #3

Updated by bmbouter over 7 years ago

  • Description updated (diff)

I biffed the description right at the end! I updated it to read as you suspected, their browsers would read as pulp.github.io.

I agree it's not an appealing change, but it is one way to resolve the SSL problems on pulpproject.org.

Another option would be to explore self-hosting, but that will require more initial and ongoing effort. Given those two choices (or any others) what do you think we should do to resolve the SSL problems?

Actions #4

Updated by mhrivnak over 7 years ago

Perhaps we can do more to explore why it's a problem to begin with. Which information on the website do we need to be SSL-protected, and why? Based on the answers to that, one option would be to find an SSL-enabled home for just that content, and let the main website stay where it is.

Actions #5

Updated by bmbouter over 7 years ago

Yes I want to do a better job of starting with problem statements before going to solutions. I'm learning that from @dkliban some also.

We need TLS on our docs.pulproject.org and pulpproject.org for at least 2 reasons.

As a related problem statement, the user experience currently at https://pulpproject.org/ is bad. Resolving the TLS issues would fix that too.

Actions #6

Updated by bmbouter almost 7 years ago

  • Subject changed from Add https support for project homepage by making homepage pulp.github.io to Fix SSL for pulpproject.org homepage

Retitling to reflect that pulpproject.org is too important to the brand to rename it to pulp.github.io.

Actions #7

Updated by bmbouter almost 7 years ago

  • Status changed from NEW to ASSIGNED
Actions #8

Updated by bmbouter almost 7 years ago

  • Status changed from ASSIGNED to NEW

Putting back at NEW. Moving to ASSIGNED was a mistake.

Actions #9

Updated by bmbouter over 6 years ago

  • Subject changed from Fix SSL for pulpproject.org homepage to Github Pages is causing SSL issues and is being marked as spam
  • Description updated (diff)

Revising the description to include the part where pulpproject.org is marked as a spam site.

Actions #10

Updated by bmbouter over 6 years ago

  • Description updated (diff)

Rewriting to outline what needs to be done to fix this issue.

Actions #11

Updated by bmbouter over 6 years ago

I created the openshift V2 hosting environment. It is currently available at 54.145.148.190. Note that this environment uses the same ssh credentials that already securely stored in Jenkins and used by the existing docs building job here

^ means that the auth is already in place in Jenkins and those lines can effectively be blindly copied.

Actions #12

Updated by mhrivnak over 6 years ago

  • Sprint/Milestone set to 45

This is already in-progress, so someone will groom it ASAP even though we're putting it on the sprint.

Actions #13

Updated by bmbouter over 6 years ago

  • Description updated (diff)

We are waiting on a new hosting environment to be made. We are not hosting on openshift V2. Instead we will go with a different environment which will be able to provide several other benefits. These include: rolling all traffic to https, automatic cert renewal that they handle with letsencrypt, and hosting both the docs site and the main website on one webserver. This ticket has been rewritten some to clarify these changes in the plan.

Actions #14

Updated by bmbouter over 6 years ago

  • Status changed from NEW to ASSIGNED
  • Assignee set to bmbouter
Actions #15

Updated by jortel@redhat.com over 6 years ago

  • Sprint/Milestone changed from 45 to 46
Actions #16

Updated by mhrivnak over 6 years ago

  • Sprint/Milestone changed from 46 to 47
Actions #17

Updated by bmbouter over 6 years ago

  • Status changed from ASSIGNED to CLOSED - COMPLETE

This ticket got a lot simpler when we decided to use the Jekyll build+push service from https://osci.io/

The pulpproject.org is transitioned off of the IP of concern so the spam issue is resolved. Also osci is auto-regenerating TLS certs from letsencrypt so the TLS issues are also resolved. With both issues resolved, I'm closing as complete.

Actions #18

Updated by bmbouter about 6 years ago

  • Sprint set to Sprint 28
Actions #19

Updated by bmbouter about 6 years ago

  • Sprint/Milestone deleted (47)
Actions #20

Updated by bmbouter almost 5 years ago

  • Tags Pulp 2 added

Also available in: Atom PDF