@Hamishcn, many veterans (including me) and sysops support the proposal; there is evident consensus to implement. As I proposed, the bot with those permissions should be operated only by a sysop, global sysop, global rollbacker or steward. We need to wait, but vandals will not.

In T317835#8241735, @rook wrote:

Hello! This sounds like a tool that would work pretty well in toolforge. Would a toolforge account work for this?
https://wikitech.wikimedia.org/wiki/Portal:Toolforge/About_Toolforge

Some updates:

Looking further, in Among Us, memory exhaustion happens when invoking Módulo:Lanzamientovj 🠒 Módulo:Wikidata/Fecha 🠒 Módulo:Fechas, specifically, at the lines 76 - 93, the repetitive invocation of Módulo:Wikidata/Fecha.

This happened in Wikidata in my phone. while I successfully logged-in at Wikipedia and Commons, I stay logged out at Wikidata only in the mobile domain, while in the desktop version stays logged in.

In T288547#7277918, @jrbs wrote:

Hi @Amitie_10g, could you please email ca@wikimedia.org from the email attached to your account, quoting this task number (T288547)? Thank you!

Done.

I use 2fA for Wikimedia sites and logged in again successfully. Is recommended to change the password anyways?

I can't believe this issue is still unresolved nor even commented, as history merging/spliting (in order to comply the License) is a pain. The English Wikipedia decided to make it easy and redirect instead of history merging, but other projects li the Spanish Wikipedia, decided to use history merging.

Also, the code should also ignore redirections to User pages not created locally but found at Meta.

Sorry for the delay. Below are the hostname and directory:

I also want to test the ContentTranslation tool, specially due the bug affecting blocked users from translating.

In T232518#5480547, @Reedy wrote:

Previous task is T163931

Can I ask, why you didn't save the recovery/scratch tokens for a second time?

Resolved, but I think this behaviour should not happen.

In T212620#4843540, @zhuyifei1999 wrote:

@Amitie_10g Do you have a ~/.webservicerc file?

Mmm, then, anything where the DB field is Timestamp in the MediaWiki function may be hardcoded to reject any value greater than 2147483647 (January 19, 3038), and send the proper message to the browser, until the Y2K38 problem is fixed in both HHVM and MariaDB.

As I know, the limit for the current UNIX Timestamp implementation is ca. 2038 (as the Timestamp value is a 14 digit, signed 32-bit Integer), and this issue is related to PHP/HHVM and MySQL/MariaDB rather than MediaWiki.

My request at GitHub has been answered: The HHVM developers don't have plans to add support for more than one index file. However, Pull requests are welcome.

In T164161#3224686, @bd808 wrote:

In T164161#3224683, @Amitie_10g wrote:

I'll document that tomorrow.

A good way to get debug information is using the logs, that I'll add to the configuration file. Also, should be a good idea to try HHVM in Daemon instead of the default Server mode (wich uses a PID file, and declaring the logs path is required. Just for experimenting.

Running HHVM in demon mode is actually a bad idea. I had to clean up about 17 orphaned HHVM process that were started from your tool and the one I was testing from that were in demon mode on various job grid hosts. Processes running on the job grid should stay in the foreground. When they demonize they get "lost" and are not cleaned up when webservice stop is run.

I'll document that tomorrow.

For the record, I'm currently running the WebArchiveBOT's Web service as generic web service using the script provided by@bd808 since several hours ago.

As HHVM in Proxygen mode worked properly, do you think is appropriate to document that at Wikitech as an experimental deployment (until the became official)? Also keep in mind my but report at GitHub.

In T164161#3224562, @bd808 wrote:

In T164161#3224547, @Amitie_10g wrote:

I attempted to use Repo Authoritative by adding the following to hhvm-webservice.sh:

hhvm.repo.authoritative=true
hhvm.repo.central.path=${HOME}/hhvm.hhbc

As @ori wrote upstream in https://github.com/facebook/hhvm/issues/6878, RepoAuth mode is difficult to get right. A tool would have to be very, very active before dealing with the complexity of RepoAuth would be remotely worth while. I'm not going to work on integrating it with webservice.

I attempted to use Repo Authoritative by adding the following to hhvm-webservice.sh:

In T164161#3224443, @bd808 wrote:

I spent some time exploring running HHVM in proxygen mode using webservice generic and a bootstrapping script that generates an HHVM ini file and starts HHVM in server mode. This does make a working webservice, but it has several drawbacks:

• Documentation for configuring HHVM's proxygen webserver is lacking upstream. Information can be found, but it requires a lot of digging.
• No obvious support for alias configuration to easily map https://tools.wmflabs.org/my-tool-name/ to the tool's $HOME/public_html. This can be worked around using hhvm.virtual_host[default][rewrite_rules] settings.
• No obvious way to do multi-view indexing as noted by @Amitie_10g in T164161#3224126
  
  My experiments show that using proxygen mode is certainly possible, but based on the lack of documentation and that we don't use it in WMF production I would recommend against it for the average Tool Labs user. I will be looking more closely at fcgi mode configuration for integration with webservice.
  
  For those who are curious, here's the script that I came up with to generate an appropriate configuration file and start the HHVM service using `webservice --backend=gridengine generic start ${HOME}/hhvm-webservice.sh:

hhvm-webservice.sh

#!/usr/bin/env bash
# Run an HHVM webservice
#
# usage: webservice --backend=gridengine generic start hhvm-webservice.sh
set -e

TOOLNAME=${USER#tools.}

if [[ -z $PORT ]]; then
  echo "PORT environment variable not set." >&2
  echo "usage: webservice --backend=gridengine generic start $0" >&2
  exit 1
fi

/bin/cat << EOF > ${HOME}/server.ini
date.timezone = UTC
hhvm.enable_obj_destruct_call = true
hhvm.enable_zend_compat = true
hhvm.error_handling.call_user_handler_on_fatals = true
hhvm.hack.lang.iconv_ignore_correct = true
hhvm.jit = true
hhvm.log.always_log_unhandled_exceptions = true
hhvm.log.level = Warning
hhvm.log.native_stack_trace = false
hhvm.log.runtime_error_reporting_level = HPHP_ALL
hhvm.log.use_log_file = true
hhvm.log.use_syslog = false
hhvm.pcre_cache_type = lru
hhvm.pid_file =
hhvm.repo.central.path = /tmp/hhvm-${TOOLNAME}.hhbc
hhvm.server.apc.expire_on_sets = true
hhvm.server.apc.expire_on_sets = true
hhvm.server.apc.purge_frequency = 4096
hhvm.server.apc.table_type = concurrent
hhvm.server.apc.ttl_limit = 172800
hhvm.server.default_document = index.php
hhvm.server.dns_cache.enable = true
hhvm.server.dns_cache.ttl = 300
hhvm.server.exit_on_bind_fail = true
hhvm.server.port = ${PORT}
hhvm.server.source_root = ${HOME}/public_html
hhvm.server.stat_cache = true
hhvm.server.thread_count = 4
hhvm.server.type = proxygen
hhvm.virtual_host[default][rewrite_rules][0][pattern] = "^/${TOOLNAME}(.*)\$"
hhvm.virtual_host[default][rewrite_rules][0][qsa] = true
hhvm.virtual_host[default][rewrite_rules][0][to] = "\$1"
max_execution_time = 60
memory_limit = 128M
EOF

exec /usr/bin/hhvm -m server -c ${HOME}/server.ini -c ${HOME}/hhvm.ini

Well, I'm running my tool with the generic webserver you provided and works perfectly. I only need to tweak the links to point to the right index.html at the /doc.

I'm trying to run HHVM in Proxygen mode inside my tool account and I opened the page successfully. Following is the way to run HHVM:

In T164161#3224045, @bd808 wrote:

In T164161#3224040, @Amitie_10g wrote:

HHVM in Proxygen mode supports only numbered ports. Then, a Kubernetes container can run two instances of HHVM in Proxygen mode, listening the ports 80 and 443. Then, nginx proxy forwards the traffic originated to https://tools.wmflabs.org/**webarchivebot** to the HHVMs instances running inside the WebArchiveBOT's Kubernetes container. Everything (enabling SSL and setting the certificates paths) should be declared in the command line,or in the configuration file.

Only one backend instance of the HHVM proxygen (or fcgi) server is needed. HTTPS requests are handled by the Tool Labs nginx proxy which has the proper SSL certificates. Requests from the nginx proxy to each tool's webservice are done via plain HTTP across the Labs network segment. An X-Forwarded-Proto header is added to requests sent through the proxy to ecah webservice so that the webservice can determine the protocol in use by the client.

In T164161#3223888, @bd808 wrote:

If we try proxygen mode, the webservice backend will need to provide a way for the user to provide configuration settings for the HHVM process in some per-tool config file. This would be needed for things like setting up rewrite rules for tools that use a dispatcher script.

As the user who is interested in this, I have some question that has been not answered at the IRC. Based in my knlwledge, I see the following situations:

After trying to install from bastion to an alternative php_dir, I got phpize missing, and php5-dev is required for that.

Yes, there is not php5-judy, and it is only available from PECL. When I trying to install judy from PECL (in bastion), the following error appears:

$ pecl install judy
Cannot install, php_dir for channel "pecl.php.net" is not writeable by the current user

that means I don't have permission to install it (at least from bastion), and I don't know if using an alternative php_dir will work at the bastion and the grid.

I ran a bot and got a (huge) list of files SVGs > 10 MB (more than 8000 ones). I'll post the list soon, so, I don't have the time to see every file for rendering errors, so, please take it.

I see the files that {{HugeSVG}} ins transcluded, but them're still unable to render as PNG.

Meanwhile the bug is resolved (or scheduled for resolving), could be a good idea to add {{HugeSVG}} at the Description in the Upload Wizard.

According to this thread at the Commons Village Pump, the Community is urged that this issue should be corrected as soon as possible. T111722 is another recent issue that request the preserving, at least, the Copyright information in Exif metadata.