Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 27 Jun 1998 08:02:15 +0000 (GMT)
From:      Terry Lambert <tlambert@primenet.com>
To:        freelist@webweaver.net (Nicole Harrington)
Cc:        tlambert@primenet.com, freebsd-isp@FreeBSD.ORG, freebsd-advocacy@FreeBSD.ORG, opsys@mail.webspan.net
Subject:   Re: Packet Engines - FreeBSD + more
Message-ID:  <199806270802.BAA24158@usr08.primenet.com>
In-Reply-To: <XFMail.980626230553.freelist@webweaver.net> from "Nicole Harrington" at Jun 26, 98 11:05:53 pm

next in thread | previous in thread | raw e-mail | index | archive | help
> > Well, for customer-bound mail traffic, it's not really a "server".  For
> > SPAMmers and for FTP/HTTP servers, I could see there being a problem.
> > You could easily block that by firewalling HTTP/FTP packets without
> > the response bit set.  8-).  I expect you want them to pull data instead
> > of pushing it.  I know the @Home guys are
> 
> Um... OK.. It's Late.. I'm not sure I understand what you mean.
> Are you revering to those spammers who look for people connected to
> the net with open smtp ports to spam to or from?

SPAMmers look for ISP's who don't stop them from sending SPAM,
and for relay hosts otherwise.  Either way, the packets coming from
your customers to the Internet could be a problem for you.


>  What do you mean by "I expect you want them to pull data instead of
> pushing it?"

I expect that you have a small channel from the user to the Internet,
and a big channel from the Internet to the user.  Most cable-modem
setups use ADSL, with a tiny channel for requests and a huge back
channel for responses, on the theory that an FTP/HTTP "get" will
result in a heck of a lot of data compared to the size of the request
for the data... ie: "people get cable modems so they can suck stuff
down faster".

You're effectively a "content provider".  A cable company offering
Internet connectivity via cable-modem is generally doing so on the
theory that people will be pulling data down from the Internet, not
pushing data up to the Internet (ie: you expect the vast majority of
them to run client software, not server software).


If you want people to not be able to run HTTP or FTP or other TCP
based servers, you can refuse connection requests going from the
Internet to your customers machines.  Connection requests will go
up, and packets will come back from the server with the "response"
bit set in the header.

Connection packets that don't have the "response" bit in them are
connections to your customer's machines from the Internet -- basically,
unsolicited traffic in violation of the "don't run a server" policy.


This is a typical CISCO configuration for corporate firewalls; it
saves them having to set up proxies for their outbound connections
(FTP, HTTP, etc.).

As far as policies go, machine enforcement always works better than
voluntary cooperation from humans.  8-).


>  Also, having the mail in the users directory makes space usage/quotas
>  easier to manage for me.
> 
>  Speaking of which, I think you will like my directory scheme.
>  Nicole =   /home/1/n/nic/nicole
>  terry =    /home/2/t/ter/terry
>  lambert =  /home/3/l/lam/lambert

Good thinking.  A semi-b-tree to break up the directory entry space
into smaller chunks so linear traversals don't take as long.  8-).


>  the first number is a random number generated during acct creation (1-3).
> 
>  If you can think of any additions or alternatives, please let me know.

The only two that come to mind are:

1)	"Keep a count and try to balance the tree at account creation
	 time by making the first number choice a weighted value instead
	 of a random number".

2)	"Rebalance the tree from time to time by migrating accounts
	 around.  Just prebalancing the tree (per #1) is not enough,
	 since accunts also have random duration, as well as random
	 arrival times".

> > Solaris x86, or Solaris/SPARC?
> 
>  They have both, but reccomend the sparc version.

Is the x86 code statically or dynamically linked?


>  I also need to run the Netscape calendering software.

Hmmmm... r e a l l y...

I have LDAP schema's for the full Netscape calendering, per the Netscape
published documentation on their Web Site.

What I *don't* have is a way to test vs. a client, or knowledge of
what the server does besides provide an LDAP repository (if it even
does anything else).

I was thinking that I'd write a calendering library for client
interoperability, if I ever found someone who actually bought their
server...

I can send the netscape.at.conf and netscape.oc.conf files (which
actually have my version of their entire schema set, not just the
calendering) if you wanted to putter around.  8-).


>  Hmm Yea but the other stuff has a nice pretty interface and has been
>  used by other cable companies. Just like I have said about the needs
>  of the FreeBSD pages, the bosses want to see who else is using it,
>  etc etc. So, I could push it and if it works I'm OK. If it doesn't,
>  I'm MUD. FreeBSD I know, trust and belive in enough to be able to say
>  BAH! we don't need  Xbrand comercial UNIX or Billy Bloatware and feel
>  safe.

8-).  Yeah; did you see:  http://ccwf.cc.utexas.edu/~kirch/ ?


>  I will look deeper however.

Yeah; don't take unnecessary risks; I was just thinking of the
financial side of things...



					Terry Lambert
					terry@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-isp" in the body of the message



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199806270802.BAA24158>