cross-posted from: https://lemmy.world/post/22872422

Windows Server 2022 creates one recovery partition just on the right of the C: partition. So, when it is required to expand the C: partition it is impossible due to this recovery partition. I realised of this problem because our IT department provides Windows Server virtual machines users are unable to expand.

I would like to know how are you dealing with this problem. Do you remove the recovery partition? Do you keep the recovery partition? how?

Found here.

If you're in the U.S. anyway.

Recently Microsoft released the link 365 which is basically a thin client for Azure. You can't run anything locally nor is there any local files. It literally just connects you to a desktop elsewhere.

Do you think this is what Windows 12 might look like? I feel like this idea is not practical for average consumers. Maybe they will make something that's like Chrome OS?

It's just a fad. It'll pass.

Spent the last 3 months getting requirements for computer upgrades. After that picked out some decent laptops. (Thinkpad L and T series)

Nothing fancy, but I'm just tired of diagnosing problems with previous sysadmin purchased Vostro laptops.

After getting quotes from multiple vendors, finally got everything and sent the CEO to confirm. Guess fucking what... It got fucking denied.

"Look for cheaper laptops and replace only whats critical"

Employees are rocking 7 year old laptops with 128G SSDs! The bloody things can't even run Win 11! The whole upgrade costs less than their single "teambuilding"! I hate this these cheapskates so fucking much...

I was literally told to set up this new service as quickly as possible and it didn't need to be correct or best practice because this was just a proof of concept.

Here we are 6 months later and I'm still cleaning up my own mess.

Let me tell you about the hell that is Roku. They create so much wireless interference and I can't just get rid of them.

The problem stems from WiFi direct. They automatically scan for the busiest channel and then broadcast full strength on that channel. I don't know why they do this but it creates a crazy amount of interference.

And before you ask, no you can't turn WiFi direct off. Also the remote uses WiFi direct for some reason.

WHY, ROKU WHY!

What are you guys working on? Anything new in the world

Doing a PhD in humanities and enjoy it. I’ve recently really started to enjoy Linux, self hosting, and messing around with various lab stuff.

[email protected]

This is a Chinese attack that targets Azure

Tick tick

Anyone here have any experience with a Datto Backup Appliance?

I have just been told that they've never run a full restoration in the six years that it's been in service, deployed for the backup of four mission critical virtual Windows Servers, four Windows Workstation and a (physical?) Linux PABX server.

The actual appliance is apparently a "Datto S3-2000 BCDR"

Edit: The anal retentive in me is going WTF in a tight loop. The industry professional with 40 years experience in the field is going, different day, same old...

I realised that I didn't actually ask the pertinent question, the hamster wheel was running full tilt, but is this normal, or is this WTF, or somewhere in-between?

As you all might be aware VMware is hiking prices again. (Surprise to no one)

Right now Hyper-V seems to be the most popular choice and Proxmox appears to be the runner up. Hyper-V is probably the best for Windows shops but my concern is that it will just become Azure tied at some point. I could be wrong but somehow I don't trust Microsoft to not screw everyone over. They already deprecated WSUS which is a pretty popular tool for Windows environments.

Proxmox seems to be a great alternative that many people are jumping on. It is still missing some bigger features but things like the data center manager are in the pipeline. However, I think many people (especially VMware admins) are fundamentally misunderstanding it.

Proxmox is not that unique and is built on Foss. You could probably put together a Proxmox like system without completely being over your head. It is just KVM libvirt/qemu and corosync along with some other stuff like ZFS.

What Proxmox does provide is convenience and reliability. It takes time to make a system and you are responsible when things go wrong. Doing the DIY method is a good exercise but not something you want to run in prod unless you have the proper staff and skillset.

And there is where the problem lies. There are companies are coming from a Windows/point in click background who don't have staff that understand Linux. Proxmox is just Debian under the hood so it is vulnerable to all the same issues. You can install updates with the GUI but if you don't understand how Linux packaging works you may end up with a situation where you blow off your own foot. Same goes for networking and filesystems. To effectively maintain a Proxmox environment you need expertise. Proxmox makes it very easy to switch to cowboy mode and break the system. It is very flexible but you must be very wary of making changes to the hypervisor as that's the foundation for everything else.

I personally wish Proxmox would serious consider a immutable architecture. TrueNAS already does this and it would be nice to have a solid update system. They would do a stand alone OS image or they could use something based on OStree. Maybe even build in a update manager that can update each node and check the health.

Just my thoughts

What is this thing?

That's sounds strange to say but hear me out. Before ransomeware there was no economic incentive for companies to worry about security. There was a strong "why would you hack us" vibe that made it hard to talk management into doing anything basic like locking down ports.

Nowadays everyone and there mom is worried about getting compromised. I've seen companies who historically didn't care at all about IT suddenly invest heavily in security. We are now much more secure than we were previously as everyone has suddenly realized that the internet had a huge risk. I doubt we will see any of the old style worms we had back in the day that would infect millions of machines.

I haven't seen it yet, and this one is near and dear to my heart.

Update your stuff -- this one's been affecting Enterprise Linux for maybe 12 years, versions the distros have long since grown bored of supporting, so essentially every EL install out there. So great.

This article will describe how to download an image from a (docker) container registry.

Manual Download of Container Images with wget and curl

Intro

Remember the good `'ol days when you could just download software by visiting a website and click "download"?

Even apt and yum repositories were just simple HTTP servers that you could just curl (or wget) from. Using the package manager was, of course, more secure and convenient -- but you could always just download packages manually, if you wanted.

But have you ever tried to curl an image from a container registry, such as docker? Well friends, I have tried. And I have the scars to prove it.

It was a remarkably complex process that took me weeks to figure-out. Lucky you, this article will break it down.

Examples

Specifically, we'll look at how to download files from two OCI registries.

1. Docker Hub
2. GitHub Packages

Terms

First, here's some terminology used by OCI

1. OCI - Open Container Initiative
2. blob - A "blob" in the OCI spec just means a file
3. manifest - A "manifest" in the OCI spec means a list of files

Prerequisites

This guide was written in 2024, and it uses the following software and versions:

1. debian 12 (bookworm)
2. curl 7.88.1
3. OCI Distribution Spec v1.1.0 (which, unintuitively, uses the '/v2/' endpoint)

Of course, you'll need 'curl' installed. And, to parse json, 'jq' too.

sudo apt-get install curl jq

What is OCI?

OCI stands for Open Container Initiative.

OCI was originally formed in June 2015 for Docker and CoreOS. Today it's a wider, general-purpose (and annoyingly complex) way that many projects host files (that are extremely non-trivial to download).

One does not simply download a file from an OCI-complianet container registry. You must:

1. Generate an authentication token for the API
2. Make an API call to the registry, requesting to download a JSON "Manifest"
3. Parse the JSON Manifest to figure out the hash of the file that you want
4. Determine the download URL from the hash
5. Download the file (which might actually be many distinct file "layers")

One does not simply download from a container registry

In order to figure out how to make an API call to the registry, you must first read (and understand) the OCI specs here.

• https://opencontainers.org/release-notices/overview/

OCI APIs

OCI maintains three distinct specifications:

1. image spec
2. runtime spec
3. distribution spec

OCI "Distribution Spec" API

To figure out how to download a file from a container registry, we're interested in the "distribution spec". At the time of writing, the latest "distribution spec" can be downloaded here:

• https://github.com/opencontainers/distribution-spec/releases/tag/v1.1.0
• https://github.com/opencontainers/distribution-spec/releases/download/v1.1.0/oci-distribution-spec-v1.1.0.pdf

The above PDF file defines a set of API endpoints that we can use to query, parse, and then figure out how to download a file from a container registry. The table from the above PDF is copied below:

ID	Method	API Endpoint	Success	Failure
end-1	GET	/v2/	200	404/401
end-2	GET / HEAD	/v2/<name>/blobs/<digest>	200	404
end-3	GET / HEAD	/v2/<name>/manifests/<reference>	200	404
end-4a	POST	/v2/<name>/blobs/uploads/	202	404
end-4b	POST	/v2/<name>/blobs/uploads/?digest=<digest>	201/202	404/400
end-5	PATCH	/v2/<name>/blobs/uploads/<reference>	202	404/416
end-6	PUT	/v2/<name>/blobs/uploads/<reference>?digest=<digest>	201	404/400
end-7	PUT	/v2/<name>/manifests/<reference>	201	404
end-8a	GET	/v2/<name>/tags/list	200	404
end-8b	GET	/v2/<name>/tags/list?n=<integer>&last=<integer>	200	404
end-9	DELETE	/v2/<name>/manifests/<reference>	202	404/400/405
end-10	DELETE	/v2/<name>/blobs/<digest>	202	404/405
end-11	POST	/v2/<name>/blobs/uploads/?mount=<digest>&from=<other_name>	201	404
end-12a	GET	/v2/<name>/referrers/<digest>	200	404/400
end-12b	GET	/v2/<name>/referrers/<digest>?artifactType=<artifactType>	200	404/400
end-13	GET	/v2/<name>/blobs/uploads/<reference>	204	404

In OCI, files are (cryptically) called "blobs". In order to figure out the file that we want to download, we must first reference the list of files (called a "manifest").

The above table shows us how we can download a list of files (manifest) and then download the actual file (blob).

Examples

Let's look at how to download files from a couple different OCI registries:

1. Docker Hub
2. GitHub Packages

Docker Hub

To see the full example of downloading images from docker hub, click here

GitHub Packages

To see the full example of downloading files from GitHub Packages, click here.

Why?

I wrote this article because many, many folks have inquired about how to manually download files from OCI registries on the Internet, but their simple queries are usually returned with a barrage of useless counter-questions: why the heck would you want to do that!?!

The answer is varied.

Some people need to get files onto a restricted environment. Either their org doesn't grant them permission to install software on the machine, or the system has firewall-restricted internet access -- or doesn't have internet access at all.

3TOFU

Personally, the reason that I wanted to be able to download files from an OCI registry was for 3TOFU.

Verifying Unsigned Releases with 3TOFU

Unfortunaetly, most apps using OCI registries are extremely insecure. Docker, for example, will happily download malicious images. By default, it doesn't do any authenticity verifications on the payloads it downloaded. Even if you manually enable DCT, there's loads of pending issues with it.

Likewise, the macOS package manager brew has this same problem: it will happily download and install malicious code, because it doesn't use cryptography to verify the authenticity of anything that it downloads. This introduces watering hole vulnerabilities when developers use brew to install dependencies in their CI pipelines.

My solution to this? 3TOFU. And that requires me to be able to download the file (for verification) on three distinct linux VMs using curl or wget.

⚠ NOTE: 3TOFU is an approach to harm reduction.

It is not wise to download and run binaries or code whose authenticity you cannot verify using a cryptographic signature from a key stored offline. However, sometimes we cannot avoid it. If you're going to proceed with running untrusted code, then following a 3TOFU procedure may reduce your risk, but it's better to avoid running unauthenticated code if at all possible.

Registry (ab)use

Container registries were created in 2013 to provide a clever & complex solution to a problem: how to package and serve multiple versions of simplified sources to various consumers spanning multiple operating systems and architectures -- while also packaging them into small, discrete "layers".

However, if your project is just serving simple files, then the only thing gained by uploading them to a complex system like a container registry is headaches. Why do developers do this?

In the case of brew, their free hosing provider (JFrog's Bintray) shutdown in 2021. Brew was already hosting their code on GitHub, so I guess someone looked at "GitHub Packages" and figured it was a good (read: free) replacement.

Many developers using Container Registries don't need the complexity, but -- well -- they're just using it as a free place for their FOSS project to store some files, man.

What's the best way to monitor and log which processes are responsible for high system load throughout the day? Tools like top and htop only provide immediate values, but I'm looking for a solution that offers historical data to identify the main culprits over time.

@sysadmin

#sysadmin #linux #server

Discussion question: Are we to centralized? (I know Lemmy isn't unbiased)