The checks are done based on the state of the blacklists/watchlist as of the last reboot. They don't account for any changes which are currently in process, but which have not been applied to the running SD code. Thus, the new pattern being caught by "Blacklisted username" was expected. I should have just used -force for the first !!/blacklist-username, but it's habit not to do so.
@EriktheOutgolfer If you are concerned about that, then you can wait for SD to reboot and check it. It's significantly less of a concern for the username blacklist, because the list is only 100 lines long. As I usually do, I had the file open and had searched through it for what was catching "rayaz". While I couldn't say with 100% certainty that another regex wouldn't have caught it, I was quite confident that there wasn't one.
The username regexes are not complex, and can be easily scanned visually, having eliminated most with the simple search used to find "rayaz". In addition, I'd done a search on MS to see what posts the regex was intended to catch, all of which were the username "Rayaz".
@EriktheOutgolfer True, but it's a relatively rare occurrence. It's not clear to me that we should spend additional developer time to come up with a rarely used method to accomplish that when there's an already a foolproof way of doing it, and the base files are available for when the person making the change wants to look through them. I guess it would depend on various trade-offs, but I'm not seeing it as a good cost/benefit at the moment. In addition, the negative consequences aren't that great
for having more than one pattern in the same list that could match a particular string. In fact, that's something that we do intentionally, from time-to-time. Sure, if it was in a different list, then it would be of more concern, as that might cause things to be caught by multiple reasons, without the intent to do so. However, all of the regexs in one file are built into a single actual regex, where some overlap doesn't have negative consequences. There are negatives wrt. maintenance.
@Undo @ArtOfCode any chance I could get an API key for MS?
so I can experiment with handling the API output data. Or does Smokey have an embedded MS API key? (IIRC there's no Smokey integrated API functionality for checking other smokedetectors or their statuses)
actually... @Undo @ArtOfCode how hard would it be to return with the MS API a 'mode' argument in teh JSON output to ID if it's in standby mode or not?
assuming the MS API documentation is up to date that is.
@ArtOfCode I think the filter generator and the MS api endpoints are... broken?
if I don't want the last ping time and don't include it in the filter I get an exception from the system
is there a "minimum required" for the filter for the smoke detectors?
@ArtOfCode if I select filter to only show me the smokey id, name, location, and is_standby, for example, I get a Rails error because last_ping isn't present so it errors out in the model code.
so is 'last_ping' mandatory?
if I'm reading the smoke_detector ruby handler properly, the answer would be "yes"...
@ArtOfCode @Undo the way I read the Ruby it suggested as such. I am on the commute home will give you a URL that triggers the ruby error I observed in a bit (where if I skip out last_ping in the filter it explodes)
@ArtOfCode @Undo https://metasmoke.erwaysoftware.com/api/v2.0/smokeys?key=VALIDAPIKEY&filter=GONMHGIIIKKMMHIGIL - filter generated by metasmoke.erwaysoftware.com/api/filters with selectors under smoke_detectors of id, name, location, and is_standby.
that triggers a Ruby explosion because it's expecting last_ping in the constructor that creates the JSON
which in turn creates the status_color object in the JSON array
adding in last_ping (and getting filter HMFMMNOHMKOKLKGFMH) however works
and it looks to me like the bare minimum necessary to operate without NULL values or errors for what I'm after (name, and is_standby, though I figured out a way to utilize status_color to get even better results for what I'm after) is, in fact, id, last_ping, name, is_standby (which gives the filter of HKHMLJKHOFNLGLOFNN which works for my needs)
I am now, however earlier it gave a different error
@ArtOfCode at this moment, yes. But previously, it was a Ruby-level error
about last_ping not being present or something along the lines of a NoneType equivalent error
which depended on last_ping which I hadn't selected in the filters (and was not in the requested data, actually). Selecting last_ping did, however, resolve the error(s)
IMO, if that is needed (and the way that code seems to behave, it is needed), that should not be allowed to be excluded in the filters
The bad news is, however
I don't have a way to test my new function written into the smokey branch I made lately (for SmokeDetector). (which is why I was looking at the API and the filters, consequently, in order to try and implement a detection mechanism using MS on whether there's more than one alive non-standby smokey and uses that to determine if there's going to be two Smokeys racing for the GitHub push (if the requested individual who called the blacklist add function has codeprivs))
actually yes there is
I have to run two TCOMs
at the same moment. That'll cause some "WTF" from MS I bet heh
hmm... @ArtOfCode @Undo is the /api/v2.0/smokeys endpoint supposed to show all smokedetectors?
