]> David Faure

faure@kde.org

&FDLNotice; 2001 David Faure 2001-05-02 1.05.02 &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. KTALKD talk talkd otalk ntalk ktalkdlg kcmktalkd &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. Note that &ktalkd; is designed to run on a single-user workstation, and shouldn't be run on a multi-user machine: since it reads users' configuration files, users can get the talk daemon to run any command, which is particularly dangerous. Do not use &ktalkd; if you create accounts on your machine, to people you don't fully trust. In this document, if somebody wants to talk to you, you are designated as the callee. &ktalkd; has the following features : 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 announcement If you are logged remotely (⪚ 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 folder. 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 &kcontrol; 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 To use &ktalkd;, you need a talk client. The text-based talk is available on most &UNIX; systems. Try talk your_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 &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). 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_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 (⪚ 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. 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 as &kdm; ones). The S.u.S.E &Linux; distribution includes those lines by default. Those config files are normally in a folder 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 folder. Here is what you have to do: Edit the file Xstartup, or create it, (in the xdm config folder) 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 &konsole;, nor xterm, to log the user, but to xdm and &kdm;, in my opinion. However, this will not log the user as an 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 behavior 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 the previous question, 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 the previous question, provided that you run kdm or xdm to log into X. Another solution is to make sure you always have an 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/ktalkd -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_messages When submitting a bug report, never forget to include the debugging output, but also &ktalkd;'s version number and the ./configure output. Thanks. &ktalkd; is maintained and improved by David Faure, faure@kde.org The original program was written by Robert Cimrman, cimrman3@students.zcu.cz &underFDL; &underGPL; &ktalkd; is now a core application of the &kde; project http://www.kde.org, part of the kdenetwork package. 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 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/. In order to compile and install &ktalkd; on your system, type the following in the base folder 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/ktalkd 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 On newer systems, using xinetd, there is no more /etc/inetd.conf, and you should edit or create /etc/xinetd.d/talk instead, with those lines: service talk { socket_type = dgram wait = yes user = root server = /usr/bin/ktalkd } service ntalk { socket_type = dgram wait = yes user = root server = /usr/bin/ktalkd } then restart xinetd. Please inform me of any modification you had to undertake in order to get &ktalkd; to compile or work on your platform.