hp xterm

Hi,
I've trying to get a few HP 700/RX terminal working, but I'm not very
experienced with them and I'm encountering a problem. The software is
installed over a suse 9.1 server, and the terminal connects rightly thru tftp
to the server downloading the code. However, after the whole process, the
xterm shows me the x cursor (the classical 'X') and the standard x
background, and nothing more. I mean, no login prompt, no windows are
displayed. The server is configured to accept xdmcp calls, but I cannot get
the xterm working. Any idea about? I'm running kdm as login manager.

Thanks,
Luca
--
Luca Ferrari,
fluca1978@infinito.it


-
To unsubscribe from this list: send the line "unsubscribe linux-admin" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: hp xterm

Luca Ferrari wrote:

> I've trying to get a few HP 700/RX terminal working, but I'm not very
> experienced with them and I'm encountering a problem. The software is
> installed over a suse 9.1 server, and the terminal connects rightly thru tftp
> to the server downloading the code. However, after the whole process, the
> xterm shows me the x cursor (the classical 'X') and the standard x
> background, and nothing more. I mean, no login prompt, no windows are
> displayed. The server is configured to accept xdmcp calls, but I cannot get
> the xterm working. Any idea about? I'm running kdm as login manager.

Does the X terminal use XDMCP? Is there any record (in the log files)
of an XDMCP request being sent? If not, can you observe an XDMCP
request being sent (using e.g. tcpdump)?

--
Glynn Clements
-
To unsubscribe from this list: send the line "unsubscribe linux-admin" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: hp xterm

On Friday 5 November 2004 06:11 your cat walking on the keyboard wrote:

> Luca Ferrari wrote:
> > I've trying to get a few HP 700/RX terminal working, but I'm not very
> > experienced with them and I'm encountering a problem. The software is
> > installed over a suse 9.1 server, and the terminal connects rightly thru
> > tftp to the server downloading the code. However, after the whole
> > process, the xterm shows me the x cursor (the classical 'X') and the
> > standard x background, and nothing more. I mean, no login prompt, no
> > windows are displayed. The server is configured to accept xdmcp calls,
> > but I cannot get the xterm working. Any idea about? I'm running kdm as
> > login manager.
>
> Does the X terminal use XDMCP? Is there any record (in the log files)
> of an XDMCP request being sent?

I think so, but I'm not really experienced about them. However, in the log I
found the following:



XFree86 Version 4.3.99.902 (4.4.0 RC 2)
Release Date: 18 December 2003
X Protocol Version 11, Revision 0, Release 6.6
Build Operating System: SuSE Linux [ELF] SuSE
Current Operating System: Linux lx01 2.6.4-52-default #1 Wed Apr 7 02:08:30
UTC 2004 i686
Build Date: 06 April 2004
Changelog Date: 29 February 2004
Before reporting problems, check http://www.XFree86.Org/
to make sure that you have the latest version.
Module Loader present
Markers: (--) probed, (**) from config file, (==) default setting,
(++) from command line, (!!) notice, (II) informational,
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
(==) Log file: "/var/log/XFree86.0.log", Time: Fri Nov 5 18:49:44 2004
(==) Using config file: "/etc/X11/XF86Config"
(WW) SIS(0): Failed to set up write-combining range (0xd0000000,0x2000000)
Could not init font path element /usr/X11R6/lib/X11/fonts/local, removing from
list!
Could not init font path element /usr/X11R6/lib/X11/fonts/CID, removing from
list!


and nothing in the messages. Xinetd stores only things about tftp, that seems
to work rightly. The following are my configuration files:

lx01:~ # cat /opt/kde3/share/config/kdm/kdmrc
# KDM configuration example.
# Note, that all comments will be lost if you change this file with
# the kcontrol frontend.
#
# Definition: the greeter is the login dialog, i.e., the part of KDM
# which the user sees.
#
# You can configure every X-display individually.
# Every display has a display name, which consists of a host name
# (which is empty for local displays specified in the Xservers file),
# a colon and a display number. Additionally, a display belongs to a
# display class (which can be ignored in most cases; the control center
# does not support this feature at all).
# Sections with display-specific settings have the formal syntax
# "[X-" host [":" number [ "_" class ]] "-" sub-section "]"
# You can use the "*" wildcard for host, number and class. You may omit
# trailing components; they are assumed to be "*" then.
# The host part may be a domain specification like ".inf.tu-dresden.de".
# From which section a setting is actually taken is determined by these
# rules:
# - an exact match takes precedence over a partial match (for the host part),
# which in turn takes precedence over a wildcard
# - precedence decreases from left to right for equally exact matches
# Example: display name "myhost:0", class "dpy".
# [X-myhost:0_dpy] precedes
# [X-myhost:0_*] (same as [X-myhost:0]) precedes
# [X-myhost:*_dpy] precedes
# [X-myhost:*_*] (same as [X-myhost]) precedes
# [X-*:0_dpy] precedes
# [X-*:0_*] (same as [X-*:0]) precedes
# [X-*:*_*] (same as [X-*])
# These sections do NOT match this display:
# [X-hishost], [X-myhost:0_dec], [X-*:1], [X-:*]
# If a setting is not found in any matching section, the default is used.
#
# Every comment applies to the following section or key.
# The defaults refer to KDM's built-in values, not anything set in this file.
#

[General]
# This option exists solely for the purpose of a clean automatic upgrade.
# Don't even think about changing it!
ConfigVersion=2.0
# If "false", KDM won't daemonize after startup. Note, that you needn't to
# use this if you start KDM from inittab, as KDM won't daemonize in this case
# automatically. Default is true.
#DaemonMode=false
# If the value starts with a slash (/), it specifies the file, where X-servers
# to be used by KDM are listed; the file is in the usual XDM-Xservers format.
# Otherwise it's interpreted like one line of the Xservers file, i.e., it
# specifies exactly one X-server.
# Default is ":0 local@tty1 /usr/X11R6/bin/X vt7"
# XXX i'm planning to absorb this file into kdmrc, but i'm not sure how to
# do this best.
Xservers=/etc/opt/kde3/share/config/kdm/Xservers
# Where KDM should store its PID. Default is "" (don't store)
PidFile=/var/run/kdm.pid
# Whether KDM should lock the pid file to prevent having multiple KDM
# instances running at once. Leave it "true", unless you're brave.
#LockPidFile=false
# Where to store authorization files. Default is /var/run/xauth
AuthDir=/var/lib/xdm/authdir/authfiles/
# Whether KDM should automatically re-read configuration files, if it
# finds them having changed. Just keep it "true".
#AutoRescan=false
# Additional environment variables KDM should pass on to kdm_config,
kdm_greet,
# Xsetup, Xstartup, Xsession, and Xreset. LD_LIBRARY_PATH is a good candidate;
# otherwise it shouldn't be necessary very often.
#ExportList=SOME_VAR,ANOTHER_IMPORTANT_VAR
# Where the command FiFos should be created. Make it empty to disable
# the FiFos. Default is /var/run/xdmctl
#FifoDir=/tmp
# To which group the command FiFos should belong.
# Default is -1 (effectively root)
#FifoGroup=xdmctl

[Xdmcp]
# Whether KDM should listen to XDMCP requests. Default is true.
Enable=true
# The UDP port KDM should listen on for XDMCP requests. Don't change the 177.
Port=177
# File with the private keys of X-terminals. Required for XDM authentication.
# Default is ""
#KeyFile=/opt/kde3/share/config/kdm/kdmkeys
# XDMCP access control file in the usual XDM-Xaccess format.
# Default is /opt/kde3/share/config/kdm/Xaccess
# XXX i'm planning to absorb this file into kdmrc, but i'm not sure how to
# do this best.
Xaccess=/etc/X11/xdm/Xaccess
# Number of seconds to wait for display to respond after the user has
# selected a host from the chooser. Default is 15.
#ChoiceTimeout=10
# Strip domain name from remote display names if it is equal to the local
# domain. Default is true
#RemoveDomainname=false
# Use the numeric IP address of the incoming connection instead of the
# host name. Use this on multihomed hosts. Default is false
#SourceAddress=true
# The program which is invoked to dynamically generate replies to XDMCP
# BroadcastQuery requests.
# By default no program is invoked and "Willing to manage" is sent.
Willing=/etc/X11/xdm/Xwilling

and

lx01:~ # cat /etc/X11/xdm/Xaccess
* #any host can get a login window
* CHOOSER BROADCAST #any indirect host can get a chooser


Any idea?

Luca


--
Luca Ferrari,
fluca1978@infinito.it


-
To unsubscribe from this list: send the line "unsubscribe linux-admin" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: hp xterm

Luca Ferrari wrote:

> > > I've trying to get a few HP 700/RX terminal working, but I'm not very
> > > experienced with them and I'm encountering a problem. The software is
> > > installed over a suse 9.1 server, and the terminal connects rightly thru
> > > tftp to the server downloading the code. However, after the whole
> > > process, the xterm shows me the x cursor (the classical 'X') and the
> > > standard x background, and nothing more. I mean, no login prompt, no
> > > windows are displayed. The server is configured to accept xdmcp calls,
> > > but I cannot get the xterm working. Any idea about? I'm running kdm as
> > > login manager.
> >
> > Does the X terminal use XDMCP? Is there any record (in the log files)
> > of an XDMCP request being sent?
>
> I think so, but I'm not really experienced about them. However, in the log I
> found the following:

[snip]

> and nothing in the messages. Xinetd stores only things about tftp, that seems
> to work rightly. The following are my configuration files:

> lx01:~ # cat /opt/kde3/share/config/kdm/kdmrc

> [Xdmcp]
> # Whether KDM should listen to XDMCP requests. Default is true.
> Enable=true

> Any idea?

Realistically, I think that you are going to need to use tcpdump (or
ethereal etc) to check that the terminals are actually sending out
XDMCP requests. If they aren't, no amount of server-side configuration
will have any effect.

Once you've determined that XDMCP requests are actually being sent,
you can look into the server-side configuration.

If you can't get the terminals to issue XDMCP requests, the only
solution is to forcibly manage them, by adding them to the Xservers
file. This requires that the terminals are started before xdm/kdm.

--
Glynn Clements
-
To unsubscribe from this list: send the line "unsubscribe linux-admin" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html