WordPress.org

Make WordPress Systems

Recent Updates Page 2 Toggle Comment Threads | Keyboard Shortcuts

  • Konstantin Kovshenin 9:30 am on April 20, 2015 Permalink |
    Tags:   

    Hi there! I’d like to request a few nginx changes on WordCamp.org if possible. In wordcamp-web.conf:

    • Remove the second server block (for server_name wordcamp.org http://www.wordcamp.org)
    • Remove the last two server blocks that listen on 443, but
    • Move those SSL directives (listen, ssl, include conf.d/ssl-config, ssl_*) to the main server block (with server_name _)
    • At this point wordcamp.org-common doesn’t seem to be used anymore, so we can nuke it

    This is part of forcing https on WordCamp.org. In order to support old-format requests and hot-linking (photos, etc.) we will still be serving some traffic over port 80, but mostly it’s redirects via sunrise.php.

    Thanks!

     
  • John James Jacoby 3:35 pm on April 7, 2015 Permalink |
    Tags: ,   

    Can I please have commit access granted to buddypress.svn.wordpress.org for the username “hnla″?

    Hugo will be focusing on BuddyPress’s theme compatibility with WordPress’s core themes in 2.3, and will be a permanent committer for all releases going forward in a similar capacity.

    We’ve chatted about responsibilities, expectations, and security of commit access. His front-end abilities will really help BuddyPress fit more naturally and feel more turn-key, and the core team is excited for him to get started.

     
  • Dion Hulse 4:11 am on April 4, 2015 Permalink |
    Tags:   

    WordPress.org & WordCamp email SPF = softfail 

    Emails being sent by WordPress.org & WordCamp WordPress instances are currently SPF softfail’ing, I suspect that’s what has caused Gmail to mark all contact requests from a WordCamp site to me (and the rest of the team) as spam.

    This is happening as the bounce reply address is currently set to bouce@wp.com which doesn’t accept w.org IP ranges as SPF permitted senders (as expected).
    WordPress.org emails are DKIM signed (where as WordCamp ones are not), so i suspect that’s why they don’t get marked as spam.

    Relevant part of a WordCamp email:
    Received-SPF: softfail (google.com: domain of transitioning bounce@wp.com does not designate 66.155.40.24 as permitted sender) client-ip=66.155.40.24;
    Authentication-Results: mx.google.com;
    spf=softfail (google.com: domain of transitioning bounce@wp.com does not designate 66.155.40.24 as permitted sender) smtp.mail=bounce@wp.com
    Received: from [66.155.40.205] (port=20977 helo=wordcamp1.lax.wordpress.org)
    by marx.multipattern.com with esmtp (Exim 4.85)
    (envelope-from )
    id 1YeF53-00028j-BS
    for *brisbane wc email removed*; Sat, 04 Apr 2015 03:49:16 +0000

    And that of a Make blog:
    Received-SPF: softfail (google.com: domain of transitioning bounce@wp.com does not designate 66.155.40.19 as permitted sender) client-ip=66.155.40.19;
    Authentication-Results: mx.google.com;
    spf=softfail (google.com: domain of transitioning bounce@wp.com does not designate 66.155.40.19 as permitted sender) smtp.mail=bounce@wp.com;
    dkim=pass header.i=@wordpress.org
    Received: from mail.wordpress.org (localhost.localdomain [127.0.0.1])
    by mail.wordpress.org (Postfix) with ESMTP id 3DAEA206CA9;
    Fri, 27 Mar 2015 04:05:43 +0000 (UTC)

     
    • stankea 8:23 am on April 4, 2015 Permalink | Log in to Reply

      We need to stop using @wp.com domain on wp.org stuff. The bounce@wp.com manages bounces for wp.com stuff, so any bounces to bounce@wp.com (by email sent from wp.org) does not do anything on wp.org and is useless.
      Changed the SPF to ?all (neutral) for now so that they don’t softfail, but the correct fix is to change the email addresses. Do you see any issues with switching the email from bounce@wp.com to something like bounce@wordpress.org (or even better – @bounces.wordpress.org) ?

      • Dion Hulse 8:40 am on April 4, 2015 Permalink | Log in to Reply

        We need to stop using @wp.com domain on wp.org stuff.

        agreed, I assume it’s only there because of a configuration copy-paste.

        Do you see any issues with switching the email from bounce@wp.com to something like bounce@wordpress.org (or even better – @bounces.wordpress.org) ?

        I personally don’t quite understand the bounce address setup, so I’ll defer to anyone on systems for that.. but I don’t see it causing any problems for us – It’ll probably only reduce the amount of email incorrectly marked as spam.

        It looks like the Trac emails, and anything going through lists.wordpress.org are unaffected, as they have their own return-path specified, so it’s really only down to WordPress, WordCamp, and bbPress emails which are far more infrequent.

        • stankea 7:54 am on April 9, 2015 Permalink | Log in to Reply

          Currently wp.org does not do any bounce management, so it doesn’t really matter. If you plan to do bounce management, then you chat with me about it :)
          I’ve set up bounce@wordpress.org (currently delivering to a super compressed mailbox /dev/null) and set the default sender to bounce@wordpress.org – looks like it was set in php.ini
          Marking as resolved

  • 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.

    • Ian Dunn 5:00 pm on April 7, 2015 Permalink | Log in to Reply

      @seanosh, I’m was hoping to have the first site setup by May 1st, because there’s a BuddyCamp in June and they’ll need the site to promote it, sell tickets, etc.

      I’m guessing the SSL process can take a few weeks, and I’ll also need some time on my end to set it up, so I think we need to get started soon if it’s going to be ready in time.

      Do you think that’s a reasonable timeline?

    • Barry 3:34 am on April 16, 2015 Permalink | Log in to Reply

      Hi @iandunn – SSL cert obtained and committed. Also updated the nameservers for buddycamp.org and added a DNS entry (might need to change). I think @seanosh can help you with the rest. Also – did you talk to Matt about buying any of the other buddycamp domains? Looks like some are already registered (.com) and others are available for registration (.net). I didn’t really look too much.

      • Ian Dunn 2:49 pm on April 16, 2015 Permalink | Log in to Reply

        Awesome, thanks :)

        I hadn’t thought about the other domains, I’ll add that to the list.

        • Ian Dunn 2:50 pm on April 16, 2015 Permalink | Log in to Reply

          Er, I meant, I’ll add that to my task list for the site and look into it once the high priority stuff is done.

    • seanosh 12:58 pm on April 21, 2015 Permalink | Log in to Reply

      Added NGINX configs for buddycamp.org, *.buddycamp.org with SSL support similar to wordcamp.org and *.wordcamp.org. Right now it 302’s to central.wordcamp.org, so it looks like you just need to set this up in WordPress. If anything else is needed on this please unresolve and comment. Thanks!

  • 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:   

    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!

     
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