missing /etc/environment file

[xh3b4sd]

Hey there,

sorry for the lack of knowledge, but I don't know where to place this issue elsewhere. Back to topic. I just started a coreos cluster using the ec2 alpha channel image ami-11c51066 with coreos version 367.0.0. I wondered why some units failed, the reason was the missing etc/environment file.

coreos-setup-environment.service does exist

core@ip-xxx-xx-xx-xxx ~ $ cat /usr/lib64/systemd/system/coreos-setup-environment.service
[Unit]
Description=Modifies /etc/environment for CoreOS
RequiresMountsFor=/usr/share/oem
ConditionPathExists=/usr/share/oem/bin/coreos-setup-environment

[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/usr/share/oem/bin/coreos-setup-environment /etc/environment

[Install]
WantedBy=multi-user.target

/usr/share/oem/bin/coreos-setup-environment does not exist

core@ip-xxx-xx-xx-xxx ~ $ cat /usr/share/oem/bin/coreos-setup-environment
cat: /usr/share/oem/bin/coreos-setup-environment: No such file or directory

/etc/environment does not exist

core@ip-xxx-xx-xx-xxx ~ $ ls /etc/environment
ls: cannot access /etc/environment: No such file or directory

unfortunately there was no error for the service

core@ip-xxx-xx-xx-xxx ~ $ systemctl status coreos-setup-environment.service
● coreos-setup-environment.service - Modifies /etc/environment for CoreOS
   Loaded: loaded (/usr/lib64/systemd/system/coreos-setup-environment.service; disabled)
   Active: inactive (dead)
           start condition failed at Tue 2014-07-08 09:25:28 UTC; 1h 18min ago

Jul 08 09:25:28 localhost systemd[1]: Started Modifies /etc/environment for CoreOS.

I did not find any documentation that this is intended behaviour. Any ideas? Thanks guys. <3

[marineam]

This was intended but we should probably revise it if folks are depending on the old contents of /etc/environment. For EC2/OpenStack instances we moved the detection of $public_ipv4 and $private_ipv4 directly into coreos-cloudinit so that it would work gracefully with both EC2-style metadata services and config drive. The old /usr/share/oem/bin/coreos-setup-environment shipped with those images hung if no metadata service was available, breaking config drive based OpenStack systems.

On the current alpha release you can continue generating /etc/environment with:

#cloud-config

write_files:
  - name: /etc/environment
    content: |
        COREOS_PUBLIC_IPV4=$public_ipv4
        COREOS_PRIVATE_IPV4=$private_ipv4

We never documented /etc/environment in the first place so that's why the change didn't get noted either. But a fair number of people have been depending on it so I may cut a 367.1.0 that essentially adds the above cloud config into cloudinit's default behavior on ec2. I would be interested to know what folks are using the old behavior for and whether it is important to preserve that feature.

[xh3b4sd]

Hey thanks for the response! You are right, there was never a documentation that says people can rely on the etc/environment file, but that approach was used in some examples demonstrating different features. So I guess people, and not only me, got used to it. I just can speak for myself. Knowing there is a file I can use to reference he internal IP was very nice, because you don't need to do things you can see here:

ExecStart=/bin/bash -c "HOST_IP=$(/bin/ifconfig eth0 | awk '/inet /{print $2}') && exec /usr/bin/docker run -rm -name %n -p $HOST_IP::6379 crosbymichael/redis"

Further the amount of data can be written using cloudinit is limited (to 4096 bytes?).

It would be really cool to be able to use the environment file further, but that decision should not rely on my personal habits.

[ibuildthecloud]

Oh no! This break me. I'll bring this up on the mailing list because it's a larger topic around simple service discovery.

[carmstrong]

We're using /etc/environment pretty extensively in Deis. We pass the host IP into our containers, so we need to easily grab it from somewhere. Having it in /etc/environment allows us to construct systemd units that use it with EnvironmentFile=/etc/environment.

https://github.com/deis/deis/blob/master/controller/systemd/deis-controller.service#L7,#L11

[marineam]

This is fixed in 367.1.0 which rolled out to alpha over the weekend.

[carmstrong]

This is fixed in 367.1.0 which rolled out to alpha over the weekend.

👍

[sukrit007]

Can we continue to use this file in our deployment or is this going to be a deprecated(supported for now) feature ?

[marineam]

You can continue to use it.

[brendanjerwin]

This issue appears to be happening (still? again?) in 522.2.0 and 494.5.0. /usr/share/oem/bin/coreos-setup-environment is not present.

[antgeo]

557.2.0 is missing /usr/share/oem/bin/coreos-setup-environment and /etc/environment

[xueshanf]

@antgeo I think it depends on the platforms. Vagrant still has /usr/share/oem/bin/coreos-setup-environment (CoreOS beta (584.0.0)) and /etc/environment is created. On AWS EC2 (557.2 and 584 for me), /usr/share/oem/bin/coreos-setup-environment doesn't exist, but /etc/environment does - it was created with the instance's public and private IP as part of the cloud-init. I used to have units that depend on coreos-setup-environment.service, now I use ConditionPathExists=/etc/environment/etc/environment on AWS EC2 instances.

[anapsix]

both /usr/share/oem/bin/coreos-setup-environment and /etc/environment are missing in 633.1.0 (beta)
adding a write_files to cloud-config helps, though..

write_files:
  - name: /etc/environment
    content: |
        COREOS_PUBLIC_IPV4=74.125.228.232
        COREOS_PRIVATE_IPV4=10.100.0.1

[philips]

@anapsix What platform are you on?

[anapsix]

@philips, running CoreOS 633.1.0 on bare metal

[philips]

@anapsix On bare metal we have no metadata service to query so we haven't created /etc/environment on those environments for quite some time. Are you seeing a regression on this from a previous version you were using?

[anapsix]

I see your point @philips. However /usr/share/oem/bin/coreos-setup-environment does not exist..
Besides, one may choose to implement such metadata services..
I could see using private_data_url to override defaults or ensure compatibility (e.g. for hybrid setup of bare-metal/aws/rackspace/your-favorite-cloud-that-does-not-support-private-data) instead of relying on proprietary AWS/Vargant private_data / user_data delivery mechanism.

Consider this:

coreos:
  private_data_url: http://provisioning.internal.company.net
  private_data_optional_token: cukyagNobrIa

During processing of cloud_config, coreos-setup-environment GET[s] private_data_url with it's hostname (and optional (auth?) token) in the params and retrieves the ENV.
Obviously, this functionality could be easily implemented via custom unit in cloud_config.. Imho, it makes sense for convenience / consistency sake to have it built in.

[dj-wasabi]

Hi,

I am at CoreOS stable (723.3.0) with the VMWare image and also /etc/environments and /usr/share/oem/bin/coreos-setup-environment are missing on my systems.

[ntquyen]

I have the same problem with CoreOS stable 723.3.0. $private_ipv4 is not loaded in cloud-init, /etc/environments and /usr/share/oem/bin/coreos-setup-environment are missing. Can we re-open this issue?

[mischief]

@ntquyen $private_ipv4 is not supported on all platforms. see the note at https://coreos.com/os/docs/latest/cloud-config.html#coreos.

please file a new issue if the problem exists on a platform where it is documented to work.