openssh unix dev - Feb 2021 - [openssh-commits] [openssh] 02/02: upstream: hostname is not specified by POSIX but uname -n is, so use

Tim Rice wrote:
> > -HOST=`hostname | cut -f1 -d.`
> > -HOSTNAME=`hostname`
> > +HOST=`uname -n | cut -f1 -d.`
> > +HOSTNAME=`uname -n`
> 
> This may not work as intended.
> ....
> tim at server01-UnixWare 69% hostname
> server01.int.multitalents.net
> tim at server01-UnixWare 70% uname -n
> server01
> ....
I'll just note that on Debian, Ubuntu, other derivatives (such as
Mint, Trisquel...) both the "uname -n" and "hostname" values
would
typically be just the short name.  It's not just UnixWare...

    rwp at havoc:~$ uname -n
    havoc

    rwp at havoc:~$ hostname
    havoc

Getting a FQDN is truly not trivial. :-(

Bob

On Mon, 8 Feb 2021 at 09:53, Bob Proulx <bob at proulx.com> wrote:
[...]
> I'll just note that on Debian, Ubuntu, other derivatives (such as
> Mint, Trisquel...) both the "uname -n" and "hostname"
values would
> typically be just the short name.  It's not just UnixWare...
Double sigh.

Fortunately for this purpose it only matters that the output from
hostname(1) matches the return from gethostname(2), which in this case
it does. so the test still passes on those platforms:

$ cat /etc/lsb-release
[...]
DISTRIB_DESCRIPTION="Ubuntu 20.04.2 LTS"
$ ./ssh -o controlpath='%L' -G ::1 | grep controlpath
controlpath server01
$ ./ssh -o controlpath='%l' -G ::1 | grep controlpath
controlpath server01
$ make t-exec LTESTS=percent TEST_SSH_UNSAFE_PERMISSIONS=1
[...]
ok percent expansions
make[1]: Leaving directory '/home/dtucker/openssh/regress'
all t-exec passed
--
Darren Tucker (dtucker at dtucker.net)
GPG key 11EAA6FA / A86E 3E07 5B19 5880 E860  37F4 9357 ECEF 11EA A6FA (new)
    Good judgement comes with experience. Unfortunately, the experience
usually comes from bad judgement.

On Sun, 7 Feb 2021, Bob Proulx wrote:
> I'll just note that on Debian, Ubuntu, other derivatives (such as
> Mint, Trisquel...) both the "uname -n" and "hostname"
values would
> typically be just the short name.  It's not just UnixWare...
Which I *still* consider a bug, and I set all my systems to use the
FQDN as hostname, so please make sure to test with both ;)

Thanks,
//mirabilos
-- 
tarent solutions GmbH
Rochusstra?e 2-4, D-53123 Bonn ? http://www.tarent.de/
Tel: +49 228 54881-393 ? Fax: +49 228 54881-235
HRB 5168 (AG Bonn) ? USt-ID (VAT): DE122264941
Gesch?ftsf?hrer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg

*************************************************

Mit unserem Consulting bieten wir Unternehmen ma?geschneiderte Angebote in
Form von Beratung, Trainings sowie Workshops in den Bereichen
Softwaretechnologie, IT Strategie und Architektur, Innovation und Umsetzung
sowie Agile Organisation.

Besuchen Sie uns auf https://www.tarent.de/consulting .
Wir freuen uns auf Ihren Kontakt.

*************************************************

On Sun, 7 Feb 2021, Bob Proulx wrote:
>     rwp at havoc:~$ hostname
>     havoc
> 
> Getting a FQDN is truly not trivial. :-(
True, and some hostname (ubuntu, centos, etc) implimentations have
"hostname -f" for the FQDN.

-- 
Tim Rice				Multitalents	
tim at multitalents.net

On Sun, Feb 07, 2021 at 03:43:24PM -0700, Bob Proulx
wrote:
> Tim Rice wrote:
> > > -HOST=`hostname | cut -f1 -d.`
> > > -HOSTNAME=`hostname`
> > > +HOST=`uname -n | cut -f1 -d.`
> > > +HOSTNAME=`uname -n`
> > 
> > This may not work as intended.
> > ....
> > tim at server01-UnixWare 69% hostname
> > server01.int.multitalents.net
> > tim at server01-UnixWare 70% uname -n
> > server01
> > ....
> 
> I'll just note that on Debian, Ubuntu, other derivatives (such as
> Mint, Trisquel...) both the "uname -n" and "hostname"
values would
> typically be just the short name.  It's not just UnixWare...
> 
>     rwp at havoc:~$ uname -n
>     havoc
> 
>     rwp at havoc:~$ hostname
>     havoc
> 
Isn't it just 'hostname -f'?

    chris$ hostname -f
    t470.zbmc.eu
    chris$ hostname
    t470


-- 
Chris Green