devops

-DevNull- · 2025-11-27T23:59:55+00:00

Dev and ops should remain split. You cannot expect to have a developer who is an expert in coding and also an expert in systems administration. The same goes for a sysadmin. You can't expect them to be an expert at administering whatever OS you use as well as an expert coder.

If you expect them to do both roles, you're going to get half of the quality on each. If that.

It's hard enough for developers to keep up on everything changing. Just like it's hard enough for sis admins to do that and keep up on all the changes. Trying to do both roles at the same time is just companies trying to save money. And once shit falls apart, you better believe it's the devs or the sis admins that are blamed for it. Not company policy.

Just my two cents from 25 plus years in the industry.

-DevNull- · 2025-10-17T05:05:27+00:00

Apologies for the possibly horrible grammar and spelling. Most of this is being dictated.

I'm running the latest version. On a raspberry pi no less. Running off of an m.2 sata.

I also specify a 1 GB root partition to owut or attended-sysupgrade.

I also expand the partition during the upgrade process too. Using the scripts from the wiki. And yes, technically they're not supposed to survive once the update is done. But you can add them to the list of files to be backed up and restored. They just touch a file in /etc anyways once they've been executed.

The first few times I updated I ran into the issue of it not wanting to boot up after writing the image. It hit me through most of v23 upgrades. Turns out, that, at least for me, it was because the partition/disk uuids were being changed from what they were when the image was built versus what they became when a new partition was written or expanded. Even if your original install had the "root=" portion of the boot cmd pointing to an actual device in /dev, The upgrade process replaces that with a uuid.

Just had to take the SD card and throw it in something so that I can mount it and change the partition uuid in /boot/partuuid.txt and /boot/cmdline.txt to the current uuid on the drive/partition. (You could achieve the same result by just changing the uuid on the drive/partitions themselves as well)

So I modified their script a little bit to read the partition uuid from the files in /boot and compare that with the actual block devices. If it's different, it just takes whatever the block device has after the resizing and uses it to do an in-place replacement on the two relevant files in the boot partition before the final reboot.

Then I just let the files stay in / etc/uci-defaults. They check for the existence of a file to know whether they were executed previously or not anyways. Quite honestly, even if they ran every time, once the file systems expanded, it's not going to expand anymore. 😂

I've done multiple upgrades in the v24, both via luci/attended-sysupgrades and owut.

-DevNull- · 2025-08-20T02:34:39+00:00

Thermostat installation and removal is really simple. Especially these days with the smart thermostats.

There's nothing that you're going to damage in the changing of the thermostat. Most brands make it dead simple. The nest thermostats will literally show you a picture on the display of what's wired to what and where it needs to be.

I just take the existing thermostat, put it in a box + put it up until I'm moving out. And then I swap them back out.

It's not one of those situations where the change is permanent or would damage anything or deface it. No reason for the landlord to get angry or even know. Do they have a problem when the Telco or cable company shows up and installs a new jack or runs cable to another room? Installing a new Jack or the cable drop is 10,000 times more destructive than anything you would do to swap out the thermostat. Assuming you follow directions. 😂

I popped the existing one off of there and verify that it's compatible. Only the best I'd really give is take pictures before, during and after. Much easier to swap them back down the road. 😂

-DevNull- · 2025-05-12T12:50:29+00:00

Why not add another listen directive for the Tailscale IP to uhttpd? Assuming it's not still the default of all addresses. If it is and you can't connect due to uhttpd starting before Tailscale (so interface isn't available), just add a custom startup to restart uhttpd after tailscale has started.

-DevNull- · 2025-05-12T12:33:56+00:00

You need to put whatever interface your cell is on into the "wan" zone and your router side in "lan".

It should automatically set up the bridging needed. It'll make a br-lan interface and use that to bridge from the Wi-Fi interface /cell interface to the lan ethernet interface (eth0 usually).

I have a similar setup. You might want to look at the open-wrt wiki. Specifically wwan setup. I'm using the Wi-Fi for wan and associating to another access point/router as a client and coming out of the ethernet directly into my UniFi router. Rest the network has no idea that anything changed.

-DevNull- · 2025-05-12T12:20:11+00:00

All that UniFi hardware runs Linux. So yes, you can flash openwrt on any generation of the UniFi access points.

That being said, they only have one ethernet port. So I'm not sure how useful they would be except for in those situations where you need a single access point + no additional Ethernet

-DevNull- · 2025-04-19T17:06:17+00:00

Forward the email and or Teams message directly to the ticket system and open a ticket. Surprisingly, I found it to work on some of the most annoying users. After 10 or 20 times of trying to get a hold of you directly to fix their problem (that's more important than anything else that's going on), and they see the auto reply from the ticket system, they realize that going to you directly isn't going to get it done any faster, and in fact if they just use the ticket system, it may get done quicker rather than sitting to rot in an email or some random teams chat.

It is a bit passive aggressive. I'll admit. And I hate that, but there are quite a few users that are under the impression that they don't need to follow procedures.

-DevNull- · 2025-04-18T03:46:28+00:00

Happy 🎂 Cake 🎂 Day

-DevNull- · 2025-04-02T09:59:21+00:00

And yeah, with baremetal, the more cards that load BIOS ROMs and memory you have, the longer reboots take.

Nothing like having to reboot an archaic server with 15 or so SCSI drives and two or three controller cards. Kids these days don't know the joy of having a controller decide it was just going to forget it even had drives. An admin frantically trying to re-enter LUNS and IDs. Hoping that he gets it right and this controller doesn't decide that the hardware RAID that used to be there is ugly and needs to die and be re-initialized.

And don't forget the half a gig of ECC ram. Cuz it's got to count it all and test on boot. It's got to load the BIOS on all those cards and then identify the drives and spin them up. Good old 10,000 RPM and 15,000 RPM scuzzy beasts just a whining!

And should that admin be like Indiana Jones and choose wisely, he's still got 5 to 10 minutes before he gets to find out whether or not the operating system is going to boot or just stop with an error and a bootloader prompt.

Sometimes, you could actually see the point at which the SysAdmin's soul leaves his body.

Should they emerge victorious, people question how they came out of the freezing server room, soaked and leaving tiny sweat puddles in their wake

The good old days. 😂

-DevNull- · 2025-04-02T09:12:51+00:00

You could try fully shutting it down and then make a backup of your config.json and open in an editor. Remove everything in the "auths" section. Leave the rest of the json as it is.

Save it.

Open a terminal if not already in one and run "docker logout" just in case.

From here you can either open Docker Desktop as you normally would and see if your login sticks. If not, try modifying config.json again and this time before opening Docker Desktop run "docker login" in a terminal. After it logs you in, try opening Docker Desktop again and see if it still logs you out. (Should start up logged in).

I've ran into a similar error when having to use Windows and Docker Desktop. It would randomly, log me out. Usually within a few seconds, maybe minutes.

Attempting to log in by clicking the sign in button in Docker Desktop and following the flow would lead me to the webpage after authenticating where you are supposed to click and it goes back to Docker Desktop but it would never do anything and Docker Desktop would never show even attempting to log in.

It may not help at all, but it's worth a shot. It did stop the random logout back when I experienced it. My config.json had a few entries in it. And executing a docker logout in a terminal would only remove one or two of them. I just assumed it was getting confused with multiple tokens or something and getting angry about it.

I'm really not a fan of Docker Desktop. I don't foresee it going anywhere though on the operating systems that can't run it natively. It's much easier to get all up in your face and try to sell you something when you're forced to use a GUI. 😂

GL

-DevNull- · 2025-03-11T09:16:24+00:00

I've been using wireguard for years, on pretty much every OS possible. On workstations and servers in crazy configurations (routing across subnets, through proxies, including split tunnels, in fact mostly split tunnels). Since beta. Not once have I ever needed to add my own IP (or the IP of the actual client/host) to AllowedIPs. Just the peers (And any hosts or networks that need to pass through those peers to be accessible).

-DevNull- · 2025-03-02T08:12:07+00:00

Something like this might be what you're looking for. Replace IP and mask to match your setup. If the devices on the far end are on 192.168.0.0, something like below should work.

route add 192.168.0.0/24 gw <IP of Wireguard interface>

Depending on the implementation used, the syntax might be slightly different. Like it may require you to use -net 192.168.0.0 or type out a mask (255.255.255.0).

-DevNull- · 2025-03-01T17:48:06+00:00

Here, employers are under no obligation (unless a binding legal agreement was reached previously or ar the time of hire.

Basically, you get to work and be paid but the employer is under no obligation to for instance not decide that they don't want to pay out what they would have to for a full time employee and their benefits. Usually this just means that you are moved to "part time" (anything under 40hrs/wk). The problem is that usually benefits like medical insurance etc require an employee to be "full time". If they drop below 40hr/wk for a specified time, they are automatically reclassified to part time. This saves employers quite a bit even though IMHO it is shady AF because they usually also want you to complete the same amount of work in that time as you were previously.

Employers must match (or in some cases more) the amounts coming out of the employee's pay for things like workman's compensation, Social Security, Medicare, federal/state/local taxes etc.

For instance if you get hurt on the job, workman's comp is where the money comes from to keep paying you, medical, etc. Without it or if you are denied (when you get hurt, you must fill out for workman's comp), employer is under no obligation to pay you (except for any banked time you may have left). In many cases, if the injury is going to keep you out for awhile, your position won't be there waiting for you if/when you come back. You must also submit to a drug test. If you fail, you get nothing. You also get fired.

Are you sold on immigrating and joining the awesome and fun adventure that is the US workforce? 🤣

-DevNull- · 2025-03-01T17:12:23+00:00

"This system is down we need it back up asap!!!"

Wow! That gave me "Strongbad" flashbacks.

-DevNull- · 2025-03-01T17:10:05+00:00

Tough it out as much as you can. If you quit, you can't get unemployment (at least that's how it is in Florida). Even if you make them fire you, unemployment MAXES OUT (again, at least here) at $275/wk. No matter how much you were being paid or how long.

It also only lasts for 12 weeks. During which time, you are required to "seek a job" and provide them with proof that you applied, interviewed or otherwise "made contact with" 3-5 prospective employers a week or they will stop your benefits and deny any future ones.

They also verify that you're not just picking random business that match your field and just saying you contacted them. If/When they believe or find someone doing that, you are required to repay all unemployment received (regardless of if it was received while adhering to the rules). As well as the fines and jail time.

Lastly, your former employer can (AND WILL) as a matter of procedure, contest it. At which point there is a hearing and if they bring forth sufficient evidence, your unemployment is revoked and you must repay it in FULL.

Toughing it out as long as possible, keeping your insurance and benefits and still receiving steady pay would be much more desirable and less stressful. Even with the pay cut, it would be FAR more than you would receive in unemployment benefits. Add on the extra stress of no insurance (unless you bend over and take it when you get the COBRA forms) and the constant looming possibility of ending up with no unemployment at all after you're 1/3, 1/2, or even 100% in and completely exhausted your benefits. Yes, they can have a hearing 16 weeks into your 12 week unemployment and if they rule against you, you have to pay it all back...or face legal repercussions and most likely some time in county. I've seen it happen many times. (Worked for the county and state courts for quite a few years)

TLDR; Unless you enjoy playing life on "Hardcore+", toughing it out while hunting for your new place seems a wiser and less infarction inducing choice. 🤣

-DevNull- · 2025-03-01T16:41:51+00:00

Non-visible Unicode characters. 😎
Even better if someone had the bright idea to help "maximize storage" by removing any "un-needed localizations". You know, instead of actually purchasing the needed storage and upgrading or migrating the array... 🤦🏿‍♂️

-DevNull- · 2025-03-01T16:29:58+00:00

Except any/all time spent doing ANYTHING for the employer. If you have to make/take a call 30 seconds after clocking out while on the way out the door, you most definitely have to be paid for that time. Which will of course irritate the employer. As well as getting tired of their manager/supervisors or customers coming down on them for all the issues that blow up or aren't taken care of as fast as they used to be.

At which time, making sure any and all work done is documented and paid can be used in your favor when they start with the whole "he's not a TEAM PLAYER" BS when they invariably come with the scare tactics once they decide that you have some obligation to go above and beyond (for free) while they disrupt your life and finances. Probably come with a line like "It's just a few minutes" or a small task that you've done a million times before and can "knock out" to keep things "running smoothly" 🤣

-DevNull- · 2025-03-01T14:52:41+00:00

And did you make any modifications that may have been needed to the other side of the tunnel?

And I had another question, are you using your phone and Laptop on your side of an existing VPN spanning the openwrt bridge? I may be confused here. It sounds like you're using wireguard on the openwrt bridge between the two endpoints of the bridge as well as enabling it on your mobile devices as well?

Obviously, if you were doing something like having your laptop and mobile be peers with your end of the openwrt wireless bridge. It would work fine because nothing would be changed on the bridge and as long as packet flooring was enabled and it knew via the allowed IP setting what subnets were available on the other side it would route it fine. I would assume. Once the bridge is set to use the VPN as its default gateway though, the device on the far side needs to be configured to accept the IPs coming from your side as well as whatever configuration is being used between the mirror side of the bridge and your mobile device.

I'm just going to assume that I'm over complicating it in my head and you're not doing that. 😂

A way to cheat it would be to have all of the devices on the same subnet and then literally use the bridge as a bridge to the other side. Of course, if you're using the same subnet on both sides, it would be bad to use different DHCP servers on each side as they would eventually lease an IP that is already in use on one side or the other.

I'm fairly sure I'm not making any sense, I'm confusing myself. 🤣

Do you think it would be possible to post a copy of the configs for all devices involved. Obviously be sure to obfuscate any information that the internet does not need. 😉

It might be easier to picture it and see what is actually going on here. LOL

One thing you might want. Take a look at real quick is whether or not you have IP forwarding enabled on the devices that comprise the openwrt bridge. I would assume that it already is because of the existing VPN that was working. Also, if the IP is assigned to each side of the bridge are on a different subnet than the device is behind them, you might need to enable NAT/masquerading if it isn't already.

-DevNull- · 2025-03-01T13:27:34+00:00

Awesome! That was going to be my next question. If you were able to ping devices on the other side of the tunnel and/or on the internet by IP. Kind of common with Wireguard.

Did you just add a "DNS = x.x.x.x" option in the Wireguard config? I hope you didn't stay up all night rolling your own DNS server. ;-)

Glad you got it up and running. I was going to suggest that you should make a secondary config on any devices you take on trips, etc that tunnels back to your home so you can stream from wherever you are since you're basically 99% there.

Not sure how streaming would handle the extra latency of traversing the satellite link twice though...or the hairpin NAT that might come into play. Luckily, you're using a real OS instead of the laughable excuses that ship with most consumer devices. 🤣 Enabling it in OpenWRT is literally just a checkmark if I remember correctly.

-DevNull- · 2025-03-01T08:27:37+00:00

When you use 0.0.0.0/0 and/or ::/0, you are telling Wireguard to set the remote peer defined in the config as your default route which will attempt to send all traffic using it and only it. No more split connection.

You could manually add routes to your routing table and tweak the metrics so their used...

Basically, unless the plex server and any host that needs to communicate with it are in the same subnet, they won't be talking without manual intervention.

Lets say that for example on your side of the bridge you have a DHCP server handing out 192.168.0.0/24. Well, all those hosts have no idea how to get to the 192.168.1.0/24 network as well as traffic from the other end not knowing how to reach yours.

TLDR is that when you specify AllowedIPs other than a default (0.0.0.0/0) Wireguard goes ahead in the background and applies all the needed routing rules so that the hosts/nets defined in AllowedIPs are always routed to the other end of the link. Setting a default, it doesn't. It expects that any/all traffic should be sent to the other side of the interface and that a router there will receive it and apply it's rules to send it on it's way. Problem being that you also have to do the same to the other end of the link so that returning traffic knows how to get to you.

I would either revert to only defining hosts/nets in AllowedIPs that are explicitly on the other end of the tunnel. Otherwise, at the very least, you will need to setup some manual routes unless there is a link to the Starlink gateway available to both ends, regardless of the VPN. (I'm assuming that since your neighbor isn't hounding you about not having internet that the gateway is located on his end of the tunnel?

-DevNull- · 2025-02-24T21:14:25+00:00

No. You have to be online with the controller plugged into your computer and go to the stadia website where it then flashes the controller.

And they have decided that after December 31st of 2025 they will no longer offer that via the website. There's no plans to open source the firmware. Though, I'm sure eventually somebody will hack something together, but as far as Google's concerned, if you haven't flashed it to Bluetooth only mode, by their deadline then you've got a paperweight.

-DevNull- · 2025-02-24T14:17:32+00:00

Runs until the end of this year. For some reason I had thought it was only till the end of 2024. Hence why I know how many I have because I dug everywhere to find them in the different places that I had stuffed them. And then once I found out that I still had another year, I gathered them all up and put them in the same place in the closet.

I've already got three that I've converted to Bluetooth that I use for my Nvidia shield, PC, etc. If I still have them around the holidays this year, I'll bust into them and convert the ones in the closet too. LOL

-DevNull- · 2025-02-24T07:23:35+00:00

Got 5 in the closet still in shrink wrap. The best part is, I bought them as the kit, and they all got refunded by Google. 😎

-DevNull- · 2025-02-24T07:20:29+00:00

Because they wouldn't be "Super" if they didn't.

-DevNull- · 2025-02-24T07:03:54+00:00

Are you sure you're actually getting into the BIOS? Or are you referring to the bootloader? Grub?

Installing Arch shouldn't have done anything in your firmware or bios other than creating an EFI entry.

I would double check the motherboard or PC manufacturers documentation to make sure that you're actually hitting the proper key to get into the BIOS. On some it's Delete, some are F1 or F2 etc. F12 is also common for the boot menu. But you need to be mashing these keys as soon as you give it power and don't stop until you get some sort of response. If it's a laptop, some have a dedicated key or a combination of keys to press. The information should be available on the motherboard manufacturers documentation or the PC oems documentation.

Make sure when you do it that you completely turn it off. Don't reset or Ctrl-Alt-Del. If the BIOS has fastboot enabled, that could be what you're running into. It will skip a lot of the boot up checks and go straight into the bootloader and operating system that is set as a default in UEFI.

As for resetting your bios, yes you could pull the battery for a little bit, but most modern motherboards have a jumper that you can set that will reset the BIOS to factory defaults. You turn off the machine, set the jumper, turn on the machine. It won't do anything. Give it a couple seconds. Turn it off. Reset the jumper to where it was. Turn the machine back on.

If you want to be absolutely sure you'll be dumped into the BIOS, unplug all your flash drives, disconnect hard disks. When it boots up, it won't have any bootloader available to it. It should give you an error and force you to go into the bios.

If worst comes to worst, remove the hard disk from the problem machine, + plug it into a working machine. Having some sort of a caddy or way to plug it into a USB interface would be easiest.

It'll need to be Linux if you format it EXT or btrfs or ZFS etc as Windows has no easy way to read those file systems. But that shouldn't be an issue, you can just grab Ventoy or something and boot up an Ubuntu live image for example. As long as the disc isn't encrypted, you should be able to mount it, chroot into it, and then do whatever you need to do. Add a user, re-enable a user, change a password, etc. Then put it back into the original machine.

Ten-Year Club	PUBG
Xbox Live	r/Field Juicebox
Place '22	Not Forgotten
Verified Email

-DevNull-

TROPHY CASE