cloud-init FreeBSD-14.1BASIC-CLOUDINIT-ufs.qcow2.xz

V

vesuvienne

Hi team! happy to be here :)
Have some question, i have downloaded this image: FreeBSD-14.1-RELEASE-amd64-BASIC-CLOUDINIT-ufs.qcow2.xz (i'm on proxmox building a freebsd VM)
this image come with:
* A default user freebsd -> can i remove it ? (rmuser freebsd)
* No root password -> is it normal? should i create a password ? (passwd)
* I need to install pkg install -y py39-cloud-init-24.1.4 if not cloud-init doesn't work, is i normal ?
thx!
 
That's not an official image. I'd by *highly* cautious with that...

Regarding cloud-init: Yes, there are some python scripts available, which drag in a lot of bloat like python, sudo and avahi, that's why I never used cloud-init for any of my cloud instances at digitalocean/vultr or even smartOS, but built my own shellscripts for that. Cloud-init is basically nothing but a primitive REST-API - no idea why one would want to drag in tons of dependencies just to poll some URIs, which can be easily done with pure, dependency-free shellscripts.

There are many such solutions on github; I took most of the ideas from there for my own scripts and always wanted to make them "feature complete" (as far as I regarded the features desirable) and somewhat clean, but due to the fact that I completely switched to jailhosts and automated deployment of jails instead of small VMs, I lost interest in cloud-init. Hence those scripts haven't been updated since 2019 and the initial setup for a "master-image" was a bit tedious with lots of manual steps (back then I couldn't figure out how to make a proper buildscript that doesn't blow up every now and then...) and documentation in them is rather scarce, so I think that mess will be more confusing than helpful...
But basically all you want to do is poll some URIs at boot, do some sanity-checking and then either put those values in the appropriate files (or check they are already there/set) or trigger some commands with those values as arguments.
As a bonus, trigger a system upgrade at first boot, install a basic set of packages and pull some custom configs from a git repo or do/trigger other things with values handed over via "customer_data"/"vendordata"...
Thanks to libxo and its toolset, you won't even have to deal with json 'by hand' anymore in such scripts.

TL;DR: depending on how often you want to deploy VMs, just use a regular (official!) image, build your own "base-image" from that and maybe script something for the network configuration - or just do the initial config from the host via a serial console into the running VM (no idea if proxmox/KVM has such a thing or only a full-blown graphical console...)
 
_martin said:
It is official image hosted on freebsd.org web page: http://ftp.freebsd.org/pub/FreeBSD/releases//VM-IMAGES/14.1-RELEASE/amd64/Latest/.

I don't use cloud-init on FreeBSD but yes, clients need to have cloud-init installed. You can do whatever you want to that image including what you specified.
Click to expand...

thanks for that hint. I only looked at the path for installer images, not the VMs. Very sorry for that, I'll put on the hat of shame for the rest of the day.
(and I even remembered that there was some talk about officially supporting cloud-init a while ago...)
 
Luckily day is getting over now ;-).

For me old habits die hard. I can spur a VM quickly by running installer but I do like these images. In qemu I just throw that disk at it; in VMware it's more finicky (time wise).
Mostly I use them if I need to copy something users share here I need to execute. Use it and then KKND it (kill krush 'n destroy).
 
I use streamlined and repository'd configurations for jail-/vmhosts everywhere, so manually setting up a host is done in a matter of minutes (base install, minimal set of packages, handful of config files from a git repository) and jails or VMs can be created from common templates and send|recvd between hosts, thanks to identical "environments" for them (e.g. names of network bridges those jails/vms are connected to are the same everywhere).
I mostly use clonejails and my "master-template"-jail is simply distributed via a small zfs-replication script from the host I hold that master-jail to all jailhosts.

As said: I pretty much completely moved away from cloud services to self-hosted (and mostly on-premise) jails/VMs and hence build most things to my needs. E.g. for (semi-)automatic network configuration of jails I hook into the repository of our local nameservers to find free ip addresses and to register the hostnames as well as the dhcp servers to provide VMs with statically assigned IPs via DHCP.
I like to keep control of such things on the hosts and central repositories and not within jails/VMs - which is much simpler to manage with 'single points of truth' (and single points for configuration changes) and no need for complex configuration within the guests, which and also brings security benefits.
 
You must log in or register to reply here.
Back
Top