ODBC, ISP IPv4 grab, Osada, Notifications, Cloudflare, DANE/TLSA, SHACAL

Daily fun, with Python and ODBC. Had to work with databases, which were designed by other team and required really complex join stuff and had annoying variable and table names. I had to write separate lookup routine to find the data indexes from the row using cursor description. Because references like this-table.this-column won't work obviously with ODBC directly. There are two ways, either format whole row as dictionary, or instead of that just mapping descriptions with enumeration to dictionary, which then allows getting the row indexes easily using the description string. I've actually done this several times in past, but every time when you encounter it, it causes slight frustration why it's like this. It would be so nice, if the row would directly allow references using strings, instead of only index numbers. - But this is relatively nice way of doing it. The worse ways dealing with it, is using magic number indexes or renaming every output using as in SQL query. Of course that also works. In general I do not like glue, redundant, obfuscating and brittle -code.
Daily WTF. ISP dropped routed traffic to our own static addresses. Why? Because their internal documentation lacked information about our static addresses. Ok, they quite quickly recovered the routing, but it was once again silly mess. Yet it was quite easy to analyze, when I saw that links are up, there's some traffic, but primary (routed) traffic isn't getting through and there are responses destination unreachable from OSPF based routing. Business as usual. But now it's working again. After checking with friends, this seemed to happen widely, only way to get the addresses back was to request for it. It's likely that they're just doing unholy IPv4 address grab to get addresses, in case the end users wouldn't notice it at all.
Alitalia Flight 404. Typical, messed up crew, system which gives incorrect indication about it's status as well as lack of secondary warning system (minimum altitude) and busy flight traffic control -> didn't warn about fail. So four different systems failed at once, but as it's obvious at least two of the systems failed "by design" or didn't have adequate controls in place. This is good example how many of the IT systems and projects fail as well. Luckily in most of cases, this won't kill anyone. But who knows what the indirect consequences in some cases are.
Added to specific alarms systems direct integration to Slack, Telegram and Teams & Android via GCM. These platforms provide really easy and super nice to use integration environments. Now it's possible to get critical alerts as direct notifications on your phone, via any of those channels, additionally instead of more traditional SMS and email.
Tested social network Osada. Nothing special yet another platform, which I don't really have any need to use after the initial test.
Moved my domains DNS to Cloudflare, at least that worked well. Thank you Cloudflare for doing good and usable stuff. Namecheap didn't support IPv6 nor HTTPS domain forwarding, Clouflare fixed both of those issues.
Some notes about DANE and TLSA when using Let's Encrypt certificates. Yet it all makes perfect sense. Who says, you need to use ready scripts, usually admins are very comfortable writing own scripts when required. Also great a post DNSSEC DS and DANE TLSA common mistakes. See: DANE / TLSA @ Wikipedia
SHACAL cipher @ Wikipedia - Yet another basic cipher, from existing building blocks.
Misc, Tested: TOTP, RDP, SSH, Microsoft Authenticator, MePIN, Office 365 Authentication, Mobile SSO, LDAP, OKTA Verify MFA, OTP Push mobile app, Geo-location with Dynamic Zones, Authentication user device detection, Okta MFA SDK.

2020-03-22