I am a Software Engineer on the Wikimedia Release-Engineering-Team.
Does this scap config take effect in the source as well as the target of the deploy?
Tue, Jul 16
Mon, Jul 15
So it seems that it's not possible to override the policy on form editing. @epriestley: shouldn't this use the application "can edit / can configure application" policy for the transactions application? It doesn't seem to actually work that way although it looks like it should from reading the code.
Thu, Jul 11
@MarcoAurelio Can you edit those forms now?
@MarcoAurelio I'll see what I can do to make this work.
|25||phabricator||infrastructure/javelin/markup.php : 22||CelerityStaticResourceResponse::addMetadata()|
|24||phabricator||view/AphrontTagView.php : 161||javelin_tag()|
|23||phabricator||infrastructure/markup/rule/PhabricatorObjectRemarkupRule.php : 177||AphrontTagView::render()|
|22||phabricator||infrastructure/markup/rule/PhabricatorObjectRemarkupRule.php : 108||PhabricatorObjectRemarkupRule::renderHovertag()|
|21||phabricator||infrastructure/markup/rule/PhabricatorObjectRemarkupRule.php : 84||PhabricatorObjectRemarkupRule::renderObjectRef()|
|20||phabricator||infrastructure/markup/rule/PhabricatorObjectRemarkupRule.php : 389||PhabricatorObjectRemarkupRule::renderObjectRefForAnyMedia()|
|19||phutil||markup/engine/PhutilRemarkupEngine.php : 293||PhabricatorObjectRemarkupRule::didMarkupText()|
|18||phabricator||infrastructure/markup/PhabricatorMarkupEngine.php : 144||PhutilRemarkupEngine::postprocessText()|
|17||phabricator||infrastructure/markup/PhabricatorMarkupEngine.php : 73||PhabricatorMarkupEngine::process()|
|16||phabricator||infrastructure/markup/view/PHUIRemarkupView.php : 90||PhabricatorMarkupEngine::renderOneObject()|
|15||phabricator||view/AphrontView.php : 222||PHUIRemarkupView::render()|
|14||phutil||markup/render.php : 111||AphrontView::producePhutilSafeHTML()|
|12||phutil||markup/render.php : 181||array_map()|
|11||phabricator||aphront/response/AphrontResponse.php : 317||hsprintf()|
|9||phabricator||aphront/response/AphrontResponse.php : 333||array_walk_recursive()|
|8||phabricator||applications/celerity/CelerityStaticResourceResponse.php : 279||AphrontResponse::encodeJSONForHTTPResponse()|
|7||phabricator||view/page/PhabricatorStandardPageView.php : 583||CelerityStaticResourceResponse::renderHTMLFooter()|
|6||phabricator||view/page/AphrontPageView.php : 51||PhabricatorStandardPageView::getTail()|
|5||phabricator||view/page/PhabricatorStandardPageView.php : 889||AphrontPageView::render()|
|4||phabricator||aphront/configuration/AphrontApplicationConfiguration.php : 715||PhabricatorStandardPageView::produceAphrontResponse()|
|3||phabricator||aphront/configuration/AphrontApplicationConfiguration.php : 301||AphrontApplicationConfiguration::produceResponse()|
|2||phabricator||aphront/configuration/AphrontApplicationConfiguration.php : 209||AphrontApplicationConfiguration::processRequest()|
|1||/srv/deployment/phabricator/deployment-cache/revs/61f10999d8837a8c9dbeea12f67b2554daf057ab/phabricator/webroot/index.php : 35||AphrontApplicationConfiguration::runHTTPRequest()|
Wed, Jul 10
The upstream fix has been applied to production.
Tue, Jul 9
The charts are now based on the 'facts' application and the application was uninstalled on our phabricator. I "installed" the facts application and now this works as it should. Note it's still a very early prototype so it may be buggy.
Mon, Jul 8
fixed by editing the project hashtags
This is something we can consider implementing in our fork and maintaining downstream if there is enough interest. I am of the opinion that it'd be helpful. Another option might be to do it with a browser extension or userscript.
Thu, Jul 4
Now the graphs look better. Unfortunately, puppet will set the config back to 10 taskmasters unless we make a commit to rOPUP Wikimedia Puppet
@Marostegui ok I found a way to slow down the queue: I lowered phd.taskmasters to 1
I could cancel the rest of the search jobs, I think that would still produce quite a bit of database activity but maybe less than all the queue status updates needed to execute the jobs. This would result in the search index missing some data though.
@Marostegui: The phabricator work queue is almost empty now, see https://phabricator.wikimedia.org/daemon/ (There were well over 1 million jobs, now down to just over 300,000 and those are search jobs which should not have significant insert / update load on mysql. Rather, those jobs will be doing a lot of mysql read queries and inserting a lot of documents into elasticsearch.
I'm cleaning up the worker queue to lighten the load. It should subside soon.
Wed, Jul 3
Mon, Jul 1
@MoritzMuehlenhoff: cool! FWIW the new package seems to have fixed the problem and I haven't noticed any other bugs with it.
Fri, Jun 28
Thu, Jun 27
Thanks @MoritzMuehlenhoff ! I really appreciate it! I'll install that now.
Wed, Jun 26
lock wait timeout? That seems a bit strange based on the query
Note: we should think about how this affects canary tests in scap.
We could kick off a rolling restart also at the end of each SWAT window, just for good measure. Of course, that goes against @Krinkle's desire for keeping app servers running for > 3 days. Still waiting to hear more from him about the performance implications of restarting ~daily.
It seems that @Seb35 uncovered the steps to reproduce:
Tue, Jun 25
deploying MediaWiki 1.34.0-wmf.10 to all wikis
Works fine for me with Firefox 67.0.3 (64-bit) (Linux)
This is causing significant inconvenience as we have some repositories which are hosted on phabricator and cannot be pushed over ssh. I'm kind of grasping at straws here but I'll ask anyway:
Is there any temporary solution that we could use to get the self-built binary on phab1003 (and then configure sshd-phabricator service to use it)? I'm not even sure what sort of solution would be acceptable to SRE and I'm not very keen on it given the ad-hoc nature of installing binaries outside of the dpkg system. I only ask because debian isn't exactly known for moving quickly and the upstream bug has been open for quite a while without any movement since August of last year.
So I finally got a chance to test this, I can confirm that my patched sshd binary fixes the issue.
Mon, Jun 24
Given the above, the current plan is as follows:
This is now unblocked! 🎉
Thanks @kostajh, indeed that sounds like it's not a blocker.
If this is really not a blocker then lets remove the parent tasks. @kostajh: can you explain? Also, what remains to be done with https://gerrit.wikimedia.org/r/518739 before it can merge? I'd like to deploy wmf.10 today but I would prefer to fix the fatals before doing so.
@ArielGlenn I built the whole package successfully and uploaded the sshd binary to my home directory on phab1003. I think I can test it without swapping out the normal sshd binary by simply stopping the git-sshd service and then running the patched binary in debug mode with sudo ./sshd -d
Fri, Jun 21
@LucasWerkmeister that could work, though if the fix is as simple as it appears to be then I'd like to just patch sshd. @ArielGlenn what do you think? If I attempt to build sshd with a patch, where should I build it and how should I deploy the patched binary?
I no longer believe that scap swat is the right solution to the problem that it originally attempted to address. In the near future we will be working on other tooling to streamline swat deployments. I think this task can be laid to rest.
This seems like a good idea, however, the upstream documentation has a warning that there are some issues with an external blog / dedicated subdomain: https://secure.phabricator.com/book/phabricator/article/phame/#external-blogs
@hashar: we already have a read-only replica of most repositories on phabricator. Is that not satisfactory? It's kept up to date, with a lag of just a few minutes in the worst case.
Thu, Jun 20
Jun 18 2019
Jun 16 2019
Jun 13 2019
Jun 12 2019
es6 patch was rolled back because at the time I think we were still on es5 and my code wasn't as forward/backward compatible as I thought it was. Still need to re-apply the patch for fully es6 index.
pywebview is a lightweight cross-platform wrapper around a webview component that allows to display HTML content in its own native GUI window. It gives you power of web technologies in your desktop application, hiding the fact that GUI is browser based. You can use pywebview either with a lightweight web framework like Flask or Bottle or on its own with a two way bridge between Python and DOM.
pywebview uses native GUI for creating a web component window: WinForms on Windows, Cocoa on macOS and QT or GTK on Linux. If you choose to freeze your application, pywebview does not bundle a heavy GUI toolkit or web renderer with it keeping the executable size small. pywebview is compatible with both Python 2 and 3.
Jun 11 2019
So it appears that there is a fix upstream in sshd but it hasn't made it's way into a stable debian package. What's the next step here? Move phabricator back to an older debian version? Build a custom sshd package with the fix applied? Something else? What do you thank @ArielGlenn?
Jun 10 2019
openssh-server: SSH AuthorizedKeysCommand hangs when output is too large