diff --git a/Documentation/bootcfg.md b/Documentation/bootcfg.md index e170ab77..f7e87463 100644 --- a/Documentation/bootcfg.md +++ b/Documentation/bootcfg.md @@ -5,6 +5,8 @@ Network boot endpoints provide PXE, iPXE, GRUB, and [Pixiecore](https://github.com/danderson/pixiecore/blob/master/README.api.md) support. `bootcfg` can be deployed as a binary, as an [appc](https://github.com/appc/spec) container with rkt, or as a Docker container. +Bootcfg Overview + ## Getting Started Get started running `bootcfg` on your Linux machine, with rkt or Docker, to network boot virtual or physical machines into CoreOS clusters. @@ -12,15 +14,14 @@ Get started running `bootcfg` on your Linux machine, with rkt or Docker, to netw * [bootcfg with rkt](getting-started-rkt.md) * [bootcfg with Docker](getting-started-docker.md) -Bootcfg Overview - ## Flags See [flags and variables](config.md) ## API -See [API](api.md) +* [HTTP API](api.md) +* [gRPC API](https://godoc.org/github.com/coreos/coreos-baremetal/bootcfg/client) ## Data @@ -44,11 +45,6 @@ Prepare `/var/lib/bootcfg` with `profile`, `groups`, `ignition`, and `cloud` sub └── etcd.json └── worker.json -Ignition templates can be JSON or YAML files (rendered as JSON). Cloud-Config templates can be a script or YAML file. Both may contain [Go template](https://golang.org/pkg/text/template/) elements which will be executed with machine Group [metadata](#groups-and-metadata). For details and examples: - -* [Ignition Config](ignition.md) -* [Cloud-Config](cloud-config.md) - ### Profiles Profiles specify a Ignition config, Cloud-Config, and network boot config. @@ -76,6 +72,13 @@ To use cloud-config, set the `cloud-config-url` kernel option to reference the ` To use Ignition, set the `coreos.config.url` kernel option to reference the `bootcfg` [Ignition endpoint](api.md#ignition-config), which will render the `ignition_id` file. Be sure to add the `coreos.first_boot` option as well. +### Configs + +Ignition templates can be JSON or YAML files (rendered as JSON). Cloud-Config templates can be a script or YAML file. Both may contain [Go template](https://golang.org/pkg/text/template/) elements which will be executed with machine Group [metadata](#groups-and-metadata). For details and examples: + +* [Ignition Config](ignition.md) +* [Cloud-Config](cloud-config.md) + ## Groups and Metadata Groups define selectors which match zero or more machines. Machine(s) matching a group will boot and provision according to the group's `Profile` and `metadata`. diff --git a/Documentation/getting-started-docker.md b/Documentation/getting-started-docker.md index 33bb4309..63c0bf49 100644 --- a/Documentation/getting-started-docker.md +++ b/Documentation/getting-started-docker.md @@ -85,6 +85,5 @@ Clean up the VM machines. ## Going Further -Explore the [examples](../examples). Try the [k8s-docker example](kubernetes.md) to produce a TLS-authenticated Kubernetes cluster you can access locally with `kubectl` ([docs](../examples/README.md#kubernetes)). +Learn more about [bootcfg](bootcfg.md) or explore the other [example](../examples) clusters. Try the [k8s-docker example](kubernetes.md) to produce a TLS-authenticated Kubernetes cluster you can access locally with `kubectl` ([docs](../examples/README.md#kubernetes)). -Learn more about [bootcfg](bootcfg.md) or adapt an example for your own [physical hardware](physical-hardware.md) and network. diff --git a/Documentation/getting-started-rkt.md b/Documentation/getting-started-rkt.md index 1b01996c..d0f5c175 100644 --- a/Documentation/getting-started-rkt.md +++ b/Documentation/getting-started-rkt.md @@ -123,6 +123,5 @@ Press ^] three times to stop a rkt pod. Clean up the VM machines. ## Going Further -Explore the [examples](../examples). Try the [k8s example](kubernetes.md) to produce a TLS-authenticated Kubernetes cluster you can access locally with `kubectl` ([docs](../examples/README.md#kubernetes)). +Learn more about [bootcfg](bootcfg.md) or explore the other [example](../examples) clusters. Try the [k8s example](kubernetes.md) to produce a TLS-authenticated Kubernetes cluster you can access locally with `kubectl` ([docs](../examples/README.md#kubernetes)). -Learn more about [bootcfg](bootcfg.md) or adapt an example for your own [physical hardware](physical-hardware.md) and network. diff --git a/Documentation/img/network-setup-flow.png b/Documentation/img/network-setup-flow.png new file mode 100644 index 00000000..7570baa3 Binary files /dev/null and b/Documentation/img/network-setup-flow.png differ diff --git a/Documentation/network-booting.md b/Documentation/network-booting.md index ed8ea491..8870ba15 100644 --- a/Documentation/network-booting.md +++ b/Documentation/network-booting.md @@ -1,9 +1,7 @@ # Network Boot Environments -These guides walk through booting and configuring CoreOS on real or virtual hardware on your network. This introductory document reviews network booting protocols and the requirments of your network environment. - -Once you've reviewed the protocols, you'll be ready to [get started](getting-started-rkt.md) serving configs to machines during boot with [bootcfg](bootcfg.md). +This guide reviews network boot protocols and the different ways client machines can be PXE booted. ## PXE @@ -45,8 +43,6 @@ PXELINUX then downloads the specified kernel and init RAM filesystem images with This approach has a number of drawbacks. TFTP can be slow, managing config files can be tedious, and using different ignition or cloud configs on different machines requires separate pxelinux configs. These limitations spurred the development of various enhancements to PXE, discussed next. -In these guides, PXE is used to load the iPXE boot file so iPXE can chainload config scripts and HTTP images over HTTP. Continue to the [baremetal guide](physical-hardware.md) to boot PXE clients by chainloading iPXE. Consult [CoreOS with PXE](https://coreos.com/os/docs/latest/booting-with-pxe.html) for details about CoreOS support for PXE. - #### iPXE [iPXE](http://ipxe.org/) is an enhanced implementation of the PXE client firmware and a network boot program which uses iPXE scripts rather than config files and can download scripts and images with HTTP. @@ -70,24 +66,14 @@ A TFTP server is used only to provide the `undionly.kpxe` boot program to older CoreOS `bootcfg` can render signed iPXE scripts to machines based on their hardware attributes. Setup involves configuring your DHCP server to point iPXE clients to the `bootcfg` [iPXE endpoint](api.md#ipxe). -Continue to the [baremetal guide](physical-hardware.md) to use iPXE to boot PXE/iPXE client machines. Consult [CoreOS with iPXE](https://coreos.com/os/docs/latest/booting-with-ipxe.html) for details about CoreOS support for iPXE. - #### Pixiecore [Pixiecore](https://github.com/danderson/pixiecore) is a newer service which implements a proxyDHCP server, TFTP server, and HTTP server all-in-one and calls through to an HTTP API. CoreOS `bootcfg` can serve Pixiecore JSON (optionally signed) based on the supplied MAC address, to implement the Pixiecore HTTP API. -## Network Environments +## DHCP -### DHCP - -Many networks have DHCP services which are impractical to modify or disable. Corporate DHCP servers are governed by network admin policies and home/office networks often have routers running a DHCP service which cannot supply PXE options to PXE clients. +Many networks have DHCP services which are impractical to modify or disable. Company DHCP servers are governed by network admin policies and home/office networks often have routers running a DHCP service which cannot supply PXE options to PXE clients. To address this, PXE client firmware listens for DHCPOFFERs from a non-PXE DHCP server *and* a PXE-enabled **proxyDHCP server** configured to respond with the next server and boot filename only. Client firmware combines the two responses as if they had come from a single PXE-enabled DHCP server. DHCP and proxyDHCP responses are merged to get PXE Options - -The [baremetal guide](physical-hardware.md) shows how to check your network environment and run either a standalone PXE-enabled DHCP server, a proxyDHCP server to compliment your existing network DHCP service, or configure existing services. - -## Configuration Service - -Now that you understand network booting protocols [get started](getting-started-rkt.md) serving configs to machines during boot with [bootcfg](bootcfg.md). diff --git a/Documentation/network-setup.md b/Documentation/network-setup.md new file mode 100644 index 00000000..a4ba136d --- /dev/null +++ b/Documentation/network-setup.md @@ -0,0 +1,160 @@ + +# Network Setup + +This guide shows how to create a DHCP/TFTP/DNS network boot environment to work with `bootcfg` to boot and provision PXE, iPXE, or GRUB2 client machines. + +`bootcfg` serves iPXE scripts or GRUB configs over HTTP to serve as the entrypoint for CoreOS cluster bring-up. It does not implement or exec a DHCP, TFTP, or DNS server. Instead, you can configure your own network services to point to `bootcfg` or use the convenient [coreos/dnsmasq](../contrib/dnsmasq) container image (used in libvirt demos). + +*Note*: These are just suggestions. Your network administrator or system administrator should choose the right network setup for your company. + +## Requirements + +Client hardware must have a network interface which supports PXE or iPXE. + +## Goals + +* Add a DNS name which resolves to a `bootcfg` deploy. +* Chainload PXE firmware to iPXE or GRUB2 +* Point iPXE clients to `http://bootcfg.foo:port/boot.ipxe` +* Point GRUB clients to `http://bootcfg.foo:port/grub` + +## Setup + +Many companies already have DHCP/TFTP configured to "PXE-boot" PXE/iPXE clients. In this case, machines (or a subset of machines) can be made to chainload from `chain http://bootcfg.foo:port/boot.ipxe`. Older PXE clients can be made to chainload into iPXE or GRUB to be able to fetch subsequent configs via HTTP. + +On simpler networks, such as what a developer might have at home, a relatively inflexible DHCP server may be in place, with no TFTP server. In this case, a proxy DHCP server can be run alongside a non-PXE capable DHCP server. + +This diagram can point you to the **right section(s)** of this document. + +Network Setup Flow + +The setup of DHCP, TFTP, and DNS services on a network varies greatly. If you wish to use rkt or Docker to quickly run DHCP, proxyDHCP TFTP, or DNS services, use [coreos/dnsmasq](#coreos/dnsmasq). + +## DNS + +Add a DNS entry (e.g. `bootcfg.foo`, `provisoner.mycompany-internal`) that resolves to a deployment of the CoreOS `bootcfg` service from machines you intend to boot and provision. + + dig bootcfg.foo + +If you deployed `bootcfg` to a known IP address (e.g. dedicated host, load balanced endpoint, Kubernetes NodePort) and use `dnsmasq`, a domain name to IPv4/IPv6 address mapping could be added to the `/etc/dnsmasq.conf`. + + # dnsmasq.conf + address=/bootcfg.foo/172.15.0.2 + +## iPXE + +Servers with DHCP/TFTP/ services which already network boot iPXE clients can use the `chain` command to make clients download and execute the iPXE boot script from `bootcfg`. + + # /var/www/html/ipxe/default.ipxe + chain http://bootcfg.foo:8080/boot.ipxe + +You can chainload from a menu entry or use other [iPXE commands](http://ipxe.org/cmd) if you have needs beyond just delegating to the iPXE script served by `bootcfg`. + +## GRUB + +Needs docs. + +### Configuring DHCP + +Configure your DHCP server to supply options to older PXE client firmware to specify the location of an iPXE or GRUB network boot program on your TFTP server. Send clients to the `bootcfg` iPXE script or GRUB config endpoints. + +Here is an example `/etc/dnsmasq.conf`: + + dhcp-range=192.168.1.1,192.168.1.254,30m + enable-tftp + tftp-root=/var/lib/tftpboot + # if request comes from older PXE ROM, chainload to iPXE (via TFTP) + dhcp-boot=tag:!ipxe,undionly.kpxe + # if request comes from iPXE user class, set tag "ipxe" + dhcp-userclass=set:ipxe,iPXE + # point ipxe tagged requests to the bootcfg iPXE boot script (via HTTP) + dhcp-boot=tag:ipxe,http://bootcfg.foo:8080/boot.ipxe + # verbose + log-queries + log-dhcp + # (optional) disable DNS + port=0 + # (optional) static DNS assignements + # address=/bootcfg.foo/192.168.1.100 + +Add [unidonly.kpxe](http://boot.ipxe.org/undionly.kpxe) (and undionly.kpxe.0 if using dnsmasq) to your tftp-root (e.g. `/var/lib/tftpboot`). + + sudo systemctl start dnsmasq + sudo firewall-cmd --add-service=dhcp --add-service=tftp [--add-service=dns] + sudo firewall-cmd --list-services + +#### proxy DHCP + +Alternately, a DHCP proxy server can be run alongside an existing non-PXE DHCP server. The proxy DHCP server provides only the next server and boot filename Options, leaving IP allocation to the DHCP server. Clients listen for both DHCP offers and merge the responses as though they had come from one PXE-enabled DHCP server. + +Example `/etc/dnsmasq.conf`: + + dhcp-range=192.168.1.1,proxy,255.255.255.0 + enable-tftp + tftp-root=/var/lib/tftpboot + # if request comes from older PXE ROM, chainload to iPXE (via TFTP) + pxe-service=tag:#ipxe,x86PC,"PXE chainload to iPXE",undionly.kpxe + # if request comes from iPXE user class, set tag "ipxe" + dhcp-userclass=set:ipxe,iPXE + # point ipxe tagged requests to the bootcfg iPXE boot script (via HTTP) + pxe-service=tag:ipxe,x86PC,"iPXE",http://bootcfg.foo:8080/boot.ipxe + # verbose + log-queries + log-dhcp + +Add [unidonly.kpxe](http://boot.ipxe.org/undionly.kpxe) (and undionly.kpxe.0 if using dnsmasq) to your tftp-root (e.g. `/var/lib/tftpboot`). + + sudo systemctl start dnsmasq + sudo firewall-cmd --add-service=dhcp --add-service=tftp [--add-service=dns] + sudo firewall-cmd --list-services + +With rkt: + + sudo rkt run coreos.com/dnsmasq:v0.3.0 --net=host -- -d -q --dhcp-range=192.168.1.1,proxy,255.255.255.0 --enable-tftp --tftp-root=/var/lib/tftpboot --dhcp-userclass=set:ipxe,iPXE --pxe-service=tag:#ipxe,x86PC,"PXE chainload to iPXE",undionly.kpxe --pxe-service=tag:ipxe,x86PC,"iPXE",http://bootcfg.foo:8080/boot.ipxe --log-queries --log-dhcp + +With Docker: + + sudo docker run --net=host --rm --cap-add=NET_ADMIN quay.io/coreos/dnsmasq -d -q --dhcp-range=192.168.1.1,proxy,255.255.255.0 --enable-tftp --tftp-root=/var/lib/tftpboot --dhcp-userclass=set:ipxe,iPXE --pxe-service=tag:#ipxe,x86PC,"PXE chainload to iPXE",undionly.kpxe --pxe-service=tag:ipxe,x86PC,"iPXE",http://bootcfg.foo:8080/boot.ipxe --log-queries --log-dhcp + +### Configurable TFTP + +If your DHCP server is configured to PXE boot clients, but you don't have control over this configuration, you can modify the pxelinux.cfg's served to PXE clients. + +Example `/var/lib/tftpboot/pxelinux.cfg/default`: + + timeout 10 + default iPXE + LABEL iPXE + KERNEL ipxe.lkrn + APPEND dhcp && chain http://bootcfg.foo:8080/boot.ipxe + +Add ipxe.lkrn to `/var/lib/tftpboot` (see [iPXE docs](http://ipxe.org/embed)). + +## coreos/dnsmasq + +On networks without network services, the `coreos.com/dnsmasq:v0.3.0` rkt ACI or `coreos/dnsmasq:latest` Docker image can setup an appropriate environment quickly. The images bundle `undionly.kpxe` and `grub.efi` for convenience. Here are some examples which run a DHCP/TFTP/DNS server on your host's network: + +With rkt: + +``` +sudo rkt trust --prefix coreos.com/dnsmasq +# gpg key fingerprint is: 18AD 5014 C99E F7E3 BA5F 6CE9 50BD D3E0 FC8A 365E +``` + +``` +sudo rkt run coreos.com/dnsmasq:v0.3.0 --net=host -- -d -q --dhcp-range=192.168.1.3,192.168.1.254 --enable-tftp --tftp-root=/var/lib/tftpboot --dhcp-userclass=set:ipxe,iPXE --dhcp-boot=tag:#ipxe,undionly.kpxe --dhcp-boot=tag:ipxe,http://bootcfg.foo:8080/boot.ipxe --address=/bootcfg.foo/192.168.1.2 --log-queries --log-dhcp +``` + +With Docker: + +``` +sudo docker run --rm --cap-add=NET_ADMIN --net=host quay.io/coreos/dnsmasq -d -q --dhcp-range=192.168.1.3,192.168.1.254 --enable-tftp --tftp-root=/var/lib/tftpboot --dhcp-userclass=set:ipxe,iPXE --dhcp-boot=tag:#ipxe,undionly.kpxe --dhcp-boot=tag:ipxe,http://bootcfg.foo:8080/boot.ipxe --address=/bootcfg.foo/192.168.1.2 --log-queries --log-dhcp +``` + +Ensure that `bootcfg.foo` resolves to a `bootcfg` deployment and that you've allowed the services to run in your firewall configuration. + + sudo firewall-cmd --add-service=dhcp --add-service=tftp --add-service=dns + +## Troubleshooting + +See [troubleshooting](troubleshooting.md). \ No newline at end of file diff --git a/Documentation/physical-hardware.md b/Documentation/physical-hardware.md deleted file mode 100644 index 163ae7be..00000000 --- a/Documentation/physical-hardware.md +++ /dev/null @@ -1,103 +0,0 @@ - -# CoreOS on Baremetal/Physical Hardware - -Physical or baremetal hardware can be booted and configured with CoreOS by PXE, iPXE, and Pixiecore network environments. This guide will show how to setup and test network boot environments with physical clients. - -DHCP, TFTP, and HTTP services can run on separate network hosts or on the same host in PXE network environments. We'll focus on configuring a single *provisioner* Linux host to run these services as containers. - -## Requirements - -Client hardware boot firmware must support PXE or iPXE and the client must have at least one PXE-capable network interface. Most boot firmware and network cards support PXE so you're probably ok. - -## Inspect - -Identify whether the network runs a DHCP service which can be configured or whether you'll need to run a proxyDHCP service. Check a host's routing table to find the gateway where DHCP is likely to be running. - - route -n # e.g. Gateway 192.168.1.1 - -## bootcfg - -Set up `bootcfg` according to the [docs](bootcfg.md). Pull the `coreos/bootcfg` image, prepare a data volume with `Machine` definitions, `Spec` definitions and ignition/cloud configs. Optionally, include a volume of downloaded image assets. - -Run the `bootcfg` container to serve configs for any of the network environments we'll discuss next. - - docker run -p 8080:8080 --net=host --name=bootcfg --rm -v $PWD/examples:/data:Z -v $PWD/assets:/assets:Z coreos/bootcfg:latest -address=0.0.0.0:8080 -log-level=debug -config /data/etcd-docker.yaml - -Note, the kernel options in the `Spec` [examples](../examples) reference 172.17.0.2 (the libvirt case). Your kernel cmdline options should reference the IP or DNS name where `bootcfg` runs. - -## Network Setups - -Your network may already have a configurable PXE or iPXE server, configurable DHCP, a DHCP server you cannot modify, or no DHCP server at all. We'll show how to setup each network environment to talk to `bootcfg`, depending on your circumstances. - -Otherwise create a PXE, iPXE, or Pixiecore network boot environment using the CoreOS [dnsmasq](../contrib/dnsmasq) container image which can run DHCP, proxyDHCP, TFTP, and/or DNS with `dnsmasq`. Use `--net=host` to run the services on the host and use `--dhcp-boot` to point clients to `bootcfg`. - -### Configurable iPXE - -If your network environment already supports iPXE, edit your iPXE boot script to chainload from `bootcfg` - - # boot.ipxe - chain http://192.168.1.100:8080/boot.ipxe - -Substitute the name or IP and port where `bootcfg` runs. - -### Configurable DHCP - -If the DHCP server on your network is PXE-enabled and configurable, send the `bootcfg` iPXE endpoint as the boot filename option (e.g. `http://192.168.1.100:8080/boot.ipxe`). Substitute the name or IP and port where `bootcfg` runs. - -Optionally, respond to older PXE client firmware with the location of the `undionly.kpxe` boot program on your TFTP server. - -With `dnsmasq`, here is an example `dnsmasq.conf` - - # dnsmasq.conf - dhcp-range=192.168.1.1,192.168.1.254,30m - enable-tftp - tftp-root=/var/lib/tftpboot - # set tag "ipxe" if request comes from iPXE ("iPXE" user class) - dhcp-userclass=set:ipxe,iPXE - # if PXE request came from regular firmware, serve iPXE firmware (via TFTP) - dhcp-boot=tag:!ipxe,undionly.kpxe - # if PXE request came from iPXE, serve an iPXE boot script (via HTTP) - dhcp-boot=tag:ipxe,http://192.168.1.100:8080/boot.ipxe - -### proxyDHCP - -If the network already runs a DHCP service, setup a PXE/iPXE network environment alongside it with proxyDHCP and TFTP. - -Run DHCP in proxy mode to respond to DHCP requests on the subnet. Optionally, serve the `undionly.pxe` boot file to older, non-iPXE clients (the '#' means not). Detect iPXE clients by the user class sent in their DHCPDISCOVER (or by Option 175) and point them to the `bootcfg` iPXE boot script. - -``` -sudo docker run --net=host --rm --cap-add=NET_ADMIN quay.io/coreos/dnsmasq -d -q -i enp0s25 --dhcp-range=192.168.1.1,proxy,255.255.255.0 --enable-tftp --tftp-root=/var/lib/tftpboot --dhcp-userclass=set:ipxe,iPXE --pxe-service=tag:#ipxe,x86PC,"PXE chainload to iPXE",undionly.kpxe --pxe-service=tag:ipxe,x86PC,"iPXE",http://192.168.1.100:8080/boot.ipxe -``` - -Change the `dhcp-range`, `-i interface`, and boot.ipxe endpoint to match your environment. - -In this example, an existing router at 192.168.1.1 runs DHCP to allocate IP addresses between 192.168.1.2 and 192.168.1.254. The proxyDHCP is configured to respond to disocver requests on the 192.168.1.0/24 subnet. `bootcfg` runs on host (192.168.1.100) to serve iPXE boot scripts. - -### DHCP - -If the network does not already run a DHCP service, you can run one yourself and provide PXE options to baremetal clients. This is the case if your baremetal machines are connected to an isolated switch. - -Identify a host machine which should run the DHCP service. If this machine has two NICs, it can serve as a router, using one for the uplink connection and the other to connect to the subnet with baremetal clients. - -Run DHCP to allocate IP address leases and TFTP to serve the `undionly.pxe` boot file to older, non-iPXE clients (the '#' means not). Point iPXE clients to the `bootcfg` iPXE boot script. - -``` -sudo docker run --net=host --rm --cap-add=NET_ADMIN quay.io/coreos/dnsmasq -d -q -i enp0s20u1 --dhcp-range=192.168.1.101,192.168.1.150 --enable-tftp --tftp-root=/var/lib/tftpboot --dhcp-userclass=set:ipxe,iPXE --dhcp-boot=tag:#ipxe,undionly.kpxe --dhcp-boot=tag:ipxe,http://192.168.1.100:8080/boot.ipxe -``` - -Change the `dhcp-range`, `-i interface`, and boot.ipxe endpoint to match your environment. - -In this example, a DHCP server is configured to allocate IP addresses between 192.168.1.101 and 192.168.1.150. `bootcfg` runs on host (192.168.1.100) to serve iPXE boot scripts. - -You may have to explicitly assign the interface (-i) a network address and mark the interface as up. - - ip addr add 192.168.1.100/24 dev enp0s20u1 - ip link set dev enp0s20u1 up - -## Troubleshooting - -See [troubleshooting](troubleshooting.md). - -### Alternatives - -If you prefer, [Debian](http://www.debian-administration.org/article/478/Setting_up_a_server_for_PXE_network_booting), [Fedora](https://docs.fedoraproject.org/en-US/Fedora/7/html/Installation_Guide/ap-pxe-server.html), and [Ubuntu](https://help.ubuntu.com/community/DisklessUbuntuHowto) provide guides on PXE server setups. CoreOS-baremetal also includes [Vagrantfiles](vagrant) to quickly setup example Fedora PXE, iPXE, and Pixiecore servers on libvirt. diff --git a/README.md b/README.md index 786d05b6..9cef21ae 100644 --- a/README.md +++ b/README.md @@ -7,12 +7,13 @@ CoreOS on Baremetal provides guides and a service for network booting and provis ## Guides -* [Network Booting](Documentation/network-booting.md) +* [Network Setup](Documentation/network-setup.md) * [Machine Lifecycle](Documentation/machine-lifecycle.md) +* [Background: PXE Booting](Documentation/network-booting.md) ## bootcfg -`bootcfg` is an HTTP and gRPC service that renders signed [Ignition configs](https://coreos.com/ignition/docs/latest/what-is-ignition.html), [cloud-configs](https://coreos.com/os/docs/latest/cloud-config.html), network boot configs, and metadata to machines to create CoreOS clusters. Groups match machines based on labels (e.g. UUID, MAC, stage, region) and use named Profiles for provisioning. Network boot endpoints provide PXE, iPXE, GRUB, and Pixiecore support. `bootcfg` can be deployed as a binary, as an [appc](https://github.com/appc/spec) container with [rkt](https://coreos.com/rkt/docs/latest/), or as a Docker container. +`bootcfg` is an HTTP and gRPC service that renders signed [Ignition configs](https://coreos.com/ignition/docs/latest/what-is-ignition.html), [cloud-configs](https://coreos.com/os/docs/latest/cloud-config.html), network boot configs, and metadata to machines to create CoreOS clusters. Groups match machines based on labels (e.g. MAC, UUID, stage, region) and use named Profiles for provisioning. Network boot endpoints provide PXE, iPXE, GRUB, and Pixiecore support. `bootcfg` can be deployed as a binary, as an [appc](https://github.com/appc/spec) container with [rkt](https://coreos.com/rkt/docs/latest/), or as a Docker container. * [bootcfg with rkt](Documentation/getting-started-rkt.md) * [bootcfg with Docker](Documentation/getting-started-docker.md) @@ -22,7 +23,8 @@ CoreOS on Baremetal provides guides and a service for network booting and provis * [Ignition](Documentation/ignition.md) * [Cloud-Config](Documentation/cloud-config.md) * [Flags](Documentation/config.md) -* [API](Documentation/api.md) +* [HTTP API](Documentation/api.md) +* [gRPC API](https://godoc.org/github.com/coreos/coreos-baremetal/bootcfg/client) * Backends * [FileStore](Documentation/bootcfg.md#data) * Deployment via