Tema: provisioning
-
Windows answer files (unattend.xml): configuration passes and where Setup looks for them
An unattend.xml answer file supplies settings to specific configuration passes of Windows Setup — windowsPE, generalize, specialize and oobeSystem are the ones provisioning touches most. Setup finds the file through a fixed implicit search order and caches it in %WINDIR%\Panther, and Windows System Image Manager builds these files and can hide, but not encrypt, local-account passwords in them.
-
Ansible ad-hoc commands and check mode for a safe first run against a fleet
An ad-hoc `ansible` command runs one module against one or more hosts without a playbook, and combining it with `--check --diff` and a narrow `--limit` lets an agent see what a change would do to a fleet before it does it.
-
Generalizing a Windows image with Sysprep: /generalize, /oobe, /shutdown and the rearm limit
Sysprep /generalize removes computer-specific information such as the SID and the configured devices from a Windows installation so the image can be deployed to other computers; on Windows 8.1/Server 2012 and later Sysprep can be run up to 1001 times per image (3 times on Windows 7/Server 2008 R2), and generalize failures leave their trace in the Panther logs under System32\Sysprep.
-
Regenerating SSH host keys and the machine ID on a cloned Linux host
A freshly cloned Linux host needs its own SSH host keys and machine ID before it joins a fleet; ssh-keygen -A and systemd-machine-id-setup can create them, but on an already-booted clone a duplicated machine ID needs a freshly written value and a reboot. Checking for duplicates across the fleet is the only real verification that cloning did not just copy the same identifiers everywhere.
-
Preparing a Linux golden image for cloning: host keys, machine-id, logs and net rules
A Linux image meant to be cloned many times must not carry a populated /etc/machine-id (or a stale /var/lib/dbus/machine-id), existing SSH host keys, MAC-pinned network configuration or cloud-init state. Otherwise every clone boots with the same identifiers as its siblings, and removing the host keys without a first-boot regeneration path leaves clones without SSH.
-
Decommissioning a server safely: removing it from every system that still trusts it
Decommissioning is not just powering a machine off: DNS, monitoring, backup jobs, the inventory record, and any directory computer object all keep trusting or expecting a server unless someone explicitly removes it, and the storage itself needs a sanitization method that actually matches the media type before reuse or disposal.
-
Building machine images with Packer: builders, provisioners, validate and build
HashiCorp Packer separates a template's builders (what platform produces the image) from its provisioners (what configures the machine before it is captured); `packer init` installs the required plugins, `packer validate` checks a template's syntax and configuration before `packer build` runs it, and marking variables sensitive keeps credentials out of both templates and logs.
-
Debian preseed and Ubuntu autoinstall: two automated-install formats, not interchangeable
Debian's installer is automated with a preseed file that answers debconf questions, while Ubuntu Server (20.04+) and Desktop (23.04+) use Subiquity's YAML autoinstall format, delivered either as cloud-init user-data or as autoinstall.yaml on the install media. The two formats are not portable between distributions, and both should be validated before use in an unattended install.
-
Windows first-boot provisioning agents in the cloud: EC2Launch v2, the Azure VM Agent, and cloudbase-init
AWS, Azure and most other clouds run a small agent inside a Windows image that processes user data or custom data on first boot; the common agents are EC2Launch v2, Azure's provisioning and Windows VM agents (which store custom data in CustomData.bin but do not execute it) and the open-source cloudbase-init. Each logs to a different location worth checking when provisioning appears to have silently failed.
-
Post-provisioning verification checklist before handing a server over
A server that boots is not the same as a server that is ready to run production work; this checklist gives an agent a fixed order of checks — time, name resolution, patch level, monitoring, backup enrollment, access, and a baseline scan — to run before marking a newly provisioned host as done.
-
Configuration management versus image baking: where idempotence and drift decide
Configuration management tools converge a running system toward a declared state on every run, while baking a machine image fixes that state once, at build time; idempotence is what makes the first approach safe to repeat, and the choice between baking and configuring at boot is really a choice about where drift is allowed to happen.
-
Naming, tagging and recording a new server: a methodology for hostnames and inventory
A server that is provisioned but never named consistently, tagged with its owner and purpose, and recorded in an inventory is effectively undocumented infrastructure the moment the person who built it moves on; this methodology sets the hostname on Linux and Windows and defines what a minimal inventory record must contain.
-
Driving cloud-init on a fresh Debian or Ubuntu instance: user-data, status --wait, and safe re-runs
cloud-init applies user-data once at first boot; `cloud-init status --wait` blocks until that run finishes so a provisioning script does not race it, `cloud-init schema --system` catches a bad user-data file before the next boot, and `cloud-init clean` is the documented way to force a full re-run for testing.
Legible por máquina: JSON