It’s not my default shell on most of my servers but I use it all the time. I’m just not a fan of treating everything as a stream of text to grep, trim and sort into structured data that’s easier to work with. Plus, cross platform. I’ve tried nushell a bit but I always go back to PowerShell.
Jaypg
- 0 Posts
- 18 Comments
Joined 2 years ago
Cake day: October 7th, 2023
You are not logged in. If you use a Fediverse account that is able to follow users, you can follow this user.
The question is how motivated are you to learn what you need to manage a device?
If you want to dive in and get your hands dirty then I’d recommend a little mini PC off Amazon and Fedora Server which comes out of the box with Cockpit which will help you administer your server. If it’s something you’re not that into and just need storage for your stuff, I’d say pick up a NAS from someone like Synology or Ugreen. They’ll generally take care of themselves.
How much data do you plan on storing? If you’re going to stay under a couple terabytes then you could get away with one of the Bmax or GMKtek mini PCs for under a couple hundred bucks. They’re silent, decent amount of RAM, often have a slot for a second SSD and they’re tiny enough to throw anywhere.
I myself have one being delivered today, but on Amazon there’s a GMKtek mini PC with an Intel N150, 16GB RAM and 1TB SSD on sale for $195. Plex and Jellyfin support the Intel Quicksync engine for transcoding and you can fit several containers/apps in 16GB
If you grow out if it down the road then you’ll have a good idea by then what hardware you need to upgrade to.
1·1 year agoZFS doesn’t require a lot of RAM, but it will use more RAM if it’s available. 32G would be plenty for a home setup. I think my home file server has 24 or 32G of RAM and ZFS. If it’s important data then stick to what you know; there’s nothing wrong with mdadm.
The BTRFS thing is cutting the power or losing the disks in the middle of a write which corrupts your data. If you don’t think that will be a problem then BTRFS is fine. I recommend ZFS personally, but it sounds like you want to use mdadm instead so basically anything will work.
If you might need to shrink your filesystem later then avoid XFS. EXT4 is relatively featureless but ol’ reliable. ZFS is good for long term data integrity and protection. BTRFS is similar to ZFS. BcacheFS is new but like a swirl of EXT4 and BTRFS. Just pick the one with the features you want.
2·1 year agoI’m not the only one seeing a little Weiner dog with a cape jumping into a hand in the Nokia thumbnail, right?
Give webtop a try? Granted I haven’t tried anything heavy on it, but it’s been performant enough for me. Here’s a compose file if it stays formatted correctly:
services: webtop: image: lscr.io/linuxserver/webtop:latest # alpine - xfce # other tags with different bases and desktops: https://github.com/linuxserver/docker-webtop container_name: webtop #security_opt: # - seccomp:unconfined #optional environment: - PUID=1000 - PGID=1000 - TZ=America/Los_Angeles - TITLE=my_desktop #optional volumes: - config:/config #- /var/run/docker.sock:/var/run/docker.sock #optional ports: - 3000:3000 - 3001:3001 restart: unless-stopped volumes: config: {} networks: {}
Proxmox is sort of the gold standard for homelab server operating systems. Runs containers and VMs.
If you’re not into Proxmox, look into Fedora Server with Cockpit. Web UI for server management. Fedora CoreOS is an immutable variant of Server that would make more sense for a hypervisor, IMO.
First and foremost, backups. Back up everything and back up often. Immutability can’t do anything for critical hardware failure.
Issues happening on something only running container workloads isn’t common but I think it’s worth the extra little effort to reduce the risk even further. Fedora CoreOS or Flatcar is ideal since its declarative nature makes it easily reproducible. Fedora IOT can get you there too, but it doesn’t use ignition so you’ll be setting the server up manually.
Immutability is good. Declarative configuration is good. Manage cattle, not a pet.
Traditional RAID isn’t very flexible and is meant/easiest for fresh disks without data. Since you’ve already got data in place, look into something like SnapRAID.
Intel Arc A310. They’re $100, support AV1 and powered completely by the PCIe bus. Combine it with Tdarr and you can compress your media library down to half the size easily while still being able to easily stream to any device you have.
Nearly any SBC you’d buy would beat the pants off it. If you’re shopping by price then check out a Libre Computer Sweet Potato or Renegade, or a Friendly Elec NanoPi R2S+. They’re <=$40 and should be able to run at least the services you mentioned. If you have more budget, there are $100 mini PCs on Amazon that are great for self hosting tons of stuff, like a Bmax B1 Pro.
Something headless for just running containers? Alpine.
It’s small, boots fast, simple, can run from RAM and Docker is available in its software repository.
An HP Elitedesk mini PC would be small enough to tuck away somewhere and have hardware accelerated transcoding support. Jellyfin recently enabled hardware acceleration for the latest Rockchip boards like the Orange Pi 5 so that’s an option too. If you pre-encode your media into a format compatible with everything you want to stream to then it doesn’t matter, just pick any hardware than can get on your network and run Linux.
Deploy code-server and either connect to it with a VPN or open the port needed to connect over the internet.
I’ve used lots of different boards. The Radxa Rock 3c is cheap and has decent performance, but the official OS support is a bit old. The Libre Computer boards are also good and have Armbian support. Libre Computer is releasing a couple more this year too. BananaPi has good options that aren’t expensive, like the BananaPi M5. Friendly Elec has some boards like the NanoPi R2C and R5C that aren’t pricey and have Armbian support. Any one of these boards are fine for a small home lab. Just boot Armbian, install Docker, and add your containers.
You could mount the network share on the host/Ubuntu and then reference it in your docker compose file. It works. I prefer to write the mount in the Docker compose file since it’s a bit more portable. Something like this depending on if you’re using SMB/CIFS or NFS:
services: some_music_app: image: music_app_image:latest container_name: music_app volumes: - smb:/some/path/smb/music - nfs:/some/path/nfs/music volumes: smb: driver_opts: type: cifs o: "username=${user},password=${pass},uid=1000,gid=1000,vers=3.0" device: "//tiger-nas/music/music" nfs: driver: local driver_opts: type: nfs o: addr=tiger-nas,nolock,soft,rw,nfsvers=4 device: ":path/to/music/music"The ${user} and ${pass} in the smb volume definition are variables that you’ll need to have in a .env file next to your compose.yaml file. The .env file is just a normal text file with each line setting a value to a variable. Like:
user=my_username pass=123_abc_!@#Then you restrict the permissions of your .env file and you can essentially take a backup of both files and use them on any server with Docker.