• 0 Posts
  • 39 Comments
Joined 2 years ago
cake
Cake day: June 23rd, 2023

help-circle




  • With this concept in mind, I recently put together a VDI setup for a person who’s in one location for half of the year and another the other half. The idea is he’ll have a thin client at each location and connect to the same session wherever he is.

    I’m doing this via a VM on Proxmox and SPICE. Maybe there’s some idea in there you could use.




  • Take this with a grain of salt, the more I re-read, the more I realize I’m making assumptions about your setup that may or may not be true. First, I’m making an assumption that you’re doing ACLs for samba shares (and I know that system better on FreeBSD than Linux). I’m also assuming based on your description you want everyone to have access, but not write access.

    I think you could do an officewide group with read-only permissions on all of the shares and then set the unix group to the department.

    So, for your HR team you’d do chgrp -R hr /path/to/parent/shares/hr and setfacl -m d:g:rwx /path/to/parent/shares/hr and add the officewide group’s read-only perms: setfacl -m d:g:officewide:rx /path/to/parent/shares/hr. Rinse and repeat for each share.

    Not sure if this is what you’re after, but maybe it’ll help lead in a good direction.





  • In general, I prefer unprivileged LXC to a full VM unless there’s some specific requirement that countermands that preference (like running an appliance or a non-Linux OS).

    What I tend to do is create a new container for each service (unless there’s a related stack). If the service runs on Docker, I’ll install that right inside the container and manage it with docker compose. By installing Docker directly from get.docker.com instead of the built in packages, it pretty much works all the time.

    Since each service is in its own container, restoring backups is pretty service-specific. If you wanted some kind of central control plane for docker, you could check out swarm mode.





  • tvcvt@lemmy.mltoLinux@lemmy.mlLinux on iMac?
    link
    fedilink
    arrow-up
    1
    ·
    6 months ago

    Linux runs fine on Intel Macs. There are a couple peculiarities you’ll want to be aware of, though.

    • Ventoy doesn’t work as an installer. The boot menu will come up, but any ISO you choose will hang
    • Not all distros will recognize the wireless card and install the firmware (Be prepared to install it using a USB to Ethernet adapter)
    • Same goes for the iSight web cam

    Other than those initial hiccups, everything works pretty flawlessly.




  • I’m making some assumptions, namely that you’re using an unprivileged LXC container and the mount point is a bind mount.

    Unprivileged LXC shift user ID numbers so that an escape won’t result in root access to the host. The root user (uid 0) in the container is actually uid 100000 from the perspective of the Proxmox host.

    What I usually do is set ownership of my bind mounts to that high-numbered ID (so something like chown -R 100000:100000 /path/to/bind/mount) from Proxmox. Then the root user in the container will be able to set whatever permissions you need directly.


  • Since you’re interested in this kind of DIY, approach, I’d seriously consider thinking the whole process through and writing a simple script for this that runs from your desktop. That will make it trivial to do an automatic backup whenever you’re active on the network.

    Instead of cron, look into systemd timers and you can fire off your script after, say, one minute of being on your desktop, using a monotonic timer like OnUnitActiveSec=60.

    Thinking through the script in pseudo code, it could look something like:

    rsync -avzh $server_source $desktop_destination || curl -d "Backup failed" ntfy.sh/mytopic

    This would pull the back from your server to your desktop and, if the backup failed, use a service such as ntfy.sh to notify you of the problem.

    I think that would pretty much take care of all of your requirements and if you ever decided to switch systems (like using zfs send/recv instead of rsync), it would be a matter of just altering that one script.