linux-l: Kriege mein offline Mailsystem nicht wieder hin!
Kay Molkenthin
molkiheg at cetus.zrz.TU-Berlin.DE
Di Jun 16 00:22:48 CEST 1998
Hi,
also erstmal vielen Dank an alle, die sich meinem Problem annehmen!
So und jetzt wirds lang und ausführlich:
Ein kurzer Ausschnitt, daß es tatsächlich mal lief ;-)
Jun 14 19:59:08 petra in.pop3d[16920]: Servicing request for kay
Jun 14 19:59:11 petra in.pop3d[16940]: Servicing request for kay
Und jetzt wirds ernst:
ifconfig:
=========
kay:
kay:[/root] #ifconfig
lo Link encap:Local Loopback
inet addr:127.0.0.1 Bcast:127.255.255.255 Mask:255.0.0.0
UP BROADCAST LOOPBACK RUNNING MTU:3584 Metric:1
RX packets:2 errors:0 dropped:0 overruns:0 frame:0
TX packets:2 errors:0 dropped:0 overruns:0 carrier:0 coll:0
eth0 Link encap:Ethernet HWaddr 00:40:95:A4:04:E4
inet addr:192.168.1.1 Bcast:192.168.1.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:11123 errors:0 dropped:0 overruns:0 frame:0
TX packets:13960 errors:0 dropped:0 overruns:0 carrier:0
coll:0
Interrupt:5 Base address:0x240
kay:[/root] #
petra:
petra:[kay] #ifconfig
lo Link encap:Local Loopback
inet addr:127.0.0.1 Bcast:127.255.255.255 Mask:255.0.0.0
UP BROADCAST LOOPBACK RUNNING MTU:3584 Metric:1
RX packets:26264 errors:0 dropped:0 overruns:0 frame:0
TX packets:26264 errors:0 dropped:0 overruns:0 carrier:0
coll:0
eth0 Link encap:Ethernet HWaddr 00:40:95:A4:04:14
inet addr:192.168.1.2 Bcast:192.168.1.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:172210 errors:0 dropped:0 overruns:0 frame:0
TX packets:133810 errors:0 dropped:0 overruns:0 carrier:0
coll:11
Interrupt:15 Base address:0x260
ippp0 Link encap:Point-to-Point Protocol
inet addr:130.149.1.203 P-t-P:130.149.1.69
Mask:255.255.255.0
UP POINTOPOINT RUNNING NOARP MTU:1500 Metric:1
RX packets:105613 errors:0 dropped:0 overruns:0 frame:0
TX packets:141259 errors:0 dropped:0 overruns:0 carrier:0
coll:0
petra:[kay] #
route -n:
=========
kay:
kay:[/root] #route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use
Iface
192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 1
eth0
127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 1
lo
0.0.0.0 192.168.1.2 0.0.0.0 UG 0 0 7
eth0
kay:[/root]
#
petra: (ohne aktive ISDN-Verbindung, also "offline")
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use
Iface
130.149.1.69 0.0.0.0 255.255.255.255 UH 0 0 0
ippp0
192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 44
eth0
127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 28
lo
Die /etc/hosts, etc/hosts.allow /etc/hosts.deny und /etc/inetd.conf von
"petra" hab ich ja schon mal gepostet und die sind unverändert.
Hier also die von "kay":
/etc/hosts:
===========
127.0.0.1 localhost
192.168.1.1 kay.chaos.network kay
192.168.1.2 petra.chaos.network petra
/etc/host.conf:
===============
kay:
order hosts, bind
multi on
petra:
order hosts,bind
multi on
/etc/hosts.allow:
=================
#
# hosts.allow This file describes the names of the hosts which are
# allowed to use the local INET services, as decided
# by the '/usr/sbin/tcpd' server.
#
# See hosts.allow(5) for a description.
#
# Ngo Than <than at delix.de>
# in.tftpd: LOCAL, .my.domain
# ALL: LOCAL @some_netgroup
# ALL: .foobar.edu EXCEPT terminalserver.foobar.edu
ALL: 192.168.1.
/etc/hosts.deny:
================
#
# hosts.deny This file describes the names of the hosts which are
# *not* allowed to use the local INET services, as decided
# by the '/usr/sbin/tcpd' server.
#
# The portmap line is redundant, but it is left to remind you that
# the new secure portmap uses hosts.deny and hosts.allow. In particular
# you should know that NFS uses portmap!
#
# See hosts.deny(5) for a description.
#
# Ngo Than <than at delix.de>
# ALL: ALL
# ALL: some.host.name, .some.domain
# ALL EXCEPT in.fingerd: other.host.name, .other.domain
/etc/inetd.conf:
================
#
# inetd.conf This file describes the services that will be available
# through the INETD TCP/IP super server. To re-configure
# the running INETD process, edit this file, then send the
# INETD process a SIGHUP signal.
#
# Version: @(#)/etc/inetd.conf 3.10 05/27/93
#
# Authors: Original taken from BSD UNIX 4.3/TAHOE.
# Fred N. van Kempen, <waltje at uwalt.nl.mugnet.org>
#
#
# <service_name> <sock_type> <proto> <flags> <user> <server_path> <args>
#
# Echo, discard, daytime, and chargen are used primarily for testing.
#
# To re-read this file after changes, just do a 'killall -HUP inetd'
#
#echo stream tcp nowait root internal
#echo dgram udp wait root internal
#discard stream tcp nowait root internal
#discard dgram udp wait root internal
#daytime stream tcp nowait root internal
#daytime dgram udp wait root internal
#chargen stream tcp nowait root internal
#chargen dgram udp wait root internal
#
# These are standard services.
#
ftp stream tcp nowait root /usr/sbin/tcpd in.ftpd -l -a
telnet stream tcp nowait root /usr/sbin/tcpd in.telnetd
gopher stream tcp nowait root /usr/sbin/tcpd gn
# do not uncomment smtp unless you *really* know what you are doing.
# smtp is handled by the sendmail daemon now, not smtpd. It does NOT
# run from here, it is started at boot time from /etc/rc.d/rc#.d.
#smtp stream tcp nowait root /usr/bin/smtpd smtpd
#nntp stream tcp nowait root /usr/sbin/tcpd in.nntpd
#
# Shell, login, exec and talk are BSD protocols.
#
#shell stream tcp nowait root /usr/sbin/tcpd in.rshd
#login stream tcp nowait root /usr/sbin/tcpd in.rlogind
#exec stream tcp nowait root /usr/sbin/tcpd in.rexecd
talk dgram udp wait root /usr/sbin/tcpd in.talkd
ntalk dgram udp wait root /usr/sbin/tcpd in.ntalkd
#dtalk stream tcp waut nobody /usr/sbin/tcpd in.dtalkd
#
# Pop and imap mail services et al
#
pop-2 stream tcp nowait root /usr/sbin/tcpd ipop2d
#pop-3 stream tcp nowait root /usr/sbin/tcpd ipop3d
imap stream tcp nowait root /usr/sbin/tcpd imapd
#
# The Internet UUCP service.
#
#uucp stream tcp nowait uucp /usr/sbin/tcpd /usr/lib/uucp/uucico -l
#
# Tftp service is provided primarily for booting. Most sites
# run this only on machines acting as "boot servers." Do not uncomment
# this unless you *need* it.
#
#tftp dgram udp wait root /usr/sbin/tcpd in.tftpd
#bootps dgram udp wait root /usr/sbin/tcpd bootpd
#
# Finger, systat and netstat give out user information which may be
# valuable to potential "system crackers." Many sites choose to disable
# some or all of these services to improve security.
#
# cfinger is for GNU finger, which is currently not in use in RHS Linux
#
finger stream tcp nowait root /usr/sbin/tcpd in.fingerd
#cfinger stream tcp nowait root /usr/sbin/tcpd in.cfingerd
#systat stream tcp nowait guest /usr/sbin/tcpd /bin/ps -auwwx
#netstat stream tcp nowait guest /usr/sbin/tcpd /bin/netstat -f inet
#
# Time service is used for clock syncronization.
#
time stream tcp nowait nobody /usr/sbin/tcpd in.timed
time dgram udp wait nobody /usr/sbin/tcpd in.timed
#
# Authentication
#
auth stream tcp wait nobody /usr/sbin/in.identd in.identd
-w -t120
#
# End of inetd.conf
Vielleicht kommt hier jetzt was richtig wichtiges (hat wahrscheinlich
mit dem Hängenbleiben beim Start von Netscape zu tun, wenn ich auch
schon vorher bei Offline meine Mails & News lesen wollte:
"kay" /etc/resolv.conf
domain chaos.network
search chaos.network
nameserver 130.149.4.10
"petra" /etc/resolv.conf
domain chaos.network
search chaos.network
nameserver 130.149.4.10
/etc/networks: "kay" & "petra" identisch
==============
#
# networks This file describes a number of netname-to-address
# mappings for the TCP/IP subsystem. It is mostly
# used at boot time, when no name servers are running.
#
loopback 127.0.0.0
localnet 192.168.1.0
# End.
Da ich noch kein Netwerk-Guru bin möchte ich folgendes fragen:
Sehe ich das Problem richtig, daß "kay" auf "petra" einen 110/tcp-Dienst
(was besagt eigentlich die "110" -> Diensterkennung???), nämlich pop3
wahrnehmen will und "petra" sagt, "nein nein, ich kenne Dich doch gar
nicht!"
Ich hoffe, wir können dem Problem so etwas besser auf die Schliche
kommen!
BTW: Da die Belug-Mails in meinem in 2 Min. konfigurierten
Pine-Hilfsmailreader alle durcheinanderfliegen und nicht in einer
schönen Belug-Mappe liegen, weiß ich im Augenblick nicht mehr, wer es
geschrieben hat. Es ging um ein evtl. vereinsamtes "Lock-File" (die
Vermutung hatte ich am Anfang übrigens auch), daß aber nicht in
/var/lock liegt (da hab ich schon geschaut) - könnte da was dran sein???
Gruß Kay.
--
Kay Molkenthin - Ruesternallee 45 - 14050 Berlin [GERMANY]
Email: molkiheg at sp.zrz.tu-berlin.de / Kay_Molkenthin at Bigfoot.de
------------------------------------------------------------------
Key fingerprint = A6 1E 73 E7 E7 77 75 E1 7C E6 EF AF 78 A6 6C 38
Mehr Informationen über die Mailingliste linux-l