我们想暂时禁用 CoreOS 机器更新时重启，因为我们还没有实现我们服务的高可用性。除了编辑 cloud-init 配置（在第一次配置机器时提供）之外，还有其他方法可以实现吗？
我正在尝试在我的 CoreOS 节点中启动 etcd2。
我的云配置中有这个：
coreos:
etcd2:
discovery: https://discovery.etcd.io/new?size=1
advertise-client-urls: http://127.0.0.1:2379,http://127.0.0.1:4001
initial-advertise-peer-urls: http://127.0.0.1:2380
listen-client-urls: http://0.0.0.0:2379,http://0.0.0.0:4001
listen-peer-urls: http://127.0.0.1:2380
安装后，当我启动系统时出现错误（根据日志）：
etcdmain：顶级值后的无效字符“p”
并且 etcd2 无法启动。
这意味着什么？我遵循了https://coreos.com/os/docs/latest/cloud-config.html和https://coreos.com/os/docs/latest/cluster-discovery.html上的指南。
编辑
节点 1
coreos:
etcd2:
name: coreos1
discovery: https://discovery.etcd.io/2d585793b364cf8985ca7a983d6c52e3
advertise-client-urls: http://127.0.0.1:2379,http://127.0.0.1:4001
initial-advertise-peer-urls: http://127.0.0.1:2380
listen-client-urls: http://0.0.0.0:2379,http://0.0.0.0:4001
listen-peer-urls: http://127.0.0.1:2380
节点 2
coreos:
etcd2:
name: coreos2
discovery: https://discovery.etcd.io/2d585793b364cf8985ca7a983d6c52e3
advertise-client-urls: http://127.0.0.1:2379,http://127.0.0.1:4001
initial-advertise-peer-urls: http://127.0.0.1:2380
listen-client-urls: http://0.0.0.0:2379,http://0.0.0.0:4001
listen-peer-urls: http://127.0.0.1:2380
coreos1> journalctl -u etcd2：
Sep 21 20:10:31 coreos1 etcd2[671]: 2015/09/21 20:10:31 discovery: found self e276d5b4c276a19d in the cluster
Sep 21 …如何在 CoreOS 中查看硬盘 ( SMART )的状态？
smartd和smartctl不是CoreOS的一部分。
因此，遵循 CoreOS 理念 smartd 将在容器内运行，因为systemd 单元和 smartctl 将从toolbox 中使用。
我无法从工具箱访问硬盘驱动器。
有没有办法使用 systemd 启动服务并将其记录到 /dev/null 而不在单元文件中包含正确的行。
例如，将 StandardOutput 和 StandardErorr 指令设置为 null 的文件会将日志发送到 /dev/null。
[Unit]
Description=MyService
[Service]
ExecStart=/usr/bin/start_myservice.sh
Restart=always
StandardOutput=null
StandardError=inherit
[X-Fleet]
Global=true
这个服务可以用
systemctl start MyService.service
我的问题是是否有办法启动没有设置 StandardOutput 和 StandardError 指令的服务，并强制它的日志转到 /dev/null。也许用这样的命令
systemctl start OtherService.service --disable-logging
我正在 kubernetes 集群上试用 coreos。此设置包括一个服务 DNSSEC 响应的绑定服务器。由于 DNSSEC 密钥管理，绑定服务器用完所有可用的熵并在启动时挂起，并且需要数小时才能获得足够的熵来签署单个区域。
我可以做些什么来增加服务器上的熵以防止这种情况发生？
从 CoreOs 766 开始，审计子系统部分集成：
内核中已启用审计子系统，并将 auditctl 添加到映像中。大多数审计事件默认被忽略。审计规则可以在/etc/audit/rules.d 中修改。请注意，auditd 不包括在内，而 journald 负责记录事件，尽管它是一种尽力而为的机制。与基于auditd 的系统不同，如果journald 由于某种原因未能记录事件，内核不会恐慌。
为了审计 899 和 alpha 1000 CoreOs 版本上的系统调用，我尝试了以下方法。
# starting a new periodic process:
$ while true; do echo "coreos ..." > /tmp/a.txt && sleep 5s; done &
[1] 4509
# get its pid and add a new audit rule:
$ sudo auditctl -a always,exit -F arch=b64 -S read,write,close,dup2,wait4 -F pid=4509
# wait 5 minutes and check if any audit related event was logged into by …我想添加一个授权密钥，所以我为 coreos 编写了一个 yaml，我以核心身份登录到我的 coreos 并为以下文件发出 coreos-cloudinit
-------
users:
- name: xyz
ssh_authorized_keys:
- ssh-rsa asdfadf....
-------
看起来它删除了我以前的默认用户“核心”
1) does coreos-cloudinit wipes the previous config ?
2) if so how do I append to the existing config ?
3) how do I dump the exising cloud config so I can append to it and do a cloudinit again?
谢谢。