Linux-Networking Digest #433, Volume #11 Sun, 6 Jun 99 18:13:52 EDT
Contents:
Re: Linux: ICMP Redirect, IP Source Routing unterdruecken (Detlef Bosau)
HEARD STUFF ABOUT REDHAT (�SOP)
Re: Networking problems caused by upgrade to Red Hat 6.0 (Marc Kandel)
Re: Mount CD-ROM over network and report as CD-ROM (Onno Ebbinge)
ppp and ip address (Christian Palmer)
BNC "grounded type" terminators. (Christopher R. Barry)
Re: A good diald Question. (norman elliott)
Re: IP masq works, but can't read news (Barrett Richardson)
Re: Linux: ICMP Redirect, IP Source Routing unterdruecken (Detlef Bosau)
Re: Samba Printing (Paul Kube)
Re: Help! is pci nic compatible with 486 board? (David Efflandt)
Re: Linux vs. 3CON Etherlink III (Marc Kandel)
----------------------------------------------------------------------------
Date: 06 Jun 1999 21:09:00 +0200
From: [EMAIL PROTECTED] (Detlef Bosau)
Crossposted-To: de.comm.internet.routing
Subject: Re: Linux: ICMP Redirect, IP Source Routing unterdruecken
[EMAIL PROTECTED] meinte am 06.06.99
zum Thema "Re: Linux: ICMP Redirect, IP Source Routing unterdruecken":
> In comp.os.linux.networking Detlef Bosau <[EMAIL PROTECTED]>
> > wrote: abgetrennte Netzchen, da kann das Zeuch hemmungslos
> > rumsauen, das stoert mich nicht.
>
> Hmm... nun ja, wenn ein Grossteil deiner User MS Anwender ist, dann
> stoert es diese schon wenn dein NetBios Netzwerk nicht tut. Aber
> das musst du selber wissen was dir wichtiger ist :)
>
> Gruss
> Bernd
Was mir wichtig ist, ist eine Sache. Dass ich von irgend etwas leben
muss, eine zweite.
Ich muss halt sehen, einen vertraeglichen Kompromiss zu finden.
Wobei die Zahl der Alternativen nicht sehr gross ist. In der Wirtschaft
wirst Du bevorzugt Firmennetze betreuen oder aber bei einem ISP
arbeiten. Und letzteres will ich nicht. Also betreue ich Firmennetze,
und da geht es nicht ganz ohne Windows NT ab.
Die dritte Alternative kennst Du. Und das liegt nicht an mir alleine,
dass sich die nicht in der Weise stellt, die ich mir wuensche.
Wenn sich diese Alternative stellen wuerde, wuerde ich NT _nicht_
mehr sehen.
(Zumindest wenn die Unis in Deutschland da vernuenftig waeren. Bei
einer Bewerbung an einer solchen haben mir die Leute im dortigen
Netzwerkinstitut mit ihrer tollen NT-Ausstattung angegeben.)
Detlef
--
Detlef Bosau [EMAIL PROTECTED]
Bienroder Weg 79 Tel.: +49 531 303383
D2: +49 172 6819937
38106 Braunschweig, Germany Fax: +49 531 303364
>>>> PGP Public Key als Empfangsbestaetigung <<<<
## CrossPoint v3.1 R ##
------------------------------
From: [EMAIL PROTECTED] (�SOP)
Subject: HEARD STUFF ABOUT REDHAT
Date: 6 Jun 1999 13:49:13 -0500
I heard from a friend that redhat 6.0 has numerous backdoors when run
as a server, and that others are much safer.
Also, my goal is to setup a simple server which will have approx. 3
other computers connected to it. All three will be running win98. I
plan to put the server on a 486, which i heard will run linux at super
speeds. With that all said, and if i left anything out i needed to
say please say so, which is the best linux release to use. The LAN I
can setup myself, i just need to know what the server should use.
Thank you very much.
------------------------------
From: Marc Kandel <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux,alt.linux,alt.os.linux
Subject: Re: Networking problems caused by upgrade to Red Hat 6.0
Date: Sun, 06 Jun 1999 16:30:33 -0400
John,
If you do an "ifconfig -a" do you see the eth0? If so your problem is most
likely with the redhat6 dhcp client. They don't use dhcpcd they use /sbin/pump
and there is an upgrade for this from redhat.
HTH
Marc
John Pfeifer wrote:
> I recently upgraded from Redhat 5.2 to Redhat 6.0 and have experienced
> problems trying to configure my ethernet card for the @home network. I
> have an SMC EtherEZ (8416) ISA card that was functioning properly under
> RH 5.2. After upgrading, my connection no longer works. I have tried
> going through the steps I used to configure my connection under RH 5.2.
>
> pnpdump > intel.conf
>
> modify IRQ and BASE (IRQ is 10 and BASE is 0x0240)
> uncomment necessary lines
>
> isapnp intel.conf
>
> Executing the isapnp command gives me the following errors:
>
> Fatal resource conflict allocating IRQ10 (see /proc/interrupts)
> Fatal error occured executing requrest 'IRQ 10' --- further action
> aborted
>
> I checked the /proc/interrupts file to make sure that IRQ 10 is not
> being used
>
> /proc/ioports tells me that the address 0x0240 is the correct address
>
> How do I fix this problem? Any help would be greatly appreciated.
>
> Thanks,
> John
------------------------------
From: Onno Ebbinge <[EMAIL PROTECTED]>
Crossposted-To:
linux.redhat.misc,comp.os.linux.help,comp.os.linux.misc,comp.os.linux.questions,comp.os.linux.setup
Subject: Re: Mount CD-ROM over network and report as CD-ROM
Date: Sun, 06 Jun 1999 21:57:34 +0200
Thats the one I need! Please think hard or call your friend...
I would be very greatfull...
Thanks in advance,
Onno.
Greg Menke wrote:
>
> I've seen a little program which does this- you get a drive mapping,
> this program creates another one which gives a view of the first as if
> it were a CD. But for the life of me I can't remember its name. A
> guy I know was using it to get around stupid copy protection stuff.
>
> Gregm
>
> > >
> > > Onno Ebbinge <[EMAIL PROTECTED]> wrote in message
> > > news:[EMAIL PROTECTED]...
> > > > I want to mount a CD-ROM (or ISO file, or directory) that
> > > > resides on my RH Linux 6.0 server over my network and my
> > > > WIN NT 4 machine must report it as a CD-ROM.
> > > >
> > > > I've posted this question on some NT newsgroups but there
> > > > were mostly brain dead people...
> > > >
> > > > I think I need a NT 4 device driver who can pull this off
> > > > but I can't find one. If it's really necessary I can write
> > > > the driver (I have the NT 4 DDK stuff) but I prefer a download...
------------------------------
From: Christian Palmer <[EMAIL PROTECTED]>
Subject: ppp and ip address
Date: Mon, 07 Jun 1999 07:38:34 +0000
This is a multi-part message in MIME format.
==============394481B3E5434DA2A218CEDF
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Every time I use my ppp script I get the same ip address as my eth0.
I'm connecting to a windows nt ras server.
Attached is a copy of my ifcfg-ppp0 if that helps.
christian
[EMAIL PROTECTED]
==============394481B3E5434DA2A218CEDF
Content-Type: text/plain; charset=us-ascii;
name="ifcfg-pppC"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
filename="ifcfg-pppC"
DEVICE=ppp0
PERSIST=yes
DEFROUTE=yes
ONBOOT=no
DEBUG=yes
INITSTRING=ATZ
MODEMPORT=/dev/modem
LINESPEED=38400
ESCAPECHARS=no
DEFABORT=yes
HARDFLOWCTL=yes
DEVICE=ppp0
PPPOPTIONS=
DEBUG=
PAPNAME=DOMAIN\\username
REMIP=
IPADDR=
BOOTPROTO=none
MTU=
MRU=
DISCONNECTTIMEOUT=
RETRYTIMEOUT=
USERCTL=yes
==============394481B3E5434DA2A218CEDF==
------------------------------
Subject: BNC "grounded type" terminators.
From: [EMAIL PROTECTED] (Christopher R. Barry)
Date: Sun, 06 Jun 1999 21:01:41 GMT
Are any of you familiar with the "grounded type" BNC terminator? When
I bought all my networking hardware last week the standard 50 ohm
terminators without the little grounding chain were $5.00 a pop, but
the grounded type were $0.88. They are also 50 Ohm and the back of the
package seems to indicate they will work fine without connecting the
grounding chain to anything. Is this correct? A few days ago when I
was fiddling around with the back of my PC where all of my cards are
plugged in, I touched the grounding chain and got a surging, throbbing
jolt. That chain is just dangling there and if it touched the metal
chassis of my case I get a feeling the consequences might not be so
great....
Christopher
------------------------------
From: norman elliott <[EMAIL PROTECTED]>
Subject: Re: A good diald Question.
Date: Sun, 06 Jun 1999 21:25:38 +0000
"Walter L. Williams" wrote:
> Greetings all
>
> I havent had the need (or the time (I have a wife)) to read from this
> usnet group
> for a while. Besides my Linux box (SuSE) has been working great.
>
> In my SuSE system is the YaST program. Which is used to setup various
> things in my system. I used it to setup my PPP connection with my ISP
> useing diald.
>
> Diald seems to have a little habbit of dialing out when ever it wants
> to.
> And sometimes for no apperent reason.
>
> Is there a way to adjust diald to only dail out when it looking for a
> URL?
> It seems to be a little TOO sensitive.
>
> Any comments will be appreciated.
>
> Walter L. Williams
When you say diald seems to dial out without reason perhaps it is just
that
have your mail and newsgroups open. By default the mail server is
queried
periodically for fresh mail.
best wishes,
norm
------------------------------
Crossposted-To: news.software.nntp
Date: Sun, 6 Jun 1999 17:04:49 -0400
From: Barrett Richardson <[EMAIL PROTECTED]>
Subject: Re: IP masq works, but can't read news
On Sun, 6 Jun 1999, Mike wrote:
>
> 224 data follows
>
> and then lots of nothing!
>
Another option is to get acquire the TIS FWTK code. There is an NNTP
proxy there. You have to send an e-mail to acquire the code.
Directions are at
ftp://ftp.tis.com/pub/firewalls/toolkit/README
------------------------------
Date: 06 Jun 1999 22:01:00 +0200
From: [EMAIL PROTECTED] (Detlef Bosau)
Crossposted-To: de.comm.internet.routing
Subject: Re: Linux: ICMP Redirect, IP Source Routing unterdruecken
[EMAIL PROTECTED] meinte am 05.06.99
zum Thema "Re: Linux: ICMP Redirect, IP Source Routing unterdruecken":
>
> >Das alles sind Aktivitaeten, die derzeit paketweise laufen.
>
> Alle diese Funktionen brauchst Du in einem zellenbasierten Netzwerk
> auch, wenn Du jemals eine End-zu-End-Datentransparenz herstellen
> willst.
>
> Du sortierst halt Zellen, quittierst, routest/routest um (bei
> Ausfall einer Leitung), usw.
>
> Und, was hast Du gewonnen?
>
Zunaechst mal sollten wir daran arbeiten, etwas mehr die Layer zu
trennen. Ich habe bei unseren letzten Postings mit SONET und ATM
den Eindruck gewonnen, dass wir an dieser Stelle sehr unpraezise
geworden sind.
Das fuehrt zu Verwirrung und Entgleisungen.
Nun zu Deiner Aussage.
Ich habe noch gar nichts zu Quittungen und dergleichen gesagt.
Eben hier verhaelt sich TCP (vorsicht! Layerwechsel!) auch undifferenziert.
Es muss definiert werden, was ueberhaupt gewuenscht ist.
Eine virtuelle Leitung kann z.B. Videodaten uebertragen. Hier ist
die Prioritaet der Zeitbezug. Ein einzelner Bit-Dropout in 5 Minuten
wird dem Betrachter deutlich weniger auffallen als der "Flackerer",
der durch eine Retransmission der Bilddaten entstehen wuerde. Hier
ist es sinnvoll, den Zeitbezug aufrecht zu erhalten und Ausfaelle
zu interpolieren.
Ein anderer Fall ist die Beschriftung eines WORMS zur Datenarchivierung
in einer Bank. Hier ist die Prioritaet die Datenintegritaet, dabei
ist der Zeitbezug nicht entscheidend.
Derzeit verfuegbare Protokolle des Layer 4 bieten hier keine Unterscheidung.
TCP setzt willkuerlich die Prioritaet in der Datenintegritaet.
> >Wenn ich einen PVC in einem switched network habe, arbeite
> >ich mit einem zu Beginn der Verbindung festgelegten Source Route
> >Pfad.
>
> Und was machst Du, wenn eine Leitung auf diesem Pfad ausfaellt?
Das ist zu vereinbaren.
Eine TCP/IP Leitung kann per Denkparadigma gar nicht ausfallen.
(Nun ja, in der Tat definiert man irgendwelche Timeouts, aber die
liegen jenseits von gut und boese.)
Nach dem TCP/IP Denkparadigma gibt es fuer ein Datagramm keine Reisezeit-
beschraenkung.
Es geht noch weiter: In der Realitaet hast Du ueberhaupt keine Information
darueber, ob zwischen zwei Endgeraeten Deiner Kommunikation ueberhaupt
eine Verbindung besteht. Das, was heute in "The Internet" laeuft,
ist hier simpler Blindflug im Nebel und mit leerem Benzintank.
Hier sind Vereinbarungen noetig.
- Ist ueberhaupt eine Ersatzwegschaltung vorzusehen?
- In welcher Zeit muss eine Ersatzwegschaltung bereitstehen?
- Muss der Ersatzweg qualitativ dem ausgefallen Weg vergleichbar sein?
Gerade _hier_ sind Entscheidungen zu treffen, die den Layer 2 betreffen.
In der Regel hast Du an dieser Stelle ueber die Funktionen auf Layer 2
aus TCP/IP Sicht nur begrenzte Kenntnis. Automatismen helfen Dir
nicht weiter, weil Du etwa beim Rueckfall von einer dynamischen auf
eine statische Route zwar eine Route angibst, deren Funktion Du
_erwartest_. Aber ob diese Route funktioniert, und welche Qualitaet
sie hat, weisst Du nicht.
Hier gibt es fuer mich eigentlich zwei Faelle.
1. Definierter QoS. Dann habe ich die Kommunikation auf Layer 2 durch-
definiert, incl. QoS Parameter, definierter Ersatzwegeigenschaften
und -verfuegbarkeit, average fail over time, maximum fail over time,
die Liste liesse sich fortsetzen.
2. Best Effort Delivery. Auf Deutsch: Wenn's loept, dann loept's, wenn
nicht, dann schaumermal.
Im "The Internet" ist die zweite Variante heute ueblich.
Die erste Variante wird heute mit einer Mischung aus Networkmanagement-
software, Pager, Nachgucken, Handy, Manpower und Beten aufrechterhalten ;-)
In der Tat faellt mir dabei auf, dass hier die meisten Vertraege sehr
nachlaessig formuliert sind. In den wenigsten Vertraegen sind definierte
Kommunikationswege sowie deren Eigenschaften und Verfuegbarkeit
explizit ausgewiesen.
>
> Was genau das ist, was ein ATM-Switch tut. Er schaut auf die ATM-
> "Zieladresse", sucht sich die passende Leitung, setzt eine (fuer
> den naechsten Switch gueltige) ATM-Zieladresse ein, und forwarded
> die Zelle.
Der Switch "sucht" keine passende Leitung. Es wird kein Suchalgorithmus
angewendet, sondern aus einem Index der Wert abgegriffen.
BTW ist die VPI/VCI/Port Kombination keine ATM-Zieladresse.
>
> [..]
> >Beim Cellswitching habe ich den DLCI 10. Und da schaue ich in
> >die Tabelle, da habe ich die 10: neuer DLCI ist 7, Ausgangsport
> >ist 8.
>
> Was ziemlich dem Mechanismus des Route-Caches einer Cisco
> entspricht (da stehen auch ggf. MAC-Adressen der Next-Hop-Router
> drin, usw.)
Solange die ankommenden Pakete passen. Das Problem ist, dass Du
ein nichtdeterministisches Verhalten hast. Hinzu kommen nichtdeterministische
Stauungen, etwa bei Ethernet, keinerlei Kontrolle ueber die
auf der Transportstrecke angetroffenen Netztechnologien und
dergleichen k.o. Kriterien fuer Quality of Service mehr.
> >habe ich, nur mal so als Orientierung, teilweise "nur" DLCIs von
> >0 bis 1023. Also 1024 Tabelleneintraege fuer maximal 1024
> >Channels. Das reicht fuer viele Faelle absolut aus.
>
> ... solange ich mich in kleinen Netzen bewege. Auf einem grossen
Naja, diese kleinen Netze koennen schon recht gross sein. Hier
verwechselst Du vermutlich lokale DLCIs mit globalen Adressen.
1024 DLCIs auf einer Leitung findest Du praktisch nur im
Interswitchlinkbereich. Hinzu kommt, dass Du in den Switching-Tables
auch noch Ports als Routingparameter hast. Du kommst also schon
mit 1024 DLCIs recht weit ;-)
Aber das ist alles Definitionssache.
> Backbone-Router habe ich so viele parallele virtuelle Verbindungen
> ("Flows"), dass diese Tabelle sofort voll ist. Ergo: Dein System
> skaliert nicht, damit ist es gestorben.
Langsam bereitet mir diese Diskussion etwas Muehe, am Rande
gesagt.
Ich habe Dir den Wert fuer DLCIs fuer uebliche Node Sites bei Frame
Relay genannt, ueber die dann in der Regel Point to Point PVC's
gelegt werden. Dafuer sind 1024 Kanaele durchaus ausreichend.
Ich habe ferner erwaehnt, dass das ein Beispiel war und konfigurierbar
ist.
In einer ATM Zelle hast Du am UNI 8 bit VPI und 16 bit VCI.
Also 24 bit Virtuelle Kanaele _pro_ Port.
Am NNI, darueber unterhalten sich dann die Cell-Switches, hast Du
12 bit VPI und 16 bit VCI, als 28 bit pro Port. 268435000. Also
knapp 270 Millionen Kommunikationen auf _einem_ Port, und der Port
ist _immer_ mit ein Adresskennzeichen, das den VCC auszeichnet,
sollten fuers erste ausreichen.
Ich habe zudem gesagt, ATM sei ein Denkparadigma. Also ich habe
auch kein Problem damit, noch mal 20 Bit zu spendieren, wenn
es sein muss.
>
> Real-World-Zahlen von einem mittelgrossen ISP an einem
> traffic-armen Samstag:
>
> > sh ip cache flow
> ...
> IP Flow Switching Cache, 4456448 bytes
> 1374 active, 64162 inactive, 249938702 added
Ja? Wieviele Routeneintraege sind das? Mehr als 270 Millionen
pro Interface?
>
> 10^-9 ist eine fuer IP-Anwendungen voellig ausreichende Fehlerrate:
> auf eine gegebene TCP-Verbindung kommt im Durschnitt genau *gar
> kein* verlorenes Paket.
"gar kein" ist keine Aussage. In Service Level Agreements steht
da bei mir eine Zahl. Und in dieser Zahl steht z.B. drin,
dass ich gewisse Dateien in einem gewissen Zeitraum ausliefern
muss.
In vielen praktischen Faellen ist die erwaehnte Fehlerrate
ausreichend.
Ich habe allein in diesem Jahr mehrfach Faelle erwaehnt, wo
sich reale Bitfehlerraten mit Retransmissions so aufgeschaukelt haben,
wo die Arbeitsfaehigkeit beim Kunden nicht mehr gegeben war
und mich im Urlaub morgens um 7.00h ein verstoerter Kunde anrief,
seine Produktion stehe.
In der Tat war die Fehlerrate da sicher hoeher als 10^(-9).
Dennoch moechte ich hier die Moeglichkeit zur sauberen Definition
bieten. Es wurde in der Vergangenheit mehrfach von Szenarien
wie "Internetoperationen" gesprochen. Operateur in Boston,
ferngesteuertes, stereotaktisches Equipment in Muenchen, schwierige
Hirnoperation. Gerade die Heise Presse oder Vertriebler von
ISPs erzaehlen sowas.
Also ich wuerde als Patient heute derartige Operationen verweigern.
Gerade bei solchen Kommunikationen muss ich die Verfuegbarkeit
zahlenmaessig abschaetzen koennen.
Gegenwaertig kann ich das genau _nicht_.
Gegenwaertig laeuft IP fast nur ueber Best Effort.
> >und das ist bei 2.4 GBit/s Backbone Leitungen schon ganz
> >bemerkbar.
>
> Das sind so viele *verschiedene* Verbindungen, dass hier und da mal
> ein einsames kaputtes Paket ueberhaupt nicht ins Gewicht faellt.
>
> Mit vereinzelten Paketverlusten MUSS TCP zurechtkommen
> (Router-Crash, um nur mal einen nicht zu leugnenden Grund zu
> nennen), warum also an anderer Stelle mehr Aufwand treiben als
> noetig? Das fuehrt auf Dein eigenes Argument vom SLA - soviel
> Aufwand wie noetig, und *nicht mehr*.
SLA ist Definitionssache. Eine Definition haben wir hier nicht
gegeben.
Im Falle der Internetoperation von eben wuerde ein Routerausfall
ohne eine definierte maximum fall back time schlichtweg den
Tod des Patienten bedeuten.
Ich rede hier nicht von den Faellen "Tante Elfriede surft, um
ein neues Futter fuer Hamster Waldemar zu suchen." Aber wenn
von QoS geredet wird, und hin und wieder wird das gebraucht,
dann muessen wir die Dinge schon genau nehmen.
Nicht jeder braucht einen definierten QoS. Aber vereinzelt
wird definierter QoS nachgefragt werden.
>
> [..]
> >auch _NUR_ da. D.h. unser lieber Carrier wird sich noch ganz
> >gewaltig umschauen, wenn da jemand z.B. IPX macht, wo die
> >Pruefsumme ueblicherweise nicht gepflegt wird. Oder auch nur UDP,
> >wo die Retransmission nicht so penetrant laeuft wie bei TCP,
> >sondern die Clients in der Regel etwas verhaltener reagieren. Das
> >verbluefft die Leute immer wieder, wenn dann eine simple
> >Routerkonfiguration von 2 kByte nicht per tftp ausgeliefert werden
> >kann.
>
> Das ist doch alles Kaese. Rechne Dir mal Deine Zahlen von oben in
> prozentuale Paketverluste um. Das ist derartig minimal, dass es
Ja. 10^-9 Paketfehlerrate auf Layer 2 heisst bei einem konkreten
Netwareserver, dass dort nach einem Tag betrieb nicht eine heile
Datei mehr drauf ist.
Den Fall mit tftp haben wir aktenmaessig dokumentiert, da kann
ich Dir den Verlust in DM vorrechnen.
> (z.B. excessive collisions an einem Switchport), Anwendungen, die
> damit nicht zurecht kommen, gehoeren auf den Sondermuell.
Leider ist z.B. Excel in Bueroumgebungen recht verbreitet.
Es soll sogar Anwender geben, die lesen ihre Mail mit MS Outlook.
>
> [..]
> >IP-Implementierungen (ich kann nicht sagen, ob aller, darum
> >sage ich mancher, weil ich mich da auf die beschraenken muss,
> >die ich vom Sniffer kenne) im Fehlerfall schlicht desastroes ist,
> >um das zurueckhaltend auszudruecken. Manche Stacks reissen da ganz
> >einfach den Kredit auf bis der Arzt kommt und donnern die
> >eh schon ueberlastete und fehlerbehaftete Leitung mit
> >Retransmissions dicht bis nichts mehr geht.
>
> RTRFC. Da gibt's genaue Dokumente drueber, wie das sein *muss*,
Ja und?
Es ist mir herzlich egal, was in Dokumenten drinsteht, wenn ich
4 Wochen, dokumentierter Debug Zeit Fehlersuche gebraucht habe.
> und welche Implementationen in welcher Form dagegen verstossen.
> Mit Verlaub, Du erzaehlst Unsinn.
Gert, ich habe mir Deine Verbalinjurien jetzt lange genug
angehoert. Ich habe es nicht noetig, mir hier von irgend einem ISP
Schuesse unter die Guertellinie anzutun, wenn ich an einigen Dingen,
die ich hier beschrieben habe, konkret ueber Wochen Ueberstunden
eingelegt habe und die Dinge aktenmaessig objektiv und nachweislich
dokumentiert sind.
Wenn Du meine Argumentationen nicht nachvollziehen kannst,
kann ich nichts dafuer.
Ich bin gerne bereit, Sachverhalte zu diskutieren.
Aber wenn ich Dir jetzt nochmal eine Nachhilfestunde in Sachen Netz
geben soll, nur weil Du mich hier oeffentlich als Luegner diffamierst,
stelle ich Dir die Zeit kostenpflichtig in Rechnung.
Wenn Du meinst, dass einige Debugzeiten des letzten Jahres nur
in meiner Phantasie existieren, musst Du mir schon mit einem
psychiatrischen Gutachten kommen, dass ich am False Memory Syndrome leide.
Bis dahin lasse ich mich nicht von Dir beleidigen, weil Du Monate,
in denen ich gearbeitet habe wie ein Schwein hier einfach als
Unsinn abtust und meine Arbeit, und damit auch meine Person,
diskreditierst.
Das muss ich mir nicht gefallen lassen. Von niemandem.
Detlef
--
Detlef Bosau [EMAIL PROTECTED]
Bienroder Weg 79 Tel.: +49 531 303383
D2: +49 172 6819937
38106 Braunschweig, Germany Fax: +49 531 303364
>>>> PGP Public Key als Empfangsbestaetigung <<<<
## CrossPoint v3.1 R ##
------------------------------
From: Paul Kube <[EMAIL PROTECTED]>
Subject: Re: Samba Printing
Date: Sun, 06 Jun 1999 13:51:58 -0700
Trevor Porter wrote:
> ... when I set up my Linux (RH6) box to print using Samba printing,
> using the appropriate share name and the relevant username and password, the
> printer prints to the local Linux queue, which flashes the job for a second
> and then empties but the job never shows up in the NT queue.
I just managed to get things working, printing from my Linux 2.2.5
(Debian)
machine to an Epson Stylus 800 hanging off an NT 4.0 SP4 box.
Let me just tell you what I did, before I forget; maybe it will help
you,
or someone else who tracks this down in a future search.
1. Get Samba basically working between the Linux and NT machines.
Among
other things, the installation should have set up a smbpasswd entry for
every existing Linux account.
2. Set up an account on the NT machine that you will use for printing.
As far as I can tell, the name of this account has to be identical to
one
on your Linux host, though the passwords don't have to be. I used
"lp", and set it up with no home directory and no group memberships.
3. Sitting at the NT box, go to my computer>control panel>printers>,
click on the relevant printer, then go to file>sharing, enable the
printer share,
and name the service. Now click the security tab and make sure the
printer permissions include the account you set up in step 2. Including
"Everybody"
also seems to do it, by---well, by giving everybody permission. I can't
resist
one small comment about what a lousy interface this is.
4. Now on the Linux side you should be able to do a
smbclient \\\\NTMACHINE\\PRINTERSERVICE THEPASSWD -U PRINTACCT -N
with the args in CAPS replaced according to your setup. Once connected,
try the print FILENAME command to make sure you can print something.
If not, fix things at this level before going on.
5. Make e.g. /etc/samba/smbprint look something like this:
=======================================================
#!/bin/sh
# This script is an input filter for printcap printing on a unix
machine. It
# uses the smbclient program to print the file to the specified
smb-based
# server and service.
#
# Set up an entry in /etc/printcap similar to this:
#
# smb:\
# :lp=/dev/smb:\
# :sd=/var/spool/lpd/smb:\
# :sh:\
# :af=/var/spool/lpd/smb/acct:\
# :mx#0:\
# :if=/etc/samba/smbprint:
#
# which would create a unix printer called "smb"
# with input filter :if that points to this script.
# You will need to create the spool directory /usr/spool/smb
# with appropriate permissions and ownerships for your system.
# The "dummy" device /dev/smb is used only for locking; /dev/null
# might work as well.
# Set these variables as appropriate for your installation:
# server is the name of the print server
server=NTMACHINE
# service is the name of the shared print service on that server
service=PRINTERSERVICE
# user is the name of the user on the server that will use the print
service
user=PRINTACCT
# password is the password of that user on the server
password=THEPASSWD
# prefilter is the pre-filtering script to use. Use /bin/cat for no
prefiltering
prefilter=/etc/magicfilter/stylus800-filter
# logfile is where diagnostics will be logged
logfile=/var/spool/lpd/smb/smb-print.log
# Log some info. Change the >> to > if you want to save some space.
/bin/echo "server $server, service $service, user $user, filter $filter"
>> $logfile
# Pipe the job through the prefilter and thence to smbclient print
( /bin/echo "print -"
$prefilter
) | /usr/bin/smbclient "\\\\$server\\$service" $password -U $user -N >>
$logfile
=======================================================
6. Do what the comments in that script say about making the
/etc/printcap
entry, and creating a spool directory. Of course make sure the
variables
in the script are set appropriately. You can do it with .config files
that
reside in spool directories and get a more flexible arrangement that
works
transparently with different printers; but I only have one so this
simpler
approach is fine for me.
7. Then lpr -P<whatever you called your printcap entry> should work.
8. A small note about security: If lpr is setuid root (this is
typical)
you can chown and chgrp the smbprint script to lp, and chmod 700 it.
This makes the presence of the plaintext password in it a little less
troubling. Beyond that, I'm running this arrangement on a small
firewalled
LAN where I directly controll all the machines, and I sleep well; but
anyone
administering a more open environment will need to think harder about
the issues.
> ps one the printing HOW-TOs refers to a "Printing in Windows Mini-Howto"
> which I am unable to find??
Right, I couldn't find it anywhere either. So, consider the above a
"Printing in Windows Micro-Mini-Howto".
Hope it helps,
--Paul Kube
Computer Science and Engineering, UCSD
------------------------------
From: [EMAIL PROTECTED] (David Efflandt)
Subject: Re: Help! is pci nic compatible with 486 board?
Reply-To: [EMAIL PROTECTED]
Date: Sun, 06 Jun 1999 16:42:34 -0400
On Tue, 1 Jun 1999 21:57:26 GMT, Rey Kanzaki <[EMAIL PROTECTED]> wrote:
>Hi,
>
>Another newbie asking for help here. (hardware newbie to be exact).
>I'm using an old 486 box as a gateway and occassionally, the box
>hangs. The problem goes away after a reboot. I'm using the faster
>100mb pci nic (from Realtek) after having replaced my reliable but
>slower 10mb isa nic. I've never had problems with the old isa nic,
>so I'm wondering if the problem is that 486 boards simply do not
>support new pci hardware. I was told that the new pci specification
>(2.1??) may not be compatible with old 486 boards.
>
>So I ask, is this a common problem? If there is a faq or how-to
>that can answer this question, please point me in that direction.
>My 486's have been good to me, and I'll only replace them if left
>with no other choice. Please save them... :) Thank you.
Even 60, 75 and some 90 MHz Pentiums (PCI 2.0) have trouble running
PCI 2.1 network cards, so it would not be surprising that a 486 croaks. I
had one working for months on a P-5 60 until I added RAM. Then it would
not run at all, even with RAM removed, until the network card was removed.
The mfr was surprised that it worked at all. Now using an ISA card.
--
David Efflandt [EMAIL PROTECTED]
http://www.xnet.com/~efflandt/
------------------------------
From: Marc Kandel <[EMAIL PROTECTED]>
Subject: Re: Linux vs. 3CON Etherlink III
Date: Sun, 06 Jun 1999 16:44:08 -0400
Jhumur,
I had the same problem and solved it (after fighting with it for almost a week
... recompiling kernels ... looked at the driver sources ... ) by getting a new
NIC. I got an eepro 10/100 PCI and it works great. Someone on the
linux.redhat.misc said he got it to work but has yet to forward me the
resolution (I'd still like to use it as a second NIC). If he does I will post
it here!!
Good luck!!!!
Marc
Jhumur wrote:
> The OS desn't seem to recognize my 3COM NIC (3C509B-TPO). During boot it
> hangs for 15-20 secs while "bringing up interface eth0", and then fails.
> What's my solution?
------------------------------
** FOR YOUR REFERENCE **
The service address, to which questions about the list itself and requests
to be added to or deleted from it should be directed, is:
Internet: [EMAIL PROTECTED]
You can send mail to the entire list (and comp.os.linux.networking) via:
Internet: [EMAIL PROTECTED]
Linux may be obtained via one of these FTP sites:
ftp.funet.fi pub/Linux
tsx-11.mit.edu pub/linux
sunsite.unc.edu pub/Linux
End of Linux-Networking Digest
******************************