# talk + ytalk won't work[SOLVED]

## EasterParade

Hi all,

I don't do chat but I would like to have a lan messenger. Xinetd is running on both boxes on my lan but talk says 

```
Error on read daemon. Connection refused
```

 and ytalk thinks there is no talk daemon running on either system.

I know that talk is practically dead and ytalk depends on the same daemon. Since telnet isn't used any more for good reasons and logging on to another machine in a lan runs via openssh ( works well on my lan ) messaging within a local lan isn't as easy as is once was. But there just has to be a way to chat within a lan without the use of any irc channel or outside service.

So either I've misconfigured xinetd or any other config file for my lan or there just is no way to chat on a lan any more. For instance where do I make the other hosts within a lan known to my system? 

My xinetd.conf:

```
# Define general logging characteristics.

        log_type        = SYSLOG daemon info

        log_on_failure  = HOST

        log_on_success  = PID HOST DURATION EXIT

# Define access restriction defaults

#

#       no_access       =

        only_from       = localhost

#       max_load        = 0

        cps             = 50 10

        instances       = 50

        per_source      = 10

# Address and networking defaults

#

#       bind            =

#       mdns            = yes

        v6only          = no

# setup environmental attributes

#

#       passenv         =

        groups          = yes

        umask           = 002

```

My /etc/xinetd.d/talk:

```
# default: off

# description: The talk server accepts talk requests for chatting with users \

#       on other systems.

service ntalk

{

#       flags                   = IPv4

        disable                 = yes

        socket_type             = dgram

        wait                    = yes

        user                    = nobody

        group                   = tty

        server                  = /usr/sbin/in.talkd

}

```

In /etc/xinetd.d/ there is an rlogin file. But isn't rlogin disabled by openssh? 

I'm greatful for any insight and suggestion.

transsibLast edited by EasterParade on Thu Mar 26, 2009 2:56 pm; edited 2 times in total

----------

## smerf

you should have: disable = no

there should be some xinetd process listening on ntalk port 518 udp (netstat -lup)

----------

## EasterParade

 *Quote:*   

> you should have: disable = no 

 

I now have, thank you.

```
# netstat -lup

Aktive Internetverbindungen (Nur Server)

Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name

udp        0      0 *:ntalk                 *:*                                24774/xinetd
```

Doesn't say which port.

What about squid? Could squid block access within a local network?

 *Quote:*   

> there should be some xinetd process listening on ntalk port 518 udp

 

I am dumb   :Sad:   but in which file?

Changing disable from yes to no and restarting xinetd ( the talk daemon ) alone didn't work. Ytalk still complains about no talk daemon on localhost and no on remote box.

Thanks for your answer.

EDITIn /etc/services I've found th following lines:

```
talk            517/tcp                         # like tenex link

talk            517/udp

ntalk           518/tcp

ntalk           518/udp

```

----------

## smerf

 *transsib wrote:*   

> Doesn't say which port.

 

No, it does.

 *transsib wrote:*   

> What about squid? Could squid block access within a local network?

 

No, firewall is much more likely.

 *transsib wrote:*   

> Changing disable from yes to no and restarting xinetd ( the talk daemon ) alone didn't work. Ytalk still complains about no talk daemon on localhost and no on remote box.

 

```
talk            517/tcp                         # like tenex link

talk            517/udp

ntalk           518/tcp

ntalk           518/udp

```

I use 'talk' only and it is happy with ntalk port... try that before ytalk.

----------

## EasterParade

 *Quote:*   

> No, firewall is much more likely. 

 

Firewall is on gateway router but there is a specialty here due to cable length and such: one box' lan cable goes into a D-Link switch which goes into our gateway router. The other box has a direct cable into the gateway. 

Talk now doesn't complain on either box except for the message 

```
No connection yet
```

. The firewall on the gateway router takes care of the outside world. It shouldn't block lan traffic, unless I'm mistaken. Am I?   :Sad: 

Thanks for taking care.   :Smile: 

----------

## smerf

Does it work on the same machine where talk server is?

I mean sth like on tty1: ytalk user#tty2 and on tty2: ytalk user@tty1

----------

## smerf

Just noticed: I hope that you have changed only_from = localhost too (on all machines)  :Wink: 

----------

## EasterParade

That's where the difficulty starts or my lack of knowledge about networking takes over. My mistake may be ridiculously easy to find for experienced people.

Each computer within the lan has its own IP as well as the gateway-router which is nameserver in /etc/resolv.conf ( and the printer ) - tcp to the internet not dhcp -

One box has to be server?

But up to now I thought it was enough if each box on the lan has the daemon running for talk to work. And /etc/xinetd.d/talk says server is /usr/sbin/in.talkd.

Each box within the lan has its own IP. On the console of my box I type 

```
talk user@his_ip
```

 ( without tty# ). Up to now I was convinced this would suffice. It obviously doesn't. 

It is obvious that I haven't fully understood the chemistry of networking yet   :Sad:  ! I am confused - it should be as easy as a walk in the park but for me it isn't.

greetings

----------

## smerf

Okay, so can you communicate via talk on single machine or not?

ytalk(1) says:

 *Quote:*   

>        The username field may be formatted in several different ways:
> 
>             name          - some user on your machine
> 
>             name@host     - some user on a different machine
> ...

 

I want you to simply test localhost connectivity, forget about LAN for now.

----------

## EasterParade

Forgetting about lan is a good idea. Let's take my box. I have two users: root and user. If root wants to talk to user, talk says 

```
No Connection yet
```

 If root wants to ytalk to user, ytalk says 

```
no talk daemon on xy@localhost
```

Which means I can't even talk to myself on my own box    :Very Happy:  .

----------

## NeddySeagoon

transsib,

I use talk to talk among users logged into my ssh server.

Its xinetd.conf is

```
# Define access restriction defaults

#

#       no_access       =

#       only_from       = localhost

        only_from       = 192.168.0.0

#       max_load        = 0

        cps             = 50 10

        instances       = 50

        per_source      = 10

# Address and networking defaults

#

#       bind            =

#       mdns            = yes

        v6only          = no

# setup environmental attributes

#

#       passenv         =

        groups          = yes

        umask           = 002
```

only_from       = 192.168.0.0 allows connections from other machines in my network but I've not tested that.

/etc/xinetd.d/talk contains 

```
#default: off

# description: The talk server accepts talk requests for chatting with users \

#       on other systems.

service ntalk

{

#       flags                   = IPv4

#       disable                 = yes

        disable                 = no

        socket_type             = dgram

        wait                    = yes

        user                    = nobody

        group                   = tty

        server                  = /usr/sbin/in.talkd

```

Something has changed on me though, it used to connect with talk <user>, now in needs talk user@fqdn.

----------

## EasterParade

 *Quote:*   

> I use talk to talk among users logged into my ssh server. 

 

SSH seems to be the key to all this. If I ssh to user@remotehost on my lan I am on his console. I then act practically as this remote host on a console of the remote machine. How could I talk to that host? How could talk work in this environment if I can't talk to "myself" on my own box? On the other box I have the same error messages.

I have changed the xinetd.conf now according to Neddys proposal and restarted the service but nothing considerable has changed. 

Now I'm really confused and since the other system is offline now ( he lost interest   :Sad:   ) I'll let it settle and keep on working tomorrow.

Thanks to all of you.

transsib

----------

## smerf

What is in xinetd logs? You may have wrong dns/hosts setup. Post your /etc/hosts and 'hostname --fqdn' output.

Make sure, that in your xinetd.conf you have at least: only_from = localhost [ip_that_your_hostname_resolves_to]

----------

## EasterParade

I only have this in /var/log/messages :

```
Mar  7 11:17:29 aldebaran xinetd[3260]: Reading included configuration file: /etc/xinetd.d/chargen-dgram [file=/etc/xinetd.conf

] [line=50]

Mar  7 11:17:29 aldebaran xinetd[3260]: Reading included configuration file: /etc/xinetd.d/chargen-stream [file=/etc/xinetd.d/c

hargen-stream] [line=67]

Mar  7 11:17:29 aldebaran xinetd[3260]: Reading included configuration file: /etc/xinetd.d/cvspserver [file=/etc/xinetd.d/cvsps

erver] [line=67]

Mar  7 11:17:29 aldebaran xinetd[3260]: Reading included configuration file: /etc/xinetd.d/daytime-dgram [file=/etc/xinetd.d/da

ytime-dgram] [line=14]

Mar  7 11:17:29 aldebaran xinetd[3260]: Reading included configuration file: /etc/xinetd.d/daytime-stream [file=/etc/xinetd.d/d

aytime-stream] [line=67]

Mar  7 11:17:29 aldebaran xinetd[3260]: Reading included configuration file: /etc/xinetd.d/discard-dgram [file=/etc/xinetd.d/discard-dgram] [line=67]

Mar  7 11:17:29 aldebaran xinetd[3260]: Reading included configuration file: /etc/xinetd.d/discard-stream [file=/etc/xinetd.d/discard-stream] [line=67]

Mar  7 11:17:29 aldebaran xinetd[3260]: Reading included configuration file: /etc/xinetd.d/echo-dgram [file=/etc/xinetd.d/echo-dgram] [line=67]

Mar  7 11:17:29 aldebaran xinetd[3260]: Reading included configuration file: /etc/xinetd.d/echo-stream [file=/etc/xinetd.d/echo-stream] [line=67]

Mar  7 11:17:29 aldebaran xinetd[3260]: Reading included configuration file: /etc/xinetd.d/ftp-sensor [file=/etc/xinetd.d/ftp-sensor] [line=67]

Mar  7 11:17:29 aldebaran xinetd[3260]: Reading included configuration file: /etc/xinetd.d/git-daemon [file=/etc/xinetd.d/git-daemon] [line=70]

Mar  7 11:17:29 aldebaran xinetd[3260]: Reading included configuration file: /etc/xinetd.d/rexec [file=/etc/xinetd.d/rexec] [line=13]

Mar  7 11:17:29 aldebaran xinetd[3260]: Reading included configuration file: /etc/xinetd.d/rlogin [file=/etc/xinetd.d/rlogin] [line=12]

Mar  7 11:17:29 aldebaran xinetd[3260]: Reading included configuration file: /etc/xinetd.d/rsh [file=/etc/xinetd.d/rsh] [line=12]

Mar  7 11:17:29 aldebaran xinetd[3260]: Reading included configuration file: /etc/xinetd.d/smb [file=/etc/xinetd.d/smb] [line=12]

Mar  7 11:17:29 aldebaran xinetd[3260]: Reading included configuration file: /etc/xinetd.d/talk [file=/etc/xinetd.d/talk] [line=12]

Mar  7 11:17:29 aldebaran xinetd[3260]: Reading included configuration file: /etc/xinetd.d/tcpmux-server [file=/etc/xinetd.d/tcpmux-server] [line=14]

Mar  7 11:17:29 aldebaran xinetd[3260]: Reading included configuration file: /etc/xinetd.d/time-dgram [file=/etc/xinetd.d/time-dgram] [line=68]

Mar  7 11:17:29 aldebaran xinetd[3260]: Reading included configuration file: /etc/xinetd.d/time-stream [file=/etc/xinetd.d/time-stream] [line=67]

Mar  7 11:17:29 aldebaran xinetd[3260]: removing chargen

Mar  7 11:17:29 aldebaran xinetd[3260]: removing chargen

Mar  7 11:17:29 aldebaran xinetd[3260]: removing cvspserver

Mar  7 11:17:29 aldebaran xinetd[3260]: removing daytime

Mar  7 11:17:29 aldebaran xinetd[3260]: removing daytime

Mar  7 11:17:29 aldebaran xinetd[3260]: removing discard

Mar  7 11:17:29 aldebaran xinetd[3260]: removing discard

Mar  7 11:17:29 aldebaran xinetd[3260]: removing echo

Mar  7 11:17:29 aldebaran xinetd[3260]: removing echo

Mar  7 11:17:29 aldebaran xinetd[3260]: removing ftp

Mar  7 11:17:29 aldebaran xinetd[3260]: removing git-daemon

Mar  7 11:17:29 aldebaran xinetd[3260]: removing exec

Mar  7 11:17:29 aldebaran xinetd[3260]: removing login

Mar  7 11:17:29 aldebaran xinetd[3260]: removing shell

Mar  7 11:17:29 aldebaran xinetd[3260]: removing microsoft-ds

Mar  7 11:17:29 aldebaran xinetd[3260]: removing tcpmux

Mar  7 11:17:29 aldebaran xinetd[3260]: removing time

Mar  7 11:17:29 aldebaran xinetd[3260]: removing time

Mar  7 11:17:29 aldebaran xinetd[3260]: xinetd Version 2.3.14 started with libwrap loadavg options compiled in.

Mar  7 11:17:29 aldebaran xinetd[3260]: Started working: 1 available service

```

----------

## smerf

No logs from connection attempt? What about the rest of my question?

----------

## EasterParade

 :Smile:   *Quote:*   

> No logs from connection attempt? 

 

Nope...

 *Quote:*   

> What about the rest of my question?

 

/etc/hosts :

```
# /etc/hosts: Local Host Database

#

# This file describes a number of aliases-to-address mappings for the for

# local hosts that share this file.

#

# In the presence of the domain name service or NIS, this file may not be

# consulted at all; see /etc/host.conf for the resolution order.

#

# IPv4 and IPv6 localhost aliases

127.0.0.1       aldebaran.localhost     aldebaran       localhost

::1             localhost

192.168.0.2     server

#

# Imaginary network.

192.168.x.x               hostname1.localhost

192.168.x.x               hostname2.localhost

#

# According to RFC 1918, you can use the following IP networks for private

# nets which will never be connected to the Internet:

#

#       10.0.0.0        -   10.255.255.255

#       172.16.0.0      -   172.31.255.255

#       192.168.0.0     -   192.168.255.255

#

# In case you want to be able to connect directly to the Internet (i.e. not

# behind a NAT, ADSL router, etc...), you need real official assigned

# numbers.  Do not try to invent your own network numbers but instead get one

# from your network provider (if any) or from your regional registry (ARIN,

# APNIC, LACNIC, RIPE NCC, or AfriNIC.)

#

```

```
# hostname --fqdn

aldebaran.localhost

```

I don't think this will help. SSH works perfectly both ways. Logged in to the remote host on my LAN I try to "talk" with the same result as on or from my own: 

```
No Connection yet -- Checking on invitation on caller's machine
```

Since my significant other has lost interest because I've promised fast success ( I shouldn't have done that   :Laughing:  ) but couldn't deliver I've come to the conclusion to put a lid on the matter and read up on networking. May be I am just too n00bish for things like this.

Thanks to both helpers 

transsib

----------

## NeddySeagoon

transsib,

Do

```
talk transsib@aldebaran.localhost
```

 on aldebaran while you are logged in as transsib.

It would be good to have two shells open. talkd is certainly running.

----------

## smerf

Okay, I just installed talk/ytalk on my desktop and laptop - compare with your setup (both machines, files should be identical):

/etc/hosts

```
127.0.0.1   localhost

::1      localhost

192.168.1.1 router

192.168.1.2 desktop

192.168.1.3 laptop
```

/etc/xinetd.conf

```
defaults

{

   log_type   = SYSLOG daemon info 

   log_on_failure   = HOST

   log_on_success   = PID HOST DURATION EXIT

   only_from   = localhost 192.168.1.0/24

   cps      = 50 10

   instances   = 50

   per_source   = 10

   v6only   = no

   groups   = yes

   umask      = 002

}

includedir /etc/xinetd.d
```

/etc/xinetd.d/talk

```
service ntalk

{

   disable      = no

   socket_type      = dgram

   wait         = yes

   user         = nobody

   group         = tty

   server      = /usr/sbin/in.talkd

}
```

Now, local connection:

two xterminals, pts/4 calls the same user on pts/5:

```
ytalk lukasz@desktop#pts/5
```

on pts/5:

```
lukasz@desktop ~ $ tty

/dev/pts/5

lukasz@desktop ~ $ 

                                               

Message from Talk_Daemon@desktop at 20:24 ...  

talk: connection requested by lukasz@desktop.  

talk: respond with:  talk lukasz@desktop    
```

then remote:

on laptop: ytalk lukasz@desktop

and here's invitation on desktop:

lukasz@desktop ~ $ 

Message from Talk_Daemon@desktop at 20:28 ...      

talk: connection requested by lukasz@laptop.  

talk: respond with:  talk lukasz@laptop       

If you want to be specific (and sure, that invitation will appear on right console add its name after #).

Log entry: Mar  7 20:44:24 desktop xinetd[13609]: START: ntalk pid=13775 from=192.168.1.3

This is datagram service, so expect delays when connecting, sometimes this may be reported

as lack of talk server, depending on host/dns configuration there can be client name mismatches

reported (unexpected client name). For testing you may want to enable access from all networks.

Remember to allow writes to your terminal (mesg y).

The setup above was created in less than 5 minutes, two changes in config files and less than 10 commands

including emerge, starting xinetd and testing... should be easy, this is not very sophisticated protocol  :Wink: 

----------

## EasterParade

 *Quote:*   

> The setup above was created in less than 5 minutes, two changes in config files and less than 10 commands
> 
> including emerge, starting xinetd and testing... should be easy, this is not very sophisticated protocol 

 

I agree which is why I've promised fast delivery   :Confused: 

@NeddySeagoon

```
#       only_from       = localhost

        only_from       = 192.168.0.0 
```

I`ve tested xinetd with several configs here. I've tried out smerfs config as well but all this running in circles has even thrown me back behind the line where talk only says No Connection yet. Now it is Connection refused again. 

```
talk <user>@aldebaran.localhost
```

 returns the same message.

I'll certainly not give up but more tries result in more setbacks at the moment. I really don't understand - should be a piece of cake. I feel soooo dumb   :Embarassed: 

greetings from transsib

----------

## NeddySeagoon

transsib,

When you change xinetd.conf you do restart the service ?

Thats not required with talkd.conf as xinetd starts a new instance with every connection attempt.

Did you get my PM ?

----------

## EasterParade

 *Quote:*   

> When you change xinetd.conf you do restart the service ? 

 

Yes, I always restart the service after changing xinetd.conf.

 *Quote:*   

> Did you get my PM? 

 

No, I saw that I've recieved a PM but when I tried to read it I came back to the forum overview. 

Spooky   :Laughing:   or I'm completely gaga - hm well, nothing new about this.

My xinetd.conf looks like this now:

```
#       enabled         =

        disabled        = no

# Define general logging characteristics.

#       log_type        = SYSLOG daemon info

        log_on_failure  = HOST

        log_on_success  = PID HOST DURATION EXIT

# Define access restriction defaults

#

#       no_access       =

        only_from       = 192.168.0.0/24

#       max_load        = 0

        cps             = 50 10

        instances       = 50

        per_source      = 10

# Address and networking defaults

#

#       bind            =

#       mdns            = yes

        v6only          = no

# setup environmental attributes

#

#       passenv         =

        groups          = yes

        umask           = 002

```

Restarted service and achieved at least that talk merely says No Connection yet. No "Connection refused" any more when I do:

```
talk <user>/dev/pts/2
```

I am testing talk on one machine only at the moment before I bug my loved one again about this   :Laughing: 

----------

## smerf

Why are you blocking localhost from connecting to your service?

I fail to understand, why are you trying to type "ytalk <user>/dev/pts/2" - read manual or one of my earlier posts, PLEASE!  :Wink: 

(with this you are trying to call user named '<user>/dev/pts/2', rather funny name I would say)

If you want to use 'talk' instead of 'ytalk' there should be space between <user> and <tty>. It should be a tty NAME, not DEVICE (see my prev post).

----------

## EasterParade

Doesn`t make much of a difference. Changed only_from to localhost again, restarted xinetd und tried:

```
ytalk <user>@aldebaran#pts/2
```

Message from ytalk was no talk daemon on aldebaran.localhost.

----------

## smerf

 *transsib wrote:*   

> Doesn`t make much of a difference. Changed only_from to localhost again.

 

Why? I asked you not to block localhost and not to block everything which does not originate from localhost...

For testing it is much better to be as permissive as possible, just like in my test setup: only_from = localhost 192.168.0.0/24

Make sure that you have enabled logging (please, please, take a look at my configs: log_type = SYSLOG daemon info).

Now, do echo whatever > /dev/udp/$H/518 instead $H use localhost and your_hostname. In logs you should see something like (for localhost):

xinetd[PID1]: START: ntalk pid=PID2 from=127.0.0.1

talkd[PID2]: localhost (127.0.0.1): unintelligible packet

PID1 is your xinetd and PID2 is forked in.talkd process. This will make us sure, that datagrams reach its destination.

----------

## NeddySeagoon

transsib,

If everyone is logged onto the same machne, normally, 

```
talk <user>
```

is enough, you need not specify the pts.

If the user has several pts open, as you do when you try to talk to yourself, talk will connect to the second pts, which is sensible.

I suspect my /etc/hosts is in mess which is why I need 

```
talk user@fqdn
```

 just now.

I have a feeling its my fault you coudn't read the PM.  My sent box was full.

----------

## smerf

NeddySeagoon:

Talking to yourself require specifying terminal, because talk will write to most recently used terminal

(which obviously is the one where you said 'talk yourself') and invitation will mess up your talk screen.

EDIT: at least as far as I understand how it works... anyway, I have to use #tty to avoid getting invitation

on the same tty. If you are fast enough you can switch ttys, type something and get invitation on another tty.

Depending on your hosts/dns (that's why I asked transsib about this) your request may originate from

localhost (127.0.0.1) or `hostname` (address_of_another_interface). This may be something alse than

you may have expected (that's why I want to be permissive and allow BOTH localhost and whole network).

The next step IMO should be tcpdump dst port 518 - we want to be really sure which interface is used  :Wink: 

(it is still unclear why there are no log entries... sending bogus datagram must generate some log, if not

we will know, that there is something wrong with logger or transsib did not turned xinetd logging on yet...)

----------

## EasterParade

 *Quote:*   

> I have a feeling its my fault you coudn't read the PM

 

It`s ok now; I`ve read your message and sent an answer.

My /etc/hosts...I remember that I had to configure it the way it is now, except for the imaginary network which may be wrong like it is now:

```
# /etc/hosts: Local Host Database

#

# This file describes a number of aliases-to-address mappings for the for

# local hosts that share this file.

#

# In the presence of the domain name service or NIS, this file may not be

# consulted at all; see /etc/host.conf for the resolution order.

#

# IPv4 and IPv6 localhost aliases

127.0.0.1       aldebaran.localhost     aldebaran       localhost

::1             localhost

192.168.0.2     server

#

# Imaginary network.

192.168.0.2               aldebaran.localhost

192.168.0.7               runaway.localhost

192.168.0.100             gateway

192.168.0.10              hp1320n

```

It is a while that I`ve configured phpmyadmin, apache and mysql but I remember having had difficulties resulting from the definition of localhost on my system. I don`t remember though how I have solved these problems. 

```
talk <user>
```

returns the usual:

```
No connection yet
```

      and

```
[Checking for invitation on caller's machine]
```

@smerf

 *Quote:*   

> (it is still unclear why there are no log entries... sending bogus datagram must generate some log, if not
> 
> we will know, that there is something wrong with logger or transsib did not turned xinetd logging on yet...)
> 
> 

 

I`m not sure about this either:

```
# Define general logging characteristics.

#       log_type        = SYSLOG daemon info

        log_on_failure  = HOST

        log_on_success  = PID HOST DURATION EXIT

```

Is logging turned on or not? I`ve changed the log_type entry once which both returned an error message about this in /var/log/messages but also some information about xinetd as well:

```
 Bad log_on_failure flag: RECORD [file=/etc/xinetd.conf] [line=19]

Mar  8 12:23:28 aldebaran xinetd[3254]: A fatal error was encountered while parsing the default section. xinetd will exit.

Mar  8 12:23:28 aldebaran xinetd[3254]: Exiting...
```

```
Mar  8 12:25:28 aldebaran [  150.599039] process `talk' is using obsolete setsockopt SO_BSDCOMPAT

```

----------

## smerf

You should not setup `hostname` to resolve to 127.0.0.1 on network-enabled machine.

(that's my personal opinion, IMO this only leads to problems that are usually hard to trace)

----------

## EasterParade

 *Quote:*   

> You should not setup `hostname` to resolve to 127.0.0.1 on network-enabled machine.
> 
> (that's my personal opinion, IMO this only leads to problems that are usually hard to trace)

 

As I said it may already have lead to problems especially for mysql which I have solved because these were known problems. But I remember that this was recomended years ago by a howto for Gentoo /etc/hosts - not 2003 when I first installed Gentoo on my box but much later on some update or other. I haven`t changed it since then; didn`t want to touch it. If you change too much problems that might arise because of changes like these may also be even harder to trace than before the change.

----------

## smerf

I must admit, my /etc/hosts was always full of workarounds and sometimes really messed up...

----------

## EasterParade

It may be messed up, my /etc/hosts but I am not sure about that until someone more experienced tells me so. And I would rather not fiddle around with it. I`d like all the other much more complicated services in good working order be left alone. But of course I am grateful for all ideas. There may have been changes I do not know about yet.

Logging still not visible

@Neddy

Cannot see your new PM - again - I am not sure it is your fault; I should be able to at least get into my inbox or outbox.

EDIT

 *Quote:*   

> not 2003 when I first installed Gentoo on my box but much later on some update or other.

 

Wait a minute - that is a lie. It was when I installed Gentoo on my then newly built box with new processor and chipset and stuff. It was in the handbook I used while installing.   :Embarassed: 

----------

## smerf

If you have logging turned off (just like in my example config) and still nothing, it means, that you have broken syslog configuration (intentionally or not xinetd messages get filtered...). Have you tried sending bogus UDP datagram? What logger do you use? Try sending something to the syslog via 'logger whatever'.

----------

## EasterParade

The only useful message in /var/log/messages where syslog-ng puts all messages is:

```
Mar  8 17:37:36 aldebaran xinetd[29576]: libwrap refused connection to ntalk (libwrap=in.talkd) from 127.0.0.1

Mar  8 17:37:38 aldebaran xinetd[29579]: libwrap refused connection to ntalk (libwrap=in.talkd) from 127.0.0.1

```

I just now tried again to 

```
talk liki@aldebaran.localhost
```

 the variant Neddy proposed. So logging is not disabled.

The same message appears on 

```
talk liki tty2
```

Could that hint to tcpwrappers? What about this link http://www.gentoo.org/doc/en/security/security-handbook.xml?full=1? If I changed /etc/xinetd.conf accordingly ( middle of the page in the doc ) ... ? But none of you did this and talk works on your systems.

greetingsLast edited by EasterParade on Sun Mar 08, 2009 4:50 pm; edited 1 time in total

----------

## smerf

No logs, huh? Show your hosts.allow file.

----------

## EasterParade

```
cat /etc/hosts.allow

ALL: localhost

ALL: 192.168.x.x/255.255.255.0 <other_box>.localhost

sshd: 192.168.x.x/255.255.255.0 <other_box>.localhost

```

nothing for xinetd, hm...

Finally 

```
Mar  8 17:56:48 aldebaran xinetd[4777]: START: ntalk pid=4786 from=127.0.0.1

Mar  8 17:56:48 aldebaran xinetd[4786]: libwrap refused connection to ntalk (libwrap=in.talkd) from 127.0.0.1

Mar  8 17:56:48 aldebaran xinetd[4786]: FAIL: ntalk libwrap from=127.0.0.1

Mar  8 17:56:48 aldebaran xinetd[4777]: EXIT: ntalk status=0 pid=4786 duration=0(sec)

```

I really managed to turn logging on   :Shocked: Last edited by EasterParade on Sun Mar 08, 2009 4:58 pm; edited 1 time in total

----------

## smerf

What about hosts.deny?

----------

## EasterParade

hosts.deny

```
ALL: ALL
```

----------

## smerf

Ok, I hope that now you can see the problem  :Wink: 

For testing remove or make empty hosts.deny, for normal use add talk to hosts.allow.

EDIT: It is, however, strange that ALL: localhost does not match... but I'm not an expert here,

I do not use tcp-wrappers - iptables are IMO sufficient and much more powerful.

----------

## EasterParade

I have edited /etc/hosts.allow and added talkd. Now I have - finally - different messages from talk which seem to go into the right direction thanks to you. On:

```
talk <user> tty2
```

I get

```
[Your party is refusing messages]
```

and

```
[Trying to connect to your party's talk daemon]

```

The same for 

```
talk <user>@<hostname>.localhost

```

 and for 

```
talk <user>@IP
```

Ytalk gives this new error message: refusing messages.

In /var/log/messages I now read:

```
Mar  8 18:40:31 aldebaran xinetd[4964]: xinetd Version 2.3.14 started with libwrap loadavg options compiled in.

Mar  8 18:40:31 aldebaran xinetd[4964]: Started working: 9 available services

Mar  8 18:40:41 aldebaran xinetd[4964]: START: ntalk pid=4970 from=127.0.0.1

Mar  8 18:43:11 aldebaran xinetd[4964]: EXIT: ntalk status=0 pid=4970 duration=150(sec)

Mar  8 18:43:16 aldebaran xinetd[4964]: START: ntalk pid=4976 from=127.0.0.1
```

(while the exits - needless to say - are made by myself)

This is a huge progress and I thank you very much. From here it is not far to success.   :Very Happy: 

But something is still missing. To remove All: All from hosts.deny does not help.

greetings

----------

## smerf

Quoting myself:

 *smerf wrote:*   

> Remember to allow writes to your terminal (mesg y).

 

Have you checked that?

----------

## EasterParade

Do I have to add mesg = y into /etc/xinetd.conf?

I have now changed config files on the other system on the LAN which resulted in that user being able to talk to himself between ttys. The fact that I still cannot do this on my box shows that there must be differences now in config files although I have made those changes myself.

On my own system I read 

```
Your party is not logged on
```

I apologize for the constant editing. When I tra talk <user> without tty number the message is 

```
You party is refusing messages
```

When I try to reach the other box on the LAN I now get the message:

```
Target machine does not recognize us
```

EDIT It has something to do with the current definition of localhost on my system undoubtedly. I should close for today, shut down and plug up the courage to change my /etc/hosts and hope that this will not disrupt other services like mysql apache or phpmyadmin. But certainly not tonight.Last edited by EasterParade on Sun Mar 08, 2009 7:11 pm; edited 1 time in total

----------

## smerf

mesg is a command and y is y[es]  :Wink:  (no = sign, see man mesg)

Now, since we know why connections were rejected just re-read my previous posts.

----------

## EasterParade

Hi smerf,

mesg is not necessary. I can write to terminal without this command. Also it is not necessary to name #tty as talkd uses the next available terminal.

I have made talk on my friends box possible in no time now as I have already said, thanks to your help.

And I have made progress on my own system as well - a little more than on sunday when I have posted last.

Now when I give 

```
ytalk <user>@aldebaran
```

or 

```
ytalk <user>
```

it works on my system.   :Smile: 

I have not changed my /etc/hosts. Instead /etc/hosts.allow looks like this now - a little overdressed for my taste, but I thought I should have all my dogs lined up for this REAL BIG THING   :Wink:   to work :

```
ALL: localhost

ALL: 127.0.0.1

All: 192.168.x.x/255.255.255.0 aldebaran.localhost

ALL: 192.168.x.x/255.255.255.0 runaway.localhost

sshd: 192.168.x.x/255.255.255.0 runaway.localhost

talkd: 192.168.x.x/255.255.255.0 runaway.localhost <other_user>@runaway <other_user>@192.168.x.x 

talkd: 192.168.x.x/255.255.255.0 aldebaran.localhost <my_user>@aldebaran <my_user>@192.168.x.x

talkd: 127.0.0.1
```

When I do 

```
talk user
```

or any other combination it does not work:

```
Your party is refusing messages
```

and

```
Trying to connect to your party's talk daemon
```

Now - what bugs me is the question whether ytalk has beccome possible because I have added my user@aldebaran and the variants with their respective IPs to hosts.allow. I believe it is true. 

This does not explain however why talk alone still does not work. 

I also dislike this excessiveness which should not be required under normal circumstances. It hints to some unsound configuration on my system or other which I cannot pinpoint yet.

greetings and thank you although I do not consider the issue solved yet.

transsib[/code]

----------

## smerf

 *transsib wrote:*   

> mesg is not necessary. I can write to terminal without this command. Also it is not necessary to name #tty as talkd uses the next available terminal.

 

You can always write to your own terminal, the question is whether you want others to be able to do this? It is just a matter of tty permissions:

```
lukasz@desktop ~ $ mesg y

lukasz@desktop ~ $ ls -l `tty`

crw--w---- 1 lukasz tty 136, 2 III 10 23:10 /dev/pts/2

lukasz@desktop ~ $ mesg n

lukasz@desktop ~ $ ls -l `tty`

crw------- 1 lukasz tty 136, 2 III 10 23:10 /dev/pts/2
```

Without this only root can write to you (with talk/ytalk/write/wall etc.).

On my system talking to myself between two xterms require #tty sytax... oh, well.... minor issue.

 *transsib wrote:*   

> When I do 
> 
> ```
> talk user
> ```
> ...

 

"Refusing messages" is typical for situation where at some point process was unable to write on your party's terminal. It can be that it is not in tty group or tty permissions allow only owner access... I don't think it has anything to do with hosts.allow, but as I've never used tcp-wrapper I may be wrong.

----------

## EasterParade

Permission to write to terminal is clear; I checked. Besides ytalk is possible now on my system ( still testing on my own system alone; the other box is ready to fire it up ). I can write to terminal with ytalk. 

 *Quote:*   

> "Refusing messages" is typical for situation where at some point process was unable to write on your party's terminal. It can be that it is not in tty group or tty permissions allow only owner access... 

 

That is one way to read this message. But you could as well think around the corner; I mean refusing messaging might be something else altogether, especially if I see that with ytalk <my_user>@aldebaran.localhost I can babble to myself as much as I like, write to terminal and ask myself whether talking to myself is a reason for concern   :Laughing:   :Wink: 

I think my crowded hosts.allow is unnecessary. No one needs to put so much into that file to enable talk on his/her system. Why do I have to do that? It should work out of the box. It is a symptom for something else and I will search for it until I find it. But right now I do not know where to start. Changing /etc/hosts dow nothing; I can leave this file as is.

----------

## smerf

You can try to write to an nonexisting user on other machine - if you get "your party is refusing messages" it will be communication problem not permissions-related one (connection rejected by tcp-wrapper). Now you can try some low-level debugging (tcpdump) to see what response do you get from remote host. What is in logs on both machines?

----------

## EasterParade

Thanks smerf,

I will chase it tomorrow. I returned from work half an hour ago. Cannot concentrate any more right now.

I think that your idea is much closer. 

greetings

----------

## EasterParade

User is not logged in is the message when I try to reach the other box in the LAN.

tcpdump -v tells a lot while my box tries to receive an answer from his box. Frankly it does not make me smarter than I am. 

For example:

```
ICMP runaway.localhost udp port talk unreachable, length 112
```

The rest is a detailed protocol of asking,responding and waiting for response which do not help much. It is more or less the message I get on the console with ytalk except that it is wrapped in numbers which are of no public interest.

greetings

----------

## smerf

So, you get response from the server... and regardless your party is logged on remote machine or not you get "your party is refusing messages"? No invitation appeared on any console? Do you have access to xinetd logs on remote machine?

----------

## EasterParade

On both systems the IPs of the target machines are logged as bad dns by the daemon.

I do not know about /etc/hosts on the other system. On my system the other machines IP and hostname is listed.

 :Sad: 

At least there is only one failure message left and it is the same on both systems. That's the good news.

Before I forget: when I try to connect both systems I use ytalk on both because ytalk is the only thing that works on my system. The message ytalk gives on the console of both machines is User is not logged on and Target machine was not recognized.

greetings

transsib

----------

## smerf

 *transsib wrote:*   

> On both systems the IPs of the target machines are logged as bad dns by the daemon.

 

What do you mean?

----------

## EasterParade

In /var/log/messages appears :

```
Mar 14 09:49:02 <my_hostname> [  583.991026] process `talk' is using obsolete setsockopt SO_BSDCOMPAT

Mar 14 09:49:03 <my_hostname> talkd[3582]: <other_ip>: bad dns
```

```
Mar 14 09:48:41 <his_hostname> [  593.914515] process `talk' is using obsolete setsockopt SO_BSDCOMPAT

Mar 14 09:49:33 <his_hostname> talkd[3286]: <my_ip>: bad dns
```

The daemon keeps knocking on the door and the bad dns messages pile up in the log file.  Unknown whether the bad setsockopt can be ignored or not. 

On the console with talk it looks like this :

```
[Target machine does not recognize us
```

```
[Trying to connect to your party's talk daemon]
```

Ytalk says user@host not logged in - waiting for connection.

Lets just have a look at my system alone. When I try talk <my_user> I get :

```
Mar 14 17:51:20 <my_hostname> xinetd[3260]: START: ntalk pid=4933 from=127.0.0.1

Mar 14 17:51:21 <my_hostname> talkd[4933]: <my_ip>: bad dns
```

On the console I then get :

```
Your party is refusing messages
```

```
[Trying to connect to your party's talk daemon]
```

With ytalk it works - no error message :

```
Mar 14 18:03:04 <my_hostname> xinetd[3260]: START: ntalk pid=5016 from=127.0.0.1
```

I`m afraid the confusion is complette now   :Wink: 

greetings

----------

## EasterParade

Today I decided on a little experiment. I`ve created a new user on my system, complete with passwd, groups and home. This new user has nothing in his home directory but .bash_logout, .bash_profile, .bashrc and .ssh/ directory and is not mentioned in /etc/hosts.allow!

My old user invited this new user to talk with talk <new_user>@hostname and connection has been established at once.

This proves two things: 

hosts.allow is unnecessary - 

something in my old user prevents the daemon from connecting respectively from working uninhibited and connecting to the other box on the LAN.

However I do not know what difference there is between the old user and the fresh, clean new user. It is even possible that there is nothing wrong with the old user because the old user initiated the conversation, not the new user.

greetings and thanks for sticking around

transsib

----------

## smerf

Somehow I missed notification of your response... sorry  :Sad: 

 *transsib wrote:*   

> obsolete setsockopt SO_BSDCOMPAT

 

This is one harmless...

 *transsib wrote:*   

> hosts.allow is unnecessary

 

Files are examined as follows: hosts.allow (allow if matched) -> hosts.deny (deny if metched) -> grant access.

For debugging purposes it is best to remove/empty both files.

 *transsib wrote:*   

> something in my old user prevents the daemon from connecting respectively from working uninhibited and connecting to the other box on the LAN [...] the old user initiated the conversation, not the new user

 

What about new user -> old user?

The only difference I can think of is mentioned earlier 'mesg' status... I'll keep thinking  :Wink: 

----------

## EasterParade

No worries; I was busy anyway.

 *Quote:*   

> What about new user -> old user? 

 

Both ways work, which means talk works flawlessly with two users on the same system, same box.

But reaching out from my box to the user on the other box on the LAN is a no go.

I am still not sure what exactly prevents the connection although I now know for sure that the daemon is

up and does its job.

 *Quote:*   

> Files are examined as follows: hosts.allow (allow if matched) -> hosts.deny (deny if metched) -> grant access.
> 
> For debugging purposes it is best to remove/empty both files.

 

I have renamed hosts.allow two day ago. It now is hosts.allow_sec so that it cannot be found anymore. That has not changed the status quo as seen above:

talk works for two users on the same system but not for users of diffrent systems that however belong to the same local area network.

This proves doubtlessly that hosts.allow is not crucial and may even not be read by the daemon in the first place. 

File hosts.deny is empty.

I will do some reconfiguring of /etc/hosts and then start copying files from old to new user account for elimination of any other culprit.

----------

## smerf

As far as I understand the protocol invitations use UDP datagrams but the actual

conversation uses TCP (port number where client listens is advertised in invitation).

See: http://www.iagora.com/~espel/talk-info.txt (in english, pretty old  :Wink: )

Now, those 'bad dns' messages - they seem to be the root of all evil, looking into talkd.c:

```
syslog(LOG_WARNING, "%s: bad dns", theirip);

send_reject_packet(mp, &sn, MACHINE_UNKNOWN, 0);
```

There are two possible reasons for rejecting packet with such message:

Call to gethostbyaddr or gethostbyname fails (unable to resolve name/address).

The name it got does not resolve back to any of its addresses (spoofing or wrong setup).

Looks like talkd tries to do everything by himself without libwrap, quoting talkd.c again:

```
Wrapping talkd with tcpd isn't very useful.
```

Because it uses UDP, I thought it uses libwrap directly, but apparently it does not,

I think that xinetd wraps this: [UDPpacket]->xinetd->libwrap->in.talkd (more or less like this).

If you are in the right mood, just add another syslog call to differentiate those calls

and send the true reason (I mean h_errno value) and recompile netkit-talkd

Something like: syslog(LOG_WARNING, "%s: bad dns (gethostbyaddr=%d)", theirip,h_errno); and so on.

You may try strace -f -p `pidof xinetd` but it will require a lot of patience to read...

Or check once again /etc/hosts /etc/nsswitch.conf and /etc/resolv.conf  :Wink: 

When I find some time I'll try to reproduce your problem with conflicting entries in /etc/hosts and patched talkd.

----------

## EasterParade

smerf

don`t wreck your smoothly running system, please.   :Shocked: 

I am soooooo close to solution. My friend on the other box can ssh to the new user account 

on my system and then talk to the first user on my system. He can now tell me to bring some

coffee or serve dinner    :Very Happy: 

My issue is practically solved in a manner of speaking. 

All that`s still left to do is finding a way to allow the direct connection from box#1 to box#2 using talk. 

But this is rather for perfections`sake, or a theoretical curiousity.

As of the protocol - you think tcp was better suited than udp? I`ll try your commands for analysis today.

ejoy

transsib

----------

## smerf

As a matter of fact using ssh or ssh tunnel is also the most secure way as talk does not encrypt

traffic by itself and has a long history of security issues (buffer overflows).

Now I'm pretty sure (just as I suspected earlier) the problem emerges because you have:

```
127.0.0.1       aldebaran.localhost     aldebaran       localhost

192.168.0.2               aldebaran.localhost 
```

Avoid doubling names. Do not use dot inside local names and - if possible - do not use aliases for localhost.

In your setup you will never know how particular address will be resolved and which interface will be used.

This should be ok (and enough):

```
127.0.0.1 localhost # or at least give 'localhost' first position on the list of aliases

192.168.0.2 aldebaran
```

Of course you may break things that rely on your current setup. However, IMO the less "hackish" configs are the better.

(if you want to set domain name to 'localhost' put dns_domain_lo="localhost" in /etc/conf.d/net instead of messing with /etc/hosts)

Disclaimer: I still don't know what do you have inside nsswitch.conf and resolv.conf so I suppose, that the order is: 'files dns'

----------

## EasterParade

 *Quote:*   

> Now I'm pretty sure (just as I suspected earlier) the problem emerges because you have:
> 
> ```
> 
> 127.0.0.1       aldebaran.localhost     aldebaran       localhost
> ...

 

 *Quote:*   

> Avoid doubling names. Do not use dot inside local names and - if possible - do not use aliases for localhost.
> 
> In your setup you will never know how particular address will be resolved and which interface will be used.
> 
> This should be ok (and enough):
> ...

 

Yep thanks for reassuring me as I was already at it.  Wasn`t my idea though; standing on a giant`s shoulders   :Wink: 

I hope it won`t break anything else. Don`t think so -  bind-address in mysql  my.cnf is 172.0.0.1, the other playgrounds all look for localhost.

Breaks with an old tradition but seems to be about time.

 *Quote:*   

> Disclaimer: I still don't know what do you have inside nsswitch.conf and resolv.conf so I suppose, that the order is: 'files dns'

 

Ah, sorry, here they are:

```
# /etc/nsswitch.conf:

# $Header: /var/cvsroot/gentoo/src/patchsets/glibc/extra/etc/nsswitch.conf,v 1.1 2006/09/29 23:52:23 vapier Exp $

passwd:      compat

shadow:      compat

group:       compat

# passwd:    db files nis

# shadow:    db files nis

# group:     db files nis

hosts:       files dns

networks:    files dns

services:    db files

protocols:   db files

rpc:         db files

ethers:      db files

netmasks:    files

netgroup:    files

bootparams:  files

automount:   files

aliases:     files

```

```
# Generated by net-scripts for interface eth0

nameserver 192.168.0.100
```

= DSL router

greetings

----------

## smerf

Anything changed after you modified /etc/hosts? (nsswitch.conf and resolv.conf seem to be ok)

----------

## EasterParade

No, status is unchanged, no developement to the worse though.

On trying to directly talk to the user on the other box ( talk other_user@other_box )

I still get 

```
Target machine does not recognize us
```

 on my console and

```
Your party is refusing messages
```

 on the console of the other computer.

Then both of them go like trying to establish connection.   :Confused: 

No damage done to mysql, apache, phpmyadmin...

But no changes have been made on the other computer yet. And I don`t want to fiddle around

with another persons` system.

But there is ssh and the way I`ve managed to achieve as described.

In case no further progress will be possible ( perhaps I should leave it at that for the moment and

sleep over it ) I am glad that my etc/hosts has been changed. And I`ve never before dealt so much with

networking .

 :Question:    What`s your opinion: should I mark the thread solved? Practically it is. Plus no one else seems to care

for it. They may not have those n00b probs or they just don`t use talk. Could be premature but 

it is about bandwidth as well - three pages for talk...

----------

## smerf

Do you still get "bad dns" messages?

 *Quote:*   

> Should I mark the thread solved?

 

Well, it is entirely up to you - feel free to mark it if you're satisfied with the results  :Smile: 

I'm just curious what makes it behave like that. I have a feeling that we are still missing

something simple and obvious. That's why I don't like the idea to leave it as it is.

And there are plenty of ideas we still haven't tried yet...

Anyway, as I said - it is up to you. I can always try to reproduce your problem on my

machine(s) in case I won't be able to get a good night's sleep because of this  :Wink: 

----------

## EasterParade

 *Quote:*   

> I'm just curious what makes it behave like that. I have a feeling that we are still missing
> 
> something simple and obvious. That's why I don't like the idea to leave it as it is.

 

Ja, s.th. obvious is lurking in the shadows and I should leave it unresolved for now. Why can`t I see 

what it is, I agree it is likely s.th. simple.

Satisfied? Yes because he can come over onto my box and 

```
talk
```

 that my music sounds like a bag of cats

and please could I turn down the volume for heavens`sake   :Laughing: 

Satisfied? No, because the core of the issue has not been dug out yet. 

Plus the /etc/hosts of the other system has not been altered - don`t want to force it.

However no issue is worth the loss of only a minute of a good nights`sleep and we all know how much work

a well greased system is; so please don`t run the risk of trying to reproduce this abnormal behaviour on your system.  :Smile: 

I might feel bad about it too. Thank you for your heroic offer though   :Very Happy: 

I`ll leave it and with a little distance the solution might fall down out of the blue.

 *Quote:*   

> Do you still get "bad dns" messages? 

 

No   :Exclamation: 

greetings

----------

## smerf

So be it  :Smile: 

PM me if you resolve this issue or observe something interesting.

----------

## NeddySeagoon

transsib,

Post the answer to the thread, when you  have it.

We all want to know.

----------

## EasterParade

 *Quote:*   

> Post the answer to the thread, when you have it.
> 
> We all want to know.

 

Ah, yes, I stand corrected. Don`t repeat this at home.  :Embarassed: 

Changing my /etc/hosts like I showed above causes turbulences and I only like them on flights   :Wink: 

This

```
# IPv4 and IPv6 localhost aliases

127.0.0.1       localhost

::1             localhost
```

causes that

```
10:36:28 liki@aldebaran ~ $ hostname -vs

gethostname()=,,aldebaran''

Löse ,,aldebaran'' auf ...

Ergebnis: h_name=,,aldebaran''

Ergebnis: h_addr_list=,,192.168.0.2''

aldebaran 
```

and when I think I`m sooo smart and put my IP plus hostname.local here

```

# In case you want to be able to connect directly to the Internet (i.e. not

# behind a NAT, ADSL router, etc...), you need real official assigned

# numbers. Do not try to invent your own network numbers but instead get one

# from your network provider (if any) or from your regional registry (ARIN,

# APNIC, LACNIC, RIPE NCC, or AfriNIC.)

#

192.168.0.2 aldebaran.local
```

The system thanks me with

```
10:36:38 liki@aldebaran ~ $ hostname -vf

gethostname()=,,aldebaran''

Löse ,,aldebaran'' auf ...

hostname: Unbekannter Rechner
```

unknown host    :Rolling Eyes: 

So I thought it is back to my previous /etc/hosts and now hostname resolves to 127.0.0.1 again.

Btw Apache wasn`t impressed by the stunt. Apache worked all the same, looking for the real IP but still serving from 

/var/www/localhost/htdocs/   :Laughing:   and mysql/phpmyadmin just shrugged it off.

For now I resign to the status. There is no direct connection from one box to the other. Any user of one box has to ssh to user 

on the other box. But once there talk is working flawlessly.

I still don`t know why. My curiousity is unsatisfied but the practical use is predominant for the time being. And may be the solution will fall down from the ceiling as it sometimes does once the dust has settled.

Does this deserve a [SOLVED]?

May be talk just doesn`t work from box to box within a LAN only among users on the same system.   :Question: 

greetings

----------

## smerf

 *transsib wrote:*   

> This
> 
> ```
> # IPv4 and IPv6 localhost aliases
> 
> ...

 

Is it wrong?

 *transsib wrote:*   

> The system thanks me with
> 
> ```
> 10:36:38 liki@aldebaran ~ $ hostname -vf
> 
> ...

 

What do you have in /etc/conf.d/hostname must resolve to your IP.

You are allowed to use dots (see hosts(5) manual), but leave 'aldebaran' as alias.

Apache behaviour depends on its vhosts configuration, but is is flexible enough to work

happily even for weird resolver setup. Hostname to serve is usually taken from Host:

HTTP 1.1 header field, so it depends on your browser and not entirely Apache itself.

----------

## EasterParade

Must be wrong if I get aldebaran.unknown_domain after booting is

complete.

/etc/conf.d/hostname has hostname="aldebaran"

Is there a syntax error somewhere, here?

```
# IPv4 and IPv6 localhost aliases

127.0.0.1       localhost

::1             localhost
```

the additional 'localhost' after ::1?

Does it make sense to put aldebaran.local or aldebaran together with its

internal IP here?

```
# In case you want to be able to connect directly to the Internet (i.e. not

# behind a NAT, ADSL router, etc...), you need real official assigned

# numbers.  Do not try to invent your own network numbers but instead get one

# from your network provider (if any) or from your regional registry (ARIN,

# APNIC, LACNIC, RIPE NCC, or AfriNIC.)

#

192.168.0.2     aldebaran.local
```

Wrong place here, 'cause it`s behind a router.

I mean this is just an internal IP, the name given to my box within the local LAN. And it is not

a server, just a desktop system. Apache, mysql a. phpmyadmin are just a part of my 

own personal rosegarden. All they need is 127.0.0.1 localhost.

----------

## smerf

 *Quote:*   

> Must be wrong if I get aldebaran.unknown_domain after booting is
> 
> complete.

 

Why? You just do not have domain set, simply remove \O from /etc/issue if this annoys you.

 *Quote:*   

> Does it make sense to put aldebaran.local or aldebaran together with its
> 
> internal IP here?

 

YES. See 'examples' section in manual.

Leave localhost as is. What's the difference between 'internal' (you meant 'private'?) and

'external ('public'?) in this case? Anything other than 127.0.0.0/8 is external for your box.

----------

## NeddySeagoon

transsib,

```
127.0.0.1       localhost
```

 is not wrong, its just incomplete.

Typically you would have 

```
127.0.0.1       localdomain.localhost localhost
```

 so that the resolver returned localdomain.localhost when asked about 127.0.0.1, alhough this is a bad example as 127.0.0.1 is often hard coded, so it still works even if networking is not set up.

You can choose to have the resolver return all the aliases, or just the first name in the list, which is the default, hence localdomain.localhost should be first in the list as it has a domain.

localdomain.localhost localhost should not appear against any other IPs, except those in 127.0.0.0/8

Consider the entry 

```
192.168.1.10 localdomain.localhost localhost realdomain.realhost
```

Forward lookups are confusing by may work as the 127.0.0.1 entry traditionally appears in /etc/hosts before other IPs

Getting localdomain.localhost as the name for 192.168.1.10 is ok too, if 192.168.1.10 is the local box. It will work for the wrong reason.

To be clear what is happening do not have any aliases in /etc/hosts. Against each IP have only one name. It may as well be the short name too, so you have 

```
127.0.0.1 localhost

192.168.10.1 Router

192.168.10.2 PC1

192.168.10.3 PC2
```

 Router, PC1 and PC2 are the host names, not the fully qualified domain names.

At a glance you should be able to see that /etc/hosts can now be identical on all the PCs on your network. It you add more, you have to modify /etc/hosts and copy it everywhere. Indeed, the internet used to work this way before DHCP

----------

## EasterParade

Neddy, smerf

I am at a dead end right now. Neddy, your last posting is important and I`ll

play with it . I just can`t rush it as there are two many other things

at the moment which demand a great deal of attention. I cannot function 

properly like this.

I`ve marked the thread partly solved as this is indeed the case; talk works

in a way.

I thank you all for your help and patience.   :Smile: 

greetings

transsib

----------

## EasterParade

 *Quote:*   

> To be clear what is happening do not have any aliases in /etc/hosts. Against each IP have only one name. It may as well be the short name too, so you have
> 
> Code:
> 
> 127.0.0.1 localhost
> ...

 

Despite the narrow time window for the system in my schedule I couldn`t resist the temptation to give it

another try after letting the issue lie dormant for two days.

I still haven`t changed the first line in /etc/hosts and hostname still resolves to 127.0.0.1 on both machines.

I only managed to clear the thick mist out of my head and out of both hosts files.

Then I  just followed your instructions to the book, Neddy, without trying to make it more complicated than it really is   :Confused: 

added the IPs and hostnames of the members of the LAN correctly, synchronized the hosts files on both systems

and finally got what I wanted: talk now works from one box to the other without detour.   :Smile: 

There only appears to have arisen a new issue which is doubtlessly unrelated to talk or networking. The other box must respond

talk user@hostname to start communication. But bash returns : talk: no such file or directory and another no such referring to my user@hostname which has to follow talk. There is a prob on the other box. I will have to delegate it   :Wink: 

Well, isn`t that nice! But o.k., I`ll get that. Connection is up and running, the issue is completely solved. Thank you all   :Very Happy: 

( man, was I stubborn - it was a flyspeck   :Embarassed:  )

greetings

transsib

----------

## smerf

Finally [SOLVED], cool  :Wink: 

----------

