🚀 go-pugleaf

In article <MSGID_2=3A310=2F81.81_e9cc351@fidonet>,
Martina Umlauft <Martina.Umlauft@2-310-81-81.st.co.at> wrote:

> Noch was: wie kann man das am gescheitesten mit den Nameservern machen? Ich
> habe hier 2 Maschinen im LAN, fuer die ich natuerlich nicht extra named
> aufsetzen will, dh. die sind einfach in /etc/hosts drinnen und das war's.

ich hab hier meine linux-maschin und eine dose im lan haengen, muss
aber einen nameserver lokal betreiben, sonst spielt das pegasus mail
fuer dos nicht mit. also:

;
;    boot file for name server
;
directory /etc/named

; type     domain                source host/file          backup file

cache      .                                               root.cache
primary    kukuruz.ping.at          named.hosts
primary    0.0.127.IN-ADDR.ARPA                            named.local
primary    2.0.192.IN-ADDR.ARPA                         named.rev

...in named.boot; dh. (fake-) nameserver fuer meine domain und die
reversemap, und ansonsten 'richtiger' nameserver fuer alles aus der
grossen weiten welt. (bei dieser konfiguration ist 'FEATURE(nodns)' in
der sendmail .mc angesagt, sonst wartet er ohne inet-verbindung endlos
auf den nameserver-timeout).

funktioniert oberpraechtig -- alles, was lokal passiert, greift auf
lokale ressourcen des nameservers zu, alles andere macht DNS in die
weite welt hinaus, inkl. caching. beim starten des named will der kurz
einmal die rootserver befragen, aber das ist nur ein problem, wenn Du
beim booten auch diald oder eine aehnliche dial-on-demand-loesung startest.

wenn du

order hosts,bind
domain deine.lokale.domain
domain tuwien.ac.at

in die resolv.conf reingibst, dann ersparst du dir damit auch
kurznamen a la 'stud1' in /etc/hosts.

> Ok, wie habt ihr das geloest? Va. will ich von beiden LAN-Maschinen aus ins
> Internet gehen koennen; dazu muss ich dann wohl den Rechner mit der SLIP-Line
> als Gateway aufsetzen, oder? (Ich hab das noch nicht getestet, denn wie gesagt

da wirst du ein problem bekommen, weil die TU vermutlich nur die
adresse deiner slip-verbindung routet, nicht aber deinen zweiten
rechner -- woher sollte sie von dem auch wissen.

jenachdem, was du auf der zweiten maschine machen willst, kommst du
mit einem simplen CERN-http-proxy auf der slip-maschine durch, musst
IP masquerading verwenden (hat davon irgendwer eine ahnung?), socks,
oder eine umfassendere proxy-loesung wie den TIS FWTK.

> Achja, nochwas: wieviel Sicherheitsvorkehrungen trefft ihr fuer sowas? Da ich
> die Kisten bis jetzt nur standalone betrieben hatte, hab ich mir da nie
> Gedanken drueber gemacht. An und fuer sich oeffnet man ja dabei jedem
> Mutwilligen Tuer und Tor...

/etc/inetd.conf abgrasen. ich hab im moment aktiv (ausser den
'internal' services):

ftp     stream  tcp     nowait  root    /usr/sbin/tcpd  /usr/sbin/wu.ftpd
telnet  stream  tcp     nowait  root    /usr/sbin/tcpd  /usr/sbin/in.telnetd
smtp    stream  tcp     nowait  root    /usr/sbin/tcpd  /usr/bin/sendmail -bs -X /tmp/smtplog
talk    dgram   udp     wait    root    /usr/sbin/tcpd  /usr/sbin/in.ntalkd
ntalk   dgram   udp     wait    root    /usr/sbin/tcpd  /usr/sbin/in.ntalkd
pop3    stream  tcp     nowait  root    /usr/sbin/tcpd  /usr/sbin/ipop3d
finger  stream  tcp     nowait  daemon  /usr/sbin/tcpd  /usr/sbin/in.fingerd
auth    stream  tcp     nowait  root    /usr/sbin/in.identd     in.identd
netbios-ssn     stream  tcp     nowait  root    /usr/sbin/tcpd  smbd
netbios-ns      dgram   udp     wait    root    /usr/sbin/nmbd  nmbd

...und das alles mit den tcp wrappers abgesichert -- in der art

[hosts.allow]
smbd:   192.0.2.
ipop3d: 192.0.2.2
sendmail:       192.0.2.2
in.telnetd:             192.0.2.2,127.0.0.1

[hosts.deny]
smbd:   ALL
ipop3d: ALL
sendmail: ALL
in.telnetd:     ALL

ciao,

cm.