From owner-freebsd-advocacy Sat Jun 27 12:09:36 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id MAA15263 for freebsd-advocacy-outgoing; Sat, 27 Jun 1998 12:09:36 -0700 (PDT) (envelope-from owner-freebsd-advocacy@FreeBSD.ORG) Received: from xwin.webweaver.net (xwin.webweaver.net [208.138.29.35]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id MAA15246; Sat, 27 Jun 1998 12:09:33 -0700 (PDT) (envelope-from nicole@xwin.webweaver.net) Received: (from nicole@localhost) by xwin.webweaver.net (8.8.8/8.8.7) id LAA01179; Sat, 27 Jun 1998 11:08:46 -0700 (PDT) (envelope-from nicole) Message-ID: X-Mailer: XFMail 1.2 [p0] on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii MIME-Version: 1.0 In-Reply-To: <199806270802.BAA24158@usr08.primenet.com> Date: Sat, 27 Jun 1998 11:08:46 -0700 (PDT) From: Nicole Harrington To: Terry Lambert Subject: Re: Packet Engines - FreeBSD + more Cc: opsys@mail.webspan.net, freebsd-advocacy@FreeBSD.ORG, freebsd-isp@FreeBSD.ORG Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by hub.freebsd.org id MAA15248 Sender: owner-freebsd-advocacy@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 27-Jun-98 Terry Lambert wisely wrote: > 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. > > Oh Yea..We have already had problems with people sending spam from their cable connection as well as people thinking "cool, I have this nice fast connection to my house, I think I'll set up my own server" and set up an NT box or some Linux box. The next thing they know I have to call them to ask why odd things are hap pening from their connection. Only to learn that they have been hacked! This is a fun game, as there is nothing so dangerous as a clueless user with a T 1 to their house. >> 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". Yes, depending on 1 way or 2 way systems and the QOS they buy. > 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-). > This is a good idea I am going to make sure our new lead Networking person know s and thinks about this. Thanks :> >> 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-). > Thanks! > >> 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". > Hmmm Yes, to make sure it stays even and random. > 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". > This is tricky however since this will affect those with web sites who hav e cgi-scripts that need to know where they are. But yes I need to think about ho w to make sure things stay balanaced. Hmmmm >> > Solaris x86, or Solaris/SPARC? >> >> They have both, but reccomend the sparc version. > > Is the x86 code statically or dynamically linked? Dunno.. how do I find out. Just calling them I guess :} >> 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-). > Sure! I love to putter. I learn a lot that way. However I know nothing about LDAP. But the calendar software is for schedual ma nagement for the executypes to set up meetings. How does this work with LDAP? I am working on a new Intranet machine and the ONE thing they need/want (the ne tscape calendering) won't run on FreeBSD so I may have to run a SPARC for the w hole thing. BAH! >> 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/ ? > > No.. However I just read a bit of it and found it most amusing and true. I plan to read on.. Thanks >> I will look deeper however. > > Yeah; don't take unnecessary risks; I was just thinking of the > financial side of things... Yea it's a tough balance. Our new VP of technology is from Netscape so of cours e he would like to have us use Netscape stuff. Most of which does not run on Fre eBSD. So I had to present my case as to why FreeBSD and Apache etc.. is good for us instead of Netscape Suite etc etc etc ... So far I have been sucessfull in h aving us standardize on FreeBSD. After all, what's not to love :> Nicole nicole@webweaver.net - http://www.webweaver.net/ webmistress@dangermouse.org - http://www.dangermouse.org/ ------------------------------------------------- -- Powered by Coka Cola and FreeBSD -- -- Stong enough for a man - But made for a Woman -- -- Microsoft: What bug would you like today? -- -- I tried an internal modem once, but it hurt when I walked -- --------------------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-advocacy" in the body of the message