Random Thoughts

This is the continuing story of me trying to watch some movies…

So here’s my setup: I have two RAID machines.

The old one has two fanless 4x disk cabinets. It was perfect — I’ve used it for half a decade, but the RAID card died, and the BIOS on the new card doesn’t allow me to spin down the disks, which started this journey.

The new RAID machine is more traditional — it has fans and stuff, but doesn’t make that much noise. Especially since I’m going to place it in the home office, so I don’t have to listen to it.

The new one is a mirror of the old one. I’m using the RAID to store movies I rip from Blurays/DVDs I buy, and I watch the movies from there.

Given that more than 95% of the time I’m not watching movies, I really prefer to spin down the disks and let them rest. Presumably they’ll last longer that way. (Indeed, the ones in the old RAID setup have survived more than half a decade without a hitch.)

So I can play movies from either of these machines, and the other one can be semi-permanently off (unless I’m running a backup). Get the setup?

OK.

But which one to use for watching movies? And how to spin things down?

Well, on the old machine, there’s only one option now: Suspend the entire machine, and use Wake-on-LAN. (Side note — I love the Archlinux wiki — it has such detailed information on all Linuxey things I’m wondering about. And I don’t even use Arch.)

The old machine has an LSI card, and it’s so enterprisey that it takes five minutes to boot. Which makes experimenting with the machine a bit tiresome.

Especially since I had to get into the BIOS several times to experiment with things, but it turns out that if you set “PCIE Devices Power On” to “Enabled”, then Wake-on-LAN works.

That is, if I send a Wake-on-LAN package to it, it switches the screen on immediately and answers ping. But it takes about two and a half minutes for userland to wake up, and the machine to be usable.

Do I want to wait two and a half minutes before watching a movie? Hm.

OK, let’s look at the new RAID machine. On that one, I could theoretically just spin the disks down, and then accessing via NFS would wake them up, and I wouldn’t have to do any explicit waking.

But the machine has fans, and that’s not optimal.

And the fans can’t be spun down manually.

So let’s try to suspend (S3) the machine… and that works fine. Except for this:

The fans keep going. And waking up from suspend takes 30 seconds before userland is available. (It seems to spend this time spinning up the disks.)

30 seconds isn’t bad, but the fans…?

And there doesn’t seem to be anything in the BIOS of this X13SCL-IF motherboard to control the fans, as far as I can tell.

So what about hibernate? If I hibernate instead of suspending the machine, then the fans stop after a couple minutes. But it uses 2 minutes to wake up from hibernation, because it basically has to do a full boot (and Supermicro motherboard are really, really slow to boot).

*sigh*

To sum up:

• Old RAID suspend: 150 seconds.
• New RAID suspend: 30 seconds, but fans run continuously.
• New RAID hibernate: 120 seconds.

There really doesn’t seem to be any perfect solution here. Well, I had the perfect solution, but that stopped working and there seems to be no way to get that back.

Hardware sure is frustrating.

But considering I did have the perfect solution (i.e., disks spin down automatically, and I don’t have to futz with wake-on-LAN, and there’s no fans), can I recreate that with a new RAID/SATA card, perhaps?

A modern SAS card (for eight disks) uses Mini SAS SFF-8644 connectors. My disk cabinets don’t:

That connector is an SFF-8470, which is also called Infiniband/SAS. There are SFF-8644 to SFF-8470 cables, but this is the only one I could find:

And it’s no longer being produced.

Amazon lists the same cable — must be from the same producer going by the image — and says “usually ships within 6 to 7 months”. So I don’t think this actually exists (any more).

So… could I just swap out the backplate on the RAID cabinet to a SFF-8644 backplate? (Are those things called “backplates”?) Like…

But how would I mount this? Use a Dremel on the thing to get it to fit? Hm.

As far as I can tell, these various Mini SAS connectors are all electrically compatible — it’s just a form factor issue? (I’m not at all sure, though.)

The cable I have today looks like this:

Does an adapter from Mini SAS SFF-8088 (that’s the one on the right) to SFF-8644 exist?

Yes!!

But… I’d need two of those since there are two cables, and there’s only room for one of those?

OK, they don’t actually need to be installed anywhere, I guess, but just letting them bop around would be kinda sloppy…. er…

Oh oh oh! I’m thinking extra super stupidly here. I don’t need an external Mini SATA card if I’m going to use the SFF-8088 cable anyway — I need an internal Mini SATA card (which I already bought while testing stuff out on the new RAID machine) and then a converter. Does that exist?

YES!!!!

So I just need two of those and everything should, like, work! And there’s room for that in the old machine.

And this is cheap, too — these two gadgets are the only things I have to buy to test this out.

*orders gadgets*

So now I just have to wait for Genuine Modules to deliver… *drums fingers*

Oh, I should have gotten this instead — but I guess it doesn’t really matter.

[To be continued.]

[Update two days later:]

After waking the old RAID system from sleep after two days, I got this:

2025-08-13T17:02:10.165445+02:00 big-tex kernel: EXT4-fs error (device md0): __ext4_find_entry:1639: inode #2: comm nfsd: reading directory lblock 0
2025-08-13T17:02:10.169424+02:00 big-tex kernel: Buffer I/O error on dev md0, logical block 0, lost sync page write
2025-08-13T17:02:10.169440+02:00 big-tex kernel: EXT4-fs (md0): I/O error while writing superblock

It fixed itself after a couple reboots, but I guess that RAID card (or disk cabinet) doesn’t like sleeping for a long time.

I mean, that’s just common sense, so why even mention it?

Because of ?p=, which I think most people who use WordPress aren’t aware of. This mechanism allows anyone to trivially download any media files you upload to WordPress, even without knowing the names of the files.

To backtrack a bit before going into the details of this problem (or “problem”): Yes, yes, you should never upload something secret to the Internet. And especially not to a place that’s publicly downloadable. But we all do it, right? When we want to send a big file to somebody (especially a (small) group of people), we just bang it on a web server somewhere and then send the URL to the people concerned. This is “safe-ish”, because nobody else knows the URL, right? And besides, we’re going to delete the file after a while anyway. Except when we forget.

Personally, I do this all the time with stuff — I mean, funny screenshots, jokes, pics — I bang them onto my WordPress and then share the URL in limited venues (irc, mail, whatever). Of course, nothing here is “secret” secret, but on the other hand, in these days when giving a milquetoast opinion like “I think killing children is bad” can get you landed on a terrorist list, you may prefer to be a bit more careful with this sort of thing.

So here’s the problem: Say I took a pic of my bookcase and put it on https://lars.ingebrigtsen.no/wp-content/uploads/2017/09/p1340399.jpg, and then mailed somebody the URL, and they were mildly impressed and then forgot about it. Nobody else will ever see it. But did you know that you can access (most) WordPress media items via URLs like https://lars.ingebrigtsen.no/?p=43041? No?

If a nefarious institution is interested in getting info on the general WordPress populace (*cough* Palantir *cough*), then can just loop through all those ?p= (on all WordPress sites in the world) starting from zero and going up to however many things that’s been put into the media library — unedited versions of images or videos, for instance.

Now, if somebody were to target you especially, there are, of course, other methods:

Because media file names have a tendency to be pretty regular, so you can just try a lot of https://lars.ingebrigtsen.no/wp-content/uploads/2025/07/DSC02869.jpg etc, and you’ll probably find something. But a targeted thing like this is impractical for most things — a general ?p= could be part of a general “sentiment” analysis that I bet sounds very attractive to some organisations.

But the ?p= thing is, of course, also super useful if you’re doing a targeted sploit — you can find (for instance) all PDFs an org has uploaded to their WordPress (along with all the cat pictures) without much work. The fun thing about ?p= is that you just loop through the numbers sequentially, and then you get everything, no matter what the media type is.

As far as I can tell, there’s no way to disable the ?p= thing without breaking other functionality:

After digging around in the WordPress source code, this seems to be the relevant code. Following the code afterwards, there doesn’t seem to be any way to mark a media item as “unavailable” — the closest you can get is to attach the item to an unpublished post, and then the ?p= will lead you to a 404 page instead of the image. If you have the direct URL to the item, you can always see it, as far as I can tell, but then we’re over in “find out the URL” land again, which isn’t as interesting.

So what I’ve done is to write a snippet for ewp to find all unattached files, and then include them all in a draft post, thereby making ?p= stop working for them. If this sounds really clumsy and awkward to you, then you’re totally right.

What I wish WordPress would do is to 1) make the ?p= an option — especially for unlinked media items — and 2) default it to “don’t do that” for all installations. And then the few people who want this surprising behaviour can switch it on.

This is more important now than ever, when there are vast resources that can ingest all this “hidden” data and process it in an efficient manner (using AI or not) — and especially since WordPress apparently powers a sizeable portion of the Internet.

If you want to disable this manually, something like the following seems to work:

function custom_is_post_type_viewable( $is_viewable, $post_type ) {
  if ($post_type->name === 'attachment' &&
      (! empty( @$_GET['page_id'] || ! empty( @$_GET['p']))))
    return false;
  return $is_viewable;
}
add_filter( 'is_post_type_viewable', 'custom_is_post_type_viewable', 10, 2 );

It’s pretty gross, though — it basically adds a filter to the very general function that says whether a post type is viewable, and tests there whether we’re trying to view an attachment, and whether a ?p= is present (or ?page_id=, which is the same thing).

This disables ?p= for all attachments, not just the non-published ones, so it’s really not quite what one wants.