Conference noted::seal

    Hello,
    
       The X-windows relay capability of the telnetxd/rloginxd programs
    in the Annecy relay kit is based on a few simple assumptions.
    I am the first to admit that the way to set this up and use it is
    not super well documented, I do my best with the time I have.
    Here I will try to explain how it is supposed to work, and you can
    compare with what you are trying:
    
    X-windows ----------- Proxy   ------------------ Server "C"
     Display              System                     (with X programs
      "A"                   "B"                      for which we want
                                                     displays to go to "A")
    
       Of course, it is possible to test all this on a single machine
    (I do this routinely on my Linux laptop), but you still have to make
    sure you understand the prerequisites. I assume here we are
    doing a test with rloginxd:
    
    1. You must have rloginxd configured on "B"
       so that it will accept INCOMING rlogin connections from
       the X-display host "A" (the source host from rloginxd's
       point of view) and permit connections to host "C"
       (the DESTINATION host from rloginxd's point of view).
       This is controlled essentially by the file hosts.rloginxd,
       which is searched for by default in /usr/s4/config.
       Note that if you use host names in hosts.rloginxd, they
       must be fully qualified domain names, and rloginxd
       will try a match with what is configured based on a
       reverse lookup of the IP address involved. In other words,
       if you use hostnames, you must make sure that the proxy
       host "B" has a reasonably coherent view of the world when
       it comes to name resolution (whether you are using
       local hostfile resolution or DNS).
    
    2. The X-display host "A" MUST HAVE allowed machine "B"
       (the proxy system) to access its display (not machine "C").
       From machine C's point of view, the rlogin connection
       will appear to come from B (the proxy system), so if "C"
       has some sort of access control turned on for rlogin,
       it must allow the connection to come from B (not A!).
    
    
    3. Once all this is setup, in order to test, you must rlogin
       to the proxy system FROM the X-display host "A". The rloginxd
       program is hardwired so that (for a given session) it will
       send the displays ONLY to the IP address from which the rlogin
       connection came, not anywhere else! There is no way you can
       rlogin to the proxy system running the rloginxd utility
       and convince it to send the displays somewhere else than
       where you rlogin from (unless you modify the rloginxd source,
       of course).
    
       The idea is the whole scenario (which involves up to 3 machines),
       if permitted, must be usable by one human. The only place where
       it always makes sense for a human to be present is at the
       X-windows display, so the software is setup so that the scenario
       must be initiated BY THE display (i.e. the initial rlogin
       connection starts from there).
    
    4. Assuming you rlogin from A to B and rloginxd's setup is right,
       you will eventually get a prompt from the rloginxd program
       (unless you are using the autoconnect features). What you have
       to type in at rloginxd's prompt is:
    
         x name_of_host_c
    
       Once again, from rloginxd's point of view, the identity is
       host A (the display host) is fixed, it is where you rlogin from.
       What you specify in the "x" command is the server on which there
       are X-windows programs for which you want to send the displays
       to host "A" (the server is host C). The "name_of_host_c" string
       must be resolvable by host B:
    
          a) rloginxd will try to resolve the string typed in into
             an IP address; if this is not successful, the command fails.
             Things like the exact configuration of /etc/resolv.conf and
             /etc/svc.conf ON HOST B have an impact on what kind of
             string you can use (you may set a default domain name in
             resolv.conf, for example).
    
          b) assuming rloginxd got the IP address of the candidate host C,
             it will attempt a reverse lookup on the IP address to get
             its fully qualified domain name. If that fails, it will
             use the fake name "unknown" as the name of the address.
    
          c) rloginxd will determine if either the IP address or the
             name obtained for C are allowed as destination hosts
             (the hosts.rloginxd file format supports addresses and names).
    
          d) assuming all these checks pass, rloginxd will then verify
             if it can access the X-windows display of the IP address
             you did your rlogin FROM (that is host "A"). If that works,
             it will close the display again and proceed. That means
             rloginxd will attempt to open port 6000 on the IP address
             you did your rlogin from (that should be host "A").
    
          e) rloginxd will then allocate a virtual display number on host
             "B", tell you about it, and start the X-windows relay.
    
          f) assuming you then type "connect name_of_host_c" while at the
             rloginxd prompt, you should reach host "C". From there, in
             order to send X display information to host "A", you will have
             to set your X-window display environment variable to:
    
                  name_of_host_b:virt_display_number
    
    
        Does this help you a bit?
        Marc Chatel @ AEO
    
    
    
    
    

    Hi Mark,
    
    Tx for replying.
    
    I did all you described and X works throught the relay.
    
    However, for some reason  as soon as I type the x 'X program host'
    it keeps sending the following to the authserver.log file :
    
    Feb 20 09:57:04 localhost rloginxd[2289]: INFO TIME= 856450624 Start of
    relay
    Feb 20 09:57:04 localhost rloginxd[2289]: ALLOW TIME= 856450624 SRC=
    205.210.188.22:michelpc Access anonymous
    Feb 20 09:57:09 localhost rloginxd[2289]: ALLOW TIME= 856450629 DEST=
    205.210.190.4:nu1 GETFLAGS Connect anonymous
    Feb 20 09:57:09 localhost rloginxd[2289]: ALLOW TIME= 856450629 DEST=
    205.210.190.4:nu1 XWINDOWS Connect
    Feb 20 09:57:12 localhost rloginxd[2289]: DENY TIME= 856450632 DEST=
    127.0.0.1:localhost Incoming Connect REJECTED
    Feb 20 09:57:13 localhost rloginxd[2289]: DENY TIME= 856450633 DEST=
    127.0.0.1:localhost Incoming Connect REJECTED
    Feb 20 09:57:14 localhost rloginxd[2289]: DENY TIME= 856450634 DEST=
    127.0.0.1:localhost Incoming Connect REJECTED
    Feb 20 09:57:15 localhost rloginxd[2289]: DENY TIME= 856450635 DEST=
    127.0.0.1:localhost Incoming Connect REJECTED
    Feb 20 09:57:16 localhost rloginxd[2289]: DENY TIME= 856450636 DEST=
    127.0.0.1:localhost Incoming Connect REJECTED
    Feb 20 09:57:17 localhost rloginxd[2289]: DENY TIME= 856450637 DEST=
    127.0.0.1:localhost Incoming Connect REJECTED
    Feb 20 09:57:18 localhost rloginxd[2289]: DENY TIME= 856450638 DEST=
    127.0.0.1:localhost Incoming Connect REJECTED
    Feb 20 09:57:19 localhost rloginxd[2289]: DENY TIME= 856450639 DEST=
    127.0.0.1:localhost Incoming Connect REJECTED
    
    
    
    
    	
    
    	I looked at the code for termxd_win.c and for some reason it seems the problem
    might be caused by reverse address resolution (gethostbyaddr). I am not
    using BIND/DNS (only host file). I have removed bind for host
    resolution from svc.conf.
    
    
    Any idea what's wrong !
    
    Tx for your help. It is very appreciated.
    
    Michel baker
    DTN 621-4081

    Marc,
    
    Something strange ! When I rlogin to gatekeeper01, an rloginxd process
    is started and the process parent is inetd. If I start a virtual X
    session by typing the x command at the rloginxd prompt (thats where I
    get all the messages in the log file)....and if I then kill the
    rloginxd process started by inetd.....then a new rloginxd process is
    started BUT the process parent is now "1" . Now that I have rloginxd
    running as "1" being the parent process. I do not get these error
    messages in the log anymore and it works great !
    
    Here is the line I have in inetd.conf :
    
    login     stream  tcp  nowait   root    /usr/annecy/rloginxd     
    rloginxd -Xx
    
    Tx
    
    Michel

    Hmmm...
    
       What you describe in 1805.3 is normal, assuming you kill the
    rloginxd parent process (the one which handles the "rlogin"
    connection).
    
       It is the behavior you see in 1805.2 that freaks me out.
    When you typed the "X" command, you got a message of the kind:
    
         On the machine where the X client program is
         (host_c), you will need to set
         the DISPLAY variable to proxy_system:nnn
    
    What were the exact values displayed during testcase 1805.2
    for "host_c", "proxy_system", and "nnn". Assume "nnn" was "1".
    
    The logs you describe would APPARENTLY imply that you have a
    program on the proxy system itself that tries EVERY SECOND
    to connect to port 6000 + 1 = 6001 using the localhost address.
    rloginxd rejects such a connection as it should ....
    
    I know this sounds crazy, but would you have such a program
    running on the proxy system ??? What kind of program is it ???
    
       Regards,
       Marc Chatel @ AEO
    
    

    Hi,   
    
    The process running on the proxy system are :
    
    USER       PID  PPID %CPU STARTED  TTY             TIME COMMAND
    root         0     0  0.0   Oct 24 ??          03:30:40 [kernel idle]
    root         1     0  0.0   Oct 24 ??           3:19.51 /sbin/init -a
    root         3     1  0.0   Oct 24 ??           0:00.11 /sbin/kloadsrv
    -f
    root        19     1  0.0   Oct 24 ??          01:20:46 /sbin/update
    root       123     1  0.0   Oct 24 ??          01:26:28
    /usr/sbin/syslogd
    root       125     1  0.0   Oct 24 ??           0:00.05
    /usr/sbin/binlogd
    root       152     1  0.0   Oct 24 ??          26:49.48 /usr/sbin/gated
    root       301     1  0.0   Oct 24 ??           1:18.73 /usr/sbin/inetd
    root       306     1  0.0   Oct 24 ??           0:44.86 /usr/sbin/cron
    root       358     1  0.0   Oct 24 ??           8:23.20
    /usr/sbin/id_mond
    root       359   358  0.0   Oct 24 ??          01:03:16 id_ard -s 10 -f
    /var/ad
    root       361     1  0.0   Oct 24 ??          47:56.33 auditd -d
    root       935   301  0.0 11:04:13 ??           0:00.22 -kaou11.k
    (telnetxd)
    root      3787   301  0.0 11:02:31 ??           0:00.58 -kaou11.k
    (telnetxd)
    root      3865   301  0.0 11:18:30 ??           0:00.65 -kaou11.k
    (telnetxd)
    root      4163     1  0.0   Feb 17 ??           9:39.31 screend -s
    root      5695     1  0.0 12:15:07 ??           0:00.00 rloginxd -Xx
    root      6791     1  0.0 12:15:40 ??           0:00.12
    /usr/dfws/etc/alarmd -d
    root      6908   301  1.0 12:15:49 ??           0:00.10 -unknown
    (telnetxd)
    root     25759   301  0.0 07:46:25 ??           0:00.69 -kaou11.k
    (telnetxd)
    root     26367   301  0.0 09:12:47 ??           0:01.06 -kaou11.k
    (telnetxd)
    root     30719   301  0.0 09:25:10 ??           0:02.05 -kaou11.k
    (telnetxd)
    root     31684   301  0.0 07:07:37 ??           0:03.87 -kaou11.k
    (telnetxd)
    root     31737   301  0.0 10:51:04 ??           0:00.15 -kaou11.k
    (telnetxd)
    root     31788   301  0.0 09:13:14 ??           0:01.07 -kaou11.k
    (telnetxd)
    root     32074   301  0.0 10:38:53 ??           0:00.15 -kaou11.k
    (telnetxd)
    root     32174   301  0.0 09:43:44 ??           0:02.94 -kaou11.k
    (telnetxd)
    root     32491     1  0.0   Feb 17 ??           0:00.77 /usr/lbin/lpd
    root     32604   301  0.0 07:29:59 ??           0:06.22 -kaou11.k
    (telnetxd)
    root      3970 32341  0.0 12:15:49 console      0:00.07 ps -ef
    root     32341     1  0.0 09:42:37 console      0:01.32 -sh (sh)
    
    
    (Actually I also had xdm and httpd running, but I killed them and still
    have the same problem).
    
    Also, in 1805.2 here is the answer back from rloginxd assuming I types
    x nu1.
    
    Attempting to open your X-display "205.210.188.22:0"...
    Virtual X display allocated successfully on the gateway.
    On the machine where the X client program is
    (nu1), you will need to set
    the DISPLAY variable to "gatekeeper01:0"
    
    And right after that the firewall keeps getting the alarams...unless I
    kill the following process :
    
    root      2347  6877  0.0 12:23:08 ??           0:00.00 rloginxd -Xx
    root      6877   301  1.0 12:23:03 ??           0:00.36 rloginxd -Xx
    
    I kill (kill -KILL 6877) and then the following process appears :
    
    root      2347     1  0.0 12:23:08 ??           0:00.00 rloginxd -Xx
    
    Then if I type x nu1 again (right away after the kill)...it works fine.
    It seems like if I wait too long it does not work...
    
    
    Again, tx for your help.
    
    Michel
    
    
    
    

    Marc,
    
    I did a netstat on the proxy system :
    
    After starting the rloginxd program, I get a lot of connection to
    localhost:6000. If I kill rloginxd then I do not get the localhost:6000
    connections !!! It seems that when I have the problem a lot of
    connections are tryed to port 6000 from localhost. As soon as I stop
    the rloginxd...the port 6000 connections started to disapear.
    
    Michel
    DTN 621-4081
                

    Hi,
    
    Seems like alarmd is causing the problem. The system I used to do the
    testing has DFWU 2.0 installed and I thing it expect the firewall
    system to have a graphics console. I do not ...  and for some reason
    alarmd dies and always restarts (because of inittab) when rloginxd is
    started. 
    
    Without alarmd it work great !
    
    Michel                        

    alarmd is trying to set the monitor background colour to the current
    firewall status - you should be able to disable this behaviour by
    setting the value dfw.setcolour to FALSE in firewall.conf.
    
    Mark
    
    P.S. I have no idea why anyone would combine the AFWU with Marc's
    relays - trying to build a super product or something!

    Hello again,
    
       Happy to see the basic problems resolved. Some items to keep in
    mind:
    
    - take a good look at the manual pages rloginxd.8 and
      hosts.xd.5 to see the options available. Some are interesting.
      Some are useful. Some are neither... :-)
    
    - Install them so the customer can do a "man rloginxd"
      and "man hosts.rloginxd". There is not much documentation,
      but he/she should at least get what is there...
    
         ex. mkdir /usr/local
             mkdir /usr/local/man
             mkdir /usr/local/man/man5
             mkdir /usr/local/man/man8
             cp rloginxd.8 /usr/local/man/man8
             cp hosts.xd.5 /usr/local/man/man5
             cd /usr/local/man/man5
             ln -s hosts.xd.5 hosts.rloginxd.5
    
    - When you used the script "./Build" to compile the relays,
      make sure that at option 3 you selected "1- Plain X11 based dialog",
      especially if your customer is using Sun workstations running old
      SunOS releases. The Motif dialog variants do not work properly
      when rloginxd tries to start them on those old systems...
    
    - Assuming you gather all logs produced by "rloginxd" into a
      specific log file at regular intervals, say "rloginxd.currentlog",
      you will find you can generate somewhat useful reports by doing:
    
      grep rloginxd rloginxd.currentlog | awk -f baselog.awk > rloginxd.report
    
      baselog.awk is of course contained in the fw_relays kit
      Such reports can be easily put in a mail message, with just a bit
      of shellscript and CRON work...
    
       Regards,
       Marc Chatel @ AEO
    
    
      

Hi,


Regarding .8, as far as I know (and please correct me if I am wrong),
DFWU does not include a X relay. That is why I am using Marc's relay.
Marc's relay seems to be doing a good job now anyway.

Tx to Marc and Mark for helping in solving this problem. Very appreciated.

Michel

    I have been trying to use marc chatel's relays also, having some
    problems but might get thru them, given his latest info.
    
    As for tring to build a super product per .8?  No, trying to give the
    customers what they want, which is quite a concept, a market driven
    idea, not engineering driven.  
    
    Dan Lowry