Documentation for CoreOS projects
Home Page: http://coreos.com/docs
License: Apache License 2.0
This repository contains the Markdown source of the Container Linux documentation.
Container Linux documentation is released under the Apache 2.0 License, and we welcome contributions. Check out the help-wanted tag in this project's Issues list for good places to start participating, and review the contribution guidelines to find out how to submit your edits and improvements.
People may want details on how the partition layout works, lets provide those details with the UUIDs, labels, etc.
This throws errors in both RHEL and Ubuntu (precise) where I've tried
wget http://storage.core-os.net/coreos/amd64-generic/dev-channel/coreos_production_image.bin.bz2
bunzip2 coreos_production_image.bin.bz2
losetup --show --find -P coreos_production_image.bin
mount /dev/loop0p6 /mnt/
the error is as follows:
losetup: invalid option -- 'P'
removing the -P option for losetup created the /dev/loop0, also incorrect in the documentation, but it is unable to mount it requesting the filesystem
$ losetup --show --find coreos_production_image.bin
/dev/loop0
$ mount /dev/loop0 /mnt
mount: you must specify the filesystem type
section Launching a Container example of installing apache
before the command
apt_get_install apache2
need this command
apt-get update
Here is a starting point. It would be great to make a utility that handled it a bit better.
Run these commands as root to create a 512 megabyte swap.
fallocate -l 512m /media/state/512MiB.swap
chmod 600 /media/state/512MiB.swap
mkswap /media/state/512MiB.swap
Create a unit file at /media/state/units/swapon.service with these contents:
[Unit]
Description=Turn on swap
[Service]
Type=oneshot
ExecStart=/sbin/swapon /media/state/512MiB.swap
[Install]
WantedBy=local.target
systemctl enable --runtime /media/state/units/swapon.service
systemctl start swapon
On your next reboot the swap will be turned on automatically.
From the CoreOS Vagrant docs, it implies three instance are started when issuing vagrant up. But on Mac OS X.9.2, with vagrant 1.5.2, and virtual box 4.3.10, it only starts one instance.
I can start three using NUM_INSTANCES=3 vagrant up yet, still, vagrant status doesn't recognize instances core-02 and core-03 even though i see them in the .vagrant/machines directory and in virtual box as running instances.
here is the error:
This XML file does not appear to have any style information associated with it. The document tree is shown below.
NoSuchKey
The specified key does not exist.
I was looking for a way to deploy CoreOS on Bare Metal ARM devices (no not the rasperry Pi, that probably wouldn't work :), although it might (http://resin.io/blog/docker-on-raspberry-pi/)
I could not find anywhere in the docs how to download (or build) an ARM image.
Even if this is not supported (or even known to not work), a relevant warning / link to issue might be helpful.
Thanks :)
Hello,
I'm trying to execute this:
sudo coreos-install -d /dev/vda -C stable
But I get
/bin/coreos-install: Image URL unavailable: http://stable.release.core-os.net/amd64-usr/410.0.0/coreos_production_vultr_image.bin.bz2
How I can fix it ? Thank you.
Per https://coreos.com/docs/sdk-distributors/distributors/notes-for-distributors/, additional systemd unit files are part of a target called oem.target.
On CoreOS 206.1.0:
systemctl start oem.target
Failed to issue method call: Unit oem.target failed to load: No such file or directory. See system logs and 'systemctl status oem.target' for details.
And:
find /usr /etc -name '*target' | grep oem
Is blank.
systemctl status oem.target
oem.target
Loaded: not-found (Reason: No such file or directory)
Active: inactive (dead)
Other targets, ie default.target, work fine,
Is there something missing, either in CoreOS or the instructions, to create oem.target?
If you expect to change the hostname and SSH host keys, SSH in for the first time without updating your local known_hosts file:
ssh -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no -i insecure_ssh_key [email protected]
To change the hostname:
hostnamectl set-hostname hostname.domain.com
To regenerate the host keys and insert your new hostname into the key descriptions:
rm /etc/ssh/ssh_host_*key*
reboot
You'd think systemctl restart sshd would be a better choice, there, but an ExecStartPre line in sshd.service runs /usr/bin/ssh-keygen -A and generates more files than either sshd-keygen or whatever's happening during reboot.
One such file is /etc/ssh/ssh_host_ed25519_key, which features in the journal:
May 21 06:30:57 hostname.example.com systemd[1]: Started Generate sshd host keys. May 21 06:30:57 hostname.example.com coreos-cloudinit[2947]: 2014/05/21 06:30:57 Authorized SSH keys for core user ... May 21 06:30:59 hostname.example.com systemd[1]: Starting system-sshd.slice. May 21 06:30:59 hostname.example.com systemd[1]: Created slice system-sshd.slice. May 21 06:30:59 hostname.example.com systemd[1]: Starting OpenSSH per-connection server daemon (10.128.185.54:49631)... May 21 06:30:59 hostname.example.com systemd[1]: Started OpenSSH per-connection server daemon (10.128.185.54:49631). May 21 06:30:59 hostname.example.com sshd[4955]: Could not load host key: /etc/ssh/ssh_host_ed25519_key
… so, maybe -A is a good idea and should be introduced to sshd-keygen.service, assuming /usr/lib/coreos/sshd_keygen takes the same arguments as /usr/bin/ssh-keygen.
I'm having trouble figuring out your intent from your code, here. Why have two ways of generating SSH host keys? Why run only one of them at boot, only to log errors due to it not being as comprehensive as the other?
When I try to SSH into the "coreos_production_vmware_insecure" image with ssh -i insecure_ssh_key [email protected] I get the response ssh_exchange_identification: read: Connection reset by peer
Does this have to do with the fact that I am running CoreOS under NAT instead of Bridged? (My network doesn't have a DHCP server so CoreOS just sits there, ip-less under bridged)
Also (Not really an issue, probably just me being incompetent with YAML), for the life of me I cannot get the config file working with my SSH keys. I've tried everything and it will not let me log in. Should the RSA key include the user@hostname at the end? basically the entire contents of id_rsa.pub should be there?
Start from something like this and explain how to setup a network bridge: http://jpetazzo.github.io/2013/10/16/configure-docker-bridge-network/
From sdk/index.md:
Tips and Tricks
Finding all open pull requests and issues
These links are available only for oraganization members who have access to coreos dashboard on github. You can check this accessing them as unauthenticated user.
The only real trick is useradd -p "*".
/cc @robszumski
Not sure if its the right place, are the docs accurate on logging in via ssh, coreos still asks for a password even when it has been added to the knownhosts. The password is not the same and I can't login
config:
Host coreos
HostName localhost
Port 2222
User core
StrictHostKeyChecking no
UserKnownHostsFile /dev/null
i have the necessary id_rsa and id_rsa_pub
According to the docs at http://coreos.com/docs/running-coreos/cloud-providers/rackspace/, I should be able to start coreos on performance1-1.
I tried twice on that flavor and both times I got to about 80/90%, maybe 100%, and then the server went to error.
I switched to standard flavor 2, just like in the example, and on my third try it worked perfectly.
I can update the docs to note that performance1-1 does not currently work, but it would be nice if performance flavors could be used with coreos, too.
Hi folks,
I'm new to coreos and can't find a way to change the default keyboard layout. Google search doesn't find anything either.
The example of "My Advanced Service" in "Advanced Unit Files" is not actually functional.
https://github.com/coreos/docs/blob/master/launching-containers/launching/getting-started-with-systemd/index.md#advanced-unit-files
I mean it will work exactly once, since ExecStart docker run action is naming the container it won't be able to start it next time which defeats the purpose of systemd script.
There is already a working script out there, which builds an ISO-file connected to your local ssh-key: https://github.com/nyarla/coreos-live-iso
In using-coreos/index.md, there is the following paragraph:
First, you will need to run all of this as
rootsince you are modifying system state:sudo su
The sudo su is redundant, and should be replaced with sudo -i.
I'm trying to install CoreOS to disk, and I'm following the recomendation from official doc.
I have PXE with CoreOS, then I'm booting CoreOS from RAM and I continue these steps:
1- execute: cfdisk -z /dev/sda
2- execute: touch "/usr.squashfs (deleted)" # work around a bug in mkfs.btrfs 3.12
3- execute: mkfs.btrfs -L ROOT /dev/sda1
1- copy all resources to /home/core (coreos-install and my-cloud-config.yml)
2- execute: chmod +x coreos install
3- execute: sudo ./coreos-install -d /dev/sda -c /home/core/my-cloud-config.yml
The output was:
...
Installing cloud-config...
[2312.930275] BTRFS info (device sda1): disk space caching is enabled
mount: mount(2) failed: No such file or directory
I don't know what's the problem, because on internet I can't find any report of this behavior during the installation of CoreOS.
Any ideas, @robszumski, @brianredbeard, @philips, @vCarly ?
This suggests using pastie's 'raw' feature, but this is not actually raw.
As an example:
http://pastie.org/pastes/9250779/text
View the source for this page, you'll see it's a HTML document, not raw text.
MAINTAINER NOTE The above link is broken. This is the correct URL: https://github.com/coreos/docs/blob/master/os/booting-with-ipxe.md#setting-up-the-boot-script
According to the docs Service Discovery with etcd and Using docker with etcd, I should be able to run the following from within a container, but I get an error.
curl -L http://127.0.0.1:4001/v2/keys/
curl: (7) Failed to connect to 127.0.0.1 port 4001: Connection refused
However, if I use the gatway IP (docker0 interface on coreos host) of the container, it works:
curl -L http://10.1.42.1:4001/v2/keys/
{"action":"get","node":{"key":"/","dir":true,"nodes":[{"key":"/coreos.com","dir":true,"modifiedIndex":4,"createdIndex":4}]}}
I also read Reading and Writing from Inside a Container, which states:
To read and write to etcd from within a container you must use the docker0 interface which you can find in ip address show. It's normally 172.17.42.1 and using it is as easy as replacing 127.0.0.1.
This makes it a little clearer, but the 3 pages I mentioned should do a better job of explaining exactly where the commands are being run and to which IP addresses should be used. Since there are several layers of virtualization (more so when you are on Vagrant), the details become imperative.
The definition of the docker-tcp unit is correct; however, the docs fail to note that coreos defines a standard docker.socket in /usr/lib/systemd/system for the docker 'local' socket that is used when fleet locally invokes docker. So, for instance, if a user were to name this unit docker.socket it would hide the coreos docker.socket and fleet provisioning of docker containers will fail.
This is a general issue with cloud-config docs - when cloud-config extends systemd units created by coreos there is an assumption that the reader doesn't need to know anything about the base units these extensions are being made to. This is a bad assumption.
Via this IRC conversation
[08:18:32] <jchackert> [07:14:40] anyone run into this: ./chromite/bin/cros_sdk
[08:18:32] <jchackert> [07:14:40] -bash: ./chromite/bin/cros_sdk: /usr/bin/python2: bad interpreter: No such file or directory
[08:18:32] <jchackert> [07:15:13] trying to build an image on an os x 10.8.4 machine
[08:25:01] <philips> jchackert: you need linux to build the SDK, sorry
[08:25:32] <philips> jchackert: The SDK requires an amd64 linux machine essentially. I will make the docs more clear about that.
[08:28:02] <philips> jchackert: you can use vmware or virtualbox with ubuntu/fedora/etc to run the sdk
[08:28:11] <jchackert> doing that now
[08:28:13] <philips> jchackert: a few people do that with succses
[08:28:15] <philips> jchackert: cool
As fleet and fleetctl have evolved, we have inadvertently invalidated some of our documentation. For example, take a look at https://coreos.com/docs/launching-containers/launching/launching-containers-fleet/. The output from fleetctl list-units does not match the behavior of the latest release, and fleetctl list-unit-files is not referenced at all.
People may want to software RAID CoreOS. Can we do this today? Can we help with the coreos-install script?
/cc @marineam
In the Example Deployment documentation under the Service Files section, there is a link with the text "templates" that points to the following URL:
https://github.com/coreos/fleet/Documentation/unit-files-and-scheduling#template-unit-files
That URL does not appear to exist.
[09:39:34] <ahjohannessen> philips: What's the difference between coreos_production_vmware_image.vmdk and coreos_production_vmware_insecure_image.vmdk ? Can't see it from the docs
[09:40:10] <philips> ahjohannessen: one has the vagrant insecure ssh key onboard
[09:40:17] <philips> ahjohannessen: we should document it though
When reaching the step "Bootstrap the SDK chroot", the repoi init step fails with the following error:
object 12fd10c20115046dcd2fbe468a45e566f38ffbc9
type commit
tag v1.12.7
tagger Conley Owens <[email protected]> 1381959964 -0700
repo 1.12.7
gpg: Signature made Thu 17 Oct 2013 using RSA key ID 692B382C
gpg: Can't check signature: public key not found
error: could not verify the tag 'v1.12.7'
Somehow it seems my system does not update. I have GROUP=alpha in /etc/coreos/update.conf, and I expect the system to bump to v431.0.0.
$ journalctl -u update-engine
Sep 09 12:04:37 localhost update_engine[2915]: [0909/120437:INFO:omaha_request_action.cc(292)] Posting an Omaha request to https://public.update.core-os.net/v1/update/
Sep 09 12:04:37 localhost update_engine[2915]: [0909/120437:INFO:omaha_request_action.cc(293)] Request: <?xml version="1.0" encoding="UTF-8"?>
Sep 09 12:04:37 localhost update_engine[2915]: <request protocol="3.0" version="CoreOSUpdateEngine-0.1.0.0" updaterversion="CoreOSUpdateEngine-0.1.0.0" installsource="scheduler" ismachine="1">
Sep 09 12:04:37 localhost update_engine[2915]: <os version="Chateau" platform="CoreOS" sp="343.0.0_x86_64"></os>
Sep 09 12:04:37 localhost update_engine[2915]: <app appid="{e96281a6-d1af-4bde-9a0a-97b76e56dc57}" version="343.0.0" track="alpha" from_track="alpha" bootid="{9759e0c0-fc53-4229-a7b3-8f834a237bf0}" oem="" machineid=
Sep 09 12:04:37 localhost update_engine[2915]: <ping active="1"></ping>
Sep 09 12:04:37 localhost update_engine[2915]: <updatecheck targetversionprefix=""></updatecheck>
Sep 09 12:04:37 localhost update_engine[2915]: <event eventtype="3" eventresult="2" previousversion=""></event>
Sep 09 12:04:37 localhost update_engine[2915]: </app>
Sep 09 12:04:37 localhost update_engine[2915]: </request>
Sep 09 12:04:37 localhost update_engine[2915]: [0909/120437:INFO:libcurl_http_fetcher.cc(63)] Starting/Resuming transfer
Sep 09 12:04:37 localhost update_engine[2915]: [0909/120437:INFO:libcurl_http_fetcher.cc(78)] Using proxy: no
Sep 09 12:04:38 localhost update_engine[2915]: [0909/120437:INFO:libcurl_http_fetcher.cc(52)] We are connected via Ethernet, Updates allowed: Yes
Sep 09 12:04:38 localhost update_engine[2915]: [0909/120437:INFO:libcurl_http_fetcher.cc(206)] Setting up curl options for HTTPS
Sep 09 12:04:38 localhost update_engine[2915]: [0909/120438:INFO:libcurl_http_fetcher.cc(488)] Setting up timeout source: 1 seconds.
Sep 09 12:04:38 localhost update_engine[2915]: [0909/120438:INFO:libcurl_http_fetcher.cc(289)] HTTP response code: 200
Sep 09 12:04:38 localhost update_engine[2915]: [0909/120438:INFO:libcurl_http_fetcher.cc(358)] Transfer completed (200), 267 bytes downloaded
Sep 09 12:04:38 localhost update_engine[2915]: [0909/120438:INFO:omaha_request_action.cc(619)] Omaha request response: <?xml version="1.0" encoding="UTF-8"?>
Sep 09 12:04:38 localhost update_engine[2915]: <response protocol="3.0" server="update.core-os.net">
Sep 09 12:04:38 localhost update_engine[2915]: <daystart elapsed_seconds="0"></daystart>
Sep 09 12:04:38 localhost update_engine[2915]: <app appid="e96281a6-d1af-4bde-9a0a-97b76e56dc57" status="ok">
Sep 09 12:04:38 localhost update_engine[2915]: <updatecheck status="noupdate"></updatecheck>
Sep 09 12:04:38 localhost update_engine[2915]: </app>
Sep 09 12:04:38 localhost update_engine[2915]: </response>
Sep 09 12:04:38 localhost update_engine[2915]: [0909/120438:INFO:omaha_request_action.cc(433)] No update.
...
Any ideas what might be wrong?
Like the debug customization document HTTP_PROXY=http://web-proxy:8080.
In docs/using-coreos/index.md the default user is shown to be core
NOTE: the user for ssh is
core.
When I try to log in via ssh, I am prompted for a password -- the default password is neither empty nor core -- the obvious choices. What is the default password?
On os x, ssh agent forwarding is turned off in /etc/ssh_config (for security reasons). This must be enabled ("ForwardAgent" must be set to "yes") for ssh -A to work.
Automatic filesystem resizing is a feature we added ages ago but still haven't documented (my fault). I'm impressed that at least one user has managed to find the code implementing it (https://github.com/coreos/coreos-vagrant/issues/8#issuecomment-24680510) but that really shouldn't be more obvious. :-D
Will get this done in the next day or so.
Hello, I would like to change the $PATH in CoreOS, but when I try to modified the file ~/.bashrc (and the others to do that), it says : "Read-only file system". Any idea about how I could change the path??
I can copy files into /bin, /etc/ or /var/ directories neiteher, that is the reason because I want to change the path.
All the commands require a region and supernova gives a really bad error message if you don't specify one.
↪︎ supernova dreid keypair-add --pub-key ~/.ssh/id_rsa.pub dreid-key
Found more than one valid endpoint. Use a more restrictive filter
ERROR: AmbiguousEndpoints: [{u'region': u'SYD', u'tenantId': u'416511', u'versionId': u'2', 'serviceName': u'cloudServersOpenStack', u'versionList': u'https://syd.servers.api.rackspacecloud.com/', u'versionInfo': u'https://syd.servers.api.rackspacecloud.com/v2', u'publicURL': u'https://syd.servers.api.rackspacecloud.com/v2/416511'}, {u'region': u'DFW', u'tenantId': u'416511', u'versionId': u'2', 'serviceName': u'cloudServersOpenStack', u'versionList': u'https://dfw.servers.api.rackspacecloud.com/', u'versionInfo': u'https://dfw.servers.api.rackspacecloud.com/v2', u'publicURL': u'https://dfw.servers.api.rackspacecloud.com/v2/416511'}, {u'region': u'ORD', u'tenantId': u'416511', u'versionId': u'2', 'serviceName': u'cloudServersOpenStack', u'versionList': u'https://ord.servers.api.rackspacecloud.com/', u'versionInfo': u'https://ord.servers.api.rackspacecloud.com/v2', u'publicURL': u'https://ord.servers.api.rackspacecloud.com/v2/416511'}, {u'region': u'IAD', u'tenantId': u'416511', u'versionId': u'2', 'serviceName': u'cloudServersOpenStack', u'versionList': u'https://iad.servers.api.rackspacecloud.com/', u'versionInfo': u'https://iad.servers.api.rackspacecloud.com/v2', u'publicURL': u'https://iad.servers.api.rackspacecloud.com/v2/416511'}, {u'region': u'HKG', u'tenantId': u'416511', u'versionId': u'2', 'serviceName': u'cloudServersOpenStack', u'versionList': u'https://hkg.servers.api.rackspacecloud.com/', u'versionInfo': u'https://hkg.servers.api.rackspacecloud.com/v2', u'publicURL': u'https://hkg.servers.api.rackspacecloud.com/v2/416511'}]
Either every command needs an --os-region-name or you show one specified in the config file.
The example deployment link in :
is broken.
It points to location that no longer exists->
https://github.com/coreos/docs/blob/master/launching-containers/launching/launching-containers-fleet/%7B%7Bsite.url%7D%7D/docs/launching-containers/launching/fleet-example-deployment/#service-files
I did a search in repo but could not find it.
I booted up coreos via vagrant/vmware instructions, ssh'd in, and followed along with http://coreos.com/docs/using-coreos/
$ curl -L http://127.0.0.1:4001/v1/keys/message -d value="Hello world"
curl: (7) Failed connect to 127.0.0.1:4001; Connection refused
The tail of my running processes is:
248 ? Ss 0:00 /usr/lib/systemd/systemd-journald
270 ? S 0:00 [kworker/0:3]
274 ? Ss 0:00 /usr/lib/systemd/systemd-udevd
331 ? S 0:00 [jbd2/sda9-8]
332 ? S< 0:00 [ext4-dio-unwrit]
349 ? S 0:00 [jbd2/sda6-8]
350 ? S< 0:00 [ext4-dio-unwrit]
382 ? Ss 0:00 /sbin/dhcpcd -q --nobackground
384 ? Ss 0:00 /usr/bin/dbus-daemon --system --address=systemd: --nofork --nopidfile --systemd-activation
386 ? Ss 0:00 /bin/bash /usr/sbin/update_engine_reboot_manager
389 ? Ss 0:00 /usr/lib/systemd/systemd-logind
392 ? Ssl 0:00 /usr/sbin/update_engine -foreground -logtostderr -no_connection_manager
395 ? Ssl 0:00 /usr/bin/docker -d -D
397 ? S 0:00 dbus-monitor --system type=signal,interface='org.chromium.UpdateEngineInterface',member='StatusUpdate'
399 ? S 0:00 /bin/bash /usr/sbin/update_engine_reboot_manager
402 tty1 Ss+ 0:00 /sbin/agetty --noclear tty1
404 ttyS0 Ss+ 0:00 /sbin/agetty --keep-baud ttyS0 115200 38400 9600
616 ? Ss 0:00 sshd: core [priv]
618 ? S 0:00 sshd: core@notty
735 ? Ss 0:00 sshd: core [priv]
737 ? R 0:00 sshd: core@pts/0
738 pts/0 Ss 0:00 -bash
746 pts/0 R+ 0:00 ps ax
There is no etcd process. Is there a step missing in docs or a bug in the vagrant up scripts?
I have no ethernet port on my machine so I need to use a usb-ethernet adapter. I'm using one from Apple and this is working with the asix usb driver, this driver also supports other adapters. I can see from the log that ASIX AX88772 is loaded.
Tell users how to customize sshd. Use an example of changing the ClientAliveInterval 30.
OS_TENANT_NAME needs to be set to a tenant ID.
You'll have to explain to the user how to figure out what their default tenant ID is.
Remember, the image name is in the format of username/name...we're going to use coreos in this example. Insert the id with the image name you'd like to use:
Wouldn't the username be 'core', rather than 'coreos', as that's the Linux username coreos images use? Or does 'username' mean something other than 'Linux username' in this context?
Please describe how people can get docker running after having installed an ISO to some bare metal. Without docker coreos is useless!
Namely, the "Cluster Management" section
https://coreos.com/docs/cluster-management/scaling/etcd-optimal-cluster-size/
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
Django
The Web framework for perfectionists with deadlines.
Laravel
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
Microsoft
Open source projects and samples from Microsoft.
Google
Google ❤️ Open Source for everyone.
Alibaba
Alibaba Open Source for everyone
D3
Data-Driven Documents codes.
Tencent
China tencent open source team.