Linux-Setup Digest #503, Volume #19 Tue, 29 Aug 00 00:13:12 EDT
Contents:
Re: Connecting to the internet (John Todd)
Re: Install question - newbie- Laptop ("Patrick Lambert")
Re: Install question - newbie- Laptop (Garry Knight)
Linux Server ("Thomas Toh")
Re: Linux, XML, and assalting Windows (Bob Hauck)
Re: Linux, XML, and assalting Windows (Bob Hauck)
Re: Linux Server ("Thomas Toh")
Re: Books for Linux admin, related topics? (Martha H Adams)
How to make NumLock behave on my ThinkPad in KDE/Gnome? (Jerome Mrozak)
Re: Get rid of LILO in the MBR (joe flasch)
Re: Linux, XML, and assalting Windows ("paul snow")
Re: Recommendations on a good book. (joe flasch)
Re: Linux, XML, and assalting Windows ("paul snow")
Re: FTP client dir error (David Efflandt)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (John Todd)
Subject: Re: Connecting to the internet
Date: 29 Aug 2000 01:35:44 GMT
Reply-To: [EMAIL PROTECTED]
http://axion.physics.ubc.ca/ppp-linux.html
On Mon, 28 Aug 2000 13:11:50 GMT, Michael Potter
<[EMAIL PROTECTED]> wrote:
>Hi folks,
>
>I'm running Redhat 6.1 with a USR sportster 33.6 internal modem. I've got
>all the details on the modem and connecting to my ISP. Can someone explain
>or point me to a procedure that'll help me get connected?
>
>Thanks,
>
>Mike
>
>
--
_____________________
The lap of Linuxury
|<de in RH6
------------------------------
From: "Patrick Lambert" <[EMAIL PROTECTED]>
Crossposted-To: alt.os.linux.mandrake,comp.os.linux.portable
Subject: Re: Install question - newbie- Laptop
Date: Tue, 29 Aug 2000 02:31:54 GMT
"Gerardo" <[EMAIL PROTECTED]> wrote in message
news:39ab0a7e$0$51195$[EMAIL PROTECTED]...
> 1. Can I format the hard drive in my laptop with the Linux partition
system
> using a DOS program from a small DOS partition in my hard drive? What
> program do I use? At the end I will have a small DOS partition and the
rest
> of the HD ready for LINUX. (like a DOS Partition Magic...) .
You do your DOS things like create a partition and format it in DOS, and
leave the Linux things for Linux tools. Don't attempt to create a Linux
partition in DOS or it will fail. Simply leave empty space outside of your
DOS partition.
> 2. Is there a Linux Distribution (I prefer Mandrake) that I can put the
> "setup.exe" program in my small DOS partition in my HD, and install LINUX
> from the CD? (My floppy drive would not be available during the
> installation).
There is no .exe in Linux. Most distributions now have bootable CDs so if
your CD drive is bootable simply insert the CD and reboot, and the Linux
install starts.
>
> Thank you,
> Gerardo
> [EMAIL PROTECTED]
>
>
>
------------------------------
From: Garry Knight <[EMAIL PROTECTED]>
Crossposted-To: alt.os.linux.mandrake,comp.os.linux.portable
Subject: Re: Install question - newbie- Laptop
Date: Tue, 29 Aug 2000 03:26:42 +0100
"Gerardo" <[EMAIL PROTECTED]> wrote:
>1. Can I format the hard drive in my laptop with the Linux partition system
>using a DOS program from a small DOS partition in my hard drive? What
>program do I use? At the end I will have a small DOS partition and the rest
>of the HD ready for LINUX. (like a DOS Partition Magic...) .
Ranish Partition Manager (http://www.users.intercom.com/~ranish/part/)
--
Garry Knight
[EMAIL PROTECTED]
------------------------------
From: "Thomas Toh" <[EMAIL PROTECTED]>
Subject: Linux Server
Date: Tue, 29 Aug 2000 10:35:40 +0800
Hi there
Is there any difference in setting up Linux Server and workstation? If so,
how to server up the server? Any special hardware requirement for a Linux
server? Thanks!
------------------------------
From: [EMAIL PROTECTED] (Bob Hauck)
Crossposted-To: alt.os.linux,comp.text.xml,comp.os.linux.misc,comp.os.linux.advocacy
Subject: Re: Linux, XML, and assalting Windows
Reply-To: bobh{at}haucks{dot}org
Date: Tue, 29 Aug 2000 02:43:48 GMT
On Mon, 28 Aug 2000 02:28:10 GMT, paul snow <[EMAIL PROTECTED]> wrote:
>Bob Hauck <[EMAIL PROTECTED]> wrote in message
>news:[EMAIL PROTECTED]...
>> You've got it exactly backwards. Raw storage is just numbered blocks
>> on the disk. Filesystems are an abstraction created by the OS.
>No, you have it backwards. Where is the OS when your computer is off?
In a pile of bits on the hard disk.
>You turn your computer on. Where does the OS come from?
The boot loader reads it from the disk. The boot loader does not
necessarily know anything about the filesystem on the disk, although
some do. It just needs to know what block to start reading at, how
many blocks to read, and what address to jump to after the OS kernel is
loaded.
>In fact, given the same file system (no matter how it was
>constructed), you get the same behavior once the computer is turned on.
Which may or may not be what you want, since the identical disk could
be installed in a completely different computer. So now your tool has
to probe for hardware and the like too, unless the human tells it that
information.
Why are we building this again, instead of letting the OS do the work
for us?
>That is because your file system is nothing more than a persistent data
>structure. Nothing more. No magic.
It is nothing but a pile of bits until some software interprets it.
The persistent data structures are just patterns of bits that only have
meaning in the context of some software interpreting them. The boot
process is called "bootstrapping" for a reason.
On reset, the CPU hardware jumps to a reset vector in ROM and starts
executing what it finds as instructions. The ROM code causes the
hardware to read a boot block from disk. The boot block loads a kernel
from a known location (block) of the disk. The kernel loads drivers
and so forth and the system is running. I've simplfied and left many
details out out, but the point is that the software leverages it's way
step-by-step from a very simple understanding of what the bits on the
disk are (numbered blocks or similar that contain code to run) to a
state where they can be interpreted as files and directories. There is
no "chicken and egg" problem, just one piece of code loading another in
a carefully-orchestrated sequence. And the supposed data structures on
the disk do not drive the process until it is well along.
>But your file system is also the data structure that defines your OS
>and its applications. All the abstractions come into existence only
>after your software is loaded into memory from these data structures,
>and your software begins to run.
There *are no* data structures on a disk. There are blocks of bits.
Data structures are an abstraction created by software. Filesystems
are data structures. Different software (BIOS, boot loader, OS) can
and do treat the same data in different ways.
Filesystems as they live on disk are not self-describing. Sure, tools
besides operating system utilities can create filesystems and even read
and write them, but there is nothing there but patterns of bits until
some software somewhere interprets the bits.
This is why tools like Ghost can typically only be used to create exact
copies of a system. The tools don't know anything about the logical
structure of the data they manipulate. Don't get me wrong here, they
*could* know, and be able to manipulate the files "behind the back" of
the OS. That's been done. For example, you can take a DOS disk image,
mount it under Linux using the loopback device, edit it, and then write
it to a real disk. I can see that as something useful if you do mass
rollouts of identical systems, which is why people buy tools like
Ghost, but it seems cumbersome as a standard way to install software.
Your idea as I understand it is that one could have "generic" code to
do this manipulation of filesystems. You would describe the various
filesystem structures and things like the registry with XML-based
databases. You would have other databases that describe installation
requirements of your software, and a generic installer that does the
right thing based on these databases. All that is surely possible,
with a lot of effort, but I fail to see how the problem is simplfied by
doing that. You are essentially creating a specialized programming
language, but you seem to want to get away from programming.
On top of that, from a practical perspective, managing software from
outside the OS would seem to require rebooting the computer every time
you wanted to make a change. That is a step backwards for nearly all
server operating systems.
--
-| Bob Hauck
-| To Whom You Are Speaking
-| http://www.haucks.org/
------------------------------
From: [EMAIL PROTECTED] (Bob Hauck)
Crossposted-To: alt.os.linux,comp.text.xml,comp.os.linux.misc,comp.os.linux.advocacy
Subject: Re: Linux, XML, and assalting Windows
Reply-To: bobh{at}haucks{dot}org
Date: Tue, 29 Aug 2000 02:43:51 GMT
On Mon, 28 Aug 2000 04:06:33 GMT, paul snow <[EMAIL PROTECTED]> wrote:
>> My response is in the other part of the thread. I'm not going to
>> repeat it here. Basically, it sounds like you want some sort of
>> meta-language to define installation procedures. This meta-language
>> would generate install programs for each supported platform, or perhaps
>> a database of some kind that could be used by the universal installer
>> to actually do the install.
>>
>> You are aware that this is sort of how Installshield and RPM work,
>> right? The developer creates scripts that describe his installation
>> and the tool makes some assumptions, and everything usually works. You
>> just want to make these scripts more abstract so that they'll work on
>> different platforms, and make them editable so you can pre-configure
>> your local setup.
>>
>> Is that about right?
>
>Yes, I am quite aware that this is how Installshield and RPM work. That is
>why I claim that all the information needed to re-factor the problem is
>right there in our hands already.
>
>Just stop for a moment and focus on the problem. Forget the execution
>environment.
But 'correctness' of a software installation is in reference to a
particular execution environment.
>From a data structure point of view, who really cares if one file is a
>font file, one is executable, another is an initial database, a
>library,
Existing installation tools don't care. I agree that it doesn't matter
from the point of view of the installation. It might be helpful when
you are trying to troubleshoot to know what files are for though.
>So of course I don't want to generate install programs. Why would I?
So you can write one generic one and apply it to many different
platforms. I thought that's what you were after.
>Take the XML descriptions of what structures are required for each
>software component. Take any set of options that are givens for this
>configuration. Evaluate what should then be done to construct each
>software component into this data structure that happens to be a file
>system. Then just render the proper structures into storage, and keep
>track of what structures are being modified, and why.
Ok, you're glossing over a *lot* here, but let's go with that. You're
talking about modifying the existing data structures in order to
"render" your application into the proper places. Which means that
your tool has to know what the structures are and how to manipulate
them in ways that the OS will treat as valid (your program does, after
all, have to run). Which means you need some language for describing
the structures, which you will presumably build using XML. This sounds
a lot like writing install programs to me. You're just moving the
complexity from code to data.
>If this is being done outside the OS (logically or even literally)
>then there is really no reason the same facility can't manage
>different platforms (like Solaris, Windows, Palm pilots, Linux, etc.).
Well, on NT, Solaris and Linux it would _have_ to be done literally
outside the OS, as those don't take too kindly to changing the
structures out from underneath the OS while it is running. Bad things
happen when you do that.
>Do I get some advantages? You bet. I can manage an OS even if the
>OS isn't functional.
Yes, but on the flip side it _can't_ be functional while you are
managing it. That's a step backwards.
>I can detect if structures that should be locked down have been
>changed.
You mean, your existing tools can't tell you this? Mine can.
>If I involve the various Operating Systems in this process, and all
>the abstractions they define, then I complicate the process.
Only because you have glossed over a huge number of implementation
details by simply assuming that "data structures" are simpler than
"code". You can move the complexity back and forth between the two,
but that does not make it go away.
--
-| Bob Hauck
-| To Whom You Are Speaking
-| http://www.haucks.org/
------------------------------
From: "Thomas Toh" <[EMAIL PROTECTED]>
Subject: Re: Linux Server
Date: Tue, 29 Aug 2000 10:42:26 +0800
***** Sorry, I meant "If so, how to setup Linux server.......".
Thomas Toh <[EMAIL PROTECTED]> wrote in message
news:8of7sb$inb$[EMAIL PROTECTED]...
> Hi there
>
> Is there any difference in setting up Linux Server and workstation? *****
If so,
> how to server up the server?***** Any special hardware requirement for a
Linux
> server? Thanks!
>
>
------------------------------
Crossposted-To:
comp.os.linux,comp.os.linux.admin,comp.os.linux.networking,comp.os.linux.security
From: [EMAIL PROTECTED] (Martha H Adams)
Subject: Re: Books for Linux admin, related topics?
Date: Tue, 29 Aug 2000 02:48:36 GMT
I've shopped around for a few years, and I haven't ever seen one good
book on Linux administration. Further, the ones I've seen have no basis
in theoretical computer science -- they sort of float up there without
anything basic about how things work.
Brian Ball's book on Red Hat Linux has a lot of good in it for non-Red
Hat users. (I'm of the Slackware persuasion.) Publisher O'Reilly's
books are generally good.
Here's a suggestion. Get a Linux CDROM and find the bootdisks and
rootdisks subdirectories. Make yourself a bare.i bootdisk and a rescue
rootdisk. Do this *first*.
Now load the bootdisk and then the rescue disk into a computer with at
least 4 MB of memory. *This gives you a small complete Linux system*
and you can play with that to begin understanding Linux. You can play
with the vi editor in it -- you may not want vi for your work but it's
the Linux default for systems administration. And if you break the
little Linux somehow, or freeze or crash it, you just reboot and reload
and start over. So the rescue system is good for very much more than
just fixing up after a crash of your big HD-based system.
And once you have booted your rescue system, you can mount an empty
floppy and save useful work into it.
Cheers -- Martha Adams
------------------------------
From: Jerome Mrozak <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.x,comp.windows.x.kde,comp.os.linux.misc,comp.sys.laptops
Subject: How to make NumLock behave on my ThinkPad in KDE/Gnome?
Date: Mon, 28 Aug 2000 21:55:19 -0500
I have an IBM ThinkPad 1412 with Mandrake 7.1 installed. My problem
happens under Gnome and KDE, but I'll concentrate on KDE.
My NumLock key is accessed through Shift+ScrollLock, but it isn't being
done right under the X sessions. This is a problem for me because
various letter keys share the numlock functions ("u" or "4", etc.) and
my "ls -A" becomes "3s -A".
I have a graphical login, and when there the NumLock light stays OFF.
This is GOOD. During the login process the NumLock light turns ON.
This is BAD.
I can press Shift+ScrollLock and I hear a beep from the unit. The
displayed keys then change to (or from) NumLock mode. But that NumLock
light stays lit.
I've examined the various ~/.* files (.Xinits) for the user's home
directory. I've monkeyed with /etc/X11/.Xmodmap and XF86Config, but
things don't really get better. In fact, things get pretty funky, with
the keyboard shifting between cursor modes and number modes, but not
back to alpha modes.
So...can I get a short lesson on which X or KDE files I should use to
affect numlock? I suspect them because NumLock works OK in text mode.
Thanks,
Jerome.
--
Jerome Mrozak "Never buy a dog and bark for yourself"
[EMAIL PROTECTED] --"Slippery" Jim DiGriz
(the Stainless Steel Rat)
------------------------------
From: joe flasch <[EMAIL PROTECTED]>
Subject: Re: Get rid of LILO in the MBR
Date: Mon, 28 Aug 2000 22:21:01 -0500
To all,
One of the many hurdles when trying Linux is understanding how hard drives
work and how they boot. Most people have set up partitions on there hard
drive, but still things like MBR
are a mystery. When a system boots it loads a small program area off the hard
disk record 0 head 0 cylinder 0 (The MBR) . Every hard drive has this setup
for us by the hard drive maker. The default program looks for a partition
that is marked bootable/startable (more info in the MBR partition table
area.) If it finds it, it boots that partition. LILO (by most installs
default) over writes that small program with a small LILO program. Note: when
you load WIN 98 it doesn't over write the small MBR program. So LILO will
still be there. One way to get LILO off the MBR is DOS fdisk. And
undocumented option of "fdisk /mbr" will do it. Another way is to never load
LILO on the MBR. Only load linux on a primary partition and then load LILO on
that same partition. To boot LILO set that partition as (fdisk can do this)
startable/active and the default MBR program will always bring up LILO. To
turn LILO off, use fdisk to make another partition startable/active (very
simple and easy). I wish most installs would not put LILO on the MBR it is
always a source of much confusion.
Joe flasch
[EMAIL PROTECTED] wrote:
> Lilo will be destroyed by Win 98.
> When you install Windows, the installation overwrites on the master
> boot record, where LILO stands.
>
> The real problem would be to keep LILO...
>
> On Sat, 26 Aug 2000 15:57:18 +1000, "Stephan J"
> <[EMAIL PROTECTED]> wrote:
>
> >Hi all,
> >
> >I have installed LILO and now wish to install Windows 98 over it, I don't
> >know why? How can I get rid of LILO? I have created new partitions but
> >still get the LI when my new operating system boots.
> >
> >--
> >Stephan J
> >[EMAIL PROTECTED]
> >
> >
------------------------------
From: "paul snow" <[EMAIL PROTECTED]>
Crossposted-To: alt.os.linux,comp.text.xml,comp.os.linux.misc
Subject: Re: Linux, XML, and assalting Windows
Date: Tue, 29 Aug 2000 03:18:40 GMT
Christopher Browne <[EMAIL PROTECTED]> wrote in message
news:Y_Dq5.536726$[EMAIL PROTECTED]...
> Centuries ago, Nostradamus foresaw a time when [EMAIL PROTECTED]
> would say:
> >> As such, while it would be possible to describe all of a system using
> >> an XML document, that would probably be rather useless, as you need
> >> some substrate on which the XML is to be stored.
> >>
> >> In effect, XML _can't_ be the "base;" there needs to be a serial
> >> stream on which to place the XML-formatted material. You need
> >> something below it.
> >>
> >> It seems more useful to talk about that specific "thing that is
> >> below."
> >
> >Okay. Today we have an architecture where we store our programs and
> >data on a persistent medium (usually a hard disk). We could in fact
> >execute directly against the hard disk (skipping the need to implement
> >memory). There are two problems with this approach. The first is that
> >it would be slow. Yet that isn't necessarily the biggest problem. The
> >biggest problem is fault tolerance. If you have a crash, and the only
> >representation you have was the one you were running against, you are
> >simply out of luck. (Like typing byte codes in to a Commadore 64. It
> >crashes, and you end up starting over, typing the byte codes in all
> >over again.)
> >
> >So, what we have done is create an architecture where we keep a rather
> >stable instance of our configuration information on disk (generally in
> >a file system). Then if our system happens to crash, we can turn it
> >off, turn it back on, and be up and running again.
> >
> >We do this, even though we could simply save and restore our current
> >state to disk. Rebooting is necessary though, because we don't have
> >systems stable enough that we can be absolutely sure our image will
> >never crash.
> >
> >Looking at our storage vs. the memory images in a computer system, we
> >see a rather significant drop in complexity. Data structures in memory
> >being far more complex, and executable code being far more complex in
> >memory than that which exists in storage (EPROM).
> >
> >We also see storage showing a significantly reduced amount of change
> >when compared to memory. Files in storage tend to be rather fixed,
> >with few changes, while what is expressed in memory varies widely over
> >time. (Keep in mind, this is all relative! Compared to the return
> >stack, nothing on disk changes much, no matter how we pound the disk.)
> >
> >The point of what I am trying to get across is that storage really
> >serves as a working, dynamic definition of what programs can be
> >executed in memory, without requiring all those programs to be loaded
> >into memory at any given time. Almost everything that ends up
> >executing in memory was defined in storage.
> >
> >This model works very well, as long as storage is more static than
> >dynamic. And as long as storage remains rather simple, without too much
> >complicated structure.
> >
> >How does networking modify the model we have been using? It is
> >complicating the underlying structure. The mostly simple tree (a
> >directory structure) is becoming more of a general net, like a tree of
> >nodes with links into locations in other trees, on other computers.
> >
> >And storage is becoming more dynamic. I am installing and removing many
> >more applications than I was in the early 90s. And compared to what I
> >was doing in the 80's, I thought I was doing too many installations
> >then!
> >
> >One could argue at this point that we have already seen most of the
> >changes to computer systems that we are going to really need. That the
> >rate of installs and reconfigurations is going to slow down. I don't
> >really think so.
> >
> >We can get more stability without requiring major changes to existing
> >operating systems and applications by constructing a "storage"
> >for "storage". In other words, instead of rebooting solely to storage
> >(where if I have a failure, I am really out of luck), I can instead
> >access a more fundamental definition of storage. It is this layer that
> >can make use of definitions of storage constructed in XML.
> >
> >The result is a model that looks like this:
> >
> > X ==> Storage ==> Memory
> >
> >Where X is that "Thing Below" you wanted to talk about.
> >
> >Does this help?
>
> It explains a bit more about what you're talking about.
>
> You put forth the notion of having some sort of storage model.
>
> But none of what you say has the slightest bit to do with XML as
> distinct from other models for storing data.
To quote myself:
"XML is simply a way to describe structured data. So is a database.
Nothing magic. "
> It is easy to _claim_ that you have described some "more fundamental
> definition of storage," but you haven't demonstrated this.
No, I would claim that we already have a "more fundamental definition of
storage" in the form of a set of installation disks and manual procedures.
And a collection of decisions points gathered in one way or another during
what we call an installation process. And a collection of different and
incompatible abstractions for supporting this process across different
operating systems.
I think it is rather obvious if you think about what we do. So try this on.
Today we have
X => storage => memory
Where X is a set of installation disks, and the process of creating the
storage is a largely manually guided process. And this process is generally
unquie to the OS in question.
And it is also obvious that we don't *have* to do it that way, it is just
the way it has always been done. We could provide software in a standard
form so that one logical discription of our software can be used to install
it on multiple platforms.
There isn't anything about installing software into storage that can not be
described in abstract, in one form, such that it can be installed into
storage without an installation program or script supplied by the developer.
Make the description rich enough, and the developer can control what happens
without having to provide code to do it. At the same time, the more
information the developer pours into this description, the more solid
installations become. Which means that as problems are identified, the
description can be updated, and problems avoided.
If the installation and repair of software is performed in an execution
enviornment logically or literally separated from the OS, then such
installation and repair can be performed much more reliabibly. Mostly
because these descriptions do not interact with each other within X like
they do in storage or in memory.
> --
> (concatenate 'string "cbbrowne" "@" "acm.org")
> <http://www.hex.net/~cbbrowne/xml.html>
> "Life. Don't talk to me about life." -- Marvin
------------------------------
From: joe flasch <[EMAIL PROTECTED]>
Subject: Re: Recommendations on a good book.
Date: Mon, 28 Aug 2000 22:33:33 -0500
People ask me all the time for a good Linux book. The best and most update
Linux books
are on the Net in how-to's and the Linux doc sites. Most non net books are
out of date
by the time they hit the stores. It seems to be the how-to on ipchains / ip
maskerade is
a good start for routing and ISP like stuff. Check out www.linuxdoc.org
to start and some good search sites like www.google.com .
Joe Flasch
"Adam H." wrote:
> Thanks...
>
> I've had someone else email me about the first book (Securing &
> Optimising. I'll have to check out the other too)...
>
> Thanks again.
>
> Adam
>
> "The Contact" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]...
> > Yes their is, actually, their ARE. But before running to the bookshop,
> > you may look at http://www.linuxdoc.org/duides.html
> > "Securing and Optimizing Red Hat Linux" and "Linux System Administrating
> > Made Easy" are very recommendable, but other guides should be good too
> > (I haven't read those).
> >
> > --
> > The Contact
> > "Ones and zeros represent more than just the binary count.
> > They represent the mass knowledge we know as Internet."
> > ~~~~~~~~~~~~~~~~~~~~~~~~~~
> > [EMAIL PROTECTED]
------------------------------
From: "paul snow" <[EMAIL PROTECTED]>
Crossposted-To: alt.os.linux,comp.text.xml,comp.os.linux.misc,comp.os.linux.advocacy
Subject: Re: Linux, XML, and assalting Windows
Date: Tue, 29 Aug 2000 03:43:20 GMT
> As a wise man said, any advanced technology would appear as magic to a
> primative. No wonder you are having trouble installing software and are
> hoping for miracle solutions. I on the other hand am not a primative I
> understand just how the software and hardware operate. I can assure you
> there is no magic involved. It is technology based on sound scientific
> principles that make the computers work. Do you know that programs can
> exist without computer storage? So your statement that storage defines
the
> software is a invalid.
No, I did not know programs can exist without computer storage.
I would be very, very interested to learn about this new model of
computation that isn't based Turing's model of computation. After all, if
Turing's tape isn't storage, what is it?
------------------------------
From: [EMAIL PROTECTED] (David Efflandt)
Subject: Re: FTP client dir error
Date: Tue, 29 Aug 2000 04:07:04 +0000 (UTC)
Reply-To: [EMAIL PROTECTED]
On Mon, 28 Aug 2000 04:40:38 GMT, Shelley D <[EMAIL PROTECTED]> wrote:
>Hi,
>
>I am running ReHat 6.2 networked with a real Windows machine and a
>Virtual Windows machine using VMware. I have Samba running and have
>network access to all machines. I am using ipchains for IPmasquerading.
>So far so good.
>
>I can log into ftp sites but I can not get directory information from
>any site. I have my client set up for non-passive transfer. I know
>there must be a setting in my ftp configuration files somewhere, but
>which file and which setting? .
>
>The error is: Opening ASCII no print mode for data connection for ls -l.
>
>I can't get directory information from any ftp site.
>
>Thanks in advance,
>Shelley
Did you load the ip_masq_ftp module?
--
David Efflandt [EMAIL PROTECTED] http://www.de-srv.com/
http://www.autox.chicago.il.us/ http://www.berniesfloral.net/
http://hammer.prohosting.com/~cgi-wiz/ http://cgi-help.virtualave.net/
------------------------------
** 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.setup) 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-Setup Digest
******************************
