Hallo
Ich habe ein kleines Problem mit dem Laptop, ich habe mir eine Zusatztastatur
zugelegt, leider funktioniert die aut. erkennung nicht. Woran könnte das
liegen und wie bindet man diese händisch ein oder wie erzwingt man den
Erkennungsprozess. Irgendwann erkennt er diese auch, aber ich kenn nicht
darauf warten bis er möchte.
--
Ferdinand Tavernini, Schlanders
e-mail: info(a)ing-tavernini.com
Da ich Morgen beruflich in München bin,
kann ich versuchen, die deutsche Redhat zeitschrift zu
erwerben, wenn ich jemandem eine mitbringen soll, möge er
es mir bis heute abend bitte direkt (per Mail) mitteilen
mit freundlichen Grüßen
Martin Senoner
http://www.emsis.it/
Hallo und guten Morgen ihr zwei!
Hm.... der Teil belegt jetzt wie die Sache laufen sollte, nur verstehe ich
genausowenig wie eine eingehende Anfrage eintreffen kann, wenn im
prerouting nur eine Drop-Policy steht.
Aber egal, ich muß mich voraussichtlich diese Woche eh noch tiefer mit ein
paar Sachen aus dem Bereich beschäftigen. Wenn es euch interessiert werde
ich ein paar Tests machen.
Grüße,
Günther
Günther Mair
Internet Engineer
ENERGIS Italia GmbH
Pfarrhofstrasse 60/A
I-39100 Bozen (BZ)
Tel.: +39 0471 254000
Fax: +39 0471 251617
Email: guenther.mair(a)energis.it
Web: http://www.energis.it
Am Dienstag, 27. Mai 2003 02:06 schrieb Peter Warasin:
Hallo
> hallo
>
> > Wenn jemand genaueres zum Thema findet, sagt mir bescheid!
>
> hab das interview auf kernelnewbies rausgesucht..
> da stehts doch besser erklaert als in den howtos:
>
>
> <LaForge> PART 1 - netfilter basics
> <LaForge> I was talking about these hooks at particular points in
> the network stack. <LaForge> I'm going to concentrate on IPv4, as
> this seems to be the most important case :) <LaForge>
> --->[1]--->[ROUTE]--->[3]--->[4]--->
> <LaForge> | ^
> <LaForge> | |
> <LaForge> | [ROUTE]
> <LaForge> v |
> <LaForge> [2] [5]
> <LaForge> | ^
> <LaForge> | |
> <LaForge> v |
> <LaForge>
> <LaForge> on the left hand, you have incoming packets, coming
> from the network <LaForge> on the right hand, outgoing packets
> are leaving to the network <LaForge> on the bottom of the picture
> is our local machine, the local userspace processes. <LaForge>
> the 5 hooks are called:
> <LaForge> 1 NF_IP_PRE_ROUTING
> <LaForge> 2 NF_IP_LOCAL_IN
> <LaForge> 3 NF_IP_FORWARD
> <LaForge> 4 NF_IP_POST_ROUTING
> <LaForge> 5 NF_IP_LOCAL_OUT
> <LaForge> so let's view at the path a packet goes while being
> forwarded by our machine: <LaForge> Firs it comes off the wire,
> it passes hook #1. The routing decision is made, <LaForge> it
> passes hook #3 (forward), passes hook #4 (post_routing) and
> leaves off to the network again. <LaForge> If we look on packets
> which have a local destionation (are locally terminated an are
> not routed), the following path: <LaForge> packet comes off the
> wire
> <LaForge> packet hits hoo #1 (pre_routing)
> <LaForge> routing decision decides that packet is local
> <LaForge> packet hits hook #2 (local_in)
> <LaForge> packet hits local process
> <LaForge>
> <LaForge> If we look at a locally-originated packet:
> <LaForge> packet is generated by local process at the bottom
> <LaForge> packet hits hook #5 (local_out)
> <LaForge> routing code decides where to route the packet
> <LaForge> packet passes hook #4 (post_routing)
> <LaForge> packet hits the wire of the network
Das erklärt einiges. Wie gesagt, ich habe zunächst die Einstellungen
von einem Buch (Ziegler - Verlag Markt und Technik) einfach
kritiklos übernommen, nachdem ich iptables als masquerading aber
ohne drops mit Erfolg eingesetzt hatte. Irreführend war ja die
Tatsache, dass dhcp auch mit "gedropten" nat+mangle zunächst
einmal funktioniert. Es funkioniert sogar das automatische
Auffrischen, nur ein gezieltes Erneuern scheitert.
>
> das interview ist auf:
> http://www.kernelnewbies.org/documents/irclogs/netfilter.log
Werde ich nachlesen.
>
> da sind dann noch mehr solcher interviews und dokumente:
> http://www.kernelnewbies.org/documents/
>
>
> peter
Nochmals danke an alle
Luigi
>
> _______________________________________________
> http://www.lugbz.org/mailman/listinfo/lugbz-list
> LUGBZ is pcn.it-powered
_______________________________________________
http://www.lugbz.org/mailman/listinfo/lugbz-list
LUGBZ is pcn.it-powered
La città di Monaco (Germania) ha deciso di migrare 14000 client da
Windows NT a Linux! :)
Maggiori informazioni le trovate su www.lugbz.org
bye
raf
p.s. viva linux! :)
--
:: e n d i a n
:: open source - open minds
:: raphael vallazza
:: i-39057 eppan/appiano, bergweg 41 via monte
:: mobile +39 339 5620338 :: fax +39 0471 673476
:: www.endian.it :: raphael(a)endian.it
Hallo Peter!
Die Netfilter-Dokumentation ist recht gut, enthält die Infos speziell zum
Thema Prerouting und Postrouting aber ziemlich zwischen den Zeilen
versteckt. Daraus ist nicht leicht erkenntlich wieso sich genau dieses
Verhalten bei Luigi manifestiert (Thema: Postrouting ACCEPT / Prerouting
DROP).
Das hat nicht viel mit rumprobieren zu tun ;o)
Ich habe mir die Sache nochmal kurz angesehen. Meine Erinnerungen gehen da
leider auf ipchains und ipfwadm zurück... deshalb war ich mir auch nicht
mehr so sicher. Es gibt einen einzigen Hinweis auf der aktuellen
Netfilter-Seite (wenigstens was ich persönlich zum Thema finden konnte) und
zwar im NAT-HOWTO Kapitel 5 und 5.1.
Wenn jemand genaueres zum Thema findet, sagt mir bescheid!
Übrigens: ich habe mir kurz nochmal die Sache mit dem IDE-Raid angesehen.
Effektiv werden als richtiges IDE-HW-Raid nur 3ware-Systeme von einem
ungepatchten Linux-Kernel unterstützt.
Cheers,
Gunny
Günther Mair
Internet Engineer
ENERGIS Italia GmbH
Pfarrhofstrasse 60/A
I-39100 Bozen (BZ)
Tel.: +39 0471 254000
Fax: +39 0471 251617
Email: guenther.mair(a)energis.it
Web: http://www.energis.it
Peter Warasin
<Peter.Warasin@darkr An: lugbz-list(a)lugbz.org
ealms.org> Kopie: guenther.mair(a)energis.it
Gesendet von: Thema: Re: Antwort: [Lugbz-list] iptables
lugbz-list-admin@lug
bz.org
25.05.2003 13:06
Bitte antworten an
lugbz-list
hallo
On Fri, 2003-05-23 at 21:50, luigi wrote:
> Die filter-tabelle ist die einzige, die grundsatzlich nichts am
> Paket verändern kann. Die anderen beiden schon.
> Ich vermute, dass die Ketten aller Tabellen hintereindander
> abgearbeitet werden.
> Das würde einiges erklären.
bevor ihr da rumprobiert um sachen rauszufinden:
auf www.netfilter.org gibts genug dokumentation wo genau beschrieben ist
wie, welche chains fuer was gebraucht werden und wie das alles
funktioniert.
gibts sogar in mehreren sprachen und in mehreren formaten.
da steht z.b wie die pakete die filter passieren:
http://www.netfilter.org/documentation/HOWTO/de/packet-filtering-HOWTO.html…
_______________________________________________
http://www.lugbz.org/mailman/listinfo/lugbz-list
LUGBZ is pcn.it-powered
Hallo!
Ich bin zwar kein Experte in Sachen DHCP und habe auch nicht so schnell die
Möglichkeit etwas zu testen, aber grundsätzlich kann ich folgendes Sagen:
- mangle/nat Tabellen sind üblicherweise nur dazu da um "Sonderfälle" zu
handhaben und IP-Header im Ein-/Ausgang zu verändern; sie dürften keinen
Einfluß auf DHCP nehmen
- X-Windows Desktop-Manager (wie viele andere Client/Server-Anwendungen)
benutzen Unix- oder TCP/IP-Sockets um mit anderen Anwendungen zu
kommunizieren; das macht die Verwendung von "X-Clients" (oder nennen wir
sie zum besseren Verständnis "Network Clients" oder "Thin Clients") über
xdmcp erst möglich
- wenn die lokale Anmeldung nach Einsatz der FW-Tools nicht läuft, würde
das bedeueten, dass dies bei SuSE über eine öffentliche IP-Adresse erfolgt
(loopback ist ja frei).... Sinn und Unsinn sei dahingestellt; es gibt bei
SuSE allerdings irgendwo eine Konfigurationsdatei wo dies eingestellt
wird..... /etc/sysconfig/xdm oder /etc/X11/xdm oder irgendsowas.... bin mir
nicht mehr 100%ig sicher in der Sache (versuch evtl. kurz ein "lsof -i"
dann siehst du welche Anwendung sich lokal an welchen Port bindet)
Im Anhang die abgekürzte Version des gleichen Skripts unter Verwendung von
stateful connections. Ich habe das mit DHCP noch nicht getestet, aber denke
schon, dass das conntrack-Modul die Sachen erkennt. Nimm bei
Nicht-Funktionieren evtl. die state-Befehle weg, im Log sollte sich schon
einiges finden. Ausserdem ist es vielleicht nützlich (und korrekter) die
LOG-Befehle einzuschränken sonst ist dein Server bei viel Verkehr womöglich
innerhalb ein paar Stunden mit einem großen Logfile zugestopft.
Grüße,
Günther
(See attached file: fwtest.txt)
Günther Mair
Internet Engineer
ENERGIS Italia GmbH
Pfarrhofstrasse 60/A
I-39100 Bozen (BZ)
Tel.: +39 0471 254000
Fax: +39 0471 251617
Email: guenther.mair(a)energis.it
Web: http://www.energis.it
luigi
<in3dzz(a)gmx.de> An: liste lugbz <lugbz-list(a)lugbz.org>
Gesendet von: Kopie:
lugbz-list-admin Thema: [Lugbz-list] iptables
@lugbz.org
22.05.2003 11:44
Bitte antworten
an lugbz-list
Hallo Liste!
Kämpfe gerade mit iptables. Dabei habe ich zunächste versucht dhcp
für das LAN frei zu bekommen.
ref: SuSE-8.1, iptables 1.2.7a-17.
Hier das Skript
#!/bin/bash
#/root/fw-ipt/fw-start
# 0.1 - 14.5.2003
# Dieses Skript entfernt alle Regeln, Ketten und auch die Module.
# Es funktioniert bestimmt.
/root/fw-ipt/fw-stop
#################################Module
laden###########################################################
modprobe ip_tables
modprobe ip_conntrack
modprobe ip_conntrack_ftp
modprobe ipt_state
modprobe iptable_nat
modprobe ipt_MASQUERADE
echo "fw-start -- Module geladen."
#################################
IPT=/usr/sbin/iptables
LAN_INTERFACE="eth0" # Interface
zum LAN
LOOPBACK_INTERFACE="lo" # Loopback-Interface
LAN_IPADDR="192.168.1.1" # Adresse des
Lan-Interfaces
LAN_ADDRESSES="192.168.1.0/24" # LAN-Bereich"
BROADCAST_SRC="0.0.0.0" # Broadcast-Absender
BROADCAST_DEST="255.255.255.255" # Broadcast-Empfänger
########################################################################################################
$IPT -P INPUT DROP
$IPT -P OUTPUT DROP
$IPT -P FORWARD DROP
$IPT -t nat -P PREROUTING DROP
$IPT -t nat -P OUTPUT ACCEPT
$IPT -t nat -P POSTROUTING ACCEPT
$IPT -t mangle -P PREROUTING DROP
$IPT -t mangle -P OUTPUT ACCEPT
#Loopback freischalten
$IPT -A INPUT -i lo -j ACCEPT
$IPT -A OUTPUT -o lo -j ACCEPT
########################################################################################################
# DHCP
#source-address 0.0.0.0.68 dest-address 255.255.255.255.67
#dhcp-discover und dhcp-request benutzen das gleiche Muster
$IPT -A INPUT -i $LAN_INTERFACE -p udp -s $BROADCAST_SRC --sport 68
-d $BROADCAST_DEST --dport 67 -j ACCEPT
#source-address 192.168.1.1.67 dest-address 192.168.1.199.68
#dhcp-offer und dhcp-ack benutzen das gleiche Muster
$IPT -A OUTPUT -o $LAN_INTERFACE -p udp -s $LAN_IPADDR --sport 67 -d
$LAN_ADDRESSES --dport 68 -j ACCEPT
#source-address 192.168.1.199.68 dest-address 192.168.1.1.67
#Freigeben oder erneuern benutzen diese Muster
$IPT -A INPUT -i $LAN_INTERFACE -p udp -s $LAN_ADDRESSES --sport 68
-d $LAN_IPADDR --dport 67 -j ACCEPT
$IPT -A OUTPUT -o $LAN_INTERFACE -j LOG
$IPT -A INPUT -i $LAN_INTERFACE -j LOG
exit 0
Wenn ich nat/POSTROUTING,OUTPUT und mangle/OUTPUT nicht auf ACCEPT
setze, dann kann ich vom W98-Client (ausführen --> winipcgf -->
aktualisieren) die Adresse nicht mehr aktualisieren.
Ein Überprüfen der /var/log/messages sagt dann
lintsz01 dhcpd: DHCPACK on 192.168.1.199 to 00:a0:24:ef:94:a1 via
eth0
lintsz01 dhcpd: send_packet: Operation not permitted
Ein Überwachen des Interfaces (tcpdump -i eth0 "udp[2:2] = 67 or
udp[2:2] = 68] zeigt, dass eine Anfrage zwar ankommt, aber keine
Antwort abgeht.
Und hier die Fragen
1. Warum muß ich nat/POSTROUTING,OUTPUT und mangle/OUTPUT auf
ACCEPT stellen?
2. Damit dhcp funktioniert sollte ich also entsprechende Regeln auch
für diese drei Ketten anfügen? Wie kann sowas aussehen?
3. Diese Einstellungen verhindern auch die Anmeldungen am KDE bzw.,
wenn KDE bereits aktiv ist kann man keine neue Anwendung aufrufen.
Warum?
Danke für die Hilfe und bitte nicht laut lachen.....
Luigi
_______________________________________________
http://www.lugbz.org/mailman/listinfo/lugbz-list
LUGBZ is pcn.it-powered
Hallo,
hat jemand erfahrung wie man unter Linux Compact Flash verwendet?
Ich habe erst einen minipc OpenBrick (es wurde mir von der Liste
empfohlen und ist toll...) erworben www.openbrick.org mit einer
vorinstallierter Debian.
Jetzt wollte ich einmal drauf bastelln aber wollte zuerst eine
Sicherungskopie machen...
ich habe einen CF->PCMCIA adapter und verwende es mit meinem laptop.
Der PCMCIA adapter funktioniert, ich sehe dass ich eine IDE Festplatte
in den PCMCIA slots habe aber ich kann sie nicht mounten:
folgender fehler tritt auf:
get dev info on socket 0 failed: Resource temporarily unavailable
im kernel habe ich auch die option PCMCIA IDE support ausgewählt.
Hat schon jemand Erfahrung mit CF und CF->PCMCIA adapter unter Linux
gemacht und kann mir weiterhelfen?
danke
Diti
LOL....
vielleicht sollte man aber auch davon Rechnung tragen, dass es ausreichend
veranwortungsbewußte Leute gibt, die ihre Arbeit zu einer Zeit tätigen wo
sie im Fall von Ausfällen anschließend noch erreichbar sind. (Es gibt ja
auch einige die Wartungsarbeiten am Freitag durchführen.... und wenn übers
WE nichts geht dann geht halt nichts......)
;-)
Günther Mair
Internet Engineer
ENERGIS Italia GmbH
Pfarrhofstrasse 60/A
I-39100 Bozen (BZ)
Tel.: +39 0471 254000
Fax: +39 0471 251617
Email: guenther.mair(a)energis.it
Web: http://www.energis.it
??Wieso WebServer immer am Montagmorgen abstuerzen??
:-) gruesse Martin
ICT Weekly of May 23, 2003
...
======================
Websites don't like Mondays
======================
UK websites are more likely to crash on a Monday morning, not because
this is when hackers or viruses are most active, but because this is
when developers come in and implement ideas they had over the weekend.
Development staff are now a bigger threat to website uptime than hackers
and viruses combined, according to data taken from 70 leading sites over
a nine-week period. 'Manic Monday' syndrome often arises when web
developers tinker with the site after 'weekend inspiration'. This
results in more faults on a Monday morning than at any other time,
according enterprise applications specialist Attenda.
Attenda advises businesses to ensure that the work will have the
intended positive effects by putting stringent change control processes
in place, such as change management and a test server. This, along with
thorough pre-emptive testing and adequate roll-back provisioning, will
ensure that bad code does not take the site down.
VNUnet UK - May 16, 2003
http://nl2.vnunet.com/News/1140934
--
Unix _IS_ user friendly -
it's just selective about who its friends are!
_______________________________________________
http://www.lugbz.org/mailman/listinfo/lugbz-list
LUGBZ is pcn.it-powered
