Description of problem: The last week I tried to set up XDMCP with Mageia, both with 7.1 and Cauldron Starting with the packages from 7.1 a week ago and the newest Cauldron, these packages are effected. At least one of these packages should work. Version-Release number of selected component (if applicable): See above. Packages are: xdm lightdm gdm sddm has no XDMCP How reproducible: Follow these steps: https://wiki.archlinux.org/index.php/XDMCP xdm: In xdm you just need to edit /etc/X11/xdm/xdm-config: !DisplayManager.requestPort: 0 Xacces should be ready as there are only asterisk gdm: Modify /etc/gdm/custom.conf to include: [xdmcp] Enable=true Port=177 lightdm: Modify /etc/lightdm/lightdm.conf Enable the XDMCP Server: [XDMCPServer] enabled=true port=177 Steps to Reproduce: Shorewall ist stoped and disabled, windows firewall too. Tested on Windows side with Xygwin/X an VcXsrv I did this: 0. Logout from Desktop, switch to console 1. systemctl stop <old service> 2. systemctl disable <old service> 3. edit /etc/sysconfig/desktop to new DM 4. systemctl start <old service> 5. systemctl enable <old service> 6. try to login localy (wored every time) 7. Reboot (it might be that the new display number is different than 0, this prevent it, so the system is clean started with the new DM) After reboot, from windows try to connect. Command for Cygwin/X in CygwinTerminal: X -query IPofServer You can see the following effects: xdm: On Linux do tcpdump, you can see incomeing packages, but no responses. There is an open port 177 for xdm in netstat On Windows: nothing gdm: On Linux no port 177! On Windows: nothing lightdm: On Linux: port 177 is open On windows: Loginscreen of Lightdm BUT: Only on Windows, locally on Linux it works fine: you can't login. After entering username and password, the system tries to start the session and then the session restarts to login screen again. this lines are in syslog: Aug 27 10:01:19 linux.local lightdm[1528]: /usr/bin/sessreg: unrecognized argument '<username to login>' Aug 27 10:01:19 linux.local lightdm[1528]: /usr/bin/sessreg: usage /usr/bin/sessreg {-a -d} [-w wtmp-file] [-u utmp-file] [-L lastlog-file] I didn't find any errors for xdm or gdm in the syslog. As no other dm provides XDMCP, no XDMCP in Mageia. The best option seems to be lightdm. I don't know if the patches in the source rpm causes this errors, that's why I posted this here first.
Hi, Thanks reporting you get some troubles with our distribution. We do not support XDMCP as it leaves a Mageia systems to security issues, without properly configuration. It is deactivated. Running a X server (as root) throught a network without doing a ssh connection is not best practices. Have you ever tried a VNC server and client? We think this should runs better. Could you also attach a copy of "/var/log/Xorg.0.log" here when attempting remote connections, for forensics?
XDMCP on GDM is disabled by default upstream. It seems to rely on tcp-wrappers. If that is not explicitly enabled it will not enable XDMCP. Mageia nor Fedora enables that. Tcp_wrappers is IMO outdated, not maintained and should not be relied upon. See e.g. the history of tcp_wrappers: http://svnweb.mageia.org/packages/cauldron/tcp_wrappers/current/SPECS/tcp_wrappers.spec?view=log. For almost 10 years there hasn't been any new version.
CC: (none) => olav
I filed a bug with GDM regarding the unclear documentation. Though possibly they could reconsider why it relies on tcp_wrapper. Maybe there's a systemd thing. I've added that thought as a PS.
See Also: (none) => https://gitlab.gnome.org/GNOME/gdm/-/issues/625
Thanks Olav for your wisdom. I was prone to close this. But, leaving this in Bugsquad for several weeks, before: or closing, or assigning to pkg maintainers.
@ Mia Pienitz, After some discuss on our dev IRC, there is a setting in our MSEC tool to allow X connections throught network. Can you please see it in MCC => Security => Configure system security, permissions, audit => Security Settings => System security and there is a key named: ALLOW_X_SERVER_TO_LISTEN Should be ON to work.
(In reply to Aurelien Oudelet from comment #1) > Hi, > Thanks reporting you get some troubles with our distribution. > > We do not support XDMCP as it leaves a Mageia systems to security issues, > without properly configuration. It is deactivated. Deactivating is not a problem, than it can be activated again. > Running a X server (as root) throught a network without doing a ssh > connection is not best practices. Well, in a little developer network behind some firewalls shouldn't be a problem. I think I can handle it. ;) > > Have you ever tried a VNC server and client? > We think this should runs better. > It integrates not so well. Try multiwindow. Or in other words, VNC RDP or whatever is to connect remotely to a machine. With XDMCP you can have a seamless integration of two desktops in one. > Could you also attach a copy of "/var/log/Xorg.0.log" here when attempting > remote connections, for forensics? With which DM?
(In reply to Aurelien Oudelet from comment #5) > @ Mia Pienitz, > > After some discuss on our dev IRC, there is a setting in our MSEC tool to > allow X connections throught network. > Can you please see it in MCC => Security => Configure system security, > permissions, audit => Security Settings => System security and there is a > key named: > > ALLOW_X_SERVER_TO_LISTEN > > Should be ON to work. xdm: Did it, reboot, nothing changed. At the same time I had a look at the Xorg.0.log: during the time of connection, no new entries.
CC: (none) => ouaurelien
Hello, The variable name in msec is ALLOW_XSERVER_TO_LISTEN. It manages at least gdm and SDDM. It seems that you have also to open ports 177 UDP
CC: (none) => yves.brungard_mageia
Status of this BR?
@ Mia have you take a look at Comment 8
Assignee: bugsquad => ouaurelienStatus: NEW => NEEDINFO
The msec utility will change the parameters used when starting xorg to allow X server to accept connections from network on tcp port 6000. netstat will show that there is a process listening on the port. It doesn't show whether or not shorewall will allow the packets in. To ensure all traffic that originates within the lan will be accepted, add the following four lines to /etc/shorewall/rules.drakx ... # head -n 4 /etc/shorewall/rules.drakx ACCEPT net:10.0.0.0/8 fw ACCEPT net:169.254.0.0/16 fw ACCEPT net:172.16.0.0/12 fw ACCEPT net:192.168.0.0/16 fw This ensures that no matter what range the router uses for the lan, all traffic will be accepted. Don't use this on a device that will be used on an untrusted network. Don't use drakfirewall after that to make any changes or those lines will be removed.
CC: (none) => davidwhodgins
Reporter, could you please reply to the previous question? If you don't reply within two weeks from now, I will have to close this bug as OLD. Thank you.
Keywords: (none) => NEEDINFO
(In reply to papoteur from comment #8) > Hello, > The variable name in msec is ALLOW_XSERVER_TO_LISTEN. > It manages at least gdm and SDDM. > It seems that you have also to open ports 177 UDP No, as per https://github.com/sddm/sddm/issues/1180 sddm will not have any XDMCP support which many major distros will ditch when wayland stuff will be the default window system. Anyway, the recommended Display Manager which can handle XDMCP under Mageia is: LightDM. To enable it, you must do: 1. Modify /etc/lightdm/lightdm.conf 2. add: [XDMCPServer] enabled=true port=177 3. On a headless system, disable the automatic start of one seat so that LightDM can run in the background: [LightDM] start-default-seat=false 4. Enable X server XDMCP support under MSEC by activating the variable: ALLOW_XSERVER_TO_LISTEN 5. Open firewall (default is shorewall) with the 117 port. Also, you can accept local LAN traffic by enabling it by editing as root: /etc/shorewall/rules ACCEPT net:10.0.0.0/8 fw ACCEPT net:169.254.0.0/16 fw ACCEPT net:172.16.0.0/12 fw ACCEPT net:192.168.0.0/16 fw Closing this, as this is tested OK. Feel free to repoen in case of still difficulties.
Status: NEEDINFO => RESOLVEDResolution: (none) => WORKSFORME