7 |
8 | - Enter your registry's URL as the application URL
9 |
10 | Note: If using public GitHub, the URL entered must be accessible by *your users*. It can still be an internal URL.
11 |
12 | - Enter `https://{REGISTRY URL HERE}/oauth2/github/callback` as the Authorization callback URL.
13 | - Create the application
14 |
15 | 
16 |
17 | - Note down the `Client ID` and `Client Secret`.
18 |
--------------------------------------------------------------------------------
/os/adding-certificate-authorities.md:
--------------------------------------------------------------------------------
1 | # Custom Certificate Authorities
2 |
3 | CoreOS supports custom Certificate Authorities (CAs) in addition to the default list of trusted CAs. Adding your own CA allows you to:
4 |
5 | - Use a corporate wildcard certificate
6 | - Use your own CA to communicate with an installation of CoreUpdate
7 | - Use your own CA to [encrypt communications with a container registry](registry-authentication.md)
8 |
9 | The setup process for any of these use-cases is the same:
10 |
11 | 1. Copy the PEM-encoded certificate authority file (usually with a `.pem` file name extension) to `/etc/ssl/certs`
12 |
13 | 2. Run the `update-ca-certificates` script to update the system bundle of Certificate Authorities. All programs running on the system will now trust the added CA.
14 |
15 | ## More Information
16 |
17 | [Generate Self-Signed Certificates](generate-self-signed-certificates.md)
18 |
19 | [Use an insecure registry behind a firewall](registry-authentication.md#using-a-registry-without-ssl-configured)
20 |
21 | [etcd Security Model]({{site.baseurl}}/etcd/docs/latest/security.html)
22 |
--------------------------------------------------------------------------------
/README.md:
--------------------------------------------------------------------------------
1 | # CoreOS Documentation
2 |
3 | These are publicly accessible versions of the documentation on [coreos.com](http://coreos.com/docs/).
4 |
5 | Check out the [help-wanted tag](https://github.com/coreos/docs/issues?q=is%3Aopen+label%3Ahelp-wanted) if you're not sure what to help out with.
6 |
7 | 1. Fork this repo
8 | 2. Send a Pull Request
9 | 3. We will get your fix up on [coreos.com](http://coreos.com/docs/)
10 |
11 | Thanks for your contributions and fixes!
12 |
13 | ## Translations
14 |
15 | We accept patches for documentation translation. Please send the
16 | documents as a pull request and follow two guidelines:
17 |
18 | 1. Name the files identically to the originals but put them in a
19 | directory that matches the language locale. For example: JA\_JP,
20 | ZH\_CN or KO\_KN.
21 |
22 | 2. Add an explanation about the translated document to the top of the
23 | file: "These documents were localized into Esperanto by Community
24 | Member 
12 |
13 | ## View the logs for each service
14 |
15 | - Click the logs tab ()
16 | - To view logs for each service, click the service name at the top. The logs will update automatically.
17 |
18 | ## Contacting support
19 |
20 | When contacting support, one should always include a copy of the Enterprise Registry's log directory.
21 |
22 | To download logs, click the " Download All Local Logs (.tar.gz)" link
23 |
24 | ## Shell script to download logs
25 |
26 | The aforementioned operations are also available in script form on [GitHub](https://github.com/coreos/docs/blob/master/quay-enterprise/gzip-registry-logs.sh).
27 |
--------------------------------------------------------------------------------
/quay-enterprise/github-auth.md:
--------------------------------------------------------------------------------
1 | # GitHub Authentication
2 |
3 | CoreOS Enterprise Registry supports using GitHub or GitHub Enterprise as an authentication system.
4 |
5 | ## Create an OAuth Application in GitHub
6 |
7 | Following the instructions at [Create a GitHub Application](github-app.md).
8 |
9 | **NOTE:** This application must be **different** from that used for GitHub Build Triggers.
10 |
11 | ## Visit the Management Panel
12 |
13 | Sign in to a super user account and visit `http://yourregister/superuser` to view the management panel:
14 |
15 |
16 |
17 | ## Enable GitHub Authentication
18 |
19 | 
20 |
21 | - Click the configuration tab () and scroll down to the section entitled GitHub (Enterprise) Authentication.
22 | - Check the "Enable GitHub Authentication" box
23 | - Fill in the credentials from the application created above
24 | - Click "Save Configuration Changes"
25 | - Restart the container (you will be prompted)
26 |
--------------------------------------------------------------------------------
/golang/test:
--------------------------------------------------------------------------------
1 | #!/bin/bash -e
2 | #
3 | # Run all tests (not including functional)
4 | # ./test
5 | # ./test -v
6 | #
7 | # Run tests for one package
8 | # PKG=./foo ./test
9 | # PKG=bar ./test
10 | #
11 |
12 | # Invoke ./cover for HTML output
13 | COVER=${COVER:-"-cover"}
14 |
15 | source ./build
16 |
17 | TESTABLE="foo bar"
18 | FORMATTABLE="$TESTABLE baz"
19 |
20 | # user has not provided PKG override
21 | if [ -z "$PKG" ]; then
22 | TEST=$TESTABLE
23 | FMT=$FORMATTABLE
24 |
25 | # user has provided PKG override
26 | else
27 | # strip out slashes and dots from PKG=./foo/
28 | TEST=${PKG//\//}
29 | TEST=${TEST//./}
30 |
31 | # only run gofmt on packages provided by user
32 | FMT="$TEST"
33 | fi
34 |
35 | # split TEST into an array and prepend REPO_PATH to each local package
36 | split=(${TEST// / })
37 | TEST=${split[@]/#/${REPO_PATH}/}
38 |
39 | echo "Running tests..."
40 | go test ${COVER} $@ ${TEST}
41 |
42 | echo "Checking gofmt..."
43 | fmtRes=$(gofmt -l $FMT)
44 | if [ -n "${fmtRes}" ]; then
45 | echo -e "gofmt checking failed:\n${fmtRes}"
46 | exit 255
47 | fi
48 |
49 | echo "Checking govet..."
50 | vetRes=$(go vet $TEST)
51 | if [ -n "${vetRes}" ]; then
52 | echo -e "govet checking failed:\n${vetRes}"
53 | exit 255
54 | fi
55 |
56 | echo "Success"
57 |
--------------------------------------------------------------------------------
/quay-enterprise/provision_mysql.sh:
--------------------------------------------------------------------------------
1 | #!/bin/bash
2 | # A simple shell script to provision a dedicated MySQL container for the CoreOS Enterprise Registery
3 | set -e
4 |
5 | # Edit the following three values to your liking:
6 | MYSQL_USER="coreosuser"
7 | MYSQL_DATABASE="enterpriseregistrydb"
8 | MYSQL_CONTAINER_NAME="mysql"
9 |
10 | # Do not edit these values:
11 | # (creates a 32 char password for the MySQL root user and the Enterprise Registery DB user)
12 | MYSQL_ROOT_PASSWORD=$(cat /dev/urandom | LC_CTYPE=C tr -dc 'a-zA-Z0-9' | fold -w 32 | sed 1q)
13 | MYSQL_PASSWORD=$(cat /dev/urandom | LC_CTYPE=C tr -dc 'a-zA-Z0-9' | fold -w 32 | sed 1q)
14 |
15 | echo "Start the Oracle MySQL container:"
16 | # It will provision a blank database for the Enterprise Registery upon first start.
17 | # This initial provisioning can take up to 30 seconds.
18 |
19 | docker \
20 | run \
21 | --detach \
22 | --env MYSQL_ROOT_PASSWORD=${MYSQL_ROOT_PASSWORD} \
23 | --env MYSQL_USER=${MYSQL_USER} \
24 | --env MYSQL_PASSWORD=${MYSQL_PASSWORD} \
25 | --env MYSQL_DATABASE=${MYSQL_DATABASE} \
26 | --name ${MYSQL_CONTAINER_NAME} \
27 | --publish 3306:3306 \
28 | mysql:5.7;
29 |
30 | echo "Sleeping for 10 seconds to allow time for the DB to be provisioned:"
31 | for i in `seq 1 10`;
32 | do
33 | echo "."
34 | sleep 1
35 | done
36 |
37 | echo "Database '${MYSQL_DATABASE}' running."
38 | echo " Username: ${MYSQL_USER}"
39 | echo " Password: ${MYSQL_PASSWORD}"
--------------------------------------------------------------------------------
/os/switching-channels.md:
--------------------------------------------------------------------------------
1 | # Switching Release Channels
2 |
3 | CoreOS is released into stable, alpha and beta channels. New features and bug fixes are tested in the alpha channel and are promoted bit-for-bit to the beta channel if no additional bugs are found.
4 |
5 | By design, the CoreOS update engine does not execute downgrades. If you're switching from a channel with a higher CoreOS version than the new channel, your machine won't be updated again until the new channel contains a higher version number.
6 |
7 | 
8 |
9 | ## Create Update Config File
10 |
11 | You can switch machines between channels by creating `/etc/coreos/update.conf`:
12 |
13 | ```ini
14 | GROUP=beta
15 | ```
16 |
17 | ## Restart Update Engine
18 |
19 | The last step is to restart the update engine in order for it to pick up the changed channel:
20 |
21 | ```sh
22 | sudo systemctl restart update-engine
23 | ```
24 |
25 | ## Debugging
26 |
27 | After the update engine is restarted, the machine should check for an update within an hour. You can view the update engine log if you'd like to see the requests that are being made to the update service:
28 |
29 | ```sh
30 | journalctl -f -u update-engine
31 | ```
32 |
33 | For reference, you can find the current version:
34 |
35 | ```sh
36 | cat /etc/os-release
37 | ```
38 |
39 | ## Release Information
40 |
41 | You can read more about the current releases and channels on the [releases page]({{site.baseurl}}/releases).
42 |
--------------------------------------------------------------------------------
/quay-enterprise/swift-temp-url.md:
--------------------------------------------------------------------------------
1 | # Enterprise Registry Swift Direct Download
2 |
3 | ## Direct Download
4 |
5 | The Swift storage engine supports using a feature called [temporary URLs](http://docs.openstack.org/juno/config-reference/content/object-storage-tempurl.html) to allow for faster pulling of images.
6 |
7 | To enable direct download with Swift, please follow these instructions.
8 |
9 | ## Create a Swift temporary URL token
10 |
11 | To enable temporary URLs, first set the `X-Account-Meta-Temp-URL-Key` header on your Object Storage account to an arbitrary string. This string serves as a secret key. For example, to set a key of `somecoolkey` using the swift command-line tool:
12 |
13 | ```
14 | $ swift post -m "Temp-URL-Key:somecoolkey"
15 | ```
16 |
17 | ## Visit the Management Panel
18 |
19 | Sign in to a super user account and visit `http://registry.example.com/superuser` to view the management panel:
20 |
21 |
22 |
23 | ## Go to the settings tab
24 |
25 | - Click the configuration tab () and scroll down to the section entitled Registry Storage.
26 | - Ensure that "OpenStack Storage (Swift)" is selected
27 |
28 | ## Enter the temporary URL key
29 |
30 | Enter the key generated above into the `Temp URL Key` field under the Swift storage engine settings.
31 |
32 | ## Save configuration
33 |
34 | Hit `Save Configuration` to save and validate your configuration. The Swift storage engine system will automatically
35 | test that the direct download feature is enabled and working.
--------------------------------------------------------------------------------
/ignition/network-configuration.md:
--------------------------------------------------------------------------------
1 | # Network Configuration #
2 |
3 | Configuring networkd with Ignition is a very straightforward task. Because
4 | Ignition runs before networkd starts, configuration is just a matter of writing
5 | the desired config to disk. The Ignition config has a specific section
6 | dedicated to this.
7 |
8 | ## Static Networking ##
9 |
10 | In this example, the network interface with the name "eth0" will be given the
11 | IP address 10.0.1.7. A typical interface will need more configuration and can
12 | use all of the options of a [network unit][network].
13 |
14 | ```json
15 | {
16 | "networkd": {
17 | "units": [
18 | {
19 | "name": "00-eth0.network",
20 | "contents": "[Match]\nName=eth0\n\n[Network]\nAddress=10.0.1.7"
21 | }
22 | ]
23 | }
24 | }
25 | ```
26 |
27 | This configuration will instruct Ignition to create a single network unit named
28 | "00-eth0.network" with the contents:
29 |
30 | ```
31 | [Match]
32 | Name=eth0
33 |
34 | [Network]
35 | Address=10.0.1.7
36 | ```
37 |
38 | When the system boots, networkd will read this config and assign the IP address
39 | to eth0.
40 |
41 | [network]: http://www.freedesktop.org/software/systemd/man/systemd.network.html
42 |
43 | ## Bonded NICs ##
44 |
45 | In this example, all of the network interfaces whose names begin with "eth"
46 | will be bonded together to form "bond0". This new interface will then be
47 | configured to use DHCP.
48 |
49 | ```json
50 | {
51 | "networkd": {
52 | "units": [
53 | {
54 | "name": "00-eth.network",
55 | "contents": "[Match]\nName=eth*\n\n[Network]\nBond=bond0"
56 | },
57 | {
58 | "name": "10-bond0.netdev",
59 | "contents": "[NetDev]\nName=bond0\nKind=bond"
60 | },
61 | {
62 | "name": "20-bond0.network",
63 | "contents": "[Match]\nName=bond0\n\n[Network]\nDHCP=true"
64 | },
65 | ]
66 | }
67 | }
68 | ```
69 |
--------------------------------------------------------------------------------
/os/adding-users.md:
--------------------------------------------------------------------------------
1 | # Adding Users
2 |
3 | You can create user accounts on a CoreOS machine manually with `useradd` or via cloud-config when the machine is created.
4 |
5 | ## Add Users via Cloud-Config
6 |
7 | Managing users via cloud-config is preferred because it allows you to use the same configuration across many servers and the cloud-config file can be stored in a repo and versioned. In your cloud-config, you can specify many [different parameters]({{site.baseurl}}/docs/cluster-management/setup/cloudinit-cloud-config/#users) for each user. Here's an example:
8 |
9 | ```yaml
10 | #cloud-config
11 |
12 | users:
13 | - name: elroy
14 | passwd: $6$5s2u6/jR$un0AvWnqilcgaNB3Mkxd5yYv6mTlWfOoCYHZmfi3LDKVltj.E8XNKEcwWm...
15 | groups:
16 | - sudo
17 | - docker
18 | ssh-authorized-keys:
19 | - ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDGdByTgSVHq.......
20 | ```
21 |
22 | Check out the entire [Customize with Cloud-Config]({{site.baseurl}}/docs/cluster-management/setup/cloudinit-cloud-config/) guide for the full details.
23 |
24 | ## Add User Manually
25 |
26 | If you'd like to add a user manually, SSH to the machine and use the `useradd` tool. To create the user `user`, run:
27 |
28 | ```sh
29 | sudo useradd -p "*" -U -m user1 -G sudo
30 | ```
31 |
32 | The `"*"` creates a user that cannot login with a password but can log in via SSH key. `-U` creates a group for the user, `-G` adds the user to the existing `sudo` group and `-m` creates a home directory. If you'd like to add a password for the user, run:
33 |
34 | ```sh
35 | $ sudo passwd user1
36 | New password:
37 | Re-enter new password:
38 | passwd: password changed.
39 | ```
40 |
41 | To assign an SSH key, run:
42 |
43 | ```sh
44 | update-ssh-keys -u user1 user1.pem
45 | ```
46 |
47 | ## Further Reading
48 |
49 | Read the [full cloud-config]({{site.baseurl}}/docs/cluster-management/setup/cloudinit-cloud-config/) guide to install users and more.
50 |
--------------------------------------------------------------------------------
/quay-enterprise/mysql-container.md:
--------------------------------------------------------------------------------
1 | # Setting Up a MySQL Docker Container
2 |
3 | If you don't have an existing MySQL system to host the Enterprise Registry database on then you can run the steps below to create a dedicated MySQL container using the Oracle MySQL verified Docker image from https://registry.hub.docker.com/_/mysql/
4 |
5 | ```sh
6 | docker pull mysql:5.7
7 | ```
8 |
9 | Edit these values to your liking:
10 |
11 | ```sh
12 | MYSQL_USER="coreosuser"
13 | MYSQL_DATABASE="enterpriseregistrydb"
14 | MYSQL_CONTAINER_NAME="mysql"
15 | ```
16 | Do not edit these values:
17 | (creates a 32 char password for the MySQL root user and the Enterprise Registry DB user)
18 |
19 | ```sh
20 | MYSQL_ROOT_PASSWORD=$(cat /dev/urandom | tr -dc 'a-zA-Z0-9' | fold -w 32 | sed 1q)
21 | MYSQL_PASSWORD=$(cat /dev/urandom | tr -dc 'a-zA-Z0-9' | fold -w 32 | sed 1q)
22 | ```
23 |
24 | Start the MySQL container and create a new DB for the Enterprise registry:
25 |
26 | ```sh
27 | docker \
28 | run \
29 | --detach \
30 | --env MYSQL_ROOT_PASSWORD=${MYSQL_ROOT_PASSWORD} \
31 | --env MYSQL_USER=${MYSQL_USER} \
32 | --env MYSQL_PASSWORD=${MYSQL_PASSWORD} \
33 | --env MYSQL_DATABASE=${MYSQL_DATABASE} \
34 | --name ${MYSQL_CONTAINER_NAME} \
35 | --publish 3306:3306 \
36 | mysql:5.7;
37 | ```
38 |
39 | Wait about 30 seconds for the new DB to be created before testing the connection to the DB, the MySQL container will not respond during the initial DB creation process.
40 |
41 |
42 | Alternatively you can download a simple shell script to perform the steps above:
43 |
44 | ```sh
45 | curl --location https://raw.githubusercontent.com/coreos/docs/master/quay-enterprise/provision_mysql.sh -o /tmp/provision_mysql.sh -#
46 | ```
47 | Then run:
48 |
49 | ```sh
50 | chmod -c +x /tmp/provision_mysql.sh
51 | /tmp/provision_mysql.sh
52 | ```
53 |
54 | Note: Using Percona v5.6 for the MySQL container is known to not work at this point in time.
55 |
--------------------------------------------------------------------------------
/os/power-management.md:
--------------------------------------------------------------------------------
1 | # Tuning CoreOS Power Management
2 |
3 | ## CPU Governor
4 |
5 | By default, CoreOS uses the "performance" CPU governor meaning that the CPU
6 | operates at the maximum frequency regardless of load. This is reasonable for
7 | a system that is under constant load or cannot tolerate increased latency.
8 | On the other hand, if the system is idle much of the time and latency is not
9 | a concern, power savings may be desired.
10 |
11 | Several governors are available:
12 |
13 | | Governor | Description |
14 | |--------------------|-------------|
15 | | `performance` | Default. Operate at the maximum frequency |
16 | | `ondemand` | Dynamically scale frequency at 75% cpu load |
17 | | `conservative` | Dynamically scale frequency at 95% cpu load |
18 | | `powersave` | Operate at the minimum frequency |
19 | | `userspace` | Controlled by a userspace application via the `scaling_setspeed` file |
20 |
21 | The "conservative" governor can be used instead using the following shell commands:
22 |
23 | ```sh
24 | modprobe cpufreq_conservative
25 | echo "conservative" | tee /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor > /dev/null
26 | ```
27 |
28 | This can be configured with [cloud-config]({{site.baseurl}}/docs/cluster-management/setup/cloudinit-cloud-config/#coreos) as well:
29 |
30 | ```yaml
31 | coreos:
32 | units:
33 | - name: cpu-governor.service
34 | command: start
35 | runtime: true
36 | content: |
37 | [Unit]
38 | Description=Enable CPU power saving
39 |
40 | [Service]
41 | Type=oneshot
42 | RemainAfterExit=yes
43 | ExecStart=/usr/sbin/modprobe cpufreq_conservative
44 | ExecStart=/usr/bin/sh -c '/usr/bin/echo "conservative" | tee /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor'
45 | ```
46 |
47 | More information on further tuning each governor is available in the [Kernel Documentation](https://www.kernel.org/doc/Documentation/cpu-freq/governors.txt)
48 |
--------------------------------------------------------------------------------
/os/sdk-testing-with-mantle.md:
--------------------------------------------------------------------------------
1 | # Mantle: Gluing CoreOS together
2 |
3 | Mantle is a collection of utilities for the CoreOS SDK.
4 |
5 | ## plume index
6 |
7 | Generate and upload index.html objects to turn a Google Cloud Storage
8 | bucket into a publicly browsable file tree. Useful if you want something
9 | like Apache's directory index for your software download repository.
10 |
11 | ## plume gce cluster launching
12 |
13 | Related commands to launch instances on Google Compute Engine(gce) with
14 | the latest SDK image. SSH keys should be added to the gce project
15 | metadata before launching a cluster. All commands have flags that can
16 | overwrite the default project, bucket, and other settings. `plume help
17 |
21 |
22 | ## Enable GitHub Triggers
23 |
24 | 
25 |
26 | - Click the configuration tab () and scroll down to the section entitled GitHub (Enterprise) Build Triggers.
27 | - Check the "Enable GitHub Triggers" box
28 | - Fill in the credentials from the application created above
29 | - Click "Save Configuration Changes"
30 | - Restart the container (you will be prompted)
31 |
32 | ## Tag an Automated Build
33 |
34 | After getting automated builds working, it may be desired to tag a specific build with a name. By default, the last image pushed to a repository will be tagged as `latest`.
35 | Because tagging is [usually done client side](https://docs.docker.com/userguide/dockerimages/#setting-tags-on-an-image) before an image is pushed, it may not be clear how to tag an image that was built and pushed by GitHub. Luckily, there is a interface for doing so on the repository page. After clicking to select a given build on the build graph, the right side of the page displays tag information which when clicked provides a drop-down menu with the option of creating a new tag.
36 |
37 | 
38 |
39 | There is currently no ability to automatically tag GitHub triggered builds.
40 |
--------------------------------------------------------------------------------
/os/install-debugging-tools.md:
--------------------------------------------------------------------------------
1 | # Install Debugging Tools
2 |
3 | You can use common debugging tools like tcpdump or strace with Toolbox. Using the filesystem of a specified Docker container Toolbox will launch a container with full system privileges including access to system PIDs, network interfaces and other global information. Inside of the toolbox, the machine's filesystem is mounted to `/media/root`.
4 |
5 | ## Quick Debugging
6 |
7 | By default, Toolbox uses the stock Fedora Docker container. To start using it, simply run:
8 |
9 | ```sh
10 | /usr/bin/toolbox
11 | ```
12 |
13 | You're now in the namespace of Fedora and can install any software you'd like via `yum`. For example, if you'd like to use `tcpdump`:
14 |
15 | ```sh
16 | [root@srv-3qy0p ~]# yum install tcpdump
17 | [root@srv-3qy0p ~]# tcpdump -i ens3
18 | tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
19 | listening on ens3, link-type EN10MB (Ethernet), capture size 65535 bytes
20 | ```
21 |
22 | ### Specify a Custom Docker Image
23 |
24 | Create a `.toolboxrc` in the user's home folder to use a specific Docker image:
25 |
26 | ```sh
27 | $ cat .toolboxrc
28 | TOOLBOX_DOCKER_IMAGE=index.example.com/debug
29 | TOOLBOX_USER=root
30 | $ /usr/bin/toolbox
31 | Pulling repository index.example.com/debug
32 | ...
33 | ```
34 |
35 | You can also specify this in cloud-config:
36 |
37 | ```
38 | #cloud-config
39 | write_files:
40 | - path: /home/core/.toolboxrc
41 | owner: core
42 | content: |
43 | TOOLBOX_DOCKER_IMAGE=index.example.com/debug
44 | TOOLBOX_DOCKER_TAG=v1
45 | TOOLBOX_USER=root
46 | ```
47 |
48 | ## SSH Directly Into A Toolbox
49 |
50 | Advanced users can SSH directly into a toolbox by setting up an `/etc/passwd` entry:
51 |
52 | ```sh
53 | useradd bob -m -p '*' -s /usr/bin/toolbox -U -G sudo,docker
54 | ```
55 |
56 | To test, SSH as bob:
57 |
58 | ```sh
59 | ssh bob@hostname.example.com
60 |
61 | ______ ____ _____
62 | / ____/___ ________ / __ \/ ___/
63 | / / / __ \/ ___/ _ \/ / / /\__ \
64 | / /___/ /_/ / / / __/ /_/ /___/ /
65 | \____/\____/_/ \___/\____//____/
66 | [root@srv-3qy0p ~]# yum install emacs
67 | [root@srv-3qy0p ~]# emacs /media/root/etc/systemd/system/docker.service
68 | ```
69 |
--------------------------------------------------------------------------------
/os/configuring-dns.md:
--------------------------------------------------------------------------------
1 | # DNS Configuration
2 |
3 | By default, DNS resolution on CoreOS is handled through `/etc/resolv.conf`, which is a symlink to `/run/systemd/resolve/resolv.conf`.
4 | This file is managed by [systemd-resolved][systemd-resolved].
5 | Normally, `systemd-resolved` gets DNS IP addresses from [systemd-networkd][systemd-networkd], either via DHCP or static configuration.
6 | DNS IP addresses can also be set via `systemd-resolved`'s [resolved.conf][resolved.conf].
7 | See [Network configuration with networkd](network-config-with-networkd.md) for more information on `systemd-networkd`.
8 |
9 | ## Using a local DNS cache
10 |
11 | `systemd-resolved` includes a caching DNS resolver.
12 | To use it for DNS resolution and caching, you must enable it via [nsswitch.conf][nsswitch.conf] by adding `resolv` to the `hosts` section.
13 |
14 | Here is an example cloud-config snippet to do that:
15 |
16 | ```yaml
17 | #cloud-config
18 | write_files:
19 | - path: /etc/nsswitch.conf
20 | permissions: 0644
21 | owner: root
22 | content: |
23 | # /etc/nsswitch.conf:
24 |
25 | passwd: files usrfiles
26 | shadow: files usrfiles
27 | group: files usrfiles
28 |
29 | hosts: files usrfiles resolv dns
30 | networks: files usrfiles dns
31 |
32 | services: files usrfiles
33 | protocols: files usrfiles
34 | rpc: files usrfiles
35 |
36 | ethers: files
37 | netmasks: files
38 | netgroup: files
39 | bootparams: files
40 | automount: files
41 | aliases: files
42 | ```
43 |
44 | Only nss-aware applications can take advantage of the `systemd-resolved` cache.
45 | Notably, this means that statically linked Go programs and programs running within Docker/rkt will use `/etc/resolv.conf` only, and will not use the `systemd-resolve` cache.
46 |
47 | [systemd-resolved]: http://www.freedesktop.org/software/systemd/man/systemd-resolved.service.html
48 | [systemd-networkd]: http://www.freedesktop.org/software/systemd/man/systemd-networkd.service.html
49 | [resolved.conf]: http://www.freedesktop.org/software/systemd/man/resolved.conf.html
50 | [nsswitch.conf]: http://man7.org/linux/man-pages/man5/nsswitch.conf.5.html
51 |
52 |
--------------------------------------------------------------------------------
/os/verify-images.md:
--------------------------------------------------------------------------------
1 | # Verify CoreOS Images with GPG
2 |
3 | CoreOS publishes new images for each release across a variety of platforms and hosting providers. Each channel has it's own set of images ([stable], [beta], [alpha]) that are posted to our storage site. Along with each image, a signature is generated from the [CoreOS Image Signing Key][signing-key] and posted.
4 |
5 | [signing-key]: {{site.baseurl}}/security/image-signing-key
6 | [stable]: http://stable.release.core-os.net/amd64-usr/current/
7 | [beta]: http://beta.release.core-os.net/amd64-usr/current/
8 | [alpha]: http://alpha.release.core-os.net/amd64-usr/current/
9 |
10 | After downloading your image, you should verify it with `gpg` tool. First, download the image signing key:
11 |
12 | ```sh
13 | curl -O https://coreos.com/security/image-signing-key/CoreOS_Image_Signing_Key.asc
14 | ```
15 |
16 | Next, import the public key and verify that the ID matches the website: [CoreOS Image Signing Key][signing-key]
17 |
18 | ```sh
19 | gpg --import --keyid-format LONG CoreOS_Image_Signing_Key.asc
20 | gpg: key 50E0885593D2DCB4: public key "CoreOS Buildbot (Offical Builds)
13 |
14 | ## Enable Building
15 |
16 | 
17 |
18 | - Click the configuration tab () and scroll down to the section entitled Dockerfile Build Support.
19 | - Check the "Enable Dockerfile Build" box
20 | - Click "Save Configuration Changes"
21 | - Restart the container (you will be prompted)
22 |
23 | ## Setup the Build Workers
24 |
25 | 
26 |
27 | One or more build workers will communicate with the main registry container to build new containers when triggered. The machines must have Docker installed and must not be used for any other work. The following procedure needs to be done every time a new worker needs to be
28 | added, but it can be automated fairly easily.
29 |
30 | ### Pull the Build Worker Image
31 |
32 | The build worker is currently in beta. To gain access to its repository, please contact support.
33 | Once given access, pull down the latest copy of the image just like any other:
34 |
35 | ```sh
36 | docker pull quay.io/coreos/registry-build-worker:latest
37 | ```
38 |
39 | ### Run the Build Worker image
40 |
41 | Run this container on each build worker. Since the worker will be orchestrating docker builds, we need to mount in the docker socket. This orchestration will use a large amount of CPU and need to manipulate the docker images on disk — we recommend that dedicated machines be used for this task.
42 |
43 | Use the environment variable `SERVER` to tell the worker how to communicate with the primary Enterprise Registry container. A websocket is used as a data channel, and it was configured when we changed the feature flag above.
44 |
45 | | Security | Websocket Address |
46 | |----------|-------------------|
47 | | Using SSL | ```wss://somehost.com``` |
48 | | Without SSL | ```ws://somehost.com``` |
49 |
50 | Here's what the full command looks like:
51 |
52 | ```sh
53 | docker run --restart on-failure -e SERVER=wss://myenterprise.host -v /var/run/docker.sock:/var/run/docker.sock quay.io/coreos/registry-build-worker:latest
54 | ```
55 |
56 | When the container starts, each build worker will auto-register with the Enterprise Registry and start building containers once a job triggered and it is assigned to a worker.
57 |
58 | ### Setup GitHub Build (optional)
59 |
60 | If your organization plans to have builds be conducted via pushes to GitHub (or GitHub Enterprise), please continue
61 | with the Setting up GitHub Build.
62 |
63 |
--------------------------------------------------------------------------------
/quay-enterprise/initial-setup.md:
--------------------------------------------------------------------------------
1 | # On-Premise Installation
2 |
3 | CoreOS Enterprise Registry requires three components to be running to begin the setup process:
4 |
5 | - A supported database (MySQL, Postgres)
6 | - A Redis instance (for real-time events)
7 | - The Enterprise Registry image
8 |
9 | **NOTE**: Please have the host and port of the database and the Redis instance ready.
10 |
11 |
12 | ## Preparing the Database
13 |
14 | A MySQL RDBMS or Postgres installation with an empty database is required, and a login with full access to said database. The schema will be created the first time the registry image is run. The database install can either be pre-existing or run on CoreOS via a [Docker container](mysql-container.md).
15 |
16 | ## Setting up Redis
17 |
18 | Redis stores data which must be accessed quickly but doesn’t necessarily require durability guarantees. If you have an existing Redis instance, make sure to accept incoming connections on port 6379 (or change the port in the setup process) and then feel free to skip this step.
19 |
20 | To run redis, simply pull and run the Quay.io Redis image:
21 |
22 | ```
23 | sudo docker pull quay.io/quay/redis
24 | sudo docker run -d -p 6379:6379 quay.io/quay/redis
25 | ```
26 |
27 | **NOTE**: This host will have to accept incoming connections on port 6379 from the hosts on which the registry will run.
28 |
29 | ## Downloading the Enterprise Registry image
30 |
31 | After signing up you will receive a `.dockercfg` file containing your credentials to the `quay.io/coreos/registry` repository.
32 | Save this file to your CoreOS machine in `/home/core/.dockercfg` and `/root/.dockercfg`.
33 | You should now be able to execute `docker pull quay.io/coreos/registry` to download the container.
34 |
35 | ## Setting up the Directories
36 |
37 | CoreOS Enterprise registry requires a storage directory and a configuration directory:
38 |
39 | ```
40 | mkdir storage
41 | mkdir config
42 | ```
43 |
44 | ## Setting up and running the Registry
45 |
46 | Run the following command, replacing `/local/path/to/the/config/directory` and `/local/path/to/the/storage/directory` with the absolute
47 | paths to the directories created above:
48 |
49 | ```
50 | sudo docker run --restart=always -p 443:443 -p 80:80 --privileged=true -v /local/path/to/the/config/directory:/conf/stack -v /local/path/to/the/storage/directory:/datastorage -d quay.io/coreos/registry
51 | ```
52 |
53 | 
54 |
55 | Once started, visit: http://yourhost/setup, wait for the page to load (it may take a minute or two) and follow instructions there to setup the enterprise registry.
56 |
57 | **NOTE**: The Enterprise Registry will restart itself a few times during this setup process. If the container does not automatically come
58 | back up, simply run the command above again.
59 |
60 | 
61 |
62 |
63 | ## Verifying the Registry status
64 |
65 | Visit the `/health/endtoend` endpoint on the registry hostname and verify that the `code` is `200` and `is_testing` is `false`.
66 |
67 |
68 | ## Logging in
69 |
70 | ### If using database authentication:
71 |
72 | Once the Enterprise Registry is running, new users can be created by clicking the `Sign Up` button. If e-mail is enabled, the sign up process will require an e-mail confirmation step, after which repositories, organizations and teams can be setup by the user.
73 |
74 |
75 | ### If using LDAP authentication:
76 |
77 | Users should be able to login to the Enterprise Registry directly with their LDAP username and password.
78 |
79 |
--------------------------------------------------------------------------------
/os/booting-with-iso.md:
--------------------------------------------------------------------------------
1 | # Booting CoreOS from an ISO
2 |
3 | The latest CoreOS ISOs can be downloaded from the image storage site:
4 |
5 |
6 |
11 |
41 |
42 | ## Known Limitations
43 |
44 | 1. The best strategy for providing [cloud-config]({{site.baseurl}}/docs/cluster-management/setup/cloudinit-cloud-config) is via [config-drive]({{site.baseurl}}/docs/cluster-management/setup/cloudinit-config-drive).
45 |
46 | ## Install to Disk
47 |
48 | The most common use-case for this ISO is to install CoreOS to disk. You can [find those instructions here]({{site.baseurl}}/docs/running-coreos/bare-metal/installing-to-disk).
49 |
50 | ## Bypass Authentication
51 |
52 | If you need to bypass authentication in order to install, the kernel option `coreos.autologin` allows you to drop directly to a shell on a given console without prompting for a password. Useful for troubleshooting but use with caution.
53 |
54 | For any console that doesn't normally get a login prompt by default be sure to combine with the `console` option:
55 |
56 | ```
57 | console=tty0 console=ttyS0 coreos.autologin=tty1 coreos.autologin=ttyS0
58 | ```
59 |
60 | Without any argument it enables access on all consoles. Note that for the VGA console the login prompts are on virtual terminals (`tty1`, `tty2`, etc), not the VGA console itself (`tty0`).
61 |
--------------------------------------------------------------------------------
/golang/README.md:
--------------------------------------------------------------------------------
1 | # Go at CoreOS
2 |
3 | We use Go (golang) a lot at CoreOS, and we’ve built up a lot of internal knowledge about how best to develop Go projects.
4 |
5 | This document serves as a best practices and style guide for how to work on new and existing CoreOS projects written in Go.
6 |
7 | ## Version
8 |
9 | - Wherever possible, use the [latest official release][go-dl] of go
10 | - Any software shipped in the CoreOS image should be developed against the [version shipped in the CoreOS image](https://github.com/coreos/portage-stable/tree/master/dev-lang/go)
11 |
12 | [go-dl]: https://golang.org/dl/
13 |
14 | ## Style
15 |
16 | Go style at CoreOS essentially just means following the upstream conventions:
17 | - [Effective Go][effectivego]
18 | - [CodeReviewComments][codereview]
19 | - [Godoc][godoc]
20 |
21 | It's recommended to set a save hook in your editor of choice that runs `goimports` against your code.
22 |
23 | [effectivego]: https://golang.org/doc/effective_go.html
24 | [codereview]: https://github.com/golang/go/wiki/CodeReviewComments
25 | [godoc]: http://blog.golang.org/godoc-documenting-go-code
26 |
27 | ## Tests
28 |
29 | - Always run [goimports][goimports] (which transitively calls `gofmt`) and `go vet`
30 | - Use [table-driven tests][table-driven] wherever possible ([example][table-driven-example])
31 | - Use [travis][travis] to run unit/integration tests against the project repository ([example][travis-example])
32 | - Use [SemaphoreCI][semaphore] to run functional tests where possible ([example][semaphore-example])
33 | - Use [GoDebug][godebug] `pretty.Compare` to compare objects (structs, maps, slices, etc.) ([example] [godebug-compare-example])
34 |
35 | [godebug]: https://github.com/kylelemons/godebug/
36 | [godebug-compare-example]: https://github.com/coreos-inc/auth/blob/master/functional/db_test.go#L107
37 | [goimports]: https://github.com/bradfitz/goimports
38 | [table-driven]: https://github.com/golang/go/wiki/TableDrivenTests
39 | [table-driven-example]: https://github.com/coreos/etcd/blob/35fddbc5d01f5e88bbc590c60f0b5e3ea8fa141b/raft/raft_paper_test.go#L186
40 | [travis]: https://travis-ci.org/
41 | [travis-example]: https://github.com/coreos/fleet/blob/master/.travis.yml
42 | [semaphore]: https://semaphoreci.com/
43 | [semaphore-example]: https://github.com/coreos/rkt/blob/master/tests/README.md
44 |
45 | ## Dependencies
46 |
47 | - Carefully consider adding dependencies to your project: Do you really need it?
48 | - Manage third-party dependencies with [godep][godep-guide]
49 |
50 | [godep-guide]: golang/godep.md
51 |
52 | ## Shared Code
53 |
54 | Idiomatic golang generally eschews creating generic utility packages in favour of implementing the necessary code as locally as possible to its use case.
55 | In cases where generic, utility code makes sense, though, move it to `github.com/coreos/pkg`.
56 | Use this repository as a first port of call when the need for generic code seems to arise.
57 |
58 | ## Docker
59 |
60 | When creating Docker images from Go projects, use a combination of a `.godir` file and the `golang:onbuild` base image to produce the most simple Dockerfile for a Go project.
61 | The `.godir` file must contain the import path of the package being written (i.e. etcd's .godir contains "github.com/coreos/etcd").
62 |
63 | ## Logging
64 |
65 | When in need of more sophisticated logging than the [stdlib log package][stdlib-log] provides, use the shared [CoreOS Log package][capnslog] (aka `capnslog`)
66 |
67 | [stdlib-log]: https://golang.org/pkg/log
68 | [capnslog]: https://github.com/coreos/pkg/tree/master/capnslog
69 |
70 | ## CLI
71 |
72 | In anything other than the most basic CLI cases (i.e. where the [stdlib flag package][stdlib-flag] suffices), use [Cobra][cobra] to construct command-line tools.
73 |
74 | [stdlib-flag]: https://golang.org/pkg/log
75 | [cobra]: https://github.com/spf13/cobra
76 |
77 | ## Development Tools
78 |
79 | - Use `gvm` to manage multiple versions of golang and multiple GOPATHs
80 |
--------------------------------------------------------------------------------
/os/overview-of-systemctl.md:
--------------------------------------------------------------------------------
1 | # Overview of systemctl
2 |
3 | `systemctl` is your interface to systemd, the init system used in CoreOS. All processes on a single machine are started and managed by systemd, including your Docker containers. You can learn more in our [Getting Started with systemd]({{site.baseurl}}/docs/launching-containers/launching/getting-started-with-systemd) guide. Let's explore a few helpful `systemctl` commands. You must run all of these commands locally on the CoreOS machine:
4 |
5 | ## Find the Status of a Container
6 |
7 | The first step to troubleshooting with `systemctl` is to find the status of the item in question. If you have multiple `Exec` commands in your service file, you can see which one of them is failing and view the exit code. Here's a failing service that starts a private Docker registry in a container:
8 |
9 | ```sh
10 | $ sudo systemctl status custom-registry.service
11 |
12 | custom-registry.service - Custom Registry Service
13 | Loaded: loaded (/media/state/units/custom-registry.service; enabled-runtime)
14 | Active: failed (Result: exit-code) since Sun 2013-12-22 12:40:11 UTC; 35s ago
15 | Process: 10191 ExecStopPost=/usr/bin/etcdctl delete /registry (code=exited, status=0/SUCCESS)
16 | Process: 10172 ExecStartPost=/usr/bin/etcdctl set /registry index.domain.com:5000 (code=exited, status=0/SUCCESS)
17 | Process: 10171 ExecStart=/usr/bin/docker run -rm -p 5555:5000 54.202.26.87:5000/registry /bin/sh /root/boot.sh (code=exited, status=1/FAILURE)
18 | Main PID: 10171 (code=exited, status=1/FAILURE)
19 | CGroup: /system.slice/custom-registry.service
20 |
21 | Dec 22 12:40:01 localhost etcdctl[10172]: index.domain.com:5000
22 | Dec 22 12:40:01 localhost systemd[1]: Started Custom Registry Service.
23 | Dec 22 12:40:01 localhost docker[10171]: Unable to find image '54.202.26.87:5000/registry' (tag: latest) locally
24 | Dec 22 12:40:11 localhost docker[10171]: 2013/12/22 12:40:11 Invalid Registry endpoint: Get http://index2.domain.com:5000/v1/_ping: dial tcp 54.204.26.2...o timeout
25 | Dec 22 12:40:11 localhost systemd[1]: custom-registry.service: main process exited, code=exited, status=1/FAILURE
26 | Dec 22 12:40:11 localhost etcdctl[10191]: index.domain.com:5000
27 | Dec 22 12:40:11 localhost systemd[1]: Unit custom-registry.service entered failed state.
28 | Hint: Some lines were ellipsized, use -l to show in full.
29 | ```
30 |
31 | You can see that `Process: 10171 ExecStart=/usr/bin/docker` exited with `status=1/FAILURE` and the log states that the index that we attempted to launch the container from, `54.202.26.87` wasn't valid, so the container image couldn't be downloaded.
32 |
33 | ## List Status of All Units
34 |
35 | Listing all of the processes running on the box is too much information, but you can pipe the output into grep to find the services you're looking for. Here's all service files and their status:
36 |
37 | ```sh
38 | sudo systemctl list-units | grep .service
39 | ```
40 |
41 | ## Start or Stop a Service
42 |
43 | ```sh
44 | sudo systemctl start apache.service
45 | ```
46 |
47 | ```sh
48 | sudo systemctl stop apache.service
49 | ```
50 |
51 | ## Kill a Service
52 |
53 | This will stop the process immediately:
54 |
55 | ```sh
56 | sudo systemctl kill apache.service
57 | ```
58 |
59 | ## Restart a Service
60 |
61 | Restarting a service is as easy as:
62 |
63 | ```sh
64 | sudo systemctl restart apache.service
65 | ```
66 |
67 | If you're restarting a service after you changed its service file, you will need to reload all of the service files before your changes take effect:
68 |
69 | ```sh
70 | sudo systemctl daemon-reload
71 | ```
72 |
73 | #### More Information
74 | Getting Started with systemd
75 | systemd.service Docs
76 | systemd.unit Docs
77 |
--------------------------------------------------------------------------------
/os/booting-on-cloudstack.md:
--------------------------------------------------------------------------------
1 | # Running CoreOS on CloudStack
2 |
3 | This guide explains how to deploy CoreOS with CloudStack. These instructions will walk you through downloading CoreOS image and running an instance from it.
4 | This document assumes that CloudStack is already installed. Please refer Install Guide for CloudStack installation steps.
5 |
6 |
7 | ## Register the CoreOS image (Template)
8 |
9 | After logging in to CloudStack UI, to upload a template:
10 |
11 |
12 |
40 |
13 |
19 |
21 |
14 |
16 | Download Alpha ISO
17 | Browse Storage Site
18 | The alpha channel closely tracks master and is released to frequently. The newest versions of Docker, etcd and fleet will be available for testing. Current version is CoreOS {{site.alpha-channel}}.
15 |19 |
All of the files necessary to verify the image can be found on the storage site.
20 |
22 |
28 |
30 |
23 |
25 | Download Beta ISO
26 | Browse Storage Site
27 | The beta channel consists of promoted alpha releases. Current version is CoreOS {{site.beta-channel}}.
24 |28 |
All of the files necessary to verify the image can be found on the storage site.
29 |
31 |
37 |
39 |
32 |
34 | Download Stable ISO
35 | Browse Storage Site
36 | The Stable channel should be used by production clusters. Versions of CoreOS are battle-tested within the Beta and Alpha channels before being promoted. Current version is CoreOS {{site.stable-channel}}.
33 |37 |
All of the files necessary to verify the image can be found on the storage site.
38 |-
12 |
In the left navigation bar, click Templates.
13 |
14 | Click Register Template.
15 |
16 | Provide the following:
17 |-
18 |
Name and Description. These will be shown in the UI, so choose 19 | something descriptive.
20 |
21 | URL. The Management Server will download the file from the 22 | specified URL, such as http://dl.openvm.eu/cloudstack/coreos/x86_64/coreos_production_cloudstack_image-kvm.qcow2.bz2.
23 |
24 | Zone. Choose the zone where you want the template to be 25 | available, or All Zones to make it available throughout 26 | CloudStack.
27 |
28 | OS Type: This helps CloudStack and the hypervisor perform 29 | certain operations and make assumptions that improve the 30 | performance of the guest.
31 |
32 | Hypervisor: The supported hypervisors are listed. Select the 33 | desired one.
34 |
35 | Format. The format of the template upload file, such as VHD or 36 | OVA.
37 |
38 | Extractable. Choose Yes if the template is available for 39 | extraction. If this option is selected, end users can download a 40 | full image of a template.
41 |
42 | Public. Choose Yes to make this template accessible to all 43 | users of this CloudStack installation. The template will appear in 44 | the Community Templates list. See “Private and 45 | Public Templates”.
46 |
47 | Featured. Choose Yes if you would like this template to be 48 | more prominent for users to select. The template will appear in 49 | the Featured Templates list. Only an administrator can make a 50 | template Featured.
51 |
52 |
54 |
To create a VM from a template:
66 |-
67 |
Log in to the CloudStack UI as an administrator or user.
68 |
69 | In the left navigation bar, click Instances.
70 |
71 | Click Add Instance.
72 |
73 | Select a zone.
74 |
75 | Select the CoreOS template registered in the previous step. 76 |
77 | Click Submit and your VM will be created and started.
78 |
79 |
44 |
49 |
67 |
68 | ### サーバーの追加
69 |
70 | さらにクラスタにサーバーを追加するには、同じcloud-config、適当なファイアウォールグループで立ち上げるだけです。
71 |
72 | ## SSH
73 |
74 | 下記のコマンドでログインできます。
75 |
76 | ```sh
77 | ssh core@
50 |
66 |
51 |
55 | AlphaチャンネルはMasterをぴったりと追っていて、頻繁にリリースされます。テストのために最新のDocker、etcd、fleetの利用が可能です。現在のバージョンはCoreOS {{site.alpha-channel}}です。
52 |$ZONE, $TYPE, $FW_ID and $SSH_KEY_IDを指定し、ニフティクラウドCLIで立ち上げます。
nifty-run-instances $(nifty-describe-images --delimiter ',' --image-name "CoreOS Alpha {{site.alpha-channel}}" | awk -F',' '{print $2}') --key $SSH_KEY_ID --availability-zone $ZONE --instance-type $TYPE -g $FW_ID -f cloud-config.yml -q POST
54 |
56 |
60 | BetaチャンネルはAlphaリリースが昇格されたものです。現在のバージョンはCoreOS {{site.beta-channel}}です。
57 |$ZONE, $TYPE, $FW_ID and $SSH_KEY_IDを指定し、ニフティクラウドCLIで立ち上げます。
nifty-run-instances $(nifty-describe-images --delimiter ',' --image-name "CoreOS Beta {{site.beta-channel}}" | awk -F',' '{print $2}') --key $SSH_KEY_ID --availability-zone $ZONE --instance-type $TYPE -g $FW_ID -f cloud-config.yml -q POST
59 |
61 |
65 | プロダクションクラスターではStableチャンネルを使用すべきです。CoreOSの各バージョンは昇格されるまでにBetaとAlphaチャンネルで検証済みです。現在のバージョンはCoreOS {{site.stable-channel}}です。
62 |$ZONE, $TYPE, $FW_ID and $SSH_KEY_IDを指定し、ニフティクラウドCLIで立ち上げます。
nifty-run-instances $(nifty-describe-images --delimiter ',' --image-name "CoreOS Stable {{site.stable-channel}}" | awk -F',' '{print $2}') --key $SSH_KEY_ID --availability-zone $ZONE --instance-type $TYPE -g $FW_ID -f cloud-config.yml -q POST
64 |
44 |
49 |
67 |
68 | ### Adding More Machines
69 |
70 | To add more instances to the cluster, just launch more with the same cloud-config and the appropriate firewall group.
71 |
72 | ## SSH
73 |
74 | You can log in your CoreOS instances using:
75 |
76 | ```sh
77 | ssh core@
50 |
66 |
51 |
55 | The alpha channel closely tracks master and is released to frequently. The newest versions of Docker, etcd and fleet will be available for testing. Current version is CoreOS {{site.alpha-channel}}.
52 |Launch via NIFTY Cloud CLI by specifying $ZONE, $TYPE, $FW_ID and $SSH_KEY_ID:
nifty-run-instances $(nifty-describe-images --delimiter ',' --image-name "CoreOS Alpha {{site.alpha-channel}}" | awk -F',' '{print $2}') --key $SSH_KEY_ID --availability-zone $ZONE --instance-type $TYPE -g $FW_ID -f cloud-config.yml -q POST
54 |
56 |
60 | The beta channel consists of promoted alpha releases. Current version is CoreOS {{site.beta-channel}}.
57 |Launch via NIFTY Cloud CLI by specifying $ZONE, $TYPE, $FW_ID and $SSH_KEY_ID:
nifty-run-instances $(nifty-describe-images --delimiter ',' --image-name "CoreOS Beta {{site.beta-channel}}" | awk -F',' '{print $2}') --key $SSH_KEY_ID --availability-zone $ZONE --instance-type $TYPE -g $FW_ID -f cloud-config.yml -q POST
59 |
61 |
65 | The Stable channel should be used by production clusters. Versions of CoreOS are battle-tested within the Beta and Alpha channels before being promoted. Current version is CoreOS {{site.stable-channel}}.
62 |Launch via NIFTY Cloud CLI by specifying $ZONE, $TYPE, $FW_ID and $SSH_KEY_ID:
nifty-run-instances $(nifty-describe-images --delimiter ',' --image-name "CoreOS Stable {{site.stable-channel}}" | awk -F',' '{print $2}') --key $SSH_KEY_ID --availability-zone $ZONE --instance-type $TYPE -g $FW_ID -f cloud-config.yml -q POST
64 |
33 |
38 |
62 |
63 | After the script is finished successfully, will be available at the specified
64 | destination location the CoreOS image or at current location. The file name will
65 | be something like:
66 |
67 | ```
68 | coreos_production_stable.vdi
69 | ```
70 |
71 | ## Creating a Config-Drive
72 |
73 | Cloud-config can be specified by attaching a
74 | [config-drive]({{site.baseurl}}/docs/cluster-management/setup/cloudinit-config-drive/)
75 | with the label `config-2`. This is commonly done through whatever interface
76 | allows for attaching CD-ROMs or new drives.
77 |
78 | Note that the config-drive standard was originally an OpenStack feature, which
79 | is why you'll see strings containing `openstack`. This filepath needs to be
80 | retained, although CoreOS supports config-drive on all platforms.
81 |
82 | For more information on customization that can be done with cloud-config, head
83 | on over to the
84 | [cloud-config guide]({{site.baseurl}}/docs/cluster-management/setup/cloudinit-cloud-config/).
85 |
86 | You need a config-drive to configure at least one SSH key to access the virtual
87 | machine. If you are in hurry you can create a basic config-drive with following
88 | steps.
89 |
90 | ```sh
91 | wget https://raw.github.com/coreos/scripts/master/contrib/create-basic-configdrive
92 | chmod +x create-basic-configdrive
93 | ./create-basic-configdrive -H my_vm01 -S ~/.ssh/id_rsa.pub
94 | ```
95 |
96 | Will be created an ISO file named `my_vm01.iso` that will configure a virtual
97 | machine to accept your SSH key and set its name to my_vm01.
98 |
99 | ## Deploying a New Virtual Machine on VirtualBox
100 |
101 | I recommend to use the built image as base image. Therefore you should clone the
102 | image for each new virtual machine and set it to desired size.
103 |
104 | ```sh
105 | VBoxManage clonehd coreos_production_stable.vdi my_vm01.vdi
106 | # Resize virtual disk to 10 GB
107 | VBoxManage modifyhd my_vm01.vdi --resize 10240
108 | ```
109 |
110 | At boot time the CoreOS will detect that the volume size changed and will resize
111 | the filesystem according.
112 |
113 | Open VirtualBox Manager and go to menu Machine > New. Type the desired machine
114 | name and choose 'Linux' type and 'Linux 2.6 / 3.x (64 bit)' version.
115 |
116 | Next, choose the desired memory size. I recommend 1 GB for smooth experience.
117 |
118 | Next, choose 'Use an existing virtual hard drive file' and find the new cloned
119 | image.
120 |
121 | Click on 'Create' button to create the virtual machine.
122 |
123 | Next, go to settings from the created virtual machine. Then click on Storage tab
124 | and load the created config-drive into CD/DVD drive.
125 |
126 | Click on 'OK' button and the virtual machine will be ready to be started.
127 |
128 | ## Logging In
129 |
130 | Networking can take a bit of time to come up under VirtualBox and you will need
131 | to know the IP in order to connect to it. Press enter a few times at the login
132 | prompt and you see an IP address pop up.
133 |
134 | Now you can login using your private SSH key.
135 |
136 | ```sh
137 | ssh core@192.168.56.101
138 | ```
139 |
140 | ## Using CoreOS
141 |
142 | Now that you have a machine booted it is time to play around.
143 | Check out the [CoreOS Quickstart]({{site.baseurl}}/docs/quickstart) guide or dig
144 | into [more specific topics]({{site.baseurl}}/docs).
145 |
--------------------------------------------------------------------------------
/os/customizing-sshd.md:
--------------------------------------------------------------------------------
1 | # Customizing the SSH Daemon
2 |
3 | CoreOS defaults to running an OpenSSH daemon using `systemd` socket activation -- when a client connects to the port configured for SSH, `sshd` is started on the fly for that client using a `systemd` unit derived automatically from a template. In some cases you may want to customize this daemon's authentication methods or other configuration. This guide will show you how to do that at build time using `cloud-config`, and after building by modifying the `systemd` unit file.
4 |
5 | As a practical example, when a client fails to connect by not completing the TCP connection (e.g. because the "client" is actually a TCP port scanner), the MOTD may report failures of `systemd` units (which will be named by the source IP that failed to connect) next time you log in to the CoreOS host. These failures are not themselves harmful, but it is a good general practice to change how SSH listens, either by changing the IP address `sshd` listens to from the default setting (which listens on all configured interfaces), changing the default port, or both.
6 |
7 | ## Customizing sshd with Cloud-Config
8 |
9 | In this example we will disable logins for the `root` user, only allow login for the `core` user and disable password based authentication. For more details on what sections can be added to `/etc/ssh/sshd_config` see the [OpenSSH manual][openssh-manual].
10 |
11 | [openssh-manual]: http://www.openssh.com/cgi-bin/man.cgi?query=sshd_config
12 |
13 | ```yaml
14 | #cloud-config
15 |
16 | write_files:
17 | - path: /etc/ssh/sshd_config
18 | permissions: 0600
19 | owner: root:root
20 | content: |
21 | # Use most defaults for sshd configuration.
22 | UsePrivilegeSeparation sandbox
23 | Subsystem sftp internal-sftp
24 |
25 | PermitRootLogin no
26 | AllowUsers core
27 | PasswordAuthentication no
28 | ChallengeResponseAuthentication no
29 | ```
30 |
31 | ### Changing the sshd Port
32 |
33 | CoreOS ships with socket-activated SSH by default. The configuration for this can be found at `/usr/lib/systemd/system/sshd.socket`. We're going to override some of the default settings for this in the cloud-config provided at boot:
34 |
35 | ```yaml
36 | #cloud-config
37 |
38 | coreos:
39 | units:
40 | - name: sshd.socket
41 | command: restart
42 | content: |
43 | [Socket]
44 | ListenStream=2222
45 | Accept=yes
46 | ```
47 |
48 | `sshd` will now listen only on port 2222 on all interfaces when the system is built.
49 |
50 | ### Further Reading
51 |
52 | Read the [full cloud-config]({{site.baseurl}}/docs/cluster-management/setup/cloudinit-cloud-config/) guide to install users and more.
53 |
54 | ## Customizing sshd after build
55 |
56 | If you have CoreOS hosts that need configuration changes made after build, log into the CoreOS host as the core user, then:
57 |
58 | ```
59 | $ sudo cp /usr/lib/systemd/system/sshd.socket /etc/systemd/system/sshd.socket
60 | ```
61 |
62 | This gives you a copy of the sshd.socket unit that will override the one supplied by CoreOS -- when you make changes to it and `systemd` re-reads its configuration, those changes will be implemented.
63 |
64 | ### Changing the sshd port
65 |
66 | To change how sshd listens, change or add the relevant lines in the `[Socket]` section of `/etc/systemd/system/sshd.socket` (leaving options not specified here intact).
67 |
68 | To change just the listened-to port (in this example, port 2222):
69 |
70 | ```
71 | [Socket]
72 | ListenStream=2222
73 | ```
74 |
75 | To change the listened-to IP address (in this example, 10.20.30.40):
76 |
77 | ```
78 | [Socket]
79 | ListenStream=10.20.30.40:22
80 | FreeBind=true
81 | ```
82 |
83 | You can specify both an IP and an alternate port in a single ListenStream line; additionally, IPv6 address bindings would be specified as, for example, `[2001:db8::7]:22` Note two things: first, while a specific IP address is optional, you must always specify the port, even if it is the default SSH port. Second, the `FreeBind` option is used allow the socket to be bound on addresses that are not actually configured on an interface yet, to avoid issues caused by delays in IP configuration at boot. (This is not needed if you are not specifying an address.)
84 |
85 | Multiple ListenStream lines can be specified, in which case `sshd` will listen on all the specified sockets:
86 |
87 | ```
88 | [Socket]
89 | ListenStream=2222
90 | ListenStream=10.20.30.40:2223
91 | FreeBind=true
92 | ```
93 |
94 | `sshd` will now listen to port 2222 on all configured addresses, and port 2223 on 10.20.30.40.
95 |
96 | Taking the last example, the complete contents of `/etc/systemd/system/sshd.socket` would now be:
97 |
98 | ```
99 | [Unit]
100 | Description=OpenSSH Server Socket
101 | Conflicts=sshd.service
102 |
103 | [Socket]
104 | ListenStream=2222
105 | ListenStream=10.20.30.40:2223
106 | FreeBind=true
107 | Accept=yes
108 |
109 | [Install]
110 | WantedBy=sockets.target
111 | ```
112 |
113 | ### Activating changes
114 |
115 | After the edited file is written to disk, you can activate it without rebooting with:
116 |
117 | ```
118 | $ sudo systemctl daemon-reload
119 | ```
120 |
121 | We now see that systemd is listening on the new sockets:
122 |
123 | ```
124 | $ systemctl status sshd.socket
125 | ● sshd.socket - OpenSSH Server Socket
126 | Loaded: loaded (/etc/systemd/system/sshd.socket; disabled; vendor preset: disabled)
127 | Active: active (listening) since Wed 2015-10-14 21:04:31 UTC; 2min 45s ago
128 | Listen: [::]:2222 (Stream)
129 | 10.20.30.40:2223 (Stream)
130 | Accepted: 1; Connected: 0
131 | ...
132 | ```
133 |
134 | And if we attempt to connect to port 22 on our public IP, the connection is rejected, but port 2222 works:
135 |
136 | ```
137 | $ ssh core@[public IP]
138 | ssh: connect to host [public IP] port 22: Connection refused
139 | $ ssh -p 2222 core@[public IP]
140 | Enter passphrase for key '/home/user/.ssh/id_rsa':
141 | ```
142 |
143 | ### Further reading on systemd units
144 |
145 | For more information about configuring CoreOS hosts with `systemd`, see [Getting Started with systemd]({{site.baseurl}}/docs/launching-containers/launching/getting-started-with-systemd/).
146 |
--------------------------------------------------------------------------------
/os/sdk-tips-and-tricks.md:
--------------------------------------------------------------------------------
1 | # Tips and Tricks
2 |
3 | ## Finding all open pull requests and issues
4 |
5 | - [CoreOS Issues][issues]
6 | - [CoreOS Pull Requests][pullrequests]
7 |
8 | [issues]: https://github.com/organizations/coreos/dashboard/issues/
9 | [pullrequests]: https://github.com/organizations/coreos/dashboard/pulls/
10 |
11 | ## Searching all repo code
12 |
13 | Using `repo forall` you can search across all of the Git repos at once:
14 |
15 | ```sh
16 | repo forall -c git grep 'CONFIG_EXTRA_FIRMWARE_DIR'
17 | ```
18 |
19 | ## Add new upstream package
20 |
21 | Before making modifications use `repo start` to create a new branch for the changes.
22 |
23 | To add a new package fetch the Gentoo package from upstream and add the package as a dependency of coreos-base/coreos
24 |
25 | If any files in the upstream package will be changed the package can be fetched from upstream Gentoo directly into `src/third_party/coreos-overlay` it may be necessary to create any missing directories in the path too.
26 |
27 | e.g.
28 |
29 | ```sh
30 | ~/trunk/src/third_party/coreos-overlay $ mkdir -p sys-block/open-iscsi && rsync -av rsync://rsync.gentoo.org/gentoo-portage/sys-block/open-iscsi/ sys-block/open-iscsi/
31 | ```
32 |
33 | The tailing / prevents rsync from creating the directory for the package so you don't end up with `sys-block/open-iscsi/open-iscsi`
34 | Remember to add the new files to git.
35 |
36 | If the new package does not need to be modified the package should be placed in `src/third_party/portage-stable`
37 |
38 | You can use `scripts/update_ebuilds` to fetch packages into `src/third_party/portage-stable` and add the files to git.
39 | You should specify the category and the packagename.
40 | e.g.
41 | `./update_ebuilds sys-block/open-iscsi`
42 |
43 | If the package needs to be modified it must be moved out of `src/third_party/portage-stable` to `src/third_party/coreos-overlay`
44 |
45 | To include the new package as a dependency of coreos add the package to the end of the RDEPEND environment variable in `coreos-base/coreos/coreos-0.0.1.ebuild` then increment the revision of coreos by renaming the softlink `git mv coreos-base/coreos/coreos-0.0.1-r237.ebuild coreos-base/coreos/coreos-0.0.1-r238.ebuild`
46 |
47 | The new package will now be built and installed as part of the normal build flow.
48 |
49 | Add and commit the changes to git using AngularJS format. See [CONTRIBUTING.md]
50 | [CONTRIBUTING.md]: https://github.com/coreos/etcd/blob/master/CONTRIBUTING.md
51 |
52 | Push the changes to your GitHub fork and create a pull request.
53 |
54 | ### Ebuild Tips
55 |
56 | - Manually merge a package to the chroot to test build `emerge-amd64-usr packagename`
57 | - Manually unmerge a package `emerge-amd64-usr --unmerge packagename`
58 | - Remove a binary package from the cache `sudo rm /build/amd64-usr/packages/catagory/packagename-version.tbz2`
59 | - recreate the chroot prior to a clean rebuild `./chromite/bin/cros_sdk -r`
60 | - it may be necessary to comment out kernel source checks from the ebuild if the build fails -- as coreos does not yet provide visibility of the configured kernel source at build time -- usually this is not a problem but may lead to warning messages
61 | - Chromium OS [Portage Build FAQ]
62 | - [Gentoo Development Guide]
63 |
64 |
65 | [Portage Build FAQ]: http://www.chromium.org/chromium-os/how-tos-and-troubleshooting/portage-build-faq
66 | [Gentoo Development Guide]: http://devmanual.gentoo.org/
67 |
68 | ## Caching git https passwords
69 |
70 | Note: You need git 1.7.10 or newer to use the credential helper
71 |
72 | Turn on the credential helper and git will save your password in memory
73 | for some time:
74 |
75 | ```sh
76 | git config --global credential.helper cache
77 | ```
78 |
79 | Why doesn't CoreOS use SSH in the git remotes? Because, we can't do
80 | anonymous clones from GitHub with an SSH URL. In the future we will fix
81 | this.
82 |
83 | ### Base system dependency graph
84 |
85 | Get a view into what the base system will contain and why it will contain those
86 | things with the emerge tree view:
87 |
88 | ```sh
89 | emerge-amd64-usr --emptytree -p -v --tree coreos-base/coreos-dev
90 | ```
91 |
92 | ## SSH Config
93 |
94 | You will be booting lots of VMs with on the fly ssh key generation. Add
95 | this in your `$HOME/.ssh/config` to stop the annoying fingerprint warnings.
96 |
97 | ```ini
98 | Host 127.0.0.1
99 | StrictHostKeyChecking no
100 | UserKnownHostsFile /dev/null
101 | User core
102 | LogLevel QUIET
103 | ```
104 |
105 | ## Hide loop devices from desktop environments
106 |
107 | By default desktop environments will diligently display any mounted devices
108 | including loop devices used to construct CoreOS disk images. If the daemon
109 | responsible for this happens to be ``udisks`` then you can disable this
110 | behavior with the following udev rule:
111 |
112 | ```sh
113 | echo 'SUBSYSTEM=="block", KERNEL=="ram*|loop*", ENV{UDISKS_PRESENTATION_HIDE}="1", ENV{UDISKS_PRESENTATION_NOPOLICY}="1"' > /etc/udev/rules.d/85-hide-loop.rules
114 | udevadm control --reload
115 | ```
116 |
117 | ## Leaving developer mode
118 |
119 | Some daemons act differently in "dev mode". For example update_engine refuses
120 | to auto-update or connect to HTTPS URLs. If you need to test something out of
121 | dev_mode on a vm you can do the following:
122 |
123 | ```
124 | mv /root/.dev_mode{,.old}
125 | ```
126 |
127 | If you want to permanently leave you can run the following:
128 |
129 | ```
130 | crossystem disable_dev_request=1; reboot
131 | ```
132 |
133 | ## Known Issues
134 |
135 | ### build\_packages fails on coreos-base
136 |
137 | Sometimes coreos-dev or coreos builds will fail in `build_packages` with a
138 | backtrace pointing to `epoll`. This hasn't been tracked down but running
139 | `build_packages` again should fix it. The error looks something like this:
140 |
141 | ```
142 | Packages failed:
143 | coreos-base/coreos-dev-0.1.0-r63
144 | coreos-base/coreos-0.0.1-r187
145 | ```
146 |
147 | ## Constants and IDs
148 |
149 | ### CoreOS App ID
150 |
151 | This UUID is used to identify CoreOS to the update service and elsewhere.
152 |
153 | ```
154 | e96281a6-d1af-4bde-9a0a-97b76e56dc57
155 | ```
156 |
157 | ### GPT UUID Types
158 |
159 | - CoreOS Root: 5dfbf5f4-2848-4bac-aa5e-0d9a20b745a6
160 | - CoreOS Reserved: c95dc21a-df0e-4340-8d7b-26cbfa9a03e0
161 |
--------------------------------------------------------------------------------
/os/booting-on-vultr.md:
--------------------------------------------------------------------------------
1 | # Running CoreOS on a Vultr VPS
2 |
3 | These instructions will walk you through running a single CoreOS node. This guide assumes:
4 |
5 | * You have an account at [Vultr.com](https://www.vultr.com).
6 | * You have a public + private key combination generated. Here's a helpful guide if you need to generate these keys: [How to set up SSH keys](https://help.github.com/articles/generating-ssh-keys).
7 |
8 | The simplest option to boot up CoreOS is to select the "CoreOS Stable" operating system from Vultr's default offerings. However, most deployments require a custom `cloud-config`, which can only be achieved in Vultr with an iPXE script. The remainder of this article describes this process.
9 |
10 | ## Cloud-Config
11 |
12 | First, you'll need to make a shell script containing your `cloud-config` available at a public URL:
13 |
14 | **cloud-config-bootstrap.sh**
15 |
16 | ```sh
17 | #!/bin/bash
18 |
19 | cat > "cloud-config.yaml" <
39 |
61 |
40 |
46 | The alpha channel closely tracks master and is released to frequently. The newest versions of Docker, etcd and fleet will be available for testing. Current version is CoreOS {{site.alpha-channel}}.
41 |Create a disk image from this channel by running:
42 |43 | ./create-coreos-vdi -V alpha 44 |45 |
47 |
53 | The beta channel consists of promoted alpha releases. Current version is CoreOS {{site.beta-channel}}.
48 |Create a disk image from this channel by running:
49 |50 | ./create-coreos-vdi -V beta 51 |52 |
54 |
60 | The Stable channel should be used by production clusters. Versions of CoreOS are battle-tested within the Beta and Alpha channels before being promoted. Current version is CoreOS {{site.stable-channel}}.
55 |Create a disk image from this channel by running:
56 |57 | ./create-coreos-vdi -V stable 58 |59 |
45 |
94 |
95 |
96 | Go to My Servers > Startup Scripts > Add Startup Script, select type "PXE", and input your script. Be sure to replace the cloud-config-url with that of the shell script you created above.
97 |
98 | Additional reading can be found at [Booting CoreOS with iPXE](http://coreos.com/docs/running-coreos/bare-metal/booting-with-ipxe/) and [Embedded scripts for iPXE](http://ipxe.org/embed).
99 |
100 | ## Create the VPS
101 |
102 | Create a new VPS (any server type and location of your choice), and then:
103 |
104 | 1. For the "Operating System" select "Custom"
105 | 2. Select "iPXE Custom Script" and the script you created above.
106 | 3. Click "Place Order"
107 |
108 | Once you receive the "Subscription Activated" email the VPS will be ready to use.
109 |
110 | ## Accessing the VPS
111 |
112 | You can now log in to CoreOS using the associated private key on your local computer. You may need to specify its location using ```-i LOCATION```. If you need additional details on how to specify the location of your private key file see [here](http://www.cyberciti.biz/faq/force-ssh-client-to-use-given-private-key-identity-file/).
113 |
114 | SSH to the IP of your VPS, and specify the "core" user: ```ssh core@IP```
115 |
116 | ```sh
117 | $ ssh core@IP
118 | The authenticity of host 'IP (2a02:1348:17c:423d:24:19ff:fef1:8f6)' can't be established.
119 | RSA key fingerprint is 99:a5:13:60:07:5d:ac:eb:4b:f2:cb:c9:b2:ab:d7:21.
120 | Are you sure you want to continue connecting (yes/no)? yes
121 | Warning: Permanently added '[IP]' (ED25519) to the list of known hosts.
122 | Enter passphrase for key '/home/user/.ssh/id_rsa':
123 | CoreOS stable (557.2.0)
124 | core@localhost ~ $
125 | ```
126 |
127 | ## Using CoreOS
128 |
129 | Check out the [CoreOS Quickstart]({{site.baseurl}}/docs/quickstart) guide or dig into [more specific topics]({{site.baseurl}}/docs).
130 |
--------------------------------------------------------------------------------
/os/mounting-storage.md:
--------------------------------------------------------------------------------
1 | # Mounting Storage
2 |
3 | The [cloud-config]({{site.baseurl}}/docs/cluster-management/setup/cloudinit-cloud-config) *mount unit* mechanism is used to attach additional filesystems to CoreOS nodes, whether such storage is provided by an underlying cloud platform, physical disk, SAN, or NAS system. By [systemd convention](http://www.freedesktop.org/software/systemd/man/systemd.mount.html), mount unit names derive from the target mount point, with interior slashes replaced by dashes, and the `.mount` extension appended. A unit mounting onto `/var/www` is thus named `var-www.mount`.
4 |
5 | Mount units name the source filesystem and target mount point, and optionally the filesystem type. Cloud-config writes mount unit files beneath `/etc/systemd/system`. *Systemd* mounts filesystems defined in such units at boot time. The following example mounts an [EC2 ephemeral disk]({{site.baseurl}}/docs/running-coreos/cloud-providers/ec2/#instance-storage) at the node's `/media/ephemeral` directory, and is therefore named `media-ephemeral.mount`:
6 |
7 | ```yaml
8 | #cloud-config
9 |
10 | coreos:
11 | units:
12 | - name: media-ephemeral.mount
13 | command: start
14 | content: |
15 | [Mount]
16 | What=/dev/xvdb
17 | Where=/media/ephemeral
18 | Type=ext3
19 | ```
20 |
21 | ## Use Attached Storage for Docker
22 |
23 | Docker containers can be very large and debugging a build process makes it easy to accumulate hundreds of containers. It's advantageous to use attached storage to expand your capacity for container images. Be aware that some cloud providers treat certain disks as ephemeral and you will lose all Docker images contained on that disk.
24 |
25 | We're going to mount a btrfs device to `/var/lib/docker`, where Docker stores images. We can do this on the fly when the machines starts up with a oneshot unit that formats the drive and another one that runs afterwards to mount it. Be sure to hardcode the correct device or look for a device by label:
26 |
27 | ```yaml
28 | #cloud-config
29 | coreos:
30 | units:
31 | - name: format-ephemeral.service
32 | command: start
33 | content: |
34 | [Unit]
35 | Description=Formats the ephemeral drive
36 | After=dev-xvdb.device
37 | Requires=dev-xvdb.device
38 | [Service]
39 | Type=oneshot
40 | RemainAfterExit=yes
41 | ExecStart=/usr/sbin/wipefs -f /dev/xvdb
42 | ExecStart=/usr/sbin/mkfs.btrfs -f /dev/xvdb
43 | - name: var-lib-docker.mount
44 | command: start
45 | content: |
46 | [Unit]
47 | Description=Mount ephemeral to /var/lib/docker
48 | Requires=format-ephemeral.service
49 | After=format-ephemeral.service
50 | Before=docker.service
51 | [Mount]
52 | What=/dev/xvdb
53 | Where=/var/lib/docker
54 | Type=btrfs
55 | ```
56 |
57 | Notice that we're starting both units at the same time and using the power of systemd to work out the dependencies for us. In this case, `var-lib-docker.mount` requires `format-ephemeral.service`, ensuring that our storage will always be formatted before it is mounted. Docker will refuse to start otherwise.
58 |
59 | ## Creating and Mounting a btrfs Volume File
60 |
61 | CoreOS [561.0.0](https://coreos.com/releases/#561.0.0) and later are installed with ext4 + overlayfs to provide a layered filesystem for the root partition.
62 | Installations from prior to this, are using btrfs for this functionality.
63 | If you'd like to continue using btrfs on newer CoreOS machines, you can do so with two systemd units: one that creates and formats a btrfs volume file and another that mounts it.
64 |
65 | In this example, we are going to mount a new 25GB btrfs volume file to `/var/lib/docker`, and one can verify that Docker is using the btrfs storage driver once the Docker service has started by executing `sudo docker info`.
66 | We recommend allocating **no more than 85%** of the available disk space for a btrfs filesystem as journald will also require space on the host filesystem.
67 |
68 | ```yaml
69 | #cloud-config
70 | coreos:
71 | units:
72 | - name: format-var-lib-docker.service
73 | command: start
74 | content: |
75 | [Unit]
76 | Before=docker.service var-lib-docker.mount
77 | ConditionPathExists=!/var/lib/docker.btrfs
78 | [Service]
79 | Type=oneshot
80 | ExecStart=/usr/bin/truncate --size=25G /var/lib/docker.btrfs
81 | ExecStart=/usr/sbin/mkfs.btrfs /var/lib/docker.btrfs
82 | - name: var-lib-docker.mount
83 | enable: true
84 | content: |
85 | [Unit]
86 | Before=docker.service
87 | After=format-var-lib-docker.service
88 | Requires=format-var-lib-docker.service
89 | [Install]
90 | RequiredBy=docker.service
91 | [Mount]
92 | What=/var/lib/docker.btrfs
93 | Where=/var/lib/docker
94 | Type=btrfs
95 | Options=loop,discard
96 | ```
97 |
98 | Note the declaration of `ConditionPathExists=!/var/lib/docker.btrfs`. Without this line, systemd would reformat the btrfs filesystem every time the machine starts.
99 |
100 | ## Mounting NFS Exports
101 |
102 | This cloud-config excerpt enables the NFS host monitor [`rpc.statd(8)`](http://linux.die.net/man/8/rpc.statd), then mounts an NFS export onto the CoreOS node's `/var/www`.
103 |
104 | ```yaml
105 | #cloud-config
106 | coreos:
107 | units:
108 | - name: rpc-statd.service
109 | command: start
110 | enable: true
111 | - name: var-www.mount
112 | command: start
113 | content: |
114 | [Mount]
115 | What=nfs.example.com:/var/www
116 | Where=/var/www
117 | Type=nfs
118 | ```
119 |
120 | To declare that another service depends on this mount, name the mount unit in the dependent unit's `After` and `Requires` properties:
121 |
122 | ```yaml
123 | [Unit]
124 | After=var-www.mount
125 | Requires=var-www.mount
126 | ```
127 |
128 | If the mount fails, dependent units will not start.
129 |
130 | ## Further Reading
131 |
132 | Check the [`systemd mount` docs](http://www.freedesktop.org/software/systemd/man/systemd.mount.html) to learn about the available options. Examples specific to [EC2]({{site.baseurl}}/docs/running-coreos/cloud-providers/ec2/#instance-storage), [Google Compute Engine]({{site.baseurl}}/docs/running-coreos/cloud-providers/google-compute-engine/#additional-storage) and [Rackspace Cloud]({{site.baseurl}}/docs/running-coreos/cloud-providers/rackspace/#mount-data-disk) can be used as a starting point.
133 |
--------------------------------------------------------------------------------
/os/btrfs-troubleshooting.md:
--------------------------------------------------------------------------------
1 | # Working with btrfs and Common Troubleshooting
2 |
3 | btrfs is a copy-on-write filesystem with full support in the upstream Linux kernel and several desirable features. In the past, CoreOS shipped with a btrfs root filesystem to support Docker filesystem requirements at the time. As of version 561.0.0, CoreOS ships with ext4 as the default root filesystem by default while still supporting Docker. Btrfs is still supported and works with the latest CoreOS releases and Docker, but we recommend using ext4.
4 |
5 | btrfs was marked as experimental for a long time, but it's now fully production-ready and supported by a number of Linux distributions.
6 |
7 | Notable Features of btrfs:
8 |
9 | - Ability to add/remove block devices without interruption
10 | - Ability to balance the filesystem without interruption
11 | - RAID 0, RAID 1, RAID 5, RAID 6 and RAID 10
12 | - Snapshots and file cloning
13 |
14 | This guide won't cover these topics — it's mostly focused on troubleshooting.
15 |
16 | For a more complete troubleshooting experience, let's explore how btrfs works under the hood.
17 |
18 | btrfs stores data in chunks across all of the block devices on the system. The total storage across these devices is shown in the standard output of `df -h`.
19 |
20 | Raw data and filesystem metadata are stored in one or many chunks, typically ~1GiB in size. When RAID is configured, these chunks are replicated instead of individual files.
21 |
22 | A copy-on-write filesystem maintains many changes of a single file, which is helpful for snapshotting and other advanced features, but can lead to fragmentation with some workloads.
23 |
24 | ## No Space Left on Device
25 |
26 | When the filesystem is out of chunks to write data into, `No space left on device` will be reported. This will prevent journal files from being recorded, containers from starting and so on.
27 |
28 | The common reaction to this error is to run `df -h` and you'll see that there is still some free space. That command isn't measuring the btrfs primitives (chunks, metadata, etc), which is what really matters.
29 |
30 | Running `sudo btrfs fi show` will give you the btrfs view of how much free space you have. When starting/stopping many Docker containers or doing a large amount of random writes, chunks will become duplicated in an inefficient manner over time.
31 |
32 | Re-balancing the filesystem ([official btrfs docs](https://btrfs.wiki.kernel.org/index.php/Balance_Filters)) will relocate data from empty or near-empty chunks to free up space. This operation can be done without downtime.
33 |
34 | First, let's see how much free space we have:
35 |
36 | ```sh
37 | $ sudo btrfs fi show
38 | Label: 'ROOT' uuid: 82a40c46-557e-4848-ad4d-10c6e36ed5ad
39 | Total devices 1 FS bytes used 13.44GiB
40 | devid 1 size 32.68GiB used 32.68GiB path /dev/xvda9
41 |
42 | Btrfs v3.14_pre20140414
43 | ```
44 |
45 | The answer: not a lot. We can re-balance to fix that.
46 |
47 | The re-balance command can be configured to only relocate data in chunks up to a certain percentage used. This will prevent you from moving around a lot of data without a lot of benefit. If your disk is completely full, you may need to delete a few containers to create space for the re-balance operation to work with.
48 |
49 | Let's try to relocate chunks with less than 5% of usage:
50 |
51 | ```sh
52 | $ sudo btrfs fi balance start -dusage=5 /
53 | Done, had to relocate 5 out of 45 chunks
54 | $ sudo btrfs fi show
55 | Label: 'ROOT' uuid: 82a40c46-557e-4848-ad4d-10c6e36ed5ad
56 | Total devices 1 FS bytes used 13.39GiB
57 | devid 1 size 32.68GiB used 28.93GiB path /dev/xvda9
58 |
59 | Btrfs v3.14_pre20140414
60 | ```
61 |
62 | The operation took about a minute on a cloud server and gained us 4GiB of space on the filesystem. It's up to you to find out what percentage works best for your workload, the speed of your disks, etc.
63 |
64 | If your balance operation is taking a long time, you can open a new shell and find the status:
65 |
66 | ```
67 | $ sudo btrfs balance status /
68 | Balance on '/' is running
69 | 0 out of about 1 chunks balanced (1 considered), 100% left
70 | ```
71 |
72 | ## Adding a New Physical Disk
73 |
74 | New physical disks can be added to an existing btrfs filesystem. The first step is to have the new block device [mounted on the machine]({{site.baseurl}}/docs/cluster-management/setup/mounting-storage/). Afterwards, let btrfs know about the new device and re-balance the file system. The key step here is re-balancing, which will move the data and metadata across both block devices. Expect this process to take some time:
75 |
76 | ```sh
77 | $ btrfs device add /dev/sdc /
78 | $ btrfs filesystem balance /
79 | ```
80 |
81 | ## Disable Copy-On-Write
82 |
83 | Copy-On-write isn't ideal for workloads that create or modify many small files, such as databases. Without disabling COW, you can heavily fragment the file system as explained above.
84 |
85 | The best strategy for successfully running a database in a container is to disable COW on directory/volume that is mounted into the container.
86 |
87 | The COW setting is stored as a file attribute and is modified with a utility called `chattr`. To disable COW for a MySQL container's volume, run:
88 |
89 | ```sh
90 | $ sudo mkdir /var/lib/mysql
91 | $ sudo chattr -R +C /var/lib/mysql
92 | ```
93 |
94 | The directory `/var/lib/mysql` is now ready to be used by a Docker container without COW. Let's break down the command:
95 |
96 | `-R` indicates that want to recursively change the file attribute
97 | `+C` means we want to set the NOCOW attribute on the file/directory
98 |
99 | To verify, we can run:
100 |
101 | ```sh
102 | $ sudo lsattr /var/lib/
103 | ---------------- /var/lib/portage
104 | ---------------- /var/lib/gentoo
105 | ---------------- /var/lib/iptables
106 | ---------------- /var/lib/ip6tables
107 | ---------------- /var/lib/arpd
108 | ---------------- /var/lib/ipset
109 | ---------------- /var/lib/dbus
110 | ---------------- /var/lib/systemd
111 | ---------------- /var/lib/polkit-1
112 | ---------------- /var/lib/dhcpcd
113 | ---------------- /var/lib/ntp
114 | ---------------- /var/lib/nfs
115 | ---------------- /var/lib/etcd
116 | ---------------- /var/lib/docker
117 | ---------------- /var/lib/update_engine
118 | ---------------C /var/lib/mysql
119 | ```
120 |
121 | ### Disable in a Unit File
122 |
123 | Setting the file attributes can be done within a systemd unit using two `ExecStartPre` commands:
124 |
125 | ```ini
126 | ExecStartPre=/usr/bin/mkdir -p /var/lib/mysql
127 | ExecStartPre=/usr/bin/chattr -R +C /var/lib/mysql
128 | ```
129 |
--------------------------------------------------------------------------------
/flannel/flannel-config.md:
--------------------------------------------------------------------------------
1 | # Configuring flannel for Container Networking
2 |
3 | *Note*: flannel is only available in [CoreOS versions 554]({{site.baseurl}}/releases/#554.0.0) and later.
4 |
5 | ## Overview
6 |
7 | With Docker, each container is assigned an IP address that can be used to communicate with other containers on the _same_ host.
8 | For communicating over a network, containers are tied to the IP addresses of the host machines and must rely on port-mapping to reach the desired container.
9 | This makes it difficult for applications running inside containers to advertise their external IP and port as that information is not available to them.
10 |
11 | flannel solves the problem by giving each container an IP that can be used for container-to-container communication. It uses packet encapsulation
12 | to create a virtual overlay network that spans the whole cluster. More specifically, flannel gives each host an IP subnet (/24 by default) from which the
13 | Docker daemon is able to allocate IPs to the individual containers.
14 |
15 | flannel uses [etcd](https://coreos.com/using-coreos/etcd/) to store mappings between the virtual IP and host addresses. A `flanneld` daemon runs on each
16 | host and is responsible for watching information in etcd and routing the packets.
17 |
18 | ## Configuration
19 |
20 | ### Publishing config to etcd
21 | flannel looks up its configuration in etcd. Therefore the first step to getting started with flannel is to publish the configuration to etcd.
22 | By default, flannel looks up its configuration in `/coreos.com/network/config`. At the bare minimum, you must tell flannel an IP range (subnet) that
23 | it should use for the overlay. Here is an example of the minimum flannel configuration:
24 |
25 | ```json
26 | { "Network": "10.1.0.0/16" }
27 | ```
28 |
29 | Use `etcdctl` utility to publish the config:
30 |
31 | ```bash
32 | $ etcdctl set /coreos.com/network/config '{ "Network": "10.1.0.0/16" }'
33 | ```
34 |
35 | You can put this into a drop-in for flanneld.service via cloud-config:
36 |
37 | ```yaml
38 | #cloud-config
39 |
40 | coreos:
41 | units:
42 | - name: flanneld.service
43 | drop-ins:
44 | - name: 50-network-config.conf
45 | content: |
46 | [Service]
47 | ExecStartPre=/usr/bin/etcdctl set /coreos.com/network/config '{ "Network": "10.1.0.0/16" }'
48 | ```
49 |
50 | This will assign the specified /16 for the entire overlay network. By default, flannel will allocate a /24 to each host. This default, along with the
51 | minimum and maximum subnet IP addresses is overridable in config:
52 |
53 | ```json
54 | {
55 | "Network": "10.1.0.0/16",
56 | "SubnetLen": 28,
57 | "SubnetMin": "10.1.10.0",
58 | "SubnetMax": "10.1.50.0"
59 | }
60 | ```
61 |
62 | This config instructs flannel to allocate /28 subnets to individual hosts and make sure not to issue subnets outside of 10.1.10.0 - 10.1.50.0 range.
63 |
64 | ### Firewall
65 |
66 | flannel uses UDP port 8285 for sending encapsulated IP packets. Make sure to enable this traffic to pass between the hosts. If you find that you can't ping containers across hosts, this port is probably not open.
67 |
68 | ### Enabling flannel via Cloud-Config
69 | The last step is to enable `flanneld.service` in the cloud-config by adding `command: start` directive:
70 |
71 | ```yaml
72 | #cloud-config
73 |
74 | coreos:
75 | units:
76 | - name: flanneld.service
77 | drop-ins:
78 | - name: 50-network-config.conf
79 | content: |
80 | [Service]
81 | ExecStartPre=/usr/bin/etcdctl set /coreos.com/network/config '{ "Network": "10.1.0.0/16" }'
82 | command: start
83 |
84 | # Example service running in a Docker container
85 | - name: redis.service
86 | content: |
87 | [Unit]
88 | Requires=flanneld.service
89 | After=flanneld.service
90 |
91 | [Service]
92 | ExecStart=/usr/bin/docker run redis
93 | Restart=always
94 | command: start
95 | ```
96 |
97 | *Important*: If you are starting other units via cloud-config, `flanneld.service` needs to be listed _before_ any services that run Docker containers.
98 | In addition, other units that will run in containers, including those scheduled via fleet, should include `Requires=flanneld.service`, `After=flanneld.service`, and `Restart=always|on-failure` directives.
99 | These directive are necessary because flanneld.service may fail due to etcd not being available yet. It will keep restarting and it is important for Docker based services to also keep trying until flannel is up.
100 |
101 | *Important*: If you are starting flannel on Vagrant, it should be instructed to use the correct network interface:
102 |
103 | ```yaml
104 | #cloud-config
105 |
106 | coreos:
107 | flannel:
108 | interface: $public_ipv4
109 | ```
110 |
111 | ## Under the Hood
112 | To reduce the CoreOS image size, flannel daemon is stored in CoreOS Enterprise Registry as a Docker container and not shipped in the CoreOS image.
113 | For those users wishing not to use flannel, it helps to keep their installation minimal. When `flanneld.service` it started, it pulls the Docker image
114 | from the registry. There is, however, a chicken and the egg problem as flannel configures Docker bridge and Docker is needed to pull down the image.
115 |
116 | In order to work around this, CoreOS is configured to optionally run a second copy of Docker daemon which we call early-docker. Early-docker daemon
117 | is started with `--iptables=false` and containers that it executes need to run with host networking. This prevents Docker from starting `docker0` bridge.
118 |
119 | Here is the sequence of events that happens when `flanneld.service` is started followed by a service that runs a Docker container (e.g. redis server):
120 |
121 | 1. `early-docker.service` gets started since it is a dependency of `flanneld.service`.
122 | 2. `early-docker.service` launches a Docker on a separate Unix socket — `/var/run/early-docker.sock`.
123 | 3. `flanneld.service` executes `DOCKER_HOST=unix:///var/run/early-docker.sock docker run --net=host quay.io/coreos/flannel:$FLANNEL_VER` (actual invocation is slightly more complex).
124 | 4. flanneld starts and writes out `/run/flannel/subnet.env` with the acquired IP subnet information.
125 | 5. `ExecStartPost` in `flanneld.service` converts information in `/run/flannel/subnet.env` into Docker daemon command line args (such as `--bip` and `--mtu`),
126 | storing them in `/run/flannel_docker_opts.env`
127 | 6. `redis.service` gets started which invokes `docker run ...`, triggering socket activation of `docker.service`.
128 | 7. `docker.service` sources in `/run/flannel_docker_opts.env` which contains env variables with command line options and starts the Docker with them.
129 | 8. `redis.service` runs Docker redis container.
130 |
131 | If you would like to learn more about these service files, you can check them out like so: `systemctl cat early-docker.service`.
132 |
--------------------------------------------------------------------------------
/os/sdk-building-production-images.md:
--------------------------------------------------------------------------------
1 | # Building Production Images
2 |
3 | In general the automated process should always be used but in a pinch
4 | putting together a release manually may be necessary. All release
5 | information is tracked in the [manifest][coreos-manifest] git
6 | repository which is usually organized like so:
7 |
8 | * build-109.xml (previous release manifest)
9 | * build-115.xml (current release manifest)
10 | * master.xml (master branch manifest)
11 | * version.txt (current version information)
12 | * default.xml -> master.xml
13 | * release.xml -> build-115.xml
14 |
15 | [coreos-manifest]: https://github.com/coreos/manifest
16 |
17 | ## Tagging Releases
18 |
19 | The first step of building a release is updating and tagging the release
20 | in the manifest git repository. A typical release off of master involves
21 | the following steps:
22 |
23 | 1. Make sure you are on the master branch: `repo init -b master`
24 | 2. Sync/checkout source, excluding local changes: `repo sync --detach`
25 | 3. In the scripts directory: `./tag_release --push`
26 |
27 | That was far too easy, if you need to do it the hard way try this:
28 |
29 | 1. Make sure you are on the master branch: `repo init -b master`
30 | 2. Sync/checkout source, excluding local changes: `repo sync --detach`
31 | 3. Switch to the somewhat hidden manifests checkout: `cd .repo/manifests`
32 | 4. Update `version.txt` with the desired version number.
33 | * COREOS_BUILD is the major version number, and should be the number
34 | of days since July 1st, 2013. COREOS_BRANCH should start at 0 and
35 | is incremented for every normal release based on a particular
36 | COREOS_BUILD version. COREOS_PATCH is reserved for exceptional
37 | situations such as emergency manual releases and should normally
38 | be 0.
39 | * The complete version string is
40 | COREOS_BUILD.COREOS_BRANCH.COREOS_PATCH
41 | * COREOS_SDK_VERSION should be the complete version string of an
42 | existing build. The `cros_sdk` uses this to pick what SDK tarball
43 | to use when creating a fresh chroot and provides a fallback set of
44 | binary packages to use when the current release's packages are
45 | unavailable. Usually it will be one release behind COREOS_BUILD.
46 | 5. Generate a release manifest: `repo manifest -r -o build-$BUILD.xml`
47 | where `$BUILD` is the current value of COREOS_BUILD in `version.txt`.
48 | 6. Update `release.xml`: `ln -sf build-$BUILD.xml release.xml`
49 | 7. Commit! `git add build-$BUILD.xml; git commit -a`
50 | 8. Tag! `git tag v$BUILD.$BRANCH.$PATCH`
51 | 9. Push! `git push origin HEAD:master HEAD:dev-channel
52 | HEAD:build-$BUILD v$BUILD.$BRANCH.$PATCH`
53 |
54 | If a release branch needs to be updated after master has moved on the
55 | procedure is similar.
56 | Unfortunately since tagging branched releases (not on master) is a bit
57 | trickier to get right the `tag_release` script cannot be used.
58 | The automated build will kick off after updating the `dev-channel` branch.
59 |
60 | 1. Check out the release instead of master: `repo init -b build-$BUILD
61 | -m release.xml`
62 | 2. Sync, cherry-pick, push, and whatever else is required to publish
63 | the desired changes in the repo-managed projects. If the desired
64 | changes are already published (such as if you are just updating to a
65 | later commit from a project's master branch) then this can be
66 | skipped.
67 | 3. `cd .repo/manifests`
68 | 4. Update `version.txt` as desired. Usually just increment
69 | COREOS_PATCH.
70 | 5. Update `build-$BUILD.xml` as desired. The output of
71 | `repo manifest -r` shouldn't be used verbatim this time because it
72 | won't generate meaningful values for the `upstream` project
73 | attribute when starting from a release manifest instead of
74 | `master.xml` but it can be useful for looking up the git commit to
75 | update the `revision` attribute to. If the new git commit is on a
76 | branch other than master be sure to update the `upstream` attribute
77 | with the appropriate ref spec for that branch.
78 | 6. If this is the first time this branch has been updated on its own
79 | update the `default.xml` link so checking out this manifest branch
80 | with repo init but without the `-m` argument works:
81 | `ln -sf build-$BUILD.xml default.xml`
82 | 7. Commit! `git commit -a`
83 | 8. Tag! `git tag v$BUILD.$BRANCH.$PATCH`
84 | 9. Push! `git push origin HEAD:dev-channel
85 | HEAD:build-$BUILD v$BUILD.$BRANCH.$PATCH`
86 |
87 | Now you can start building images!
88 | This will build an image that can be ran under KVM and uses near production
89 | values.
90 |
91 | Note: Add `COREOS_OFFICIAL=1` here if you are making a real release. That will
92 | change the version to leave off the build id suffix.
93 |
94 | ```sh
95 | ./build_image prod --group alpha
96 | ```
97 |
98 | The generated production image is bootable as-is by qemu but for a
99 | larger ROOT partition or VMware images use `image_to_vm.sh` as
100 | described in the final output of `build_image`.
101 |
102 | ## Automated Builds
103 |
104 | Automated release builds are triggered by pushes to the `dev-channel`
105 | branch in the manifest repository.
106 |
107 | Note: In the future builds will be triggered by pushing new tags instead
108 | of using the `dev-channel` branch; the branch only exists due to a limitation
109 | of the current buildbot deployment.
110 |
111 | ## Pushing updates into roller
112 |
113 | The automated build host does not have access to production signing keys
114 | so the final signing and push to roller must be done elsewhere.
115 | The `coreos_production_update.zip` archive provides the tools required to
116 | do this so a full SDK setup is not required. This does require gsutil to be
117 | installed and configured.
118 | An update payload signed by the insecure development keys is generated
119 | automatically as `coreos_production_update.gz` and
120 | `coreos_production_update.meta`. If needed the raw filesystem image used
121 | to generate the payload is `coreos_production_update.bin.bz2`.
122 | As an example, to publish the insecurely signed payload:
123 |
124 | ```sh
125 | URL=http://builds.release.core-os.net/alpha/amd64-usr/321.0.0
126 | cd $(mktemp -d)
127 | gsutil -m cp $URL/coreos_production_update* ./
128 | gpg --verify coreos_production_update.zip.sig
129 | gpg --verify coreos_production_update.gz.sig
130 | gpg --verify coreos_production_update.meta.sig
131 | unzip coreos_production_update.zip
132 | ./core_roller_upload --user
46 |
61 |
47 |
49 | The alpha channel closely tracks master and is released to frequently. The newest versions of Docker, etcd and fleet will be available for testing. Current version is CoreOS {{site.data.alpha-channel.rackspace-version}}.
48 |A sample script will look like this:
50 | 51 |#!ipxe
52 |
53 | # Location of your shell script.
54 | set cloud-config-url http://example.com/cloud-config-bootstrap.sh
55 |
56 | set base-url http://alpha.release.core-os.net/amd64-usr/current
57 | kernel ${base-url}/coreos_production_pxe.vmlinuz cloud-config-url=${cloud-config-url}
58 | initrd ${base-url}/coreos_production_pxe_image.cpio.gz
59 | boot
60 |
62 |
77 |
63 |
65 | The beta channel consists of promoted alpha releases. Current version is CoreOS {{site.data.beta-channel.rackspace-version}}.
64 |A sample script will look like this:
66 | 67 |#!ipxe
68 |
69 | # Location of your shell script.
70 | set cloud-config-url http://example.com/cloud-config-bootstrap.sh
71 |
72 | set base-url http://beta.release.core-os.net/amd64-usr/current
73 | kernel ${base-url}/coreos_production_pxe.vmlinuz cloud-config-url=${cloud-config-url}
74 | initrd ${base-url}/coreos_production_pxe_image.cpio.gz
75 | boot
76 |
78 |
93 |
79 |
81 | The Stable channel should be used by production clusters. Versions of CoreOS are battle-tested within the Beta and Alpha channels before being promoted. Current version is CoreOS {{site.data.stable-channel.rackspace-version}}.
80 |A sample script will look like this:
82 | 83 |#!ipxe
84 |
85 | # Location of your shell script.
86 | set cloud-config-url http://example.com/cloud-config-bootstrap.sh
87 |
88 | set base-url http://stable.release.core-os.net/amd64-usr/current
89 | kernel ${base-url}/coreos_production_pxe.vmlinuz cloud-config-url=${cloud-config-url}
90 | initrd ${base-url}/coreos_production_pxe_image.cpio.gz
91 | boot
92 |