Debian 11 (Bullseye) xfce4 with xdmcp

[blacksheeplogic]

I did two side by side installs, one of Debian 10 (Buster) and one was Debian 11 (Bullseye). I chose the xfce4 image as given the choices available  that is my preferred goto desktop.

After doing the base install I applied the following lightdm config:
[Seat:*]
xserver-allow-tcp=true
xserver-share=true
xdmcp-port=177

[XDMCPServer]
enabled=true
port=177

and created a no-nag policy in polkit:
[Allow ALL Actions]
Identity=unix-user:*
Action=*
ResultAny=yes
ResultInactive=yes
ResultActive=yes


Using X-Win32 I can create a XFCE4 session without any issues using the Debian 10 install. Debian 11 it just does not work, it either fails to create the session after logging in (75% of the time), the rest of the time it brings up a partial desktop. I built xfwm4-4.14.16 and installed those and it seems better in that the partial desktop is created. I also tries exporting LIBGL_ALWAYS_INDIRECT=1 and that seemed to clear up many of the errors but then you get a desktop with no background and windows that only respond to the mouse events (keyboard is dead over XDMCP).

So I can continue to chase down errors like:
libGL error: No matching fbConfigs or visuals found
libGL error: failed to load driver: swrast

But I wanted to see if this was just a XFCE4 issue with Debian 11 or a desktop manager issue so I installed XMONAD which works perfectly. Also as expected with Debian "apt-get update;apt-get upgrade" does not fix anything.

GNOME is a no go and GDM3 has multiple issues with XDMCP that I don't think they will ever fix.
KDE PLASMA that just logs in, changes the background to GREY and hangs.
LXDE I've had working on Debian 11 with XDMCP
XMONAD works.

Debian 11 XFCE4 out of the box is broken. There's no issues on Debian 10 with lightdm & it's window's managers including XFCE4.

Anyone else having issues with Debian 11 & XDMCP or know of other Window managers not horribly broken in Debian 11 and  preferably that come part of the install iso. XMONAD is fine 95% of the time but floating window managers can be convenient at times. For the moment I think I will stay on Debian 10 but it may be time to look at a different distro. Debian up to now has been stable for me but theres obvious quality issues in Debian 11 + XFCE and I think it's time to part ways permanently with XFCE4.

[dietert1]

Last week i also tried to install bullseye and then went back to buster, also due to problems with the desktop. In my case the culprit was a legacy C61 Geforce 6150SE (chipset integrated GPU) that works in buster nouveau after adding some "miscellaneous non-free firmware" package i never heard of before.
Took several days to make it work again. It plays youtube, receives EMails and displays them as text-only etc. They have come a long way.
Sorry, i can't help with bullseye insight (yet). The experts recommend combining bullseye with packages from sid. But that's going to be hardcore.

Regards, Dieter

[PKTKS]

I have all my workstations with  vanilla XDM for decades...
Pretty sure it can be set up without problems...

A decade ago I had to ditch all this nonsense promoted by
"debian leaders" sponsored by the under the hood POTTERIX folks...

Two things that definitely will bring you several major problems..
- running a systemd enabled Xsession
- running anything other than proper X.org matched compiled stuff..
( includes lightdm, gdm kdm.. and so forth)

Setting up XDMCP protocol requires pretty much 2 or 3 config files
edited by hand.. namely:
- xdm-config
- Xaccess

and Xsetup/Xsession which more likely is where you set your WM session

Nevertheless putting a failsafe xdm up running requires you
to setup only the protocol part and  invoke the session with
proper tidbits...  if you will enable features like libGL GLX...

 :0  -depth 24 -fbbpp 32 r +bs +xinerama +iglx  -listen tcp

last param is required to listen remote stations..

So.. the bottom line since major distros started to mess X11R6
and made a hell of a mess into X11R7 is to get rid of these
parts... systemd and anything other than plain xdm...

The server should be able to startup clean listening remote connections
and with proper security mechanisms enabled.

Easier said than done..  my only advice is to get rid of systemd distros
Get the equivalent DEVUAN and try again... with plain XDM as the session manager

IT should BE BETTER  although I have ditched them all in favor
of a custom solution which is bullet proof once you get rid of this problematic shit

IT WORKS .. it has been working for me for decades...
reason why i ditched all distros based on systemd and
I am doing the same with this wayland  twist  which has been also a big problem

I have a hunch that these problems have the same common cause..
to implode and fragment X11 (XOrg) to cripple *NIX  and promote other thing..

You will also need a very careful setup of MESA (which relies on LLVM/clang)
to enable accelerated drivers..  the messages posted are related to a bad
installation of MESA...  which is not trivial.

and got worst since MESON replaced AUTOCONF.
I had  problems with same version compiled with MESON segfaulting..
while a clean AUTOCONF works perfect..

I can not even explain or understand why..
My hunch is that  MESON over simplified things that AUTOCONF never will..

My hunch.. so far my system is 100%  XDM libGL and working fine..
For how long... can not tell 

Last but not least...  Slackware has now a major RC (release candidate)
that should work with plain X11 and xdm mechanisms.. once Slackware
is STILL  the far way best *NIX  based LINUX distro out there

Paul

[PKTKS]

For the record...  distros with high degree of confidence
and still faithful to *NIX in which you can pretty much
do things yourself instead of being jailed by POTTERIX...

• https://files.devuan.org
• https://antixlinux.com/
• https://mxlinux.org/products/
• http://www.slackware.com/
• https://voidlinux.org/
• https://artixlinux.org/index.php
• https://web.obarun.org/index.php?id=1
• https://alpinelinux.org/downloads/

Chances of success are far better using some of the above.
Your mileage  will vary..

These are my preferred set distros to deploy always

Paul

[blacksheeplogic]

• https://files.devuan.org
• https://antixlinux.com/
• https://mxlinux.org/products/
• http://www.slackware.com/
• https://voidlinux.org/
• https://artixlinux.org/index.php
• https://web.obarun.org/index.php?id=1
• https://alpinelinux.org/downloads/

These are my preferred set distros to deploy always

Thanks for the suggestions and view. I'm going to go with your suggestion of Devuan, just downloading the DVD iso now.

I like XDMCP
 and I have noticed a very deliberate move to cripple and break it. Bug reports don't get fixed. I've used lightdm because up until now it works and was simple. If I understand your response correctly you don't have lightdm installed so what desktop manager package do you have installed? I'm also not sure on the configuration you have, can you post any of your config files.

[PKTKS]

Thanks for the suggestions and view. I'm going to go with your suggestion of Devuan, just downloading the DVD iso now.

DEVUAN was suggested because it is compatible with Debian releases..
but WITHOUT the systemd messy thing all spread around.

I am guessing that you already know something about Debian
so Devuan should be easier to jump in

I like XDMCP
 and I have noticed a very deliberate move to cripple and break it. Bug reports don't get fixed.

I have seen that too and it is very clear that things converge by replacing all X11R6/X11R7 with a panacea of twisted solutions like lightdm, wayland, different input methods.. another GLX extension totally crippled by proprietary APIs and partially and bad implemented by default..

Looks like a well sponsored movement to make X11 looks like old ugly buggy unsafe.. messy.. fragmented..  anyone can conclude what sort of strategy is this.. not new at all

I've used lightdm because up until now it works and was simple. If I understand your response correctly you don't have lightdm installed so what desktop manager package do you have installed? I'm also not sure on the configuration you have, can you post any of your config files.

I will try to give you the RATIONALE - which I think is far more useful than my opinion.
I got to the point on my workstations by need.
Things got too messy and unreliable just adopting "solutions" that are really trojans.

So by upgrading my servers with proper decisions things sorted out just fine.


*** RATIONALE ***
- Why  dismiss systemd ?
   Because systemd is A COMPILE TIME OPTION. Impossible to revert or alter

- Why is that bad ?
  Because it gives you a pre-defined way to do things without options

- Why is that bad ?
  Because being a compile time option it forces an insane number of other things to be compiled in with systemd or just blinded deformed by it. Example: DNS servers. File system tools, INIT decisions and critical stuff.

- What advantages I have using other INIT like SysV, RunINIT or others ?
  All your applications will be self contained without the systemd dependency
  All your system will be free of the forced behavior imposed by systemd
  All your systemd will be configured by you  to meet your needs
  All  your security measures will be free of that crappy systemd
   that includes already trusted reliable logging tools, authentication tools so forth

- So I will have to configure things?
  YES. That is the RATIONALE of it. **YOU** will make things as your needs demand

- How getting rid of other X11 session managers I will benefit something?
 Because by getting rid of TOOLKIT  dependency you will not have problems when making decisions if a suitable "upgrade" will render your systems  a messy confused thing made by someone else..

- So how this XDM thing works...   
 I will put that RATIONALE into another post..

give me some time to craft a sane rationale..
Paul

[PKTKS]

If I understand your response correctly you don't have lightdm installed

Yes. ditched all of them. I have been using XDM only for decades...
After trying almost all of them KDM GDM WDM and etc et al.
Why XDM? Most compatible with X11 toolkit independent, fast, enough for login.

Bottom line is that you need a proper tool which focus on doing the proper thing ONLY
That is how *NIX works and works oders of magnitide better this way
I think any book of *NIX starts by saying that..

Mixing INIT with DNS resolvers and file system tools and DisplayMangers?
Drop it.  Use the right tool which is 100% compatible under that worst possible case.
That is XDM.

I will start sort of a RATIONALE by calling some odds:
- Matching OPTIMIZED KERNEL, SECURE INIT BOOT and SECURE DisplayManagers
  is not casual or trivial. It needs a good understading how things interact.
  Why? Because OPTIMIZED things like kernel and DisplayServers are hardware dependent
  and security depends on how things were properly compiled and set up by ground zero.
 
- How? By using reliable tools focused on doing **JUST** what they are meant for:
  INIT does only init scripts
  DNS  does only and properly secure resolution
  XDM  does only the authentication for your disaplay servers.
  So using XDM and xauth to proper login you should be confident that things are
  restricted to their own.

so what desktop manager package do you have installed?

NONE. I have written my own.
After proper authentication there is just a single one applet to manage "Desktops"
shot attached

I'm also not sure on the configuration you have, can you post any of your config files.

Ok now comes the real hard RATIONALE
i will try to reduce that at minimum, in case just ask:

- First and foremost: DO NOT SKIP STEPS. Why?
  Because when things fail you need to locate them, even wo knowing the cause you will still
  be able to fix them all. Just copy and paste someone's else things will not work,
  it may work for some  first simple understanding but will fall short very soon when upgrading
  and porting that to other servers and hardware.

- Slackware methods are still the most *NIX like and can be easily inspected
 You can check them all by just browsing the packs at
    http://ftp.slackware.com/pub/slackware/slackware64-current/slackware64/x/
  Slackware is put together by people that understands how things are critical when interact
  and how important when they fail. Not trying to be fancy or cute gizmos but a secure system.
  I had several issues trying to optimize things and having them working against all these
  obsoleted and crapped stuff made since X11R7 started.... *ALOT*
 
- First RATIONALE is MESA. The drivers must be compiled with proper LLVM/clang
  because they are dependent on their versions. So upgrading LLVM you have a major issue
  Since Slackware is the best bottom line we still have I will mention it
  Slackware MESA is now  mesa-21.2.6-x86_64-1.txz
  all drivers and the master XOrg server depends on both
 
- Second RATIONALE is the interaction of XDM and the server.
  They are critical to login into a secure session using XAUTH
  Currently Slackware distro is using
 xauth-1.1-x86_64-3.txz
 xdm-1.1.11-x86_64-14.txz
 xorg-server-1.20.13-x86_64-1.txz
 I had issues of incompatible hardware with recent xorg-server and I fallback to 1.19 branch
 so the RATIONALE is be prepared to check your hardware with some odds in some upgrades

- Another worthy RATIONALE is the XDM LOGIN greeter which just for the sake of inputting
 your login and perform basic session management and requires the following matched libs
 libXdmcp-1.1.3-x86_64-3.txz
 libXinerama-1.1.4-x86_64-3.txz
 libXaw3d-1.6.3-x86_64-3.txz
 libXaw3dXft-1.6.2h-x86_64-3.txz

Last but not least is the mess they are doing on INPUT METHODS.
You need a reliable input method and a proper FontServer to all your Displays.
XFS is a reliable tool for that once it works for remote stations as well
xfs-1.2.0-x86_64-4.txz

So... Having sample init configs This  is easy....
You can find them in the Slackware packages just fine..

You can find all good sample script for everything you need on xdm-1.1.11-x86_64-14.txz
Do not just copy and paste, you can use them for options relevant to your needs..

Grab this packages and all BASE XDM SCRIPTS are there...
It is a good entry point..

Better if you can handle a Slackware base install as well...
But this is not the kind of point click and puf!
You will configure things yourself just as you want and need them working.
And they do work a hell order magnitude better after these steps.

Paul

[blacksheeplogic]

DEVUAN was suggested because it is compatible with Debian releases..
but WITHOUT the systemd messy thing all spread around.

I am guessing that you already know something about Debian
so Devuan should be easier to jump in

I chose a Debian distro because it was considered stable and well tested. My background is however not Linux - I have a Unix background using Unix since the late 80's but these have been proprietary version on non-Intel hardware for the most part. I spent many years in Kernel development.

I will try to give you the RATIONALE - which I think is far more useful than my opinion.
I got to the point on my workstations by need. Things got too messy and unreliable just adopting "solutions" that are really trojans.

Because systemd is A COMPILE TIME OPTION. Impossible to revert or alter
Because it gives you a pre-defined way to do things without options
Because being a compile time option it forces an insane number of other things to be compiled in with systemd or just blinded deformed by it. Example: DNS servers. File system tools, INIT decisions and critical stuff.

- What advantages I have using other INIT like SysV, RunINIT or others ?
  All your applications will be self contained without the systemd dependency
  All your system will be free of the forced behavior imposed by systemd
  All your systemd will be configured by you  to meet your needs
  All  your security measures will be free of that crappy systemd
   that includes already trusted reliable logging tools, authentication tools so forth

I also did not understand the move to systemd however it is not the only poor decision we are faced with. I think Polkit is actually worse. I would not have such a problem with Polkit if it was only activated with account services but it's not. It's embedded and difficult to remove. It also has huge gaping security issues due to the way it escalates.

[blacksheeplogic]

- First and foremost: DO NOT SKIP STEPS. Why?
  Because when things fail you need to locate them, even wo knowing the cause you will still
  be able to fix them all. Just copy and paste someone's else things will not work,
  it may work for some  first simple understanding but will fall short very soon when upgrading
  and porting that to other servers and hardware.
 
- Second RATIONALE is the interaction of XDM and the server.
  They are critical to login into a secure session using XAUTH
  Currently Slackware distro is using
 xauth-1.1-x86_64-3.txz
 xdm-1.1.11-x86_64-14.txz
 xorg-server-1.20.13-x86_64-1.txz
 

I primarily work in the backend and avoid anything on the frontend when I can. I know the basis to get the desktop working and how to do basic XDMCP configuration. But that stops short at xauthand .Xauthority. Basic config does not require tweaks in there but it appears some configs are now requiring it.

[blacksheeplogic]

Yes. ditched all of them. I have been using XDM only for decades...
After trying almost all of them KDM GDM WDM and etc et al.
Why XDM? Most compatible with X11 toolkit independent, fast, enough for login.

Devuan feels very familar and I really like the clean install I got with it. I installed XDM but was unable to get XDM fully working. I could get the console to login but starting a XDMCP session all I got was host unwilling. I configured the basic X11/xdm config - Xserver, Xaccess, and xdm-config. Maybe I will come back and look at the settings again when I have more time.

I installed lightdm and kept the current config, works flawlessly with XDMCP, no errors just worked first time - a no fuss, no drama setup. Configured XDMCP in lightdm.conf and all was good. Just how it should be.

Thanks for your help!

[PKTKS]

Expected to happen as Devuan being just Debian equivalent
wo systemd is following the herd using these alternatives..

But it is hard to compare the level of mature secure options you have
using XDM and xauth with others so simple..

That kind of error you mention is usually due to a permission problem
A simple file or library permission, or directly related to the user trying to
run xauth.  Should never happen in a default Slackware install.
Slackware by default follows best NIX practices.

There is a new kid on the block.. (one more) SDDM:
https://en.wikipedia.org/wiki/Simple_Desktop_Display_Manager

Looks like just a cute thing to eye candy  fast installers...

To leverage security one step.. next step is PAM
Slackware is also ready to put PAM on top of X11 stack
but that is harder to config...

You should be able to solve XDM  permissions... xauth, xhost..
and put it ok on Devuan..

Persist...
Paul