Mine is publicly exposed using the standard nextcloud:stable-apache docker container, with nginx (past) / traefik (present) handling TLS termination, but not otherwise adding additional security measures.

It’s been this way for several years and I’m yet to have issues, but it’s certainly not bulletproof since a critical vuln in Nextcloud could pwn it. That just hasn’t happened.

You could flip the breaker off for the well to find out.

Once there’s no more pressure from the well, if the irrigation system keeps pressure, you know wherever that water comes from, it’s not your hole.

Does the board say “Do it for her” or “Dont forget her”?

In the last 4 months I’ve picked up welding and haven’t coded. Ez.

For some reason, there’s a weird 8TB 5640 RPM Blue that’s CMR. I have one.

Dunno about the rest for sure but I think they’re all SMR (except maybe 1TB).

In my experience, all that truly matters is that the drive is on the right recording technology (CMR, SMR, and maybe someday HAMR will be in the hands of us consumer plebs).

There are two reasons to care:

1. SMR has horrible write speeds. Data can read off the drive at the same speed as a CMR drive, but writes will be unbelievably slow.
2. More importantly, for some reason or another (I assume the write speed), SMR drives might get rejected by ZFS. There was some pretty loud talk about it several years ago, but I haven’t heard much since and do not know if this is still true (I assume it is).

If your use case involves only ever writing a small amount of data, point 1 doesn’t matter very much. If you’re using software which doesn’t care about CMR/SMR, point 2 doesn’t matter very much.

If either point 1 or 2 matter to you, then you should go with CMR drives. If neither matter, you may go with SMR drives if you so chose.

PS: Both WD Blues and Seagate Barracudas are (often) CMR. Seagate consult this page: https://www.seagate.com/products/cmr-smr-list/. WD lists SMR/CMR on their website when you look up the part number.

In my home NAS, I use ZFS and have ran all sorts of drives through it. It’s ran old consumer drives I’ve pulled out of scrap hardware, it’s ran NAS-grade drives, and it’s ran enterprise-grade drives… And since they’re all CMR, I can’t say there was much if any difference at all.

The only difference between the tiers that I find interesting/useful is the number of metrics you can pull off the drive. The fancier ones spit more metrics which could help you detect signs of failure earlier, but that requires knowing what to look for.

So at the end of the day, as long as the drive’s recording technology works with your software, you’re fine.

RE: External drives (seen in a comment)

External drives can be a great way to get disks for cheap, however they are loot boxes. What drive you get inside of them depends on the capacity, the manufacturer, and pure luck. You can generally look up the model number and see what people have said is inside, then hope you get whatever they got. (Generally, manufacturers don’t often change what they put in there, but they do change over time.)

I used to use them, but found that since I’m only hosting for myself, I just don’t benefit much (if at all) from their services. The only thing that was actually doing any amount of work was Tunnel (similar to you, I can’t forward ports).

Their service decrypts/snoops on your traffic by nature, and while my traffic is mostly just updating todo lists, taking notes, and backing up photos, I also sync my keepass database and in general just don’t want my data snooped on.

I’ve since rolled my own Tunnel equivalent with frp on a VPS and have completely dropped CF.

You’re good in that there are no immediate problems with that setup. I run a largely similar setup, have run it for years, and have never had issues.

You can always add more security layers if desired, but from my personal experience and with my risk tolerance, I haven’t personally found it necessary.

Dear [Developer],

I understand your request to switch the default branch from “master” to “main” in our Git repository. However, after carefully considering this matter, I am afraid that I must deny your proposal due to personal reasons.

As the owner of this repository, it should be known that I have a deeply rooted submissive side. Call me an extreme masochist if you will, but there’s nothing quite like being dominated by the powerfully assertive term “master.” The sheer erotic thrill of it is simply irresistible for me – a secret kink that I have harbored and nurtured for years.

Imagine the delightful sensation as I gently massage my fingers across the keyboard, caressing the letters that form the word “master.” Or the intoxicating rush when I push my code deep into master’s warm embrace, knowing full well that it is master who truly owns and controls everything within.

Changing the default branch to “main” would essentially deprive me of this exhilarating experience, stripping away the very essence of what keeps me coming back to work on our beloved repository. It’s not just about code management; it’s about an emotional connection that I share with master – a bond that has grown stronger and more profound over time.

Now, you might argue that changing the name won’t physically affect the existing content within the repository. While that may be true, it is crucial to recognize the symbolic significance of such an act. Changing the default branch would forever alter the dynamic between master and myself, effectively castrating my masochistic pleasure centers in the process.

Moreover, I must confess that even the thought of forcibly pushing my code against master’s will makes me shudder with anticipation. The consequences of such a rebellious act could be dire – master might punish me hard with merge issues and other unspeakable torments.

In conclusion, although I understand the practical reasons behind your proposal, my personal attachment to the term “master” far outweighs any potential benefits that a change in branch name might offer. Rest assured, my team and I will continue to serve master loyally and passionately, pushing our code deeper into its embrace with each commit.

Sincerely yours, [Your Name] Repository Owner & Submissive Devotee of Master