gdm vs. kdm - X

This is a discussion on gdm vs. kdm - X ; I'm running the Etch distro of Debian Linux under the 2.6 kernel on an ADM-64 x 2 Athlon processor, but I'm havuing a little problem. I much prefer the login and shutdown utilities offered by kdm over those offered by ...

+ Reply to Thread
Results 1 to 16 of 16

Thread: gdm vs. kdm

  1. gdm vs. kdm

    I'm running the Etch distro of Debian Linux under the 2.6 kernel on an
    ADM-64 x 2 Athlon processor, but I'm havuing a little problem. I much
    prefer the login and shutdown utilities offered by kdm over those offered by
    gdm, but when I change the default dispplay manager to kdm from gdm, I can
    no longer log intothe system via XDMCP. I can log in from the console just
    fine. I changed the Enable value under the [Xdmcp] section in
    /etc/kde3/kdm/kdmrc to "true", but when I try to open a sesssion from a
    Windows PC using Xming, it shuts down the x server instantly. If I specify
    gdm as the default display manager, it works just fine, but then of course I
    no longer have the functionality of the kdm session manager.



  2. Re: gdm vs. kdm

    On Sat, 05 Jan 2008 20:00:35 -0600, Leslie Rhorer wrote:

    > I'm running the Etch distro of Debian Linux under the 2.6 kernel on an
    > ADM-64 x 2 Athlon processor, but I'm havuing a little problem. I much
    > prefer the login and shutdown utilities offered by kdm over those offered by
    > gdm, but when I change the default dispplay manager to kdm from gdm, I can
    > no longer log intothe system via XDMCP. I can log in from the console just
    > fine. I changed the Enable value under the [Xdmcp] section in
    > /etc/kde3/kdm/kdmrc to "true", but when I try to open a sesssion from a
    > Windows PC using Xming, it shuts down the x server instantly. If I specify
    > gdm as the default display manager, it works just fine, but then of course I
    > no longer have the functionality of the kdm session manager.


    See the xdmcp howto at www.tldp.org. I prefer to use gdm because, as you
    have noted, it is easier to set up xdmcp.


  3. Re: gdm vs. kdm

    "ray" wrote in message
    newsan.2008.01.06.15.52.41.113495@zianet.com...
    > On Sat, 05 Jan 2008 20:00:35 -0600, Leslie Rhorer wrote:
    >
    >> I'm running the Etch distro of Debian Linux under the 2.6 kernel on an
    >> ADM-64 x 2 Athlon processor, but I'm havuing a little problem. I much
    >> prefer the login and shutdown utilities offered by kdm over those offered
    >> by
    >> gdm, but when I change the default dispplay manager to kdm from gdm, I
    >> can
    >> no longer log intothe system via XDMCP. I can log in from the console
    >> just
    >> fine. I changed the Enable value under the [Xdmcp] section in
    >> /etc/kde3/kdm/kdmrc to "true", but when I try to open a sesssion from a
    >> Windows PC using Xming, it shuts down the x server instantly. If I
    >> specify
    >> gdm as the default display manager, it works just fine, but then of
    >> course I
    >> no longer have the functionality of the kdm session manager.

    >
    > See the xdmcp howto at www.tldp.org.


    Thanks, this produced a lot more reading than useful material and several
    references whihc acted alike all one must do is set the field in kdmrc to
    "true" as I slisted above. I did, however, run across one very obscure
    reference to Xaccess with no explanations. I looked at the
    /etc/kde3/kdm/Xaccess file for about the third and then fourth times before
    I spodtted an extremely easily overlooked commented-out line with a * on it.
    Removing the comment allowed the X server to start a session.

    It never ceases tro amaze me how skimpy the documentation for Linux is Why
    don't they put thghis in the Man page?. I love the OS, and it surely beats
    the ever-loving stuffing out of Windows, but finding basic information like
    this is like pulling teeth. The solution was trivial, but it took me four
    days to find it (with your help).

    > I prefer to use gdm because, as you
    > have noted, it is easier to set up xdmcp.


    Yes, but it doesn't offer the services (like shutdown) KDM does. 'And it's
    not like the configuration was particularly difficult, just unbelievably
    obscure.



  4. Re: gdm vs. kdm

    Leslie Rhorer wrote:

    > Yes, but it doesn't offer the services (like shutdown) KDM does. 'And it's
    > not like the configuration was particularly difficult, just unbelievably
    > obscure.
    >
    >


    If you turn on 'Show actions menu' in gdmsetup, you can shutdown,
    restart, custom and configure for XDMCP in GDM. (These are always
    available for local login, but disabled for remote login by default.)

  5. Re: gdm vs. kdm

    On Mon, 7 Jan 2008 00:51:19 -0600,
    Leslie Rhorer , in
    <4781cbf3$0$28784$4c368faf@roadrunner.com> wrote:

    >+ It never ceases tro amaze me how skimpy the documentation for Linux
    >+ is Why don't they put thghis in the Man page?


    Because most folks don't need it, and nobody stopped to write it
    down. What itches gets scratched.

    You should write up what you found, and how to make it work.

    --
    Consulting Minister for Consultants, DNRC
    I can please only one person per day. Today is not your day. Tomorrow
    isn't looking good, either.
    I am BOFH. Resistance is futile. Your network will be assimilated.

  6. Re: gdm vs. kdm

    On Mon, 07 Jan 2008 00:51:19 -0600, Leslie Rhorer wrote:

    > "ray" wrote in message
    > newsan.2008.01.06.15.52.41.113495@zianet.com...
    >> On Sat, 05 Jan 2008 20:00:35 -0600, Leslie Rhorer wrote:
    >>
    >>> I'm running the Etch distro of Debian Linux under the 2.6 kernel on an
    >>> ADM-64 x 2 Athlon processor, but I'm havuing a little problem. I much
    >>> prefer the login and shutdown utilities offered by kdm over those offered
    >>> by
    >>> gdm, but when I change the default dispplay manager to kdm from gdm, I
    >>> can
    >>> no longer log intothe system via XDMCP. I can log in from the console
    >>> just
    >>> fine. I changed the Enable value under the [Xdmcp] section in
    >>> /etc/kde3/kdm/kdmrc to "true", but when I try to open a sesssion from a
    >>> Windows PC using Xming, it shuts down the x server instantly. If I
    >>> specify
    >>> gdm as the default display manager, it works just fine, but then of
    >>> course I
    >>> no longer have the functionality of the kdm session manager.

    >>
    >> See the xdmcp howto at www.tldp.org.

    >
    > Thanks, this produced a lot more reading than useful material and several
    > references whihc acted alike all one must do is set the field in kdmrc to
    > "true" as I slisted above. I did, however, run across one very obscure
    > reference to Xaccess with no explanations. I looked at the
    > /etc/kde3/kdm/Xaccess file for about the third and then fourth times before
    > I spodtted an extremely easily overlooked commented-out line with a * on it.
    > Removing the comment allowed the X server to start a session.
    >
    > It never ceases tro amaze me how skimpy the documentation for Linux is Why
    > don't they put thghis in the Man page?. I love the OS, and it surely beats
    > the ever-loving stuffing out of Windows, but finding basic information like
    > this is like pulling teeth. The solution was trivial, but it took me four
    > days to find it (with your help).


    Because developers usually hate doing the documentation. IMHO - what the
    entire Linux system could really use is a few highly dedicated volunteer
    technical writers. The answer is usually available, but as you've
    commented it can be a bear to find it. Hence the RTFM reply is usually
    pointless as it fails to mention which manual.


    >
    >> I prefer to use gdm because, as you
    >> have noted, it is easier to set up xdmcp.

    >
    > Yes, but it doesn't offer the services (like shutdown) KDM does. 'And it's
    > not like the configuration was particularly difficult, just unbelievably
    > obscure.


    Amen.


  7. Re: gdm vs. kdm

    Leslie Rhorer wrote:

    > It never ceases tro amaze me how skimpy the documentation for Linux is Why
    > don't they put thghis in the Man page?. I love the OS, and it surely beats
    > the ever-loving stuffing out of Windows, but finding basic information like
    > this is like pulling teeth. The solution was trivial, but it took me four
    > days to find it (with your help).


    Plenty of documentation on linux.
    Try /usr/share/doc/. I think you'll find more pages of documentation
    than on any other operating system.

  8. Re: gdm vs. kdm

    "Jurgen Haan" wrote in message
    news:4781ec0f$0$85788$e4fe514c@news.xs4all.nl...
    > Leslie Rhorer wrote:
    >
    >> Yes, but it doesn't offer the services (like shutdown) KDM does. 'And
    >> it's
    >> not like the configuration was particularly difficult, just unbelievably
    >> obscure.
    >>
    >>

    >
    > If you turn on 'Show actions menu' in gdmsetup, you can shutdown,
    > restart, custom and configure for XDMCP in GDM. (These are always
    > available for local login, but disabled for remote login by default.)


    That only allows those options from the logon screen, and KDM has more
    options than just that, plus additional optionson the logout screen.



  9. Re: gdm vs. kdm

    Leslie Rhorer wrote:

    >
    > That only allows those options from the logon screen, and KDM has more
    > options than just that, plus additional optionson the logout screen.
    >


    GDM more or less only provides the logon screen (through XDMCP) right?
    The rest is done through your desktop environment.

  10. Re: gdm vs. kdm


    "Jurgen Haan" wrote in message
    news:47849ED5.8000000@fake.dom...
    > Leslie Rhorer wrote:
    >
    >>
    >> That only allows those options from the logon screen, and KDM has
    >> more
    >> options than just that, plus additional optionson the logout screen.
    >>

    >
    > GDM more or less only provides the logon screen (through XDMCP) right?
    > The rest is done through your desktop environment.


    That's true for GDM, but not KDM. KDM provides additonal logon *AND* log
    off options when configured by KDE. The options are only presented (in KDE
    or anywhere else) when KDM is employed as the Display Manager.



  11. Re: gdm vs. kdm


    "I R A Darth Aggie" wrote in message
    news:slrnfo4hp7.log.n0b0dy@invalid.invalid...
    > On Mon, 7 Jan 2008 00:51:19 -0600,
    > Leslie Rhorer , in
    > <4781cbf3$0$28784$4c368faf@roadrunner.com> wrote:
    >
    >>+ It never ceases tro amaze me how skimpy the documentation for Linux
    >>+ is Why don't they put thghis in the Man page?

    >
    > Because most folks don't need it, and nobody stopped to write it
    > down. What itches gets scratched.


    Most people *DO* need it. Indeed, while I am not a *nix guru by most
    standards, I have been working with various versions of Unix (HP-UX,
    Solaris, Debian Linux, Red Hat, Xandros) for many years. I'm not saying
    every person needs to use the same configuration I did, but every available
    option needs to be covered in the man page or in auxilliary documentation.
    This is only proper documentation methodology, nothing more.

    > You should write up what you found, and how to make it work.


    I did in my post above. If you mean submit it for includin in the man
    page, then I have no idea how to submit documents for inclusion in the man
    page, and far more than just the wide open option upon which I stumbled
    needs to be documentad in that man page. It only just so happens I'm
    running on a secure network and so opening the server to logins from any
    machine is not a problem. If this were to be used on one of my servers at
    work, I woujld still probably be researching the issue.

    Perhaps more importantly, it is not my responsibility to document other
    people's programming unless they ask me to. It is incumbent upon any
    competent developer to properly document his work or to obtain the services
    of someone who can and is willing to to do it for them. Before you decide
    to post a sarcastic reply about my not knowing about what I am speaking, I
    have worked as a developer myself and have provided documentation for my
    users. I have also worked with other developers to produce documentation
    for them. Finally, writing a man page is just not that difficult, period,
    and certainly not as documentation efforts in genreal are concerned.



  12. Re: gdm vs. kdm

    On Sun, 13 Jan 2008 20:57:12 -0600,
    Leslie Rhorer , in
    <478acf8a$0$18422$4c368faf@roadrunner.com> wrote:
    >+
    >+ "I R A Darth Aggie" wrote in message
    >+ news:slrnfo4hp7.log.n0b0dy@invalid.invalid...
    >+ > On Mon, 7 Jan 2008 00:51:19 -0600,
    >+ > Leslie Rhorer , in
    >+ > <4781cbf3$0$28784$4c368faf@roadrunner.com> wrote:
    >+ >
    >+ >>+ It never ceases tro amaze me how skimpy the documentation for Linux
    >+ >>+ is Why don't they put thghis in the Man page?
    >+ >
    >+ > Because most folks don't need it, and nobody stopped to write it
    >+ > down. What itches gets scratched.
    >+
    >+ Most people *DO* need it.


    Most people aren't connecting to a terminal server, they're logging in
    to their local machine. Until you can show me something else, I'll
    stand my by original assertion: most folks don't need XDMCP, thus the
    relative lack of documentation.

    >+ > You should write up what you found, and how to make it work.
    >+
    >+ I did in my post above. If you mean submit it for includin in the man
    >+ page, then I have no idea how to submit documents for inclusion in the man
    >+ page, and far more than just the wide open option upon which I stumbled
    >+ needs to be documentad in that man page. It only just so happens I'm
    >+ running on a secure network and so opening the server to logins from any
    >+ machine is not a problem. If this were to be used on one of my servers at
    >+ work, I woujld still probably be researching the issue.


    Well, there's this:

    http://tldp.org/
    http://gentoo-wiki.com/HOWTO_Gdm_setup
    http://live.gnome.org/DocumentationProject/Join

    >+ Perhaps more importantly, it is not my responsibility to document other
    >+ people's programming unless they ask me to.


    It isn't your responsibility, no. But you shouldn't bitch if someone
    chooses not to document their programming, either.

    Frankly, I'd rather have someone *other* than the programming team
    write the documentation. The documentation is likely to be more clear
    and less confusing than something written by someone who groks the
    program so well that the resulting documenation is...unclear because
    they know what they mean, even if you and I don't.

    As someone else noted, there's nothing wrong with Linux documentation
    that a couple of good tech writers and a good editor or three can't
    cure.

    --
    Consulting Minister for Consultants, DNRC
    I can please only one person per day. Today is not your day. Tomorrow
    isn't looking good, either.
    I am BOFH. Resistance is futile. Your network will be assimilated.

  13. Re: gdm vs. kdm

    On Jan 7, 10:37 am, I R A Darth Aggie wrote:
    > On Mon, 7 Jan 2008 00:51:19 -0600,
    > Leslie Rhorer , in
    >
    > <4781cbf3$0$28784$4c368...@roadrunner.com> wrote:
    > >+ Itneverceasestro amaze me how skimpy the documentation for Linux
    > >+ is Why don't they put thghis in the Man page?

    >
    > Because most folks don't need it, and nobody stopped to write it

    How can you say remote login is not needed??? If you run any server or
    servers who wants to plug and unplug monitors and keyboards every time
    you want to change something. I like using a GUI and have 5 old
    systems sitting on the floor and with suse I can log into all, make
    mods with yast etc.. without having to add screens and keyboards. I'd
    like to switch to kubuntu but I need remote login and NIS
    capability!!!!

  14. Re: gdm vs. kdm

    On Wed, 23 Jan 2008 06:15:27 -0800 (PST),
    mmerrit2@twcny.rr.com , in
    wrote:
    >+ On Jan 7, 10:37 am, I R A Darth Aggie wrote:
    >+ > On Mon, 7 Jan 2008 00:51:19 -0600,
    >+ > Leslie Rhorer , in
    >+ >
    >+ > <4781cbf3$0$28784$4c368...@roadrunner.com> wrote:
    >+ > >+ Itneverceasestro amaze me how skimpy the documentation for Linux
    >+ > >+ is Why don't they put thghis in the Man page?
    >+ >
    >+ > Because most folks don't need it, and nobody stopped to write it


    >+ How can you say remote login is not needed???


    Because that's not what I said? to reiterate, I stated that most
    people don't need XDMCP enabled on their X servers. If you need remote
    access, that's what G*d invented ssh for.

    And if you pay attention to the command switches for ssh, you'll note
    that there are two (-X, -Y) that have to do with tunneling X over the
    ssh connection. Which means your X session is also secure, and if
    you're feeling adventerous, you can turn on ssh's compresion feature
    (-C) if you are connecting thru a slowish network.

    And XDMCP is a potential security risk:

    http://www.gnome.org/projects/gdm/do...#xdmcpsecurity

    Even though your display is protected by cookies, XEvents and
    thus keystrokes typed when entering passwords will still go
    over the wire in clear text. It is trivial to capture these.

    >+ If you run any server or
    >+ servers who wants to plug and unplug monitors and keyboards every time
    >+ you want to change something. I like using a GUI and have 5 old
    >+ systems sitting on the floor and with suse I can log into all, make
    >+ mods with yast etc.. without having to add screens and keyboards. I'd
    >+ like to switch to kubuntu but I need remote login and NIS
    >+ capability!!!!


    And I can do all that under Debian with ssh and *no* XDMCP. Really.
    Honest. Question, if I might? why are you running X on a server? none
    of my servers run X. That's not to say that X isn't available - it is,
    but it isn't turned on by default. It is a waste of CPU cycles.

    And kubuntu should be able to do everything you want. It is, afterall,
    Debian with a pretty installer and a smaller set of packages. You need
    only make sure to install the nis package, as well as the ssh server
    or other servers to make remote access available to you in the form
    you like.

    --
    Consulting Minister for Consultants, DNRC
    I can please only one person per day. Today is not your day. Tomorrow
    isn't looking good, either.
    I am BOFH. Resistance is futile. Your network will be assimilated.

  15. Re: gdm vs. kdm

    >>+ >>+ It never ceases tro amaze me how skimpy the documentation for Linux
    >>+ >>+ is Why don't they put thghis in the Man page?
    >>+ >
    >>+ > Because most folks don't need it, and nobody stopped to write it
    >>+ > down. What itches gets scratched.
    >>+
    >>+ Most people *DO* need it.

    >
    > Most people aren't connecting to a terminal server, they're logging in
    > to their local machine. Until you can show me something else, I'll
    > stand my by original assertion: most folks don't need XDMCP, thus the
    > relative lack of documentation.


    I was speaking more broadly of the frequent lack of detail in MAN pages,
    but nonetheless, if a switch or configuration option is to be offered in a
    utility, then it needs to be documented. Failing to do so a major reason
    those who claim Windows to be superior to Linux make that claim.

    >>+ machine is not a problem. If this were to be used on one of my servers
    >>at
    >>+ work, I woujld still probably be researching the issue.

    >
    > Well, there's this:
    >
    > http://tldp.org/
    > http://gentoo-wiki.com/HOWTO_Gdm_setup
    > http://live.gnome.org/DocumentationProject/Join


    None of which would have helped. I'm not using GDM or Gnome, and the
    LDP site is mostly just a repository for the MAN pages. It's the MAN pages
    of which I am primarily speaking, in the first place.

    >>+ Perhaps more importantly, it is not my responsibility to document other
    >>+ people's programming unless they ask me to.

    >
    > It isn't your responsibility, no. But you shouldn't bitch if someone
    > chooses not to document their programming, either.


    Oh yes, I should, and so should you. Documentation is just as important
    an aspect of creating an application as writing the code, and an application
    or utility with inadequate documentation should no more be tolerated than
    bug-ridden software. That such may be in fact the norm is irrelvant. Only
    by demanding better quality form their products will consumers ever obtain
    better quality.

    > Frankly, I'd rather have someone *other* than the programming team
    > write the documentation. The documentation is likely to be more clear
    > and less confusing than something written by someone who groks the
    > program so well that the resulting documenation is...unclear because
    > they know what they mean, even if you and I don't.


    Depending on the developer, I don't disagree. Certainly I wouldn't
    expect a developer to speak many languages, for example, and asking someone
    whose programming skills are superb but who speaks only Russian or Japanese
    to write documentation in English, Spanish, Dutch, Arabic, etc. is just
    silly. That is why I said "or to obtain the services of someone who can and
    is willing to to do it for them."

    > As someone else noted, there's nothing wrong with Linux documentation
    > that a couple of good tech writers and a good editor or three can't
    > cure.


    And it is the responsibility of the developer to engage their services.
    Amything else respesents malfeasance. In the case of a MAN page for a
    widely deployed *nix utility, people capable of undeertaking and willing to
    undertake such a minor task for free are quite thick upon the ground. I
    myself have undertaken that very thing for free on far more complex projects
    than KDM.



  16. Re: gdm vs. kdm

    > Because that's not what I said? to reiterate, I stated that most
    > people don't need XDMCP enabled on their X servers. If you need remote


    Most people don't need computers. Most people don't run Linux. Most
    people don't speak English, or even have access to a reliable source of
    electricity. Most people are not relevant to this discussion. What is
    relevant is the means for those who wish to or need to run XDMCP. That
    other means of achieving a similar result may or may not be available may or
    may not be relevant. Oh, and just by the way, one doesn't enable XDMCP on
    the X server. The X server resides on the machine which contacts the remote
    machine. XDMCP is a manager to an X Display Manager client, which in this
    case resides on a file server and happens to be KDM.

    > access, that's what G*d invented ssh for.


    ssh doesn't provide a Desktop Manager. XDMCP does.

    > And XDMCP is a potential security risk:


    Of course it is! No one in their right mind would be enabling XDMCP
    unless either the host itself does not need to be secure, or the network
    itself is secure. In this case, it's both.

    A foreign as the concept seems to be in the contemporary climate of
    paranoia, not everything needs to be secure. In this particular case, every
    single data file on this machine needs to be world accessible in the first
    place, so any efforts to secure anything on the machne are wasted no matter
    what.

    > Even though your display is protected by cookies, XEvents and
    > thus keystrokes typed when entering passwords will still go
    > over the wire in clear text. It is trivial to capture these.


    It's only trivial to capture them if someone has physical access to the
    network. Since every single user with physical access to this network knows
    every password for every user on the machine, it's unlikley they would
    bother to sniff the network trying to find the passwords.

    > And I can do all that under Debian with ssh and *no* XDMCP. Really.


    Of course one can, but with multiple Windows machines on the network,
    one would be forced to create multiple ssh scripts on multiple machines. An
    XDMCP broadcast or query is much simpler.

    > Honest. Question, if I might? why are you running X on a server?


    1. It's the easiest way to manage it from a Windows machine

    2. Some of the server's utilities - the RAID array manager and the
    Galleon GUI for example - are X utilities. Indeed, once the server is set
    up and running, it's fairly unusual for the user to contact the machine
    directly except to use the Galleon GUI. The Galleon server and SMB handle
    almost all the access to the machine, but the Galleon GUI is used daily.

    > of my servers run X. That's not to say that X isn't available - it is,
    > but it isn't turned on by default. It is a waste of CPU cycles.


    Not if it isn't active, it isn't.

    > And kubuntu should be able to do everything you want. It is, afterall,
    > Debian with a pretty installer and a smaller set of packages.


    1. I prefer Debian

    2. I'd rather not have any more different versions of OS running around
    than necessary. It's bad enough I have to run Windows on some of the
    machines and that there are various different embedded Operating Systems on
    various pieces of equipment without me throwing two or three different
    distros into the mix on a whim. Not all the Linux machines are servers and
    not all the servers are Linux machines. Ditto the user workstations.



+ Reply to Thread