Bug 31413

Thanks for this bug! It has made me harden the xchroot program: https://www.elstel.org/ViewRSS.php?guid=7470&lang=en#7470

I have looked at the /etc/hostname in Debian Bullseye and since it defaults to sys76darp rather than localhost this may be the location where the wrong xauth token comes from.

Have noted M9 SRPM, rather than M8. Doubt that the problem has changed.

(In reply to Elmar Stellnberger from comment #1)
> Thanks for this bug! It has made me harden the xchroot program:
I can find no reference to xchroot in our repos.

BTAIM Assigning this globally. The Debian comparison makes this worth investigating.

Source RPM: (none) => xauth-1.1.2-1.mga9.src.rpm
Assignee: bugsquad => pkg-bugs

I once wanted to package xchroot for Mageia: Bug 25887. Packages can be found here, though: https://www.elstel.org/software/external-repositories.html.en

$ hostnamectl
   Static hostname: x3.hodgins.homeip.net
         Icon name: computer-desktop
           Chassis: desktop
        Machine ID: 924899bd8f7d45e5835e73a67b2f2aed
           Boot ID: 01d7129686a24a2b83a2732cf36aba20
  Operating System: Mageia 8
            Kernel: Linux 5.15.88-server-1.mga8
      Architecture: x86-64

The transient hostname is not guaranteed to exist.

We've had problems with xauth in the past that seem to have been resolved.
Unless there is very good reason, with backing from xorg upstream such a
change is very risky.

CC: (none) => davidwhodgins

My question would be how the hostname can be set under Mageia (with mcc?) as well as at install time. I haven't tried yet to write /etc/hostname and whether that would resolve the issue. Localhost doesn't seem to be a good candidate for the static hostname and yet it is localhost on both Mageia installations I have.

Mageia sets the basic static hostname to localhost (as each system administrator has other needs for his network). It is the task of a system administrator to set a proper static host name for his machines in his network dependend on his needs. If the administrator failed to set a static hostname and there are several machines with "localhost" in a network, the transient hostname get set by a kernel service to identify the machines (until next reboot, as transient hostnames don't survive a reboot).

Mageia offers different ways to set a hostname. The commonly used way for all linux distributions is to use the command
"hostnamectl set-hostname new-hostname"
In case you need more informations about hostnamectl, see man-pages.

There is also a graphical way via MCC. If you setup a new connection you can specify the hostname. This is also described in the official Mageia MCC documentation.
https://doc.mageia.org/mcc/8/en/content/mcc-network.html#d4e1613

  No, the transient hostname didn´t get set on boot automatically. Sys76 stands for the producer of my notebook which is System 76 and Darp stands for Darter Pro the notebook model I have, thus hostname shall be sys76darp as under Debian Bullseye. If I set the environment variable HOSTNAME then it only tells about a static hostname, namely sys76darp. Very likely I have entered this hostname on install time. Finally I am sure not to have changed it afterwards. As said, I have written the /etc/hostname file and will see whether the environment variable gets fetched from there on the next reboot.

A properly configured system has no (visible) transient hostname. Only a static one. This can be seen in Dave's output. That is also the reason why xauth reffers to the static hostname.
If you have set a static hostname, the transient one is the same but it won't show up in the "$ hostnamectl" command. 

The reason why transient hostnames exist is:
- you can change the transient hostname whilst the system is running and it wont survive a reboot. This is good for testing purposes in a network
- If the administrator failed to properly configure his network and several machines with the static hostname "localhost" exists, the kernel service (or DHCP/mDNS servers) gives each machine a transient hostname to identify the machines.

And don't compare apples with peaches. As we don't know how you have setup your Debian machine (and how Debian handles static/transient setup whilst installation) you can't compare it with the Mageia output.

The only thing what can be seen on your several outputs is:
- you failed to give your machine a static hostname
- your machine got a transient hostname (by mDNS, DHCP or Kernel service)
- xauth cookie worked as per design as for the identification the static hostname is important

Something to read
https://www.redhat.com/sysadmin/set-hostname-linux

I know all of this including the hostnamectl command which I have prsented here first, not you. I am reporting an error because this machine seems misconfigured. Your job would be to find out why with me.

(In reply to Elmar Stellnberger from comment #10)
> I am reporting an error because this machine seems
> misconfigured. Your job would be to find out why with me.
You did not set a static hostname whilst installation or setup of your network connection. End.

What I did or did not will best be known by me. Where do you think then, the sys76darp name does stem from? I have reported this because other machines running Mageia could have been affected by a similar issue.

Since you're using Bugzilla again for basic further education, I'll leave it to Dave or Lewis....
There is enough information about static, transient and pretty hostnames and how they are applied.

The behaviour you criticise, that the xauth cookie uses the static hostname, is standard compliant. This is not a bug but once again a fundamental understanding problem on your part...

I didn´t criticise that.

The bug summary "Mageia uses static hostname instead of transient hostname for xauth cookie" is based on the assumption xauth should use the transient
hostname.

The transient hostname is only generated if the system doesn't already have
a proper static hostname, and can be generated in multiple ways. It may or
may not get the same transient hostname on a reboot. It should not be used
for xauth, so closing as invalid.

The proper way to avoid the problem is to specify a valid hostname when
configuring the network interface.

Status: NEW => RESOLVED
Resolution: (none) => INVALID

To be more specific: It should use the same hostname for generating the cookie as for using it. Basically this should be provided by the mechanism running Xorg unless sethostname is called somewhere after starting the X-server, I´d suppose.