We've had a few discussions about this issue over the years and never really decided on anything more certain than "er, well..."
There's certainly a bigger discussion around moving to the 'new networking' setting but for this one particular query it seems to me that using the code currently in NetNameResolver class>>#localHostName that gets ignored by the #useOldNetwork option is a good option. That is,
localHostName "Return the local name of this host." "NetNameResolver localHostName"
| host | host := String new: NetNameResolver primHostNameSize. NetNameResolver primHostNameResult: host. ^host
returns a value that seems to be helpful, and that is retrieved via the unix function gethostname(), which is used by the hostname command. Are there any problems with the idea of using this?
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Useful random insult:- Mouth in gear, brain in neutral.
Hi,
I cannot contribute to the concrete question, but note that a host can have multiple addresses and can therefore be reachable under multiple host names. Depending on what you try to do, it may matter and you better check that you actually get the name that you expect in your production environment.
Kind regards, Jakob
tim Rowledge tim@rowledge.org schrieb am Do., 30. März 2023, 03:14:
We've had a few discussions about this issue over the years and never really decided on anything more certain than "er, well..."
There's certainly a bigger discussion around moving to the 'new networking' setting but for this one particular query it seems to me that using the code currently in NetNameResolver class>>#localHostName that gets ignored by the #useOldNetwork option is a good option. That is,
localHostName "Return the local name of this host." "NetNameResolver localHostName"
| host | host := String new: NetNameResolver primHostNameSize. NetNameResolver primHostNameResult: host. ^hostreturns a value that seems to be helpful, and that is retrieved via the unix function gethostname(), which is used by the hostname command. Are there any problems with the idea of using this?
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Useful random insult:- Mouth in gear, brain in neutral.
On 2023-03-29, at 11:32 PM, Jakob Reschke jakres+squeak@gmail.com wrote:
Hi,
I cannot contribute to the concrete question, but note that a host can have multiple addresses and can therefore be reachable under multiple host names. Depending on what you try to do, it may matter and you better check that you actually get the name that you expect in your production environment.
Yup, we've managed to make it very complicated. I'm sure OS people had excellent reasons but, boy, I wish somebody had seen a way to make it simpler. Anyway, my hypothesis is that using the hostname command means that we (Squeak) do do at least as well as we (commandline) can sensibly manage. If it is really the case that the question isn't properly answerable then we ought to remove the related methods etc so as to remove a point of confusion and error.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: START: Cancel preceding jobs in queue
Oh it is worse than that.
A system really doesn't have a canonical host name per se. It can have:
1. One IP address and no host names
2. One IP address and one host name
3. One IP address and multiple host names
4. Multiple IP addresses and one host name (different disconnected networks, say IPv6/IPv4 or 1G/10G/40G)
5. Multiple IP addresses and multiple host names (but not necessarily a one to one mapping)
and of course one hostname can map to multiple IP addresses on different independent machines.
The idea is that a hostname resolves to an address and that address lets you reach an interface on a machine.
The result of the hostname command does not even have to map in such a way that from outside the machine that hostname will allow you reach that machine.
cheers
bruce
On 2023-03-30T18:53:50.000+02:00, tim Rowledge tim@rowledge.org wrote:
On 2023-03-29, at 11:32 PM, Jakob Reschke jakres+squeak@gmail.com wrote: Hi, I cannot contribute to the concrete question, but note that a host can have multiple addresses and can therefore be reachable under multiple host names. Depending on what you try to do, it may matter and you better check that you actually get the name that you expect in your production environment.
Yup, we've managed to make it very complicated. I'm sure OS people had excellent reasons but, boy, I wish somebody had seen a way to make it simpler. Anyway, my hypothesis is that using the hostname command means that we (Squeak) do do at least as well as we (commandline) can sensibly manage. If it is really the case that the question isn't properly answerable then we ought to remove the related methods etc so as to remove a point of confusion and error. tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: START: Cancel preceding jobs in queue
While all of that is true, there is a difference between a routable name (which obviously is interface-specific) and the standard host name for the current machine, which is for humans, not for other machines. That's what the primHostName is supposed to answer. It should be equivalent to running `hostname -s` on a unix command line. It is useful, as long as users are aware of what it actually refers to.
Now the actual implementation of primHostName across VMs is not unified because (I believe) the intention of that primitive was not well-documented. On my machine (macOS VM) it answers the IPv4 address of the first external interface, apparently, which is not what I think it should answer.
Vanessa
On Thu, Mar 30, 2023 at 10:33 AM Bruce O'Neel bruce.oneel@pckswarms.ch wrote:
Oh it is worse than that.
A system really doesn't have a canonical host name per se. It can have:
- One IP address and no host names
- One IP address and one host name
- One IP address and multiple host names
- Multiple IP addresses and one host name (different disconnected
networks, say IPv6/IPv4 or 1G/10G/40G) 5. Multiple IP addresses and multiple host names (but not necessarily a one to one mapping)
and of course one hostname can map to multiple IP addresses on different independent machines.
The idea is that a hostname resolves to an address and that address lets you reach an interface on a machine.
The result of the hostname command does not even have to map in such a way that from outside the machine that hostname will allow you reach that machine.
cheers
bruce
On 2023-03-30T18:53:50.000+02:00, tim Rowledge tim@rowledge.org wrote:
On 2023-03-29, at 11:32 PM, Jakob Reschke jakres+squeak@gmail.com wrote:
Hi,
I cannot contribute to the concrete question, but note that a host can have multiple addresses and can therefore be reachable under multiple host names. Depending on what you try to do, it may matter and you better check that you actually get the name that you expect in your production environment.
Yup, we've managed to make it very complicated. I'm sure OS people had excellent reasons but, boy, I wish somebody had seen a way to make it simpler. Anyway, my hypothesis is that using the hostname command means that we (Squeak) do do at least as well as we (commandline) can sensibly manage. If it is really the case that the question isn't properly answerable then we ought to remove the related methods etc so as to remove a point of confusion and error.
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: START: Cancel preceding jobs in queue
Oh my bad, this was exactly what Tim was getting at.
primHostName does answer my machine name correctly, albeit with domain (as in `hostname`, not `hostname -s`).
It's only because useOldNetwork is true in my image that instead it answers the interface address.
So to Tim's point, yes, I'd think exposing that primitive again makes sense, with a sensible method name.
Vanessa
On Thu, Mar 30, 2023 at 11:29 AM Vanessa Freudenberg vanessa@codefrau.net wrote:
While all of that is true, there is a difference between a routable name (which obviously is interface-specific) and the standard host name for the current machine, which is for humans, not for other machines. That's what the primHostName is supposed to answer. It should be equivalent to running `hostname -s` on a unix command line. It is useful, as long as users are aware of what it actually refers to.
Now the actual implementation of primHostName across VMs is not unified because (I believe) the intention of that primitive was not well-documented. On my machine (macOS VM) it answers the IPv4 address of the first external interface, apparently, which is not what I think it should answer.
Vanessa
On Thu, Mar 30, 2023 at 10:33 AM Bruce O'Neel bruce.oneel@pckswarms.ch wrote:
Oh it is worse than that.
A system really doesn't have a canonical host name per se. It can have:
- One IP address and no host names
- One IP address and one host name
- One IP address and multiple host names
- Multiple IP addresses and one host name (different disconnected
networks, say IPv6/IPv4 or 1G/10G/40G) 5. Multiple IP addresses and multiple host names (but not necessarily a one to one mapping)
and of course one hostname can map to multiple IP addresses on different independent machines.
The idea is that a hostname resolves to an address and that address lets you reach an interface on a machine.
The result of the hostname command does not even have to map in such a way that from outside the machine that hostname will allow you reach that machine.
cheers
bruce
On 2023-03-30T18:53:50.000+02:00, tim Rowledge tim@rowledge.org wrote:
On 2023-03-29, at 11:32 PM, Jakob Reschke jakres+squeak@gmail.com wrote:
Hi,
I cannot contribute to the concrete question, but note that a host can have multiple addresses and can therefore be reachable under multiple host names. Depending on what you try to do, it may matter and you better check that you actually get the name that you expect in your production environment.
Yup, we've managed to make it very complicated. I'm sure OS people had excellent reasons but, boy, I wish somebody had seen a way to make it simpler. Anyway, my hypothesis is that using the hostname command means that we (Squeak) do do at least as well as we (commandline) can sensibly manage. If it is really the case that the question isn't properly answerable then we ought to remove the related methods etc so as to remove a point of confusion and error.
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: START: Cancel preceding jobs in queue
... maybe we should finally start using the "new" network code that is more than a dozen years old by now.,
Vanessa
On Thu, Mar 30, 2023 at 11:38 AM Vanessa Freudenberg vanessa@codefrau.net wrote:
Oh my bad, this was exactly what Tim was getting at.
primHostName does answer my machine name correctly, albeit with domain (as in `hostname`, not `hostname -s`).
It's only because useOldNetwork is true in my image that instead it answers the interface address.
So to Tim's point, yes, I'd think exposing that primitive again makes sense, with a sensible method name.
Vanessa
On Thu, Mar 30, 2023 at 11:29 AM Vanessa Freudenberg vanessa@codefrau.net wrote:
While all of that is true, there is a difference between a routable name (which obviously is interface-specific) and the standard host name for the current machine, which is for humans, not for other machines. That's what the primHostName is supposed to answer. It should be equivalent to running `hostname -s` on a unix command line. It is useful, as long as users are aware of what it actually refers to.
Now the actual implementation of primHostName across VMs is not unified because (I believe) the intention of that primitive was not well-documented. On my machine (macOS VM) it answers the IPv4 address of the first external interface, apparently, which is not what I think it should answer.
Vanessa
On Thu, Mar 30, 2023 at 10:33 AM Bruce O'Neel bruce.oneel@pckswarms.ch wrote:
Oh it is worse than that.
A system really doesn't have a canonical host name per se. It can have:
- One IP address and no host names
- One IP address and one host name
- One IP address and multiple host names
- Multiple IP addresses and one host name (different disconnected
networks, say IPv6/IPv4 or 1G/10G/40G) 5. Multiple IP addresses and multiple host names (but not necessarily a one to one mapping)
and of course one hostname can map to multiple IP addresses on different independent machines.
The idea is that a hostname resolves to an address and that address lets you reach an interface on a machine.
The result of the hostname command does not even have to map in such a way that from outside the machine that hostname will allow you reach that machine.
cheers
bruce
On 2023-03-30T18:53:50.000+02:00, tim Rowledge tim@rowledge.org wrote:
On 2023-03-29, at 11:32 PM, Jakob Reschke jakres+squeak@gmail.com wrote:
Hi,
I cannot contribute to the concrete question, but note that a host can have multiple addresses and can therefore be reachable under multiple host names. Depending on what you try to do, it may matter and you better check that you actually get the name that you expect in your production environment.
Yup, we've managed to make it very complicated. I'm sure OS people had excellent reasons but, boy, I wish somebody had seen a way to make it simpler. Anyway, my hypothesis is that using the hostname command means that we (Squeak) do do at least as well as we (commandline) can sensibly manage. If it is really the case that the question isn't properly answerable then we ought to remove the related methods etc so as to remove a point of confusion and error.
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: START: Cancel preceding jobs in queue
On Thu, Mar 30, 2023 at 11:30 AM Vanessa Freudenberg vanessa@codefrau.net wrote:
While all of that is true, there is a difference between a routable name (which obviously is interface-specific) and the standard host name for the current machine, which is for humans, not for other machines. That's what the primHostName is supposed to answer. It should be equivalent to running `hostname -s` on a unix command line. It is useful, as long as users are aware of what it actually refers to.
Now the actual implementation of primHostName across VMs is not unified because (I believe) the intention of that primitive was not well-documented. On my machine (macOS VM) it answers the IPv4 address of the first external interface, apparently, which is not what I think it should answer.
Then we should fix it, and document the intent of the primitive :-) Your definition makes sense to me.
Vanessa
On Thu, Mar 30, 2023 at 10:33 AM Bruce O'Neel bruce.oneel@pckswarms.ch wrote:
Oh it is worse than that.
A system really doesn't have a canonical host name per se. It can have:
- One IP address and no host names
- One IP address and one host name
- One IP address and multiple host names
- Multiple IP addresses and one host name (different disconnected
networks, say IPv6/IPv4 or 1G/10G/40G) 5. Multiple IP addresses and multiple host names (but not necessarily a one to one mapping)
and of course one hostname can map to multiple IP addresses on different independent machines.
The idea is that a hostname resolves to an address and that address lets you reach an interface on a machine.
The result of the hostname command does not even have to map in such a way that from outside the machine that hostname will allow you reach that machine.
cheers
bruce
On 2023-03-30T18:53:50.000+02:00, tim Rowledge tim@rowledge.org wrote:
On 2023-03-29, at 11:32 PM, Jakob Reschke jakres+squeak@gmail.com wrote:
Hi,
I cannot contribute to the concrete question, but note that a host can have multiple addresses and can therefore be reachable under multiple host names. Depending on what you try to do, it may matter and you better check that you actually get the name that you expect in your production environment.
Yup, we've managed to make it very complicated. I'm sure OS people had excellent reasons but, boy, I wish somebody had seen a way to make it simpler. Anyway, my hypothesis is that using the hostname command means that we (Squeak) do do at least as well as we (commandline) can sensibly manage. If it is really the case that the question isn't properly answerable then we ought to remove the related methods etc so as to remove a point of confusion and error.
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: START: Cancel preceding jobs in queue
On Thu, Mar 30, 2023 at 2:19 PM Eliot Miranda eliot.miranda@gmail.com wrote:
On Thu, Mar 30, 2023 at 11:30 AM Vanessa Freudenberg vanessa@codefrau.net wrote:
While all of that is true, there is a difference between a routable name (which obviously is interface-specific) and the standard host name for the current machine, which is for humans, not for other machines. That's what the primHostName is supposed to answer. It should be equivalent to running `hostname -s` on a unix command line. It is useful, as long as users are aware of what it actually refers to.
Now the actual implementation of primHostName across VMs is not unified because (I believe) the intention of that primitive was not well-documented. On my machine (macOS VM) it answers the IPv4 address of the first external interface, apparently, which is not what I think it should answer.
Then we should fix it, and document the intent of the primitive :-) Your definition makes sense to me.
I got confused, the primitive actually does what it's supposed to (on macOS at least). We're just not using it by default, that was Tim's observation.
Vanessa
On 2023-03-30, at 3:10 PM, Vanessa Freudenberg vanessa@codefrau.net wrote:
I got confused, the primitive actually does what it's supposed to (on macOS at least). We're just not using it by default, that was Tim's observation.
Exactly.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim I'm so skeptical that I'm not sure I'm really a skeptic
On Wed, Mar 29, 2023 at 06:13:55PM -0700, tim Rowledge wrote:
We've had a few discussions about this issue over the years and never really decided on anything more certain than "er, well..."
There's certainly a bigger discussion around moving to the 'new networking' setting but for this one particular query it seems to me that using the code currently in NetNameResolver class>>#localHostName that gets ignored by the #useOldNetwork option is a good option. That is,
localHostName "Return the local name of this host." "NetNameResolver localHostName"
| host | host := String new: NetNameResolver primHostNameSize. NetNameResolver primHostNameResult: host. ^host
returns a value that seems to be helpful, and that is retrieved via the unix function gethostname(), which is used by the hostname command. Are there any problems with the idea of using this?
Could someone please test this on Windows and Mac? To test it, use Tim's change above, then find the 'Enable IPv6 and new network support' preference in category 'General' in the preference browser.
Turn the preference on and off, and see if the localHostName method answers something sensible in both cases.
It looks right to me on Linux but results may be different on other platforms.
Thanks, Dave
Hi,
For me it does something sensbile on MacOS 10.15.7 and on Windows. Both with Squeak 6.0.
cheers
bruce
On 2023-03-31T04:06:12.000+02:00, David T. Lewis lewis@mail.msen.com wrote:
On Wed, Mar 29, 2023 at 06:13:55PM -0700, tim Rowledge wrote:
We've had a few discussions about this issue over the years and never really decided on anything more certain than "er, well..." There's certainly a bigger discussion around moving to the 'new networking' setting but for this one particular query it seems to me that using the code currently in NetNameResolver class>>#localHostName that gets ignored by the #useOldNetwork option is a good option. That is, localHostName "Return the local name of this host." "NetNameResolver localHostName" | host | host := String new: NetNameResolver primHostNameSize. NetNameResolver primHostNameResult: host. ^host returns a value that seems to be helpful, and that is retrieved via the unix function gethostname(), which is used by the hostname command. Are there any problems with the idea of using this?
Could someone please test this on Windows and Mac? To test it, use Tim's change above, then find the 'Enable IPv6 and new network support' preference in category 'General' in the preference browser. Turn the preference on and off, and see if the localHostName method answers something sensible in both cases. It looks right to me on Linux but results may be different on other platforms. Thanks, Dave
Tim,
I think you should go ahead and commit the change to trunk.
Dave
On Fri, Mar 31, 2023 at 09:25:46AM +0200, Bruce O'Neel wrote:
Hi,
For me it does something sensbile on MacOS 10.15.7 and on Windows. Both with Squeak 6.0.
cheers
bruce
On 2023-03-31T04:06:12.000+02:00, David T. Lewis lewis@mail.msen.com wrote:
On Wed, Mar 29, 2023 at 06:13:55PM -0700, tim Rowledge wrote:
We've had a few discussions about this issue over the years and never really decided on anything more certain than "er, well..."
There's certainly a bigger discussion around moving to the 'new networking' setting but for this one particular query it seems to me that using the code currently in NetNameResolver class>>#localHostName that gets ignored by the #useOldNetwork option is a good option. That is,
localHostName "Return the local name of this host." "NetNameResolver localHostName"
| host | host := String new: NetNameResolver primHostNameSize. NetNameResolver primHostNameResult: host. ^host
returns a value that seems to be helpful, and that is retrieved via the unix function gethostname(), which is used by the hostname command. Are there any problems with the idea of using this?
Could someone please test this on Windows and Mac ?To test it, use Tim's change above, then find the 'Enable IPv6 and new network support' preference in category 'General' in the preference browser.
Turn the preference on and off, and see if the localHostName method answers something sensible in both cases.
It looks right to me on Linux but results may be different on other platforms.
Thanks, Dave
squeak-dev@lists.squeakfoundation.org
-
Bruce O'Neel -
David T. Lewis -
Eliot Miranda -
Jakob Reschke -
tim Rowledge -
Vanessa Freudenberg