https://wikitech.wikimedia.org/wiki/News/Toolforge.org#New_URLs_for_webservices says

• Make sure your tool is ready to work with the new URL root path which will change from /<toolname>/ to /.
• Check for things that may need updating in your $HOME/.lighttpd.conf file if it exists.

@Adithyak1997: Please explain what exactly you checked in these two steps (and which adjustments you potentially made).

Please consider following code:

#!/bin/bash
cd /data/project/fireflytools
source www/python/venv/bin/activate
./u2_candidates.py enwiki 1000 &
wait

I would like to know whether the word 'fireflytools' needs to be changed from this.

Please explain what exactly you checked in these two steps (and which adjustments you potentially made).

In the HTML pages used to display the result of code, the url's mentioned in href attributes have been changed. Also, I was unable to identify the value of 'type' attribute that was mentioned in step 2 in the task description.

@Adithyak1997 was this tool running a webservice previously? Did that webservice work before your migration?

It appears to me that the tool is now running a PHP 7.3 Kubernetes webservice and that the $HOME/public_html document root contains only a toolinfo.json file. The 403 Forbidden response for https://tools.wmflabs.org/fireflytools should be expected as the lighttpd webserver is not configured to perform directory listings by default and there is no index.html or index.php document to serve in response to the request.

The tool was working fine till migration. Actually, it stopped working when I typed the command

webservice stop' followed by 'webservice --backend={kubernetes,gridengine} --canonical start

When checked in the service.manifest file, it was shown that the distribution is 'Debian'. I have doubt whether it needs to be changed to 'canonical'
(don't know whether it's possible). I tried many commands as part of which I used the command

webservice --backend={kubernetes,gridengine} --canonical python7.3 start

I have doubt whether this led to PHP 7.3 Kubernetes webservice. If you can confirm, please check whether the server is httpd or not. Because I haven't dealt with it yet for the purpose of tool. As part of trying to solve the issue, I have come across the command

webservice --backend={kubernetes,gridengine} --canonical {type} start

and have replaced the type as 'httpd' also. Couldn't that might be the reason for having a lighttpd server?

@bd808 Can you please visit https://fireflytools.toolforge.org/. The error code has changed now.

In T254690#6204650, @Adithyak1997 wrote:

@bd808 Can you please visit https://fireflytools.toolforge.org/. The error code has changed now.

The page I currently see there is the fourohfour tool's response which means that you do not have a webservice running.

In T254690#6204576, @Adithyak1997 wrote:

The tool was working fine till migration. Actually, it stopped working when I typed the command

webservice stop' followed by 'webservice --backend={kubernetes,gridengine} --canonical start

If you literally typed webservice --backend={kubernetes,gridengine} --canonical start it would have resulted in an error. The {kubernetes,gridengine} string is a shell scripting brace expansion intended to describe that one or the other value should be chosen. --backend=kubernetes is most likely the value you need.

This command is also missing an explicit [type] to select the Kubernetes container type to use. The default type when not explicitly provided is currently php7.3.

When checked in the service.manifest file, it was shown that the distribution is 'Debian'. I have doubt whether it needs to be changed to 'canonical'

No. The distribution will currently always be Debian. This setting is a left over from the migration from Ubuntu to Debian in the gridengine backend which happened approximately a year and a half ago.

webservice --backend={kubernetes,gridengine} --canonical python7.3 start

There is not a python7.3 container type. This should have resulted in an error message listing the available types. You possibly meant to use python3.7?

I have doubt whether this led to PHP 7.3 Kubernetes webservice. If you can confirm, please check whether the server is httpd or not. Because I haven't dealt with it yet for the purpose of tool. As part of trying to solve the issue, I have come across the command

webservice --backend={kubernetes,gridengine} --canonical {type} start

and have replaced the type as 'httpd' also. Couldn't that might be the reason for having a lighttpd server?

Your question here is confusing, but I think that your intent is asking for help in understanding how your tool is actually supposed to work? I know you have been trying to learn more about this tool you adopted and using the Toolforge environment in general, but it feels like a lot of that still needs more work. This task in general feels like you have been expecting to exactly copy and paste commands from wiki pages without having a clear understanding of what the commands actually do and what the needs of your tool actually are. This is a vary difficult process to support from my side of the conversation. I really want to help you and all other Toolforge tool maintainers, but I just do not have the time to do a deep investigation of each tool to understand how it is written and what it is supposed to do.

Having said all that, the signs I can see in /data/project/fireflytools make me think that if is probably meant to be running webservice --backend=kubernetes python start for the webservice. This is informed by the existence of /data/project/fireflytools/www/python indicating a python uwsgi tool and /data/project/fireflytools/www/python/venv/bin/pip3.4 indicating that the current virtualenv is build using Python 3.4. In Toolforge, the Python 3.4 runtime is named python.