3:49 p.m.
For as long as I can recall, Fedora has shipped with a default hostname of
"localhost.localdomain"[1]. This default was "safe" for a very long
time because
we also shipped an /etc/hosts entry that routed this hostname to the loopback
device for the benefit of some older system services (like sendmail).
However, having the default be the same on all systems introduces other
problems, notably with regards to acting as a client to FreeIPA or Active
Directory domain controllers.
When enrolling with one of these DCs, the machine's current hostname (up to the
first dot) is used to uniquely identify the machine into the domain. If the
machine's hostname is not unique in that domain, the enrollment will either fail
or the machine will take over that name (depending on the server-side
implementation). Neither case is likely to be what the user intended.
Some information on competing platforms:
Windows deals with this on for its systems by assigning all new machines a
random hostname of the form WIN-XXXXXXXXXXX (that's a strict count of 11 random
characters of either capital letters or decimal numerals after the WIN- prefix).
This is because there is a 15-character maximum limit on the machine-name in
Active Directory, after which it is simply truncated (which is a bad behavior,
but one we have to deal with).
Mac OS X and Ubuntu both require the user to pick a machine name at install time
explicitly. They do not autogenerate one at all.
SUSE generates a random name of the format linux-XXXXXX (I'm not sure how many
random characters).
My proposal is that we should consider changing the default hostname for Fedora
26 to be either FED-XXXXXXXXXXX or FEDORA-XXXXXXXX. The former allows for a
longer random string and therefore lower risk of collision in large
environments, while the latter would also provide improved branding for
Fedora[2]. Our default BASH shell prompt includes the current machine's hostname.
Thoughts on how to generate these random strings are of course up for
discussion. Given that initial machine creation may have limited available
entropy, we may want to avoid just calling out to /dev/random. Dusty Mabe
suggested in on IRC that one option might be to use either the first or last
8/11 characters from /etc/machine-id, since presumably those would be
sufficiently random.
[1] Unless there is a DHCP-assigned hostname, in which case it will use that.
[2] There is an ongoing discussion on the desktop@ list about how to subtly
brand the Workstation Edition such that when people are using it or showing it
to others, it is clear that it is *Fedora* as opposed to any other GNOME
distribution.
4:25 p.m.
On Tue, Nov 08, 2016 at 04:49:42PM -0500, Stephen Gallagher wrote:
SUSE generates a random name of the format linux-XXXXXX (I'm not
sure how many
My proposal is that we should consider changing the default hostname for Fedora
26 to be either FED-XXXXXXXXXXX or FEDORA-XXXXXXXX. The former allows for a
How about non-yelly Fedora-XXXXXXXXXXX? Since SUSE apparently does
lower case, that should be fine, right?
--
Matthew Miller
<mattdm(a)fedoraproject.org>
Fedora Project Leader
5:14 p.m.
On Tue, Nov 08, 2016 at 05:25:36PM -0500, Matthew Miller wrote:
On Tue, Nov 08, 2016 at 04:49:42PM -0500, Stephen Gallagher wrote:
> SUSE generates a random name of the format linux-XXXXXX (I'm not sure how many
> My proposal is that we should consider changing the default hostname for Fedora
> 26 to be either FED-XXXXXXXXXXX or FEDORA-XXXXXXXX. The former allows for a
How about non-yelly Fedora-XXXXXXXXXXX? Since SUSE apparently does
lower case, that should be fine, right?
Bastian Nocera also filed https://bugzilla.redhat.com/show_bug.cgi?id=1392925,
where he proposes "fedora" as the hostname. I think "fedora" is better
than
"localhost", and a non-constant hostname would be even better.
For interactive installs (like with anaconda) it would be great if we could
ask for the hostname. For non-interactive ones, "Fedora-[0-9a-z-]{8}" seems
like a good option (*). It would give "branding", and solve the freeipa issues.
It would also be a good default for the interactive case, so that people can
"click through" without having to pick anything.
Zbyszek
(*) The suffix could include dashes for more possibilities, but they should
not be adjacent or at the end.
5:19 p.m.
On Tue, Nov 8, 2016 at 6:14 PM, Zbigniew Jędrzejewski-Szmek
<zbyszek(a)in.waw.pl> wrote:
On Tue, Nov 08, 2016 at 05:25:36PM -0500, Matthew Miller wrote:
> On Tue, Nov 08, 2016 at 04:49:42PM -0500, Stephen Gallagher wrote:
> > SUSE generates a random name of the format linux-XXXXXX (I'm not sure how
many
> > My proposal is that we should consider changing the default hostname for Fedora
> > 26 to be either FED-XXXXXXXXXXX or FEDORA-XXXXXXXX. The former allows for a
>
> How about non-yelly Fedora-XXXXXXXXXXX? Since SUSE apparently does
> lower case, that should be fine, right?
Bastian Nocera also filed https://bugzilla.redhat.com/show_bug.cgi?id=1392925,
where he proposes "fedora" as the hostname. I think "fedora" is
better than
"localhost", and a non-constant hostname would be even better.
For interactive installs (like with anaconda) it would be great if we could
ask for the hostname. For non-interactive ones, "Fedora-[0-9a-z-]{8}" seems
like a good option (*). It would give "branding", and solve the freeipa
issues.
It would also be a good default for the interactive case, so that people can
"click through" without having to pick anything.
(*) The suffix could include dashes for more possibilities, but they should
not be adjacent or at the end.
I'm in favor of defaulting to "Fedora-[0-9a-z-]{8}" myself. However,
I'm concerned that people don't realize that we can, in fact, set the
hostname during installation. People usually don't because Anaconda
doesn't currently make that mandatory or otherwise note that it's
possible during the initial panel of spokes (hint: it's the networking
spoke), and so the default of "localhost" continues on without anyone
being the wiser.
--
真実はいつも一つ！/ Always, there's only one truth!
5:25 p.m.
On Tue, Nov 8, 2016 at 3:19 PM, Neal Gompa <ngompa13(a)gmail.com> wrote:
On Tue, Nov 8, 2016 at 6:14 PM, Zbigniew Jędrzejewski-Szmek
<zbyszek(a)in.waw.pl> wrote:
> On Tue, Nov 08, 2016 at 05:25:36PM -0500, Matthew Miller wrote:
>> On Tue, Nov 08, 2016 at 04:49:42PM -0500, Stephen Gallagher wrote:
>> > SUSE generates a random name of the format linux-XXXXXX (I'm not sure
how many
>> > My proposal is that we should consider changing the default hostname for
Fedora
>> > 26 to be either FED-XXXXXXXXXXX or FEDORA-XXXXXXXX. The former allows for a
>>
>> How about non-yelly Fedora-XXXXXXXXXXX? Since SUSE apparently does
>> lower case, that should be fine, right?
>
> Bastian Nocera also filed https://bugzilla.redhat.com/show_bug.cgi?id=1392925,
> where he proposes "fedora" as the hostname. I think "fedora" is
better than
> "localhost", and a non-constant hostname would be even better.
> For interactive installs (like with anaconda) it would be great if we could
> ask for the hostname. For non-interactive ones, "Fedora-[0-9a-z-]{8}"
seems
> like a good option (*). It would give "branding", and solve the freeipa
issues.
> It would also be a good default for the interactive case, so that people can
> "click through" without having to pick anything.
>
> (*) The suffix could include dashes for more possibilities, but they should
> not be adjacent or at the end.
I'm in favor of defaulting to "Fedora-[0-9a-z-]{8}" myself. However,
I'm concerned that people don't realize that we can, in fact, set the
hostname during installation. People usually don't because Anaconda
doesn't currently make that mandatory or otherwise note that it's
possible during the initial panel of spokes (hint: it's the networking
spoke), and so the default of "localhost" continues on without anyone
being the wiser.
If the hostname is non-constant, can we also arrange that, by default,
this hostname is never sent over the network? In particular, I think
that DHCP requests should *not* include this hostname. We're already
starting to randomize MAC addresses -- there's no reason to give a
persistent per-installation identifier to every network.
5:28 p.m.
On Tue, Nov 8, 2016 at 6:25 PM, Andrew Lutomirski <luto(a)mit.edu> wrote:
On Tue, Nov 8, 2016 at 3:19 PM, Neal Gompa <ngompa13(a)gmail.com>
wrote:
> On Tue, Nov 8, 2016 at 6:14 PM, Zbigniew Jędrzejewski-Szmek
> <zbyszek(a)in.waw.pl> wrote:
>> On Tue, Nov 08, 2016 at 05:25:36PM -0500, Matthew Miller wrote:
>>> On Tue, Nov 08, 2016 at 04:49:42PM -0500, Stephen Gallagher wrote:
>>> > SUSE generates a random name of the format linux-XXXXXX (I'm not
sure how many
>>> > My proposal is that we should consider changing the default hostname for
Fedora
>>> > 26 to be either FED-XXXXXXXXXXX or FEDORA-XXXXXXXX. The former allows
for a
>>>
>>> How about non-yelly Fedora-XXXXXXXXXXX? Since SUSE apparently does
>>> lower case, that should be fine, right?
>>
>> Bastian Nocera also filed https://bugzilla.redhat.com/show_bug.cgi?id=1392925,
>> where he proposes "fedora" as the hostname. I think "fedora"
is better than
>> "localhost", and a non-constant hostname would be even better.
>> For interactive installs (like with anaconda) it would be great if we could
>> ask for the hostname. For non-interactive ones, "Fedora-[0-9a-z-]{8}"
seems
>> like a good option (*). It would give "branding", and solve the freeipa
issues.
>> It would also be a good default for the interactive case, so that people can
>> "click through" without having to pick anything.
>>
>> (*) The suffix could include dashes for more possibilities, but they should
>> not be adjacent or at the end.
>
> I'm in favor of defaulting to "Fedora-[0-9a-z-]{8}" myself. However,
> I'm concerned that people don't realize that we can, in fact, set the
> hostname during installation. People usually don't because Anaconda
> doesn't currently make that mandatory or otherwise note that it's
> possible during the initial panel of spokes (hint: it's the networking
> spoke), and so the default of "localhost" continues on without anyone
> being the wiser.
>
>
If the hostname is non-constant, can we also arrange that, by default,
this hostname is never sent over the network? In particular, I think
that DHCP requests should *not* include this hostname. We're already
starting to randomize MAC addresses -- there's no reason to give a
persistent per-installation identifier to every network.
The idea is that the hostname is randomly generated at install time.
It definitely is constant. And speaking from experience, not including
the hostname in DHCP requests breaks quite a few user expectations
(especially the ability to identify the computer by name).
--
真実はいつも一つ！/ Always, there's only one truth!
5:38 p.m.
On Tue, Nov 8, 2016 at 3:28 PM, Neal Gompa <ngompa13(a)gmail.com> wrote:
On Tue, Nov 8, 2016 at 6:25 PM, Andrew Lutomirski
<luto(a)mit.edu> wrote:
> On Tue, Nov 8, 2016 at 3:19 PM, Neal Gompa <ngompa13(a)gmail.com> wrote:
>> On Tue, Nov 8, 2016 at 6:14 PM, Zbigniew Jędrzejewski-Szmek
>> <zbyszek(a)in.waw.pl> wrote:
>>> On Tue, Nov 08, 2016 at 05:25:36PM -0500, Matthew Miller wrote:
>>>> On Tue, Nov 08, 2016 at 04:49:42PM -0500, Stephen Gallagher wrote:
>>>> > SUSE generates a random name of the format linux-XXXXXX (I'm
not
sure how many
>>>> > My proposal is that we should consider changing the default
hostname for Fedora
>>>> > 26 to be either FED-XXXXXXXXXXX or FEDORA-XXXXXXXX. The former
allows for a
>>>>
>>>> How about non-yelly Fedora-XXXXXXXXXXX? Since SUSE apparently does
>>>> lower case, that should be fine, right?
>>>
>>> Bastian Nocera also filed https://bugzilla.redhat.com/
show_bug.cgi?id=1392925,
>>> where he proposes "fedora" as the hostname. I think
"fedora" is better
than
>>> "localhost", and a non-constant hostname would be even better.
>>> For interactive installs (like with anaconda) it would be great if we
could
>>> ask for the hostname. For non-interactive ones,
"Fedora-[0-9a-z-]{8}"
seems
>>> like a good option (*). It would give "branding", and solve the
freeipa issues.
>>> It would also be a good default for the interactive case, so that
people can
>>> "click through" without having to pick anything.
>>>
>>> (*) The suffix could include dashes for more possibilities, but they
should
>>> not be adjacent or at the end.
>>
>> I'm in favor of defaulting to "Fedora-[0-9a-z-]{8}" myself.
However,
>> I'm concerned that people don't realize that we can, in fact, set the
>> hostname during installation. People usually don't because Anaconda
>> doesn't currently make that mandatory or otherwise note that it's
>> possible during the initial panel of spokes (hint: it's the networking
>> spoke), and so the default of "localhost" continues on without anyone
>> being the wiser.
>>
>>
>
> If the hostname is non-constant, can we also arrange that, by default,
> this hostname is never sent over the network? In particular, I think
> that DHCP requests should *not* include this hostname. We're already
> starting to randomize MAC addresses -- there's no reason to give a
> persistent per-installation identifier to every network.
The idea is that the hostname is randomly generated at install time.
It definitely is constant. And speaking from experience, not including
the hostname in DHCP requests breaks quite a few user expectations
(especially the ability to identify the computer by name).
When I go to a random coffee shop and connect to wifi, I have a very strong
user expectation that the coffee shop *not* be able to identify me by
name. It's even somewhat dubious to advertise to the coffee shop that I'm
using Fedora.
If this means that NetworkManager needs to generate a per-network random
client ID, so be it. IMO a per-installation value absolutely should not be
sent to a network that is not explicitly (on an opt-in basis) configured as
trusted.
10:05 p.m.
On 11/08/2016 06:25 PM, Andrew Lutomirski wrote:
On Tue, Nov 8, 2016 at 3:19 PM, Neal Gompa <ngompa13(a)gmail.com>
wrote:
> On Tue, Nov 8, 2016 at 6:14 PM, Zbigniew Jędrzejewski-Szmek
> <zbyszek(a)in.waw.pl> wrote:
>> On Tue, Nov 08, 2016 at 05:25:36PM -0500, Matthew Miller wrote:
>>> On Tue, Nov 08, 2016 at 04:49:42PM -0500, Stephen Gallagher wrote:
>>>> SUSE generates a random name of the format linux-XXXXXX (I'm not sure
how many
>>>> My proposal is that we should consider changing the default hostname for
Fedora
>>>> 26 to be either FED-XXXXXXXXXXX or FEDORA-XXXXXXXX. The former allows for
a
>>>
>>> How about non-yelly Fedora-XXXXXXXXXXX? Since SUSE apparently does
>>> lower case, that should be fine, right?
>>
>> Bastian Nocera also filed https://bugzilla.redhat.com/show_bug.cgi?id=1392925,
>> where he proposes "fedora" as the hostname. I think "fedora"
is better than
>> "localhost", and a non-constant hostname would be even better.
>> For interactive installs (like with anaconda) it would be great if we could
>> ask for the hostname. For non-interactive ones, "Fedora-[0-9a-z-]{8}"
seems
>> like a good option (*). It would give "branding", and solve the freeipa
issues.
>> It would also be a good default for the interactive case, so that people can
>> "click through" without having to pick anything.
>>
>> (*) The suffix could include dashes for more possibilities, but they should
>> not be adjacent or at the end.
>
> I'm in favor of defaulting to "Fedora-[0-9a-z-]{8}" myself. However,
> I'm concerned that people don't realize that we can, in fact, set the
> hostname during installation. People usually don't because Anaconda
> doesn't currently make that mandatory or otherwise note that it's
> possible during the initial panel of spokes (hint: it's the networking
> spoke), and so the default of "localhost" continues on without anyone
> being the wiser.
>
>
If the hostname is non-constant, can we also arrange that, by default,
this hostname is never sent over the network? In particular, I think
that DHCP requests should *not* include this hostname. We're already
starting to randomize MAC addresses -- there's no reason to give a
persistent per-installation identifier to every network.
If this is a problem (and I'm not necessarily convinced it is), it's a problem
already for anyone using DHCP who set a hostname manually. The fact that the
default happens to be constant (and therefore indistinguishable) is a side-effect.
If this is something that is genuinely concerning from a privacy point of view,
then that should be changed in the DHCP client software rather than at the
default hostname level. If it's not acceptable to send a unique default hostname
then it must be equally unacceptable to send a manually selected hostname. (At
least a randomly-generated one is only unique; a chosen one may in fact be
possible to use for individual identification as well.)
7:02 a.m.
On Tue, 2016-11-08 at 23:05 -0500, Stephen Gallagher wrote:
On 11/08/2016 06:25 PM, Andrew Lutomirski wrote:
> On Tue, Nov 8, 2016 at 3:19 PM, Neal Gompa <ngompa13(a)gmail.com> wrote:
>> On Tue, Nov 8, 2016 at 6:14 PM, Zbigniew Jędrzejewski-Szmek
>> <zbyszek(a)in.waw.pl> wrote:
>>> On Tue, Nov 08, 2016 at 05:25:36PM -0500, Matthew Miller wrote:
>>>> On Tue, Nov 08, 2016 at 04:49:42PM -0500, Stephen Gallagher wrote:
>>>>> SUSE generates a random name of the format linux-XXXXXX (I'm not
sure how many
>>>>> My proposal is that we should consider changing the default hostname
for Fedora
>>>>> 26 to be either FED-XXXXXXXXXXX or FEDORA-XXXXXXXX. The former
allows for a
>>>>
>>>> How about non-yelly Fedora-XXXXXXXXXXX? Since SUSE apparently does
>>>> lower case, that should be fine, right?
>>>
>>> Bastian Nocera also filed
https://bugzilla.redhat.com/show_bug.cgi?id=1392925,
>>> where he proposes "fedora" as the hostname. I think
"fedora" is better than
>>> "localhost", and a non-constant hostname would be even better.
>>> For interactive installs (like with anaconda) it would be great if we could
>>> ask for the hostname. For non-interactive ones,
"Fedora-[0-9a-z-]{8}" seems
>>> like a good option (*). It would give "branding", and solve the
freeipa issues.
>>> It would also be a good default for the interactive case, so that people
can
>>> "click through" without having to pick anything.
>>>
>>> (*) The suffix could include dashes for more possibilities, but they should
>>> not be adjacent or at the end.
>>
>> I'm in favor of defaulting to "Fedora-[0-9a-z-]{8}" myself.
However,
>> I'm concerned that people don't realize that we can, in fact, set the
>> hostname during installation. People usually don't because Anaconda
>> doesn't currently make that mandatory or otherwise note that it's
>> possible during the initial panel of spokes (hint: it's the networking
>> spoke), and so the default of "localhost" continues on without anyone
>> being the wiser.
>>
>>
>
> If the hostname is non-constant, can we also arrange that, by default,
> this hostname is never sent over the network? In particular, I think
> that DHCP requests should *not* include this hostname. We're already
> starting to randomize MAC addresses -- there's no reason to give a
> persistent per-installation identifier to every network.
If this is a problem (and I'm not necessarily convinced it is), it's a problem
already for anyone using DHCP who set a hostname manually. The fact that the
default happens to be constant (and therefore indistinguishable) is a side-effect.
If this is something that is genuinely concerning from a privacy point of view,
then that should be changed in the DHCP client software rather than at the
default hostname level. If it's not acceptable to send a unique default hostname
then it must be equally unacceptable to send a manually selected hostname. (At
least a randomly-generated one is only unique; a chosen one may in fact be
possible to use for individual identification as well.)
Although this is true, one thing we could do is set a default hostname
that is static ("fedora" or similar is fine), and teach the utilities
used to join an AD/IPA/etc.. domain to generate a new random hostname if
they detect the hostname is the generic "static" one.
Simo.
--
Simo Sorce * Red Hat, Inc * New York
7:13 a.m.
On 11/09/2016 08:02 AM, Simo Sorce wrote:
On Tue, 2016-11-08 at 23:05 -0500, Stephen Gallagher wrote:
> On 11/08/2016 06:25 PM, Andrew Lutomirski wrote:
>> On Tue, Nov 8, 2016 at 3:19 PM, Neal Gompa <ngompa13(a)gmail.com> wrote:
>>> On Tue, Nov 8, 2016 at 6:14 PM, Zbigniew Jędrzejewski-Szmek
>>> <zbyszek(a)in.waw.pl> wrote:
>>>> On Tue, Nov 08, 2016 at 05:25:36PM -0500, Matthew Miller wrote:
>>>>> On Tue, Nov 08, 2016 at 04:49:42PM -0500, Stephen Gallagher wrote:
>>>>>> SUSE generates a random name of the format linux-XXXXXX (I'm
not sure how many
>>>>>> My proposal is that we should consider changing the default
hostname for Fedora
>>>>>> 26 to be either FED-XXXXXXXXXXX or FEDORA-XXXXXXXX. The former
allows for a
>>>>>
>>>>> How about non-yelly Fedora-XXXXXXXXXXX? Since SUSE apparently does
>>>>> lower case, that should be fine, right?
>>>>
>>>> Bastian Nocera also filed
https://bugzilla.redhat.com/show_bug.cgi?id=1392925,
>>>> where he proposes "fedora" as the hostname. I think
"fedora" is better than
>>>> "localhost", and a non-constant hostname would be even better.
>>>> For interactive installs (like with anaconda) it would be great if we
could
>>>> ask for the hostname. For non-interactive ones,
"Fedora-[0-9a-z-]{8}" seems
>>>> like a good option (*). It would give "branding", and solve the
freeipa issues.
>>>> It would also be a good default for the interactive case, so that people
can
>>>> "click through" without having to pick anything.
>>>>
>>>> (*) The suffix could include dashes for more possibilities, but they
should
>>>> not be adjacent or at the end.
>>>
>>> I'm in favor of defaulting to "Fedora-[0-9a-z-]{8}" myself.
However,
>>> I'm concerned that people don't realize that we can, in fact, set
the
>>> hostname during installation. People usually don't because Anaconda
>>> doesn't currently make that mandatory or otherwise note that it's
>>> possible during the initial panel of spokes (hint: it's the networking
>>> spoke), and so the default of "localhost" continues on without
anyone
>>> being the wiser.
>>>
>>>
>>
>> If the hostname is non-constant, can we also arrange that, by default,
>> this hostname is never sent over the network? In particular, I think
>> that DHCP requests should *not* include this hostname. We're already
>> starting to randomize MAC addresses -- there's no reason to give a
>> persistent per-installation identifier to every network.
>
>
> If this is a problem (and I'm not necessarily convinced it is), it's a
problem
> already for anyone using DHCP who set a hostname manually. The fact that the
> default happens to be constant (and therefore indistinguishable) is a side-effect.
>
> If this is something that is genuinely concerning from a privacy point of view,
> then that should be changed in the DHCP client software rather than at the
> default hostname level. If it's not acceptable to send a unique default hostname
> then it must be equally unacceptable to send a manually selected hostname. (At
> least a randomly-generated one is only unique; a chosen one may in fact be
> possible to use for individual identification as well.)
Although this is true, one thing we could do is set a default hostname
that is static ("fedora" or similar is fine), and teach the utilities
used to join an AD/IPA/etc.. domain to generate a new random hostname if
they detect the hostname is the generic "static" one.
I feel like that's solving a symptom (and one we'd have to keep solving every
time we encountered something for which a non-unique hostname would be a problem).
It's an option though, of course.
7:22 a.m.
On Wed, 2016-11-09 at 08:13 -0500, Stephen Gallagher wrote:
On 11/09/2016 08:02 AM, Simo Sorce wrote:
> On Tue, 2016-11-08 at 23:05 -0500, Stephen Gallagher wrote:
>> On 11/08/2016 06:25 PM, Andrew Lutomirski wrote:
>>> On Tue, Nov 8, 2016 at 3:19 PM, Neal Gompa <ngompa13(a)gmail.com>
wrote:
>>>> On Tue, Nov 8, 2016 at 6:14 PM, Zbigniew Jędrzejewski-Szmek
>>>> <zbyszek(a)in.waw.pl> wrote:
>>>>> On Tue, Nov 08, 2016 at 05:25:36PM -0500, Matthew Miller wrote:
>>>>>> On Tue, Nov 08, 2016 at 04:49:42PM -0500, Stephen Gallagher
wrote:
>>>>>>> SUSE generates a random name of the format linux-XXXXXX
(I'm not sure how many
>>>>>>> My proposal is that we should consider changing the default
hostname for Fedora
>>>>>>> 26 to be either FED-XXXXXXXXXXX or FEDORA-XXXXXXXX. The
former allows for a
>>>>>>
>>>>>> How about non-yelly Fedora-XXXXXXXXXXX? Since SUSE apparently
does
>>>>>> lower case, that should be fine, right?
>>>>>
>>>>> Bastian Nocera also filed
https://bugzilla.redhat.com/show_bug.cgi?id=1392925,
>>>>> where he proposes "fedora" as the hostname. I think
"fedora" is better than
>>>>> "localhost", and a non-constant hostname would be even
better.
>>>>> For interactive installs (like with anaconda) it would be great if
we could
>>>>> ask for the hostname. For non-interactive ones,
"Fedora-[0-9a-z-]{8}" seems
>>>>> like a good option (*). It would give "branding", and
solve the freeipa issues.
>>>>> It would also be a good default for the interactive case, so that
people can
>>>>> "click through" without having to pick anything.
>>>>>
>>>>> (*) The suffix could include dashes for more possibilities, but they
should
>>>>> not be adjacent or at the end.
>>>>
>>>> I'm in favor of defaulting to "Fedora-[0-9a-z-]{8}"
myself. However,
>>>> I'm concerned that people don't realize that we can, in fact,
set the
>>>> hostname during installation. People usually don't because Anaconda
>>>> doesn't currently make that mandatory or otherwise note that
it's
>>>> possible during the initial panel of spokes (hint: it's the
networking
>>>> spoke), and so the default of "localhost" continues on without
anyone
>>>> being the wiser.
>>>>
>>>>
>>>
>>> If the hostname is non-constant, can we also arrange that, by default,
>>> this hostname is never sent over the network? In particular, I think
>>> that DHCP requests should *not* include this hostname. We're already
>>> starting to randomize MAC addresses -- there's no reason to give a
>>> persistent per-installation identifier to every network.
>>
>>
>> If this is a problem (and I'm not necessarily convinced it is), it's a
problem
>> already for anyone using DHCP who set a hostname manually. The fact that the
>> default happens to be constant (and therefore indistinguishable) is a
side-effect.
>>
>> If this is something that is genuinely concerning from a privacy point of view,
>> then that should be changed in the DHCP client software rather than at the
>> default hostname level. If it's not acceptable to send a unique default
hostname
>> then it must be equally unacceptable to send a manually selected hostname. (At
>> least a randomly-generated one is only unique; a chosen one may in fact be
>> possible to use for individual identification as well.)
>
> Although this is true, one thing we could do is set a default hostname
> that is static ("fedora" or similar is fine), and teach the utilities
> used to join an AD/IPA/etc.. domain to generate a new random hostname if
> they detect the hostname is the generic "static" one.
I feel like that's solving a symptom (and one we'd have to keep solving every
time we encountered something for which a non-unique hostname would be a problem).
It's an option though, of course.
I do not have any strong preference, as long as we do not break stuff
that works today.
Simo.
--
Simo Sorce * Red Hat, Inc * New York
11:58 a.m.
On 11/09/2016 08:02 AM, Simo Sorce wrote:
Although this is true, one thing we could do is set a default
hostname
that is static ("fedora" or similar is fine), and teach the utilities
used to join an AD/IPA/etc.. domain to generate a new random hostname if
they detect the hostname is the generic "static" one.
The hostname is
used in the install-time-generated disk volume names
(/dev/mapper/fedora_myhostname-home), so changing it is confusing.
Would it make sense to leave the old names? or rename the volumes?
12:25 p.m.
On 11/09/2016 12:58 PM, Przemek Klosowski wrote:
On 11/09/2016 08:02 AM, Simo Sorce wrote:
> Although this is true, one thing we could do is set a default hostname
> that is static ("fedora" or similar is fine), and teach the utilities
> used to join an AD/IPA/etc.. domain to generate a new random hostname if
> they detect the hostname is the generic "static" one.
The hostname is used in the install-time-generated disk volume names
(/dev/mapper/fedora_myhostname-home), so changing it is confusing.
Would it make sense to leave the old names? or rename the volumes?
That's actually another classic problem: the fact that the default hostname is
used for creating the partitions often causes issues for people who try to do a
new installation atop older Fedora installations.
3:30 p.m.
On Wed, 2016-11-09 at 12:58 -0500, Przemek Klosowski wrote:
On 11/09/2016 08:02 AM, Simo Sorce
wrote:
> > > Although this is true, one thing we could do is set a default
hostname
> > > that is static ("fedora" or similar is
fine), and teach the
utilities
> > > used to join an AD/IPA/etc.. domain to generate a new
random
hostname if
> they detect the hostname is the generic "static" one.
> The hostname is used in the install-time-generated disk volume
names
> (/dev/mapper/fedora_myhostname-home), so changing it is
confusing.
> Would it make sense to leave the old names? or rename the
volumes?
_______________________________________________
devel mailing list -- devel(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
Is using a unique volume group name not actually preferable.
If one needs to add a disk from one machine to another it avoids the
problem of having 2 volume groups with the same name and therefore
overlapping LV names.
I got bitten by that once.
/Louis
3:44 p.m.
On 11/9/2016 1:30 PM, Louis Lagendijk wrote:
On Wed, 2016-11-09 at 12:58 -0500, Przemek Klosowski wrote:
> On 11/09/2016 08:02 AM, Simo Sorce wrote:
>> Although this is true, one thing we could do is set a default hostname
>> that is static ("fedora" or similar is fine), and teach the utilities
>> used to join an AD/IPA/etc.. domain to generate a new random hostname if
>> they detect the hostname is the generic "static" one.
> The hostname is used in the install-time-generated disk volume names
> (/dev/mapper/fedora_myhostname-home), so changing it is confusing.
> Would it make sense to leave the old names? or rename the volumes?
> _______________________________________________
> devel mailing list --devel(a)lists.fedoraproject.org
<mailto:devel@lists.fedoraproject.org>
> To unsubscribe send an email todevel-leave(a)lists.fedoraproject.org
> <devel-leave(a)lists.fedoraproject.org%0A>
Is using a unique volume group name not actually preferable.
If one needs to add a disk from one machine to another it avoids the
problem of having 2 volume groups with the same name and therefore
overlapping LV names.
I got bitten by that once.
/Louis
The problem is that those VG/LV names are distinct from the host they're
a part of.... The only thing worse than a generic label for something is
an incorrect or misleading one, as happens occasionally with clones,
host renames or imaging a VM on top of that.
If we really don't have a better, persistent, local name for a system at
install time, then I don't see why reverting to /dev/VolGroup00/LogVol00
is horrible here. VG names should be human-readable and exist in a
namespace; shouldn't uniqueness should be from VG/LV UUIDs when we need it?
-jc
4:48 p.m.
On Wed, Nov 09, 2016 at 01:44:25PM -0800, Japheth Cleaver wrote:
If we really don't have a better, persistent, local name for a
system at install time, then I don't see why reverting to
/dev/VolGroup00/LogVol00 is horrible here. VG names should be
human-readable and exist in a namespace; shouldn't uniqueness should
be from VG/LV UUIDs when we need it?
We explicitly switched from VolGroup00/LogVol00 because it caused
problems if you tried to mount virtual machine disks on the host (of
course you should use libguestfs instead, but some people still try to
do this).
The bug was: https://bugzilla.redhat.com/show_bug.cgi?id=207470
Why don't we just use randomized vgXXXXXX/lvXXXXXX names here,
independent of the hostname?
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-df lists disk usage of guests without needing to install any
software inside the virtual machine. Supports Linux and Windows.
http://people.redhat.com/~rjones/virt-df/
7:32 a.m.
On Tue, Nov 08, 2016 at 03:25:58PM -0800, Andrew Lutomirski wrote:
If the hostname is non-constant, can we also arrange that, by
default,
this hostname is never sent over the network? In particular, I think
that DHCP requests should *not* include this hostname. We're already
starting to randomize MAC addresses -- there's no reason to give a
persistent per-installation identifier to every network.
There's two different cases that I'm not sure how to resolve elegantly.
On a home network or on a business network, having the name available
is highly desirable. On a public network, just the opposite.
--
Matthew Miller
<mattdm(a)fedoraproject.org>
Fedora Project Leader
4:37 p.m.
I think Matthew is right. Maybe we could set a behaviour in Fedora
Server or Cloud and another in Fedora Workstation?
Just an idea, Sylvia
On 09/11/16 14:32, Matthew Miller wrote:
On Tue, Nov 08, 2016 at 03:25:58PM -0800, Andrew Lutomirski wrote:
> If the hostname is non-constant, can we also arrange that, by default,
> this hostname is never sent over the network? In particular, I think
> that DHCP requests should *not* include this hostname. We're already
> starting to randomize MAC addresses -- there's no reason to give a
> persistent per-installation identifier to every network.
There's two different cases that I'm not sure how to resolve elegantly.
On a home network or on a business network, having the name available
is highly desirable. On a public network, just the opposite.
4:17 a.m.
On 11/09/2016 02:32 PM, Matthew Miller wrote:
On Tue, Nov 08, 2016 at 03:25:58PM -0800, Andrew Lutomirski wrote:
> If the hostname is non-constant, can we also arrange that, by default,
> this hostname is never sent over the network? In particular, I think
> that DHCP requests should *not* include this hostname. We're already
> starting to randomize MAC addresses -- there's no reason to give a
> persistent per-installation identifier to every network.
There's two different cases that I'm not sure how to resolve elegantly.
On a home network or on a business network, having the name available
is highly desirable. On a public network, just the opposite.
Add a checkbox in nm so that users can state whether they are on a
trusted network or not ??
Theo.
5:30 a.m.
On Thu, Nov 10, 2016 at 11:17:20AM +0100, Theodore Papadopoulo wrote:
Add a checkbox in nm so that users can state whether they are on a
trusted network or not ??
We have something like this already in Firewall Zones. I think it would
be great to develop that further.
--
Matthew Miller
<mattdm(a)fedoraproject.org>
Fedora Project Leader
10:45 a.m.
On Thu, Nov 10, 2016 at 11:17:20AM +0100, Theodore Papadopoulo wrote:
On 11/09/2016 02:32 PM, Matthew Miller wrote:
> On Tue, Nov 08, 2016 at 03:25:58PM -0800, Andrew Lutomirski wrote:
>> If the hostname is non-constant, can we also arrange that, by default,
>> this hostname is never sent over the network? In particular, I think
>> that DHCP requests should *not* include this hostname. We're already
>> starting to randomize MAC addresses -- there's no reason to give a
>> persistent per-installation identifier to every network.
>
> There's two different cases that I'm not sure how to resolve elegantly.
> On a home network or on a business network, having the name available
> is highly desirable. On a public network, just the opposite.
Add a checkbox in nm so that users can state whether they are on a
trusted network or not ??
This is what Windows does.
I'm not sure it's a good idea for other reasons - almost no common
network should be "trusted" ... Should you be sharing your machine
name on your home network that contains some insecure IoT crapware?
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-df lists disk usage of guests without needing to install any
software inside the virtual machine. Supports Linux and Windows.
http://people.redhat.com/~rjones/virt-df/
11:57 a.m.
On 11/10/2016 8:45 AM, Richard W.M. Jones wrote:
On Thu, Nov 10, 2016 at 11:17:20AM +0100, Theodore Papadopoulo
wrote:
> On 11/09/2016 02:32 PM, Matthew Miller wrote:
>> On Tue, Nov 08, 2016 at 03:25:58PM -0800, Andrew Lutomirski wrote:
>>> If the hostname is non-constant, can we also arrange that, by default,
>>> this hostname is never sent over the network? In particular, I think
>>> that DHCP requests should *not* include this hostname. We're already
>>> starting to randomize MAC addresses -- there's no reason to give a
>>> persistent per-installation identifier to every network.
>> There's two different cases that I'm not sure how to resolve elegantly.
>> On a home network or on a business network, having the name available
>> is highly desirable. On a public network, just the opposite.
>
> Add a checkbox in nm so that users can state whether they are on a
> trusted network or not ??
This is what Windows does.
I'm not sure it's a good idea for other reasons - almost no common
network should be "trusted" ... Should you be sharing your machine
name on your home network that contains some insecure IoT crapware?
Rich.
It seems like that should be a policy decision made by an administrator
or user (or at least the spin/distro builder), especially if the
alternative means not having that flexibility at a low level of
infrastructure.
We're still being gently nudged to be using NM on actual servers, right?
-jc
3:04 a.m.
Dne 9.11.2016 v 00:19 Neal Gompa napsal(a):
On Tue, Nov 8, 2016 at 6:14 PM, Zbigniew Jędrzejewski-Szmek
<zbyszek(a)in.waw.pl> wrote:
> On Tue, Nov 08, 2016 at 05:25:36PM -0500, Matthew Miller wrote:
>> On Tue, Nov 08, 2016 at 04:49:42PM -0500, Stephen Gallagher wrote:
>>> SUSE generates a random name of the format linux-XXXXXX (I'm not sure how
many
>>> My proposal is that we should consider changing the default hostname for
Fedora
>>> 26 to be either FED-XXXXXXXXXXX or FEDORA-XXXXXXXX. The former allows for a
>> How about non-yelly Fedora-XXXXXXXXXXX? Since SUSE apparently does
>> lower case, that should be fine, right?
> Bastian Nocera also filed https://bugzilla.redhat.com/show_bug.cgi?id=1392925,
> where he proposes "fedora" as the hostname. I think "fedora" is
better than
> "localhost", and a non-constant hostname would be even better.
> For interactive installs (like with anaconda) it would be great if we could
> ask for the hostname. For non-interactive ones, "Fedora-[0-9a-z-]{8}"
seems
> like a good option (*). It would give "branding", and solve the freeipa
issues.
> It would also be a good default for the interactive case, so that people can
> "click through" without having to pick anything.
>
> (*) The suffix could include dashes for more possibilities, but they should
> not be adjacent or at the end.
I'm in favor of defaulting to "Fedora-[0-9a-z-]{8}" myself. However,
I'm concerned that people don't realize that we can, in fact, set the
hostname during installation. People usually don't because Anaconda
doesn't currently make that mandatory or otherwise note that it's
possible during the initial panel of spokes (hint: it's the networking
spoke), and so the default of "localhost" continues on without anyone
being the wiser.
Speaking in "workstation" context, people might realize it is possible
to change, but they don't care. My computer is not my pet, I don't need
to name it, I couldn't care less. Honestly, it would be better if the
hostname was not shown in my terminal by default.
Vít
7:06 a.m.
On Wed, 2016-11-09 at 10:04 +0100, Vít Ondruch wrote:
Dne 9.11.2016 v 00:19 Neal Gompa napsal(a):
> On Tue, Nov 8, 2016 at 6:14 PM, Zbigniew Jędrzejewski-Szmek
> <zbyszek(a)in.waw.pl> wrote:
>> On Tue, Nov 08, 2016 at 05:25:36PM -0500, Matthew Miller wrote:
>>> On Tue, Nov 08, 2016 at 04:49:42PM -0500, Stephen Gallagher wrote:
>>>> SUSE generates a random name of the format linux-XXXXXX (I'm not
sure how many
>>>> My proposal is that we should consider changing the default hostname for
Fedora
>>>> 26 to be either FED-XXXXXXXXXXX or FEDORA-XXXXXXXX. The former allows
for a
>>> How about non-yelly Fedora-XXXXXXXXXXX? Since SUSE apparently does
>>> lower case, that should be fine, right?
>> Bastian Nocera also filed https://bugzilla.redhat.com/show_bug.cgi?id=1392925,
>> where he proposes "fedora" as the hostname. I think "fedora"
is better than
>> "localhost", and a non-constant hostname would be even better.
>> For interactive installs (like with anaconda) it would be great if we could
>> ask for the hostname. For non-interactive ones, "Fedora-[0-9a-z-]{8}"
seems
>> like a good option (*). It would give "branding", and solve the
freeipa issues.
>> It would also be a good default for the interactive case, so that people can
>> "click through" without having to pick anything.
>>
>> (*) The suffix could include dashes for more possibilities, but they should
>> not be adjacent or at the end.
> I'm in favor of defaulting to "Fedora-[0-9a-z-]{8}" myself. However,
> I'm concerned that people don't realize that we can, in fact, set the
> hostname during installation. People usually don't because Anaconda
> doesn't currently make that mandatory or otherwise note that it's
> possible during the initial panel of spokes (hint: it's the networking
> spoke), and so the default of "localhost" continues on without anyone
> being the wiser.
>
>
>
Speaking in "workstation" context, people might realize it is possible
to change, but they don't care. My computer is not my pet, I don't need
to name it, I couldn't care less. Honestly, it would be better if the
hostname was not shown in my terminal by default.
The hostname is shown, historically, to allow you to understand on which
machine you are running a command. It is oriented toward a sysadmin
world, where it is common to log into many machines via telnet/rsh/ssh
to perform various tasks.
If we can ship default configurations that show the hostname in PS1 only
for shells running on a remotely initiated connection and leave the
prompt to something very short then I think that would work fine.
Simo.
--
Simo Sorce * Red Hat, Inc * New York
7:18 a.m.
On 11/09/2016 08:06 AM, Simo Sorce wrote:
On Wed, 2016-11-09 at 10:04 +0100, Vít Ondruch wrote:
> Speaking in "workstation" context, people might realize it is possible
> to change, but they don't care. My computer is not my pet, I don't need
> to name it, I couldn't care less. Honestly, it would be better if the
> hostname was not shown in my terminal by default.
The hostname is shown, historically, to allow you to understand on which
machine you are running a command. It is oriented toward a sysadmin
world, where it is common to log into many machines via telnet/rsh/ssh
to perform various tasks.
If we can ship default configurations that show the hostname in PS1 only
for shells running on a remotely initiated connection and leave the
prompt to something very short then I think that would work fine.
Historical reasons aside, part of this discussion was launched because having
something visible in the terminal that reminded a user that they are on Fedora
is of interest from a branding perspective. Since we already have the hostname
displayed there and we've established that defaulting to a static
"localhost"
name is less than ideal, it seemed like an easy place to score double points:
fix the hostname problem by selecting a default that would also help with branding.
Now, regarding Simo's point: I don't know if it's necessarily something we
want
to do by default, but it's definitely possible to accomplish with Powerline[1]
(I know this because that's exactly how I have my system set up today).
If that's something we would legitimately like to add to Workstation by default,
please start a new thread on desktop(a)lists.fedoraproject.org where it can be
discussed and designed.
[1] https://fedoramagazine.org/add-power-terminal-powerline/
1:04 p.m.
On Tue, 08.11.16 23:14, Zbigniew Jędrzejewski-Szmek (zbyszek(a)in.waw.pl) wrote:
On Tue, Nov 08, 2016 at 05:25:36PM -0500, Matthew Miller wrote:
> On Tue, Nov 08, 2016 at 04:49:42PM -0500, Stephen Gallagher wrote:
> > SUSE generates a random name of the format linux-XXXXXX (I'm not sure how
many
> > My proposal is that we should consider changing the default hostname for
Fedora
> > 26 to be either FED-XXXXXXXXXXX or FEDORA-XXXXXXXX. The former allows for a
>
> How about non-yelly Fedora-XXXXXXXXXXX? Since SUSE apparently does
> lower case, that should be fine, right?
Bastian Nocera also filed https://bugzilla.redhat.com/show_bug.cgi?id=1392925,
where he proposes "fedora" as the hostname. I think "fedora" is
better than
"localhost", and a non-constant hostname would be even better.
For interactive installs (like with anaconda) it would be great if we could
ask for the hostname. For non-interactive ones, "Fedora-[0-9a-z-]{8}" seems
like a good option (*). It would give "branding", and solve the freeipa
issues.
It would also be a good default for the interactive case, so that people can
"click through" without having to pick anything.
I'd be careful with this. I'd prefer a more generic default hostname
over a more specific, so that we leak as little information about our
system onto the network as possible.
I mean, using "localhost.localdomain" is already leaky enough, given
that only fedora is using this as default hostname — however, it's
still better than telling everyone "Hay, I am running Fedora!".
Lennart
--
Lennart Poettering, Red Hat
1:48 p.m.
On 10 November 2016 at 14:04, Lennart Poettering <mzerqung(a)0pointer.de> wrote:
On Tue, 08.11.16 23:14, Zbigniew Jędrzejewski-Szmek
(zbyszek(a)in.waw.pl) wrote:
> On Tue, Nov 08, 2016 at 05:25:36PM -0500, Matthew Miller wrote:
> > On Tue, Nov 08, 2016 at 04:49:42PM -0500, Stephen Gallagher wrote:
> > > SUSE generates a random name of the format linux-XXXXXX (I'm not sure
how many
> > > My proposal is that we should consider changing the default hostname for
Fedora
> > > 26 to be either FED-XXXXXXXXXXX or FEDORA-XXXXXXXX. The former allows for
a
> >
> > How about non-yelly Fedora-XXXXXXXXXXX? Since SUSE apparently does
> > lower case, that should be fine, right?
>
> Bastian Nocera also filed https://bugzilla.redhat.com/show_bug.cgi?id=1392925,
> where he proposes "fedora" as the hostname. I think "fedora" is
better than
> "localhost", and a non-constant hostname would be even better.
> For interactive installs (like with anaconda) it would be great if we could
> ask for the hostname. For non-interactive ones, "Fedora-[0-9a-z-]{8}"
seems
> like a good option (*). It would give "branding", and solve the freeipa
issues.
> It would also be a good default for the interactive case, so that people can
> "click through" without having to pick anything.
I'd be careful with this. I'd prefer a more generic default hostname
over a more specific, so that we leak as little information about our
system onto the network as possible.
I mean, using "localhost.localdomain" is already leaky enough, given
that only fedora is using this as default hostname — however, it's
still better than telling everyone "Hay, I am running Fedora!".
The one thing to be aware of is that some of these items while useful
to fingerprint aren't as reliable as things we leak elsewhere like
kernel version/glibc version/compile time flags and how we respond to
TCP requests. Those usually leak a lot more and are much easier to get
even sneakily than localhost.localdomain or fedora-xxxxxx. You also
have to be careful about appearing too random [say changing the mac
address each connection.. it needs to change within certain noise
levels or you look "like someone with something to hide." versus
someone trying to blend in.]
Lennart
--
Lennart Poettering, Red Hat
_______________________________________________
devel mailing list -- devel(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
--
Stephen J Smoogen.
12:20 a.m.
On Tue, Nov 08, 2016 at 04:49:42PM -0500, Stephen Gallagher wrote:
Mac OS X and Ubuntu both require the user to pick a machine name at install time
explicitly. They do not autogenerate one at all.
I'm not sure is it 100% correct, but my knowledge may be outdated.
Both macOS and Ubuntu asks for first user during the installation.
Then both suggest hostname, created by combining entered user name
and form factor of machine being installed. Ubuntu even incorporates
specific model name, read from DMI data.
Thus, macOS and Ubuntu on my laptop would suggest hostnames as
“tomasz-laptop” or “tomasz-thinkpad-t400”.
--
Tomasz Torcz Morality must always be based on practicality.
xmpp: zdzichubg(a)chrome.pl -- Baron Vladimir Harkonnen
12:34 a.m.
Tomasz Torcz wrote:
I'm not sure is it 100% correct, but my knowledge may be
outdated.
Both macOS and Ubuntu asks for first user during the installation.
Then both suggest hostname, created by combining entered user name
and form factor of machine being installed. Ubuntu even incorporates
specific model name, read from DMI data.
Thus, macOS and Ubuntu on my laptop would suggest hostnames as
“tomasz-laptop” or “tomasz-thinkpad-t400”.
For the record, Calamares (https://calamares.io/ – packaged as "calamares"
in Fedora) does something similar, but even simpler, it just always uses
"-pc", e.g., it would suggest "tomasz-pc" to you.
Kevin Kofler
1:51 a.m.
On Tue, 2016-11-08 at 16:49 -0500, Stephen Gallagher wrote:
My proposal is that we should consider changing the default hostname
for Fedora 26 to be either FED-XXXXXXXXXXX or FEDORA-XXXXXXXX. The
former allows for a longer random string and therefore lower risk of
collision in large environments, while the latter would also provide
improved branding for Fedora[2]. Our default BASH shell prompt
includes the current machine's hostname.
Using the command line for branding should be considered mostly
separately from the question of the hostname. There are really two
separate cases for the prompt string:
1) ssh'ed into a remote system, or a VM
2) Running a local terminal on the desktop
2) accounts for a large fraction of the interactions Fedora users's
have with our prompt string. In this case, there's *no* reason we
should currently be showing:
[otaylor@localhost ~]$
In the prompt (and in the window title) title - this is constantly
making the visual environment more busy, and the space available on the
line shorter. Both problems are excacerbated if that becomes:
[otaylor@fedora-7741f32a ~]$
While fedora-7741f32a provides *marginally* more information than
"localhost", it still doesn't have anything to do with what the user is
trying to do. If we want to brand the prompt, for the local terminal on
the desktop case, we're better off with, say:
[fedora ~]$
normally, and:
[root@fedora /etc]$
when youve switched to a different user.
- Owen
12:03 p.m.
On Tue, Nov 08, 2016 at 04:49:42PM -0500, Stephen Gallagher wrote:
Mac OS X and Ubuntu both require the user to pick a machine name at
install time
explicitly. They do not autogenerate one at all.
Sort of. If you install using the example Ubuntu preseed file then by
default it will have "unassigned-hostname.unassigned-domain". You're
supposed to change this, but if you don't then that's the hostname you
will actually get in your new machine.
My proposal is that we should consider changing the default hostname
for Fedora 26 to be either FED-XXXXXXXXXXX or FEDORA-XXXXXXXX. The
former allows for a longer random string and therefore lower risk of
collision in large environments, while the latter would also provide
improved branding for Fedora[2]. Our default BASH shell prompt
includes the current machine's hostname.
Having it CAPS doesn't sound very nice ...
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-top is 'top' for virtual machines. Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://people.redhat.com/~rjones/virt-top
12:27 p.m.
On 11/09/2016 01:03 PM, Richard W.M. Jones wrote:
On Tue, Nov 08, 2016 at 04:49:42PM -0500, Stephen Gallagher wrote:
> My proposal is that we should consider changing the default hostname
> for Fedora 26 to be either FED-XXXXXXXXXXX or FEDORA-XXXXXXXX. The
> former allows for a longer random string and therefore lower risk of
> collision in large environments, while the latter would also provide
> improved branding for Fedora[2]. Our default BASH shell prompt
> includes the current machine's hostname.
Having it CAPS doesn't sound very nice ...
Yeah, that's fine. I was kind of copying off the windows approach, but I really
don't care at all whether we present it in lower-case or upper-case as long as
it's consistent.
7:08 a.m.
On 11/09/2016 07:27 PM, Stephen Gallagher wrote:
On 11/09/2016 01:03 PM, Richard W.M. Jones wrote:
> Having it CAPS doesn't sound very nice ...
>
Yeah, that's fine. I was kind of copying off the windows approach, but I really
don't care at all whether we present it in lower-case or upper-case as long as
it's consistent.
All lower case, please.
Lower case is the default everywhere in Unix, and the hostname also contains
an Internet related meaning, where only lower case is used.
--
Roberto Ragusa mail at robertoragusa.it
8:21 a.m.
On Thu, Nov 10, 2016 at 02:08:48PM +0100, Roberto Ragusa wrote:
On 11/09/2016 07:27 PM, Stephen Gallagher wrote:
> On 11/09/2016 01:03 PM, Richard W.M. Jones wrote:
>> Having it CAPS doesn't sound very nice ...
>>
>
> Yeah, that's fine. I was kind of copying off the windows approach, but I really
don't care at all whether we present it in lower-case or upper-case as long as
it's consistent.
All lower case, please.
Lower case is the default everywhere in Unix, and the hostname also contains
an Internet related meaning, where only lower case is used.
Nah, the internet is case-insensitive. And Fedora is a name, starts with
a capital letter.
Zbyszek
8:27 a.m.
On 11/10/2016 09:21 AM, Zbigniew Jędrzejewski-Szmek wrote:
On Thu, Nov 10, 2016 at 02:08:48PM +0100, Roberto Ragusa wrote:
> On 11/09/2016 07:27 PM, Stephen Gallagher wrote:
>> On 11/09/2016 01:03 PM, Richard W.M. Jones wrote:
>
>>> Having it CAPS doesn't sound very nice ...
>>>
>>
>> Yeah, that's fine. I was kind of copying off the windows approach, but I
really don't care at all whether we present it in lower-case or upper-case as long as
it's consistent.
>
> All lower case, please.
> Lower case is the default everywhere in Unix, and the hostname also contains
> an Internet related meaning, where only lower case is used.
Nah, the internet is case-insensitive. And Fedora is a name, starts with
a capital letter.
I personally like the idea of the proper name as well, but the Internet is *not*
universally case-insensitive, actually. The scheme and hostname parts must be
case-insensitive[1], but the rest of the URI may be case-sensitive or
case-insensitive at the preference of the web server. Which is terrible, but
reality.
That said, since hostname is permitted to be case-insensitive, I'd like to
support "Fedora-XXXXXXXX" as the proposed name, because Fedora in our case is a
proper noun (which has specific meaning and emphasis in English, at least). A
fedora is a hat.
Fedora is a way of life :-D
[1] https://tools.ietf.org/html/rfc3986#section-3.2.2
9:18 a.m.
On 10 November 2016 at 09:27, Stephen Gallagher <sgallagh(a)redhat.com> wrote:
>> On 11/09/2016 07:27 PM, Stephen Gallagher wrote:
Here are the items I would like to point out:
1. The TLD name should be something that DNS considers a known unknown
name. With the fact that IANA is allowing top level domains of all
sorts we do not want to end up having .fedora or .foobaz end up
causing thousands of computers saying they are in someones domain. So
.invalid .localhost .example .local or .test . I expect that
.localdomain might not ever be registered but who knows.
2. The XXXXXX is rather important because of two conflicting items.
One we don't want it to be too short that collisions might occur a
lot, but we don't want it to be too long for readability but also the
less collisions the more likely it can be used to track people. If we
don't care about making breadcrumbs which could be used to 'track'
people we need to be clear about it so that people who are not wanting
that can steer clear. [My 'I am an idiot about randomness' solution
would be uuidgen | sum and that number is used for this. There is a
good chance of uniqueness per small site and non-uniqueness overall. ]
3. case-sensitivity argument about Fedora or fedora looks to be a
bikeshed. There are probably local business reasons where having
caps/lowercase in names is important but in those cases they should
put in tools to conform to their local business reason.
--
Stephen J Smoogen.
9:31 a.m.
On 11/10/2016 10:18 AM, Stephen John Smoogen wrote:
On 10 November 2016 at 09:27, Stephen Gallagher
<sgallagh(a)redhat.com> wrote:
>
>>> On 11/09/2016 07:27 PM, Stephen Gallagher wrote:
Here are the items I would like to point out:
1. The TLD name should be something that DNS considers a known unknown
name. With the fact that IANA is allowing top level domains of all
sorts we do not want to end up having .fedora or .foobaz end up
causing thousands of computers saying they are in someones domain. So
.invalid .localhost .example .local or .test . I expect that
.localdomain might not ever be registered but who knows.
RFC 2606[1] reserves several TLDs that may never be registered for public
usage. Out of those, going with
Fedora-XXXXXXXX.localhost
seems like the best bet.
[1] https://tools.ietf.org/html/rfc2606#page-2
2. The XXXXXX is rather important because of two conflicting items.
One we don't want it to be too short that collisions might occur a
lot, but we don't want it to be too long for readability but also the
less collisions the more likely it can be used to track people. If we
don't care about making breadcrumbs which could be used to 'track'
people we need to be clear about it so that people who are not wanting
that can steer clear. [My 'I am an idiot about randomness' solution
would be uuidgen | sum and that number is used for this. There is a
good chance of uniqueness per small site and non-uniqueness overall. ]
Again, I think that tracking issues are orthogonal to this ticket. Anyone who
sets a hostname *manually* is already unique. If that's something to be
concerned about, then it's better to solve that at whatever layers reveal this
information.
3. case-sensitivity argument about Fedora or fedora looks to be a
bikeshed. There are probably local business reasons where having
caps/lowercase in names is important but in those cases they should
put in tools to conform to their local business reason.
Yeah, I mostly just want Fedora for the proper noun. Since it serves no
functional difference, I don't care much. After the conversation we've had so
far, I *do* think we're more or less agreed that we want the longer
"Fedora"
rather than "fed" prefix though.
10:21 a.m.
On 10 November 2016 at 10:31, Stephen Gallagher <sgallagh(a)redhat.com> wrote:
On 11/10/2016 10:18 AM, Stephen John Smoogen wrote:
> On 10 November 2016 at 09:27, Stephen Gallagher <sgallagh(a)redhat.com> wrote:
>>
>>>> On 11/09/2016 07:27 PM, Stephen Gallagher wrote:
>
>
> Here are the items I would like to point out:
>
> 1. The TLD name should be something that DNS considers a known unknown
> name. With the fact that IANA is allowing top level domains of all
> sorts we do not want to end up having .fedora or .foobaz end up
> causing thousands of computers saying they are in someones domain. So
> .invalid .localhost .example .local or .test . I expect that
> .localdomain might not ever be registered but who knows.
>
RFC 2606[1] reserves several TLDs that may never be registered for public
usage. Out of those, going with
Fedora-XXXXXXXX.localhost
seems like the best bet.
[1] https://tools.ietf.org/html/rfc2606#page-2
> 2. The XXXXXX is rather important because of two conflicting items.
> One we don't want it to be too short that collisions might occur a
> lot, but we don't want it to be too long for readability but also the
> less collisions the more likely it can be used to track people. If we
> don't care about making breadcrumbs which could be used to 'track'
> people we need to be clear about it so that people who are not wanting
> that can steer clear. [My 'I am an idiot about randomness' solution
> would be uuidgen | sum and that number is used for this. There is a
> good chance of uniqueness per small site and non-uniqueness overall. ]
>
Again, I think that tracking issues are orthogonal to this ticket. Anyone who
sets a hostname *manually* is already unique. If that's something to be
concerned about, then it's better to solve that at whatever layers reveal this
information.
That is solving it too late because there will always be leaks.
Privacy is just another form of security. If you don't design it in as
best you can early on, you are spending too much work later trying to
patch it in.
Currently hostnames and volumegroups would not be that useful to track
people down. We all like to think that we have come up with that
unique name for the computer.. but in general it isn't that unique and
there are going to be anywhere from 10 to millions of other computers
with that identifier. That actually obscures data and so makes it less
likely to be used.
However anything which is machine created to try and make sure there
aren't easy collisions is a boon to tracking. And any identifier which
may be used in multiple places because it makes it easier on a system
admin or a general program.. bonus. So let us say we don't take this
into consideration until much later or higher in the stack and we want
to make sure that we don't have collisions. So we go with something
like a Fed-<12 char [0-9a-z]> identifier. Because we now have a unique
identifier it tends to get used everywhere that a confusion of names
might occur.. thus vg-<12 char [0-9a-z]> etc.
This makes programmers and system administrators lives easier because
you can have a huge storage array with unique names... yay. However it
also makes the person who has the laptop with Fed-0123456789ab
vg-0123456789ab, etc etc stand out like a sore thumb as various parts
of that data might get leaked out in different places. The hostname
shows up in dhcp logs, the vg shows up in browser environment
variables., some other tools decides that the sys-id is useful for
cookie generation, etc etc. Each time you think you have gotten all
the apps fixed, some programmer finds this unique id, realizes it
makes their life easier for some other problem they have and uses it
again.
So in any case, what I am suggesting is that we make a semi-unique
identifier. It is unique enough that you won't get a collision in some
'target' space, but not so unique that it stands out like a black dot
on a white shirt. Make the code adjustable somewhere in the process so
that if someone wants it off, it can be done and if they need it to be
a bigger space it can be done so.
> 3. case-sensitivity argument about Fedora or fedora looks to be a
> bikeshed. There are probably local business reasons where having
> caps/lowercase in names is important but in those cases they should
> put in tools to conform to their local business reason.
Yeah, I mostly just want Fedora for the proper noun. Since it serves no
functional difference, I don't care much. After the conversation we've had so
far, I *do* think we're more or less agreed that we want the longer
"Fedora"
rather than "fed" prefix though.
_______________________________________________
devel mailing list -- devel(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
--
Stephen J Smoogen.
10:58 a.m.
On Thu, 10 Nov 2016 11:21:13 -0500
Stephen John Smoogen <smooge(a)gmail.com> wrote:
So in any case, what I am suggesting is that we make a semi-unique
identifier. It is unique enough that you won't get a collision in some
'target' space, but not so unique that it stands out like a black dot
on a white shirt. Make the code adjustable somewhere in the process so
that if someone wants it off, it can be done and if they need it to be
a bigger space it can be done so.
Isn't this pretty trivial to create? We put a limit on the number of
machines that are accessible on a local network, say 10 million. Then
we start at
Fedora-1.localhost.
e.g.
'Fedora-' + str (counter) + '.localhost'
So if there is only one computer on the local network it is named
Fedora-1.localhost.
If there is more than one computer on the local network, we check for
collisions with names until we hit the next in numerical order that
isn't taken.
while name_taken,
counter += 1
hostname = 'Fedora-' + str (counter) + '.localhost'
name_taken = check_for_collision (hostname)
This ensures there will be *lots* of collisions on the web, but zero
locally, at least for the first few hosts.
Or am I missing something?
11:11 a.m.
On Thu, 2016-11-10 at 09:58 -0700, stan wrote:
On Thu, 10 Nov 2016 11:21:13 -0500
Stephen John Smoogen <smooge(a)gmail.com> wrote:
> So in any case, what I am suggesting is that we make a semi-unique
> identifier. It is unique enough that you won't get a collision in some
> 'target' space, but not so unique that it stands out like a black dot
> on a white shirt. Make the code adjustable somewhere in the process so
> that if someone wants it off, it can be done and if they need it to be
> a bigger space it can be done so.
Isn't this pretty trivial to create? We put a limit on the number of
machines that are accessible on a local network, say 10 million. Then
we start at
Fedora-1.localhost.
e.g.
'Fedora-' + str (counter) + '.localhost'
So if there is only one computer on the local network it is named
Fedora-1.localhost.
If there is more than one computer on the local network, we check for
collisions with names until we hit the next in numerical order that
isn't taken.
while name_taken,
counter += 1
hostname = 'Fedora-' + str (counter) + '.localhost'
name_taken = check_for_collision (hostname)
This ensures there will be *lots* of collisions on the web, but zero
locally, at least for the first few hosts.
Or am I missing something?
How exactly are you planning to check for collisions with hosts that
are shut down or somewhere else (laptops)?
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
11:40 a.m.
On 10 November 2016 at 12:11, Adam Williamson
<adamwill(a)fedoraproject.org> wrote:
On Thu, 2016-11-10 at 09:58 -0700, stan wrote:
> On Thu, 10 Nov 2016 11:21:13 -0500
> Stephen John Smoogen <smooge(a)gmail.com> wrote:
>
> > So in any case, what I am suggesting is that we make a semi-unique
> > identifier. It is unique enough that you won't get a collision in some
> > 'target' space, but not so unique that it stands out like a black dot
> > on a white shirt. Make the code adjustable somewhere in the process so
> > that if someone wants it off, it can be done and if they need it to be
> > a bigger space it can be done so.
>
> Isn't this pretty trivial to create? We put a limit on the number of
> machines that are accessible on a local network, say 10 million. Then
> we start at
> Fedora-1.localhost.
> e.g.
> 'Fedora-' + str (counter) + '.localhost'
>
> So if there is only one computer on the local network it is named
> Fedora-1.localhost.
>
> If there is more than one computer on the local network, we check for
> collisions with names until we hit the next in numerical order that
> isn't taken.
>
> while name_taken,
> counter += 1
> hostname = 'Fedora-' + str (counter) + '.localhost'
> name_taken = check_for_collision (hostname)
>
> This ensures there will be *lots* of collisions on the web, but zero
> locally, at least for the first few hosts.
>
> Or am I missing something?
How exactly are you planning to check for collisions with hosts that
are shut down or somewhere else (laptops)?
Or even how are you going to communicate that there is another machine
of that name? That is a registration and command and control issue in
a completely different 'stack' than the installer usually is in.
--
Stephen J Smoogen.
3:30 p.m.
On Thu, 10 Nov 2016 12:40:23 -0500
Stephen John Smoogen <smooge(a)gmail.com> wrote:
On 10 November 2016 at 12:11, Adam Williamson
<adamwill(a)fedoraproject.org> wrote:
> On Thu, 2016-11-10 at 09:58 -0700, stan wrote:
>> Or am I missing something?
>
> How exactly are you planning to check for collisions with hosts that
> are shut down or somewhere else (laptops)?
Or even how are you going to communicate that there is another machine
of that name? That is a registration and command and control issue in
a completely different 'stack' than the installer usually is in.
So I was missing something. :-)
11:03 p.m.
RFC 2606[1] reserves several TLDs that may never be registered for
public usage. Out of those, going with
Fedora-XXXXXXXX.localhost
seems like the best bet.
The *reason* localhost is a reserved name is to discourage its use in
DNS names. Your proposal is the opposite to that intended by RFC2606,
something which the casual reader of your message may have missed.
-glen
11:16 p.m.
On Sat, Nov 12, 2016 at 03:33:10PM +1030, Glen Turner wrote:
> RFC 2606[1] reserves several TLDs that may never be registered
for
> public usage. Out of those, going with
> Fedora-XXXXXXXX.localhost
> seems like the best bet.
The *reason* localhost is a reserved name is to discourage its use in
DNS names. Your proposal is the opposite to that intended by RFC2606,
something which the casual reader of your message may have missed.
Setting a hostname has nothing to do with what names are in the DNS, so
I have no idea how you came to that conclusion.
Perhaps you can explain further?
7:24 a.m.
On 11/12/2016 12:03 AM, Glen Turner wrote:
> RFC 2606[1] reserves several TLDs that may never be registered for
> public usage. Out of those, going with
> Fedora-XXXXXXXX.localhost
> seems like the best bet.
The *reason* localhost is a reserved name is to discourage its use in
DNS names. Your proposal is the opposite to that intended by RFC2606,
something which the casual reader of your message may have missed.
This misses something I neglected to point out in the original message. Sorry
about that.
When we enroll with FreeIPA or Active Directory through realmd, one side-effect
of this enrollment is that the domain part of the local hostname is changed to
match that of the domain into which they are enrolled.
So if we set fedora-abcdefgh.localhost as the default domain and then enrolled
with FreeIPA domain "fedoraproject.org", then the machine's full hostname
would
become fedora-abcdefgh.fedoraproject.org
So my proposal really *was* to indicate that the default hostname should only be
used when not part of a formal domain.
2:06 p.m.
On Thu, Nov 10, 2016 at 10:18:21AM -0500, Stephen John Smoogen wrote:
On 10 November 2016 at 09:27, Stephen Gallagher
<sgallagh(a)redhat.com> wrote:
>
>>> On 11/09/2016 07:27 PM, Stephen Gallagher wrote:
Here are the items I would like to point out:
1. The TLD name should be something that DNS considers a known unknown
name. With the fact that IANA is allowing top level domains of all
sorts we do not want to end up having .fedora or .foobaz end up
causing thousands of computers saying they are in someones domain. So
.invalid .localhost .example .local or .test . I expect that
.localdomain might not ever be registered but who knows.
Or better, don't provide any TLD. Plain local hostname is enough for
all the purposes mentioned.
2. The XXXXXX is rather important because of two conflicting items.
One we don't want it to be too short that collisions might occur a
lot, but we don't want it to be too long for readability but also the
less collisions the more likely it can be used to track people. If we
don't care about making breadcrumbs which could be used to 'track'
people we need to be clear about it so that people who are not wanting
that can steer clear. [My 'I am an idiot about randomness' solution
would be uuidgen | sum and that number is used for this. There is a
good chance of uniqueness per small site and non-uniqueness overall. ]
I don't think you can have both. If the randomized part is long enough
to have rare collisions, it'll certainly be good enough for tracking.
If you consider that tracking can combine any external information
(like the MAC address or anything else that it learns about the machine),
tracking will "win" with many less bits of information.
Instead, we should concentrate on not leaking the hostname in places
where it shouldn't be leaked, for example on untrusted networks.
3. case-sensitivity argument about Fedora or fedora looks to be a
bikeshed. There are probably local business reasons where having
caps/lowercase in names is important but in those cases they should
put in tools to conform to their local business reason.
Ack.
Zbyszek
2:14 p.m.
On 10 November 2016 at 15:06, Zbigniew Jędrzejewski-Szmek
<zbyszek(a)in.waw.pl> wrote:
On Thu, Nov 10, 2016 at 10:18:21AM -0500, Stephen John Smoogen
wrote:
> On 10 November 2016 at 09:27, Stephen Gallagher <sgallagh(a)redhat.com> wrote:
> >
> >>> On 11/09/2016 07:27 PM, Stephen Gallagher wrote:
>
>
> Here are the items I would like to point out:
>
> 1. The TLD name should be something that DNS considers a known unknown
> name. With the fact that IANA is allowing top level domains of all
> sorts we do not want to end up having .fedora or .foobaz end up
> causing thousands of computers saying they are in someones domain. So
> .invalid .localhost .example .local or .test . I expect that
> .localdomain might not ever be registered but who knows.
Or better, don't provide any TLD. Plain local hostname is enough for
all the purposes mentioned.
> 2. The XXXXXX is rather important because of two conflicting items.
> One we don't want it to be too short that collisions might occur a
> lot, but we don't want it to be too long for readability but also the
> less collisions the more likely it can be used to track people. If we
> don't care about making breadcrumbs which could be used to 'track'
> people we need to be clear about it so that people who are not wanting
> that can steer clear. [My 'I am an idiot about randomness' solution
> would be uuidgen | sum and that number is used for this. There is a
> good chance of uniqueness per small site and non-uniqueness overall. ]
I don't think you can have both. If the randomized part is long enough
to have rare collisions, it'll certainly be good enough for tracking.
If you consider that tracking can combine any external information
(like the MAC address or anything else that it learns about the machine),
tracking will "win" with many less bits of information.
Instead, we should concentrate on not leaking the hostname in places
where it shouldn't be leaked, for example on untrusted networks.
As in a later email, if that is what we are wanting, we need to design
that in earlier versus later because there will always be too many
ways to make something leaked for 'good intentions'. Rememeber, if
there is a screwdriver in the toolbox, some programmer is going to use
it as a hammer at some point because it was the first tool they pulled
out of the box. If there is a /etc/machine-id it will get used
because it is the simplest tool to get a unique identifier for some
'important' thing.
In the end though there are severe limits to how 'anonymous' anyone
can make stuff with off the shelf hardware. Especially when the
majority of people aren't using your anonymous Operating System. The
fact that only 1% of the people aren't makes them clearer in large
datasets than if we just decided to make everything look like Windows
8.1 or Vista.
> 3. case-sensitivity argument about Fedora or fedora looks to be
a
> bikeshed. There are probably local business reasons where having
> caps/lowercase in names is important but in those cases they should
> put in tools to conform to their local business reason.
Ack.
Zbyszek
_______________________________________________
devel mailing list -- devel(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
--
Stephen J Smoogen.
11:05 p.m.
On Thu, Nov 10, 2016 at 9:21 AM, Zbigniew Jędrzejewski-Szmek
<zbyszek(a)in.waw.pl> wrote:
On Thu, Nov 10, 2016 at 02:08:48PM +0100, Roberto Ragusa wrote:
> On 11/09/2016 07:27 PM, Stephen Gallagher wrote:
> > On 11/09/2016 01:03 PM, Richard W.M. Jones wrote:
>
> >> Having it CAPS doesn't sound very nice ...
> >>
> >
> > Yeah, that's fine. I was kind of copying off the windows approach, but I
really don't care at all whether we present it in lower-case or upper-case as long as
it's consistent.
>
> All lower case, please.
> Lower case is the default everywhere in Unix, and the hostname also contains
> an Internet related meaning, where only lower case is used.
Nah, the internet is case-insensitive. And Fedora is a name, starts with
a capital letter.
DNS is all translated to lower case, RFC 4343. AddInG CamelCase ThaT
WilL BE igNOReD bY coDE LeaDs To UnneCEssarY CompLeXitY AnD MisMatcHEd
AnD MisSpellllEd ConfIGUraTIonZ.
7:53 a.m.
On 8.11.2016 22:49, Stephen Gallagher wrote:
For as long as I can recall, Fedora has shipped with a default
hostname of
"localhost.localdomain"[1]. This default was "safe" for a very long
time because
we also shipped an /etc/hosts entry that routed this hostname to the loopback
device for the benefit of some older system services (like sendmail).
One aspect worth considering is that localhost.localdomain as installer
default means that if hostname is not set by user (in UI or kickstart),
transient hostname of installed system would be automatically set during
network configuration (by NM) from dhcp or DNS lookup if available
(Formerly anaconda used to set the installed sytem static hostname to
hostname obtained from dhcp or DNS in installation environment but based
on a bug report we stopped doing it).
Radek.
8:01 a.m.
On 11/10/2016 08:53 AM, Radek Vykydal wrote:
On 8.11.2016 22:49, Stephen Gallagher wrote:
> For as long as I can recall, Fedora has shipped with a default hostname of
> "localhost.localdomain"[1]. This default was "safe" for a very
long time because
> we also shipped an /etc/hosts entry that routed this hostname to the loopback
> device for the benefit of some older system services (like sendmail).
One aspect worth considering is that localhost.localdomain as installer default
means that if hostname is not set by user (in UI or kickstart), transient
hostname of installed system would be automatically set during network
configuration (by NM) from dhcp or DNS lookup if available (Formerly anaconda
used to set the installed sytem static hostname to hostname obtained from dhcp
or DNS in installation environment but based on a bug report we stopped doing it).
Sorry, Radek. I can't parse that. It sounds like you said that Anaconda does
automatically set the hostname and then you say you stopped doing that because
of a bug report. Which one is true for F25/26?
8:30 a.m.
On Thu, Nov 10, 2016 at 09:01:42AM -0500, Stephen Gallagher wrote:
On 11/10/2016 08:53 AM, Radek Vykydal wrote:
>
>
> On 8.11.2016 22:49, Stephen Gallagher wrote:
>> For as long as I can recall, Fedora has shipped with a default hostname of
>> "localhost.localdomain"[1]. This default was "safe" for a
very long time because
>> we also shipped an /etc/hosts entry that routed this hostname to the loopback
>> device for the benefit of some older system services (like sendmail).
>
> One aspect worth considering is that localhost.localdomain as installer default
> means that if hostname is not set by user (in UI or kickstart), transient
> hostname of installed system would be automatically set during network
> configuration (by NM) from dhcp or DNS lookup if available (Formerly anaconda
> used to set the installed sytem static hostname to hostname obtained from dhcp
> or DNS in installation environment but based on a bug report we stopped doing it).
I don't know the details for other dhcp implementations, but systemd-networkd
will use the dchp-provided "transient" hostname if the "static"
hostname is
unset or set to "localhost". Note that this is done dynamically, i.e. the
hostname from dhcp is never stored in /etc/hostname.
Sorry, Radek. I can't parse that. It sounds like you said that
Anaconda does
automatically set the hostname and then you say you stopped doing that because
of a bug report. Which one is true for F25/26?
If those other implementations behave like systemd-networkd, then
Radek's comment makes perfect sense ;)
Zbyszek
1:02 p.m.
On Tue, 08.11.16 16:49, Stephen Gallagher (sgallagh(a)redhat.com) wrote:
For as long as I can recall, Fedora has shipped with a default
hostname of
"localhost.localdomain"[1]. This default was "safe" for a very long
time because
we also shipped an /etc/hosts entry that routed this hostname to the loopback
device for the benefit of some older system services (like sendmail).
However, having the default be the same on all systems introduces other
problems, notably with regards to acting as a client to FreeIPA or Active
Directory domain controllers.
When enrolling with one of these DCs, the machine's current hostname (up to the
first dot) is used to uniquely identify the machine into the domain. If the
machine's hostname is not unique in that domain, the enrollment will either fail
or the machine will take over that name (depending on the server-side
implementation). Neither case is likely to be what the user intended.
Some information on competing platforms:
Windows deals with this on for its systems by assigning all new machines a
random hostname of the form WIN-XXXXXXXXXXX (that's a strict count of 11 random
characters of either capital letters or decimal numerals after the WIN- prefix).
This is because there is a 15-character maximum limit on the machine-name in
Active Directory, after which it is simply truncated (which is a bad behavior,
but one we have to deal with).
Mac OS X and Ubuntu both require the user to pick a machine name at install time
explicitly. They do not autogenerate one at all.
SUSE generates a random name of the format linux-XXXXXX (I'm not sure how many
random characters).
My proposal is that we should consider changing the default hostname for Fedora
26 to be either FED-XXXXXXXXXXX or FEDORA-XXXXXXXX. The former allows for a
longer random string and therefore lower risk of collision in large
environments, while the latter would also provide improved branding for
Fedora[2]. Our default BASH shell prompt includes the current machine's hostname.
Thoughts on how to generate these random strings are of course up for
discussion. Given that initial machine creation may have limited available
entropy, we may want to avoid just calling out to /dev/random. Dusty Mabe
suggested in on IRC that one option might be to use either the first or last
8/11 characters from /etc/machine-id, since presumably those would be
sufficiently random.
Other operating systems, notably security-focussed ones like ChromeOS,
go the other way, and try to remove as many identifiers as possible
that could be used to track users. In fact, at LPC we discussed even
making /etc/machine-id an optional concept in that context, so that
there really would not be any useful local ID that could leak to
external systems.
I must say I sympathise with ChromeOS approach there, I think it would
make sense to default to more secure default in this regard, rather
than opening this all up.
Now, I can see that it is useful for systems that install the IPA
client to behave differently here, and use some better hostname for
them, but I think this should only happen on those systems: I think a
good solution would be continue to use "localhost" as the Fedora
default hostname, but make the IPA enrollment code smart enough, so
that it recognizes that "localhost" is not useful as a public hostname
(it really should know this anyway!), and if it sees that
automatically changes the hostname to something more useful for IPA
clients. (changing the hostname in this case is easy, there's a
friendly bus API for that in hostnamed)
Hence, please keep this specific to IPA clients, don't let this leak
into the Fedora defaults.
(Also, please do not leak /etc/machine-id as it is — or any parts of
it — into identifiers that are passed onto the untrusted networks, in
particular as suffixes of hostnames. Instead, hash it with some
cryptographic, keyed hash function, and use a fixed, application-specific
key. That way the ID will be properly unique, and is derived in a
constant way from the machine ID but there's no way to derive the
original machine ID from the app-specific one. I figure this
recommendation should be added to the man page.)
Lennart
--
Lennart Poettering, Red Hat
2:23 p.m.
On Thu, Nov 10, 2016 at 08:02:20PM +0100, Lennart Poettering wrote:
Other operating systems, notably security-focussed ones like
ChromeOS,
go the other way, and try to remove as many identifiers as possible
that could be used to track users. In fact, at LPC we discussed even
making /etc/machine-id an optional concept in that context, so that
there really would not be any useful local ID that could leak to
external systems.
Saying that ChromeOS "tries to removes as many identifiers as possible
that could be used to track users" is a joke: the whole purpose of that
OS is to track users ;) The only difference is in who does the tracking.
I must say I sympathise with ChromeOS approach there, I think it
would
make sense to default to more secure default in this regard, rather
than opening this all up.
It certainly is good to protect privacy in some environments, but at
the same time, there are various use-cases where being able to easily
identify the machine is crucial for usability: soho networks,
wifi sharing, any kind of setup where you want to share data in an
ad-hoc setting, printing, freeipa, etc. In fact systemd itself follows
this kind of logic: LLDP, LLMNR is enabled on "trusted" networks.
If I'm in a trusted network, where I can identify the machines anyway,
making me jump through hoops like manually checking MAC addresses or
comparing IP numbers to guess which machine is which is pointless.
And disabling the hostname does not really buy much: anyone with
control over the network are likely to be able to identify the machine
using MAC address, the DNS queries it performs, and other access
patterns. If we resolve https://fedoraproject.org/static/hotspot.txt
immediately after connecting, the information that the hostname is
"Fedora-XXXXXXXXX" does not change anything.
I think we should work on not leaking the hostname in untrusted
settings (which effectively means "unless told otherwise"), and not
trying to make the machine completely anonymous.
Zbyszek
6:13 a.m.
For as long as I can recall, Fedora has shipped with a default
hostname of
"localhost.localdomain"[1]. This default was "safe" for a very long
time because
we also shipped an /etc/hosts entry that routed this hostname to the loopback
device for the benefit of some older system services (like sendmail).
However, having the default be the same on all systems introduces other
problems, notably with regards to acting as a client to FreeIPA or Active
Directory domain controllers.
When enrolling with one of these DCs, the machine's current hostname (up to the
first dot) is used to uniquely identify the machine into the domain. If the
machine's hostname is not unique in that domain, the enrollment will either fail
or the machine will take over that name (depending on the server-side
implementation). Neither case is likely to be what the user intended.
Some information on competing platforms:
Windows deals with this on for its systems by assigning all new machines a
random hostname of the form WIN-XXXXXXXXXXX (that's a strict count of 11 random
characters of either capital letters or decimal numerals after the WIN- prefix).
This is because there is a 15-character maximum limit on the machine-name in
Active Directory, after which it is simply truncated (which is a bad behavior,
but one we have to deal with).
Mac OS X and Ubuntu both require the user to pick a machine name at install time
explicitly. They do not autogenerate one at all.
SUSE generates a random name of the format linux-XXXXXX (I'm not sure how many
random characters).
My proposal is that we should consider changing the default hostname for Fedora
26 to be either FED-XXXXXXXXXXX or FEDORA-XXXXXXXX. The former allows for a
longer random string and therefore lower risk of collision in large
environments, while the latter would also provide improved branding for
Fedora[2]. Our default BASH shell prompt includes the current machine's hostname.
Thoughts on how to generate these random strings are of course up for
discussion. Given that initial machine creation may have limited available
entropy, we may want to avoid just calling out to /dev/random. Dusty Mabe
suggested in on IRC that one option might be to use either the first or last
8/11 characters from /etc/machine-id, since presumably those would be
sufficiently random.
[1] Unless there is a DHCP-assigned hostname, in which case it will use that.
[2] There is an ongoing discussion on the desktop@ list about how to subtly
brand the Workstation Edition such that when people are using it or showing it
to others, it is clear that it is *Fedora* as opposed to any other GNOME
distribution.
I like Fedora-XXXXXXXX for default hostname. If I don't care to set a hostname it
would be an ok hostname for my machine. I would however like if the hostname setting would
be more prominent in the installer. Possibly generating based on my name along the lines
of: fredriks-laptop.rambris.lan
8:50 a.m.
On Fri, Nov 11, 2016 at 12:13:48PM -0000, fredrik(a)rambris.com wrote:
I like Fedora-XXXXXXXX for default hostname. If I don't care to
set a hostname it would be an ok hostname for my machine. I would however like if the
hostname setting would be more prominent in the installer. Possibly generating based on my
name along the lines of: fredriks-laptop.rambris.lan
Those are two separate issues really:
Making the choice it more prominent is probably not necessary, if we
provide a nice default. Although it probably wouldn't hurt. The hostname
could be displayed in the summary or maybe the user creation dialogue
('Create user "user1@Fedora-123345"'?).
Generating the name from the user name matches what Windows does, but
it seems like a bigger privacy leak that the randomly generated
"Fedora" name. It'd probably be less unique globally, while being more
personally identifiable in small environments. This means that it
wouldn't solve the freeipa case. So "Fedora-XXXXXX" sounds like a better
tradeoff.
Zbyszek
1:01 p.m.
On 11/11/16 15:50, Zbigniew Jędrzejewski-Szmek wrote:
On Fri, Nov 11, 2016 at 12:13:48PM -0000, fredrik(a)rambris.com wrote:
> I like Fedora-XXXXXXXX for default hostname. If I don't care to set a hostname it
would be an ok hostname for my machine. I would however like if the hostname setting would
be more prominent in the installer. Possibly generating based on my name along the lines
of: fredriks-laptop.rambris.lan
Those are two separate issues really:
Making the choice it more prominent is probably not necessary, if we
provide a nice default. Although it probably wouldn't hurt. The hostname
could be displayed in the summary or maybe the user creation dialogue
('Create user "user1@Fedora-123345"'?).
Generating the name from the user name matches what Windows does, but
it seems like a bigger privacy leak that the randomly generated
"Fedora" name. It'd probably be less unique globally, while being more
personally identifiable in small environments. This means that it
wouldn't solve the freeipa case. So "Fedora-XXXXXX" sounds like a better
tradeoff.
Zbyszek
_______________________________________________
devel mailing list -- devel(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
To me, the default hostname should be fedora-xx. There are thousands if
not millions of computers using Fedora so it's quite anonymous.
I don't think copying Windows behaviour is a good idea, they aren't
known for their security....
Cheers,
Sylvia
7:05 a.m.
On 11/13/2016 02:01 PM, Ms Sanchez wrote:
To me, the default hostname should be fedora-xx. There are thousands
if not
millions of computers using Fedora so it's quite anonymous.
I don't think copying Windows behaviour is a good idea, they aren't known for
their security....
Well, in order for our default to be able to function within an Active Directory
environment, we do need to stick with the 15-character limit at least.
12:22 p.m.
On 14/11/16 14:05, Stephen Gallagher wrote:
On 11/13/2016 02:01 PM, Ms Sanchez wrote:
> To me, the default hostname should be fedora-xx. There are thousands if not
> millions of computers using Fedora so it's quite anonymous.
> I don't think copying Windows behaviour is a good idea, they aren't known
for
> their security....
>
Well, in order for our default to be able to function within an Active Directory
environment, we do need to stick with the 15-character limit at least.
Yes, the length. But I was talking about the way they create a hostname.
9:31 a.m.
Thoughts on how to generate these random strings are of course up
for
discussion. Given that initial machine creation may have limited available
I am fighting against human unreadable names in hostnames (specifically in datacenters)
and I created a little tool [1] that generates human readable and memorizable names made
out of frequently occurring given names and surnames from the 1990 US Census (public
domain data - confirmed with Fedora legal). This gives about 33 million unique total
names. Examples:
velma-pratico.my.lan
angie-warmbrod.my.lan
grant-goodgine.my.lan
alton-sieber.my.lan
velma-vanbeek.my.lan
don-otero.my.lan
sam-hulan.my.lan
We could consider similar approach for default hostnames. I can imagine the US names can
be confusing, we can swap these with colors or other words to make it little bit less
confusing (e.g. "blue-star"). This is definitely nicer than
"Fedora-c4feb4b3", I don't like sharing same prefixes, this makes tab
expansion unusable, it usually needs wider columns in lists etc. Distribution name is, I
think, not relevant when it comes to naming computers. It is just a name,
"yellow-dog" isn't that bad, is it?
Another thing that should be take into account is not doing this randomly, but seeding the
algorithm based on hardware specifics (MAC, serial number), so when system is
reprovisioned, it gets the very same hostname. This approach can be combined with the
above one if needed, giving:
- human readable names
- memorizable names
- consistent names after reinstallation
[1] https://github.com/lzap/deacon
This is a rubygem, but this kind of thing is trivial (and fun) to write, I can give a hand
implementing this in Python in order to allow Anaconda to do this if folks like my idea.
2:42 p.m.
I am fighting against human unreadable names in hostnames
(specifically in datacenters)
Hurrah!
and I created a little tool [1] that generates human readable and
memorizable names made
out of frequently occurring given names and surnames from the 1990 US Census
I like this idea, but I wonder if the potential for confusion or even offence is too high
for it to be workable. I'm thinking of
https://en.wikipedia.org/wiki/Sudanese_teddy_bear_blasphemy_case.
I can imagine the US names can be confusing,
Indeed, I find them confusing as a speaker of UK English. This /could/ be localised with
UK data, but I don't think we'd want to start down that road.
we can swap these with colors or other words to make it little bit
less confusing (e.g. "blue-star").
See https://pypi.python.org/pypi/petname and
https://www.npmjs.com/package/human-readable-ids, which both use animals.
--
Peter Oliver
4:18 p.m.
On 11/15/2016 03:42 PM, Peter Oliver wrote:
I like this idea, but I wonder if the potential for confusion or even
offence is too high for it to be workable. I'm thinking
ofhttps://en.wikipedia.org/wiki/Sudanese_teddy_bear_blasphemy_case.
> >we can swap these with colors or other words to make it little bit less confusing
(e.g. "blue-star").
Seehttps://pypi.python.org/pypi/petname
andhttps://www.npmjs.com/package/human-readable-ids, which both use animals.
As an alternative, I wrote a program that takes the distribution of
trigrams from an English dictionary, and statistically generates a
Markov chain of such overlapping trigrams that look almost entirely
unlike English words but often are strangely pronounceable, for instance:
umirckbysag mpspiarefor doptinenchc lymdeotmicn gclyowdhoki
gavotlilmod hamdipicpto sriagflyori nstsdumotdo biclachiesf
dsalcleccod lreamyryazi tbrtnmchnbl gsciffsucec lveadjeortd
itiasglucpa nctyrsifesk asbeazeimst rvalvallwsh gbrcarpirgo
ootsjamakid ybawffobrcr wsbiopradsn pouidbrmcif nytblplabio
bytramojetw hdenleraloa crymolduanu nutoloymctr ofanjewsstm
We've been using them for labels and such, and of course in principle
this method should occasionally generate actual existing words,
including NSFW words in English and possibly in other languages, but it
turns out that the probability is very small, for what it's worth.
4:58 p.m.
On Tue, 2016-11-15 at 17:18 -0500, Przemek Klosowski wrote:
On 11/15/2016 03:42 PM, Peter Oliver wrote:
> I like this idea, but I wonder if the potential for confusion or even offence is too
high for it to be workable. I'm thinking
ofhttps://en.wikipedia.org/wiki/Sudanese_teddy_bear_blasphemy_case.
>
> > > we can swap these with colors or other words to make it little bit less
confusing (e.g. "blue-star").
>
> Seehttps://pypi.python.org/pypi/petname
andhttps://www.npmjs.com/package/human-readable-ids, which both use animals.
As an alternative, I wrote a program that takes the distribution of
trigrams from an English dictionary, and statistically generates a
Markov chain of such overlapping trigrams that look almost entirely
unlike English words but often are strangely pronounceable, for instance:
umirckbysag mpspiarefor doptinenchc lymdeotmicn gclyowdhoki
I, er, don't find any of those naturally pronounceable at all.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
11:30 a.m.
On 11/15/2016 05:58 PM, Adam Williamson wrote:
On Tue, 2016-11-15 at 17:18 -0500, Przemek Klosowski wrote:
>
> As an alternative, I wrote a program that takes the distribution of
> trigrams from an English dictionary, and statistically generates a
> Markov chain of such overlapping trigrams that look almost entirely
> unlike English words but often are strangely pronounceable, for instance:
>
> umirckbysag mpspiarefor doptinenchc lymdeotmicn gclyowdhoki
I, er, don't find any of those naturally pronounceable at all.
Well, I see your point, but we're competing here with qljkvwqrx,
lkdsfhkrw, or ad5cb9c940. Remember that the point is to come up with
something that could be easily remembered. I would argue that they're
not much worse than
Acthrel Iprivask Strensiq Eltrombopag Ondansetron VinCRIStine Arixtra
Arzerra Ertaczo
which are actually from a list of registered drug names that the doctors
are supposed to remember. Maybe someone could come up with a suggestion
for a better algo---adding just few vowels would fix them up
significantly:
umirckobysag mopsopiarefor doptinenchoc lymdeotemicyn goclywodhoki
BTW, when I looked at the list of drug names I was impressed with the
linguistic inventiveness of whoever comes up with this stuff; most of
them not only could plausibly be pronounced, but also sounded vaguely
'medical'.
12:22 p.m.
On 16/11/16 18:30, Przemek Klosowski wrote:
On 11/15/2016 05:58 PM, Adam Williamson wrote:
> On Tue, 2016-11-15 at 17:18 -0500, Przemek Klosowski wrote:
>>
>> As an alternative, I wrote a program that takes the distribution of
>> trigrams from an English dictionary, and statistically generates a
>> Markov chain of such overlapping trigrams that look almost entirely
>> unlike English words but often are strangely pronounceable, for instance:
>>
>> umirckbysag mpspiarefor doptinenchc lymdeotmicn gclyowdhoki
> I, er, don't find any of those naturally pronounceable at all.
Well, I see your point, but we're competing here with qljkvwqrx,
lkdsfhkrw, or ad5cb9c940. Remember that the point is to come up with
something that could be easily remembered. I would argue that they're
not much worse than
Acthrel Iprivask Strensiq Eltrombopag Ondansetron VinCRIStine Arixtra
Arzerra Ertaczo
which are actually from a list of registered drug names that the
doctors are supposed to remember. Maybe someone could come up with a
suggestion for a better algo---adding just few vowels would fix them
up significantly:
umirckobysag mopsopiarefor doptinenchoc lymdeotemicyn goclywodhoki
BTW, when I looked at the list of drug names I was impressed with the
linguistic inventiveness of whoever comes up with this stuff; most of
them not only could plausibly be pronounced, but also sounded vaguely
'medical'.
Well, I guess they're very well paid for making up those names. But
trust me, doctors don't remember most of them anyway. LOL
Anyway... why overcomplicating this? Just Fedora-something and that's
it. If someone doesn't like it, he or she just can change it
afterwards, it won't carved on stone.
Cheers, Sylvia
2717
days inactive
2725
days old
64 comments
28 participants
participants (28)
-
Adam Williamson -
Andrew Lutomirski -
fredrik＠rambris.com -
Glen Turner -
Japheth Cleaver -
Kevin Kofler -
Lailah -
Lennart Poettering -
Louis Lagendijk -
Lukas Zapletal -
Matthew Miller -
Neal Gompa -
Nico Kadel-Garcia -
Owen Taylor -
Peter Oliver -
Przemek Klosowski -
Radek Vykydal -
Richard W.M. Jones -
Roberto Ragusa -
Scott Schmit -
Simo Sorce -
stan -
Stephen Gallagher -
Stephen John Smoogen -
Theodore Papadopoulo -
Tomasz Torcz -
Vít Ondruch -
Zbigniew Jędrzejewski-Szmek