Accomplished-Lack721

joined 1 year ago
[–] [email protected] 1 points 11 months ago

It started well ahead of actual BF, but Best Buy has 18TB Easystore drives for $200.

[–] [email protected] 1 points 11 months ago

It would be nice if we, and apps' developers, always knew what the vulnerabilities are. They generally exist because the developer doesn't know about them yet, or hasn't found a solution yet (though ideally has been transparent about that). Zero-day exploits happen. There's always a first person or group discovering a flaw.

If being up to date and using SSL was all it took, security would be a lot simpler.

No one security measure is ever foolproof, other than taking everything offline. But multiple used in tandem make it somewhere between inconveniently and impractically difficult to breach a system.

[–] [email protected] 1 points 11 months ago (2 children)

It's not. SSL in itself doesn't make any exposed service safe, just safer. An updated service isn't necessarilu free of vulnerabilities.

The difference between exposing your login page and most other services is the attack surface. If someone gets into your NAS administration, game over. You're getting hit with ransomware or worse.

If someone gets into my Calibre Web server, for instance, my vulnerability is much more limited. That runs in a docker container that only has access to the resources and folders is absolutely needs. The paths to doing harm to anything besides my ebook library are limited.

I of course still use SSL, with my Calibre Wev behind a reverse proxy, with long complex passwords, and I'll probably soon move it to an OATH login where I can use MFA (since it doesn't support it natively itself). And there are more measures I could take beyond that, if I chose.

[–] [email protected] 1 points 11 months ago (5 children)

The login page to your NAS.

[–] [email protected] 1 points 11 months ago

Only expose applications to the Internet if you have a good need to. Otherwise, use a VPN to access your home network and get to your applications that way.

If you are exposing them to the internet, take precautions. Use a reverse proxy. Use 2FA if the app supports it. Always use good, long passwords. Login as a limited user whenever possible, and disable admin users for services whenever possible. Consider an alternative solution for authentication, like Authentik. Consider using Fail2ban or Crowdsec to help mitigate the risks of brute force attacks or attacks by known bad actors. Consider the use of Cloudflare tunnels (there are plusses and minuses) to help mitigate the risk of DDOS attacks or to implement other security enhancements that can sit in front of the service.

What might be a good reason for exposing an application to the Internet? Perhaps you want to make it available to multiple people who you don't expect to all install VPN clients. Perhaps you want to use it from devices where you can't install one yourself, like a work desktop. This is why my Nextcloud and Calibre Web installs, plus an instance of Immich I'm test-driving, are reachable online.

But if the application only needs to be accessed by you, with devices you control, use a VPN. There are a number of ways to do this. I run a Wireguard server directly on my router, and it only took a few clicks to enable and configure in tandem with the router company's DDNS service. Tailscale makes VPN setup very easy with minimal setup as well. My NAS administration has no reason to be accessible over the internet. Neither does my Portainer instance. Or any device on my network I might want to SSH into. For all of that, I connect with the VPN first, and then connect to the service.

[–] [email protected] 1 points 11 months ago

I've been playing with Joplin. The one thing I can't decide if I like -- there's no web interface. You have to be using the app (versions are available for Mac, Windows, Linux and mobile devices).

There's also Notes in Nextcloud.

[–] [email protected] 2 points 11 months ago

If you're happy with those services ... maybe you shouldn't?

I self-host because I prefer to house my data locally when possible. It's easier for backups and I'm not subject to the whims and financial decisions made by a company about whether their service will remain available, what it will cost, what functions it will offer. The tradeoff is work on my part, but I enjoy tinkering and learning.

In my case, I self-host a NextCloud instance for remote access to my docs, a Calibre Web server for eBooks (and to share those with a few trusted friends), a Vaultwarden instance because I'd prefer my vaults not be stored by a company whose servers are likely a major target for bad actors and that could change its TOS or offerings in the future.

[–] [email protected] 1 points 1 year ago

I installed it because I was curious, and still learning some things about Docker.

I pretty quickly used it to install portrainer, and I've since managed everything from there.

The file manager is moderately handy, but nothing I couldn't do either with the command line or another filemanager tool I'd install through Docker itself.

I still have it set up because I have no need to change it, but I wouldn't use it if I were doing my setup from scratch.

I'm kind of curious about Cosmos as what seems like a more comprehensive alternative, but I'm pretty happy with how I have some of its other functions (like reverse proxy) set up now, so if I try it, it'll probably just be to tinker.

[–] [email protected] 1 points 1 year ago

Thanks for the heads up on this project. It looks like it might work very well for some people who basically want a web app as a view right into a filestystem for dealing with folders.

Unfortunately, it doesn't really meet the needs I'm laying out. The use case I'm describing is still one where the web app abstracts away the file system and uses albums. It just lays out a (smart, I think) way of recognizing and interpreting the organization in a pre-existing library, like one created from a Google Photos takeout, when bringing photos into its own system -- accounting for duplicates in albums without doubling them up on disks.

Direct editing of EXIF is handy. Memories does that too, and it's part of why it's what I'm using. But my ideal situation would be one where the app only writes metadata changes to its own database initially, but then (optionally) applies it to EXIF when exporting/downloading files without touching the original files. And it would also give the user an option to apply metadata to EXIF for the original files, but only after first prompting with warnings.

It seems your design goals are pretty different than any of that -- which isn't a criticism, as I'm sure it works well for the way a lot of people like to work (just not me).

[–] [email protected] 1 points 1 year ago (1 children)

Syncthing would work well for just syncing.

So would Seafile, for a more Google Drive-like experience.

So would NextCloud, for more of an extensible Google Drive+Apps experience that you can customize to your needs.

 

Like a lot of people on this sub, I've migrated away from using Google Docs and Photos (most of the time) in favor of self-hosted services. For photo use, I'm really impressed by everything that's gone in to Immich, Photoprism and Memories, with the latter coming the closest to my preferred way for such an app to work.

But I still find some difficulty with the workflow and design philosophy with of these apps when it comes to two things.

  1. Working with large existing libraries, like one exported from Google Photos using takeout, while maintaining the organization of the original library.

  2. Updating metadata.

On point 1 -- I've got a few hangups about this. The biggest is how duplicates are handled. For instance, let's say in Google Photos, you had your favorite photo from your 30th birthday both in an album called "2009 favorites" and another "30th birthday pics." When (for instance) Photoprism is scanning those photos for its library, it'll import the first one it finds, and ignore the second, without any indication in the UI that happened (but it will be in the logs). Then, later, when you go looking in the "30th birthday pics" photos in Photoprism's "folders "view and it's not there, it's not clear to the user why. This is particularly confusing since the file IS in both places on the disk, and you'd think a "folders" view would represent the filesystem as-is.

Yet just ignoring the fact that you have duplicates, as Memories does, and leaving it you to manage them separately, also doesn't seem ideal.

On point 2 - Of the above, only Memories writes changes to EXIF. This is mostly great for my purposes since I keep good backups to undo any unwanted changes, but Immich and Photoprism have good reason to be cautious about messing with original files. It seems to me there's a halfway measure that would work well with both.

Here's what I'd love for file imports/organization:

  • Never try to adopt an existing file structure (like a bunch of folders from a Google Takeout) and simply use it in place. If the app is being pointed to one, use it for imports only, and copy everything over to the app's own folders/file organization.
  • Organize that new file structure however the developers like, without touching the originals.
  • During the import, offer to convert all the folders from the original file system (ie the Google Takeout folders) to albums, managed in the app's own database. If the user declines, import the photos in a flat structure without assigning them to albums.
  • During import, the app may notice a photo appearing in more than one of the original system's folders. If so, only copy it to the new file structure once, but assign it to both corresponding albums. This way, that birthday photo appears in both in the newly created "2009 favorites" and "30th birthday pics" albums without actually being in the new file structure twice.
  • If you're regarding anything other than exact file matches as duplicates, let the user see somewhere in your UI which files have been detected as duplicates and override the detection if necessary.
  • Don't expose a "folder view" to the user under normal circumstances. Optionally have it available as an advanced feature, disabled by default. The user should manage things as albums, and the app takes care of the underlying folder structure on its own, however, the developers find makes sense.

And for metadata:

  • When importing files, check for EXIF, json, xmp and any other sidecar files. In your advanced settings, have an option letting the user specify which to prioritize if the existing files have incompatible metadata in multiple places (including an option for a prompt). Import than metadata into your database.
  • When updating metadata via the app, only write those changes to the database (or, optionally, the databased and a human-readable sidecar file, like Photoprism does). Do not, by default, write it directly back into the EXIF.
  • Important: If the database's metadata is different than what's currently in the EXIF, because the user has updated it in your app, give the user an option to write it to the EXIF as a batch operation. Warn the user these changes are irreversible before proceeding. Have a flag in the UI that shows the user when the EXIF data and database data are not the same, and allow the user to filter their view by it.
  • Important: When exporting a photo from your app, if the EXIF metadata and database data aren't the same, by default write the database data to the EXIF of the exported photo. Do not change the original photo stored in the app's file structure -- only make this change to the exported version. Have an option to disable this. That way, under normal circumstances, when someone exports a photo from your app, and imports it into a photo editor or other library, it'll carry over the changes they made in your app unless otherwise specified ... without risking the original files that remain untouched for safety.
  • Optional: Provide a command-line script to interpret your human-readable sidecar files and apply them to photos' EXIF data in batches using something like EXIFtool (I wish Photoprism had this already and I'm surprised I haven't found anything generated by a user to do it).
[–] [email protected] 2 points 1 year ago

Sorry, but this sounds a bit: "I'd like to eat this piece of cake, but also still have it available to me when I'm done."

There are front-ends that can make docker apps easier to manage, like CasaOS. The tradeoff for ease of use is flexibility compared to something like Portainer or the CLI. CasaOS's app library (for instance) frequently has out-of-date versions of apps, and if their default configuration doesn't make sense for your purposes, you're still going to have it delve deeper (whether in the CasaOS UI or another tool) to customize things to your needs.

That's pretty much a given with any tool - if you don't want to deal with how it works, then you need to accept the default configuration and cross your fingers that it works for your purposes.

And you're still not going to get away from the fundamentals of how docker works, if you find them troublesome for some reason. Updating a docker app with something like CasaOS is doing the same thing it would be with Portainer or the command line. I'm not quite sure what seems "wrong" about it to you, but it would be "wrong" in the same way no matter what front end you use.

[–] [email protected] 1 points 1 year ago

It can handle almost any service you might care to self-host - and with that much RAM, several at a time. You could run multiple VMs and still have breathing room.

But a much less powerful box can also handle most self-hosted services well. If your existing Pi is doing the job, I wouldn't switch. The 9900K will consume way more power, which is bad for the environment and your wallet.

Maybe make it into a testing station. Or donate it to a nonprofit. Or sell it. Or turn it into a living room gaming station, playing light games natively and streaming AAA games from another machine with Steam Link or Moonlight (in sleep mode when it's not in use?). Or give it to a family member. Or make it available to a neighbor via Freecycle/Buy Nothing/similar gifting networks.

view more: next ›