Re: [Wikitech-l] Tampa datacenter issues
Did that on purpose ;) But the links are still recovering, we're on a single link and we're not sure of their stability, so be wary! On Fri, Jan 17, 2014 at 2:26 PM, Tim Landscheidt t...@tim-landscheidt.de wrote: I wrote: We had a fibre cut of our connection to our Tampa DC this morning. ETA of a fix is still pending, but the cuts have been located and crews are being dispatched. Meanwhile public traffic is being rerouted via the public Internet, so most services should be reachable. Tampa is our secondary DC which we're decommissioning, so there was no impact on our main sites. Impacted temporarily were: inbound Wikimedia.org email, Bugzilla, Labs. Fundraising is still impacted, but shouldn't be (we're debugging). Small correction: Labs is still impacted as neither the replica servers nor Wikipedia Co. can be reached without the link so tools and bots relying on that are out of ser- vice at the moment. ... and when I hit C-c C-c, the link came back up. So now Labs should be fully working again. Tim ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l -- Leslie Carr Wikimedia Foundation AS 14907, 43821 http://as14907.peeringdb.com/ ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] OpenID deployment delayed until sometime in 2014
Also, we allow people to login via plain text and not SSL. Scary On Wed, Nov 27, 2013 at 10:07 AM, Ryan Lane rlan...@gmail.com wrote: On Wed, Nov 27, 2013 at 3:51 AM, Gerard Meijssen gerard.meijs...@gmail.comwrote: According to the website of myopenid [1], they are closing down Februari 1. My hope was for the Wikimedia Foundation to come to the rescue and provide a non commercial alternative to what Google and Facebook offer. I am extremely disappointed that we are not. I hope that what is done instead has at least a similar impact than leaving it all to the commercial boys and girls. Privacy should not be left to commerce and national secret services. Our account security honestly makes us a poor choice for an auth provider and you should have never considered us for this anyway. We don't have password requirements, we don't offer two factor auth, we don't offer good ways to rescue a lost account, and we really don't want to be a target of attack for the purpose of owning other websites. Also, if you're really concerned about privacy you should be putting your support behind Mozilla's BrowserID (Persona). - Ryan ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l -- Leslie Carr Wikimedia Foundation AS 14907, 43821 http://as14907.peeringdb.com/ ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] 2013 Datacenter RFP - open for submissions
I'm curious which details you would like to see? On Mon, Oct 21, 2013 at 5:22 PM, Jay Ashworth j...@baylink.com wrote: - Original Message - From: Ken Snider ksni...@wikimedia.org After working through the specifics internally, we now have a public RFP posted[1] and ready for proposals. We invite any organization meeting the requirements outlined to submit a proposal for review. My snap reaction, Ken, is that the RFP seems fairly thin on relevant details; how many passes did it go through before you posted it? How much input came from the Ashburn project? Equinix Tampa? Or was it left loose on purpose, to see what people would come up with? Cheers, -- jra -- Jay R. Ashworth Baylink j...@baylink.com Designer The Things I Think RFC 2100 Ashworth Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l -- Leslie Carr Wikimedia Foundation AS 14907, 43821 http://as14907.peeringdb.com/ ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] 2013 Datacenter RFP - open for submissions
On Sat, Oct 19, 2013 at 1:17 PM, Maarten Dammers maar...@mdammers.nl wrote: Hi Ken, Op 18-10-2013 22:05, Ken Snider schreef: The Wikimedia Foundation's Technical Operations team is seeking proposals on the provisioning of a new data-centre facility. After working through the specifics internally, we now have a public RFP posted[1] and ready for proposals. We invite any organization meeting the requirements outlined to submit a proposal for review. You have stated some technical requirements, but not the availability you would like to have. You probably want to include that you're looking for a tier-4 data center (https://en.wikipedia.org/wiki/Tier_4_data_center#Data_center_tiers). Is this one going to replace the Florida data center? Where are you keeping documentation these days? The information on wikitech seems to be very incomplete and outdated. Wikitech is our best source of documentation Something related: While travelling in China I noticed the bad performance of our sites. Would it be a good idea to investigate this (lack of) performance and maybe consider a caching site somewhere in Asia? The latency should be much better than getting is all the way from the USA. http://www.glif.is/publications/maps/GLIF_5-11_World_4k.jpg (from http://www.glif.is/publications/maps/) gives a good idea of connectivity by the way. (Employee hat) - we are starting to move some of the Asian traffic to a new caching center on the US west coast, which has helped latency. (Personal hat) - I would love to get an Asian caching center (Hong Kong or Tokyo would be my top 2 choices), but IMHO the biggest barrier to this the time and availability of people resources. Maarten ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l -- Leslie Carr Wikimedia Foundation AS 14907, 43821 http://as14907.peeringdb.com/ ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] 2013 Datacenter RFP - open for submissions
On Sat, Oct 19, 2013 at 2:18 PM, Gerard Meijssen gerard.meijs...@gmail.com wrote: Hoi, Are some of our partners in Wikipedia Zero not caching already ? Thanks, GerardM Are you asking if they have varnish caches (they do not) or if they are using some web caching on their environment (which is possible, using transparent proxies , though I do not know of providers who use them... however my mobile web ecosystem knowledge is limited) On 19 October 2013 12:59, Leslie Carr lc...@wikimedia.org wrote: On Sat, Oct 19, 2013 at 1:17 PM, Maarten Dammers maar...@mdammers.nl wrote: Hi Ken, Op 18-10-2013 22:05, Ken Snider schreef: The Wikimedia Foundation's Technical Operations team is seeking proposals on the provisioning of a new data-centre facility. After working through the specifics internally, we now have a public RFP posted[1] and ready for proposals. We invite any organization meeting the requirements outlined to submit a proposal for review. You have stated some technical requirements, but not the availability you would like to have. You probably want to include that you're looking for a tier-4 data center (https://en.wikipedia.org/wiki/Tier_4_data_center#Data_center_tiers). Is this one going to replace the Florida data center? Where are you keeping documentation these days? The information on wikitech seems to be very incomplete and outdated. Wikitech is our best source of documentation Something related: While travelling in China I noticed the bad performance of our sites. Would it be a good idea to investigate this (lack of) performance and maybe consider a caching site somewhere in Asia? The latency should be much better than getting is all the way from the USA. http://www.glif.is/publications/maps/GLIF_5-11_World_4k.jpg (from http://www.glif.is/publications/maps/) gives a good idea of connectivity by the way. (Employee hat) - we are starting to move some of the Asian traffic to a new caching center on the US west coast, which has helped latency. (Personal hat) - I would love to get an Asian caching center (Hong Kong or Tokyo would be my top 2 choices), but IMHO the biggest barrier to this the time and availability of people resources. Maarten ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l -- Leslie Carr Wikimedia Foundation AS 14907, 43821 http://as14907.peeringdb.com/ ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l -- Leslie Carr Wikimedia Foundation AS 14907, 43821 http://as14907.peeringdb.com/ ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] 2013 Datacenter RFP - open for submissions
On Sat, Oct 19, 2013 at 2:39 PM, Gerard Meijssen gerard.meijs...@gmail.com wrote: Hoi, I am not so much interested in what they use. What I would like to suggest is that we have partners in both Africa and Asia. They are likely to have the expertise to run a caching centre on our behalf. They provide us a service in bringing Wikipedia at no cost to their customers. When we pay them to run a non-discriminatory caching service, it would increase our service and maybe even the cost of transatlantic traffic. Thanks, GerardM Running a mobile network is completely different operation from running a CDN. -- Leslie Carr Wikimedia Foundation AS 14907, 43821 http://as14907.peeringdb.com/ ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] 2013 Datacenter RFP - open for submissions
On Sat, Oct 19, 2013 at 2:50 PM, Gerard Meijssen gerard.meijs...@gmail.com wrote: Before it is send to a mobile phone, the data has to be retrieved in the classic way. As an engineer I do know how the internet works ;) Do you really think that the companies who run mobile network do not have the expertise to keep a bunch of caching servers in the air ? When you do, do you think that all these mobile operators do not have that skill? Do you think they do not have capacity at the key locations of the Internet infrastructure? That is exactly what I think. Thanks, GerardM On 19 October 2013 13:44, Leslie Carr lc...@wikimedia.org wrote: On Sat, Oct 19, 2013 at 2:39 PM, Gerard Meijssen gerard.meijs...@gmail.com wrote: Hoi, I am not so much interested in what they use. What I would like to suggest is that we have partners in both Africa and Asia. They are likely to have the expertise to run a caching centre on our behalf. They provide us a service in bringing Wikipedia at no cost to their customers. When we pay them to run a non-discriminatory caching service, it would increase our service and maybe even the cost of transatlantic traffic. Thanks, GerardM Running a mobile network is completely different operation from running a CDN. -- Leslie Carr Wikimedia Foundation AS 14907, 43821 http://as14907.peeringdb.com/ ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l -- Leslie Carr Wikimedia Foundation AS 14907, 43821 http://as14907.peeringdb.com/ ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] 2013 Datacenter RFP - open for submissions
On Sat, Oct 19, 2013 at 3:01 PM, MZMcBride z...@mzmcbride.com wrote: Ken Snider wrote: The Wikimedia Foundation's Technical Operations team is seeking proposals on the provisioning of a new data-centre facility. After working through the specifics internally, we now have a public RFP posted[1] and ready for proposals. We invite any organization meeting the requirements outlined to submit a proposal for review. Most of the relevant details are in the document itself, but feel free to reach out to myself or the list should anyone have any questions. Hi. I'm pretty confused how this RFP relates to the ulsfo datacenter. As far as I know, ulsfo is not being proposed, it's already been approved. Is this RFP intended for an additional new datacenter somewhere in the U.S.? I looked at https://meta.wikimedia.org/wiki/Wikimedia_servers#Hosting to try to gain clarity. ulsfo is a caching center (varnish + LVS servers, but no backend infrastructure and very few machines) MZMcBride ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l -- Leslie Carr Wikimedia Foundation AS 14907, 43821 http://as14907.peeringdb.com/ ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] 2013 Datacenter RFP - open for submissions
On Sat, Oct 19, 2013 at 3:29 PM, MZMcBride z...@mzmcbride.com wrote: Leslie Carr wrote: ulsfo is a caching center (varnish + LVS servers, but no backend infrastructure and very few machines) Thank you for clarifying a bit. That helps. Is this new datacenter intended to be more like eqiad, then? And (echoing Maarten's question) will this new datacenter replace pmtpa? Yes to both! I'm just trying to wrap my head around this at a very high level. :-) MZMcBride ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l -- Leslie Carr Wikimedia Foundation AS 14907, 43821 http://as14907.peeringdb.com/ ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Help run an Open Source Day Oct. 5, in Minneapolis, USA?
As someone who attended this last year, I think that having a specific small project/goal in mind would be very helpful -- many attendees seemed to enjoy the projects where they could show off what they did in the end. On Tue, Sep 3, 2013 at 2:07 PM, Sumana Harihareswara suma...@wikimedia.org wrote: http://gracehopper.org/2013/conference/grace-hopper-open-source-day/ The purpose of Grace Hopper Open Source Day is to give attendees of the conference and some of our friends from local universities the opportunity to code, network and contribute to the greater social good. I was going to lead this. But if possible, I'd like to concentrate on my sabbatical and give someone else a chance to guide these folks (mostly women who are studying computer science as grad students or undergraduates). I can give you instructions and task lists for how to help these MediaWiki/Wikimedia newbies started. And WMF can pay for you to get to Minneapolis and stay overnight for a few nights. (The closer you are, the better.) Can you help? I'd like to get this taken care of by the end of this Friday; please email me off-list if you're interested. Thanks. -- Sumana Harihareswara Engineering Community Manager Wikimedia Foundation ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l -- Leslie Carr Wikimedia Foundation AS 14907, 43821 http://as14907.peeringdb.com/ ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] git.wikimedia.org dead?
Ahha - looks like the robots.txt isn't being served - so googlebot is grabbing things from the zip files client denied by server configuration: /var/www/robots.txt sadly too jetlagged to keep looking at this :( On Sun, Aug 11, 2013 at 4:52 AM, rupert THURNER rupert.thur...@gmail.com wrote: On Sat, Aug 10, 2013 at 4:49 PM, MZMcBride z...@mzmcbride.com wrote: rupert THURNER wrote: https://git.wikimedia.org/ seems to be dead. Yup. It keeps happening: https://bugzilla.wikimedia.org/51769. would it be possible to help debugging this? rupert. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l -- Leslie Carr Wikimedia Foundation AS 14907, 43821 http://as14907.peeringdb.com/ ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Fwd: [outages] www.wikipedia.com from Level3 via IPv6 not working
This was technically redundant reporting, but forwarding to a list that we read often versus lists which we may or may not read often is helpful. On Thu, Aug 8, 2013 at 4:07 AM, George Herbert george.herb...@gmail.com wrote: The original reporter saw the same restoration of service (I assume)... Question - Are the WMF ops folks on the NANOG and outages lists? Was this redundant reporting? 8-) -- Forwarded message -- From: cb.list6 cb.li...@gmail.com Date: Wed, Aug 7, 2013 at 12:40 PM Subject: Re: [outages] www.wikipedia.com from Level3 via IPv6 not working To: outa...@outages.org FYI, the route is now back in at Level3 From the Level3 looking glass Traceroute results from Baton Rouge, LA to 2620:0:860:ed1a::1 1 vl-16.car1.Houston1.Level3.net (2001:1900:1D::39) 404 msec 204 msec 148 msec 2 vl-5.bar1.Houston1.Level3.net (2001:1900:1D::1) 200 msec 204 msec 132 msec 3 vl-4045.edge2.Dallas1.Level3.net (2001:1900:4:1::18D) 200 msec 208 msec 208 msec 4 vl-60.edge2.Dallas3.Level3.net (2001:1900:17:1::E) 204 msec 200 msec 204 msec 5 XO-Level3.dallas3.Level3.net (2001:1900:4:3::192) 208 msec 212 msec 208 msec 6 * * * 7 2610:18::30EC 76 msec 52 msec 52 msec 8 2610:18::30E8 52 msec 52 msec 48 msec 9 * * * 10 wikipedia-lb.pmtpa.wikimedia.org (2620:0:860:ED1A::1) 128 msec 132 msec 128 msec On Wed, Aug 7, 2013 at 11:17 AM, cb.list6 cb.li...@gmail.com wrote: Anyone else seeing this? The Level3 looking glass seems to be all stars and no route in BGP at the Level3 looking glass. But, HE has the route core1.fmt1.he.net show ipv6 bgp routes detail 2620:0:860::/46 Number of BGP Routes matching display condition : 1 S:SUPPRESSED F:FILTERED s:STALE 1 Prefix: 2620:0:860::/46, Status: BI, Age: 68d19h32m18s NEXT_HOP: 2001:470:0:1c0::2, Metric: 665, Learned from Peer: 2001:470:0:17::1 (6939) In-Label: 794624 LOCAL_PREF: 140, MED: 1, ORIGIN: igp, Weight: 0 AS_PATH: 14907 COMMUNITIES: 6939:1000 6939:6000 Last update to IP routing table: 7d12h24m40s# Entry cached for anothe [cbyrne@~]$ dig @8.8.8.8 wikipedia.org ; DiG 9.8.3-P4 @8.8.8.8 wikipedia.org ; (1 server found) ;; global options: +cmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 46671 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;wikipedia.org. IN ;; ANSWER SECTION: wikipedia.org. 444 IN 2620:0:860:ed1a::1 ;; Query time: 53 msec ;; SERVER: 8.8.8.8#53(8.8.8.8) ;; WHEN: Wed Aug 7 11:02:28 2013 ;; MSG SIZE rcvd: 59 Traceroute results from Atlanta, GA to 2620:0:860:ed1a::1 1 * * * 2 * * * 3 * * * 4 * * * 5 * * * 6 * * * 7 * * * 8 * * * 9 * * * 10 * * * 11 * * * 12 * * * 13 * * * timeout ! ___ Outages mailing list outa...@outages.org https://puck.nether.net/mailman/listinfo/outages -- -george william herbert george.herb...@gmail.com ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l -- Leslie Carr Wikimedia Foundation AS 14907, 43821 http://as14907.peeringdb.com/ ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] How's the SSL thing going?
On Wed, Jul 31, 2013 at 5:22 PM, Tyler Romeo tylerro...@gmail.com wrote: Also, on a side note, Facebook *just* made HTTPS the default: https://www.facebook.com/notes/facebook-engineering/secure-browsing-by-default/10151590414803920 As an FYI - facebook, a site where every person is logged in and possibly seeing non-public content is very different than Wikimedia. *-- * *Tyler Romeo* Stevens Institute of Technology, Class of 2016 Major in Computer Science www.whizkidztech.com | tylerro...@gmail.com On Wed, Jul 31, 2013 at 6:03 PM, Brian Wolff bawo...@gmail.com wrote: As for government-run spy networks, we don't know what their full capabilities are. But there are plenty of benefits to rolling out SSL regardless, even just for privacy from the person at the other end of the coffee shop. Firesheep, anyone? Matt Flaschen I agree that there's lots of benefits to ssl, and its something that we really should do. I just think we should be clear on our threat model, and not mislead people into thinking it will protect them from an entity with the resources of a state. SSL is too often banded about as being something which will totally prevent government type spying. --bawolff ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l -- Leslie Carr Wikimedia Foundation AS 14907, 43821 http://as14907.peeringdb.com/ ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Proposal: Let's move to a one-week deploy cycle
On Mon, May 6, 2013 at 7:43 PM, Erik Moeller e...@wikimedia.org wrote: On Mon, May 6, 2013 at 7:20 PM, MZMcBride z...@mzmcbride.com wrote: The reason I ask about a distinction is that there have been a lot of changes to Wikimedia wikis lately and likely more to come, as the Wikimedia Foundation has gotten larger and has more dedicated tech resources. Overall, this is great. But big new features come with big changes, and these changes sometimes need a bit of breathing room. I've read a lot of pushback lately against rapid changes (usurping usernames, getting rid of the new message indicator, etc.). A lot of this seems mostly outside the scope how often to deploy (and I don't want to shift the focus of this thread), but it gets confusing (to me, at least) to make a distinction between new code/features on Wikimedia wikis and how often to branch MediaWiki core/extensions. A lot of this could potentially be addressed in a consistent manner across wikis if we applied the alpha-beta-prod (or just beta-prod for starters) channel model that's used on the Wikimedia mobile sites. Then features (whether in core or extensions) could be flagged for alpha or beta readiness, and users would only get them if they've decided to opt into either of those channels. We could still flip the switch from beta-prod, but that decision could be decoupled from the weekly deployment cycle. This would likely be done for features changes which have significant user-facing impact, and where segregation into on and off modes is possible (not always the case). I think this is awesome for features ... but if we're putting work into this, I would love even more to have a clustered a+b production environment, such that 10% of folks are put on the new release (cluster a) and then it gets pushed over to cluster b. Then we can also test performance in a real world environment, and breakages only happen for 10% (PS the 10% number was pulled out of thin air). The opt-in beta is much too limited, as well as being inapplicable to the vast majority of our traffic (logged in users are such a small percentage) to make proper comparisons. You could also see the impact of features on usage for average users. We may want to consider at least putting some such scaffolding for beta-prod desktop modes into place before shifting to weekly deployments, although if that holds up this change significantly, I'd be in favor of making the shift first and then iterating. Right now we have lots of individual experimental prefs, some dark launch URL parameters (useNew=1 for the account creation forms etc.), some changes that are announced widely but then rolled out immediately (section edit link change), etc. What would be the disadvantage of having a single I'd like the latest and greatest changes once they come in preference for our users? The main disadvantage I see is that we'd need to temporarily retain two codepaths for significant user-facing changes, potentially increasing code complexity a fair bit, but perhaps reducing post-launch cost in return. And we'd need to consider more carefully if/when to make the beta/prod switch -- not necessarily a bad thing. ;-) Have there been any negative experiences with this model on the mobile sites? Erik -- Erik Möller VP of Engineering and Product Development, Wikimedia Foundation ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l -- Leslie Carr Wikimedia Foundation AS 14907, 43821 http://as14907.peeringdb.com/ ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Have production server access? Please read this document
The Ops team has been working on a document about best practices with regards to production machines. If you have access to a production machine, please read this document https://wikitech.wikimedia.org/wiki/Server_access_responsibilities -- Leslie Carr Wikimedia Foundation AS 14907, 43821 http://as14907.peeringdb.com/ ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Important maintenance bug
https://bugzilla.wikimedia.org/show_bug.cgi?id=46428 If one of the php-knowledgable peeps can take a look at this (sadly my php-foo is quite weak). -- Leslie Carr Wikimedia Foundation AS 14907, 43821 http://as14907.peeringdb.com/ ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] [Wmfall] (Cross-posting) Fw: Parsoid blog post job opening
Do you want to mention node.js in the job posting? It seems to be a big buzzword :) On Mon, Mar 4, 2013 at 3:41 PM, Ori Livneh oliv...@wikimedia.org wrote: Apologies for cross-posting. I'm forwarding the note below from Gabriel because I reallly think it's so important that this gets circulated widely. The set of skills required for contributing to Parsoid is somewhat more specialized than the set we typically recruit for, so it's really important for this to be distributed far and wide. -- Ori Livneh Forwarded message: From: Gabriel Wicke gwi...@wikimedia.org Reply To: Wikitext-l wikitex...@lists.wikimedia.org To: Wikitext-l wikitex...@lists.wikimedia.org Date: Monday, March 4, 2013 12:01:40 PM Subject: [Wikitext-l] Parsoid blog post job opening Hi, we just published a blog post about Parsoid at http://blog.wikimedia.org/2013/03/04/parsoid-how-wikipedia-catches-up-with-the-web/ We are also looking for somebody to join us in our Parsoid adventure: http://hire.jobvite.com/Jobvite/Job.aspx?j=oIsbXfw2c=qSa9VfwQ Cheers, Gabriel ___ Wikitext-l mailing list wikitex...@lists.wikimedia.org (mailto:wikitex...@lists.wikimedia.org) https://lists.wikimedia.org/mailman/listinfo/wikitext-l ___ Wmfall mailing list wmf...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wmfall -- Leslie Carr Wikimedia Foundation AS 14907, 43821 http://as14907.peeringdb.com/ ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Nagios is dead, long live icinga!
On Tue, Feb 26, 2013 at 8:35 PM, Jeremy Baron jer...@tuxmachine.com wrote: On Feb 26, 2013 11:25 PM, Matthew Bowker matthewrbowker.w...@me.com wrote: I hate to be that guy, but is it supposed to be password protected? Is there somewhere non-ops people can look for server status, or is http://status.wikimedia.org it? try HTTP instead of HTTPS. (I don't know anything about why they're not the same or how long they've been like that.) On a slightly un-related note, nagios-wm is still in the IRC channels. Does that mean Nagios will still be providing the IRC feed? There's also an icinga-wm. Not sure how long we'll have both. If I had to guess I'd say having then both is intentional for now. Yep :) I haven't killed off nagios and nagios-wm completely yet, just in case there's a catastrophic bug and I have to switch us back. I am planning on completely killing off nagios in a few days, when we are certain that there are 0 remaining icinga bugs. -Jeremy ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l -- Leslie Carr Wikimedia Foundation AS 14907, 43821 http://as14907.peeringdb.com/ ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Nagios is dead, long live icinga!
On Wed, Feb 27, 2013 at 8:17 AM, MZMcBride z...@mzmcbride.com wrote: Jay Ashworth wrote: https://icinga.wikimedia.com is now confirmed accessible, yes. You mean https://icinga.wikimedia.org. One issue, possibly specific to me: I'm old, my laptop has a 12 screen. So I am prone to put Firefox in Zoom Text Only mode, and run the zoom up to read stuff. Icinga handles that pretty well, in our implementation, with one exception: that tab, top right, that has the icinga logo in it also appears to contain some summary data, and that part blows off the right edge of the screen (though it impinges on the Icinga text logo even at normal size). Definitely not specific to you. I had a similar issue. Probably should be reported upstream. Not sure where specifically, sorry. http://www.icinga.org/faq/how-to-report-a-bug/ is how to report upstream bugs. And that service that's running status. is very spiffy; is that commercial? Yes, I believe so. It was previously called WatchMouse. Now it's called Nimsoft, I think, though they appear to have been bought out by someone. Some quick googling should let you know. Why is the Wikimedia Foundation using this (non-free) service? As I recall, it was donated. But the information surrounding status.wikimedia.org has always been kind of sketchy. Status.wikimedia.org is half fixed and i'm working on completing the fix. It is a donated service and is awesome. We need out of network monitoring (because in network obviously has flaws). We would love tohave any other out of network monitoring as well, and there are no free services that have global probes with layer 7 monitoring. If anyone knows any other commercial services that are willing to donate, please let me know. Leslie MZMcBride ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l -- Leslie Carr Wikimedia Foundation AS 14907, 43821 http://as14907.peeringdb.com/ ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Nagios is dead, long live icinga!
As some may have noticed, we are phasing out nagios in favor of icinga ( https://www.icinga.org/ ) nagios.wikimedia.org now redirects to icinga.wikimedia.org ! Please let us know if you notice anything that has broken or is inconsistent. Thanks Leslie -- Leslie Carr Wikimedia Foundation AS 14907, 43821 http://as14907.peeringdb.com/ ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Nagios is dead, long live icinga!
Icinga is public. On Feb 26, 2013 7:49 PM, Liangent liang...@gmail.com wrote: On Wed, Feb 27, 2013 at 9:32 AM, Leslie Carr lc...@wikimedia.org wrote: As some may have noticed, we are phasing out nagios in favor of icinga ( https://www.icinga.org/ ) nagios.wikimedia.org now redirects to icinga.wikimedia.org ! Please let us know if you notice anything that has broken or is inconsistent. So now there's no public view of server monitoring info? http://status.wikimedia.org/ always shows nagios as disrupted now. -Liangent Thanks Leslie -- Leslie Carr Wikimedia Foundation AS 14907, 43821 http://as14907.peeringdb.com/ ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Nagios is dead, long live icinga!
Thanks - I'll try to get status.wikimedia updated in the morning. Can you try with https now ? I had forgotten to reload apache when pushing out a change to the https config (to allow https without login). You can also use http. On Tue, Feb 26, 2013 at 8:46 PM, Matthew Flaschen mflasc...@wikimedia.org wrote: On 02/26/2013 11:35 PM, Jeremy Baron wrote: On Feb 26, 2013 11:25 PM, Matthew Bowker matthewrbowker.w...@me.com wrote: I hate to be that guy, but is it supposed to be password protected? Is there somewhere non-ops people can look for server status, or is http://status.wikimedia.org it? try HTTP instead of HTTPS. (I don't know anything about why they're not the same or how long they've been like that.) Nagios shows as disruption on the HTTP (http://status.wikimedia.org/) Matt Flaschen ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l -- Leslie Carr Wikimedia Foundation AS 14907, 43821 http://as14907.peeringdb.com/ ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] SSL certificate
On Tue, Jan 22, 2013 at 11:28 AM, Manuel Schneider manuel.schnei...@wikimedia.ch wrote: I'd like to notify you that thanks to the generosity and cooperation if the previous owner, wikimania.org and wikimania.com are now owned by Wikimedia CH. The domain is currently set up in the same way as it was before but we have now the possibility tu use ssl.wikimania.org for the registrations and scholarship tools already hosted by Wikimedia CH. Are you interested in transferring the domain to the WMF which already has a SSL cluster and an established procedure for handling new ssl certificates? Thanks Leslie Regards, Manuel -- Wikimedia CH - Verein zur Förderung Freien Wissens Lausanne, +41 (21) 34066-22 - www.wikimedia.ch ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l -- Leslie Carr Wikimedia Foundation AS 14907, 43821 http://as14907.peeringdb.com/ ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] How to contribute to sysadmin / devops
On Wed, Jan 9, 2013 at 12:02 PM, Quim Gil q...@wikimedia.org wrote: On 01/08/2013 11:01 AM, Ryan Lane wrote: There's a list of TODO items: http://www.mediawiki.org/wiki/Wikimedia_Labs#TODO There's a list of proposals: http://www.mediawiki.org/wiki/Wikimedia_Labs#Proposals There's a list of Labs infrastructure bugs: https://bugzilla.wikimedia.org/buglist.cgi?list_id=171774resolution=---resolution=LATERresolution=DUPLICATEquery_format=advancedcomponent=Infrastructureproduct=Wikimedia%20Labs I think what we're mostly missing is a quick list of easy things to do or fix as a call to action. Can we define ONE task a good sysadmin could take here and now? Sure, if you want to copy the information from this ticket - that's a good task https://rt.wikimedia.org/Ticket/Display.html?id=4060 You have one presentation next week at the Wikipedia Engineering Meetup http://www.meetup.com/Wikipedia-Engineering-Meetup/events/89239012/ I have another one in few weeks at FOSDEM: https://www.mediawiki.org/wiki/Events/FOSDEM/2013_-_Lightning_-_Qgil#Inject_your_sysadmin_skills_to_Wikipedia I believe both will be recorded. It's a good excuse to find a little fishhook while the bigger net gets ready. Feasible? Otherwise I will forget about the topic until next month. :) -- Quim Gil Technical Contributor Coordinator @ Wikimedia Foundation http://www.mediawiki.org/wiki/User:Qgil ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l -- Leslie Carr Wikimedia Foundation AS 14907, 43821 http://as14907.peeringdb.com/ ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Video on mobile: Firefox works, way is paved for more browser support
On Wed, Dec 12, 2012 at 3:44 AM, Antoine Musso hashar+...@free.fr wrote: Le 12/12/12 00:15, Erik Moeller a écrit : Since there are multiple potential paths for changing the policy (keeping things ideologically pure, allowing conversion on ingestion, allowing h.264 but only for mobile, allowing h.264 for all devices, etc.), and since these issues are pretty contentious, it seems like a good candidate for an RFC which'll help determine if there's an obvious consensus path forward. Could we host h.264 videos and related transcoders in a country that does not recognize software patents? Fact for consideration: Currently our infrastructure is not set up/able to host originals in the Netherlands. And our storage infrastructure takes more than just one server ;) Hints: - I am not a lawyer - WMF has server in Netherlands, EU. -- Antoine hashar Musso ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l -- Leslie Carr Wikimedia Foundation AS 14907, 43821 http://as14907.peeringdb.com/ ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Proposed new WMF browser support framework for MediaWiki
On Wed, Nov 21, 2012 at 9:33 AM, James Forrester jforres...@wikimedia.org wrote: On 20 November 2012 23:54, Martijn Hoekstra martijnhoeks...@gmail.com wrote: I think a best of both worlds would be preferable. I haven't seen the stats, but I'd assume market share of IE 10 will be quite low. Still it would be silly to not strive to support it. Well, until this month IE 10 wasn't released (just a developer version; I wasn't counting these). Thus the current and immediately-previous versions for IE would have been 9 and 8. Supporting browsers before they're released is a nice-to-have and, as you say, sensible to get ahead of the work, but it's not as crucial as fixing live versions for millions of people. How about any browser released in the last n months whose browser family has more then x % market share plus any individual browser version with more then m % market share for some sensible figures n, x and m? Interesting idea. Perhaps x = 5, m = 1 and n = 12; with these numbers we'd get pretty much what I suggested, plus IE 7 and Opera 12. The cost of supporting these (especially IE 7) would be heroic in some areas, however - but that's what the local policies for different features are for, after all. I think this sounds like a great compromise (perhaps even with m = 2 ?) Leslie J. -- James D. Forrester Product Manager, VisualEditor Wikimedia Foundation, Inc. jforres...@wikimedia.org | @jdforrester ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l -- Leslie Carr Wikimedia Foundation AS 14907, 43821 http://as14907.peeringdb.com/ ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Proposed new WMF browser support framework for MediaWiki
would be very helpful. [*] - This is what is meant when people bemoan Android fragmentation. [+] - Ironically for a page about the VisualEditor, creating wikitext that it will likely forever struggle to edit. J. -- James D. Forrester Product Manager, VisualEditor Wikimedia Foundation, Inc. jforres...@wikimedia.org | @jdforrester ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l -- Leslie Carr Wikimedia Foundation AS 14907, 43821 http://as14907.peeringdb.com/ ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Contributing as Wikimedia employees
I don't think that using my Wikimedia address (like I am now) is meant to create a wall. I just use it because this is my job and I like to keep my email lives separate. The (WMF) notation is used by employees to notate that they are an employee and usually used for more official business. The convention is to use a separate account for personal purposes (like normal editing, instead of something official). If you think this is a major problem, these questions are more appropriate for wikimedia-l as they are not technical and instead policy :) On Sat, Nov 3, 2012 at 8:09 AM, Petr Bena benap...@gmail.com wrote: I think there is no need to make any walls between community and wmf. Main difference between volunteers and wmf employees is that they are paid for they work. I see no reason why someone should highlight that fact by using wmf e-mail or (WMF) in SUL (it appears as showing off to me more than anything useful) so it seems quite ok to me that they are using personal e-mails and don't try to be more different from volunteers. On Sat, Nov 3, 2012 at 1:20 PM, Antoine Musso hashar+...@free.fr wrote: Le 02/11/12 21:36, Quim Gil a écrit : Hi, is there a policy / recommendation about Wikimedia employees using wikimedia.org addesses when contributing code and participating in community activities as part of their paid work? Or has this topic been discussed in the past? I use a personal email dedicated to Wikimedia stuff, sounds to me I can talk about anything this way without embarrassing the Wikimedia Foundation for which I am a contractor. The wikimedia.org I mostly use it for internal stuff and to write to WMF employees and contractors. -- Antoine hashar Musso ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l -- Leslie Carr Wikimedia Foundation AS 14907, 43821 http://as14907.peeringdb.com/ ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Work offer inside
On Sat, Sep 1, 2012 at 1:53 PM, Mark Holmquist mtrac...@member.fsf.org wrote: As true as all this is, some of us would prefer to keep an advertising giant like Google out of our business as much as possible. Or alternatively, a non-free software giant like Google. But it comes to roughly the same conclusion. That's nice, but as a business decision the wikimedia foundation has decided to host our corporate email with Google. For personal mail we all have the choice of whatever system we would like, but this business decision has been made for us, and if someone wants a wikimedia.org address, I don't think it's an onerous burden to require that they use our current infrastructure to access it, instead of requiring us to do a lot of difficult workarounds. Unless I've missed something, using wikimedia.org for non-employees is a option, not a necessity. Leslie -- Mark Holmquist Contractor, Wikimedia Foundation mtrac...@member.fsf.org http://marktraceur.info ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l -- Leslie Carr Wikimedia Foundation AS 14907, 43821 http://as14907.peeringdb.com/ ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Work offer inside
On Sat, Sep 1, 2012 at 4:18 PM, Mark Holmquist mtrac...@member.fsf.org wrote: That's nice, but as a business decision the wikimedia foundation has decided to host our corporate email with Google. For personal mail we all have the choice of whatever system we would like, but this business decision has been made for us, and if someone wants a wikimedia.org address, I don't think it's an onerous burden to require that they use our current infrastructure to access it, instead of requiring us to do a lot of difficult workarounds. Unless I've missed something, using wikimedia.org for non-employees is a option, not a necessity. It was my understanding that part of this discussion was to require volunteers to use a specific mail server to post to the listbut now I can't find the message that gave me that impression, so maybe I've misunderstood the nature of the thread? I believe the nature was SPF checks for mail claiming to be sourced from wikimedia.org addresses. This would require an authoritative SMTP server but wouldn't prevent non @wikimedia.org email addresses from posting to the list. Leslie (I'm leaving out arguments about the decision to host with Google, but it seems like a relevant thing, perhaps there are archived discussions that I could read?) -- Mark Holmquist Contractor, Wikimedia Foundation mtrac...@member.fsf.org http://marktraceur.info ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l -- Leslie Carr Wikimedia Foundation AS 14907, 43821 http://as14907.peeringdb.com/ ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Lessons from the newcomer side of the Hackathon
== The combination of newcomers and experienced people seemed to work == We got two different notes in the exit survey about this -- one from a person who said they were happy working in the big open main room and didn't feel distracted by noise, and from another person who said they went off because they found the main room too noisy. I did really like being able to send people to nearby experienced folks to have a chat. This was especially helpful as I walked around and asked people what they wanted help on, or what they wanted to work on. I did notice some experienced people, by the second day, had wandered off to quieter rooms than the big main room. I'm glad we had those rooms. (I'd love to hear from those people if they felt pushed out, or if they instead felt happy that the quieter rooms were available.) I went off to a quieter room because I felt that the main room was too loud and busy, plus the lack of working wifi made working very difficult. The side room had just the right number of people and activity to make me feel like I could be productive, as well as speedy access. == We made a good impression by just running the event == One prospective attendee who, sadly, couldn't make it, indicated to me that just by reading the survey we sent to prospective attendees, and skimming the list of tasks, it was something that they'd be interested in attending, and that it was great that such an event was going on. In particular, they suggested it felt more like a play-with-stuff-a-thon rather than a hack-a-thon, and described that as making them feel welcome. If anything, we should have capitalized on this more. I heard from other prospective attendees that they didn't know the Hackathon was intended to be newcomer-friendly this year. Personally, I think the term Hackathon gives an exclusionary vibe, and that a newcomer-oriented event should have a different name. For example, Boston Ruby recently started using project night at our (OpenHatch's) suggestion and it seems to have gone well for them: https://openhatch.org/blog/2012/the-steps-boston-ruby-is-taking-to-become-friendly-to-beginners/ I like the idea of calling it project night or tech days or something. == Logistics concerns == The room that we had agreed we would use turned out not to have power strips lining the bottom of every table, so we switched rooms and had to update signs across the event. Some exit survey respondents indicated they wanted the event to start later in the morning, and that they wanted the room to not close at 6pm. I would second that. Early mornings are tough for me, being a lazy west coast person. == Tutorials can use TAs == On the second day, I found volunteeres to be TAs for the tutorials. Their job was to wander around and help people with environment problems or people just having trouble following along because e.g. their web browser was different than the one being used by the presenter. Another difficulty I found was that sometimes a tutorial speaker wasn't loud enough to be audible in the back of the room. This is above the tasks I had labeled as needed for a Talkmeister: http://wikimania2012.wikimedia.org/wiki/Hackathon/Volunteers#Talkmeister Also, people who are having problem following along during a tutorial don't always speak up. I'm glad we added the TAs, although I think further work is required to find out how to non-intrusively convince people that asking questions is okay. The best way I've seen is to have a very small group, no bigger than 10, preferably about six people. I almost wonder if we'd be better-served to use pre-recorded video tutorials with a lot of TAs available, rather than live lecturers. Then we could easily have small group rooms, and could pause the video. I like this idea - as well as the idea of having informal tutoring - like a table of people who want to learn about a topic I am experienced at (like puppet) and then doing some more one on one work. Maybe some signs on tables like Wednesday afternoon, Bot table to encourage folks interested in one topic to join up together? Leslie -- Leslie Carr Wikimedia Foundation AS 14907, 43821 http://as14907.peeringdb.com/ ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] suggestion: replace CAPTCHA with better approaches
snip Can you provide references? What is the basis of the spam/work to do? Maybe we could make their lives easier through creating a new tool, or better anti-spam measures. snip But lastly, there is a very important fact in captcha cracking you're missing. Human aided captcha cracking already exists. No matter how hard you make it for a computer to understand captchas there are already bots breaking captchas by sending the captcha back to some home server, giving the captcha to either a badly paid turk worker or tricking some person wanting to look at porn into solving the captcha, then sending the solution back to the bot and breaking through the captcha. At this point Pick the kitten captchas will be less vulnerable than this proposal. (And even those can be broken with a human in the mix). I agree that better tools and non captcha based tech are the way to go. At a previously very-spammed company, we learned how no matter how badly you distort the captchas, it doesn't matter, as if it's human readable, humans can pick out the text. Look how cheap it is to get a human to do your captchas for the spammers! http://decaptchablog.com/decaptcher-services Technical/social solutions such as helping the community patrol and catch spam and automated detection of spammy language are the way to go Leslie P.S. This is my own personal opinion and not the opinion of the foundation P.P.S. I also vote for any proposal which increases the number of kittens I get to view on a daily basis. -- ~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name] ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l -- Leslie Carr Wikimedia Foundation AS 14907, 43821 http://as14907.peeringdb.com/ ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Barkeep code review tool
On Mon, Jul 2, 2012 at 9:59 PM, Rob Lanphier ro...@wikimedia.org wrote: On Mon, Jul 2, 2012 at 9:19 PM, Diederik van Liere dvanli...@gmail.com wrote: I became curious with these statements regarding self-review (committer==reviewer) and so I ran a couple of queries against the gerrit database to see how often this occurs: 1) For the puppet repo, 84.1% of the commits is self-reviewed. Yeah, I don't think Ops is proud of this, but from my understanding, it's very difficult to develop for puppet without committing and seeing what happens. It's possible, but it's definitely not as productive. I would agree with Ryan and say that it's not that we're not proud of this, it's that we have a different workflow. There's a lot of repetitive style work in our job (putting new servers in puppet and dhcp files, for example). These minor commits don't need any major review. Major changes can be tested in labs, usually have someone else check them out, and for many changes the worst breakage that happens is that puppet stops running(instead of a dead site). Leslie -- Leslie Carr Wikimedia Foundation AS 14907, 43821 http://as14907.peeringdb.com/ ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] potential network issue due to packet losses
On Tue, Jul 3, 2012 at 2:05 PM, Marcin Cieslak sa...@saper.info wrote: Leslie Carr lc...@wikimedia.org wrote: When in a firewall filter, packets are rejected (which sends an ICMP rejected notice), the routing engine can receive too many of these requests, causing the routing engine to choke on its backlog of requests. Leslie, thanks for excellent update! Was is something similar to ICMP storm caused by unreachables (similar to the problems caused by subnet-directed packets in the old days) that even ICMP rate limiting didn't help? Sadly ICMP rate limiting only counts for ICMP packets incoming to RE, outgoing packets are processed and created before any filters kick in. //Saper ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l -- Leslie Carr Wikimedia Foundation AS 14907, 43821 http://as14907.peeringdb.com/ ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] potential network issue due to packet losses
Hi Everyone - This issue appears to be patched up. Please let me know immediately if you see any more network issues. Longer explanation - the root cause of issues we saw today was a fixed router bug (our code version should not have been affected). When in a firewall filter, packets are rejected (which sends an ICMP rejected notice), the routing engine can receive too many of these requests, causing the routing engine to choke on its backlog of requests. This backup caused packets destined to the routing engine to drop. This caused several issues as VRRP, BFD, and BGP all stopped processing. For a currently unknown reason, OSPF was unaffected. After correcting this, for an unknown reason, one vlan was not processing packets destined to the routing engine, while the other vlans were properly processing these packets. This caused both of our main routers on that vlan to claim VRRP mastership - basically causing two routers to claim to be the default gateway for the subnet which contains the LVS servers. After disabling VRRP, the router still was not passing traffic destined to this vlan. Turning down the vlan and then turning it back up and adding and removing an arp policer (yes, turning it off and on again) fixed this situation. This vlan issue caused a public facing outage. The current status is that everything is working and cr2-pmtpa is the VRRP master for all of Tampa. We were lucky that this bug hit cr1-sdtpa much harder than cr2-pmtpa. Eqiad was not affected, and while we cannot yet say definitively, I believe it is due to the more powerful routing engines and more robust network design of the eqiad datacenter and routers. Software upgrades and configuration changes should fix this issue in Tampa. A possible fix would be hardware upgrades of the core routers, however it may be both prohibitively expensive and require some downtime for important machines in pmtpa. Leslie On Mon, Jul 2, 2012 at 3:03 PM, Ct Woo ct...@wikimedia.org wrote: All, The Technical Operations team noticed abnormal network package losses sometime after yesterday's 'leap second' switch (midnight UTC). While it does not seem to impact the site availability at this moment, it is a concern. We are still not sure if is even related to the 'leap second' switch yet. Leslie has opened a ticket with our network equipment provider and together with Mark, they have been working with them to pinpoint the problem since this morning. It is possible that they might induce some latency/issue during the troubleshooting process. If you do experience anything abnormal, please let us know (email to o...@wikimedia.org or find us at the #wikimedia-operations IRC channel). Thanks, CT ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l -- Leslie Carr Wikimedia Foundation AS 14907, 43821 http://as14907.peeringdb.com/ ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Relations with freenode and wikimedia
On Thu, Jun 21, 2012 at 11:35 PM, Sébastien Santoro dereck...@espace-win.org wrote: On Fri, Jun 22, 2012 at 3:33 AM, Petr Bena benap...@gmail.com wrote: Actually when I talked to freenode staff, there were quite interested in this. They don't have so many servers and wikimedia is well known project with established technical infrastructure. Even if they needed root, they could use puppet to set up the system to their needs and there are many folks around, who would be happy to help them do that. If there were some technical resources we could offer them, it's definitely worth of asking. Being a donor of servers means, wikimedia project would be listed together with our logo on their donor page as a top donor and that would improve the overall look of our project which is heavily using their network. You still have to demonstrate how the technical community will deal with a 3 months 25 to 75 Mbps DDoS attack targetted to IRC facilities. While I am not speaking for server hardening, our network can handle an extra 75 Mbps without a problem. However, this is a moot point if the community decides we want to talk, we in Operations can talk with freenode operations people and see what is safely mutually possible. Leslie It's the kind of attack waves who made 3 universities, one residential ISP and one dedicated servers provider (which is by the way one of the first in Europe, it's OVH) to leave UnderNet 10 years ago. I'm aware Freenode isn't currently the preferred attack playground but I'm not comfortable to excessively affect our network strength. To be an operator on one server is different to have to manage the issues at an upstream NOC level. -- Sébastien Santoro aka Dereckson http://www.dereckson.be/ ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l -- Leslie Carr Wikimedia Foundation AS 14907, 43821 http://as14907.peeringdb.com/ ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Request for data from Wikimedia Foundation for academic research
Pradeep - You may have better luck with this request at a network specific group such as nanog, arin, or ripe. A group such as Arbor Networks may also have a large amount of information on this request. I'm not the end-all of this information but I believe that it would be both non-trivial and a possible violation of user privacy. Best of luck! Leslie On Thu, Jun 14, 2012 at 2:58 AM, Pradeep Bangera pradeep.bang...@imdea.org wrote: Hello Wikimedia's system administrators and developers, I am a PhD student from Institute IMDEA Networks, Spain. I very much appreciate the data that you have published in Wikimedia Report Card. I am writing this email as a kind request for a possible cooperation for assisting me in my research work by sharing your data without violating anyone's privacy. I have a task of developing a list of Internet Service Providers (ISPs) around the globe for 2012. One way of doing it is by mapping the IP addresses of the internet users who visit your websites to their corresponding Autonomous System Numbers (ASNs) of the ISPs. For this I need to have IP address dataset logged by your web server in 2012 and certainly I do not seek it (IPs) being well aware of the privacy concerns of any website companies. So instead of the IP addresses, if you can cooperate in running a simple bash script (which I will send if you agree) on my behalf which will map the IP address (2012 recorded) from your database to its corresponding ASN and handover the ASNs dataset to me, I will be thankful and greatly appreciate for your time and cooperation. Awaiting for your reply. Thanks regards Pradeep Bangera PhD student Institute IMDEA Networks Madrid, Spain Ph: +34 914 816 986 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l -- Leslie Carr Wikimedia Foundation AS 14907, 43821 http://as14907.peeringdb.com/ ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] [Wikimedia-l] Update on IPv6
On Sat, Jun 2, 2012 at 6:13 AM, Anthony wikim...@inbox.org wrote: On Sat, Jun 2, 2012 at 8:49 AM, Thomas Dalton thomas.dal...@gmail.com wrote: On 2 June 2012 13:44, Anthony wikim...@inbox.org wrote: On Fri, Jun 1, 2012 at 7:27 PM, John Du Hart compwhi...@gmail.com wrote: What personal information do you think is contained in an IPv6 address? Don't they sometimes contain MAC address information? I don't know, but I wouldn't consider my MAC address to be personal information... you might be able to work out what brand of computer I'm using, but I can live with that. I think that having a problem with the implementation of IPv6 is about 10 years too late now ;) The IPv4 space is being exhausted, and we're going to soon run into the opposite problem that IPv4 addresses will be not identifiable enough as ISP's use NAT. If someone cares about their mac address information, they can use privacy extensions - http://en.wikipedia.org/wiki/Ipv6#Privacy . Considering that in the vast, vast majority of the consumer (versus production) world, you have to purposefully enable IPv6 (usually with some sort of tunneling), and that these are turned on in most operating systems by default, mac addressing is starting to only become applicable in production environments. Leslie -- Leslie Carr Wikimedia Foundation AS 14907, 43821 http://as14907.peeringdb.com/ ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Welcome, Chris Steipp
Welcome! On Mon, Apr 16, 2012 at 10:32 AM, Sumana Harihareswara suma...@wikimedia.org wrote: On 04/16/2012 12:41 PM, Rob Lanphier wrote: Hi everyone, I’d like to introduce Chris Steipp, who starts today as our Senior Security Engineer. Looking forward to working with you, Chris. Welcome! -- Sumana Harihareswara Volunteer Development Coordinator Wikimedia Foundation ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l -- Leslie Carr Wikimedia Foundation AS 14907, 43821 http://as14907.peeringdb.com/ ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] rsync on scap/sync reporting 'no space left on device' for a lot of hosts
It appears that there are a few issues #1 the cleanup cron is only looking for php* and there are many older files named timeline* On some machines /tmp is a separate partition, but / is still filled up. This appears to be due to a huge amount of php errors filling the logs example below : Apr 2 20:32:46 mw21 apache2[17566]: PHP Warning: readdir() expects parameter 1 to be resource, boolean given in /usr/local/apache/common-local/php-1.19/extensions/ConfirmEdit/FancyCaptcha.class.php on line 100 Can someone check out the php errors? On Mon, Apr 2, 2012 at 4:19 PM, Arthur Richards aricha...@wikimedia.org wrote: I just ran scap and saw the following for a lot of hosts: srv285: rsync: write failed on /usr/local/apache/common-local/php-1.19/cache/l10n/l10n_cache-ab.cdb: No space left on device (28) srv285: rsync error: error in file IO (code 11) at receiver.c(302) [receiver=3.0.7] srv285: rsync: connection unexpectedly closed (2051 bytes received so far) [generator] srv285: rsync error: error in rsync protocol data stream (code 12) at io.c(601) [generator=3.0.7] Also, on configchange: mw21: rsync: write failed on /apache/common-local/wmf-config/CommonSettings.php: No space left on device (28) mw21: rsync error: error in file IO (code 11) at receiver.c(302) [receiver=3.0.7] mw21: rsync: connection unexpectedly closed (37 bytes received so far) [generator] mw21: rsync error: error in rsync protocol data stream (code 12) at io.c(601) [generator=3.0.7] Not sure if this is a problem and/or if others are aware/working on it, but thought I'd mention it. -- Arthur Richards Software Engineer, Mobile [[User:Awjrichards]] IRC: awjr +1-415-839-6885 x6687 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l -- Leslie Carr Wikimedia Foundation AS 14907, 43821 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Time to redirect to https by default?
On Sun, Apr 1, 2012 at 1:14 PM, Ryan Lane rlan...@gmail.com wrote: TL;DR: we have no plans for anonymous HTTPS by default, but will eventually default to HTTPS for logged-in users. 1. It would require an ssl terminator on every frontend cache. The ssl terminators eat memory, which is also what the frontend caches do. 2. HTTPS dramatically increases latency, which would be kind of painful for mobile. Without getting into how other countries censor data (boo!) I agree with the first two points. SSL terminators are much more memory and cpu intensive which would require many more machines. Also there are more RTT's required for https/ssl and our ping latency is not very good since we do not have a very geographically diverse infrastructure. The two solutions for this are #1 more and beefier machines and #2 caching centers in various locations physically closer to users (which also requires a lot of #1). Sadly the biggest drawback of these two points is that they both cost a lot of money and that would mean a lot more pop up banners of Jimmy asking for cash :( Leslie P.S. I peronally like the idea of a cookie that you can check box at the top of the page (one time showing only perhaps?) that would default send users to https upon request. However I don't think we can do this with our current infrastructure due to the above issues. 3. Some countries may completely block HTTPS, but allow HTTP to our sites so that they can track users. Is it better for us to provide them content, or protect their privacy? 4. It's still possible for governments to see that people are going to wikimedia sites when using HTTPS, so it's still possible to oppress people for trying to visit sites that are disallowed. On Sun, Apr 1, 2012 at 7:06 PM, David Gerard dger...@gmail.com wrote: Lots of monitoring going into place: https://en.wikipedia.org/wiki/Wikipedia:List_of_articles_censored_in_Saudi_Arabia http://www.bbc.co.uk/news/uk-politics-17576745 What are the current technical barriers to redirection to https by default? - d. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l -- Leslie Carr Wikimedia Foundation AS 14907, 43821 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Wikimedia and IPv6
Speaking as a network person and someone who is working on from the operations side, we really want to do this and make it work. However, we have a lot of work to do and that's why we can't guarantee we'll make the date. We definitely don't want to commit to something and then miss the launch. Our load balancers all need to be upgraded and we'll have a lot of testing to do. I'm not sure about all of the backend developer work to be done, either. On Sat, Mar 24, 2012 at 3:38 AM, Maarten Dammers maar...@mdammers.nl wrote: Hi guys, Last year I send an email about World IPv6 day [1]. Got some responses, but nothing really happened and we missed. it. This year we have the World IPv6 launch and I hope Wikimedia will participate. I wonder if deploying ipv6 has priority at the Wikimedia Foundation. I put Erik on the cc because he can probably answer that question. This would be a good way to encourage innovation [2] Maarten [1] http://lists.wikimedia.org/pipermail/wikitech-l/2011-January/051190.html [2] http://commons.wikimedia.org/wiki/File:WMF_StrategicPlan2011_24pp.pdf Op 24-3-2012 6:13, MZMcBride schreef: Hi. Someone claiming to be ARIN's President and CEO John Curran posted the following to Meta-Wiki recently: --- As many folks are aware, the Internet has been a remarkably successful phenomena. One consequence of this success is that the present underlying Internet Protocol (IP version 4, or IPv4) is reaching the deployment limits on the number of devices that can be uniquely addressed. The upper limit is approx 4.3 Billion devices. To allow the Internet to continue to expand, it is now necessary to begin using larger IP addresses for servers, these new addresses are known as IP version 6, or IPv6. It is particularly important for major Internet content providers to make this transition, since new users are now being connected with IPv6 and must go through transition gateways to reach sites which are not using both IPv4 and IPv6. On 6 June 2012, nearly one thousand web sites are permanently turning on IPv6 as part of the Internet Society's World IPv6 Launch event. http://www.worldipv6launch.org/ This includes Google, Facebook, and other major providers. Wikipedia has been working on IPv6 support for some time, and it would be good if a commitment to having IPv6 by this date could be made. /John John Curran, President and CEO, ARIN 12.174.51.2 00:37, 22 March 2012 (UTC) --- Source: https://meta.wikimedia.org/w/index.php?title=Meta:Babeloldid=3588620#Transi tion_of_the_Internet_from_IPv4_to_IPv6_.26_Wikipedia_support_for_IPv6 Any thoughts on this from ops? MZMcBride ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l -- Leslie Carr Wikimedia Foundation AS 14907, 43821 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Video codecs and mobile
On Tue, Mar 20, 2012 at 6:13 AM, Victor Vasiliev vasi...@gmail.com wrote: On Tue, Mar 20, 2012 at 5:24 AM, Brion Vibber br...@pobox.com wrote: Is it time for us to think about H.264 encoding on our own videos? Hello, Brion. I think it is time for Apple to support Wikipedia videos. I suggest that we view the thing from this point of view — Apple do not run a Top-10 site, we do. That would be nice but is completely unrealistic. Apple doesn't support Flash and that's on a lot more sites of the world. They don't bow to pressure from major players who could make them $$$, and they are certainly not going to bow to us. Besides, the lack of wikipedia videos does not appear to be hurting their performance. Apple has a 30% market share for US smart phones[1] and their global tablet share is 58% [2] Since such a huge market share basically requires H.264 encoding, I think we should bite the bullet and go for it. If suddenly they start charging, we can drop it immediately. [1] http://www.engadget.com/2012/03/07/comscore-us-subscriber-count-reaches-100-million-android-and-i/ [2] http://www.engadget.com/2012/01/26/strategy-analytics-apple-still-owns-tablet-market-but-android/ -- Leslie Carr Wikimedia Foundation AS 14907, 43821 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Welcome Lindsey Smith - Mobile UI/UX Contractor
Will the border collies be visiting the office? On Thu, Mar 1, 2012 at 10:01 AM, Sumana Harihareswara suma...@wikimedia.org wrote: On 03/01/2012 09:58 AM, Tomasz Finc wrote: Hi everyone, I'm pleased to welcome a new member of to the mobile engineering team. Lindsey Smith started this week as our new Mobile UI/UX contractor. She'll working with us in San Francisco helping us flush out the look, feel, and experience across all of our mobile projects. This fits a critical need of the mobile team which has grown steadily over the last couple of months in development capacity but has not grown enough in design capacity. With the addition of Lindsey we'll have some keen eyes on such key projects as our new navigational system, image uploads, and numerous future projects. Lindsey joins us as a mobile designer from Dallas, Texas who's recently moved to the bay area with her husband and 2 border collies. She's worked for Semaphore Mobile on a range of client applications from restaurant review service Zagat to custom remote control interfaces for Traxxas cars[1]. Her educational background is in Software Engineering but she found her passion to be in UI/UX. Welcome Lindsey! [1] http://lsmith.me/projects --tomasz Congrats and welcome, Lindsey! I look forward to working with you. -- Sumana Harihareswara Volunteer Development Coordinator Wikimedia Foundation http://www.mediawiki.org/wiki/User:Sumanah ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l -- Leslie Carr Wikimedia Foundation AS 14907, 43821 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Decentralized data center
On Mon, Jan 23, 2012 at 9:38 AM, cyrano cyrano.faw...@gmail.com wrote: Hello, this topic is from foundation-l, I think it is more suited on wikitech-l. Message original What about sharing the whole databases among the millions of users, in some p2p net with a lot of redundancies?, something like a dense, cloudy internet of databases who remains whole even if it looses part of itself? Does it sound unwordly? It could be a good complement to the server based versions. this sounds nice but just wouldn't work at all. we need to have reliable databases with a consistant latency. Le 22/01/2012 20:50, Jussi-Ville Heiskanen a écrit : The simple option that will just blow all this talk fo lobbying away, is to migrate outside US jurisdiction entirely. It does entail some costs, and may well not be optimal, on many fronts. s/some/lots of/ A medium option is to do a plan on the lines of the actions that Google has already put into force, of diversifying datacenters that have our non-fungible assets, so that for enforcement they would have to invade sovreign territory. But for a non-profit, our best line would be to say that we are making those plans, but actually want to keep the US have the PR benefit of being able to say that WMF like entities find the US best to be incorporated in. And then grin very hard, so they know we mean business. Follow up with saying the very real contingency plans can not wait on their realizing they have the wrong end of the stick, so we have to act now. So we will put a few fallback datacenters elsewhere, just so our various communities and chapters realize we aren't going to be bullied by US jurisdiction. But we have a much more expansive plan which we tell we will eventually realize. But the legislators in the US have to understand we are doing this all so they realize what they are working on is harmful to prosperity around the globe. again, expensive! And if they play ball, (we won't give a cent of tribute, sorry) we will not accelerate the rate at which we realize the full international nature of the Wikimedia Foundation. That is pretty much the line of education that might be effective, without costing the Foundation a single backhander. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l -- Leslie Carr Wikimedia Foundation AS 14907, 43821 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Wording (RE: SOPA banner implementation)
On Tue, Jan 17, 2012 at 7:31 AM, Happy Melon happy.melon.w...@gmail.com wrote: On 17 January 2012 15:23, Markus Krötzsch mar...@semantic-mediawiki.orgwrote: On 17/01/12 15:01, Daniel Barrett wrote: http://test.wikipedia.org/?banner=blackout As a writer, I believe the current message (The Wikipedia community has authorized...) is long and wordy and therefore not likely to be read by most users. I recommend shortening simplifying it. Here's an example that removes 30+ words and preserves the meaning: WE NEED YOU TO PROTECT FREE SPEECH ONLINE The English Wikipedia is blacked out for 24 hours to protest two bills before the United States Congress, known as SOPA and PIPA. These bills endanger free speech in the United States and abroad, setting a frightening precedent of Internet censorship for the world. Today we ask you to take action. [[Take action]] [[Learn more]] +1 The first sentence is really too complicated. Markus +1 for the first sentence. The question of authorised *who*? is one that only serves to distract attention from the main message. I prefer the current wording of the legislation description: I don't think people will mind reading a few extra words there... it's not like they have anything else to read!! :-) I like this wording better as well. If we want to discuss the authorization, the learn more link might be a better place to detail it. That said, I'm sure this list is not the best place to discuss the banner wording. Where is? --HM ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l -- Leslie Carr Wikimedia Foundation AS 14907, 43821 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Wikipedia SSL certs changed before expiration
On Tue, Dec 20, 2011 at 7:37 AM, Platonides platoni...@gmail.com wrote: On 20/12/11 16:18, Michael Becker wrote: I'm running a firefox plugin called certpartol which alerts me to unusual ssl cert changes. The existing cert signed by GeoTrust, Inc. wasn't set to expire until 2016-07-19 02:17:12. The new cert is signed by DigiCert Inc. I just want to make sure this is an intentional change and not a fake cert. I took a screenshot of the certpatrol warning @ http://img204.imageshack.us/img204/8463/screenshot20111220at953.png It's legitimate. The certificate was changed last week to a new one which also supports *.m.wikipedia.org Platonides explained it perfectly :) You will also notice a change in the near-ish term future when we switch to a cert with a different certificate. I have now installed Certpatrol -- awesome plugin! -- Leslie Carr Wikimedia Foundation AS 14907, 43821 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Wikipedia SSL certs changed before expiration
On Tue, Dec 20, 2011 at 10:15 AM, Leslie Carr lc...@wikimedia.org wrote: On Tue, Dec 20, 2011 at 7:37 AM, Platonides platoni...@gmail.com wrote: On 20/12/11 16:18, Michael Becker wrote: I'm running a firefox plugin called certpartol which alerts me to unusual ssl cert changes. The existing cert signed by GeoTrust, Inc. wasn't set to expire until 2016-07-19 02:17:12. The new cert is signed by DigiCert Inc. I just want to make sure this is an intentional change and not a fake cert. I took a screenshot of the certpatrol warning @ http://img204.imageshack.us/img204/8463/screenshot20111220at953.png It's legitimate. The certificate was changed last week to a new one which also supports *.m.wikipedia.org Platonides explained it perfectly :) You will also notice a change in the near-ish term future when we switch to a cert with a different certificate. different expiration date, not a different certificate. Going to go find coffee now... I have now installed Certpatrol -- awesome plugin! -- Leslie Carr Wikimedia Foundation AS 14907, 43821 -- Leslie Carr Wikimedia Foundation AS 14907, 43821 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] irc bot
I, for one, appreciate all of the hard work Petr has put into this new bot and am enjoying the functionality. Thanks Petr! -- Leslie Carr Wikimedia Foundation AS 14907, 43821 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Reason for having php5-common pinned?
Do we have a reason we have php5-common pinned in puppet? (see generic-definitions.pp::145 generic::webserver::php5 ) The reason I ask is that with this, another generic definition (generic::webserver::php5-mysql) breaks due to the dependancy of 5.3.2-2wm1 , while the pinning causes the installation of 5.3.2-1ubuntu4.10 I would change the generic::webserver::php5 definition to remove the pin, but I want to make sure that nothing breaks first. Leslie -- Leslie Carr Wikimedia Foundation AS 14907, 43821 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
