est.social on üks paljudest sõltumatutest Mastodoni serveritest, mida saab fediversumis osalemiseks kasutada.
est.social on mõeldud Eestis üldkasutatavaks Mastodoni serveriks. est.social is meant to be a general use Mastodon server for Estonia.

Administraator:

Serveri statistika:

88
aktiivsed kasutajad

#devops

28 postitusega27 osalejaga2 postitust täna

howdy, #hachyderm!

over the last week or so, we've been preparing to move hachy's #DNS zones from #AWS route 53 to bunny DNS.

since this could be a pretty scary thing -- going from one geo-DNS provider to another -- we want to make sure *before* we move that records are resolving in a reasonable way across the globe.

to help us to do this, we've started a small, lightweight tool that we can deploy to a provider like bunny's magic containers to quickly get DNS resolution info from multiple geographic regions quickly. we then write this data to a backend S3 bucket, at which point we can use a tool like #duckdb to analyze the results and find records we need to tweak to improve performance. all *before* we make the change.

then, after we've flipped the switch and while DNS is propagating -- :blobfoxscared: -- we can watch in real-time as different servers begin flipping over to the new provider.

we named the tool hachyboop and it's available publicly --> github.com/hachyderm/hachyboop

please keep in mind that it's early in the booper's life, and there's a lot we can do, including cleaning up my hacky code. :blobfoxlaughsweat:

attached is an example of a quick run across 17 regions for a few minutes. the data is spread across multiple files but duckdb makes it quite easy for us to query everything like it's one table.

Hey Mastodon, question for my #sysadmin and #DevOps types. Has anyone used #Pester and #PSScriptAnalyzer to set up unit testing for test driven development, particularly on (relatively) simple scripts like you might use for application detection, installation, and uninstallation from a system like #SCCM #Intune or #ManageEngine ?

Apologies for the buzzword bingo, but I’m trying to reach folks who may be following the hashtags, but not necessarily have a connection otherwise.

Another round of “hey, your server is down!” drama from the "we need moar kubernetes!" crowd.

“I can’t reach your server, it must be down.”

I connect. Everything’s fine.

A few emails later, I ask to access the container. The dev says he can’t - doesn’t know how. He’s a nice guy, though, so he gives me the credentials.

I log in and find the issue: someone pushed a workload to production (cue Kubernetes! Moooaaarrr powaaaarrr! We have the cloud! Who needs sysadmins anymore?!) with DNS set to 192.168.1.1.

Of course, it fell to me to investigate, because the dev couldn’t even get a shell inside his container. And it's ok, as he's a dev - and just wants to be a dev.

Once I pointed it out, they rebuilt the container with the correct config and - TADA! - everything worked again.

Then he went to check other workloads (for other clients, not managed by me) that had been having issues for weeks... Same problem.

It was DNS.
But it wasn't DNS.

#IT#SysAdmin#DNS

Regal v0.32.0 just dropped! After having worked mostly on language server features recently, it was time for the linter to get some love. This release includes 3 new linter rules as well as much faster linting. Check it out!

github.com/StyraInc/regal/rele

This release adds 3 new linter rules to Regal, as well as many improvements and fixes.
New Rule: redundant-loop-count
A loop iterating over empty collections evaluates to nothing, and counting the ...
GitHubRelease v0.32.0 · StyraInc/regalThis release adds 3 new linter rules to Regal, as well as many improvements and fixes. New Rule: redundant-loop-count A loop iterating over empty collections evaluates to nothing, and counting the ...
#OPA#Rego#Regal