On Oct 10, 2008, at 2:41 PM, Jeremy Chadwick wrote:
On Fri, Oct 10, 2008 at 06:54:32PM +0100, RW wrote:
On Fri, 10 Oct 2008 09:51:16 -0700
Jeremy Chadwick <[EMAIL PROTECTED]> wrote:
On Fri, Oct 10, 2008 at 12:45:04PM -0400, John Almberg wrote:
I just set up a new server with a very restricted PF configuration.
One problem: I can no longer install software with ports (i.e,
the / usr/ports collection.) I have to disable PF to do so.
Obviously not a great solution.
Am I correct in guessing that ports uses FTP to grab source files
from mirrors? I'm trying to figure out the smallest number of ports
(the TCP/IP kind) that I need to open in my firewall. I don't want
to enable incoming FTP requests, but do want to allow outgoing ftp
requests, I believe.
Am I on the right track, here?
See the fetch(1) man page. Try this first:
sh/bash: export FTP_PASSIVE_MODE=true
csh: setenv FTP_PASSIVE_MODE true
First off, this did solve the problem. Thank you, Jeremy.
Now, as to the why...
passive ftp has been the default for long time, fetch is called
with the -p option.
Let's give the users some actual detail, not terse one-liners which
will
induce more questions/confusion.
First off, libfetch (which is what fetch(1)) uses) itself DOES NOT
default to using FTP passive mode. You have to either pass the -p
option to the fetch(1) binary, or you have to set the FTP_PASSIVE_MODE
environment variable (which affects anything using libfetch).
Secondly, the ports framework (not pkg_* tools!), specifically
ports/Mk/bsd.port.mk, defines FETCH_ARGS with the -p argument to force
passive mode. This will be used for things like "make fetch". It
*will
not* be used for things like "pkg_add -r" or "pkg_add ftp://...";
The addition of the -p argument to FETCH_ARGS in ports/Mk/bsd.port.mk
was applied to HEAD on 2006/09/20. HEAD at that time is what became
FreeBSD 6.2. Of course, anyone updating their ports tree after that
date would also get the change; I'm just pointing it out so people
know
what the actual date was when -p was added to the default argument
list.
Now let's expand a bit on FTP_PASSIVE_MODE, because I'm absolutely
sure
someone will try to argue "that's also been turned on by default for a
long time"; I know how people are... :-)
FTP_PASSIVE_MODE being set by default on login shells was induced
by an
addition to login.conf(5) back in late 2001 (around the time of
RELENG_6). See revision 1.45 (not 1.44!) of src/etc/login.conf in
cvsweb.
But I'll remind people that login.conf only applies to login shells;
logging in on the console, or logging in to an account via "ssh
[EMAIL PROTECTED]". Most people I know of *do not* SSH into their servers as
root; they SSH in as themselves and use sudo. Some use su2, and some
use su
Root ssh access is disabled on this machine. I login as a normal
user, and then use sudo. The only time I use su is when sudo does not
work (another question for another day!)
Let's examine the behaviours:
$ env | grep FTP
FTP_PASSIVE_MODE=YES
As you can see here, the machine I've SSH'd into as myself does apply
login.conf's defaults. But...
$ sudo -s
# env | grep FTP
# exit
$ sudo -i
# env | grep FTP
#
H'mmm... yes. This is true on my machine, too.
The above scenario (as root) fails, since the FTP_PASSIVE_MODE
environment variable isn't being handed down from the login shell (my
user account) to the root shell spawned by sudo[1].
su, on the other hand, does it a little differently:
$ su
Password:
# env | grep FTP
FTP_PASSIVE_MODE=YES
And likewise, "su -l" behaves the same way.
Yes... although I must say I'm confused by this behavior... In fact,
it's the exact opposite of what I'd expect... from the su man pages
-l Simulate a full login. The environment is discarded
except for
HOME, SHELL, PATH, TERM, and USER. HOME and SHELL are
modified
as above. USER is set to the target login. PATH is
set to
``/bin:/usr/bin''.
So why isn't the FTP environment variable discarded?
The OP did not disclose how he was installing ports. A lot of users
think that packages == ports, so for all we know, he could be
pkg_add'ing things while using sudo and running into this.
I believe I am using ports. In this case, I had just installed and
configured PF (the first thing I do, now, when building a new machine.)
I then wanted to install NTP:
cd /usr/ports/net/ntp
make config; make install clean
This failed because the mirrors were not accessible.
If "make fetch" in an actual port is timing out, then he's either
doing
it on a machine with a ports tree prior to 2006/09/20 (see above), or
his outbound pf rules are so strict that the machine is absurdly
limited.
The machine has Production Release 7.0
My outbound PF rules are fairly loose. Inbound are very tight. This
is going to be a database server with 1 user. It's going to be
running one Ruby application that will accept new data and
periodically process the data. The only access is going to be through
a ssh tunnel.
The database has valuable information, so I want it to be as locked
down as possible.
I've advocated in another thread my displeasure for filtering outbound
traffic *solely* because of this exact scenario. Network admins seem
to think that "oh, HTTP is always going to use port 80", and likewise,
"oh, FTP is always going to use ports 20-21". Bzzzt. Nothing stops
a MASTER_SITE from being http://lelele.com:9382/.
No, I think I understand this.
[1]: The problem with sudo can be addressed; FTP_PASSIVE_MODE needs to
be added to the env_keep list in the default sudoers file. I know the
port maintainer, so I'll take this up with him so that users
(including
myself) don't keep getting bit by forgetting to set FTP_PASSIVE_MODE
after doing a sudo.
Whew... I can't say I understand all this. However, you've given me
my weekend reading assignment. Hopefully this will all be a bit
clearer by Monday morning.
Thanks, Jeremy.
-- John
_______________________________________________
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
