turn that monitor off and save power?
turn that monitor off and save power?
Not saying this is impossible, you just need to have these questions in mind, and the answers written down before you start charging people for the service, and have the support infrastructure ready.
Or you can just provide the service for free, best-effort without guarantees.
I do both (free services for a few friends, paid by customers at $work, small team). Most of the time it’s smooth riding but it needs preparation (and more than 1 guy to handle emergencies - vacations, bus factor and all that).
For the git service I can recommend gitea + gitea-actions (I run the runners in podman). Gitlab has more features but it can be overwhelming if you don’t need them, and it requires more resources.
I use RSS feeds, bump version numbers when a new release is out, git commit/push and the CI does the rest (or I’ll run the ansible playbook manually).
I do check the release notes for breaking changes, and sometimes hold back updates for some time (days/weeks) when the release affects a “critical” feature, or when config tweaks are needed, and/or run these against a testing/staging environment first.
Debian
Right, I just spent 10 minutes looking for documentation that doesn’t involve shitty expensive SaaS/PaaS, couldn’t find anything. That disqualifies it for me as well, sorry for wasting your time.
I’ll keep watching this thread, relevant to my interests as well. At work we let ansible (in pull mode) handle the Linux fleet, Android we don’t have enough devices to bother, and are looking towards jamf for macs. But I’d love to find a FOSS solution too, our requirements are simple enough (as you said install/remove stuff, change basic settings)
My prod and testing environments are 2 libvirt VMs on the same hypervisor. They run the same services, deployed and managed by ansible. The testing VM just gets less disk/CPU/RAM resources, and is powered off most of the time. Simple config changes? Straight to prod. New feature, risky change? Testing first.
Ionos works for me. I’ve used OVH, Scaleway as well, no problems.
https://fleetdm.com/ doesn’t look bad, would this work?
upgrades:
vulnerabilities:
Follow the official documentation, nothing else comes close.
I have automated this process in my nextcloud ansible role
imfile
module), all syslogsfrom all server to a central rsyslog server (over TCP/SSL, example here). Use lnav
or something similar to consume the logssecurity
with containers, software maintainers also need to keep their image up-to-date with latest security fixes (most of them don’t) - whereas these are usually handled by unattended-upgrades or similar in a VM. Then put out a new release and expect users to upgrade ASAP. Or rebuild and encourage redeploying the latest
image every day or so, which is bad for other reasons (no warning for breaking changes, the software must be tested thoroughly after every commit to master
).
In short this adds the burden of proper OS/image maintenance for developers, something usually handled by distro maintainers.
trivy is helpful in assessing the maintenance/vulnerability level of OCI images.
Please not these posts again
This thread is pinned for a reason: https://lemmy.world/post/60585
You just have to find the channel_id buried in the page source
I use this Firefox addon for that: https://addons.mozilla.org/en-US/firefox/addon/youtube-rss-finder/ - really useful
Nice! I suggest adding a link to in in the README
I think any kind of graphical application should have at least one screenshot linked in documentation/README
If you needs are simple, write a simple playbook using the proxmox ansible module https://docs.ansible.com/ansible/latest/collections/community/general/proxmox_kvm_module.html
Terraform/Opentofu provides more advanced stuff but then you have to worry about persistent state storage, the clunky DSL… used it when acsolutely needed, you can do 90% of this stuff with the proxmox ansible module.
If you need to make your playbook less verbose, move the logic to a role so that you can configure your VMs from a few lines in the playbook/host_vars. Mine looks like this (it’s for libvirt and not proxmox, but the logic is the same)
# playbook.yml - hosts: hypervisor.example.org roles: - libvirt # host_vars/hypervisor.example.org.yml libvirt_vms: - name: vm1.example.org xml_file: "{{ playbook_dir }}/data/libvirt/vm1.example.org.xml" state: running autostart: yes - name: vm2.example.org xml_file: "{{ playbook_dir }}/data/libvirt/vm2.example.org.xml" autostart: no - name: vm3.example.org xml_file: "{{ playbook_dir }}/data/libvirt/vm3.example.org.xml" autostart: no - name: vm4.example.org xml_file: "{{ playbook_dir }}/data/libvirt/vm4.example.org.xml" autostart: no disk_size: 100G