GitLab, aLTEr, Date format, Email, Article 13, Credentials

• GitLab announced that they're moving from Azure to GCP. Sure, Object Storage and Cloud Data Bases can be really nice, for some purposes. Especially if and when rapid scaling is required.
• aLTEr Attack - Fully read yet nothing new really. Just good old stuff applied to LTE. Yet one more reason to use authenticated ciphers / protocols.
• Reminded my self about official date and time formats used in Europe as well as which countries make exceptions. Like Finland. It's nice that EU has adopted YYYY-MM-DD ISO 8601 date format as date time notation standard. And about exceptions, well Finland. We do use time with . not with : and we do nut use leading zeroes for hours as well as the date format is DD.MM.YYYY without leading zeroes. What reminded me about this? Well, date and time formats used with Windows Server 2016 are finally correct.
• Pure pain, let's encrypt and Microsoft Email Server. I'm just thinking if I should really suffer with PowerShell, or if I should do the traditional horror kludge, where I implement logic in Python and then just call PowerShell commands from my script. In this case, the task is something which could be of course done in pure PowerShell. But that would be just so painful to implement. Task is quite simple: Find newest certificate for domain X and copy it from "Web Hosting" to "Personal", as well as remove older certificates for this domain from the Personal path. Doable? Sure, painful, guaranteed. I've actually managed to automate the certificate renew and validation with IIS and Letsencrypt-win-simple. But I got so fed up with this stuff, that I'll probably continue some other day the part where the certificate is installed for practical use. - But this is the normal way, how you suffer, cry and learn. - It's just so enraging that Letsencrypt-win-simple always places the certificates in Web Hosting and that's not configurable even in the advanced configuration manager, it's hard coded. It would have been just so simple to change the location where the certificates are stored. Also requiring extra scripts and things to be run and managed, is kind of horror. Because when something then randomly breaks up after 4 years, like the certificate renewal fails. Then you're so badly screwed trying to get it fixed quickly. There will be so many WTF moments. It's great design to make everything very complex and brittle. At least if you prefer trolling yourself.
• Well, it wasn't as painful after all as I expected it to be. Around 1,5 hours later I got it all working. Now SMTPS SSL / TLS certificates are automatically renewed monthly and installed. I'll have to monitor that for a while, to be sure, it actually works. But at least all testing has passed so far. When I got it going, I also added FTPES support for a few sites. And I did the scripting in proper way, meaning that I'll remove expired certificates and so on. And not the normal "coder" style, where I would just generate new keys and certificates and leave expired ones lying around. Which seems to be the norm with many developers. Anyway, every time now on when I use PowerShell it's just going to get easier and easier when I learn stuff. Bash scripting was also way painful around 25 years ago, but now it's totally trivial. Everything is also Windows EventLogged now properly, allowing easy debug in case something fails.
• All that discussion about Article 13 (EU). On many platforms censorship is already so devastatingly bad, that all discussion has moved to private and or underground platforms long ago. Why people are using public, problematic, privacy invading platforms. When perfectly good and even better alternative is using private, closed, secure, platform, where there is no censorship at all. No logs and only encrypted data. Even if the unlikely happens, and site gets raided, there's pretty little to stick with. Unless it's long term infiltration operation, and who would bother doing that for basically nothing that serious.
• User Account Management. In on case, when user accounts were checked, it was found out that over 80% of the active user accounts belonged to users fired from the company. In some cases several years ago. - Standard security procedure? - Close user accounts for fired people, around every 10 years or so.

2019-12-08