# The ktalkd Handbook

David
Faure

    faure@kde.org

14/11/1998
0.09.00

This handbook describes ktalkd version 0.9.0

KTALKD
kotalkd
talk
talkd
otalk
ntalk
ktalkdlg
kcmktalkd

## Introduction

`ktalkd` is an enhanced talk daemon - a program to handle incoming talk requests, announce them and allow you to respond to it using a talk client.

GLOSSARY : In this document, if somebody wants to talk to you, you are designated as the "callee".

`ktalkd` has the following features :

KDE or not KDE

  That is the question. :) More seriously, this means that `ktalkd` is able to be compiled with or without KDE support. To use it without KDE, the compilation stage will detect if X or Qt or KDE is not installed, but you can force a non-KDE daemon if you use the configure option '--without-X'.

Answering machine

  If the callee isn't logged on, or doesn't answer after the second announcement, an answering machine is launched, takes the message, and mails it to the callee.

Sound

  If desired, a sound is played with the announcement.

X Announce

  If compiled with KDE installed, ktalkd will use ktalkdlg, a KDE dialog, for announcement. If ktalk is running, it will be asked to make the announcement itself. (New since 0.8.8).

Multiple displays annoucement

  If you are logged remotely (e.g. with an `"export DISPLAY=..."` command), the X announcement will be made on this display too. Answer on the one you want ! If you're also logged in a text terminal, and if you're NOT using xterms (internal restriction), then you'll see a text announcement too, in case you're using the text terminal at the time of the announcement.

Forwarding (New since 0.8.0)

  You can set up a forward to another user even to another host if you're away. There are 3 different forwarding methods. See section 'Usage'.

Configuration

  If ktalkd is compiled for KDE, it reads config from KDE config files, the sitewide ($KDEDIR/share/config/ktalkdrc) and the user one, in its home directory. The sitewide one has to be manually edited by the administrator, but there is now a configuration dialog for the user one. It's called kcmktalkd and can be found in the KDE Control Center after installing `ktalkd`. On non-KDE systems, `ktalkd` will read /etc/talkd.conf.

Internationalization

  Under KDE, the announcement will be in your language provided that you set it in the KDE menus and that someone translated ktalkdlg to your language. The same goes for the configuration dialog, kcmktalkd.

Support for otalk and ntalk (New since 0.8.1)

  ktalkd now supports both protocols, even when forwarding. ktalk supports both protocols as well.

I hope you will enjoy this talk daemon,

David Faure

faure@kde.org

## Supported Platforms

RedHat Linux 5.x

  My development platform. Fully tested on it.

Other Linux, BSD

  Should compile and run well.

Solaris

  It won't work until somebody makes a replacement for snprintf. Of course, one should be able to install another libc to solve this...

AIX

  I've heard about problems about localtime, ctime, and assorted functions.

I would be glad to receive comments about compiling and running `ktalkd` on those and other systems.

## Installation

### How to obtain ktalkd

`ktalkd` is now a core application of the KDE project http://www.kde.org, part of the kdenetwork package.

But you can always download the latest `ktalkd` from the main ftp site of the KDE project, ftp://ftp.kde.org/pub/kde and from its mirrors. It's usually found in ftp://ftp.kde.org/pub/kde/stable/latest/apps/network

### Requirements

In order to successfully compile `ktalkd`, you need the latest versions of the KDE libraries as well as the Qt C++ library. All required libraries as well as ktalkd itself can be found on ftp://ftp.kde.org/pub/kde/.

### Compilation and installation

In order to compile and install `ktalkd` on your system, type the following in the base directory of the `ktalkd` distribution:

    % ./configure
    % make
    % make install

As `ktalkd` is a daemon, `make install` will require root privileges.

Don't forget to update /etc/inetd.conf. For example, on a linux system, if kde is in /opt/kde, change the lines concerning talk and ntalk to :

    talk   dgram   udp     wait    root    /usr/sbin/tcpd  /opt/kde/bin/kotalkd
    ntalk  dgram   udp     wait    root    /usr/sbin/tcpd  /opt/kde/bin/ktalkd

A script is provided, to make the necessary change automatically. Update your inetd.conf file just by running

    % ./post-install.sh

Anyway, you'll have to restart inetd after this. On most Linux systems, do :

    % killall -HUP inetd

Please inform me of any modification you had to undertake in order to get `ktalkd` to compile on your platform.

## Usage

To use ktalkd, you need a talk client. The text-based `talk` is available on most Unix systems. Try `talk your&lowbar;username` to see what happens when you receive a talk request. You can also try the answering machine the same way : initiate a talk to yourself, ignore the announcement twice, and you'll see the answering machine.

There is a talk client with a graphical interface for the KDE, `ktalk`. It's not yet shipped with KDE packages, but you can find it on ftp://ftp.kde.org. It should be in ftp://ftp.kde.org/pub/kde/stable/latest/apps/network

The announcement dialog box is trivial : respond or ignore.

The configuration dialog should be rather straight forward, except for setting up a forward to another user (or even to another host).

### Choosing a Forwarding Method

None is perfect, they all have pros (+) and cons (-).

FWA : Forward announcement only. Direct connection. Not recommended.

- (+) You know who the caller is, but

- (-) Caller will have to respond to an announcement from you. Annoying.

- (-) Don't use if you have an answering machine on your 'away' location. (The answering machine can't popup an announcement, it would be confusing!)

FWR : Forward all requests, changing info when necessary. Direct connection.

- (+) Caller won't know that you're away, but

- (-) You won't really know who the caller is - only his username, (so you might see "talk from Wintalk@my&lowbar;host")

FWT : Forward all requests and take the talk. No direct connection.

- (+) Same as above, but also works if you and caller can't be in direct contact one with the other (e.g. firewall).

- (+) You'll be told who's really talking to you when you accept the talk

- (-) But as in FWR, you won't know his machine name in the announcement

In short, use FWT it you want to use it behind a firewall (and if ktalkd can access both networks), and FWR otherwise.

## Questions and Answers

### Why Doesn't Root Receive KDE Announcements ?

Because this would be security hole, with the current user detection. You can bypass the limitation by adding two lines in xdm config files (which are the same than kdm ones). Note : the S.u.S.E linux distribution includes those lines by default.

Those config files are normally in a directory such as /etc/X11/xdm, or /usr/X11R6/lib/X11/xdm on other systems. The following supposes that they are in /etc/X11/xdm, so you might have to translate them for another directory.

Here is what you have to do : Edit the file Xstartup, or create it, (in the xdm config directory) so that it reads :

    #!/bin/sh
    /etc/X11/xdm/GiveConsole
    sessreg -a -l $DISPLAY -x /etc/X11/xdm/Xservers $USER

and the file Xreset so that it reads :

    #!/bin/sh
    /etc/X11/xdm/TakeConsole
    sessreg -d -l $DISPLAY $USER

Make sure that xdm-config make reference to those two files:

    DisplayManager._0.startup:      /etc/X11/xdm/Xstartup
    DisplayManager._0.reset:        /etc/X11/xdm/Xreset

This will make kdm (or xdm) log the user into utmp, which is the right thing to do. It's not up to kvt, nor xterm, to log the user, but to xdm and kdm, in my opinion. However, this will not log the user as a X user when using startx... Any hint about that ?

### Why Don't I, as a Normal User, Receive KDE Announcements ?

If you're running a linux system (with /proc enabled), this behaviour is a bug. Please send me a description of it so that I correct it.

If you're running linux 2.0.35, this is a known bug in the kernel, which doesn't let root read /proc. The solution is the same as in section 5.1, provided that you run kdm or xdm to log into X. Or upgrade !

Otherwise, this is normal : ktalkd can't find the user, as KDE doesn't log him into utmp and the linux based (/proc) detection is disabled. The solution is the same as in section 5.1, provided that you run kdm or xdm to log into X. Another solution is to make sure you always have a xterm running.

### How Do I Get Debug Output from Ktalkd ?

As it is a daemon, there is no debug output on standard output. To get debugging output (for instance before submitting me a bug report !), update the lines in inetd.conf which launches ktalkd and kotalkd to be :

    talk   dgram   udp     wait    root    /usr/sbin/tcpd  /opt/kde/bin/kotalkd -d
    ntalk  dgram   udp     wait    root    /usr/sbin/tcpd  /opt/kde/bin/ktalkd -d

(notice the -d option)

Then edit /etc/syslog.conf to add the following line :

    *.*         /var/log/all_messages

To make it work, you then have to restart inetd and syslogd :

    % killall -HUP inetd
    % killall -HUP syslogd

Finally, run a talk session and see the result in /var/log/all&lowbar;messages

When submitting a bug report, never forget to include the debugging output, but also ktalkd's version number and the "./configure" output. Thanks.

## Copyright

ktalkd is maintained and improved by David Faure, faure@kde.org

The original program was written by Robert Cimrman, cimrman3@students.zcu.cz

    ktalkd is Copyright 1997,1998 David Faure, faure@kde.org

    This program is free software; you can redistribute it and/or modify
    it under the terms of the GNU General Public License as published by
    the Free Software Foundation; either version 2 of the License, or
    (at your option) any later version.

    This program is distributed in the hope that it will be useful,
    but WITHOUT ANY WARRANTY; without even the implied warranty of
    MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
    GNU General Public License for more details.

    You should have received a copy of the GNU General Public License
    along with this program; if not, write to the Free Software
    Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.