WordPress.org

Make WordPress Systems

Recent Updates Toggle Comment Threads | Keyboard Shortcuts

  • Ian Dunn 6:32 pm on March 19, 2015 Permalink |  

    BuddyCamp.org DNS and nginx aliases, wildcard certificate 

    @camikaos and I would like to start creating sites for BuddyCamps on the WordCamp.org multisite installation, but using the buddycamp.org domain. The domain is already in MarkMonitor and Matt gave the ok to use it.

    Could someone from systems/@nacin please setup aliases in DNS and nginx?

    We’ll also need a wildcard cert for buddycamp.org, since we’re ready to FORCE_SSL_ADMIN across all WordCamp.org sites.

     
    • Andrew Nacin 4:07 am on March 21, 2015 Permalink | Log in to Reply

      I’m powerless here. While I can touch nginx there isn’t anything to be done without there being a cert in place first.

  • Dion Hulse 9:48 am on March 14, 2015 Permalink |  

    Hi!
    Can we please do something to cause lines such as this to work properly in production?
    rewrite ^/themes/([^/]+)$ /themes/$1/ permanent;

    The problem is that using a relative redirect like that causes nginx to prefix it with $scheme://$http_host, which is fine, but now with forced-https, is causing extra redirects. On web nodes, It happens because $scheme is 'http'. It appears that the correct way of fixing this is to use proxy_redirect on the SSL-terminating load balancers.

    I’m unable to test LB changes, but it looks like this line should do the job
    proxy_redirect http://$http_host/ https://$http_host/;
    I’ve tested it on my own nginx install, in the reverse (rewriting ssl Location headers to http), and it appears to work as expected, but I’ve never used it before.
    Using the $http_host variable seems safe, since any relative redirects have to be to the current domain anyway.

    A curl request to duplicate:
    curl -I 'https://wordpress.org/themes/twentyfourteen?'

    Actual: Location: http://wordpress.org/themes/twentyfourteen/
    Expected: Location: https://wordpress.org/themes/twentyfourteen/

     
    • Barry 5:16 am on March 16, 2015 Permalink | Log in to Reply

      I’m pretty sure your proposed config will break HTTP redirects (keep in mind that WP.org isn’t the only thing that the LBs serve) :)

      proxy_redirect http:// $scheme://;

      Has been added to the config and it seems to be working.

      $ curl -sI 'https://wordpress.org/themes/twentyfourteen?' | grep ^Location
      Location: https://wordpress.org/themes/twentyfourteen/
      
      • Dion Hulse 2:09 am on March 17, 2015 Permalink | Log in to Reply

        I’m pretty sure your proposed config will break HTTP redirects (keep in mind that WP.org isn’t the only thing that the LBs serve) :)

        Hm, you’re right that it’d have broken those cases :)
        However, your config is also too greedy in it’s matching, for example, it now rewrites ALL location headers to the current scheme, regardless of if that redirect should be https.

        One example is this:
        curl -I https://wordpress.org/donate/
        which redirects to http://wordpressfoundation.org/donate/ (and then nginx is altering to https://wordpressfoundation.org/donate/).

        So I’d propose proxy_redirect http://$http_host/ $scheme://$http_host/; instead to only apply it to the current-domain again. Although we have a number of other rewrite instances which redirect to http://wordpress.org/ which it wouldn’t catch at first, but that wouldn’t cause an issue.

        • Barry 4:43 am on March 17, 2015 Permalink | Log in to Reply

          I think HTTPS –> HTTP redirect is a bad idea and we shouldn’t do it.

          • Barry 5:00 am on March 17, 2015 Permalink | Log in to Reply

            Until we stop doing this I made some changes similar to what you suggested. Can you let me know if it’s working as expected now?

            • Dion Hulse 5:02 am on March 17, 2015 Permalink

              All cases I can think of look to be working as expected.

  • Konstantin Obenland 12:09 am on February 24, 2015 Permalink |  

    We’re launching the new theme directory this week, and it comes with some URLs redirects.

    Most importantly, wordpress.org/themes/ will be served from the WordPres.org MU going forward, so themes will be just a site on that network.

    Trailingslash all request without a query,
    /themes => /themes/
    /themes/tag-filters/ => /themes/
    /themes/search.php?q=[term] => /themes/search/[term]/
    /themes/[themename]/stats/ => /themes/[themename]/
    /themes/[themename]/developer/ => /themes/[themename]/
    /themes/about/ => /themes/getting-started/
    /themes/contact/ => /themes/getting-started/
    

    We don’t have a specific date/time for the switch yet, but it will be on 2/25 or 2/26.
    Posting here to give you a heads up and some time to get it prepared.

    /cc @seanosh, @otto42

     
    • Dion Hulse 12:42 am on February 24, 2015 Permalink | Log in to Reply

      FWIW, there’s a bunch more URL changes than just these that apply to themes.

      • The links in the sidebar under Themes, /themes/mine/ /themes/about/ /themes/contact/ (I guess these are pages you haven’t yet created?)
      • Tags – /themes/tags/custom-background
      • RSS Feeds – /themes/rss/(forum|tags|view|browse)/*
      • /themes/browse/(popular|new|updated)
      • Konstantin Obenland 4:49 pm on February 24, 2015 Permalink | Log in to Reply

        • Mine is going to be /author/[login]/ going forward, so not something we could recreate, I imagine. I wasn’t sure whether letting 404 would have merit here.
        • About and Contact are now part of Upload. The reason I haven’t mentioned it yet is that the WPTRT has not made up their mind yet about what the upload experience should look like, so I wanted to hold off on that one until we know.
        • Yes, tags need to be tag, I updated the post, thanks.
        • In terms of RSS, let me try it on the WP level first.
        • Browsing URLs are going to continue to live on.
  • Andrew Nacin 1:11 am on February 19, 2015 Permalink |
    Tags: deploy wporg-web   

    Can I please have the wporg-web role updated after r5929 and r5930? It pipes deploys to Slack. Pretty clever IMO, in terms of how it detects what revision is getting deployed. This only affects sandboxes (the deploy script itself).

     
  • Andrew Nacin 6:58 pm on February 17, 2015 Permalink |
    Tags:   

    Requesting a sandbox for Kelly Dwan (@ryelle). She should have a public key at Automattic (where she is @ryelle33) to use. I’ll handle SVN access — just needs the sandbox. Thanks!

     
    • seanosh 2:48 pm on February 18, 2015 Permalink | Log in to Reply

      All set, here are the details of the sandbox:

      User Name : wporgdev
      Host Name : ryelle33.dev.wordpress.org
      IP Address: 66.155.40.190
  • Konstantin Kovshenin 4:17 pm on February 16, 2015 Permalink |
    Tags:   

    Hi! Can we please remove the following server blocks from wordcamp-web.conf?

    server {
        listen 80;
        server_name 2006.wordcamp.org 2006.sf.wordcamp.org;
        ...
    }
    
    server {
        listen 80;
        server_name 2007.wordcamp.org 2007.sf.wordcamp.org;
        ...
    }
    

    Thanks!

     
    • Konstantin Kovshenin 4:21 pm on February 16, 2015 Permalink | Log in to Reply

      Also this block from wordcamp-redirects:

      server {
          listen 80;
          server_name wordcampsf.org wordcampsf.com *.wordcampsf.org *.wordcampsf.com;
          ...
      }
      

      Thank you!

    • Andrew Nacin 1:13 am on February 19, 2015 Permalink | Log in to Reply

      I presume these sites will all still work after these rules are removed, just some other way?

      For the non-wordcamp.org domains, I presume the idea will be to handle the redirect elsewhere as they don’t have SSL certificates?

      • Konstantin Kovshenin 8:31 am on February 19, 2015 Permalink | Log in to Reply

        Correct, we’ve migrated the legacy code into themes that are now running inside the main WordCamp.org network as opposed to secondary WordPress installs in a different root. This allows us to retire the secondary installs and proceed with the URL format change for WordCamp SF sites, which are the only ones left right now.

        Re. SSL, actually I’m not sure yet. I thought about forcing SSL on WordCamp.org via nginx, but that would break year.city.wordcamp.org subdomains which will not be covered by the wildcard certificate, so I thought of handling it with PHP instead, where we already handle year.city.wordcamp.org redirects to city.wordcamp.org/year, so I think additional domains can just follow the same pattern.

        • Andrew Nacin 2:28 am on March 18, 2015 Permalink | Log in to Reply

          I couldn’t tell from this response that “wordcampsf.org wordcampsf.com *.wordcampsf.org *.wordcampsf.com” will still work. My comment about SSL was that https://wordcampsf.com would now cause an error, while previously it had nothing listening on port 443. (Minor detail, sure.)

          • Konstantin Kovshenin 2:25 pm on March 19, 2015 Permalink | Log in to Reply

            Someone would have to explicitly request those domains with https, and yes, they’ll be served with the *.wordcamp.org wildcard certificate. They’ll see the same behavior when explicitly requesting year.city.wordcamp.org hosts via https.

    • seanosh 11:42 am on March 17, 2015 Permalink | Log in to Reply

      All set. Sorry for the delay.

  • Konstantin Kovshenin 4:34 pm on February 11, 2015 Permalink |
    Tags:   

    Hi! Can we please remove the following redirects from WordCamp.org’s nginx config?

    server {
            listen 80;
            server_name newyork.wordcamp.org;
    
            rewrite ^(.*)$ http://2009.newyork.wordcamp.org$1 permanent;
    }
    
    server {
            listen 80;
            server_name utah.wordcamp.org;
    
    #       rewrite ^(.*)$ http://2010.utah.wordcamp.org$1 permanent;
            rewrite ^(.*)$ http://2011.slc.wordcamp.org$1 permanent;
    }
    

    Thanks!

     
  • Ian Dunn 11:05 pm on February 5, 2015 Permalink |
    Tags: , zip   

    ZipArchive on WordCamp.org 

    Could we please have ZipArchive installed on WordCamp.org?

    It’s needed for #262-meta, where we want to automate the generation of Gravatar badges for WordCamps.

     
  • Andrew Nacin 10:19 pm on January 22, 2015 Permalink |
    Tags:   

    I have an nginx fix for a fun issue that’s breaking Jetpack integration.

    https://make.wordpress.org/support/xmlrpc.php isn’t being rewritten to /xmlrpc.php because /support/xmlrpc.php exists (it’s a bbPress file). /support/ is a physical directory that is bypassed for all subdomains, which means we end up rewriting it to index.php and thus a 404 results.

    The simple fix appears to be this:

    
    	# make.wordpress.org/support/xmlrpc.php needs to hit /xmlrpc.php.
    	# Without this, it targets /support/xmlrpc.php (a bbPress file)
    	# which is then denied and we end up with a 404.
    	location ~ /xmlrpc\.php(?:/|$) {
    		include conf.d/php-config;
    		rewrite ^ /xmlrpc.php break;
    	}
    

    This should go into conf.d/wporg-make.wordpress.org around line 60. I’m happy to commit this but I wanted review first.

     
    • seanosh 1:58 am on February 5, 2015 Permalink | Log in to Reply

      I’m OK with this (barring any other objections). Let me know if you need help rolling it out.

    • Andrew Nacin 5:53 am on February 5, 2015 Permalink | Log in to Reply

      I’m not positive the include conf.d/php-config.php + rewrite is correct, whether anything is missing, etc. It works and I can’t find side effects, but this is a bit out of my area of expertise.

    • Barry 7:39 pm on February 11, 2015 Permalink | Log in to Reply

      Maybe @pyhhak can take a look at this.

    • pyhhak 9:59 pm on February 11, 2015 Permalink | Log in to Reply

      You don’t need the php-config, just need to use normal rewrite (without break). Also your regex location would rewrite /whatever/xmlrpc.php to /xmlrpc.php, which is useless and more of a pain to maintain in future.

      If you only need /support/xmlrpc.php my suggestion is this:

      location = /support/xmlrpc.php {
      	rewrite ^ /xmlrpc.php;
      }
      

      I sort of tested it, and it seemed to work. Can you run your tests and commit it?

  • Andrew Nacin 3:43 am on January 22, 2015 Permalink |
    Tags:   

    Can johnbillion please be given a sandbox? I can set up commit access and such.

     
c
compose new post
j
next post/next comment
k
previous post/previous comment
r
reply
e
edit
o
show/hide comments
t
go to top
l
go to login
h
show/hide help
shift + esc
cancel