Re: [gentoo-dev] rfc: /etc/hostname on gentoo

2016-08-31 Thread Daniel Campbell
On 08/28/2016 11:15 AM, William Hubbs wrote:
> Ok all,
> 
> here is what openrc-0.22 is going to do in terms of setting the host
> name.
> 
> If /etc/hostname exists, the first word of that file will be used as the
> host name.
> Otherwise, if the value is set in /etc/conf.d/hostname it will be used.
> Otherwise, OpenRC will not touch the hostname.
> 
> One advantage of this, on Linux, is that you can set your host name in
> the kernel and this setting will be respected.
> 
> Also, this means the script by default can run in containers if they
> allow overriding the hostname inside the container.
> 
> William
> 
I didn't see anyone else reply to this so I will. I think that's the
best way of supporting both without requiring (much) putzing around. If
a user changes /etc/conf.d/hostname and it doesn't change, the fix would
be to delete (or update) /etc/hostname and all is good in the world again.

Supporting kernel-level hostname as a side effect is even better. No
complaints here!

-- 
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] rfc: /etc/hostname on gentoo

2016-08-28 Thread William Hubbs
Ok all,

here is what openrc-0.22 is going to do in terms of setting the host
name.

If /etc/hostname exists, the first word of that file will be used as the
host name.
Otherwise, if the value is set in /etc/conf.d/hostname it will be used.
Otherwise, OpenRC will not touch the hostname.

One advantage of this, on Linux, is that you can set your host name in
the kernel and this setting will be respected.

Also, this means the script by default can run in containers if they
allow overriding the hostname inside the container.

William



signature.asc
Description: Digital signature


Re: [gentoo-dev] rfc: /etc/hostname on gentoo

2016-08-28 Thread Rich Freeman
On Sun, Aug 28, 2016 at 11:29 AM, Patrick Lauer  wrote:
>
> (and what abuse? it did exactly what it was supposed to do quite nicely,
> until it stopped doing that. Now you need to track state and hope you
> don't have race conditions ... )
>

You were tracking state before; in mtab.  It just isn't a terribly
great way to track state, especially when you start getting into
complex situations.  What happens when a service depends on a fuse
filesystem, which depends on a service?  And of course all the
situations where it is wrong, like when it is mounted read-only.

In the past we had kludges like iteration - try to unmount stuff, kill
stuff, and then try harder until it all dies, and then mount read-only
whatever got missed.  In theory today you can actually get messy
situations to cleanly shut down as long as you specify your
dependencies correctly (which you also need to start it all up).

I get that you can run a lot of systems without all the
complexity/rigor, but then you're pitting your ability to write
bug-free simple scripts against Redhat's ability to do QA on complex
scripts.  Sure, we aren't beholden to them, but half the point of FOSS
is to borrow stuff that works.

-- 
Rich



Re: [gentoo-dev] rfc: /etc/hostname on gentoo

2016-08-28 Thread Patrick Lauer
On 08/28/2016 04:21 PM, Michał Górny wrote:
> On Sun, 28 Aug 2016 14:34:20 +0200
> Patrick Lauer  wrote:
> 
>> On 08/28/2016 08:30 AM, Daniel Campbell wrote:
>>> On 08/24/2016 09:42 AM, Zac Medico wrote:  
 On 08/24/2016 09:33 AM, Michael Orlitzky wrote:  
>   * no benefit put forth so far, other than that it's the same file that
> systemd uses, which is true but not beneficial as far as I can tell  

 It's a de facto standard. Being different for the sake of being
 different is not a virtue in cases like this.
  
>>>
>>> And doing things because "everyone else does it" is dumb, because it
>>> precludes our ability to choose and makes us subject to the decisions
>>> made outside of our distribution. Of course, as a distro we're subject
>>> to outside decisions often, but what's the point of being a distro if
>>> you're doing things the same way everyone else does?  
>>
>>
>> At this point I feel the need to point at /etc/mtab and how it doesn't
>> work anymore. Or rather:
>>
>> In the old days it did *not* carry all mountpoints, so you could hide
>> things like /dev and /run so that "umount -a" would not screw you sideways.
>>
>> Then tools forgot to properly update mtab because hurr why u no symlink
>> to /proc/mounts (oh wait, /proc/self/mounts )
>>
>> So everyone migrated to /etc/mtab as a symlink (even OpenRC, because
>> everyone does it)
>>
>> ... and now if you still instincively use umount -a you unmount /run and
>> other bits, breaking lots of stuff (can't shutdown if OpenRC strongly
>> considers not having booted!)
>>
>>
>> That's why some of us are very resistant to change.
> 
> Which could be pretty much summarized as 'I'm unhappy because I was
> abusing the existing system to make "umount -a" not do what it was
> supposed to do, and I'm unhappy because now it started to work
> correctly'.
> 

"Just because it worked for 30 years doesn't mean it worked" ?

I like how you claim to be the authority on how umount is supposed to
behave ...

(and what abuse? it did exactly what it was supposed to do quite nicely,
until it stopped doing that. Now you need to track state and hope you
don't have race conditions ... )



Re: [gentoo-dev] rfc: /etc/hostname on gentoo

2016-08-28 Thread Michał Górny
On Sun, 28 Aug 2016 14:34:20 +0200
Patrick Lauer  wrote:

> On 08/28/2016 08:30 AM, Daniel Campbell wrote:
> > On 08/24/2016 09:42 AM, Zac Medico wrote:  
> >> On 08/24/2016 09:33 AM, Michael Orlitzky wrote:  
> >>>   * no benefit put forth so far, other than that it's the same file that
> >>> systemd uses, which is true but not beneficial as far as I can tell  
> >>
> >> It's a de facto standard. Being different for the sake of being
> >> different is not a virtue in cases like this.
> >>  
> > 
> > And doing things because "everyone else does it" is dumb, because it
> > precludes our ability to choose and makes us subject to the decisions
> > made outside of our distribution. Of course, as a distro we're subject
> > to outside decisions often, but what's the point of being a distro if
> > you're doing things the same way everyone else does?  
> 
> 
> At this point I feel the need to point at /etc/mtab and how it doesn't
> work anymore. Or rather:
> 
> In the old days it did *not* carry all mountpoints, so you could hide
> things like /dev and /run so that "umount -a" would not screw you sideways.
> 
> Then tools forgot to properly update mtab because hurr why u no symlink
> to /proc/mounts (oh wait, /proc/self/mounts )
> 
> So everyone migrated to /etc/mtab as a symlink (even OpenRC, because
> everyone does it)
> 
> ... and now if you still instincively use umount -a you unmount /run and
> other bits, breaking lots of stuff (can't shutdown if OpenRC strongly
> considers not having booted!)
> 
> 
> That's why some of us are very resistant to change.

Which could be pretty much summarized as 'I'm unhappy because I was
abusing the existing system to make "umount -a" not do what it was
supposed to do, and I'm unhappy because now it started to work
correctly'.

-- 
Best regards,
Michał Górny



pgp0w1KcBpfbo.pgp
Description: OpenPGP digital signature


Re: [gentoo-dev] rfc: /etc/hostname on gentoo

2016-08-28 Thread Rich Freeman
On Sun, Aug 28, 2016 at 8:34 AM, Patrick Lauer  wrote:
>
> Then tools forgot to properly update mtab because hurr why u no symlink
> to /proc/mounts (oh wait, /proc/self/mounts )
>
> So everyone migrated to /etc/mtab as a symlink (even OpenRC, because
> everyone does it)
>

I think containers were the final straw here (which strangely you do
not mention).  Good luck running openrc in a container with /etc/mtab
as a file, especially if you want to share /etc across multiple
containers.

Ultimately though this all comes down to the fact that files are a
pretty lousy way to store state of a running system, especially when
there are system calls to retrieve this state.

Sure, files are a nice place to store static configuration that gets
loaded into the state of a running system, since they're persistent.
The problem comes when software reads the files and assumes that they
ARE the state.

/etc should be for storing static configuration.  Processes shouldn't
generally be writing to anything there.  You should be able to mount
/etc read-only without much issue.  With the rise of containers and
configuration management and software-defined infrastructure and so on
this becomes increasingly important.

There is value in neither changing for the sake of change, or
remaining the same for the sake of the past.  Many historical
practices in the Unix world are inconsistent and it makes sense to
keep moving in the direction of making them consistent (like mtab,
having dhcpd modify /etc/resolv.conf, and so on).  Gentoo should make
similar sorts of changes (like not sticking the Gentoo repo in /usr,
and we probably shouldn't name it portage either).

There are also many historical practices in the Unix world that maybe
aren't pretty, but we probably ought not to change them just for the
sake of doing so without driving the change across distros (and I
think /etc/hostname strikes me as one of these; having more of the
host-level configuration in one place does make sense, but moreso if
everybody does it the same way).  Lots of distros actually try to move
configuration to one place, but they do it inconsistently and it seems
like somebody should be able to fix this (though you may find the
demand for consistency ends up getting satisfied by systemd to some
extent, simply due to its ubiquity).

I think williamh's approach of using hostname if it exists, and
falling back to conf.d is a pretty sane compromise.

-- 
Rich



Re: [gentoo-dev] rfc: /etc/hostname on gentoo

2016-08-28 Thread Patrick Lauer
On 08/28/2016 08:30 AM, Daniel Campbell wrote:
> On 08/24/2016 09:42 AM, Zac Medico wrote:
>> On 08/24/2016 09:33 AM, Michael Orlitzky wrote:
>>>   * no benefit put forth so far, other than that it's the same file that
>>> systemd uses, which is true but not beneficial as far as I can tell
>>
>> It's a de facto standard. Being different for the sake of being
>> different is not a virtue in cases like this.
>>
> 
> And doing things because "everyone else does it" is dumb, because it
> precludes our ability to choose and makes us subject to the decisions
> made outside of our distribution. Of course, as a distro we're subject
> to outside decisions often, but what's the point of being a distro if
> you're doing things the same way everyone else does?


At this point I feel the need to point at /etc/mtab and how it doesn't
work anymore. Or rather:

In the old days it did *not* carry all mountpoints, so you could hide
things like /dev and /run so that "umount -a" would not screw you sideways.

Then tools forgot to properly update mtab because hurr why u no symlink
to /proc/mounts (oh wait, /proc/self/mounts )

So everyone migrated to /etc/mtab as a symlink (even OpenRC, because
everyone does it)

... and now if you still instincively use umount -a you unmount /run and
other bits, breaking lots of stuff (can't shutdown if OpenRC strongly
considers not having booted!)


That's why some of us are very resistant to change.
> 
> mjo made a good point. What if the meaning of /etc/hostname changes? Or
> rather, what if the file gets moved altogether? All this effort to
> "follow the flock" will lead to higher maintenance burden. Symlinking it
> in pkg-postinst or some other mostly-automatic behavior makes sense
> because then a package "owns" the file. Should an update happen where
> the decision to follow the flock is rescinded, a revbump with the
> symlinking line removed would cleanly get rid of the symlink without any
> user intervention and next to zero maintenance burden.
> 
> /etc/conf.d/hostname sits alongside multiple other files, including
> hwclock, consolefont, localmount, fsck, modules, sshd, udev, etc. By
> glancing at it, it's clear that /etc/conf.d/ relates to system (or
> rather, package) configuration.
> 
> Considering that OpenRC puts package configuration there, and OpenRC (by
> default) looks for the hostname file in that directory, it's a
> non-issue. Why should OpenRC look elsewhere for configuration when
> there's already a place for it?
> 
> If systemd or other inits need it, then they should install the file and
> guess the initial value by sourcing /etc/conf.d/hostname. It's none of
> OpenRC's concern what other inits need.
> 




Re: [gentoo-dev] rfc: /etc/hostname on gentoo

2016-08-28 Thread Zac Medico
On 08/27/2016 11:30 PM, Daniel Campbell wrote:
> On 08/24/2016 09:42 AM, Zac Medico wrote:
>> On 08/24/2016 09:33 AM, Michael Orlitzky wrote:
>>>   * no benefit put forth so far, other than that it's the same file that
>>> systemd uses, which is true but not beneficial as far as I can tell
>>
>> It's a de facto standard. Being different for the sake of being
>> different is not a virtue in cases like this.
>>
> 
> And doing things because "everyone else does it" is dumb, because it
> precludes our ability to choose and makes us subject to the decisions
> made outside of our distribution. Of course, as a distro we're subject
> to outside decisions often, but what's the point of being a distro if
> you're doing things the same way everyone else does?

Is /etc/fstab dumb? How about /etc/hosts? Should we use something
different, just because we can?
-- 
Thanks,
Zac



Re: [gentoo-dev] rfc: /etc/hostname on gentoo

2016-08-28 Thread Daniel Campbell
On 08/27/2016 11:48 PM, Michał Górny wrote:
> On Sat, 27 Aug 2016 23:30:09 -0700
> Daniel Campbell  wrote:
> 
>> On 08/24/2016 09:42 AM, Zac Medico wrote:
>>> On 08/24/2016 09:33 AM, Michael Orlitzky wrote:  
   * no benefit put forth so far, other than that it's the same file that
 systemd uses, which is true but not beneficial as far as I can tell  
>>>
>>> It's a de facto standard. Being different for the sake of being
>>> different is not a virtue in cases like this.
>>>   
>>
>> And doing things because "everyone else does it" is dumb, because it
>> precludes our ability to choose and makes us subject to the decisions
>> made outside of our distribution. Of course, as a distro we're subject
>> to outside decisions often, but what's the point of being a distro if
>> you're doing things the same way everyone else does?
> 
> And doing things different just because "we can" is even more dumb,
> because it precludes our ability to offer users consistent environment
> and makes us subject to the decisions made by random Gentoo developers
> long time ago. Of course, as a distro we're subject to single developer
> decisions often, but what's the point of being a distro if you are
> bound to bad decisions made in the past by a single person?
> 
> Not saying that I care but just pointing out how dumb this
> argumentation is.
> 
Well, the thing is that -- on a Gentoo system -- /etc/conf.d/ is pretty
consistent. We still ship some things in their typical location, like
fstab, locale.gen, etc, but those don't directly relate to OpenRC and
aren't (to my knowledge) part of its problem space. The files in
/etc/conf.d/ that don't relate to system settings are shortcuts to
setting daemon options instead of shoving them into the scripts.

So if we go with /etc/hostname, it's inconsistent with what we (Gentoo)
do but in line with most others. The inverse is also true, putting us in
a catch-22. The "do both" will attract ire from some of us, but the
prior suggestion to throw it into an ebuild phase will largely avoid
this bikeshedding. Whether or not the phase can do that *cleanly* and
*correctly* is another matter for a different thread, but I do think
Portage (the openrc or systemd/docker/whatever package(s)) should be
handling that on Gentoo in order to reduce clutter and confusion.

There is one technical concern, though... If the OpenRC ebuild symlinks
or otherwise owns /etc/hostname and the user switches to a systemd
profile, would Portage be smart enough to leave /etc/hostname alone and
let the packages switch ownership of the file? They create an ownership
block otherwise, as (I assume) systemd would also own the file. Other
inits may, as well, and I'm fairly sure you can run Gentoo without
OpenRC at all. Would we expect the user to create the file before
switching profiles, and not permit OpenRC to own the file?

-- off-topic below --

I think "because we can", in the right circumstances, is a great reason
to do something. That's how ideas are tested and come to fruition.
Distributions need to have some sort of vision or strongly held belief
in order to form a good following, or software that exemplifies said
vision. Collaboration is important, sure, but design-by-committee is
proven to be a terrible process that's prone to analysis paralysis,
bikeshedding, and encourages a culture of yes-men (and/or yes-women for
those who want PC speech). There is a middle ground where people work
together when it's beneficial and makes sense, and go their own way on
certain decisions. It's what created the distribution model in the first
place.

For the most part, the "we should do what everyone else is doing" train
is slowly reducing most distribution differences to a package manager
and some default backgrounds. I can't speak for you or other people but
I personally enjoy technical diversity. The distribution model allows
for many different approaches to be followed: things from Gentoo to
Slackware, Debian to Arch, Fedora, Gobolinux, CRUX, SuSE, etc. Doing
things "because we can" is a feature, imo, not a bug. A consolidated
GNU/Linux world would be terrible and far less colorful.
-- 
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] rfc: /etc/hostname on gentoo

2016-08-27 Thread M. J. Everitt
On 28/08/16 07:30, Daniel Campbell wrote:
> On 08/24/2016 09:42 AM, Zac Medico wrote:
>> On 08/24/2016 09:33 AM, Michael Orlitzky wrote:
>>>   * no benefit put forth so far, other than that it's the same file that
>>> systemd uses, which is true but not beneficial as far as I can tell
>> It's a de facto standard. Being different for the sake of being
>> different is not a virtue in cases like this.
>>
> And doing things because "everyone else does it" is dumb, because it
> precludes our ability to choose and makes us subject to the decisions
> made outside of our distribution. Of course, as a distro we're subject
> to outside decisions often, but what's the point of being a distro if
> you're doing things the same way everyone else does?
>
> mjo made a good point. What if the meaning of /etc/hostname changes? Or
> rather, what if the file gets moved altogether? All this effort to
> "follow the flock" will lead to higher maintenance burden. Symlinking it
> in pkg-postinst or some other mostly-automatic behavior makes sense
> because then a package "owns" the file. Should an update happen where
> the decision to follow the flock is rescinded, a revbump with the
> symlinking line removed would cleanly get rid of the symlink without any
> user intervention and next to zero maintenance burden.
>
> /etc/conf.d/hostname sits alongside multiple other files, including
> hwclock, consolefont, localmount, fsck, modules, sshd, udev, etc. By
> glancing at it, it's clear that /etc/conf.d/ relates to system (or
> rather, package) configuration.
>
> Considering that OpenRC puts package configuration there, and OpenRC (by
> default) looks for the hostname file in that directory, it's a
> non-issue. Why should OpenRC look elsewhere for configuration when
> there's already a place for it?
>
> If systemd or other inits need it, then they should install the file and
> guess the initial value by sourcing /etc/conf.d/hostname. It's none of
> OpenRC's concern what other inits need.
+1



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] rfc: /etc/hostname on gentoo

2016-08-27 Thread Michał Górny
On Sat, 27 Aug 2016 23:30:09 -0700
Daniel Campbell  wrote:

> On 08/24/2016 09:42 AM, Zac Medico wrote:
> > On 08/24/2016 09:33 AM, Michael Orlitzky wrote:  
> >>   * no benefit put forth so far, other than that it's the same file that
> >> systemd uses, which is true but not beneficial as far as I can tell  
> > 
> > It's a de facto standard. Being different for the sake of being
> > different is not a virtue in cases like this.
> >   
> 
> And doing things because "everyone else does it" is dumb, because it
> precludes our ability to choose and makes us subject to the decisions
> made outside of our distribution. Of course, as a distro we're subject
> to outside decisions often, but what's the point of being a distro if
> you're doing things the same way everyone else does?

And doing things different just because "we can" is even more dumb,
because it precludes our ability to offer users consistent environment
and makes us subject to the decisions made by random Gentoo developers
long time ago. Of course, as a distro we're subject to single developer
decisions often, but what's the point of being a distro if you are
bound to bad decisions made in the past by a single person?

Not saying that I care but just pointing out how dumb this
argumentation is.

-- 
Best regards,
Michał Górny



pgprvWW7zInkM.pgp
Description: OpenPGP digital signature


Re: [gentoo-dev] rfc: /etc/hostname on gentoo

2016-08-27 Thread Daniel Campbell
On 08/24/2016 09:42 AM, Zac Medico wrote:
> On 08/24/2016 09:33 AM, Michael Orlitzky wrote:
>>   * no benefit put forth so far, other than that it's the same file that
>> systemd uses, which is true but not beneficial as far as I can tell
> 
> It's a de facto standard. Being different for the sake of being
> different is not a virtue in cases like this.
> 

And doing things because "everyone else does it" is dumb, because it
precludes our ability to choose and makes us subject to the decisions
made outside of our distribution. Of course, as a distro we're subject
to outside decisions often, but what's the point of being a distro if
you're doing things the same way everyone else does?

mjo made a good point. What if the meaning of /etc/hostname changes? Or
rather, what if the file gets moved altogether? All this effort to
"follow the flock" will lead to higher maintenance burden. Symlinking it
in pkg-postinst or some other mostly-automatic behavior makes sense
because then a package "owns" the file. Should an update happen where
the decision to follow the flock is rescinded, a revbump with the
symlinking line removed would cleanly get rid of the symlink without any
user intervention and next to zero maintenance burden.

/etc/conf.d/hostname sits alongside multiple other files, including
hwclock, consolefont, localmount, fsck, modules, sshd, udev, etc. By
glancing at it, it's clear that /etc/conf.d/ relates to system (or
rather, package) configuration.

Considering that OpenRC puts package configuration there, and OpenRC (by
default) looks for the hostname file in that directory, it's a
non-issue. Why should OpenRC look elsewhere for configuration when
there's already a place for it?

If systemd or other inits need it, then they should install the file and
guess the initial value by sourcing /etc/conf.d/hostname. It's none of
OpenRC's concern what other inits need.
-- 
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] rfc: /etc/hostname on gentoo

2016-08-24 Thread Cédric Krier
On 2016-08-24 22:23, Consus wrote:
> On 09:42 Wed 24 Aug, Zac Medico wrote:
> > On 08/24/2016 09:33 AM, Michael Orlitzky wrote:
> > >   * no benefit put forth so far, other than that it's the same file that
> > > systemd uses, which is true but not beneficial as far as I can tell
> > 
> > It's a de facto standard. Being different for the sake of being
> > different is not a virtue in cases like this.
> 
> AFAIR /etc/hostname works even in OpenBSD.

On OpenBSD, it is stored in /etc/myname

-- 
Cédric Krier



Re: [gentoo-dev] rfc: /etc/hostname on gentoo

2016-08-24 Thread Consus
On 09:42 Wed 24 Aug, Zac Medico wrote:
> On 08/24/2016 09:33 AM, Michael Orlitzky wrote:
> >   * no benefit put forth so far, other than that it's the same file that
> > systemd uses, which is true but not beneficial as far as I can tell
> 
> It's a de facto standard. Being different for the sake of being
> different is not a virtue in cases like this.

AFAIR /etc/hostname works even in OpenBSD.



Re: [gentoo-dev] rfc: /etc/hostname on gentoo

2016-08-24 Thread Zac Medico
On 08/24/2016 09:33 AM, Michael Orlitzky wrote:
>   * no benefit put forth so far, other than that it's the same file that
> systemd uses, which is true but not beneficial as far as I can tell

It's a de facto standard. Being different for the sake of being
different is not a virtue in cases like this.
-- 
Thanks,
Zac



Re: [gentoo-dev] rfc: /etc/hostname on gentoo

2016-08-24 Thread Michael Orlitzky
On 08/24/2016 12:22 PM, Zac Medico wrote:
> 
> Seems like something we could automate in pkg_posinst of the openrc
> ebuild, but probably also deserves a news item.
> 

Or in the systemd ebuild =P

I'll drop this, I've made my peace:

  * adding another configuration file is inconsistent with every other
openrc service

  * having two configuration files is confusing, since it looks like one
of them just doesn't work if the other is populated

  * two code paths to maintain, and you'll eventually want to deprecate
the consistent /etc/conf.d location (more news items...)

  * appropriating someone else's file like we did with LINGUAS can
cause problems if they decide to change its meaning

  * handbook and other documentation updates need to happen

  * no benefit put forth so far, other than that it's the same file that
systemd uses, which is true but not beneficial as far as I can tell




Re: [gentoo-dev] rfc: /etc/hostname on gentoo

2016-08-24 Thread Zac Medico
On 08/24/2016 09:06 AM, Michael Orlitzky wrote:
> On 08/24/2016 11:49 AM, Mike Gilbert wrote:
>>
>> You're right that the orignal purpose of the change has been debunked.
>>
>> So, starting over: one real benefit would be cross-compatibility with
>> systemd. It's one less thing people would need to reconfigure when
>> migrating to/from openrc.
>>
> 
> I still have to take the contents of /etc/conf.d/hostname and copy it
> into /etc/hostname. I can do it now, or I can do it when I switch to
> systemd -- but I still have to do it once.

Seems like something we could automate in pkg_posinst of the openrc
ebuild, but probably also deserves a news item.
-- 
Thanks,
Zac



Re: [gentoo-dev] rfc: /etc/hostname on gentoo

2016-08-24 Thread Michael Orlitzky
On 08/24/2016 11:49 AM, Mike Gilbert wrote:
> 
> You're right that the orignal purpose of the change has been debunked.
> 
> So, starting over: one real benefit would be cross-compatibility with
> systemd. It's one less thing people would need to reconfigure when
> migrating to/from openrc.
> 

I still have to take the contents of /etc/conf.d/hostname and copy it
into /etc/hostname. I can do it now, or I can do it when I switch to
systemd -- but I still have to do it once.





Re: [gentoo-dev] rfc: /etc/hostname on gentoo

2016-08-24 Thread Mike Gilbert
On Wed, Aug 24, 2016 at 7:42 AM, Michael Orlitzky  wrote:
> On 08/24/2016 07:37 AM, Daniel Campbell wrote:
>>
>> I imagine _someone_ out there wants it, otherwise we wouldn't be
>> discussing it.
>
> The thread started out proposing it as a solution to a docker problem
> that, it turns out, isn't a problem. Why are we still trying to fixing
> something that isn't broken? Maybe I'm losing it, but nowhere in the
> whole thread has anyone given a single reason why this might be useful.

You're right that the orignal purpose of the change has been debunked.

So, starting over: one real benefit would be cross-compatibility with
systemd. It's one less thing people would need to reconfigure when
migrating to/from openrc.

And before anyone starts an argument about it, I don't care what your
opinion on systemd is. I'm just throwing this out there as an actual
benefit of adding support for /etc/hostname to openrc.



Re: [gentoo-dev] rfc: /etc/hostname on gentoo

2016-08-24 Thread Rich Freeman
On Wed, Aug 24, 2016 at 7:42 AM, Michael Orlitzky  wrote:
> On 08/24/2016 07:37 AM, Daniel Campbell wrote:
>>
>> I imagine _someone_ out there wants it, otherwise we wouldn't be
>> discussing it.
>
> The thread started out proposing it as a solution to a docker problem
> that, it turns out, isn't a problem. Why are we still trying to fixing
> something that isn't broken? Maybe I'm losing it, but nowhere in the
> whole thread has anyone given a single reason why this might be useful.
>

++

The need for /etc/hostname isn't really a container issue either in
general.  It isn't like containers need that file any more than
anything else.  The original proposed issue wouldn't be unlike
somebody 20 years ago saying that they need their system with an nfs
root filesystem to know the hostname of the nfs server.  There are
certainly ways to accomplish this by having the server stick a file
somewhere, but it is a bit orthogonal to whether the nfs server uses
/etc/hostname to set its hostname.

-- 
Rich



Re: [gentoo-dev] rfc: /etc/hostname on gentoo

2016-08-24 Thread Michael Orlitzky
On 08/24/2016 07:37 AM, Daniel Campbell wrote:
>
> I imagine _someone_ out there wants it, otherwise we wouldn't be
> discussing it.

The thread started out proposing it as a solution to a docker problem
that, it turns out, isn't a problem. Why are we still trying to fixing
something that isn't broken? Maybe I'm losing it, but nowhere in the
whole thread has anyone given a single reason why this might be useful.




Re: [gentoo-dev] rfc: /etc/hostname on gentoo

2016-08-24 Thread Daniel Campbell
On 08/24/2016 04:17 AM, Michael Orlitzky wrote:
> On 08/24/2016 03:12 AM, Daniel Campbell wrote:
>>>
>> That seems like a fair compromise. Those who want /etc/hostname get to
>> use it, those who don't won't need to change anything.
>>
> 
> Does anyone want it? This feels like a legacy backwards compatibility
> hack that we're adding after it's obsolete, to support no one. Is there
> a single use case for it?
> 
> 
I imagine _someone_ out there wants it, otherwise we wouldn't be
discussing it.

But those of us who use /etc/conf.d/hostname shouldn't need to change
anything for a package or two that insists on /etc/hostname.

I've not yet learned/used containers so I don't personally have a use
for /etc/hostname.
-- 
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] rfc: /etc/hostname on gentoo

2016-08-24 Thread Michael Orlitzky
On 08/24/2016 03:12 AM, Daniel Campbell wrote:
>>
> That seems like a fair compromise. Those who want /etc/hostname get to
> use it, those who don't won't need to change anything.
> 

Does anyone want it? This feels like a legacy backwards compatibility
hack that we're adding after it's obsolete, to support no one. Is there
a single use case for it?




Re: [gentoo-dev] rfc: /etc/hostname on gentoo

2016-08-24 Thread Rich Freeman
On Wed, Aug 24, 2016 at 2:52 AM, Christian Kniep  wrote:
> Hey there,
>
> as for the /etc/hostname when sharing /etc/ as a volume… This ain’t a
> problem as /etc/hostname is taken care of by the docker-engine (in previous
> versions they used it to discover other hosts).
>

Docker isn't the only container manager out there...  Hopefully they
only populate it if it already exists.  But, yes, you can bind mount
an individual file.

In any case, my concern isn't so much with using /etc/hostname to SET
the hostname.  My concern is more with having other processes read
/etc/hostname to determine the hostname.  It just isn't the right way
to do things.

Maybe it should just be installed chmod 600 by default?  :)

-- 
Rich



Re: [gentoo-dev] rfc: /etc/hostname on gentoo

2016-08-24 Thread Daniel Campbell
On 08/23/2016 12:57 PM, William Hubbs wrote:
> On Tue, Aug 23, 2016 at 02:45:20PM -0400, Rich Freeman wrote:
>> Symlinking /proc into /etc/hostname is still useful because it not
>> only handles container hostnames (keep in mind that two containers
>> could share the same /etc), but it also covers cases where the
>> hostname changes, and it doesn't require writing to etc (which in
>> general shouldn't be used to store state).
>>
>> The people who are saying /etc/hostname shouldn't really exist are
>> completely right.  However, if for whatever reason we did want to
>> provide it for compatibility (just like mtab), then a symlink to /proc
>> at least ensures it returns the same answer as the system call.
> 
> My understanding of /etc/hostname is it is a widely used standard for
> storing the name of the host and it is used to set the name of the host
> on bootup. I just ran a google search of /etc/hostname, and it gets a
> number of hits.
> 
> Here is what I'm looking at in OpenRC:
> 
> I am planning to change the logic in /etc/init.d/hostname so that if
> /etc/hostname exists, the first word out of that file will be used as
> the hostname rather than any setting in /etc/conf.d/hostname. If you
> don't want /etc/hostname, just don't create it and the settings from
> /etc/conf.d/hostname will still be used.
> 
> It turns out this has nothing to do with the Docker situation I brought
> up. Whether or not a docker container should be able to access the
> hostname of the host it is running on is a separate question.
> 
> William
> 
That seems like a fair compromise. Those who want /etc/hostname get to
use it, those who don't won't need to change anything.

Will other packages be able to modify or create the file and thus
jeopardize anything?

-- 
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] rfc: /etc/hostname on gentoo

2016-08-23 Thread Christian Kniep
On second thought I put in the —hostname flags, to make it clearer. Before
it was a digest from the container-id, which was not telling in the example…

$ docker run -d -v /etc/ --name host1 --hostname host1 ubuntu tail -f /dev/null
6a85473421368051efec9b6f55991a5c3b4150c575a0724695cdad99f7a26e06
$ docker run -ti --volumes-from host1 --name host2 --hostname host2 ubuntu bash
root@host2:/# cat /etc/hostname
host2
root@host2:/#

Cheers
Christian



On 24 August 2016 at 08:52:15, Christian Kniep (ckn...@gaikai.com) wrote:

Hey there,

as for the /etc/hostname when sharing /etc/ as a volume… This ain’t a
problem as /etc/hostname is taken care of by the docker-engine (in previous
versions they used it to discover other hosts).

As you can see in the snippet below, /etc/hostname is local, while it is
possible to create a file test in /etc/, which is also present in the
container I mounted the volumes from.

$ docker run -d -v /etc/ --name host1 ubuntu tail -f /dev/null
3f90929cc4b761096b600d5e2b02c61ec2e26ba74167a71b2da73d28d2274dba
$ docker run -ti --volumes-from host1 --name host2 ubuntu bash
root@dd0167aec38e:/# cat /etc/hostname
dd0167aec38e
root@dd0167aec38e:/# echo "huhu" > /etc/test
root@dd0167aec38e:/# exit
$ docker exec host1 cat /etc/test

To me the /etc/hostname problem is just to make Gentoo play nice among
other distros. As described below, this is (IMHO) a sound solution to
propagate the underlying hostname to the containers.

Cheers Christian

On 23 August 2016 at 23:22:44, William Hubbs (willi...@gentoo.org) wrote:

On Tue, Aug 23, 2016 at 04:25:30PM -0400, Rich Freeman wrote:
> On Tue, Aug 23, 2016 at 3:57 PM, William Hubbs 
wrote:
> >
> > I am planning to change the logic in /etc/init.d/hostname so that if
> > /etc/hostname exists, the first word out of that file will be used as
> > the hostname rather than any setting in /etc/conf.d/hostname. If you
> > don't want /etc/hostname, just don't create it and the settings from
> > /etc/conf.d/hostname will still be used.
> >
>
> Keep in mind that this is potentially problematic for a few reasons:
>
> 1. The hostname could change after openrc is done setting it. If it
> does, a program that reads /etc/hostname won't get the real hostname.

This is also true for /etc/conf.d/hostname, so I don't see the problem
here.

> 2. You could have a situation where multiple containers use the same
> /etc. Obviously in this situation you wouldn't want to store the
> hostname anywhere in /etc unless you wanted them to all have the same
> hostname. It would be better to obtain it from dhcp, or to have it
> set before init is run during initialization.


/etc/init.d/hostname doesn't run inside containers, so this is not
relevant.

> The main danger is people not thinking of all the scenarios. I'm not
> quite sure why we even need /etc/hostname now given these issues and
> the fact that we've apparently gotten along for a long time without
> it. Have we ever gotten around to making /etc/mtab a symlink yet? I
> know it wasn't for a long time. It seems like we are moving away from
> container support when we should be moving towards it if anything...

Container support is controlled by the keyword line in dependencies.
OpenRC can detect most containers, so if you put the proper keywords on
that line and RC_SYS is set correctly or the container is autodetected
properly, openrc will not run the scripts that it shouldn't run in the
container.

Yes, /etc/mtab is a symlink by default now; that was taken care of a
while back.

William


Re: [gentoo-dev] rfc: /etc/hostname on gentoo

2016-08-23 Thread Christian Kniep
Hey there,

as for the /etc/hostname when sharing /etc/ as a volume… This ain’t a
problem as /etc/hostname is taken care of by the docker-engine (in previous
versions they used it to discover other hosts).

As you can see in the snippet below, /etc/hostname is local, while it is
possible to create a file test in /etc/, which is also present in the
container I mounted the volumes from.

$ docker run -d -v /etc/ --name host1 ubuntu tail -f /dev/null
3f90929cc4b761096b600d5e2b02c61ec2e26ba74167a71b2da73d28d2274dba
$ docker run -ti --volumes-from host1 --name host2 ubuntu bash
root@dd0167aec38e:/# cat /etc/hostname
dd0167aec38e
root@dd0167aec38e:/# echo "huhu" > /etc/test
root@dd0167aec38e:/# exit
$ docker exec host1 cat /etc/test

To me the /etc/hostname problem is just to make Gentoo play nice among
other distros. As described below, this is (IMHO) a sound solution to
propagate the underlying hostname to the containers.

Cheers Christian


On 23 August 2016 at 23:22:44, William Hubbs (willi...@gentoo.org) wrote:

On Tue, Aug 23, 2016 at 04:25:30PM -0400, Rich Freeman wrote:
> On Tue, Aug 23, 2016 at 3:57 PM, William Hubbs 
wrote:
> >
> > I am planning to change the logic in /etc/init.d/hostname so that if
> > /etc/hostname exists, the first word out of that file will be used as
> > the hostname rather than any setting in /etc/conf.d/hostname. If you
> > don't want /etc/hostname, just don't create it and the settings from
> > /etc/conf.d/hostname will still be used.
> >
>
> Keep in mind that this is potentially problematic for a few reasons:
>
> 1. The hostname could change after openrc is done setting it. If it
> does, a program that reads /etc/hostname won't get the real hostname.

This is also true for /etc/conf.d/hostname, so I don't see the problem
here.

> 2. You could have a situation where multiple containers use the same
> /etc. Obviously in this situation you wouldn't want to store the
> hostname anywhere in /etc unless you wanted them to all have the same
> hostname. It would be better to obtain it from dhcp, or to have it
> set before init is run during initialization.


/etc/init.d/hostname doesn't run inside containers, so this is not
relevant.

> The main danger is people not thinking of all the scenarios. I'm not
> quite sure why we even need /etc/hostname now given these issues and
> the fact that we've apparently gotten along for a long time without
> it. Have we ever gotten around to making /etc/mtab a symlink yet? I
> know it wasn't for a long time. It seems like we are moving away from
> container support when we should be moving towards it if anything...

Container support is controlled by the keyword line in dependencies.
OpenRC can detect most containers, so if you put the proper keywords on
that line and RC_SYS is set correctly or the container is autodetected
properly, openrc will not run the scripts that it shouldn't run in the
container.

Yes, /etc/mtab is a symlink by default now; that was taken care of a
while back.

William


Re: [gentoo-dev] rfc: /etc/hostname on gentoo

2016-08-23 Thread William Hubbs
On Tue, Aug 23, 2016 at 04:25:30PM -0400, Rich Freeman wrote:
> On Tue, Aug 23, 2016 at 3:57 PM, William Hubbs  wrote:
> >
> > I am planning to change the logic in /etc/init.d/hostname so that if
> > /etc/hostname exists, the first word out of that file will be used as
> > the hostname rather than any setting in /etc/conf.d/hostname. If you
> > don't want /etc/hostname, just don't create it and the settings from
> > /etc/conf.d/hostname will still be used.
> >
> 
> Keep in mind that this is potentially problematic for a few reasons:
> 
> 1.  The hostname could change after openrc is done setting it.  If it
> does, a program that reads /etc/hostname won't get the real hostname.
 
 This is also true for /etc/conf.d/hostname, so I don't see the problem
 here.

> 2.  You could have a situation where multiple containers use the same
> /etc.  Obviously in this situation you wouldn't want to store the
> hostname anywhere in /etc unless you wanted them to all have the same
> hostname.  It would be better to obtain it from dhcp, or to have it
> set before init is run during initialization.

/etc/init.d/hostname doesn't run inside containers, so this is not
relevant.

> The main danger is people not thinking of all the scenarios.  I'm not
> quite sure why we even need /etc/hostname now given these issues and
> the fact that we've apparently gotten along for a long time without
> it.  Have we ever gotten around to making /etc/mtab a symlink yet?  I
> know it wasn't for a long time.  It seems like we are moving away from
> container support when we should be moving towards it if anything...

Container support is controlled by the keyword line in dependencies.
OpenRC can detect most containers, so if you put the proper keywords on
that line and RC_SYS is set correctly or the container is autodetected
properly, openrc will not run the scripts that it shouldn't run in the
container.

Yes, /etc/mtab is a symlink by default now; that was taken care of a
while back.

William



signature.asc
Description: Digital signature


Re: [gentoo-dev] rfc: /etc/hostname on gentoo

2016-08-23 Thread Rich Freeman
On Tue, Aug 23, 2016 at 3:57 PM, William Hubbs  wrote:
>
> I am planning to change the logic in /etc/init.d/hostname so that if
> /etc/hostname exists, the first word out of that file will be used as
> the hostname rather than any setting in /etc/conf.d/hostname. If you
> don't want /etc/hostname, just don't create it and the settings from
> /etc/conf.d/hostname will still be used.
>

Keep in mind that this is potentially problematic for a few reasons:

1.  The hostname could change after openrc is done setting it.  If it
does, a program that reads /etc/hostname won't get the real hostname.

2.  You could have a situation where multiple containers use the same
/etc.  Obviously in this situation you wouldn't want to store the
hostname anywhere in /etc unless you wanted them to all have the same
hostname.  It would be better to obtain it from dhcp, or to have it
set before init is run during initialization.

The main danger is people not thinking of all the scenarios.  I'm not
quite sure why we even need /etc/hostname now given these issues and
the fact that we've apparently gotten along for a long time without
it.  Have we ever gotten around to making /etc/mtab a symlink yet?  I
know it wasn't for a long time.  It seems like we are moving away from
container support when we should be moving towards it if anything...

-- 
Rich



Re: [gentoo-dev] rfc: /etc/hostname on gentoo

2016-08-23 Thread Marc Schiffbauer
* Rich Freeman schrieb am 22.08.16 um 20:29 Uhr:
> On Mon, Aug 22, 2016 at 1:51 PM, Sven Vermeulen  wrote:
> >
> > Yes, wouldn't the Docker project be happy to take on a patch that uses
> > gethostname() or so?
> >
> 
> This might be another option: symlink to /proc/sys/kernel/hostname

I think on boot the hostname is actually set from the contents of that 
file. With this approach that cat would bite itself into its tail ;-)

-Marc

-- 
0xCA3E7BF67F979BE5 - F7FB 78F7 7CC3 79F6 DF07
 6E9E CA3E 7BF6 7F97 9BE5


signature.asc
Description: PGP signature


Re: [gentoo-dev] rfc: /etc/hostname on gentoo

2016-08-23 Thread William Hubbs
On Tue, Aug 23, 2016 at 02:45:20PM -0400, Rich Freeman wrote:
> Symlinking /proc into /etc/hostname is still useful because it not
> only handles container hostnames (keep in mind that two containers
> could share the same /etc), but it also covers cases where the
> hostname changes, and it doesn't require writing to etc (which in
> general shouldn't be used to store state).
> 
> The people who are saying /etc/hostname shouldn't really exist are
> completely right.  However, if for whatever reason we did want to
> provide it for compatibility (just like mtab), then a symlink to /proc
> at least ensures it returns the same answer as the system call.

My understanding of /etc/hostname is it is a widely used standard for
storing the name of the host and it is used to set the name of the host
on bootup. I just ran a google search of /etc/hostname, and it gets a
number of hits.

Here is what I'm looking at in OpenRC:

I am planning to change the logic in /etc/init.d/hostname so that if
/etc/hostname exists, the first word out of that file will be used as
the hostname rather than any setting in /etc/conf.d/hostname. If you
don't want /etc/hostname, just don't create it and the settings from
/etc/conf.d/hostname will still be used.

It turns out this has nothing to do with the Docker situation I brought
up. Whether or not a docker container should be able to access the
hostname of the host it is running on is a separate question.

William


signature.asc
Description: Digital signature


Re: [gentoo-dev] rfc: /etc/hostname on gentoo

2016-08-23 Thread Rich Freeman
On Tue, Aug 23, 2016 at 8:26 AM, Christian Kniep  wrote:
> Hey Rich,
>
> nice idea, but unfortunately this provides the hostname of the container
> itself.
>

As it should.  /etc/hostname inside a container should contain the
hostname of the container.  It shouldn't actually be possible to
determine the hostname of the host from inside a container, or even
that there is a host outside the container.

You could still bind-mount it into the container if you wanted to in
order to leak this information into the container.  That is up to you,
but I would suggest that openrc should not by default expose host
information into the container.

Symlinking /proc into /etc/hostname is still useful because it not
only handles container hostnames (keep in mind that two containers
could share the same /etc), but it also covers cases where the
hostname changes, and it doesn't require writing to etc (which in
general shouldn't be used to store state).

The people who are saying /etc/hostname shouldn't really exist are
completely right.  However, if for whatever reason we did want to
provide it for compatibility (just like mtab), then a symlink to /proc
at least ensures it returns the same answer as the system call.

--
Rich



Re: [gentoo-dev] rfc: /etc/hostname on gentoo

2016-08-23 Thread Michael Orlitzky
My mental model is wrong so I'm probably about to say something stupid.
I'm not familiar with the way docker works so bear with me...


On 08/23/2016 03:01 AM, Christian Kniep wrote:
> 
> ###
> $ docker service create --name nginx --mode=global -e 
> SERVICE_HOSTNAME=$(hostname -f)  nginx
> ###

This looks like it would set the SERVICE_HOSTNAME environment variable
inside the container to the hostname that you're running the command on.


> Each of the tasks (a container to-be-run on one of the nodes) will
> now find an environment variable SERVICE_HOSTNAME, but it will a) be
> the same among all containers and b) it will show the hostname from
> which the service was created.
> 

Cool, I'm not confused yet.


> On docker host with non-gentoo I can just run this (e.g. on my DockerForMac):
> 
> $ docker service create --mount 
> type=bind,source=/etc/hostname,target=/etc/docker-hostname:ro --name nginx  
> nginx

Doesn't this mount the /etc/hostname file, from the host that you run
the command on, to the /etc/docker-hostname file within the container?
If so, it would have the same problem as the environment variable, so
it's got to be doing something else.

...Is it the other way around? Does it mount /etc/hostname from the
container somewhere on the outside?


> By doing so I am able to determine on which host I am running on
> each tasks without much hassle.
> 
> $ docker exec -ti 56e8b2eaecc3 cat /etc/docker-hostname
> 

If this runs *inside* the container, then instead of using "cat" on a
file, why not just run "hostname"? That should give you the hostname of
the machine it ran on. For example,

  docker exec -ti 56e8b2eaecc3 hostname

But, if that runs outside the container, then... I need a better
understanding of what's going on before I start throwing out ideas.




Re: [gentoo-dev] rfc: /etc/hostname on gentoo

2016-08-23 Thread Christian Kniep
Hey Rich,

nice idea, but unfortunately this provides the hostname of the container
itself.

$ docker run -ti -v /proc/sys/kernel/hostname:/etc/docker-hostname:ro nginx bash
root@bea048d42fc3:/# cat /etc/docker-hostname
bea048d42fc3
root@bea048d42fc3:/#

Without digging deep into it I reckon that the proc (and the sys)
filesystems are treated differently, to be sure that each container is in a
distinct /proc filesystem.

Cheers Christian




On 23 August 2016 at 12:01:49, Rich Freeman (ri...@gentoo.org) wrote:

On Tue, Aug 23, 2016 at 2:39 AM, Daniel Campbell  wrote:
>
> It makes a bit more sense to rely on previous configuration
> (/etc/conf.d/hostname) and write a tiny 'script' that populates
> /etc/hostname. bash could do it (naively) in two lines:
>
> source /etc/conf.d/hostname
> echo "$hostname" > /etc/hostname
>

Seems to me that symlinking /proc/sys/kernel/hostname would be
simpler. Also, more reliable, because there are other ways the
hostname could be set other than from /etc/conf.d/hostname. The
hostname can also change.

-- 
Rich


Re: [gentoo-dev] rfc: /etc/hostname on gentoo

2016-08-23 Thread Michael Orlitzky
On 08/22/2016 06:09 PM, William Hubbs wrote:
> 
> Someone here at the office was wanting a cross-platform way to find out
> the hostname of the host the container is running on inside the
> container. We made another suggestion for that, so forget about the
> docker angle on this for now.
> 
> But, /etc/hostname is a multi-distro standard for where the hostname is
> located, so I would like to make openrc prefer it over the setting in
> /etc/conf.d/hostname if it exists.A
> 

What for? As far as I know, /etc/hostname is an arbitrary path that has
been used to configure the hostname in the past. Whatever, you gotta
configure it somewhere. But in OpenRC, there's a standard place for init
script configuration and we already use it. Switching just one service
to prefer another path is going to confuse everyone: "I changed my
hostname in /etc/conf.d/hostname and NOTHING HAPPENED!?!?"

Populating /etc/hostname will only encourage people to read it from
there rather than the proper way.




Re: [gentoo-dev] rfc: /etc/hostname on gentoo

2016-08-23 Thread Rich Freeman
On Tue, Aug 23, 2016 at 2:39 AM, Daniel Campbell  wrote:
>
> It makes a bit more sense to rely on previous configuration
> (/etc/conf.d/hostname) and write a tiny 'script' that populates
> /etc/hostname. bash could do it (naively) in two lines:
>
> source /etc/conf.d/hostname
> echo "$hostname" > /etc/hostname
>

Seems to me that symlinking /proc/sys/kernel/hostname would be
simpler.  Also, more reliable, because there are other ways the
hostname could be set other than from /etc/conf.d/hostname.  The
hostname can also change.

-- 
Rich



Re: [gentoo-dev] rfc: /etc/hostname on gentoo

2016-08-23 Thread Christian Kniep
Hey y’all,

just to elaborate on the problem and clear up the fuzz I made.

I am facing to be distro-agnostic, thus I do not know in advance if I am 
running on DockerForMac (which uses Alpine Linux), some weird Ubuntu vagrant 
setup of mine or a fleet of gentoo hosts.
Docker Service schedules the service as it pleases (oversimplification). For 
services I fancy using global services in which the described services is 
started on each node of the SWAM cluster.

A demo of how this looks like (fast-forward to minute 28): 
https://www.youtube.com/watch?v=g-YNST-COdI

I have four nodes in my cluster:

###
docker node ls
ID   HOSTNAME STATUS  AVAILABILITY  
MANAGER STATUS
4iffi5tt5jlk03ub7nd7cf5r2gentoo1  Ready   Active
5m0x0vqtjugkwi13gkaa4ijk2gentoo2  Ready   Active
6eu0fiz0ch8e7pnbbzh8pj545gentoo3  Ready   ActiveLeader
ckrxwdppbehyz806o7gxgashl *  gentoo4  Ready   ActiveReachable
$
###

If I use an environment variable like this:

###
$ docker service create --name nginx --mode=global -e 
SERVICE_HOSTNAME=$(hostname -f)  nginx
###

Each of the tasks (a container to-be-run on one of the nodes) will now find an 
environment variable SERVICE_HOSTNAME, but it will a) be the same among all 
containers and b) it will show the hostname from which the service was created.

Therefore environment variables are not going to get me far.

On docker host with non-gentoo I can just run this (e.g. on my DockerForMac):

###
$ docker service create --mount 
type=bind,source=/etc/hostname,target=/etc/docker-hostname:ro --name nginx  
nginx
###

By doing so I am able to determine on which host I am running on each tasks 
without much hassle.

###
$ docker exec -ti 56e8b2eaecc3 cat /etc/docker-hostname
###

I am using this for a zookeeper service which should reuse the same MYID when 
restarted on a given node.
Otherwise I would end up with a restarting container on a given node, which 
would get himself a new MYID and after a couple of restarts I am out of the 
range of MYID (up to 255).

Cheers and again, sorry for the misunderstanding
Christian


> On 23 Aug 2016, at 08:39, Daniel Campbell  wrote:
> 
> On 08/22/2016 03:09 PM, William Hubbs wrote:
>> On Mon, Aug 22, 2016 at 09:28:44PM +0200, Hans de Graaff wrote:
>>> On Mon, 2016-08-22 at 10:58 -0500, William Hubbs wrote:
 All,
 
 it looks like app-emulation/docker expects /etc/hostname to exist.
>>> 
>>> Is there a bug for this? docker seems to work fine for me on a system
>>> without this file present.
>> 
>> Ok, now for the clarification.
>> 
>> Someone here at the office was wanting a cross-platform way to find out
>> the hostname of the host the container is running on inside the
>> container. We made another suggestion for that, so forget about the
>> docker angle on this for now.
>> 
>> But, /etc/hostname is a multi-distro standard for where the hostname is
>> located, so I would like to make openrc prefer it over the setting in
>> /etc/conf.d/hostname if it exists.A
>> 
>> I suppose whether we populate it by default might be a separate
>> question.
>> 
>> William
>> 
> Changing the way one configures the hostname because one or a few
> packages A) need this knowledge, and B) hardcode /etc/hostname is not
> worth changing the canonical way to update it and getting people to
> change their habits.
> 
> It makes a bit more sense to rely on previous configuration
> (/etc/conf.d/hostname) and write a tiny 'script' that populates
> /etc/hostname. bash could do it (naively) in two lines:
> 
> source /etc/conf.d/hostname
> echo "$hostname" > /etc/hostname
> 
> The 'multi-distro standard' is du jour at best and imo not a compelling
> reason to follow.
> 
> -- 
> Daniel Campbell - Gentoo Developer
> OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
> fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6
> 



smime.p7s
Description: S/MIME cryptographic signature


Re: [gentoo-dev] rfc: /etc/hostname on gentoo

2016-08-22 Thread Daniel Campbell
On 08/22/2016 03:09 PM, William Hubbs wrote:
> On Mon, Aug 22, 2016 at 09:28:44PM +0200, Hans de Graaff wrote:
>> On Mon, 2016-08-22 at 10:58 -0500, William Hubbs wrote:
>>> All,
>>>
>>> it looks like app-emulation/docker expects /etc/hostname to exist.
>>
>> Is there a bug for this? docker seems to work fine for me on a system
>> without this file present.
> 
> Ok, now for the clarification.
> 
> Someone here at the office was wanting a cross-platform way to find out
> the hostname of the host the container is running on inside the
> container. We made another suggestion for that, so forget about the
> docker angle on this for now.
> 
> But, /etc/hostname is a multi-distro standard for where the hostname is
> located, so I would like to make openrc prefer it over the setting in
> /etc/conf.d/hostname if it exists.A
> 
> I suppose whether we populate it by default might be a separate
> question.
> 
> William
> 
Changing the way one configures the hostname because one or a few
packages A) need this knowledge, and B) hardcode /etc/hostname is not
worth changing the canonical way to update it and getting people to
change their habits.

It makes a bit more sense to rely on previous configuration
(/etc/conf.d/hostname) and write a tiny 'script' that populates
/etc/hostname. bash could do it (naively) in two lines:

source /etc/conf.d/hostname
echo "$hostname" > /etc/hostname

The 'multi-distro standard' is du jour at best and imo not a compelling
reason to follow.

-- 
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] rfc: /etc/hostname on gentoo

2016-08-22 Thread William Hubbs
On Mon, Aug 22, 2016 at 09:28:44PM +0200, Hans de Graaff wrote:
> On Mon, 2016-08-22 at 10:58 -0500, William Hubbs wrote:
> > All,
> > 
> > it looks like app-emulation/docker expects /etc/hostname to exist.
> 
> Is there a bug for this? docker seems to work fine for me on a system
> without this file present.

Ok, now for the clarification.

Someone here at the office was wanting a cross-platform way to find out
the hostname of the host the container is running on inside the
container. We made another suggestion for that, so forget about the
docker angle on this for now.

But, /etc/hostname is a multi-distro standard for where the hostname is
located, so I would like to make openrc prefer it over the setting in
/etc/conf.d/hostname if it exists.A

I suppose whether we populate it by default might be a separate
question.

William



signature.asc
Description: Digital signature


Re: [gentoo-dev] rfc: /etc/hostname on gentoo

2016-08-22 Thread William Hubbs
On Mon, Aug 22, 2016 at 09:28:44PM +0200, Hans de Graaff wrote:
> On Mon, 2016-08-22 at 10:58 -0500, William Hubbs wrote:
> > All,
> > 
> > it looks like app-emulation/docker expects /etc/hostname to exist.
> 
> Is there a bug for this? docker seems to work fine for me on a system
> without this file present.

Let me take a look on my end more and I'll clarify this.

Thanks,

William


signature.asc
Description: Digital signature


Re: [gentoo-dev] rfc: /etc/hostname on gentoo

2016-08-22 Thread Hans de Graaff
On Mon, 2016-08-22 at 10:58 -0500, William Hubbs wrote:
> All,
> 
> it looks like app-emulation/docker expects /etc/hostname to exist.

Is there a bug for this? docker seems to work fine for me on a system
without this file present.

Hans

signature.asc
Description: This is a digitally signed message part


Re: [gentoo-dev] rfc: /etc/hostname on gentoo

2016-08-22 Thread Dirkjan Ochtman
On Mon, Aug 22, 2016 at 5:58 PM, William Hubbs  wrote:
> On Gentoo, this file does not exist, so I'm wondering how we can make it
> exist?

Not sure if/how related, but when I have:

djc@enrai ~ $ cat /etc/conf.d/hostname
# Set to the hostname of this machine
hostname="enrai"

Apache 2 tells me:

AH00558: apache2: Could not reliably determine the server's fully
qualified domain name, using 127.0.0.1. Set the 'ServerName' directive
globally to suppress this message[ ok ]

I've set dns_domain and dns_search in /etc/conf.d/net, and domain is
set in /etc/resolv.conf.

The Handbook also has a non-fully-qualified hostname set in
/etc/conf.d/hostname, and I didn't get this Apache warning on the
previous server I ran this stuff on.

Cheers,

Dirkjan



Re: [gentoo-dev] rfc: /etc/hostname on gentoo

2016-08-22 Thread Rich Freeman
On Mon, Aug 22, 2016 at 1:51 PM, Sven Vermeulen  wrote:
>
> Yes, wouldn't the Docker project be happy to take on a patch that uses
> gethostname() or so?
>

This might be another option: symlink to /proc/sys/kernel/hostname

I'm not sure if somebody can find a flaw in this.  It appears to use
the UTS namespace hostname inside containers, which is what you'd
want.

-- 
Rich



Re: [gentoo-dev] rfc: /etc/hostname on gentoo

2016-08-22 Thread Matthew Thode
On 08/22/2016 10:58 AM, William Hubbs wrote:
> All,
> 
> it looks like app-emulation/docker expects /etc/hostname to exist.
> 
> On Gentoo, this file does not exist, so I'm wondering how we can make it
> exist?
> 
> I know in OpenRC I can read it and use the value there as the hostname
> instead of /etc/conf.d/hostname if it exists,but I'm not sure whether
> OpenRC should populate /etc/hostname if it does not exist or whether
> something else should do that.
> 
> Thoughts?
> 
> William
> 

Secondarily I'd like /etc/hostname to be seen as a source of truth.
Having to write wrapper scripts to fix /etc/hostname issues can suck
(cloud-init and glean).

-- 
-- Matthew Thode (prometheanfire)



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] rfc: /etc/hostname on gentoo

2016-08-22 Thread Sven Vermeulen
On Mon, Aug 22, 2016 at 01:28:50PM -0400, Michael Orlitzky wrote:
> On 08/22/2016 11:58 AM, William Hubbs wrote:
> > All,
> > 
> > it looks like app-emulation/docker expects /etc/hostname to exist.
> > 
> 
> Isn't there some kind of portable operating system standard that says
> how to do these things?

Yes, wouldn't the Docker project be happy to take on a patch that uses
gethostname() or so?

Wkr,
Sven Vermeulen



Re: [gentoo-dev] rfc: /etc/hostname on gentoo

2016-08-22 Thread Matthew Thode
On 08/22/2016 10:58 AM, William Hubbs wrote:
> All,
> 
> it looks like app-emulation/docker expects /etc/hostname to exist.
> 
> On Gentoo, this file does not exist, so I'm wondering how we can make it
> exist?
> 
> I know in OpenRC I can read it and use the value there as the hostname
> instead of /etc/conf.d/hostname if it exists,but I'm not sure whether
> OpenRC should populate /etc/hostname if it does not exist or whether
> something else should do that.
> 
> Thoughts?
> 
> William
> 

I'd like us to populate the file in some way (symlink to /run or
otherwise).  Just keep in mind that the format is different than
/etc/conf.d/hostname when considering your options.

-- 
-- Matthew Thode (prometheanfire)



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] rfc: /etc/hostname on gentoo

2016-08-22 Thread Rich Freeman
On Mon, Aug 22, 2016 at 1:03 PM, William Hubbs  wrote:
>
> I'm not sure about putting this in /run for a couple of reasons:
>
> The contents of this file is a setting, like /etc/conf.d/hostname, which
> will be set by the user.

There is no reason a script can't populate /run with the right thing.
For example, with systemd you can set up a static networking config
with a static DNS, and it will populate a resolv.conf in /run with
whatever it parsed out of your networkd configuration.  Or you can
tell it to use dhcp in which case it populates /run with whatever the
dhcp server gives it.

The idea is that only one tool has to worry about where to get the
right network settings from, and everything else can just read them in
whatever format they prefer from wherever it is preferred.

However, it isn't the only way to accomplish this goal.  You could
just keep writing to /etc.  That does break in situations where you
want /etc to be read-only, etc.

>
> The other reason is, I don't know enough about containers to know if
> they will have a separate /run from the host.
>

Typically containers will have their own /run.  Containers were one of
the big reasons to not store hostnames in /etc, since then you can
share a single image across many containers, with a static /etc, and
the dynamic stuff all goes in /run.  Containers are also one of the
reasons for ditching /etc/mtab.

-- 
Rich



Re: [gentoo-dev] rfc: /etc/hostname on gentoo

2016-08-22 Thread Michael Orlitzky
On 08/22/2016 11:58 AM, William Hubbs wrote:
> All,
> 
> it looks like app-emulation/docker expects /etc/hostname to exist.
> 

Isn't there some kind of portable operating system standard that says
how to do these things?





Re: [gentoo-dev] rfc: /etc/hostname on gentoo

2016-08-22 Thread William Hubbs
On Mon, Aug 22, 2016 at 12:39:03PM -0400, Rich Freeman wrote:
> On Mon, Aug 22, 2016 at 12:11 PM, M. J. Everitt  wrote:
> > On 22/08/16 16:58, William Hubbs wrote:
> >>
> >> it looks like app-emulation/docker expects /etc/hostname to exist.
> >>
> >> On Gentoo, this file does not exist, so I'm wondering how we can make it
> >> exist?
> >>
> >> I know in OpenRC I can read it and use the value there as the hostname
> >> instead of /etc/conf.d/hostname if it exists,but I'm not sure whether
> >> OpenRC should populate /etc/hostname if it does not exist or whether
> >> something else should do that.
> >>
> > Sym-link it perhaps? Making another file could make synchronisation, etc
> > a headache
> >
> 
> Systemd has generally been going the route of symlinking files like
> these to files in /run.  That might be an approach that would work for
> openrc as well.  It also eliminates giving write-access to /etc to
> things like dhcpd.

I'm not sure about putting this in /run for a couple of reasons:

The contents of this file is a setting, like /etc/conf.d/hostname, which
will be set by the user.

The other reason is, I don't know enough about containers to know if
they will have a separate /run from the host.

William


signature.asc
Description: Digital signature


Re: [gentoo-dev] rfc: /etc/hostname on gentoo

2016-08-22 Thread Rich Freeman
On Mon, Aug 22, 2016 at 12:11 PM, M. J. Everitt  wrote:
> On 22/08/16 16:58, William Hubbs wrote:
>>
>> it looks like app-emulation/docker expects /etc/hostname to exist.
>>
>> On Gentoo, this file does not exist, so I'm wondering how we can make it
>> exist?
>>
>> I know in OpenRC I can read it and use the value there as the hostname
>> instead of /etc/conf.d/hostname if it exists,but I'm not sure whether
>> OpenRC should populate /etc/hostname if it does not exist or whether
>> something else should do that.
>>
> Sym-link it perhaps? Making another file could make synchronisation, etc
> a headache
>

Systemd has generally been going the route of symlinking files like
these to files in /run.  That might be an approach that would work for
openrc as well.  It also eliminates giving write-access to /etc to
things like dhcpd.

-- 
Rich



Re: [gentoo-dev] rfc: /etc/hostname on gentoo

2016-08-22 Thread M. J. Everitt
On 22/08/16 16:58, William Hubbs wrote:
> All,
>
> it looks like app-emulation/docker expects /etc/hostname to exist.
>
> On Gentoo, this file does not exist, so I'm wondering how we can make it
> exist?
>
> I know in OpenRC I can read it and use the value there as the hostname
> instead of /etc/conf.d/hostname if it exists,but I'm not sure whether
> OpenRC should populate /etc/hostname if it does not exist or whether
> something else should do that.
>
> Thoughts?
>
> William
>
Sym-link it perhaps? Making another file could make synchronisation, etc
a headache



signature.asc
Description: OpenPGP digital signature


[gentoo-dev] rfc: /etc/hostname on gentoo

2016-08-22 Thread William Hubbs
All,

it looks like app-emulation/docker expects /etc/hostname to exist.

On Gentoo, this file does not exist, so I'm wondering how we can make it
exist?

I know in OpenRC I can read it and use the value there as the hostname
instead of /etc/conf.d/hostname if it exists,but I'm not sure whether
OpenRC should populate /etc/hostname if it does not exist or whether
something else should do that.

Thoughts?

William



signature.asc
Description: Digital signature