Jump to content

User talk:Feedback Request Service bot

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia

Lurking Stats

[edit]
Page views for this talk page over the last 90 days

Detailed traffic statistics

@Primefac: Novem Linguae suggested that I put a link to the WP:BFRA page on this proposed bot--which I believe was accomplished with this edit--and then ping you and ask if you could please add a bot flag. --David Tornheim (talk) 01:02, 14 March 2024 (UTC)[reply]

This bot has not received approval for anything (and there isn't even a BRFA yet). Primefac (talk) 09:42, 14 March 2024 (UTC)[reply]
It looks like the wrong brfa was linked on the user page. This bot is a take over of the task Wikipedia:Bots/Requests for approval/Yapperbot. That bot is inactive, so the toolforge inactive account takeover policy was used. The source code is exactly the same as yapperbot. Primefac, do you think a new brfa is needed, or can we just flag the bot? David, did you end up getting control of the yapperbot toolforge account, or did you make your own toolforge account? –Novem Linguae (talk) 11:40, 14 March 2024 (UTC)[reply]
Let me post my update (probably in the next 24 hours) which answers many of these questions and likely follow up questions from you all. The act of writing the update (especially writing out what was confusing) has helped me answer questions I was about to post. I have rewritten it a few times as things continue to become clearer. Now it's time to finish up and post it. --David Tornheim (talk) 11:59, 14 March 2024 (UTC)[reply]
Thinking about this more, I think I gave you bad advice David. Apologies. The most proper way to do this is probably to file a WP:BRFA. If you check enterprisey's user scripts, there is a good one for filing brfas.–Novem Linguae (talk) 11:55, 14 March 2024 (UTC)[reply]
Thanks, I agree. I was going to tell you I would feel more comfortable following the BRFA protocol, because it will be close to impossible to make the software 100% identical. Legoktm specifically asked me to "Create a new bot account and file a BRFA to take over the Yapperbot tasks." Even if I copy the code exactly, the configuration files will have to be changed to adopt to the new file locations, account names, etc., and there is a possibility it will not work correctly the first time--even if I change nothing else. I would prefer using the regular testing protocol and review process. I will explain more about that in the update, which is very close to finished. Thanks for the feedback and guidance. --David Tornheim (talk) 13:43, 14 March 2024 (UTC)[reply]
The very short answer is yes, a new BRFA will be needed, if only to rubber-stamp and show that it has been approved. Primefac (talk) 16:41, 14 March 2024 (UTC)[reply]

Update

[edit]

@Legoktm:,Novem Linguae,Pppery,DreamRimmer,Awesome Aasim,a smart kitten,Aaron Liu:

This is a continuation of the discussions at User_talk:Naypta and User_talk:Yapperbot:

I wanted to give you guys a report on my progress since I last posted. So far, these are done or in progress:

(1) Notified Yapperbot’s owner User:Naypta

(2) Reviewing code of:

Yapperbot:
Support modules called by Yapperbot:
Legobot: code, Task 33 approval, with focus on rfcbot.php, rfcbot.sql, goodarticles.php, and ga.sql.

(3) Writing sample test bot(s)

(4) Reviewing Wiki API, e.g.

(5) Learning new languages

(6) Learning about new data storage formats

(7) Created accounts/logins:

Challenges:

(1) Sparse documentation–I think we are all used to that.
(2) The Wiki API and the countless software support modules that call on the Wiki API were the hardest for me to understand. Much harder that reading the Go code written in Yapperbot. Despite the minimal comments, the code is not that hard to follow.
It would be nice if the I/O specifications for support modules (and most software used on MediaWiki or referred to) were written out more clearly and precisely. I have concluded that system upgrades, major software changes, protocols, system and security requirements and keeping all the WikiMedia software backward compatible have a lot to do with why the documentation is so messy and leads in so many directions.
(3) Toolforge: Initially I could not find a simple tutorial on how to write a bot that does something as simple as read a Wikipedia page. The pages Help:Creating_a_bot (especially Help:Creating_a_bot#APIs_for_bots) and the use of Wiki API and have been the most challenging. I think I have a handle on the main concepts now and will soon start trying the Wiki API directly and modules that call it.
I recently did find User:GreenC/BotWikiAwk and [3], which I believe are exactly what I have been looking for. I am about to delve into them.
I also looked at Build and host your first tool. I believe I tried out the My_first_Buildpack_Python_tool a couple of weeks ago, ran into some configuration problem and never got back to it—focusing instead on everything else I had to learn. Is there a another one of those tutorials that is easier to work with? I’ll probably try My_first_PHP_tool next.
(4) Version Control: Although I understand that bot maintainers can upload code to a server and use SSH through Toolforge to run it, e.g. phab:T320195, I’m still a little fuzzy on the relationship between the published code and the code on the server that appears to be protected. [Some concerns allayed as explained here added 19:39, 15 March 2024 (UTC)] Hopefully, BotWikiAwk and [4] will make it clear enough.[reply]
I am uncertain how version control is done with regard to bots. It seems like GitHub has some sort of automatic version control, but I have not yet read up on it. (I just looked up [5] and [6].) For GitHub, it seems like what you see is always the current' version. I am under the impression that rather than call that code on GitHub, the first time Go code is run, it downloads all the appropriate modules from GitHub (or whereever they may be stored) to the local server and then uses keys in yaml files to keep track of exactly what copy it has downloaded.[7]
I’m used to services like Unix’s SCCS and RCS that keep track of every change, and big version releases. When I worked as a VLSI designer in the early 1990s, we had write-protected directories for each released version of the code/design, so we could be confident that module was stable.
I find it odd that the Yapperbot code, the scripts that call the code, and the data the code stores on the server (other than the bot password) appears to be protected from view.
I understand that code is published on GitHub, but how do we know it is *identical* to the copy that is actually being run? And what happens when the programmer must tweak and/or re-release the code for bug fix? How can WP:BRFA review code and assure it is not changed, if it is protected from view? Does BRFA focus almost entirely on behavior in edits rather than the code itself?

Questions:

(1) Do I need to install MediaWiki? Was this already accomplished by installing Toolforge?
(2) Legobot: Is there a higher level definition for the tables and/or queries that are used to store the RfC and GA data? Where exactly is that data stored? Should I assume it is in a MySQL database?
I believe the answer can be found here: wikitech:Help:Toolforge/Database.--David Tornheim (talk) 06:50, 19 March 2024 (UTC)[reply]
(3) Single step / Debugger. It would be nice to single-step through code (acting on the test-wiki) and look at the data as it is being used. Is this possible? My research of debuggers for Go suggested GDB and delve.
For my personal code, if I had no debugger, I frequently put in statements of the form: if (Debug_value > constant) {Print internal variable(s)}. Debug_value is assigned 0=No Debug; 1=Debug showing the fewest variables; >1 = larger values give greater detail. I do see that console.log() is a useful function for doing something like that. However, I don’t recall seeing internal variable printouts for debug in *any* the code I have looked at. What do programmers typically do to debug their bots?

Plan/Readiness:

The API related software was more complex than I had anticipated. After a number of days grappling with it, I think I get the overall gist of how it is supposed to be used. I want to try it out with simple code on the test wiki.
Although I don’t mind telling editors to refer to me if they have questions about Yapperbot, I do want to understand all of Yapperbot’s Feedback Service functionality (and how it communicates with the API) more fully before I am asked and expected to fix a bug, change parameters, etc. My comfort level is increasing each day on that. I have been looking at Yapperbot code (its support modules and all of the above) at least a couple hours a day since notifying Naypta.
I am happy to receive any advice on what aspects of the above I should study most to be ready.

Yapperbot’s other functions:

Yapperbot does a couple of other tasks that appear to be completely unrelated to the Feedback Service, notably Uncurrenter, Yapperbot-wikidatatable and some functions of Pruner (other than pruning the FRS lists). Over the long term, I would prefer someone else take over the non-WP:FRS related functions. I am willing to look after those additional functions for the time being and possibly reconsider helping maintain those as well.

Adoption:

I did not yet request to adopt Yapperbot on Toolforge yet—even though the 14-day waiting period recently passed. I thought I should share my progress with you all first, in case anyone has concerns or has good reasons for me to wait before filing. Otherwise, I am happy to file the application.

Again, I am very happy to receive advice and guidance to keep my continued learning focused on what is most needed to accomplish this job of making sure the Feedback Request Service bot is functioning correctly, so that editors are getting the notifications they have requested. --David Tornheim (talk) 05:39, 15 March 2024 (UTC)[reply]

Responses to Update

[edit]

Aaron Liu

[edit]
  1. Since you have an account on Wikipedia, you already have an account at mediawiki.org
  2. Link [6] should explain Git the best. It's not exactly automatic, you have to "git add " your changes and then "git commit" them to create a new current version. "git push" would then upload your current version to the server. And your impression with local downloading is correct.
  3. Unless you wish/need to test on your own wiki instead of just testwiki, you shouldn't need to install MediaWiki.
  4. If you want to maintain Pruner for FRS, I think you should also maintain it for all lists. It sounds like that would be as simple as a config change.
  5. I'd say you should probably adopt. Like NL said, there could be changes only present on toolforge.
Anyways, thanks! Aaron Liu (talk) 11:38, 15 March 2024 (UTC)[reply]

Novem Linguae

[edit]
Thanks for doing this David. Some thoughts/tips:
  • If you haven't discovered/experimented with Special:ApiSandbox, will definitely want to take a look at this. Although keep in mind it is not actually a sandbox, it makes live edits, so be careful with non-view API actions when not on testwiki. The documentation on mediawikiwiki for the action API is also pretty good: mw:Action API.
  • Git is a pain in the butt and has a big learning curve, but is by far the industry standard now. Worth learning because of this. Everything uses git. Mercurial, SVN, etc. (alternative version control systems) are almost extinct as far as I can tell. Personally I like interactive exercise websites for learning. Here's a good one for git: https://learngitbranching.js.org/.
  • GitHub is a good website/repository for bots. Gitlab.wikimedia.org is the open-source version of GitHub for Wikimedia, but for various reasons a mass switchover hasn't occurred yet. GitHub is a bit more industry standard and folks are familiar with it.
  • I have a PHP Toolforge bot tutorial if you want to take a look: User:Novem Linguae/Essays/Toolforge bot tutorial.
  • I personally just use SFTP to drag n drop files from my local machine to Toolforge when I update my code / issue a release. There are more proper and complex ways to publish updates, but this is dead simple which has its advantages. I combine this technique with git version control because version control is a nice efficiency tool so you can diff everything you've done, you can have a commit simultaneously close a ticket (a GitHub issue) by putting something like "Fix #27" in the commit message, and so that your code is published for others to view. You can use a .gitignore file to keep "secrets" out of git, such as password files.
–Novem Linguae (talk) 13:13, 15 March 2024 (UTC)[reply]
I'm pretty sure that they were talking about the PHP API, since the bot is partially written in that. Aaron Liu (talk) 13:23, 15 March 2024 (UTC)[reply]
@Novem Linguae and Aaron Liu: Thanks to both of you for the feedback. I'm going to start keeping a log on what I am doing on User:David_Tornheim/YapperBotRelated. If either (or both) of you would be kind enough to put it on your watch list, you could watch my progress there and any further problems. Right now, I don't really want it to be a talk page: It's more a compilation of relevant links, items to do, and things like what I described above. I don't mind if you add info. to it, or even put in "todo items", or change the priority or order. If you want to talk about anything there, I would prefer it on its own talk page, here, my talk page, or yapperbot talk page.--David Tornheim (talk) 17:06, 15 March 2024 (UTC)[reply]
From looking again at wikitech:Help:Toolforge/Quickstart, I see that it mentions GitLab. I mistakenly thought that was run by and controlled entirely by GitHub, but it looks like it is instead part of MediaWiki--that allays one my key concerns about who is control of software versions releases, where it is stored, etc. --David Tornheim (talk) 19:17, 15 March 2024 (UTC)[reply]
GitLab is a piece of software, just like MediaWiki, that WMF has installed. Aaron Liu (talk) 20:23, 15 March 2024 (UTC)[reply]

Bot passwords / Special bot passwords

[edit]

@Novem Linguae and Aaron Liu: Making more progress. Since last report have worked through some of User:GreenC/BotWikiAwk and got through the setup of the BotWikiAwk tools. Now I am working on User:Novem_Linguae/Essays/Toolforge_bot_tutorial. I tried a few php scripts, one of which successfully performs the "include('botclasses.php');" without an error.

Now I am at User:Novem_Linguae/Essays/Toolforge_bot_tutorial#Bot_passwords.

I have looked at mw:Manual:Bot_passwords. To start with, I would like to create a task that does the absolute minimum and has the absolute minimum privileges, e.g. a bot that just reads pages. I like to incrementally try commands and routines with increasing complexity until I can eventually get all of the Yapperbot code to work. The sooner I can start trying out the simplest commands of the Yapperbot code, the closer I will be to being able to maintain it.

Can you guys (or anyone else) who is watching, please give me a suggestion on names for special bots and the appropriate privileges so as not to do much damage.

I logged into the page Special:BotPasswords is a little bit overwhelming... It claims I have an "existing bot password: David@Tornheim". I don't remember making such a password. I clicked on the link and it then goes to: mw:Special:BotPasswords/David@Tornheim. That page says the username is: "David Tornheim@David@Tornheim". It gives the option to reset the password and laundry list of checkboxes. Then it gives an IP range of:

0.0.0.0/0
::/0

and allowed pages for editing. I would like to try just being able to edit a page such as "User:David Tornheim/test" and/or read or write a file like "User:David Tornheim/config.json". Can someone please help me figure out the best way to setup the first bot special password task name, and the best privs, so as to reduce the likelihood of inadvertent disruption? --David Tornheim (talk) 07:48, 19 March 2024 (UTC)[reply]

Glad you're finding my Toolforge bot tutorial helpful. I happened to update the cron job section of the tutorial yesterday, and I added some detail to the bot passwords section just now, so the tutorial should be pretty up to date with current best practices.
For Special:BotPasswords, if you want to play around with it, go log into your bot account (not your main account), then visit Special:BotPasswords, then at the bottom where it says "create a new bot password", type Task1 and click "Create". That'll take you to a screen that tells you your bot username is "[AccountName]@Task1" (or similar), then lets you grant permissions to that particular username via check boxes. Looks like there's an "Allowed pages for editing" box at the bottom if you want to restrict it to just your test page. Then click "Create" again and it'll give you a generated password for that username. I think this username and password only work for the API, not for logging in via the normal website login form.
I wouldn't go too crazy with the security stuff. If you tick an extra permission box or two for your bot, you'll probably be fine. Can save your brainpower for other parts of the tutorial :) –Novem Linguae (talk) 03:00, 29 March 2024 (UTC)[reply]
Thanks. I'll try what you suggested. --David Tornheim (talk) 21:11, 30 March 2024 (UTC)[reply]

Trying to run Yapperbot code

[edit]

@Novem Linguae and Aaron Liu: I'm trying to run the Yapperbot code (not as a bot yet) first on my local machine (Windows), then on the Toolforge shell. I spent about an hour on this problem, which I posted at WP:VPT. I don't know if either of you are familiar with Go. Do you know any Wikipedians who are? --David Tornheim (talk) 07:10, 23 March 2024 (UTC)[reply]

Bummer when I see bots that don't use a language that Wikimedia devs are familiar with (PHP, Node) or doesn't use a language that is popular and many folks are familiar with (Python). Makes maintainability harder.
If the VPT folks couldn't help you, I'd try the chat room platforms next: WP:DISCORD and WP:IRC. For Discord, I think the channel you want is #technical (create your own thread), or #general-technical-discussion. For IRC, maybe #wikimedia-tech. –Novem Linguae (talk) 03:20, 29 March 2024 (UTC)[reply]
@Novem Linguae: Thanks for the reply. I was hoping you or another programmer would eventually write back. For a TL;DR, I put the key points in bold.
My focus lately has been to simply try to run the Go code on my local machine--so that it just cycles through the loops in the code and can't edit any Wiki pages and can't do any damage. Once I have gone as far as I can with that, I plan to try it on the test wiki using the new bot running on Toolforge.
When responding to another user at User_talk:Naypta#Yapperbot_RfC_-_no_requests (permalink), I reviewed some of my old 2020 conversations with Naypta about my concern about under notification. At some point in those discussions, Naypta indicated that we have to trust that the code on Toolforge is identical to that on GitHub. That made me pause.
I saw no point in continuing to mess with the code from Github if there was even the slightest chance it doesn't exactly match the actual code that is being run on Wikipedia right now. Even though I have been able to successfully log onto Toolforge, run SSH commands, compile and run simple Go programs, and create the new FRS bot (and its folder) on Toolforge, become the bot/tool, when I go to the yapperbot folder, most of the code is protected from view.
So my next step is to apply for adoption so I can see the actual code and make a copy of that to work with. I was about to notify you of my plan to file for adoption last night. I ran out of steam, but plan to do it tonight and report back to you when that is filed.
I could still use some overall guidance with regard to the priorities of what packages I am learning and where to focus my energy. (For example, I did not try to learn the GitHub protocols for updates yet, because it is easy enough to see all the most current published code. My main goal is to make sure I fully understand every subtly of the code, so that if it breaks or needs to be modified, I can fix or adjust it quickly. That's why my focus right now is running a COPY of the code where I can print internal variables, etc., to make sure it is doing what I think it is doing.
The number of tools and software packages I have had to learn is substantial. It's way different than 30 years ago, when you wrote the entire package in C and had a minimal number of support packages to rely on--we had to create our own data structures, I/O, sorting, tree structures and tree pruning with pointers, etc. in a way that seems pretty obsolete now with OOP. It's impressive just how much simpler code is now. I do feel more comfortable with all of this than when I posted the last update on 3/15/24. --David Tornheim (talk) 06:14, 29 March 2024 (UTC)[reply]
Hey David. I agree that it would be best to wait until the Toolforge adoption process is complete, so that you can get access to the latest and greatest YapperBot files. It doesn't make sense to take the risk of using out-of-date or incomplete (key config files missing) GitHub files. I recommend that you finish the adoption process, download the Toolforge files, then start a new GitHub repo with those ToolForge files as the first commit (since I assume you don't have collaborator access to the old GitHub repo anyway). Be sure to put any password file paths in your .gitignore file so that they stay out of git.
I think learning git and GitHub last is a good idea. Like any big programming problem or any big problem in general, it benefits from being diced into smaller problems. Git is the industry standard for version control now, but has a nasty learning curve.
Yeah, the Internet has made software libraries a thing, which can be a time saver, but can come with other costs (the complexity of learning how to use the library download/update software, having to keep these external dependencies up to date, having to make sure that updates don't break your code, etc.) Pros and cons I suppose. –Novem Linguae (talk) 21:28, 29 March 2024 (UTC)[reply]
@Novem Linguae: While waiting for the adoption to play out and permission to look at the current code running, my main focus continues to be running the code--so that I can look at internal variables, to make sure I fully understand how it works. Now that I found a workaround to solve the problem I had had related to modules, I will need to be able to modify a copy. I need a record of every change I make to the copy. While working on it, I will also add comments. Rather than use my past favorite RCS/SCCS, it makes more sense to start with GitHub.
Hence, I have made a copy to play with:
If you would like to be added as a collaborator, I'm happy to do that.--David Tornheim (talk) 18:35, 5 April 2024 (UTC)[reply]
Sure, feel free to add me as a collaborator. https://github.com/NovemLinguae. –Novem Linguae (talk) 20:21, 5 April 2024 (UTC)[reply]
Invitation  Done --David Tornheim (talk) 21:08, 5 April 2024 (UTC)[reply]

Yapperbot Adoption Request Filed

[edit]

@Novem Linguae: Yapperbot adoption request filed here. --David Tornheim (talk) 12:16, 30 March 2024 (UTC)[reply]

Thumbs up icon –Novem Linguae (talk) 19:57, 31 March 2024 (UTC)[reply]

Commenting Yapperbot Code

[edit]

@Novem Linguae: Question about Github. If there is a better place to ask you, please let me know. I'd like to know the formatting rules for a file of type *.MD. I want the readme at DavidTornheim/ybtools to look like this:

# Yapperbot Tools
# 2024-04-07 DAT attribute original readme; describe expected configuration files
# 2020-05-19 CPF last commit
Original description from CPF (https://github.com/mashedkeyboard)
A set of imports used by other Wikipedia bots I've created. These probably won't be of much use to anyone else, but you're welcome to them in accordance with the license if you like!
Configuration Files expected in home directory:
const localConfigFilename string = "config.yml"
const globalConfigFilename string = "config-global.yml"
const botPasswordFilename string = "botpassword"
from: config.go

However, instead, it deletes all the line feeds and turns it into a mess:

MD stands for markdown. It's the same syntax used on Reddit, Discord, and a couple other places. "Markdown" should hopefully be a good enough clue to google a syntax guide. Try adding line breaks where appropriate, or surrounding code block tops and bottoms with triple backticks (```) –Novem Linguae (talk) 16:14, 7 April 2024 (UTC)[reply]
@David Eppstein To address your question specifically: Add two spaces at the end at the previous line for a line break, and do double linebreaks for a paragraph break. Aaron Liu (talk) 16:41, 7 April 2024 (UTC)[reply]
Thanks for both comments. --David Tornheim (talk) 18:15, 7 April 2024 (UTC)[reply]
oh god i just realized i've pinged the wrong person, sorry David Eppstein Aaron Liu (talk) 18:16, 7 April 2024 (UTC)[reply]

Yapperbot Tools

[edit]

2024-04-07 DAT attribute original readme; describe expected configuration files

[edit]

2020-05-19 CPF last commit

[edit]

Original description from CPF (https://github.com/mashedkeyboard): A set of imports used by other Wikipedia bots I've created. These probably won't be of much use to anyone else, but you're welcome to them in accordance with the license if you like!

Configuration Files expected in home directory: const localConfigFilename string = "config.yml" const globalConfigFilename string = "config-global.yml" const botPasswordFilename string = "botpassword" from: config.go


I imagine there is set of rules that are like Wikitext somewhere. Do you know where I might find such rules? --David Tornheim (talk) 11:44, 7 April 2024 (UTC)[reply]

Toolforge email

[edit]

@Novem Linguae, Sohom Datta, and Aaron Liu:

Yapperbot code uses the module Ybtools. Ybtools includes the file error.go. If there is an error, an email is sent to "tools.Yapperbot@tools.wmflabs.org". Is that an email account that was automatically created for each bot, or did Naypta create it? Would anyone else check that email except Naypta? Is there a section that explains email accounts ending in @tools.wmflabs.org and their use with regard to bots? --David Tornheim (talk) 21:23, 8 May 2024 (UTC)[reply]

Take a look at wikitech:Help:Toolforge/Email. I believe the emails are automatically forwarded to Naypta and is automagically created for each bot account. I'm unsure if anyone has access to those emails, but will ask around in IRC. sohom@enwiki 21:47, 8 May 2024 (UTC)[reply]
Thanks. --David Tornheim (talk) 22:25, 8 May 2024 (UTC)[reply]

P.S. FYI, with Sohom Datta's help--Sohom Data is familiar with Go -and- bots--I have started running a local copy of the Yapperbot code on my home machine, so that I can look at internal variables and make sure I fully understand how the code works. I won't let the copy mess with mainspace--only test space. Slow but steady progress.--David Tornheim (talk) 21:36, 8 May 2024 (UTC)[reply]

Problem with Shell login

[edit]

@Novem Linguae, Sohom Datta, and Aaron Liu: I am trying to log into to ssh--which I have used successfully in the past. Now I am getting this error: 

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@       WARNING: POSSIBLE DNS SPOOFING DETECTED!          @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
The ECDSA host key for login.toolforge.org has changed,
and the key for the corresponding IP address 185.15.56.62
is unknown. This could either mean that
DNS SPOOFING is happening or the IP address for the host
and its host key have changed at the same time.
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that a host key has just been changed.
The fingerprint for the ECDSA key sent by the remote host is
<<omitted>>
Please contact your system administrator.
Add correct host key in C:\\Users\\MYLOCALNAME/.ssh/known_hosts to get rid of this message.
Offending ECDSA key in C:\\Users\\MYLOCALNAME/.ssh/known_hosts:1
ECDSA host key for login.toolforge.org has changed and you have requested ::strict checking.
Host key verification failed.

I don't believe I have changed anything significant on my end that would trigger this. What should I do? Should I post this question on discord, or somewhere else to ask about it? When it says Add correct host key in C:\\Users\\MYLOCALNAME/.ssh/known_hosts to get rid of this message., I don't get what that means. If it worked before, that means the key should still be correct, right? --David Tornheim (talk) 10:32, 15 May 2024 (UTC)[reply]

I know very little about SSH, but Add correct host key in C:\\Users\\MYLOCALNAME/.ssh/known_hosts to get rid of this message. seems like the way to go here. Could try something like this. –Novem Linguae (talk) 10:35, 15 May 2024 (UTC)[reply]
Thanks for quick response. I'll try that and report back here if it works or not. --David Tornheim (talk) 10:37, 15 May 2024 (UTC)[reply]
@Novem Linguae @David Tornheim I think the ssh fingerprint of the servers changed semi-recently (in March). The SSH fingerprints for the current login.toolforge.org instance are at wikitech:Help:SSH Fingerprints/login.toolforge.org. If the fingerprint match, you can delete the lines in C:\\Users\\MYLOCALNAME/.ssh/known_hosts that start with login.toolforge.org and ssh should add the correct entries the next time you connect to the servers. (You might get a message of the effect:
:::The authenticity of host 'login.toolforge.org (185.15.56.62)' can't be established.
:::ED25519 key fingerprint is SHA256:BD7PYn+h064QofXmhn69Ehos6skHvaki6MO+EOubL3Q.
:::This key is not known by any other names.
:::Are you sure you want to continue connecting (yes/no/[fingerprint])? 
:::
when you login next, and once you approve it, the new fingerprint will get added to your know_hosts file) Sohom (talk) 16:00, 15 May 2024 (UTC)[reply]
Retrieved from "https://en.wikipedia.org/w/index.php?title=User_talk:Feedback_Request_Service_bot&oldid=1223989260"