Communicating With Users Using ntalkd And ytalk

Linh Pham <question-articles@closedsrc.org>

When you think of chat services, the first thing to that properly comes to mind is IRC or even BBS chat rooms from the days of yore. Setting up a server for IRC chat services or a BBS isn't always an easy feat nor is it very efficient for chatting with a couple of people at once. There are instant messaging services like AOL Instant Messenger, Jabber or MSN Messenger which provide a solution for sending quick messages back and forth with another person (some also have chat room facilities) but are not considered too secure. Thankfully, FreeBSD provides a service that falls in between instant messaging services and chat rooms, which provides a quick and simple solution for chatting called ntalk and using the talk or ytalk client. I will cover how to setup the ntalk dæmon, restrict access to the service and provide basic instructions on how to use both clients.

Setting Up ntalkd

The ntalk dæmon is included with any FreeBSD installation and is installed under /usr/libexec as ntalkd. Like many services available, the dæmon needs to be enabled within /etc/inetd.conf. Some machines may already have the ntalk dæmon enabled, but not all do. To enable the service, make sure that you have inetd enabled and running by adding inetd_enable="YES" or changing NO to YES if inetd_enable="NO" in /etc/rc.conf if it is already present. Once you have enabled inetd in rc.conf, find the following line in your inetd.conf file and remove the hash mark (#) from the beginning of the line:

	#ntalk  dgram   udp     wait    tty:tty /usr/libexec/ntalkd     ntalkd

and save the file. If inetd is already running, run

	kill -HUP `cat /var/run/inetd.pid`

to tell the dæmon to re-read the configuration file. If it inetd is not running, run

	/usr/sbin/inetd -wW

to start it up.

By enabling and running the inetd dæmon, you have a chance of opening your host to possible hack attempts if it is set up to run services like telnet or rsh. To help lock down access to "tcp wrapped" services and inetd dæmons, you can use the hosts.allow facility to allow and deny specific hosts or IP address ranges. You can learn more on how to setup and use hosts.allow by checking out the "HOWTO - Limiting Access to tcp wrapped Services With hosts.allow" article in this month's issue. The service name that you would want to use to restrict access to ntalk via hosts.allow is ntalkd. Since ntalk is uses the UDP protocol, some of the options in hosts.allow will not be available.

Other than that, there really isn't any configuration or tweaking that you need to do to make the service work. Simple, no?

Using The talk Clients To Chat

The talk Client

Also included with the ntalk dæmon is the simplistic talk client which allows you to chat with another user. The syntax for running the talk client is:

	talk person [ttyname]

The definition of the arguments are as follows:

person:

This can simply be the username of the person that you want to chat with if that person is on the same host as you, or in the form of user@host where host is the remote host (which can be specified as an IP address, a relative hostname, or a full qualified domain name). The remote host must be running a talk dæmon and allow your machine access to it in order to talk to someone on that remote host.

ttyname:

(Optional) If the user is logged into multiple terminals, you can direct your talk request to that specific terminal by including the full terminal device name (for example: ttyp1 if that user is logged into p1). You can find out the terminal(s) that a user is logged into by running the w command.

When you run the talk command with a proper user (and terminal name if need be), it will try to connect to the host (local or remote) and then it sends a message to the user asking them to run:

	talk your-username@your-host

You will get the same message when someone sends you a talk request. If you accidentally typed in a wrong username and/or host, or if the user or host is not available, then it will return an error message.

When you run the proper talk command and arguments, the talk client will appear on the screen with panes. The top pane is what you would type in and the bottom pane is what the remote user's response will be printed. To exit out of the client, press CTRL+C (or C-c for EMACS users, or ^C if you prefer). One of the disadvantages of the talk program is that it will only allow for a chat with one other person.

The ytalk Client

The ytalk client has one feature that is glaringly missing in the standard talk: the ability to talk to multiple people at the same time and using one instance of the client. Another feature of the ytalk client is that it includes a native X11 interface for those you who are running X Windows and want a more native looking client. ytalk is not included with the base install, but can easily be installed from the Ports collection. To install the client, run make all install within the /usr/ports/net/ytalk directory. Any specific configuration commands that you want to make should be added to the .ytalkrc in your home directory. Configuration commands that affect all users should be placed in /usr/local/etc/ytalkrc. For a detailed list of configuration commands and options, check out the man page for ytalk.

The ytalk command uses a slightly different syntax than the regular talk client. Many of which aren't really needed in most cases, but you can feel free to look at them in the ytalk(1) man page. The basic syntax of the command is:

	ytalk [-x] username ...

where -x disables the X11 interface (which is implied if the DISPLAY environment variable is not set). ytalk accepts several different syntaxes for the username argument as described below.

name:

Simply the username of the person you want to chat to, if he/she is on the same host as you are.

name#tty:

If the person is logged into multiple terminals, you can target the request to a specific by using the full terminal name (like ttyp2 in place of tty.

name@host:

This is the same as the talk client where host is the name of the remote host which the user is logged in to.

name#tty@host and name@host#tty

A combination of name#tty and name@host.

Once you have started ytalk and are placed into the client, which looks ======= Once you have started ytalk you are placed into the client, which looks >>>>>>> 1.6 fairly similar to the talk client. It will start off one pane until the person you invited joins in (or automatically splits into the appropriate number of panes if you were invited to a chat).

The ytalk client provides a pop-up menu, which is accessed and dismissed by pressing the ESC key, which allows you to invite, bump off current chat participants, or bump off any invited but not connected people; plus provide options and other commands that allow you to customize the session or be more flexible or productive when a chat suddenly gets quiet. Again, you can find out more about the options in the ytalk(1) man page. Below is a screenshot of the ytalk menu.

                          ###########################
                          #        Main Menu        #
                          #                         #
                          # a: add a user           #
                          # d: delete a user        #
                          # k: kill all unconnected #
                          # o: options              #
                          # s: shell                #
                          # u: user list            #
                          # w: output user to file  #
                          # q: quit                 #
                          ###########################

You can quit out of the client through the Main Menu or by pressing CTRL+C on the keyboard. I personally like to use ytalk when chatting with the Dæmon News crew since a conversation can start off with another person, but someone else can be requested to join or just pop in at any time without having to run multiple talk clients.

Other Notes

If you use the Pine e-mail client in a console and someone is trying to send you a talk request, the Pine e-mail client will (by default) ignore the request and will not relay it to you. You can change that behavior by going into the Pine configure screen and make sure that the option "allow-talk" under the "Advanced User Preferences" section is checked. You can also enable the option by making sure that allow-talk is listed within the feature-list option set. With the option set, talk requests will pop up in the terminal over anything being displayed by Pine.

Like many instant messaging services and IRC, all of the conversations sent to remote users will be in plain-text; therefore, it is not recommended that you send sensitive information across the wire without some sort of encryption. One way to workaround this limitation, you can SSH into a server that has both the dæmon installed and the client and start your conversation from there. The other user(s) should either be located directly on that host via a console or SSH'd into the host to keep the conversation data from being sent outside of the talk host without any form of encryption. I haven't tried to use any form of SSH port forwarding to connect to remote talk hosts, though I'm not sure if it would work since the talk service uses the UDP protocol instead of TCP.

If you want to make the talk service available from a talk host behind a firewall available to the public Internet, you will need to let UDP port 518 through. According to the /etc/services file that came from 4.6-RC, it shows that ntalk also uses the TCP port 518 as well, but I'm not quite sure if it that is correct or not.

Conclusion

Although ntalk doesn't provide luxury features like file uploads and downloads, cute little graphical emoticons, or other features integrated into their respective portals or network as AOL Instant Messenger or IRC, it does provide a lightweight and very simple way of chatting with your friends, co-workers, or other people without having to run graphical or bloated text console clients. Instead, it stays true to the way many Unix utilities and programs are (and should be written): each program should be as simple as possible without unneeded bells and whistles.

Linh Pham [ closedsrc.org | question-articles@closedsrc.org ]