@ThomasWard At least on my instance, it had been working fine for months, then wasn't working when I saw MS was having SSL issues and none of the SD instances were working. No non-automatic changes were made on my instance, or the configuration of Python. I expect that @iBug's instances are having the same problem. If the only problem for them was the SSL cert., then they should be back by now.
@ThomasWard Possible. Is your instance generating a warning during boot? I'm still seeing "[16:57:25.709] <urlopen error [WinError 10060] A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond>" when my instance reboots.
Checking the errorlogs for Osiris indicates that " update_tld_names raise TldIOError(err)" was the error which it was getting when it was down, so it's not just my instance.
@ThomasWard Yeah, that's the solution I'd been thinking was going to be needed, unless there's an update soon. I'd consider an update likely. This only hit us in the last day, so...
then that's what we'd have to add. I have to finish setting up the DNS server for public access here but then it'll be reachable, will let you know when that's ready.
@iBug It looks like you're going to need to manually pull your SD instances. Unfortunately, there's a hard requirement for this Mozilla URL to work. It looks like Mozilla considered the list there obsolete and killed it/allowed it to die. All SD instances encounter an exception prior to getting to a point where they can be commanded to pull a new version, so this requires a manual pull.
Eventually, there will be a user_requirements.txt change to update the tld package (tld update not yet available). For now, there's just code to bypass the issue.
@ThomasWard I'm confident that there will be a change to user_requirements.txt, which either updates the tld version, or updates the tld version and specifies that it should be obtained from a different source. :)
@RobertLongson As @Zoe determined, backfilling is completely manual at the moment. Doing it required picking out the URLs from chat (I used a browser extension, which is incompatible with other extensions I use, so done in a different browser profile, and hand edited the list of URLs to get only SE posts), modifying SD's code to remove the enforced rate-limiting for the !!/scan command, and running a test instance configured to not automatically scan for new SE posts and running in another room.
Having SD automatically back-fill reports it was unable to send to MS, once it reconnects with MS, is on my list of things I'm wanting to code-up to add to SD. It's not at the top of the list, but it's something I want to accomplish. Having it done automatically will be much better, as it will give us a record of all of the reports, even ones which were subsequently deleted.
So, we can document how I did it/do it, but it's something where I'd rather spend the time on other tasks. Fortunately, MS going down is much more rare now that it's on @ThomasWard's infrastructure. That fact has reduced the priority of getting the automatic code written and/or better documentation.
Another alternative is to create a !!/scan-no-chat-report command, which would eliminate the desire to do the !!/scan on a test instance in another room. The desire for doing it that way is to prevent posts, which are going to be predominately FP, being re-reported into all rooms. Re-posting them in rooms expends people's time and potentially results in unwarranted negative attention to predominately FP posts. [They are predominately FP, due to many of the TPs already being deleted.]
[ SmokeDetector | MS ] Bad keyword in body, potentially bad keyword in body, potentially bad keyword in title, toxic body detected (160): I did not get a raise? by SuckOnThis on workplace.SE
In case anyone wants, I'm quickly reachable on GitHub though I'm no longer on Stack Exchange (peek occasionally so inbox notifications will still be seen rather soon).
@ThomasWard Yeah, those tend to be a bit too verbose to the point of not having useful information unless you keep a very long console buffer. My impression is that a lot of us have left things in as "debug" logs which probably don't need to be logged anymore.
@ThomasWard I'm not sure if that's a symptom or a cause. It might have happened here, but it was already in reverted mode at that point.
### AttributeError on teward/Osiris at 2020-04-19T19:56:03Z: module 'tld.defaults' has no attribute 'NAMES_LOCAL_PATH' File "/home/smokey/SmokeDetector/excepthook.py", line 44, in run_with_except_hook run_old(*args, **kw) File "/usr/lib/python3.6/threading.py", line 864, in run self._target(*self._args, **self._kwargs) File "/home/smokey/SmokeDetector/bodyfetcher.py", line 96, in add_to_queue self.check_queue() File "/home/smokey/SmokeDetector/bodyfetcher.py", line 113, in check_queue self.make_api_call_for_site(site)
@Undo we'll do the actual tests for the infrastructure getting DNS/TXT updates for LE later, since it just renewed this morning there's no need to push hard for it. Once the DNS is operating within my specific security restrictions we can move the DNS components over :)
and then that should allow TXT updates heh. (Going to do all tests with the Staging server of course :P)
@Undo can you add an NS entry to your Google Domains information for metasmoke.erwaysoftware.com to point it to dns.thomas-ward-consulting.llc for its nameserver? The A and TXT records are on that NS, so you'll need to remove the A record for metasmoke on your side (since it's delegated)
the DNS server and records are already set up and public
so barring any major chaos with DNS it should Just Work.
