I haven't used Zotero in anger for a few years and can't get to my laptop right now to verify. But I used to rely on automatic exports to a folder that I sync'd elsewhere. Never used a paid Zotero subscription, never "self-hosted" it, and had many gigs of data (including PDF attachments) working fine for years.
I used "better bibtex" (?) to ensure files were reliably renamed and moved to an appropriate folder, all automatically.
A real set-and-forget setup that ran without hitch for years.
uh oh - didn't realize sync was paid (stupidly). apparently i am at 99.6% of the free tier
now i'm interested in the answer to your question - i have my own machine running 24/7 that i would love to use. i like the software enough that maybe i'd pay/donate
I am not very familiar with Juniper config, but this phrase summarizes it well. "This means we (AS13335) took the prefix received from Meta (AS32934), our peer, and then advertised it toward Lumen (AS3356), one of our upstream transit providers. " basically you should not receive a prefix from an eBGP session ( different AS) and advertize to an eBGP session. As they mention at the next steps, good use of communities could help avoiding it, in case of other misconfigurations.
Yes of course, but from a test perspective, this kind of mistake, given their configuration snippet and how they wrote the RCA, it seems to suggest they were simply diff-ing the initial and desired configs as any VCS would do (or, more likely, a Juniper “show|compare” command).
This didn’t catch the fact that removing that line essentially removed all conditions, allowing received routes to be re-advertised by the Miami router.
Communities are useful in this case, but this kind of thing could have happened with any kind of configuration.
Example:
(Before)
set firewall family inet filter FILTER NAME term TERM1 from source-address 10.10.10.1
set firewall family inet filter FILTER NAME term TERM1 from destination-port ssh
set firewall family inet filter FILTER NAME term TERM1 then discard
What happens when you remove references to 10.10.10.1, maybe because that IP is not blacklisted anymore? You’re simply removing one condition, leaving all ssh traffic to be discarded. That’s essentially what happened with the BGP outage, only here you have no BGP communities to save you.
That’s why I re-read the RCA, because this kind of incident is way more general than BGP-specific misconfigurations.
I think you could know the state of the peers and simulate what they advertise and receive and validate that. The test unit would need to be a simulated router that behaves exactly as the real one, I actually think its technically doable with tight version control for routers.
If successfull it could slow progression, and with better detection eventually greatly reduce the impact. Of course the whole thing could not happen, but i don't think we can say it will not happen right now.
Coming from a family that has cattle and dairy cows in south eastern Brazil, where screwworm is endemic, I was surprised when I listened to a podcast about screwworm, and some of the descriptions about how huge the problem was in the US. After some research it appears it affects more climates that are always hot and humid, and big operations where the animals are not being checked frequently. Also the handling at the 60s was probably much worse than modern techniques for avoiding animals being hurt and treating when they are infected.
