# Select new login manager - was: Lost remote X capability

## depontius

EDIT:

So at this point I've crossed the bridge that I want to at least try out a new login manager.  The problem is that xorg-server has changed it's default to not listen for tcp connections, and gdm does not seem readily configurable to handle this change.  I can tweak the source code, but first I'd like to get something that just works.  Besides, I've been staying back at a back-level release on a local overlay, and I'd just as soon use live code.

So the subject is changing from "Lost remote X capability" to "Select new login manager", and I'll pick up at the end of the thread.

OLD:

Some time in the last week or so I seem to have lost my remote X connection capability.  I normally do maintenance on weekends, and seem to remember noting an oddity last weekend, but didn't think much of it - I just worked around the problem.  This weekend I noticed it more fully.  I couldn't start a GUI editor on a remote machine, and took a little time to dig in.

When I run "netstat -tupln" I see nothing listening on port 6000 - so X isn't even listening for remote connections.  I normally use (pre-systemd) gdm-2.20.11, and it has been working fine for me for years.  I'm running xorg-server-1.17.0:

```
$ emerge -ptv xorg-server

These are the packages that would be merged, in reverse order:

Calculating dependencies... done!

[ebuild   R   ~] x11-base/xorg-server-1.17.0:0/1.17.0  USE="glamor nptl suid udev xorg -dmx -doc -ipv6 -kdrive -minimal (-selinux) -static-libs -systemd -tslib -unwind -wayland -xephyr -xnest -xvfb" 0 KiB

Total: 1 package (1 reinstall), Size of downloads: 0 KiB

 * IMPORTANT: 15 news items need reading for repository 'gentoo'.

 * Use eselect news to read news items.
```

Nothing in here looks like it would have set me to local-only.  I've also looked in /var/log/Xorg.0.log and /var/log/gdm/:0.log and neither says anything about connections or sockets at all, let along local vs remote.

Is anyone else seeing anything like this?

----------

## szatox

Show us your result of

ps aux | grep '/usr/bin/X'

----------

## depontius

```
$ ps -aux | grep /usr/bin/X

root      2923  3.9  0.2 274280 57652 tty7     Ssl+ 06:28   5:28 /usr/bin/X :0 -audit 0 -auth /var/gdm/:0.Xauth vt7
```

----------

## szatox

well, this part looks fine. On which host you checked for open ports?

If you login with ssh, the remote host doesn't have to report post 6000 open. At least my doesn't and it's still working.

Is $DISPLAY setcorrectly? Maybe it's not overriden by client so the app is displayed on the remote machine instead?

Have you tried forwarding with -Y option instead of -X? (trusted mode)

----------

## Jaglover

Same here, can't restart X right now, but invoking it with -listen tcp hopefully will make to listen on 6000 again.

----------

## depontius

I'm checking on the host where I'm running.

I normally don't do "ssh -X" (or -Y) - I manage xauth and export DISPLAY.  "ssh -X" needs something extra to handle "su -" and let root use X, and I never actually got that side of things working.  Simply exporting DISPLAY always worked well enough for me.

----------

## Jaglover

Well, I can report adding '-listen tcp' to Xserver command line fixed it. Apparently the new default is '-nolisten tcp'.

----------

## depontius

I start X through gdm, and the stanza in there that used to do the job is:

```
[security]

DisallowTCP=false
```

It's still there, but doesn't work.  What you say makes sense, but now I have to understand how gdm passes that over to X when it sterts it.  I also have to hope that it's scripted and can be tweaked from here, rather than having to patch the code.

This may be the straw that broke the gdm's back.  I went shopping for alternatives once, finding nothing that did everything I needed.  At the time I wanted xdcmp, which was a bit of a deal-breaker for several display managers.  I've rather dropped that requirement in the past few months.

----------

## Hu

If you manage DISPLAY by hand, you are likely forcing the X11 traffic to flow in cleartext over TCP, rather than inside an ssh-encrypted forwarding.  This may or may not matter to you from a security perspective.

----------

## depontius

This is all inside my own home.  If someone able to snoop my network, I've got bigger problems than the fact that they're snooping my network - I have an intruder.

----------

## Jaglover

```
~ $ cat .xserverrc 

exec /usr/bin/X -listen tcp

```

This works for me, may not work with your setup.

----------

## depontius

 *Jaglover wrote:*   

> 
> 
> ```
> ~ $ cat .xserverrc 
> 
> ...

 

Done.  I can't log out now - one system is at 7 of 15 on weekend update.  But I've created the file with your contents.  I presume it needs to be executable?

----------

## Jaglover

No, it is just one of those *rc files you can have in your home directory. Depending how your X starts they may not be parsed, though. I run startx.

----------

## szatox

depontius, you seem to be using GDM, so one of it's files will most likely contain the line.

Perhaps grepping through /etc for '/usr/bin/X :0 -audit 0 -auth' would find it. Can't be sure, I have slim

----------

## depontius

 *szatox wrote:*   

> depontius, you seem to be using GDM, so one of it's files will most likely contain the line.
> 
> Perhaps grepping through /etc for '/usr/bin/X :0 -audit 0 -auth' would find it. Can't be sure, I have slim

 

I've gone to /etc/X11/gdm and done "grep -R "bin/X" *" already with no luck.

As I said, this may be the straw that broke gdm's back, especially now that I've dropped my with for xdcmp.  I need a display manager with:

1 - Set up X for remote connections

2 - Auto-login for my wife's computer

3 - Tolerate /home on NFS.  (I'm not sure I really need this one, I can run xauth whereever I need to, but gdm has a setting for allowing the cookie on NFS.)

A few months back when I was also insisting on xdcmp, gdm was the only game in town.

----------

## szatox

Does display manager even know where /home actually is?

Anyway, there are some things you might try with gdm:

 *Quote:*   

>  try creating instead
> 
> /etc/gdm/custom.conf containing just
> 
> [security]
> ...

 

 *Quote:*   

> sudo gedit /etc/gdm/gdm.schemas
> 
> find:
> 
> <schema>
> ...

  might be outdated, but I bet you will notice if it's the case  :Laughing: 

 *Quote:*   

> Try running /usr/bin/gdmsetup. Select the "Remote" tab and in the "Style" window select one of the options other than "Remote login disabled."

 

Good luck

----------

## depontius

Still no dice.  I found nothing like gdm.schemas, even in /usr/share/gdm, which is the only place I found anything remotely resembling XML.  That was a glade file, which looked as if it drove the setup GUI.  I did find /etc/X11/xinit/xserverrc and changed the "-nolisten tcp" to "-listen tcp", to no avail.

I haven't run gdmsetup yet.  I think I'll try that, and if it doesn't work it's time to start shopping.

----------

## Jaglover

Out of curiosity I did a Google search on this one, the only thing I found was GDM mailing list 5 years ago, the conclusion back then was the only way is to modify GDM source or use a wrapper instead of /usr/bin/Xorg.

----------

## depontius

I just used gdmsetup and added the "-listen tcp" to what I thought might have been the line to start the X server.  No go.

Time to shop.  I'd rather use something off-the-shelf.  I'll fiddle with gdm source if I don't find something else I like.  As I've said before, I believe that dropping xdcmp will make the search easier.

I guess I can't blame gdm for this, other than in not being properly flexible.  It's really xorg-server that changed its default.  Really, here is a poster-child for classic Unix, scripting, etc.  I've just lost capability.  Had this little piece been configured by scripting, I'd be back in business already.

----------

## depontius

I've narrowed the list down a bit, based on intrusiveness considerations.  For instance, lightdm requires polkit, and sddm calls in a pile of ~arch QT stuff, and for now I don't want that much churn.

My considerations are:

1 - Remote X capability for my home network.

2 - Autologin for my wife's ease.

3 - Individual session types - I'm currently using "Xsession" and have my wife set for xfce, while I use icewm.

4 - Shutdown/Reboot buttons at the greeter screen.

At the moment I have the list down to qingy, lxdm, slim, wdm, and cdm.  I suppose I could use xdm again, and keep re-adding the tk shutdown/reboot buttons I used years and years ago, assuming I can find them again.  For a while there xdm was seeing a lot of churn, and it was a pain re-adding them every time.  It looks to me as if qingy is quite a bit different in operation, but that probably shouldn't dissuade me if it's good in other respects.

Suggest, prefer, pursuade, convince...

----------

## szatox

create a wrapper script for X, add it to $PATH and forget?

I think your use case is not very common, so it will be damn hard to get any input. Wrapper sems to be good like in "it doesn't require maintenance on every single update"

----------

## Jaglover

szatox, 

I do not know in what environment GDM is running, the $PATH may be not set, to avoid malfunctioning GDM may have /usr/bin/X hardcoded. Since X is a symlink to Xorg replacing X with a wrapper would work, but it will not be upgrade-proof.

----------

## Ant P.

I use slim; it does what I want but the implementation is of questionable quality - it leaks a root-owned log filehandle to all child processes if you allow it to daemonize itself (the default under OpenRC).

----------

## depontius

Good point about a wrapper...

```
$ cat /usr/bin/Xwrap 

#!/bin/sh

exec /usr/bin/Xorg -listen tcp ${*}

$ ls -l /usr/bin/X*

lrwxrwxrwx 1 root root       5 Feb 25 16:09 /usr/bin/X -> Xwrap

-rws--x--x 1 root root 2120704 Feb 12 13:20 /usr/bin/Xorg

-r-xr-xr-x 1 root root 1592624 Dec  9 20:15 /usr/bin/Xvnc

-rwxr-xr-x 1 root root      47 Feb 25 16:08 /usr/bin/Xwrap
```

It works.  It's a bit of a hack, a bit of a stopgap.  Maybe what I should do is just install a range of login managers, try them out, and see which I like.  But for now I'm functional again.  I may leave this thread open a bit longer, assuming I try alternatives in the next month.  Maybe I'll install the alternatives along with weekly service, this weekend.

----------

