

Is this a vibe coded npm app that’s purpose is to avoid reading and understanding your own compose files?


Is this a vibe coded npm app that’s purpose is to avoid reading and understanding your own compose files?


I saw in another comment your lsblk output and yes I see the LUKS partition spans the whole disk.
So yes, the commands you listed should be sufficient. It will extend the decrypted logical volume to use the remaining free space of your volume group.


I realize now i may have been confused as you didn’t specify everything.Is the LUKS volume created right on the disk on a raw partition?


Edit: meant this to be a comment reply, not a post reply.


You can’t resize the filesystem without first resizing the crypted volume.
You would expand this LV. Expand the crypted volume. The decrypt the volume and expand the underlying filesystem.


Does it do screen sharing distributed via the server?


Go spam elsewhere


Most likely no unless the raid controllers are identical and you aren’t using Synology’s hybrid raid stuff.


Per his description it uses Restic under the hood so for the nitty gritty on that you can just go read the very decent Restic docs.
I’m a big fan of restic and use it for all my backups.
If the router is the single point if entry at your edge then I’d run fail2ban on it assuming it can see the traffic
What made you switch to it over tailscale+headscale? Currently that’s been doing everything I need without issue.


Check out the Teamspeak6 beta. I don’t know about offline messages but it addresses all your other complaints. I moved to it from Mumble somewhat recently and have been very happy with it.


Machine wise anything will work. Give yourself a chassis with room to add more disks down the road or just build your storage setup in a way that gives you what flexibility you need (though that tends to come with sacrifices).
I use Nextcloud for general file syncing between devices as occaisonal small file sharing.
I use keepass2android and “sync” via its native WebDAV support with my nextcloud instance as the source. Been working great forever.


Ah, well, then perhaps I will monitor it.
For internal use I just monitor everything with zabbix. What Ive been wanting is (as I said) a public “status screen” that my few users can hit just to verify if things are in fact down or if it’s just them.


Ok, you might have finally gotten me to consider a “dashboard”. I’ve been wanting a simple public facing service status page and this sounds like a nice solution.
Haha, I’ve never had to deal with something quite that high pressure but I’ve definitely been a little looser than standard during at least a couple emergencies.
Kernel upgrade WHILE you’re out for beers!
Someone just posted their own short reviews of a slew of wiki options in this community so maybe go take a peek at that.
Personally I’m finding I like Otterwiki quite a lot though I’ve not yet dug deep into it.
It is in fact the wrong place.