This is an original planning guide. It is not a vendor manual, an official standard, or legal advice. Example addresses use documentation ranges. Review every command before you paste it.
The first boot should match a file
Provisioning is how a new machine becomes the host in the ticket instead of a hand-built snowflake. cloud-init is the usual first-boot path for cloud images. Kickstart is the usual path for an Anaconda installer such as RHEL and the rebuilds. Other distros have their own installers. The distro pillars are the dialect after the host exists. This page is the file that builds it.
The file sets hostname, a user, authorized keys, packages, and maybe a network address. A password in the file is a secret in whatever stores the file. Use a key. If a form requires a password field, the note says prompt-for-this and the real value is injected by the secret store at build time, not committed. The generators on this site draft the file in the browser. Do not paste a live private key into them.
An image you reuse is better than a script that mutates a finished server every time someone needs a copy. Mutation after first boot belongs to configuration management, which should start from the image and not fight it. Two tools both installing the web server is how the listening port changes under you.
The first boot is tested by booting it once and reading what you got: hostname, user, SSH key login, and the absence of a password login if that was the decision. A file you have not booted is a draft.
A lab first boot with a key and a documentation address
The lab hostname is edge-01. The user is the named admin, not root with a password from a blog. SSH allows that user's key. Password authentication stays off only after the key works, which is the same order as the hardening guide. The lab address, if you set one, is 192.0.2.10/24 and the gateway is 192.0.2.1, and you replace both before any real network. A DHCP lab can skip the static address and say so.
The cloud-init or kickstart draft from the generator is diffed against an empty file so you see every line. Delete packages you do not need. Delete any user you do not know. Confirm the file does not contain a private key or a password. Then boot one VM from the virtualization guide and try the key.
If the boot fails, you do not debug it by enabling a password on the console and then leaving that password in the image. Fix the file and boot again from a clean disk. The console is for reading the error.
When the boot matches the ticket, save the file next to the image version. The next copy uses that pair. A hand fix on the running VM that is not copied back into the file will be missing on the next build.
# Review before you paste. Lab intent for a first-boot file.
# hostname: edge-01
# user: the named admin, SSH key only
# address example: 192.0.2.10/24 via 192.0.2.1
# Replace the address outside the lab.
# No password in the file. No private key in the file.
# prompt-for-this is a reminder, not a password to keep.A change you can finish
A production image uses the real hostname pattern, the real admin key, and the real network from the network desk. Secrets come from the secret store at build time. You boot one canary before you boot twenty.
Rollback is to keep the previous image available and to destroy the canary if it is wrong and holds no unique data.
- Write hostname, user, and whether the address is DHCP or static.
- Draft the file and diff it. Remove unknown users and extra packages.
- Confirm no password and no private key are in the file.
- Boot one clean VM.
- Log in with the key. Confirm password login is not required for that test.
- Copy any console fix back into the file and boot clean again.
- Save the file and the image version together.
Mistakes that outlive the command
server provisioning fails in the same few ways. Each one looks finished on the day you type it. The list is here so the ticket can forbid them before the window, not so you can recognise them in an incident review.
- A password or a private key committed in cloud-init or kickstart.
- Pasting a real key into the browser generator.
- Hand-fixing the VM and not the file.
- Two provisioners installing the same service.
- Turning on password SSH to debug, then shipping the image that way.
- A static address copied from the lab into production.
- Root login with a shared password as the provisioning user.
- A file nobody has booted.
Decisions to write down before the window
One decision for server provisioning: The file is the source of truth. A console fix is copied back or thrown away. Authentication is a key. prompt-for-this never becomes a real password in git. The generator was given placeholders, not live secrets. One canary boots before a fleet. The address is DHCP or a prefix you own. 192.0.2.10 stays in the lab. Package list is short and matches the purpose from the fundamentals page. Configuration management starts after first boot and does not fight the image. The previous image remains available. Password SSH is off only after the key login worked on the canary. The distro pillar is the next page for that OS's daily commands. And a second person read the user name and the address in the file.
Provisioning checks before a second host is built
Confirm this before you call the change done: The file contains the hostname and user from the ticket. No password and no private key are in the file. The diff was read. A clean VM booted from that file. Key login worked. The lab address was not copied to a real network. Console fixes were merged back or discarded. The image version is recorded next to the file. A second provisioner is not also installing these packages. The canary holds no unique data, so it can be destroyed. A second person saw the login. The hardening guide's order was respected: key first, then disable passwords. The previous image is still available. The hostname in the prompt matches the hostname in the ticket for server provisioning. The result line includes the time and the person, not only the command. You can point at the rollback value without searching a chat history. And done is a sentence a second person can repeat: the proof for server provisioning happened, and the next host is not started early. If one of those fails, stop.
Tools for this guide
These tools run in the browser on this site. They do not log into your machines.
Related pillar guides
Guides in this cluster
These supporting pages belong to this pillar.
- How-To: cloud-init Tutorial
- Comparison: Automated Linux Installs (Kickstart, Autoinstall, Preseed)
- How-To: Unattended Windows Installs
- How-To: Ansible for Sysadmins
- Comparison: Ansible vs Puppet vs Salt
- How-To: Building Golden Images with Packer
- How-To: Local Labs with Vagrant
Companion: Cloud: Infrastructure as Code Guide.