rkt run --hostname

[Derek Mahar]

What is the purpose of "rkt run --hostname"?  Where is this host name visible?  How is it accessible?  When I ran this in CoreOS, I expected to see the host name in /etc/hosts of the host, but it didn't appear there.

Thank you,

Derek  

[Brandon Philips]

UTS namespace: https://lwn.net/Articles/540087/

--
You received this message because you are subscribed to the Google Groups "rkt-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rkt-dev+u...@googlegroups.com.
To post to this group, send email to rkt...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/rkt-dev/69e918d5-6306-412f-b975-08e0f0a27503%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Euan Kemp]

To expand a little more on Brandon's response:

The hostname of a pod is visible in the `gethostname(2)` syscall (which the hostname command will display).

UTS namespacing allows a container to have a distinct hostname from the host system.

rkt also typically writes the hostname to the `/etc/hostname` file (though it might not if the file exists in the image iirc and that file is distinct from the syscall's/namespaces/kernel's value).

Adding it to /etc/hosts for 127.0.0.1 (in the cases rkt populates that) sounds like a good idea to me; there's an open issue related to that if you want to track or comment there. https://github.com/coreos/rkt/issues/2223

Best,

Euan

To view this discussion on the web visit https://groups.google.com/d/msgid/rkt-dev/CAD2oYtO-d05L%2BzmSm3ZjtQ0DouqJiysfDBH8ajhiMT9f5jWBbQ%40mail.gmail.com.

[Derek Mahar]

The article goes a bit over my head, but I think I at least understood the significance of "uname -a".  The lesson to me is that unlike "docker run --link", "rkt run --hostname" has no effect on DNS in the host or another pod or container.

I was a bit surprised that "ping postgres" inside the container didn't produce the same result as "ping localhost".

core@core-01 ~ $ sudo systemd-run /usr/bin/rkt run --hostname=postgres --net=host quay.io/coreos/postgres

core@core-01 ~ $ sudo rkt enter af7a88d0 /bin/sh

/ # cat /etc/hosts

127.0.0.1       localhost

127.0.1.1       buildroot

/ # uname -a

Linux postgres 4.6.4-coreos #1 SMP Thu Jul 14 20:36:35 UTC 2016 x86_64 GNU/Linux

/ # ping postgres

ping: bad address 'postgres'

/ # ping localhost -c 4

PING localhost (127.0.0.1): 56 data bytes

64 bytes from 127.0.0.1: seq=0 ttl=64 time=0.028 ms

64 bytes from 127.0.0.1: seq=1 ttl=64 time=0.038 ms

64 bytes from 127.0.0.1: seq=2 ttl=64 time=0.036 ms

64 bytes from 127.0.0.1: seq=3 ttl=64 time=0.034 ms

--- localhost ping statistics ---

4 packets transmitted, 4 packets received, 0% packet loss

round-trip min/avg/max = 0.028/0.034/0.038 ms

Derek

--

Derek Mahar
1.514.316.6736 Home
1.514.316.7348 Mobile
1.514.461.3650 x230 Work
102-1365 boulevard René-Lévesque Est
Montréal QC H2L 2M1
Canada

[Derek Mahar]

On 21 July 2016 at 17:13, Euan Kemp <euan...@coreos.com> wrote:

The hostname of a pod is visible in the `gethostname(2)` syscall (which the hostname command will display).

UTS namespacing allows a container to have a distinct hostname from the host system.

In my example:

/ # hostname

postgres

 

 

rkt also typically writes the hostname to the `/etc/hostname` file (though it might not if the file exists in the image iirc and that file is distinct from the syscall's/namespaces/kernel's value).

Yes:

/ # cat /etc/hostname

postgres

 

Adding it to /etc/hosts for 127.0.0.1 (in the cases rkt populates that) sounds like a good idea to me; there's an open issue related to that if you want to track or comment there. https://github.com/coreos/rkt/issues/2223

This explains the failure of "ping postgres" in my example.  I added comment https://github.com/coreos/rkt/issues/2223#issuecomment-234392817.

[Derek Mahar]

On Thursday, 21 July 2016 17:05:25 UTC-4, Brandon Philips wrote:

UTS namespace: https://lwn.net/Articles/540087/

All of the article in the series on namespaces is at https://lwn.net/Articles/531114/#series_index.  Given that I have limited knowledge of Linux kernel internals, I'll be happy if I at least understand the basic concepts.

Derek