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-advocacy" 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>