From owner-freebsd-isp@FreeBSD.ORG Sun Sep 25 13:27:39 2005 Return-Path: X-Original-To: freebsd-isp@freebsd.org Delivered-To: freebsd-isp@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 52C6E16A420 for ; Sun, 25 Sep 2005 13:27:39 +0000 (GMT) (envelope-from dean@terrabyte.dc.com.au) Received: from tyungwa.pair.com (tyungwa.pair.com [209.68.2.156]) by mx1.FreeBSD.org (Postfix) with SMTP id DDC5943D4C for ; Sun, 25 Sep 2005 13:27:38 +0000 (GMT) (envelope-from dean@terrabyte.dc.com.au) Received: (qmail 30747 invoked by uid 3034); 25 Sep 2005 13:27:38 -0000 Message-ID: <20050925132738.30746.qmail@tyungwa.pair.com> From: Autoresponder To: freebsd-isp@freebsd.org Date: 25 Sep 2005 09:27:38 -0400 Precedence: junk X-Loop: dean@terrabyte.dc.com.au Subject: Re: Mail Delivery (failure dean@terrabyte.dc.com.au) X-BeenThere: freebsd-isp@freebsd.org X-Mailman-Version: 2.1.5 Reply-To: blackhole@terrabyte.dc.com.au List-Id: Internet Services Providers List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Sep 2005 13:27:39 -0000 Hi it's Dean here, Your email hasn't reached me -- yet. Don't despair, this email tells you what to do! The email address "dean@terrabyte.dc.com.au" has been "turned off" due to the ever-growing problem of spam. This is my latest weapon in the battle to beat junk mail -- unfortunately for you it means that because you have one of my older email addresses, you have this one-time-only extra step to take. Actually, YOU MAY ALREADY HAVE MY NEW ADDRESS ... if you have received an email FROM me in the last 12 months or so, you should have the new email -- take a look closely at the new username -- it's no longer dean@terrabyte.dc.com.au -- if you do, just use that address and don't worry about following the steps below. I have a new address in use ... but you'll have to contact me to find out ... just one more step and you're done! Please note that this is an "automatic response" to your email -- so please don't be offended by the less-than-personal language if you're someone I've known for a long time! And, as you can see by the reply to email, any response to this message gets deleted automatically (partly to prevent two autoresponders causing a big loop! And also so spammers don't try and use the blackhole address.) Any incoming message sent to dean@terrabyte.dc.com.au is now also discarded automatically. If you're writing to me personally, please read below to see how to reach me directly. I'm sorry to have to make this change, but it's necessary to remove the one last email address with major spam problems (all the others were actioned early in 2004, reducing my spam problem by over 85%!). This change has already resulted in a drop of more than 99% of all incoming spam. I'm sure you'd agree that having a more "secret" email means that I only receive the really important messages (like yours I hope!) and don't waste time dealing with garbage. Here's What To Do ---------------------------- 1. Go to http://www.terrabyte.dc.com.au and use the contact page details there to reach me. There is a link to a web-based form -- you'll only need to use this ONCE, and then if your message is legitimate, I'll give you the "proper" email address for future use so you can email directly and not have to use the website. 2. After I reply, don't forget to then update your email address book so you can bypass this step once you have been allowed as a legitimate sender! 3. If all else fails, try faxing or mailing me via Australia Post. Kind regards, and good luck! Dean Kennedy http://www.terrabyte.dc.com.au (Last Updated 2 May 2005) From owner-freebsd-isp@FreeBSD.ORG Sun Sep 25 14:59:01 2005 Return-Path: X-Original-To: freebsd-isp@freebsd.org Delivered-To: freebsd-isp@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F353616A41F for ; Sun, 25 Sep 2005 14:59:00 +0000 (GMT) (envelope-from MAILER-DEAMON@sjr.fi) Received: from mx5.sjr.fi (mx5.sjr.fi [194.100.84.70]) by mx1.FreeBSD.org (Postfix) with ESMTP id 74F2243D49 for ; Sun, 25 Sep 2005 14:59:00 +0000 (GMT) (envelope-from MAILER-DEAMON@sjr.fi) Received: from mx5.sjr.fi by mx5.sjr.fi (Homepage-SJR Mail Server) with SMTP id CME38544 for ; Sun, 25 Sep 2005 17:58:55 +0300 Date: Sun, 25 Sep 2005 17:58:55 +0300 From: MAILER-DEAMON@sjr.fi To: Message-Id: <859410267@mx5.sjr.fi> Subject: We don't relay X-BeenThere: freebsd-isp@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Internet Services Providers List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Sep 2005 14:59:01 -0000 We don't relay .exe files virus reasons! Emme välitä .exe tiedostoja virus mahdollisuuksien vuoksi! From owner-freebsd-isp@FreeBSD.ORG Mon Sep 26 09:21:18 2005 Return-Path: X-Original-To: freebsd-isp@freebsd.org Delivered-To: freebsd-isp@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 64BED16A41F for ; Mon, 26 Sep 2005 09:21:18 +0000 (GMT) (envelope-from cmuser@shaggy.smf.ebay.com) Received: from smf-camp6.smf.ebay.com (smfcamppool06.emailebay.com [66.135.215.235]) by mx1.FreeBSD.org (Postfix) with ESMTP id 281B743D5A for ; Mon, 26 Sep 2005 09:21:13 +0000 (GMT) (envelope-from cmuser@shaggy.smf.ebay.com) Received: from shaggy.smf.ebay.com (fallback-camp.vip.smf.ebay.com [10.108.160.50]) by smf-camp6.smf.ebay.com (8.12.3/8.12.3) with ESMTP id j8Q9LCdi016233 for ; Mon, 26 Sep 2005 02:21:12 -0700 Received: (from cmuser@localhost) by shaggy.smf.ebay.com (8.11.6+Sun/8.11.6) id j8Q9LC209485; Mon, 26 Sep 2005 02:21:12 -0700 (PDT) Date: Mon, 26 Sep 2005 02:21:12 -0700 (PDT) From: Unexpected reply handler Message-Id: <200509260921.j8Q9LC209485@shaggy.smf.ebay.com> To: freebsd-isp@freebsd.org References: <200509260921.j8Q9L6AG026003@mailhost8.sjc.ebay.com> In-Reply-To: <200509260921.j8Q9L6AG026003@mailhost8.sjc.ebay.com> Precedence: junk X-Loop: reply@reply.ebay.com Subject: Re: Mail Delivery (failure ay.219793851.58862.0@reply3.ebay.com) X-BeenThere: freebsd-isp@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Internet Services Providers List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Sep 2005 09:21:18 -0000 Thank you for your response. Please don't reply to this message - it is an automated response and your reply will not be received. If you have a question for eBay Customer Support, please visit the following eBay Help page. This page will help you locate the answer to your question, or assist you in contacting us: http://pages.ebay.com/help/index.html If you would like to change your notification preferences, which determine what type of email you receive from eBay, please follow the steps below: 1. Click "My eBay" located at the top of all eBay pages. You may be asked to sign in. 2. Click the "eBay Preferences" link located under the "My Account" heading. 3. Click the "view/change" link to the right of "Notification Preferences." You may be asked to sign in once more. 4. On the "Change Your Notification Preferences" page, check the boxes to indicate the types of messages you'd like to receive from eBay. Then, uncheck the boxes to indicate the types of messages you don't want to receive from us. 5. Once you're done, be sure to click the "Save Changes" button at the top or bottom of the page. Again, thanks for writing eBay. -- From owner-freebsd-isp@FreeBSD.ORG Mon Sep 26 11:45:34 2005 Return-Path: X-Original-To: freebsd-isp@freebsd.org Delivered-To: freebsd-isp@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 09AB016A41F; Mon, 26 Sep 2005 11:45:34 +0000 (GMT) (envelope-from anderson@centtech.com) Received: from mh2.centtech.com (moat3.centtech.com [207.200.51.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 38DB143D48; Mon, 26 Sep 2005 11:45:32 +0000 (GMT) (envelope-from anderson@centtech.com) Received: from [10.177.171.220] (neutrino.centtech.com [10.177.171.220]) by mh2.centtech.com (8.13.1/8.13.1) with ESMTP id j8QBjU66046492; Mon, 26 Sep 2005 06:45:31 -0500 (CDT) (envelope-from anderson@centtech.com) Message-ID: <4337DF56.6030407@centtech.com> Date: Mon, 26 Sep 2005 06:45:26 -0500 From: Eric Anderson User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.11) Gecko/20050914 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Brian Candler References: <20050924141025.GA1236@uk.tiscali.com> In-Reply-To: <20050924141025.GA1236@uk.tiscali.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.82/1102/Sun Sep 25 09:04:56 2005 on mh2.centtech.com X-Virus-Status: Clean Cc: freebsd-isp@freebsd.org, freebsd-cluster@freebsd.org Subject: Re: Options for synchronising filesystems X-BeenThere: freebsd-isp@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Internet Services Providers List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Sep 2005 11:45:34 -0000 Brian Candler wrote: > Hello, > > I was wondering if anyone would care to share their experiences in > synchronising filesystems across a number of nodes in a cluster. I can think > of a number of options, but before changing what I'm doing at the moment I'd > like to see if anyone has good experiences with any of the others. > > The application: a clustered webserver. The users' CGIs run in a chroot > environment, and these clearly need to be identical (otherwise a CGI running > on one box would behave differently when running on a different box). > Ultimately I'd like to synchronise the host OS on each server too. > > Note that this is a single-master, multiple-slave type of filesystem > synchronisation I'm interested in. > > > 1. Keep a master image on an admin box, and rsync it out to the frontends > ------------------------------------------------------------------------- > > This is what I'm doing at the moment. Install a master image in > /webroot/cgi, add packages there (chroot /webroot/cgi pkg_add ...), and > rsync it. [Actually I'm exporting it using NFS, and the frontends run rsync > locally when required to update their local copies against the NFS master] > > Disadvantages: > > - rsyncing a couple of gigs of data is not particularly fast, even when only > a few files have changed > > - if a sysadmin (wrongly) changes a file on a front-end instead of on the > master copy in the admin box, then the change will be lost when the next > rsync occurs. They might think they've fixed a problem, and then (say) 24 > hours later their change is wiped. However if this is a config file, the > fact that the old file has been reinstated might not be noticed until the > daemon is restarted or the box rebooted - maybe months later. This I think > is the biggest fundamental problem. > > - files can be added locally and they will remain indefinitely (unless we > use rsync --delete which is a bit scary). If this is done then adding a new > machine into the cluster by rsyncing from the master will not pick up these > extra files. > > So, here are the alternatives I'm considering, and I'd welcome any > additional suggestions too. Here's a few ideas on this: do multiple rsyncs, one for each top level directory. That might speed up your total rsync process. Another similar method is using a content revisioning system. This is only good for some cases, but something like subversion might work ok here. > 2. Run the images directly off NFS > ---------------------------------- > > I've had this running before, even the entire O/S, and it works just fine. > However the NFS server itself then becomes a critical > single-point-of-failure: if it has to be rebooted and is out of service for > 2 minutes, then the whole cluster is out of service for that time. > > I think this is only feasible if I can build a highly-available NFS server, > which really means a pair of boxes serving the same data. Since the system > image is read-only from the point of view of the frontends, this should be > easy enough: > > frontends frontends > | | | | | | > NFS -----------> NFS > server 1 sync server 2 > > As far as I know, NFS clients don't support the idea of failing over from > one server to another, so I'd have to make a server pair which transparently > fails over. > > I could make one NFS server take over the other server's IP address using > carp or vrrp. However, I suspect that the clients might notice. I know that > NFS is 'stateless' in the sense that a server can be rebooted, but for a > client to be redirected from one server to the other, I expect that these > filesytems would have to be *identical*, down to the level of the inode > numbers being the same. > > If that's true, then rsync between the two NFS servers won't cut it. I was > thinking of perhaps using geom_mirror plus ggated/ggatec to make a > block-identical read-only mirror image on NFS server 2 - this also has the > advantage that any updates are close to instantaneous. > > What worries me here is how NFS server 2, which has the mirrored filesystem > mounted read-only, will take to having the data changed under its nose. Does > it for example keep caches of inodes in memory, and what would happen if > those inodes on disk were to change? I guess I can always just unmount and > remount the filesystem on NFS server 2 after each change. I've tried doing something similar. I used fiber attached storage, and had multiple hosts mounting the same partition. It seemed as though when host A mounted the filesystem read-write, and then host B mounted it read-only, any changes made by host A were not seen by B, and even remounting did not always bring it up to current state. I believe it has to do with the buffer cache and host A's desire to keep things (like inode changes, block maps, etc) in cache and not write them to disk. FreeBSD does not currently have a multi-system cache coherency protocol to distribute that information to other hosts. This is something I think would be very useful for many people. I suppose you could just mount the filesystem when you know a change has happened, but you still may not see the change. Maybe mounting the filesystem on host A with the sync option would help. > My other concern is about susceptibility to DoS-type attacks: if one > frontend were to go haywire and start hammering the NFS servers really hard, > it could impact on all the other machines in the cluster. > > However, the problems of data synchronisation are solved: any change made on > the NFS server is visible identically to all front-ends, and sysadmins can't > make changes on the front-ends because the NFS export is read-only. This was my first thought too, and a highly available NFS server is something any NFS heavy installation wants (needs). There are a few implementations of clustered filesystems out there, but non for FreeBSD (yet). What that allows is multiple machines talking to a shared storage with read/write access. Very handy, but since you only need read-only access, I think your problem is much simpler, and you can get away with a lot less. > 3. Use a network distributed filesystem - CODA? AFS? > ---------------------------------------------------- > > If each frontend were to access the filesystem as a read-only network mount, > but have a local copy to work with in the case of disconnected operation, > then the SPOF of an NFS server would be eliminated. > > However, I have no experience with CODA, and although it's been in the tree > since 2002, the README's don't inspire confidence: > > "It is mostly working, but hasn't been run long enough to be sure all the > bugs are sorted out. ... This code is not SMP ready" > > Also, a local cache is no good if the data you want during disconnected > operation is not in the cache at that time, which I think means this idea is > not actually a very good one. There is also a port for coda. I've been reading about this, and it's an interesting filesystem, but I'm just not sure of it's usefulness yet. > 4. Mount filesystems read-only > ------------------------------ > > On each front-end I could store /webroot/cgi on a filesystem mounted > read-only to prevent tampering (as long as the sysadmin doesn't remount it > read-write of course). That would work reasonably well, except that being > mounted read-only I couldn't use rsync to update it! > > It might also work with geom_mirror and ggated/ggatec, except for the issue > I raised before about changing blocks on a filesystem under the nose of a > client who is actively reading from it. I suppose you could mount r/w only when doing the rsync, then switch back to ro once complete. You should be able to do this online, without any issues or taking the filesystem offline. > 5. Using a filesystem which really is read-only > ----------------------------------------------- > > Better tamper-protection could be had by keeping data in a filesystem > structure which doesn't support any updates at all - such as cd9660 or > geom_uzip. > > The issue here is how to roll out a new version of the data. I could push > out a new filesystem image into a second partition, but it would then be > necessary to unmount the old filesystem and remount the new on the same > place, and you can't really unmount a filesystem which is in use. So this > would require a reboot. > > I was thinking that some symlink trickery might help: > > /webroot/cgi -> /webroot/cgi1 > /webroot/cgi1 # filesystem A mounted here > /webroot/cgi2 # filesystem B mounted here > > It should be possible to unmount /webroot/cgi2, dd in a new image, remount > it, and change the symlink to point to /webroot/cgi2. After a little while, > hopefully all the applications will stop using files in /webroot/cgi1, so > this one can be unmounted and a new one put in its place on the next update. > However this is not guaranteed, especially if there are long-lived processes > using binary images in this partition. You'd still have to stop and restart > all those processes. > > If reboots were acceptable, then the filesystem image could also be stored > in ramdisk pulled in via pxeboot. This makes sense especially for geom_uzip > where the data is pre-compressed. However I would still prefer to avoid > frequent reboots if at all possible. Also, whilst a ramdisk might be OK for > the root filesystem, a typical CGI environment (with perl, php, ruby, > python, and loads of libraries) would probably be too large anyway. > > > 6. Journaling filesystem replication > ------------------------------------ > > If the data were stored on a journaling filesystem on the master box, and > the journal logs were distributed out to the slaves, then they would all > have identical filesystem copies and only a minimal amount of data would > need to be pushed out to each machine on each change. (This would be rather > like NetApps and their snap-mirroring system). However I'm not aware of any > journaling filesystem for FreeBSD, let alone whether it would support > filesystem replication in this way. There is a project underway for UFSJ (UFS journaling). Maybe once it is complete, and bugs are ironed out, one could implement a journal distribution piece to send the journal updates to multiple hosts and achieve what you are thinking, however, that only distributes the meta-data, and not the actual data. Good luck finding your ultimate solution! Eric -- ------------------------------------------------------------------------ Eric Anderson Sr. Systems Administrator Centaur Technology Anything that works is better than anything that doesn't. ------------------------------------------------------------------------ From owner-freebsd-isp@FreeBSD.ORG Mon Sep 26 12:25:37 2005 Return-Path: X-Original-To: freebsd-isp@freebsd.org Delivered-To: freebsd-isp@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0306D16A41F for ; Mon, 26 Sep 2005 12:25:37 +0000 (GMT) (envelope-from filip@wuytack.net) Received: from london.wuytack.net (host-84-9-106-97.bulldogdsl.com [84.9.106.97]) by mx1.FreeBSD.org (Postfix) with ESMTP id 00ABC43D48 for ; Mon, 26 Sep 2005 12:25:35 +0000 (GMT) (envelope-from filip@wuytack.net) Received: (qmail 99551 invoked by uid 1003); 26 Sep 2005 12:42:58 -0000 Received: from filip@wuytack.net by london.wuytack.net by uid 89 with qmail-scanner-1.22 (clamscan: 0.71. spamassassin: 2.63. Clear:RC:1(82.110.72.114):. Processed in 5.41758 secs); 26 Sep 2005 12:42:58 -0000 Received: from unknown (HELO ?127.0.0.1?) (filip@wuytack.net@82.110.72.114) by 10.11.12.4 with SMTP; 26 Sep 2005 12:42:52 -0000 Message-ID: <4337E8A7.6070107@wuytack.net> Date: Mon, 26 Sep 2005 13:25:11 +0100 From: filip wuytack User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Eric Anderson References: <20050924141025.GA1236@uk.tiscali.com> <4337DF56.6030407@centtech.com> In-Reply-To: <4337DF56.6030407@centtech.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-isp@freebsd.org, freebsd-cluster@freebsd.org, Brian Candler Subject: Re: Options for synchronising filesystems X-BeenThere: freebsd-isp@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Internet Services Providers List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Sep 2005 12:25:37 -0000 Eric Anderson wrote: > Brian Candler wrote: > >> Hello, >> >> I was wondering if anyone would care to share their experiences in >> synchronising filesystems across a number of nodes in a cluster. I can >> think >> of a number of options, but before changing what I'm doing at the >> moment I'd >> like to see if anyone has good experiences with any of the others. >> >> The application: a clustered webserver. The users' CGIs run in a chroot >> environment, and these clearly need to be identical (otherwise a CGI >> running >> on one box would behave differently when running on a different box). >> Ultimately I'd like to synchronise the host OS on each server too. >> >> Note that this is a single-master, multiple-slave type of filesystem >> synchronisation I'm interested in. >> >> >> 1. Keep a master image on an admin box, and rsync it out to the frontends >> ------------------------------------------------------------------------- >> >> This is what I'm doing at the moment. Install a master image in >> /webroot/cgi, add packages there (chroot /webroot/cgi pkg_add ...), and >> rsync it. [Actually I'm exporting it using NFS, and the frontends run >> rsync >> locally when required to update their local copies against the NFS >> master] >> >> Disadvantages: >> >> - rsyncing a couple of gigs of data is not particularly fast, even >> when only >> a few files have changed >> >> - if a sysadmin (wrongly) changes a file on a front-end instead of on the >> master copy in the admin box, then the change will be lost when the next >> rsync occurs. They might think they've fixed a problem, and then (say) 24 >> hours later their change is wiped. However if this is a config file, the >> fact that the old file has been reinstated might not be noticed until the >> daemon is restarted or the box rebooted - maybe months later. This I >> think >> is the biggest fundamental problem. >> >> - files can be added locally and they will remain indefinitely (unless we >> use rsync --delete which is a bit scary). If this is done then adding >> a new >> machine into the cluster by rsyncing from the master will not pick up >> these >> extra files. >> >> So, here are the alternatives I'm considering, and I'd welcome any >> additional suggestions too. > > > Here's a few ideas on this: do multiple rsyncs, one for each top level > directory. That might speed up your total rsync process. Another > similar method is using a content revisioning system. This is only good > for some cases, but something like subversion might work ok here. > > > >> 2. Run the images directly off NFS >> ---------------------------------- >> >> I've had this running before, even the entire O/S, and it works just >> fine. >> However the NFS server itself then becomes a critical >> single-point-of-failure: if it has to be rebooted and is out of >> service for >> 2 minutes, then the whole cluster is out of service for that time. >> >> I think this is only feasible if I can build a highly-available NFS >> server, >> which really means a pair of boxes serving the same data. Since the >> system >> image is read-only from the point of view of the frontends, this >> should be >> easy enough: >> >> frontends frontends >> | | | | | | >> NFS -----------> NFS >> server 1 sync server 2 >> >> As far as I know, NFS clients don't support the idea of failing over from >> one server to another, so I'd have to make a server pair which >> transparently >> fails over. >> >> I could make one NFS server take over the other server's IP address using >> carp or vrrp. However, I suspect that the clients might notice. I know >> that >> NFS is 'stateless' in the sense that a server can be rebooted, but for a >> client to be redirected from one server to the other, I expect that these >> filesytems would have to be *identical*, down to the level of the inode >> numbers being the same. >> >> If that's true, then rsync between the two NFS servers won't cut it. I >> was >> thinking of perhaps using geom_mirror plus ggated/ggatec to make a >> block-identical read-only mirror image on NFS server 2 - this also has >> the >> advantage that any updates are close to instantaneous. >> >> What worries me here is how NFS server 2, which has the mirrored >> filesystem >> mounted read-only, will take to having the data changed under its >> nose. Does >> it for example keep caches of inodes in memory, and what would happen if >> those inodes on disk were to change? I guess I can always just unmount >> and >> remount the filesystem on NFS server 2 after each change. > > > I've tried doing something similar. I used fiber attached storage, and > had multiple hosts mounting the same partition. It seemed as though > when host A mounted the filesystem read-write, and then host B mounted > it read-only, any changes made by host A were not seen by B, and even > remounting did not always bring it up to current state. I believe it > has to do with the buffer cache and host A's desire to keep things (like > inode changes, block maps, etc) in cache and not write them to disk. > FreeBSD does not currently have a multi-system cache coherency protocol > to distribute that information to other hosts. This is something I > think would be very useful for many people. I suppose you could just > mount the filesystem when you know a change has happened, but you still > may not see the change. Maybe mounting the filesystem on host A with > the sync option would help. > >> My other concern is about susceptibility to DoS-type attacks: if one >> frontend were to go haywire and start hammering the NFS servers really >> hard, >> it could impact on all the other machines in the cluster. >> >> However, the problems of data synchronisation are solved: any change >> made on >> the NFS server is visible identically to all front-ends, and sysadmins >> can't >> make changes on the front-ends because the NFS export is read-only. > > > This was my first thought too, and a highly available NFS server is > something any NFS heavy installation wants (needs). There are a few > implementations of clustered filesystems out there, but non for FreeBSD > (yet). What that allows is multiple machines talking to a shared > storage with read/write access. Very handy, but since you only need > read-only access, I think your problem is much simpler, and you can get > away with a lot less. > > >> 3. Use a network distributed filesystem - CODA? AFS? >> ---------------------------------------------------- >> >> If each frontend were to access the filesystem as a read-only network >> mount, >> but have a local copy to work with in the case of disconnected operation, >> then the SPOF of an NFS server would be eliminated. >> >> However, I have no experience with CODA, and although it's been in the >> tree >> since 2002, the README's don't inspire confidence: >> >> "It is mostly working, but hasn't been run long enough to be sure >> all the >> bugs are sorted out. ... This code is not SMP ready" >> >> Also, a local cache is no good if the data you want during disconnected >> operation is not in the cache at that time, which I think means this >> idea is >> not actually a very good one. > > > There is also a port for coda. I've been reading about this, and it's > an interesting filesystem, but I'm just not sure of it's usefulness yet. > > >> 4. Mount filesystems read-only >> ------------------------------ >> >> On each front-end I could store /webroot/cgi on a filesystem mounted >> read-only to prevent tampering (as long as the sysadmin doesn't >> remount it >> read-write of course). That would work reasonably well, except that being >> mounted read-only I couldn't use rsync to update it! >> >> It might also work with geom_mirror and ggated/ggatec, except for the >> issue >> I raised before about changing blocks on a filesystem under the nose of a >> client who is actively reading from it. > > > I suppose you could mount r/w only when doing the rsync, then switch > back to ro once complete. You should be able to do this online, without > any issues or taking the filesystem offline. > > >> 5. Using a filesystem which really is read-only >> ----------------------------------------------- >> >> Better tamper-protection could be had by keeping data in a filesystem >> structure which doesn't support any updates at all - such as cd9660 or >> geom_uzip. >> >> The issue here is how to roll out a new version of the data. I could push >> out a new filesystem image into a second partition, but it would then be >> necessary to unmount the old filesystem and remount the new on the same >> place, and you can't really unmount a filesystem which is in use. So this >> would require a reboot. >> >> I was thinking that some symlink trickery might help: >> >> /webroot/cgi -> /webroot/cgi1 >> /webroot/cgi1 # filesystem A mounted here >> /webroot/cgi2 # filesystem B mounted here >> >> It should be possible to unmount /webroot/cgi2, dd in a new image, >> remount >> it, and change the symlink to point to /webroot/cgi2. After a little >> while, >> hopefully all the applications will stop using files in /webroot/cgi1, so >> this one can be unmounted and a new one put in its place on the next >> update. >> However this is not guaranteed, especially if there are long-lived >> processes >> using binary images in this partition. You'd still have to stop and >> restart >> all those processes. >> >> If reboots were acceptable, then the filesystem image could also be >> stored >> in ramdisk pulled in via pxeboot. This makes sense especially for >> geom_uzip >> where the data is pre-compressed. However I would still prefer to avoid >> frequent reboots if at all possible. Also, whilst a ramdisk might be >> OK for >> the root filesystem, a typical CGI environment (with perl, php, ruby, >> python, and loads of libraries) would probably be too large anyway. >> >> >> 6. Journaling filesystem replication >> ------------------------------------ >> >> If the data were stored on a journaling filesystem on the master box, and >> the journal logs were distributed out to the slaves, then they would all >> have identical filesystem copies and only a minimal amount of data would >> need to be pushed out to each machine on each change. (This would be >> rather >> like NetApps and their snap-mirroring system). However I'm not aware >> of any >> journaling filesystem for FreeBSD, let alone whether it would support >> filesystem replication in this way. > > > There is a project underway for UFSJ (UFS journaling). Maybe once it > is complete, and bugs are ironed out, one could implement a journal > distribution piece to send the journal updates to multiple hosts and > achieve what you are thinking, however, that only distributes the > meta-data, and not the actual data. > > Have a look at dragonfly BSD for this. They are working on a journaling filesystem that will do just that. ~ Fil > Good luck finding your ultimate solution! > > Eric > > From owner-freebsd-isp@FreeBSD.ORG Mon Sep 26 12:46:16 2005 Return-Path: X-Original-To: freebsd-isp@freebsd.org Delivered-To: freebsd-isp@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9724C16A41F; Mon, 26 Sep 2005 12:46:16 +0000 (GMT) (envelope-from anderson@centtech.com) Received: from mh2.centtech.com (moat3.centtech.com [207.200.51.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2252743D48; Mon, 26 Sep 2005 12:46:15 +0000 (GMT) (envelope-from anderson@centtech.com) Received: from [10.177.171.220] (neutrino.centtech.com [10.177.171.220]) by mh2.centtech.com (8.13.1/8.13.1) with ESMTP id j8QCkENe047545; Mon, 26 Sep 2005 07:46:14 -0500 (CDT) (envelope-from anderson@centtech.com) Message-ID: <4337ED91.8080200@centtech.com> Date: Mon, 26 Sep 2005 07:46:09 -0500 From: Eric Anderson User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.11) Gecko/20050914 X-Accept-Language: en-us, en MIME-Version: 1.0 To: filip wuytack References: <20050924141025.GA1236@uk.tiscali.com> <4337DF56.6030407@centtech.com> <4337E8A7.6070107@wuytack.net> In-Reply-To: <4337E8A7.6070107@wuytack.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.82/1102/Sun Sep 25 09:04:56 2005 on mh2.centtech.com X-Virus-Status: Clean Cc: freebsd-isp@freebsd.org, freebsd-cluster@freebsd.org Subject: Re: Options for synchronising filesystems X-BeenThere: freebsd-isp@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Internet Services Providers List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Sep 2005 12:46:16 -0000 filip wuytack wrote: > > > Eric Anderson wrote: > >> Brian Candler wrote: >> >>> Hello, >>> >>> I was wondering if anyone would care to share their experiences in >>> synchronising filesystems across a number of nodes in a cluster. I >>> can think >>> of a number of options, but before changing what I'm doing at the >>> moment I'd >>> like to see if anyone has good experiences with any of the others. >>> >>> The application: a clustered webserver. The users' CGIs run in a chroot >>> environment, and these clearly need to be identical (otherwise a CGI >>> running >>> on one box would behave differently when running on a different box). >>> Ultimately I'd like to synchronise the host OS on each server too. >>> >>> Note that this is a single-master, multiple-slave type of filesystem >>> synchronisation I'm interested in. >>> >>> >>> 1. Keep a master image on an admin box, and rsync it out to the >>> frontends >>> ------------------------------------------------------------------------- >>> >>> >>> This is what I'm doing at the moment. Install a master image in >>> /webroot/cgi, add packages there (chroot /webroot/cgi pkg_add ...), and >>> rsync it. [Actually I'm exporting it using NFS, and the frontends run >>> rsync >>> locally when required to update their local copies against the NFS >>> master] >>> >>> Disadvantages: >>> >>> - rsyncing a couple of gigs of data is not particularly fast, even >>> when only >>> a few files have changed >>> >>> - if a sysadmin (wrongly) changes a file on a front-end instead of on >>> the >>> master copy in the admin box, then the change will be lost when the next >>> rsync occurs. They might think they've fixed a problem, and then >>> (say) 24 >>> hours later their change is wiped. However if this is a config file, the >>> fact that the old file has been reinstated might not be noticed until >>> the >>> daemon is restarted or the box rebooted - maybe months later. This I >>> think >>> is the biggest fundamental problem. >>> >>> - files can be added locally and they will remain indefinitely >>> (unless we >>> use rsync --delete which is a bit scary). If this is done then adding >>> a new >>> machine into the cluster by rsyncing from the master will not pick up >>> these >>> extra files. >>> >>> So, here are the alternatives I'm considering, and I'd welcome any >>> additional suggestions too. >> >> >> >> Here's a few ideas on this: do multiple rsyncs, one for each top level >> directory. That might speed up your total rsync process. Another >> similar method is using a content revisioning system. This is only >> good for some cases, but something like subversion might work ok here. >> >> >> >>> 2. Run the images directly off NFS >>> ---------------------------------- >>> >>> I've had this running before, even the entire O/S, and it works just >>> fine. >>> However the NFS server itself then becomes a critical >>> single-point-of-failure: if it has to be rebooted and is out of >>> service for >>> 2 minutes, then the whole cluster is out of service for that time. >>> >>> I think this is only feasible if I can build a highly-available NFS >>> server, >>> which really means a pair of boxes serving the same data. Since the >>> system >>> image is read-only from the point of view of the frontends, this >>> should be >>> easy enough: >>> >>> frontends frontends >>> | | | | | | >>> NFS -----------> NFS >>> server 1 sync server 2 >>> >>> As far as I know, NFS clients don't support the idea of failing over >>> from >>> one server to another, so I'd have to make a server pair which >>> transparently >>> fails over. >>> >>> I could make one NFS server take over the other server's IP address >>> using >>> carp or vrrp. However, I suspect that the clients might notice. I >>> know that >>> NFS is 'stateless' in the sense that a server can be rebooted, but for a >>> client to be redirected from one server to the other, I expect that >>> these >>> filesytems would have to be *identical*, down to the level of the inode >>> numbers being the same. >>> >>> If that's true, then rsync between the two NFS servers won't cut it. >>> I was >>> thinking of perhaps using geom_mirror plus ggated/ggatec to make a >>> block-identical read-only mirror image on NFS server 2 - this also >>> has the >>> advantage that any updates are close to instantaneous. >>> >>> What worries me here is how NFS server 2, which has the mirrored >>> filesystem >>> mounted read-only, will take to having the data changed under its >>> nose. Does >>> it for example keep caches of inodes in memory, and what would happen if >>> those inodes on disk were to change? I guess I can always just >>> unmount and >>> remount the filesystem on NFS server 2 after each change. >> >> >> >> I've tried doing something similar. I used fiber attached storage, >> and had multiple hosts mounting the same partition. It seemed as >> though when host A mounted the filesystem read-write, and then host B >> mounted it read-only, any changes made by host A were not seen by B, >> and even remounting did not always bring it up to current state. I >> believe it has to do with the buffer cache and host A's desire to keep >> things (like inode changes, block maps, etc) in cache and not write >> them to disk. FreeBSD does not currently have a multi-system cache >> coherency protocol to distribute that information to other hosts. >> This is something I think would be very useful for many people. I >> suppose you could just mount the filesystem when you know a change has >> happened, but you still may not see the change. Maybe mounting the >> filesystem on host A with the sync option would help. >> >>> My other concern is about susceptibility to DoS-type attacks: if one >>> frontend were to go haywire and start hammering the NFS servers >>> really hard, >>> it could impact on all the other machines in the cluster. >>> >>> However, the problems of data synchronisation are solved: any change >>> made on >>> the NFS server is visible identically to all front-ends, and >>> sysadmins can't >>> make changes on the front-ends because the NFS export is read-only. >> >> >> >> This was my first thought too, and a highly available NFS server is >> something any NFS heavy installation wants (needs). There are a few >> implementations of clustered filesystems out there, but non for >> FreeBSD (yet). What that allows is multiple machines talking to a >> shared storage with read/write access. Very handy, but since you only >> need read-only access, I think your problem is much simpler, and you >> can get away with a lot less. >> >> >>> 3. Use a network distributed filesystem - CODA? AFS? >>> ---------------------------------------------------- >>> >>> If each frontend were to access the filesystem as a read-only network >>> mount, >>> but have a local copy to work with in the case of disconnected >>> operation, >>> then the SPOF of an NFS server would be eliminated. >>> >>> However, I have no experience with CODA, and although it's been in >>> the tree >>> since 2002, the README's don't inspire confidence: >>> >>> "It is mostly working, but hasn't been run long enough to be sure >>> all the >>> bugs are sorted out. ... This code is not SMP ready" >>> >>> Also, a local cache is no good if the data you want during disconnected >>> operation is not in the cache at that time, which I think means this >>> idea is >>> not actually a very good one. >> >> >> >> There is also a port for coda. I've been reading about this, and >> it's an interesting filesystem, but I'm just not sure of it's >> usefulness yet. >> >> >>> 4. Mount filesystems read-only >>> ------------------------------ >>> >>> On each front-end I could store /webroot/cgi on a filesystem mounted >>> read-only to prevent tampering (as long as the sysadmin doesn't >>> remount it >>> read-write of course). That would work reasonably well, except that >>> being >>> mounted read-only I couldn't use rsync to update it! >>> >>> It might also work with geom_mirror and ggated/ggatec, except for the >>> issue >>> I raised before about changing blocks on a filesystem under the nose >>> of a >>> client who is actively reading from it. >> >> >> >> I suppose you could mount r/w only when doing the rsync, then switch >> back to ro once complete. You should be able to do this online, >> without any issues or taking the filesystem offline. >> >> >>> 5. Using a filesystem which really is read-only >>> ----------------------------------------------- >>> >>> Better tamper-protection could be had by keeping data in a filesystem >>> structure which doesn't support any updates at all - such as cd9660 or >>> geom_uzip. >>> >>> The issue here is how to roll out a new version of the data. I could >>> push >>> out a new filesystem image into a second partition, but it would then be >>> necessary to unmount the old filesystem and remount the new on the same >>> place, and you can't really unmount a filesystem which is in use. So >>> this >>> would require a reboot. >>> >>> I was thinking that some symlink trickery might help: >>> >>> /webroot/cgi -> /webroot/cgi1 >>> /webroot/cgi1 # filesystem A mounted here >>> /webroot/cgi2 # filesystem B mounted here >>> >>> It should be possible to unmount /webroot/cgi2, dd in a new image, >>> remount >>> it, and change the symlink to point to /webroot/cgi2. After a little >>> while, >>> hopefully all the applications will stop using files in >>> /webroot/cgi1, so >>> this one can be unmounted and a new one put in its place on the next >>> update. >>> However this is not guaranteed, especially if there are long-lived >>> processes >>> using binary images in this partition. You'd still have to stop and >>> restart >>> all those processes. >>> >>> If reboots were acceptable, then the filesystem image could also be >>> stored >>> in ramdisk pulled in via pxeboot. This makes sense especially for >>> geom_uzip >>> where the data is pre-compressed. However I would still prefer to avoid >>> frequent reboots if at all possible. Also, whilst a ramdisk might be >>> OK for >>> the root filesystem, a typical CGI environment (with perl, php, ruby, >>> python, and loads of libraries) would probably be too large anyway. >>> >>> >>> 6. Journaling filesystem replication >>> ------------------------------------ >>> >>> If the data were stored on a journaling filesystem on the master box, >>> and >>> the journal logs were distributed out to the slaves, then they would all >>> have identical filesystem copies and only a minimal amount of data would >>> need to be pushed out to each machine on each change. (This would be >>> rather >>> like NetApps and their snap-mirroring system). However I'm not aware >>> of any >>> journaling filesystem for FreeBSD, let alone whether it would support >>> filesystem replication in this way. >> >> >> >> There is a project underway for UFSJ (UFS journaling). Maybe once it >> is complete, and bugs are ironed out, one could implement a journal >> distribution piece to send the journal updates to multiple hosts and >> achieve what you are thinking, however, that only distributes the >> meta-data, and not the actual data. >> >> > Have a look at dragonfly BSD for this. They are working on a journaling > filesystem that will do just that. Do you have a link to some information on this? I've been looking at Dragonfly, but I'm having trouble finding good information on what is already working, in planning, etc. Eric -- ------------------------------------------------------------------------ Eric Anderson Sr. Systems Administrator Centaur Technology Anything that works is better than anything that doesn't. ------------------------------------------------------------------------ From owner-freebsd-isp@FreeBSD.ORG Mon Sep 26 15:33:27 2005 Return-Path: X-Original-To: freebsd-isp@freebsd.org Delivered-To: freebsd-isp@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3336B16A41F; Mon, 26 Sep 2005 15:33:27 +0000 (GMT) (envelope-from b.candler@pobox.com) Received: from leto.uk.clara.net (leto.uk.clara.net [80.168.69.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id B2F9F43D62; Mon, 26 Sep 2005 15:33:20 +0000 (GMT) (envelope-from b.candler@pobox.com) Received: from bloodhound.noc.clara.net ([195.8.70.207]) by leto.uk.clara.net with esmtp (Exim 4.43) id 1EJuyk-000HWz-Rg; Mon, 26 Sep 2005 16:33:18 +0100 Received: from personal by bloodhound.noc.clara.net with local (Exim 4.52 (FreeBSD)) id 1EJuyy-0006vz-Ff; Mon, 26 Sep 2005 16:33:32 +0100 Date: Mon, 26 Sep 2005 16:33:32 +0100 From: Brian Candler To: filip wuytack Message-ID: <20050926153332.GA26373@uk.tiscali.com> References: <20050924141025.GA1236@uk.tiscali.com> <4337DF56.6030407@centtech.com> <4337E8A7.6070107@wuytack.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4337E8A7.6070107@wuytack.net> User-Agent: Mutt/1.4.2.1i Cc: freebsd-isp@freebsd.org, Eric Anderson , freebsd-cluster@freebsd.org Subject: Re: Options for synchronising filesystems X-BeenThere: freebsd-isp@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Internet Services Providers List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Sep 2005 15:33:27 -0000 On Mon, Sep 26, 2005 at 01:25:11PM +0100, filip wuytack wrote: > Have a look at dragonfly BSD for this. They are working on a journaling > filesystem that will do just that. Someone else mentioned that. However DragonFly BSD seems very short of documentation on the web; I did finally find some on-line manpages courtesy of google (couldn't find them linked from www.dragonflybsd.org) >From what I read, I also get the impression that the journalling feature is rather a work-in-progress right now. Regards, Brian. From owner-freebsd-isp@FreeBSD.ORG Mon Sep 26 16:27:00 2005 Return-Path: X-Original-To: freebsd-isp@freebsd.org Delivered-To: freebsd-isp@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 58EAD16A41F for ; Mon, 26 Sep 2005 16:27:00 +0000 (GMT) (envelope-from tethys.ocean@gmail.com) Received: from xproxy.gmail.com (xproxy.gmail.com [66.249.82.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id C93DD43D48 for ; Mon, 26 Sep 2005 16:26:59 +0000 (GMT) (envelope-from tethys.ocean@gmail.com) Received: by xproxy.gmail.com with SMTP id t13so1106824wxc for ; Mon, 26 Sep 2005 09:26:59 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:references; b=SPoF/48QAsVWfn/b2I515QFXOOd2qorAYGw/V62+4uYlkzep+NhktidYJ1u1GhBUnBpbbxckW4rNpKjJvptXwctGLsuXYRPivIdUG+vfHZJTja/VVpl+ezmH+b3TriCAlX5st5QMsq66BmLpAZrduz5fHByDoRXPfrOcqEwtJsA= Received: by 10.70.91.7 with SMTP id o7mr2289966wxb; Mon, 26 Sep 2005 09:19:45 -0700 (PDT) Received: by 10.70.67.13 with HTTP; Mon, 26 Sep 2005 09:19:45 -0700 (PDT) Message-ID: <235b800005092609197d6b7c2e@mail.gmail.com> Date: Mon, 26 Sep 2005 19:19:45 +0300 From: tethys ocean To: freebsd-isp@freebsd.org In-Reply-To: <235b8000050926091310903997@mail.gmail.com> MIME-Version: 1.0 References: <235b8000050926091310903997@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: vqadmin X-BeenThere: freebsd-isp@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: tethys ocean List-Id: Internet Services Providers List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Sep 2005 16:27:00 -0000 I want setup vqadmin-2.3.6. FreeBSD 5.4 and qmail-1.03_4 and qmailadmin-1.2.7,1 apache+mod_ssl-1.3.33+2.8.22 mysql-server-4.0.24_1 is running on my system. Install vqadmin from ports and than setting up depens on http://freebsd.qmailrocks.org/vqadmin.htm but it is not running installaion by using port with setted up make enable-cgibindir=3D/usr/local/www/cgi-bin enable-htmldir=3D/usr/local/www/d= ata install clean my www directory contains these directory and files bash-2.05b# ls -als total 20 2 drwxr-xr-x 9 root wheel 512 Jul 1 21:05 . 2 drwxr-xr-x 15 root wheel 512 Jul 1 20:07 .. 2 drwxr-xr-x 3 root wheel 512 Jul 1 20:21 cgi 2 drwxr-xr-x 5 vpopmail vchkpw 512 Sep 25 14:56 cgi-bin 2 drwxr-xr-x 3 root wheel 512 Sep 25 14:51 cgi-bin-dist 2 drwxr-xr-x 6 root wheel 512 Sep 25 15:28 data 2 drwxr-xr-x 3 root wheel 1024 Sep 25 14:51 data-dist 4 drwxr-xr-x 3 root wheel 3584 Jul 1 21:05 icons 2 drwxr-xr-x 2 www www 512 Jul 1 21:05 proxy bash-2.05b# bash-2.05b# ls -als cgi-bin total 10 2 drwxr-xr-x 5 vpopmail vchkpw 512 Sep 25 14:56 . 2 drwxr-xr-x 9 root wheel 512 Jul 1 21:05 .. 2 drwxr-xr-x 2 root wheel 512 Jul 1 20:21 qmailadmin 2 drwxr-xr-x 2 root wheel 512 Jul 1 20:36 sqwebmail 2 drwxr-xr-x 3 vpopmail vchkpw 512 Sep 25 14:51 vqadmin bash-2.05b# My httpd.conf is > ServerAdmin root@mydomain.com DocumentRoot /usr/local/www/cgi-bin/vqadmin ServerName mydomain.com #ServerAlias mydomain.com ScriptAlias /cgi-bin "/usr/local/www/cgi-bin" .htaccess is AuthType Basic AuthUserFile /usr/local/etc/apache/.htpasswd AuthName vQadmin require valid-user satisfy any but when *http://www.mydomain.com/cgi-bin/vqadmin/vqadmin.cgi* *Authentication Failed Username unknown* *vQadmin was unable to determine your username, which means your webserver is improperly configured to run with this CGI. For security reasons, this script will not run without Apache htaccess lists. vqadmin 2.3.6 vpopmail 5.4.10* How I can get vqadmin management page? From owner-freebsd-isp@FreeBSD.ORG Mon Sep 26 18:16:38 2005 Return-Path: X-Original-To: freebsd-isp@freebsd.org Delivered-To: freebsd-isp@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 77E7516A41F; Mon, 26 Sep 2005 18:16:38 +0000 (GMT) (envelope-from ike@lesmuug.org) Received: from beth.easthouston.org (dsl254-117-002.nyc1.dsl.speakeasy.net [216.254.117.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0CE6043D66; Mon, 26 Sep 2005 18:16:35 +0000 (GMT) (envelope-from ike@lesmuug.org) Received: from [192.168.1.22] (249-218.customer.cloud9.net [168.100.249.218]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by beth.easthouston.org (Postfix) with ESMTP id 932B2D9AC20; Mon, 26 Sep 2005 14:16:34 -0400 (EDT) In-Reply-To: <20050924141025.GA1236@uk.tiscali.com> References: <20050924141025.GA1236@uk.tiscali.com> Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Isaac Levy Date: Mon, 26 Sep 2005 14:16:31 -0400 To: Brian Candler X-Mailer: Apple Mail (2.734) Cc: freebsd-isp@freebsd.org, freebsd-cluster@freebsd.org Subject: Re: Options for synchronising filesystems X-BeenThere: freebsd-isp@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Internet Services Providers List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Sep 2005 18:16:38 -0000 Hi Brian, All, This email has one theme: GEOM! :) On Sep 24, 2005, at 10:10 AM, Brian Candler wrote: > Hello, > > I was wondering if anyone would care to share their experiences in > synchronising filesystems across a number of nodes in a cluster. I > can think > of a number of options, but before changing what I'm doing at the > moment I'd > like to see if anyone has good experiences with any of the others. > > The application: a clustered webserver. The users' CGIs run in a > chroot > environment, and these clearly need to be identical (otherwise a > CGI running > on one box would behave differently when running on a different box). > Ultimately I'd like to synchronise the host OS on each server too. > > Note that this is a single-master, multiple-slave type of filesystem > synchronisation I'm interested in. I just wanted to throw out some quick thoughts on a totally different approach which nobody has really explored in this thread, solutions which are production level software. (Sorry if I'm repeating things or giving out info yall' already know:) -- Geom: http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/geom- intro.html The core Disk IO framework for FreeBSD, as of 5.x, led by PHK: http://www.bsdcan.org/2004/papers/geom.pdf This framework itself is not as useful to you as the utilities which make use of it, -- Geom Gate: http://kerneltrap.org/news/freebsd?from=20 Network device-level client/server disk mapping tool. (VERY IMPORTANT COMPONENT, it's reportedly faster, and more stable than NFS has ever been- so people have immediately and happily deployed it in production systems!) -- Gvinum and Gmirror: Gmirror http://people.freebsd.org/~rse/mirror/ http://www.ie.freebsd.org/doc/en_US.ISO8859-1/books/handbook/geom.html (Sidenote: even Greg Lehey (original author of Vinum), has stated that it's better to use Geom-based tools than Vinum for the forseeable future.) -- In a nutshell, to address your needs, let me toss out the following example setup: I know of one web-shop in Canada, which is running 2 machines for every virtual cluster, in the following configuration: 2 servers, 4 SATA drives per box, quad copper/ethernet gigabit nic on each box each drive is mirrored using gmirror, over each of the gigabit ethernet nics each box is running Vinum Raid5 across the 4 mirrored drives The drives are then sliced appropriately, and server resources are distributed across the boxes- with various slices mounted on each box. The folks I speak of simply have a suite of failover shell scripts prepared, in the event of a machine experiencing total hardware failure. Pretty tough stuff, very high-performance, and CHEAP. -- With that, I'm working towards similar setups, oriented around redundant jailed systems, with an eventual end to tie CARP (from pf) into the mix to make for nearly-instantaneous jailed failover redundancy- (but it's going to be some time before I have what I want worked out for production on my own). Regardless, it's worth tapping into the GEOM dialogues, as there are many new ways of working with disks coming into existence- and the GEOM framework itself provides an EXTREMELY solid base to bring 'exotic' disk configurations up to production level quickly. (Also noteworthy, there's a couple of encrypted disk systems based on GEOM emerging now too...) -- Hope all that helps, Best, .ike From owner-freebsd-isp@FreeBSD.ORG Mon Sep 26 20:38:09 2005 Return-Path: X-Original-To: freebsd-isp@freebsd.org Delivered-To: freebsd-isp@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2F96F16A496; Mon, 26 Sep 2005 20:38:09 +0000 (GMT) (envelope-from anderson@centtech.com) Received: from mh1.centtech.com (moat3.centtech.com [207.200.51.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6D82C43D58; Mon, 26 Sep 2005 20:38:07 +0000 (GMT) (envelope-from anderson@centtech.com) Received: from [10.177.171.220] (neutrino.centtech.com [10.177.171.220]) by mh1.centtech.com (8.13.1/8.13.1) with ESMTP id j8QKc6nK077563; Mon, 26 Sep 2005 15:38:06 -0500 (CDT) (envelope-from anderson@centtech.com) Message-ID: <43385C29.5060406@centtech.com> Date: Mon, 26 Sep 2005 15:38:01 -0500 From: Eric Anderson User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.11) Gecko/20050914 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Isaac Levy References: <20050924141025.GA1236@uk.tiscali.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.82/1102/Sun Sep 25 09:04:56 2005 on mh1.centtech.com X-Virus-Status: Clean Cc: freebsd-isp@freebsd.org, freebsd-cluster@freebsd.org Subject: Re: Options for synchronising filesystems X-BeenThere: freebsd-isp@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Internet Services Providers List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Sep 2005 20:38:09 -0000 Isaac Levy wrote: > Hi Brian, All, > > This email has one theme: GEOM! :) > > On Sep 24, 2005, at 10:10 AM, Brian Candler wrote: > >> Hello, >> >> I was wondering if anyone would care to share their experiences in >> synchronising filesystems across a number of nodes in a cluster. I >> can think >> of a number of options, but before changing what I'm doing at the >> moment I'd >> like to see if anyone has good experiences with any of the others. >> >> The application: a clustered webserver. The users' CGIs run in a chroot >> environment, and these clearly need to be identical (otherwise a CGI >> running >> on one box would behave differently when running on a different box). >> Ultimately I'd like to synchronise the host OS on each server too. >> >> Note that this is a single-master, multiple-slave type of filesystem >> synchronisation I'm interested in. > > > I just wanted to throw out some quick thoughts on a totally different > approach which nobody has really explored in this thread, solutions > which are production level software. (Sorry if I'm repeating things or > giving out info yall' already know:) > > -- > Geom: > http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/geom- intro.html > > The core Disk IO framework for FreeBSD, as of 5.x, led by PHK: > http://www.bsdcan.org/2004/papers/geom.pdf > > This framework itself is not as useful to you as the utilities which > make use of it, > > -- > Geom Gate: > http://kerneltrap.org/news/freebsd?from=20 > > Network device-level client/server disk mapping tool. > (VERY IMPORTANT COMPONENT, it's reportedly faster, and more stable than > NFS has ever been- so people have immediately and happily deployed it > in production systems!) > > -- > Gvinum and Gmirror: > > Gmirror > http://people.freebsd.org/~rse/mirror/ > http://www.ie.freebsd.org/doc/en_US.ISO8859-1/books/handbook/geom.html > > (Sidenote: even Greg Lehey (original author of Vinum), has stated that > it's better to use Geom-based tools than Vinum for the forseeable future.) > > -- > In a nutshell, to address your needs, let me toss out the following > example setup: > > I know of one web-shop in Canada, which is running 2 machines for every > virtual cluster, in the following configuration: > > 2 servers, > 4 SATA drives per box, > quad copper/ethernet gigabit nic on each box > > each drive is mirrored using gmirror, over each of the gigabit ethernet > nics > each box is running Vinum Raid5 across the 4 mirrored drives > > The drives are then sliced appropriately, and server resources are > distributed across the boxes- with various slices mounted on each box. > The folks I speak of simply have a suite of failover shell scripts > prepared, in the event of a machine experiencing total hardware failure. > > Pretty tough stuff, very high-performance, and CHEAP. > > -- > With that, I'm working towards similar setups, oriented around > redundant jailed systems, with an eventual end to tie CARP (from pf) > into the mix to make for nearly-instantaneous jailed failover > redundancy- (but it's going to be some time before I have what I want > worked out for production on my own). > > Regardless, it's worth tapping into the GEOM dialogues, as there are > many new ways of working with disks coming into existence- and the GEOM > framework itself provides an EXTREMELY solid base to bring 'exotic' > disk configurations up to production level quickly. > (Also noteworthy, there's a couple of encrypted disk systems based on > GEOM emerging now too...) I think the original poster (and I at least) knew about this already, but what I still fail to see is how you can get several machines using the same data at the same time, and still do updates to that data? The only way I know of is to use a syncing tool (like rsync) or a shared filesystem (like NFS, or CXFS, or Polyserve FS, opengfs, etc), none of which run on FreeBSD. What I read from above, is a redundant server setup, not a high-performance setup (meaning multiple machines serving the same data to many clients). If I'm missing something, please fill me in.. Eric -- ------------------------------------------------------------------------ Eric Anderson Sr. Systems Administrator Centaur Technology Anything that works is better than anything that doesn't. ------------------------------------------------------------------------ From owner-freebsd-isp@FreeBSD.ORG Mon Sep 26 20:45:51 2005 Return-Path: X-Original-To: freebsd-isp@freebsd.org Delivered-To: freebsd-isp@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B636516A41F for ; Mon, 26 Sep 2005 20:45:51 +0000 (GMT) (envelope-from rdo.oliveira@gmail.com) Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.200]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4D36543D72 for ; Mon, 26 Sep 2005 20:45:51 +0000 (GMT) (envelope-from rdo.oliveira@gmail.com) Received: by zproxy.gmail.com with SMTP id 40so462718nzk for ; Mon, 26 Sep 2005 13:45:50 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=PJ1cMA71nqSpeH8XlpZVb8xoiyus+nbHi+L6lUMkh+sEP3e3/zXhwkgHenbMk0lL+kSCE0QeA75jKvQsQ+6DVQ8jC032gp9guv1pwqwmUnuTEzT+57TaklBq4Y3Jx15vL3mp7EQ+mMdQK9MbUPCSik+C5a7md2hpZpwbkQ+DzE4= Received: by 10.36.138.6 with SMTP id l6mr1971211nzd; Mon, 26 Sep 2005 13:45:50 -0700 (PDT) Received: by 10.36.247.31 with HTTP; Mon, 26 Sep 2005 13:45:50 -0700 (PDT) Message-ID: Date: Mon, 26 Sep 2005 21:45:50 +0100 From: Rui Oliveira To: freebsd-isp@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Subject: PPPoE Server Problems, no internet, wrong gateway and netmask. need help ! X-BeenThere: freebsd-isp@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Rui Oliveira List-Id: Internet Services Providers List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Sep 2005 20:45:51 -0000 Hello, I have configures PPPoE Server + IPFW from warta project but my ppp client doesnt have internet access and pppoe server gives the wrong gateway and netmask. The problem and all the infos are here: http://pastebin.com/374637 I did search into google for many time and i didn=B4t find any solution for my problem, so if any one could help i apreciate. Thanks SpaceminD PT -- Sem Mais Rui Oliveira From owner-freebsd-isp@FreeBSD.ORG Mon Sep 26 21:27:34 2005 Return-Path: X-Original-To: freebsd-isp@freebsd.org Delivered-To: freebsd-isp@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8757816A41F; Mon, 26 Sep 2005 21:27:34 +0000 (GMT) (envelope-from ike@lesmuug.org) Received: from beth.easthouston.org (dsl254-117-002.nyc1.dsl.speakeasy.net [216.254.117.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2C02F43D48; Mon, 26 Sep 2005 21:27:34 +0000 (GMT) (envelope-from ike@lesmuug.org) Received: from [192.168.1.22] (249-218.customer.cloud9.net [168.100.249.218]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by beth.easthouston.org (Postfix) with ESMTP id 5115BD9B887; Mon, 26 Sep 2005 17:27:33 -0400 (EDT) In-Reply-To: <43385C29.5060406@centtech.com> References: <20050924141025.GA1236@uk.tiscali.com> <43385C29.5060406@centtech.com> Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Isaac Levy Date: Mon, 26 Sep 2005 17:27:30 -0400 To: Eric Anderson X-Mailer: Apple Mail (2.734) Cc: freebsd-isp@freebsd.org, freebsd-cluster@freebsd.org Subject: Re: Options for synchronising filesystems X-BeenThere: freebsd-isp@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Internet Services Providers List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Sep 2005 21:27:34 -0000 Hi Eric, All, On Sep 26, 2005, at 4:38 PM, Eric Anderson wrote: > I think the original poster (and I at least) knew about this > already, but what I still fail to see is how you can get several > machines using the same data at the same time, and still do updates > to that data? The only way I know of is to use a syncing tool > (like rsync) or a shared filesystem (like NFS, or CXFS, or > Polyserve FS, opengfs, etc), none of which run on FreeBSD. Gotcha, I did skip somewhat to the side of the original requirements, > > What I read from above, is a redundant server setup, not a high- > performance setup (meaning multiple machines serving the same data > to many clients). If I'm missing something, please fill me in.. I'm not certain that my intention was to provide the best answer, but to provide yet another set of tools to get the job done. In effect, a terse example of how someone could use the Geom tools I mentioned, to meet this requirement: + Setup mirrored disks across machines as discussed before + Mount a slice of that disk Read/Write on one machine (acting as master) + Mount that same slice Readonly on both machines, using Geom Gate, and serve data from there. - If the master machine dies, mount the volume Read/Write on the other machine I'm not certain if this meets the requirements precisely, but I believe there may be a combination of these Geom-based utilities which would- and they are all actively under continued development. -- Eric, you are definately correct, that there's not really a disk- level mechanism to maintain concurrent writes between volumes mounted across servers using FreeBSD (excepting NFS, which in this context, makes me say *yuck*). Anyone with some spare time want to take up this problem as a new Geom project? ;) However, based on my experiences with distributed database clusters, I believe it's fair to say that any persistent data (writes) are a very difficult task to get done right across a cluster- and maintain contextually sane levels of performance, (due to resource locking issues, mixed with network latency, etc...) I guess I'm saying this is a big-picture computing problem IMHO, and I don't know of a good solution here (though I'm curious about what kind of work has been done in Dragonfly which is relevant?) > > Eric > -- Got a spare NetApp anyone? My head hurts. :) Best, .ike From owner-freebsd-isp@FreeBSD.ORG Mon Sep 26 21:39:36 2005 Return-Path: X-Original-To: freebsd-isp@freebsd.org Delivered-To: freebsd-isp@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3541716A41F; Mon, 26 Sep 2005 21:39:36 +0000 (GMT) (envelope-from b.candler@pobox.com) Received: from orb.pobox.com (orb.pobox.com [207.8.226.5]) by mx1.FreeBSD.org (Postfix) with ESMTP id B6C4E43D48; Mon, 26 Sep 2005 21:39:35 +0000 (GMT) (envelope-from b.candler@pobox.com) Received: from orb (localhost [127.0.0.1]) by orb.pobox.com (Postfix) with ESMTP id 8C4871DDA; Mon, 26 Sep 2005 17:39:56 -0400 (EDT) Received: from billdog.local.linnet.org (dsl-212-74-113-66.access.uk.tiscali.com [212.74.113.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by orb.sasl.smtp.pobox.com (Postfix) with ESMTP id 30976A2; Mon, 26 Sep 2005 17:39:54 -0400 (EDT) Received: from brian by billdog.local.linnet.org with local (Exim 4.50 (FreeBSD)) id 1EK0kf-0000Cx-U9; Mon, 26 Sep 2005 22:43:09 +0100 Date: Mon, 26 Sep 2005 22:43:09 +0100 From: Brian Candler To: Isaac Levy Message-ID: <20050926214309.GA766@uk.tiscali.com> References: <20050924141025.GA1236@uk.tiscali.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i Cc: freebsd-isp@freebsd.org, freebsd-cluster@freebsd.org Subject: Re: Options for synchronising filesystems X-BeenThere: freebsd-isp@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Internet Services Providers List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Sep 2005 21:39:36 -0000 On Mon, Sep 26, 2005 at 02:16:31PM -0400, Isaac Levy wrote: > I just wanted to throw out some quick thoughts on a totally different > approach which nobody has really explored in this thread Geom (gmirror plus ggated/ggatec) was what I suggested for syncing two NFS servers (my option 2) or for direct synchronisation of the clients' filesystems to the servers (my option 4). The problem occurs when a client actually *mounts* and uses the mirrored copy, rather than just keeping a mirrored copy for resilience. > Geom Gate: > http://kerneltrap.org/news/freebsd?from=20 > > Network device-level client/server disk mapping tool. > (VERY IMPORTANT COMPONENT, it's reportedly faster, and more stable > than NFS has ever been- so people have immediately and happily > deployed it in production systems!) NFS and geom gate are two different things, so you can't really compare them directly. NFS shares files; geom gate shares a block level device. With NFS you can have one server and multiple clients, and the clients can access this filesystem read-write. With geom gate, you just have remote access to a disk partition, and essentially can only do what you could do with a local block device. Incidentally, NFS has been *hugely* dependable for me in production environments. However I've always used expensive and beefy NFS servers (Netapp) whilst FreeBSD is just the client. > I know of one web-shop in Canada, which is running 2 machines for > every virtual cluster, in the following configuration: > > 2 servers, > 4 SATA drives per box, > quad copper/ethernet gigabit nic on each box > > each drive is mirrored using gmirror, over each of the gigabit > ethernet nics > each box is running Vinum Raid5 across the 4 mirrored drives > > The drives are then sliced appropriately, and server resources are > distributed across the boxes- with various slices mounted on each box. > The folks I speak of simply have a suite of failover shell scripts > prepared, in the event of a machine experiencing total hardware failure. Right. But unless I'm mistaken, the remote mirrors are just backup copies of the data. Those remote mirrors are not actually *mounted* as filesystems. I think you're talking about a master/slave failover scenario. With careful arrangement, machine 1 can be master for dataset A and slave for dataset B, while machine 2 is slave for A and master for B, so you're not wasting your second machine. If machine 1 fails, machine 2 can take over both datasets. That's fine. However, what I need is for dataset A to be generated on machine 1 and identical copies available on machines 2, 3, 4, 5...9. Not just *stored* there, but actually *used* there, as live read-only copies. So if machine 1 makes a change to the dataset, all the other machines notice the change properly and start using it immediately. >From what I've heard, I can't use gmirror from machine 1 to machines 2-9, because you can't mount a filesystem readonly while some other machine magically updates the blocks from under its nose. The filesystem gets confused because its local caches of blocks and inodes become out of date when the data in the block device changes. > Regardless, it's worth tapping into the GEOM dialogues GEOM is definitely cool, and a strong selling point for moving from 4.x to 5.x Regards, Brian. From owner-freebsd-isp@FreeBSD.ORG Mon Sep 26 21:50:12 2005 Return-Path: X-Original-To: freebsd-isp@freebsd.org Delivered-To: freebsd-isp@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 78EB116A41F for ; Mon, 26 Sep 2005 21:50:12 +0000 (GMT) (envelope-from daniel@lvdx.com) Received: from pythagoras.zen.co.uk (pythagoras.zen.co.uk [212.23.3.140]) by mx1.FreeBSD.org (Postfix) with ESMTP id 97DC643D4C for ; Mon, 26 Sep 2005 21:50:11 +0000 (GMT) (envelope-from daniel@lvdx.com) Received: from [82.70.93.201] (helo=h1.trendhosting.net) by pythagoras.zen.co.uk with esmtp (Exim 4.30) id 1EK0rR-000791-G0 for freebsd-isp@freebsd.org; Mon, 26 Sep 2005 21:50:09 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by h1.trendhosting.net (Postfix) with ESMTP id B1941DEC5A for ; Mon, 26 Sep 2005 22:50:08 +0100 (BST) Message-ID: <43386D0D.7000209@lvdx.com> Date: Mon, 26 Sep 2005 22:50:05 +0100 From: Daniel Pocock User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.8) Gecko/20050513 Debian/1.7.8-1 X-Accept-Language: en MIME-Version: 1.0 To: freebsd-isp@freebsd.org References: <432EC4FF.4030706@lvdx.com> <20050919205757.GI62233@complx.LF.net> <432F3013.7090001@keystreams.com> <20050919214618.GJ62233@complx.LF.net> <20050919215605.GK62233@complx.LF.net> <432F4507.4020708@lvdx.com> <432F4A12.9090709@mac.com> In-Reply-To: <432F4A12.9090709@mac.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms000203000804020905090400" X-Originating-Pythagoras-IP: [82.70.93.201] Subject: Re: FreeBSD, quagga (BGP) and 2950 VLANs X-BeenThere: freebsd-isp@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Internet Services Providers List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Sep 2005 21:50:12 -0000 This is a cryptographically signed message in MIME format. --------------ms000203000804020905090400 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Chuck Swiger wrote: > Daniel Pocock wrote: > [ ... ] > >> I'm also curious about whether FreeBSD supports polled rather than >> interrupt driven behaviour in the NIC driver - that means that the >> system won't keep on re-entering an interrupt handler concurrently >> while under load (when a DoS attack is in progress). > > > Indeed it does, see "man polling". > Make sure you increase HZ to at least 1000... > Good news - I got the quagga and vlan stuff working. Thanks for all those who gave tips on this issue. It was surprisingly easy to get all this going and I'm now receiving a full BGP table from an upstream provider. I'm now starting to look at how to filter packets that I am forwarding, to ensure that none of the people I connect to can use me as their default route (unless I give them permission to do so). The FreeBSD docs mention three different packet filters - pf, ipfw and ipf. Does any of these have specific benefits for a routing device that is forwarding 99.9% of it's traffic to other hosts, or is it just a question of personal preference? The rules I intend to write are fairly simple, and I don't need any state-based stuff. -------------------------------------- Director London Voice and Data Exchange Limited http://www.lvdx.com -------------------------------------- --------------ms000203000804020905090400 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIII4TCC AsswggI0oAMCAQICAw4bBzANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UE ChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNv bmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwHhcNMDUwMjIyMTcwMTQ2WhcNMDYwMjIyMTcwMTQ2 WjBBMR8wHQYDVQQDExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMR4wHAYJKoZIhvcNAQkBFg9k YW5pZWxAbHZkeC5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDzR3Orw/fI sDm1pnwnQMEwiETBQcKtjolpydPqx0vhhZltrsd1pFxksr2kgylwclf1Ru2Jl/IoyjctJhZn VzADqrXjSlyf6efn/VBigEwKraH64ijM10aaTq72wMfs5/6i3YgxSHfOGkz0Tw5u2rwmL7cl teyP/Bv3PZxIqcfvaRVIKM6GhBrBUE+4UfOA5ggrQy1UKLjflnDgW5+UcIuPPvq5nPecfzKs FbmuGyG7m+tNzN+QRBp9//gIOWEuth9dvKI8g1RJ23PS6mHmH/2+nGeyT8n9F0bGjndCVAyk PUHv6JcAaTCeJcezOsJ96+8F+d66xIn+M1pey1XTwjx9AgMBAAGjLDAqMBoGA1UdEQQTMBGB D2RhbmllbEBsdmR4LmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GBABUeLsOY W/0NBblgBJoUjD0lvoQyAi5M5chYlww19zWE4bL7XONYqp897JTJFumcN3nFwPJygWAgXozZ Qqd2tnw5bKyOUcISoO8w4+Ipna2Xs7gf+dLCAsYBPY7RY9ID2y/IEA5gvn7HpDf3N4AwtkYr kcCeQmqcuT5xUt/YbjBkMIICyzCCAjSgAwIBAgIDDhsHMA0GCSqGSIb3DQEBBAUAMGIxCzAJ BgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYD VQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTAeFw0wNTAyMjIxNzAx NDZaFw0wNjAyMjIxNzAxNDZaMEExHzAdBgNVBAMTFlRoYXd0ZSBGcmVlbWFpbCBNZW1iZXIx HjAcBgkqhkiG9w0BCQEWD2RhbmllbEBsdmR4LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEP ADCCAQoCggEBAPNHc6vD98iwObWmfCdAwTCIRMFBwq2OiWnJ0+rHS+GFmW2ux3WkXGSyvaSD KXByV/VG7YmX8ijKNy0mFmdXMAOqteNKXJ/p5+f9UGKATAqtofriKMzXRppOrvbAx+zn/qLd iDFId84aTPRPDm7avCYvtyW17I/8G/c9nEipx+9pFUgozoaEGsFQT7hR84DmCCtDLVQouN+W cOBbn5Rwi48++rmc95x/MqwVua4bIbub603M35BEGn3/+Ag5YS62H128ojyDVEnbc9LqYeYf /b6cZ7JPyf0XRsaOd0JUDKQ9Qe/olwBpMJ4lx7M6wn3r7wX53rrEif4zWl7LVdPCPH0CAwEA AaMsMCowGgYDVR0RBBMwEYEPZGFuaWVsQGx2ZHguY29tMAwGA1UdEwEB/wQCMAAwDQYJKoZI hvcNAQEEBQADgYEAFR4uw5hb/Q0FuWAEmhSMPSW+hDICLkzlyFiXDDX3NYThsvtc41iqnz3s lMkW6Zw3ecXA8nKBYCBejNlCp3a2fDlsrI5RwhKg7zDj4imdrZezuB/50sICxgE9jtFj0gPb L8gQDmC+fsekN/c3gDC2RiuRwJ5Capy5PnFS39huMGQwggM/MIICqKADAgECAgENMA0GCSqG SIb3DQEBBQUAMIHRMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYD VQQHEwlDYXBlIFRvd24xGjAYBgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5nMSgwJgYDVQQLEx9D ZXJ0aWZpY2F0aW9uIFNlcnZpY2VzIERpdmlzaW9uMSQwIgYDVQQDExtUaGF3dGUgUGVyc29u YWwgRnJlZW1haWwgQ0ExKzApBgkqhkiG9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRoYXd0 ZS5jb20wHhcNMDMwNzE3MDAwMDAwWhcNMTMwNzE2MjM1OTU5WjBiMQswCQYDVQQGEwJaQTEl MCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3Rl IFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJ AoGBAMSmPFVzVftOucqZWh5owHUEcJ3f6f+jHuy9zfVb8hp2vX8MOmHyv1HOAdTlUAow1wJj WiyJFXCO3cnwK4Vaqj9xVsuvPAsH5/EfkTYkKhPPK9Xzgnc9A74r/rsYPge/QIACZNenpruf ZdHFKlSFD0gEf6e20TxhBEAeZBlyYLf7AgMBAAGjgZQwgZEwEgYDVR0TAQH/BAgwBgEB/wIB ADBDBgNVHR8EPDA6MDigNqA0hjJodHRwOi8vY3JsLnRoYXd0ZS5jb20vVGhhd3RlUGVyc29u YWxGcmVlbWFpbENBLmNybDALBgNVHQ8EBAMCAQYwKQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMT EVByaXZhdGVMYWJlbDItMTM4MA0GCSqGSIb3DQEBBQUAA4GBAEiM0VCD6gsuzA2jZqxnD3+v rL7CF6FDlpSdf0whuPg2H6otnzYvwPQcUCCTcDz9reFhYsPZOhl+hLGZGwDFGguCdJ4lUJRi x9sncVcljd2pnDmOjCBPZV+V2vf3h9bGCE6u9uo05RAaWzVNd+NWIXiC3CEZNd4ksdMdRv9d X2VPMYIDOzCCAzcCAQEwaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1 bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElz c3VpbmcgQ0ECAw4bBzAJBgUrDgMCGgUAoIIBpzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB MBwGCSqGSIb3DQEJBTEPFw0wNTA5MjYyMTUwMDVaMCMGCSqGSIb3DQEJBDEWBBQ9xI8eShls jE7wxwxBMiEHtLACUzBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMC AgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDB4BgkrBgEEAYI3 EAQxazBpMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQID DhsHMHoGCyqGSIb3DQEJEAILMWugaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3Rl IENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0ECAw4bBzANBgkqhkiG9w0BAQEFAASCAQCBka4V5JTa22ytnFcMzBB1 G7Yaif52JkQaK8kvo/6zispSBnRoCY2pD8DY0EOGbah5Cc0u7kpTu6okFH1z28CzM8q4a/Dj k8PbahFuAE7NqnLu6srhGnoUHan/wEUffKGPjPUnx0ULs2zDV8spv9GQUsWhVvLaqm32Q3Zc qJHzkUqVqh2VgMOu6HIczPVJIjp+Y1DoFdS2cNcBqTKKbYcExxS3SzaIfaFBu9Xn8nLUn4ER LJZdBOwoTBezCSE/n7gVryT8AxnrispgIR/GCsSl1ja2c1ibsmUNBZmp2aLEM6HxAOGXqbSC O7cRv7+LV59udBiwFbVIPUsiFeF7hcYOAAAAAAAA --------------ms000203000804020905090400-- From owner-freebsd-isp@FreeBSD.ORG Tue Sep 27 05:39:45 2005 Return-Path: X-Original-To: freebsd-isp@freebsd.org Delivered-To: freebsd-isp@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5A18916A41F for ; Tue, 27 Sep 2005 05:39:45 +0000 (GMT) (envelope-from lists@complx.LF.net) Received: from complx.LF.net (complx.LF.net [212.9.190.63]) by mx1.FreeBSD.org (Postfix) with ESMTP id EE31A43D4C for ; Tue, 27 Sep 2005 05:39:42 +0000 (GMT) (envelope-from lists@complx.LF.net) Received: from lists by complx.LF.net with local (Exim 4.43) id 1EK8Bp-0009Tt-Ct; Tue, 27 Sep 2005 07:39:41 +0200 Date: Tue, 27 Sep 2005 07:39:41 +0200 From: Kurt Jaeger To: Daniel Pocock Message-ID: <20050927053941.GW62233@complx.LF.net> References: <432EC4FF.4030706@lvdx.com> <20050919205757.GI62233@complx.LF.net> <432F3013.7090001@keystreams.com> <20050919214618.GJ62233@complx.LF.net> <20050919215605.GK62233@complx.LF.net> <432F4507.4020708@lvdx.com> <432F4A12.9090709@mac.com> <43386D0D.7000209@lvdx.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <43386D0D.7000209@lvdx.com> Cc: freebsd-isp@freebsd.org Subject: Filtering (was Re: FreeBSD, quagga (BGP) and 2950 VLANs) X-BeenThere: freebsd-isp@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Internet Services Providers List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Sep 2005 05:39:45 -0000 Hello, > I'm now starting to look at how to filter packets that I am forwarding, > to ensure that none of the people I connect to can use me as their > default route (unless I give them permission to do so). The FreeBSD > docs mention three different packet filters - pf, ipfw and ipf. We use ipfw on Freebsd. It's simple and it works and it's the native approach. pf is a relevant alternative, because it's very actively developed from the openbsd community. ipf: Its very portable on other plattforms, but it looks a bit stale (?). > Does any of these have specific benefits for a routing device that is > forwarding 99.9% of it's traffic to other hosts, or is it just a > question of personal preference? The rules I intend to write are fairly > simple, and I don't need any state-based stuff. If you start anew, maybe pf is the way to go. -- MfG/Best regards, Kurt Jaeger 15 years to go ! LF.net GmbH fon +49 711 90074-23 pi@LF.net Ruppmannstr. 27 fax +49 711 90074-33 D-70565 Stuttgart mob +49 171 3101372 From owner-freebsd-isp@FreeBSD.ORG Tue Sep 27 09:37:06 2005 Return-Path: X-Original-To: freebsd-isp@freebsd.org Delivered-To: freebsd-isp@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 24D2716A41F for ; Tue, 27 Sep 2005 09:37:06 +0000 (GMT) (envelope-from steve.rieger@tbwachiat.com) Received: from up-south.com (cpe-24-29-149-124.nyc.res.rr.com [24.29.149.124]) by mx1.FreeBSD.org (Postfix) with ESMTP id D50E243D48 for ; Tue, 27 Sep 2005 09:37:05 +0000 (GMT) (envelope-from steve.rieger@tbwachiat.com) Received: from [10.20.4.142] (nyhost250.pool.tbwachiat.com [208.244.205.250]) by up-south.com (Postfix) with ESMTP id C7427442629; Tue, 27 Sep 2005 05:37:04 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Steve Rieger Date: Tue, 27 Sep 2005 05:37:03 -0400 To: freebsd-isp@freebsd.org X-Mailer: Apple Mail (2.734) Subject: FATAL: erealloc(): Unable to allocate 577925121 bytes X-BeenThere: freebsd-isp@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Internet Services Providers List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Sep 2005 09:37:06 -0000 hi all this is causing me major headaches. when trying to d/l the following file 1 www www 551M Sep 16 13:23 20050818002.zip via apache1.3.33/php 4.3.11, i get that in the logs i thought it was because i dont have enough swap so i did cat /etc/rc.conf mdconfig -a -t vnode -f /usr/swap1 -u 1 && swapon /dev/md1 mdconfig -a -t vnode -f /usr/swap2 -u 2 && swapon /dev/md2 mdconfig -a -t vnode -f /usr/swap3 -u 3 && swapon /dev/md3 mdconfig -a -t vnode -f /usr/swap4 -u 4 && swapon /dev/md4 %swapinfo Device 1K-blocks Used Avail Capacity /dev/da0s1b 4194304 0 4194304 0% /dev/md2 262144 0 262144 0% /dev/md3 262144 0 262144 0% /dev/md4 262144 0 262144 0% /dev/md5 262144 0 262144 0% /dev/md6 1048576 0 1048576 0% Total 6291456 0 6291456 0% which means i have more than enough swap and a show of top proves it last pid: 1275; load averages: 0.24, 0.19, 0.16 up 0 +00:34:42 05:31:19 73 processes: 1 running, 72 sleeping CPU states: % user, % nice, % system, % interrupt, % idle Mem: 38M Active, 25M Inact, 54M Wired, 46M Cache, 61M Buf, 3348M Free Swap: 6143M Total, 6143M Free i set the following in the local dir in htaccess php_value upload_max_filesize 300M php_value memory_limit 947M php_value max_input_time 120 php_value max_execution_time 120 php_value post_max_size 947M i want 1 gig to be the limit of downloads. note this is on freebsd 5.4 custom kernel with smp. and yes i can scp these large files, as far as i can see i am not doing anything wrong, then why cant i download a 551 MB file anything under say 450 MB works great. Steve Rieger steve.rieger@tbwachiat.com Cell 646-335-8915 Office 212 804 1131 Fax 212 804 1200 AIM chozrim Yahoo riegersteve From owner-freebsd-isp@FreeBSD.ORG Tue Sep 27 12:42:42 2005 Return-Path: X-Original-To: freebsd-isp@freebsd.org Delivered-To: freebsd-isp@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2939D16A420 for ; Tue, 27 Sep 2005 12:42:42 +0000 (GMT) (envelope-from b.candler@pobox.com) Received: from leto.uk.clara.net (leto.uk.clara.net [80.168.69.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id A015E43D53 for ; Tue, 27 Sep 2005 12:42:41 +0000 (GMT) (envelope-from b.candler@pobox.com) Received: from bloodhound.noc.clara.net ([195.8.70.207]) by leto.uk.clara.net with esmtp (Exim 4.43) id 1EKEnA-000E9z-RA; Tue, 27 Sep 2005 13:42:40 +0100 Received: from personal by bloodhound.noc.clara.net with local (Exim 4.52 (FreeBSD)) id 1EKEnR-000Coh-FK; Tue, 27 Sep 2005 13:42:57 +0100 Date: Tue, 27 Sep 2005 13:42:57 +0100 From: Brian Candler To: Steve Rieger Message-ID: <20050927124256.GA49100@uk.tiscali.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i Cc: freebsd-isp@freebsd.org Subject: Re: FATAL: erealloc(): Unable to allocate 577925121 bytes X-BeenThere: freebsd-isp@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Internet Services Providers List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Sep 2005 12:42:42 -0000 > as far as i can see i am not doing anything wrong, then why cant i > download a 551 MB file You're probably hitting the default 512MB maximum process data segment limit somewhere, I guess on the client end as I would expect Apache to use sendfile() to transmit a large file. Try typing: $ ulimit -a core file size (blocks, -c) unlimited data seg size (kbytes, -d) 524288 << THIS LIMIT file size (blocks, -f) unlimited max locked memory (kbytes, -l) unlimited max memory size (kbytes, -m) unlimited open files (-n) 11095 pipe size (512 bytes, -p) 1 stack size (kbytes, -s) 65536 cpu time (seconds, -t) unlimited max user processes (-u) 5547 virtual memory (kbytes, -v) unlimited Now, I can never remember how to increase this, and I always have to rummage around the kernel source code. Ah yes, it's options MAXDSIZ=(1024UL*1024*1024) in the kernel configuration. See /usr/src/sys/conf/NOTES However, it seems to me that's the wrong thing to do here. If an application needs to download 1G of data, then it really should download it and spool it to disk as it goes, not spool it all into RAM and then finally write it to disk (or worse, spool it into RAM, which gets spooled to swap space on disk, which then later gets pulled back into RAM and then finally written to the filesystem). At least, that's a very poor utilisation of system resources. Regards, Brian. From owner-freebsd-isp@FreeBSD.ORG Tue Sep 27 12:53:32 2005 Return-Path: X-Original-To: freebsd-isp@freebsd.org Delivered-To: freebsd-isp@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CC57216A41F for ; Tue, 27 Sep 2005 12:53:32 +0000 (GMT) (envelope-from steve.rieger@tbwachiat.com) Received: from up-south.com (cpe-24-29-149-124.nyc.res.rr.com [24.29.149.124]) by mx1.FreeBSD.org (Postfix) with ESMTP id 821CF43D49 for ; Tue, 27 Sep 2005 12:53:32 +0000 (GMT) (envelope-from steve.rieger@tbwachiat.com) Received: from [10.20.4.142] (nyhost250.pool.tbwachiat.com [208.244.205.250]) by up-south.com (Postfix) with ESMTP id C51D644287D; Tue, 27 Sep 2005 08:53:31 -0400 (EDT) In-Reply-To: <20050927124256.GA49100@uk.tiscali.com> References: <20050927124256.GA49100@uk.tiscali.com> Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <7745CA0A-B758-4003-A4D8-1602BC7B2B50@tbwachiat.com> Content-Transfer-Encoding: 7bit From: Steve Rieger Date: Tue, 27 Sep 2005 08:53:30 -0400 To: Brian Candler X-Mailer: Apple Mail (2.734) Cc: freebsd-isp@freebsd.org Subject: Re: FATAL: erealloc(): Unable to allocate 577925121 bytes X-BeenThere: freebsd-isp@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Internet Services Providers List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Sep 2005 12:53:32 -0000 On Sep 27, 2005, at 8:42 AM, Brian Candler wrote: >> as far as i can see i am not doing anything wrong, then why cant i >> download a 551 MB file >> > > Now, I can never remember how to increase this, and I always have > to rummage > around the kernel source code. Ah yes, it's > > options MAXDSIZ=(1024UL*1024*1024) > > in the kernel configuration. See /usr/src/sys/conf/NOTES $ ulimit -a cpu time (seconds, -t) unlimited file size (512-blocks, -f) unlimited data seg size (kbytes, -d) 524288 stack size (kbytes, -s) 65536 core file size (512-blocks, -c) unlimited max memory size (kbytes, -m) unlimited locked memory (kbytes, -l) unlimited max user processes (-u) 5547 open files (-n) 11095 virtual mem size (kbytes, -v) unlimited sbsize (bytes, -b) unlimited ok now to change thanx From owner-freebsd-isp@FreeBSD.ORG Tue Sep 27 20:24:22 2005 Return-Path: X-Original-To: freebsd-isp@freebsd.org Delivered-To: freebsd-isp@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1217C16A41F for ; Tue, 27 Sep 2005 20:24:22 +0000 (GMT) (envelope-from fisp@ccstores.com) Received: from mail.qcislands.net (mail.qcislands.net [209.53.238.3]) by mx1.FreeBSD.org (Postfix) with ESMTP id CBA6043D48 for ; Tue, 27 Sep 2005 20:24:21 +0000 (GMT) (envelope-from fisp@ccstores.com) Received: from [64.114.58.101] (helo=[192.168.1.4]) by mail.qcislands.net with esmtp (Exim 4.52) id 1EKLzx-000DRA-Bg; Tue, 27 Sep 2005 13:24:21 -0700 Message-ID: <4339AA75.6020103@ccstores.com> Date: Tue, 27 Sep 2005 13:24:21 -0700 From: Jim Pazarena Organization: City Centre Stores Ltd User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-isp@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-local_scan: locally submitted (01) Subject: wifi public access X-BeenThere: freebsd-isp@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Internet Services Providers List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Sep 2005 20:24:22 -0000 I distribute wifi internet to my customers via MAC authentication at the access point, and DHCP assignment from my server. I would like to offer "wide open" (no MAC authentication) at the access point, and have my server (somehow) permit the access, or re-direct non subscribers to a sign-up page. To provide service to the tourist traffic and non clients on a pay-per-go basis. What kind of software should I be looking for? It was suggested that non-clients get routed to a specific point. How would I accomplish this? TIA Jim From owner-freebsd-isp@FreeBSD.ORG Tue Sep 27 21:27:14 2005 Return-Path: X-Original-To: freebsd-isp@freebsd.org Delivered-To: freebsd-isp@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AC66D16A41F for ; Tue, 27 Sep 2005 21:27:14 +0000 (GMT) (envelope-from lists@yazzy.org) Received: from mail.yazzy.org (mail.yazzy.org [217.8.140.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3C76943D55 for ; Tue, 27 Sep 2005 21:27:13 +0000 (GMT) (envelope-from lists@yazzy.org) Received: from lapdance.yazzy.net (unknown [192.168.99.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yazzy.org (Postfix) with ESMTP id 4549539812; Tue, 27 Sep 2005 23:27:09 +0200 (CEST) Date: Tue, 27 Sep 2005 21:26:51 +0000 From: Marcin Jessa To: Jim Pazarena Message-Id: <20050927212651.6fd6eacf.lists@yazzy.org> In-Reply-To: <4339AA75.6020103@ccstores.com> References: <4339AA75.6020103@ccstores.com> Organization: YazzY.org X-Mailer: Sylpheed version 2.0.1 (GTK+ 2.6.10; i386-portbld-freebsd6.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-isp@freebsd.org Subject: Re: wifi public access X-BeenThere: freebsd-isp@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Internet Services Providers List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Sep 2005 21:27:14 -0000 On Tue, 27 Sep 2005 13:24:21 -0700 Jim Pazarena wrote: > I distribute wifi internet to my customers via MAC > authentication at the access point, and DHCP assignment > from my server. > > I would like to offer "wide open" (no MAC authentication) > at the access point, and have my server (somehow) permit > the access, or re-direct non subscribers to a sign-up page. > > To provide service to the tourist traffic and non clients > on a pay-per-go basis. > > What kind of software should I be looking for? It was suggested > that non-clients get routed to a specific point. How would I > accomplish this? > You can use firewalling for that and redirect all unauthorized clients to some site or local squid which can allow/disallow certain domains with it's ACLs. The unauthorized users would get handed out their own network. The access point would need to run some scripts to open firewall for authorized MACs and the DHCP server would put authorized users to a different DHCP class and give them a different IP range. You could propably query your radius server and fetch all the MACs there and open up your firewall for those MACs only. Cheers. Marcin From owner-freebsd-isp@FreeBSD.ORG Tue Sep 27 21:54:35 2005 Return-Path: X-Original-To: freebsd-isp@freebsd.org Delivered-To: freebsd-isp@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4F80F16A41F for ; Tue, 27 Sep 2005 21:54:35 +0000 (GMT) (envelope-from jeff@norristechs.net) Received: from scooby.norristechs.net (scooby.norristechs.net [71.36.89.201]) by mx1.FreeBSD.org (Postfix) with ESMTP id C597843D48 for ; Tue, 27 Sep 2005 21:54:34 +0000 (GMT) (envelope-from jeff@norristechs.net) Received: from [127.0.0.1] [71.36.89.205] by scooby.norristechs.net with ESMTP (SMTPD-8.21) id AF990188; Tue, 27 Sep 2005 15:54:33 -0600 Message-ID: <4339BF96.4030404@norristechs.net> Date: Tue, 27 Sep 2005 15:54:30 -0600 From: Jeff at NorrisTechs Organization: NorrisTechs.NET.COM User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Marcin Jessa References: <4339AA75.6020103@ccstores.com> <20050927212651.6fd6eacf.lists@yazzy.org> In-Reply-To: <20050927212651.6fd6eacf.lists@yazzy.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-isp@freebsd.org, Jim Pazarena Subject: Re: wifi public access X-BeenThere: freebsd-isp@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Internet Services Providers List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Sep 2005 21:54:35 -0000 I believe you could use ipfilter or ipfirewall along with squid-cache (proxy) and Natd. All connections coming to the Internet would be picked up by the ipfilter rules and based on MAC, IP or other methods you would then forward to squid to proxy to the Internet, or redirect the connection to a sign up page. You then would need to have the web page update the ipfilter/ipfirewall rules and/or squid ruleset as well. I have seen several solutions from the users side, but not the from the admin site. Your access point would just need to be on with no WPA, WEP etc and sit between the WIFI zones and the proxy server allowing everything related to security to be setup on the BSD box(es). Just some ideas, hope the points you in the direction you wanted to. ------------------------------------------------------------------------ */Jeff Norris/* /~ Web Hosting ~ VPN Solutions ~ Network Management ~ Design, deploy, kick ass. / *N*orris*Techs* dot net http://www.norristechs.net *AOL IM or Yahoo IM: _ ntshelper _* Marcin Jessa wrote: >On Tue, 27 Sep 2005 13:24:21 -0700 >Jim Pazarena wrote: > > > >>I distribute wifi internet to my customers via MAC >>authentication at the access point, and DHCP assignment >>from my server. >> >>I would like to offer "wide open" (no MAC authentication) >>at the access point, and have my server (somehow) permit >>the access, or re-direct non subscribers to a sign-up page. >> >>To provide service to the tourist traffic and non clients >>on a pay-per-go basis. >> >>What kind of software should I be looking for? It was suggested >>that non-clients get routed to a specific point. How would I >>accomplish this? >> >> >> > >You can use firewalling for that and redirect all unauthorized >clients to some site or local squid which can allow/disallow certain >domains with it's ACLs. > >The unauthorized users would get handed out their own network. >The access point would need to run some scripts to open firewall for >authorized MACs and the DHCP server would put authorized users to a >different DHCP class and give them a different IP range. >You could propably query your radius server and fetch all the MACs >there and open up your firewall for those MACs only. > >Cheers. >Marcin > >_______________________________________________ >freebsd-isp@freebsd.org mailing list >http://lists.freebsd.org/mailman/listinfo/freebsd-isp >To unsubscribe, send any mail to "freebsd-isp-unsubscribe@freebsd.org" > > > > > From owner-freebsd-isp@FreeBSD.ORG Tue Sep 27 22:03:01 2005 Return-Path: X-Original-To: freebsd-isp@freebsd.org Delivered-To: freebsd-isp@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5298716A41F for ; Tue, 27 Sep 2005 22:03:01 +0000 (GMT) (envelope-from isbell@pd.jaring.my) Received: from smtp9.jaring.my (smtp9.jaring.my [61.6.32.59]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8C78343D48 for ; Tue, 27 Sep 2005 22:02:59 +0000 (GMT) (envelope-from isbell@pd.jaring.my) Received: from acer-57dbddb911 ([211.24.191.4]) (authenticated bits=0) by smtp9.jaring.my (8.13.4/8.13.1) with ESMTP id j8RM2s4H093345 for ; Wed, 28 Sep 2005 06:02:57 +0800 (MYT) (envelope-from isbell@pd.jaring.my) MIME-Version: 1.0 Message-Id: <4339C18B.000003.02148@ACER-57DBDDB911> Date: Wed, 28 Sep 2005 06:02:51 +0800 X-Mailer: IncrediMail (4001930) From: "LARRY C ISBELL" To: X-FID: FLAVOR00-NONE-0000-0000-000000000000 X-Priority: 3 X-Virus-Scanned: JARING E-Mail Virus Scanner v2.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Please reactivate your Yahoo! Groups account X-BeenThere: freebsd-isp@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Internet Services Providers List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Sep 2005 22:03:01 -0000 please reactovate my account.=0D =0D tell me what i did & i will change or delete=0D =0D it. i do not want to loose my e mail account.=0D =0D i have paid for yahoo plus also if that helps=0D =0D please reactovate my yahoo id is sissybuttmy=0D =0D hoping=0D =0D sissy From owner-freebsd-isp@FreeBSD.ORG Wed Sep 28 08:18:44 2005 Return-Path: X-Original-To: freebsd-isp@freebsd.org Delivered-To: freebsd-isp@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 241A816A41F for ; Wed, 28 Sep 2005 08:18:44 +0000 (GMT) (envelope-from dliebke-isp@yahoo.de) Received: from web54507.mail.yahoo.com (web54507.mail.yahoo.com [206.190.49.157]) by mx1.FreeBSD.org (Postfix) with SMTP id 9A63043D48 for ; Wed, 28 Sep 2005 08:18:43 +0000 (GMT) (envelope-from dliebke-isp@yahoo.de) Received: (qmail 90956 invoked by uid 60001); 28 Sep 2005 08:18:42 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.de; h=Message-ID:Received:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=mlxuWjU7u2spEoufVIAK6aMJHj24YFUfx1Gq9gNpfu0ePKnMmGwV0dWUBhfV690c6TNrDAcfWtYIPJTjwfAqBsHNpjQTnfhbtptSCP00gbTJpWz0nP/SGE92M+e0zLB7Vh6610lOBR7d1gykHswceivAFtkHhlq8WFzaCpOq9aE= ; Message-ID: <20050928081842.90954.qmail@web54507.mail.yahoo.com> Received: from [84.190.218.40] by web54507.mail.yahoo.com via HTTP; Wed, 28 Sep 2005 10:18:42 CEST Date: Wed, 28 Sep 2005 10:18:42 +0200 (CEST) From: To: freebsd-isp@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Subject: Re: wifi public access X-BeenThere: freebsd-isp@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dliebke-isp@yahoo.de List-Id: Internet Services Providers List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Sep 2005 08:18:44 -0000 Please take a lokk at www.chillispot.org This might be your best OSS solution. Cheers, Dirk ___________________________________________________________ Was denken Sie über E-Mail? Wir hören auf Ihre Meinung: http://surveylink.yahoo.com/wix/p0379378.aspx From owner-freebsd-isp@FreeBSD.ORG Wed Sep 28 08:30:34 2005 Return-Path: X-Original-To: freebsd-isp@freebsd.org Delivered-To: freebsd-isp@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1688716A41F for ; Wed, 28 Sep 2005 08:30:34 +0000 (GMT) (envelope-from lists@yazzy.org) Received: from mail.yazzy.org (mail.yazzy.org [217.8.140.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id B103443D48 for ; Wed, 28 Sep 2005 08:30:33 +0000 (GMT) (envelope-from lists@yazzy.org) Received: from 217-13-2-82.dd.nextgentel.com ([217.13.2.82] helo=marcin) by mail.yazzy.org with esmtps (TLSv1:AES256-SHA:256) (YazzY.org) id 1EKXKF-0004m8-8r; Wed, 28 Sep 2005 10:30:04 +0200 Date: Wed, 28 Sep 2005 10:30:29 +0200 From: Marcin Jessa To: dliebke-isp@yahoo.de Message-Id: <20050928103029.2d85d79d.lists@yazzy.org> In-Reply-To: <20050928081842.90954.qmail@web54507.mail.yahoo.com> References: <20050928081842.90954.qmail@web54507.mail.yahoo.com> Organization: YazzY.org X-Mailer: Sylpheed version 2.0.0 (GTK+ 2.6.8; i386-portbld-freebsd7.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Score: -2.5 (--) Cc: freebsd-isp@freebsd.org Subject: Re: wifi public access X-BeenThere: freebsd-isp@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Internet Services Providers List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Sep 2005 08:30:34 -0000 On Wed, 28 Sep 2005 10:18:42 +0200 (CEST) wrote: > Please take a lokk at www.chillispot.org > > This might be your best OSS solution. Or www.pfsense.com which has more stuff than just a captive portal. From owner-freebsd-isp@FreeBSD.ORG Wed Sep 28 14:19:12 2005 Return-Path: X-Original-To: freebsd-isp@freebsd.org Delivered-To: freebsd-isp@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DC3A716A420 for ; Wed, 28 Sep 2005 14:19:12 +0000 (GMT) (envelope-from b.candler@pobox.com) Received: from leto.uk.clara.net (leto.uk.clara.net [80.168.69.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7FB2843D73 for ; Wed, 28 Sep 2005 14:19:09 +0000 (GMT) (envelope-from b.candler@pobox.com) Received: from bloodhound.noc.clara.net ([195.8.70.207]) by leto.uk.clara.net with esmtp (Exim 4.43) id 1EKcm2-000Bgg-VE; Wed, 28 Sep 2005 15:19:06 +0100 Received: from personal by bloodhound.noc.clara.net with local (Exim 4.52 (FreeBSD)) id 1EKcmM-000FTu-Fs; Wed, 28 Sep 2005 15:19:26 +0100 Date: Wed, 28 Sep 2005 15:19:26 +0100 From: Brian Candler To: Marcin Jessa Message-ID: <20050928141926.GA59447@uk.tiscali.com> References: <20050928081842.90954.qmail@web54507.mail.yahoo.com> <20050928103029.2d85d79d.lists@yazzy.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050928103029.2d85d79d.lists@yazzy.org> User-Agent: Mutt/1.4.2.1i Cc: freebsd-isp@freebsd.org, dliebke-isp@yahoo.de Subject: Re: wifi public access X-BeenThere: freebsd-isp@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Internet Services Providers List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Sep 2005 14:19:13 -0000 On Wed, Sep 28, 2005 at 10:30:29AM +0200, Marcin Jessa wrote: > > Please take a lokk at www.chillispot.org > > > > This might be your best OSS solution. > > Or www.pfsense.com which has more stuff than just a captive portal. Or nocatauth: http://nocat.net/ although it seems to be Linux only. The INSTALL document says "Support for other OSes is planned, especially FreeBSD". So perhaps you could fix it for them :-) From owner-freebsd-isp@FreeBSD.ORG Fri Sep 30 03:51:17 2005 Return-Path: X-Original-To: freebsd-isp@freebsd.org Delivered-To: freebsd-isp@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B001116A41F for ; Fri, 30 Sep 2005 03:51:17 +0000 (GMT) (envelope-from lists@netxp.com.au) Received: from mail.netxp.com.au (adsl-127-117.swiftdsl.com.au [218.214.127.117]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3A97043D49 for ; Fri, 30 Sep 2005 03:51:16 +0000 (GMT) (envelope-from lists@netxp.com.au) Received: from localhost (localhost [127.0.0.1]) by mail.netxp.com.au (Postfix) with ESMTP id A467E117829 for ; Fri, 30 Sep 2005 13:47:38 +1000 (EST) Received: from mail.netxp.com.au ([127.0.0.1]) by localhost (phil.netxp.com.au [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 81002-01 for ; Fri, 30 Sep 2005 13:47:35 +1000 (EST) Received: from [192.168.101.3] (unknown [192.168.101.3]) by mail.netxp.com.au (Postfix) with ESMTP id C0E2011781F for ; Fri, 30 Sep 2005 13:47:35 +1000 (EST) Message-ID: <433CB63B.3040001@netxp.com.au> Date: Fri, 30 Sep 2005 13:51:23 +1000 From: phil grainger User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-isp@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at netxp.com.au Subject: hosting solutions X-BeenThere: freebsd-isp@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Internet Services Providers List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Sep 2005 03:51:17 -0000 Hi, has any one had any experience with raqdevil? http://www.raqdevil.com/ how complicated is it to migrate an exising server to use it? From owner-freebsd-isp@FreeBSD.ORG Fri Sep 30 09:58:51 2005 Return-Path: X-Original-To: freebsd-isp@freebsd.org Delivered-To: freebsd-isp@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0975A16A41F for ; Fri, 30 Sep 2005 09:58:51 +0000 (GMT) (envelope-from kilop@toya.net.pl) Received: from lazir.toya.net.pl (lazir.toya.net.pl [217.113.224.3]) by mx1.FreeBSD.org (Postfix) with ESMTP id 900F243D4C for ; Fri, 30 Sep 2005 09:58:50 +0000 (GMT) (envelope-from kilop@toya.net.pl) Received: from localhost (unknown [192.168.120.26]) by lazir.toya.net.pl (TOYAnet MailServer) with ESMTP id 626778BBAA for ; Fri, 30 Sep 2005 11:58:47 +0200 (CEST) Received: from lazir.toya.net.pl ([192.168.120.25]) by localhost (agregat [192.168.120.26]) (amavisd-new, port 10024) with ESMTP id 19437-05 for ; Fri, 30 Sep 2005 11:58:45 +0200 (CEST) Received: from GKHAR (unknown [217.113.230.114]) by lazir.toya.net.pl (TOYAnet MailServer) with ESMTP id 6F7F48BBA5 for ; Fri, 30 Sep 2005 11:58:44 +0200 (CEST) Date: Fri, 30 Sep 2005 11:58:49 +0200 From: kilop X-Mailer: The Bat! (v3.0.1.33) Professional X-Priority: 3 (Normal) Message-ID: <791820560.20050930115849@toya.net.pl> To: freebsd-isp@freebsd.org In-Reply-To: References: 235b8000050926091310903997@mail.gmail.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-TOYA-AV: AntyVir-Skaner at toya.net.pl Subject: vqadmin X-BeenThere: freebsd-isp@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: kilop List-Id: Internet Services Providers List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Sep 2005 09:58:51 -0000 Witaj freebsd-isp! hi i found your mail on forum about vqadmin error like this: but when *http://www.mydomain.com/cgi-bin/vqadmin/vqadmin.cgi* *Authentication Failed Username unknown* *vQadmin was unable to determine your username, which means your webserver is improperly configured to run with this CGI. For security reasons, this script will not run without Apache htaccess lists. vqadmin 2.3.6 vpopmail 5.4.10* i have the same error .htaccess file is owned by Apache and directory directive is added to httpd.conf and i have the same error please can you help me with that ?? i have qmail vpopmail installed after reading this faq http://bsdguides.org/guides/freebsd/mailserver/qmail+vpopmail+qmailadmin.php please can you help me with that ?? -- Pozdrowienia, kilop From owner-freebsd-isp@FreeBSD.ORG Fri Sep 30 13:03:16 2005 Return-Path: X-Original-To: freebsd-isp@freebsd.org Delivered-To: freebsd-isp@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B77C016A41F for ; Fri, 30 Sep 2005 13:03:16 +0000 (GMT) (envelope-from msalaque@gmail.com) Received: from xproxy.gmail.com (xproxy.gmail.com [66.249.82.200]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6100B43D48 for ; Fri, 30 Sep 2005 13:03:16 +0000 (GMT) (envelope-from msalaque@gmail.com) Received: by xproxy.gmail.com with SMTP id t13so1703321wxc for ; Fri, 30 Sep 2005 06:03:15 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=ixmT1HbMWB0XYPfKJnxS7LRaHH4S0YwBFMlai8wJagynFhsO8G/t+ByJOpxUku8xy+bEoznVeCXF3jXqgtNRVNGXAx/259oB+tWrVq51ocbQBI0DHZ6tClHOGleEKqMHpKUmg8uGqjtf7MLXRam5sEVuoQ+40e2Zr/oag/2Wks0= Received: by 10.70.118.6 with SMTP id q6mr875492wxc; Fri, 30 Sep 2005 06:03:15 -0700 (PDT) Received: by 10.70.62.18 with HTTP; Fri, 30 Sep 2005 06:03:15 -0700 (PDT) Message-ID: <27c2f3420509300603l19a45889j6cdca31b2da36bb0@mail.gmail.com> Date: Fri, 30 Sep 2005 06:03:15 -0700 From: Mohammad Salaque To: freebsd-isp@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Subject: PPPOE server with Radius X-BeenThere: freebsd-isp@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: info@salaque.com List-Id: Internet Services Providers List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Sep 2005 13:03:16 -0000 Dear All Could anyone pls give me some good resource to setup PPPOE server with Radius support Salaque From owner-freebsd-isp@FreeBSD.ORG Fri Sep 30 13:39:00 2005 Return-Path: X-Original-To: freebsd-isp@freebsd.org Delivered-To: freebsd-isp@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 11F5C16A41F for ; Fri, 30 Sep 2005 13:39:00 +0000 (GMT) (envelope-from lists@yazzy.org) Received: from mail.yazzy.org (mail.yazzy.org [217.8.140.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7019F43D48 for ; Fri, 30 Sep 2005 13:38:59 +0000 (GMT) (envelope-from lists@yazzy.org) Received: from 217-13-2-82.dd.nextgentel.com ([217.13.2.82] helo=marcin) by mail.yazzy.org with esmtps (TLSv1:AES256-SHA:256) (YazzY.org) id 1ELL5n-0002pq-JU; Fri, 30 Sep 2005 15:38:30 +0200 Date: Fri, 30 Sep 2005 15:38:48 +0200 From: Marcin Jessa To: info@salaque.com Message-Id: <20050930153848.74cb22b3.lists@yazzy.org> In-Reply-To: <27c2f3420509300603l19a45889j6cdca31b2da36bb0@mail.gmail.com> References: <27c2f3420509300603l19a45889j6cdca31b2da36bb0@mail.gmail.com> Organization: YazzY.org X-Mailer: Sylpheed version 2.0.0 (GTK+ 2.6.8; i386-portbld-freebsd7.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Score: -2.5 (--) Cc: freebsd-isp@freebsd.org, msalaque@gmail.com Subject: Re: PPPOE server with Radius X-BeenThere: freebsd-isp@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Internet Services Providers List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Sep 2005 13:39:00 -0000 On Fri, 30 Sep 2005 06:03:15 -0700 Mohammad Salaque wrote: > Dear All > Could anyone pls give me some good resource to setup PPPOE server with > Radius support http://www.hpi.net/whitepapers/warta/ From owner-freebsd-isp@FreeBSD.ORG Fri Sep 30 17:48:00 2005 Return-Path: X-Original-To: freebsd-isp@freebsd.org Delivered-To: freebsd-isp@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4522416A420 for ; Fri, 30 Sep 2005 17:48:00 +0000 (GMT) (envelope-from cmuser@shaggy.smf.ebay.com) Received: from smf-camp17.smf.ebay.com (smfcamppool17.emailebay.com [66.135.215.246]) by mx1.FreeBSD.org (Postfix) with ESMTP id A85EE43D4C for ; Fri, 30 Sep 2005 17:47:54 +0000 (GMT) (envelope-from cmuser@shaggy.smf.ebay.com) Received: from shaggy.smf.ebay.com (fallback-camp.vip.smf.ebay.com [10.108.160.50]) by smf-camp17.smf.ebay.com (8.12.3/8.12.3) with ESMTP id j8UHlswZ029591 for ; Fri, 30 Sep 2005 10:47:54 -0700 Received: (from cmuser@localhost) by shaggy.smf.ebay.com (8.11.6+Sun/8.11.6) id j8UHlsY28775; Fri, 30 Sep 2005 10:47:54 -0700 (PDT) Date: Fri, 30 Sep 2005 10:47:54 -0700 (PDT) From: Unexpected reply handler Message-Id: <200509301747.j8UHlsY28775@shaggy.smf.ebay.com> To: freebsd-isp@freebsd.org References: <200509301747.j8UHljDZ009643@mailhost5.sjc.ebay.com> In-Reply-To: <200509301747.j8UHljDZ009643@mailhost5.sjc.ebay.com> Precedence: junk X-Loop: reply@reply.ebay.com Subject: Re: Important X-BeenThere: freebsd-isp@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Internet Services Providers List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Sep 2005 17:48:00 -0000 Thank you for your response. Please don't reply to this message - it is an automated response and your reply will not be received. If you have a question for eBay Customer Support, please visit the following eBay Help page. This page will help you locate the answer to your question, or assist you in contacting us: http://pages.ebay.com/help/index.html If you would like to change your notification preferences, which determine what type of email you receive from eBay, please follow the steps below: 1. Click "My eBay" located at the top of all eBay pages. You may be asked to sign in. 2. Click the "eBay Preferences" link located under the "My Account" heading. 3. Click the "view/change" link to the right of "Notification Preferences." You may be asked to sign in once more. 4. On the "Change Your Notification Preferences" page, check the boxes to indicate the types of messages you'd like to receive from eBay. Then, uncheck the boxes to indicate the types of messages you don't want to receive from us. 5. Once you're done, be sure to click the "Save Changes" button at the top or bottom of the page. Again, thanks for writing eBay. -- From owner-freebsd-isp@FreeBSD.ORG Fri Sep 30 18:15:50 2005 Return-Path: X-Original-To: freebsd-isp@freebsd.org Delivered-To: freebsd-isp@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B030716A424 for ; Fri, 30 Sep 2005 18:15:50 +0000 (GMT) (envelope-from joshua@revealed.net) Received: from edd.revealed.net (edd.revealed.net [205.243.76.9]) by mx1.FreeBSD.org (Postfix) with SMTP id 0D72C43D49 for ; Fri, 30 Sep 2005 18:15:49 +0000 (GMT) (envelope-from joshua@revealed.net) Received: (qmail 7051 invoked by uid 1008); 30 Sep 2005 18:15:46 -0000 Received: from unknown (HELO lucy) (205.243.76.211) by 0 with SMTP; 30 Sep 2005 18:15:46 -0000 From: "Joshua M. Andrews" To: "'phil grainger'" , Date: Fri, 30 Sep 2005 13:16:01 -0500 Organization: Internet Revealed, LLC. Message-ID: <001101c5c5eb$036bccb0$d34cf3cd@lucy> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 1 (Highest) X-MSMail-Priority: High X-Mailer: Microsoft Office Outlook 11 thread-index: AcXFckJZoLzV1lzcSIybV1gNNCkmlQAeKjWg Importance: High X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 In-Reply-To: <433CB63B.3040001@netxp.com.au> Cc: Subject: RE: hosting solutions X-BeenThere: freebsd-isp@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: joshua@revealed.net List-Id: Internet Services Providers List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Sep 2005 18:15:50 -0000 It's pretty neat. It could be a bit prettier but it works. However, a new version is due out this weekend so if you're going to try it.. wait until this weekend. :) Sincerely, Joshua -----Original Message----- From: owner-freebsd-isp@freebsd.org [mailto:owner-freebsd-isp@freebsd.org] On Behalf Of phil grainger Sent: Thursday, September 29, 2005 10:51 PM To: freebsd-isp@freebsd.org Subject: hosting solutions Hi, has any one had any experience with raqdevil? http://www.raqdevil.com/ how complicated is it to migrate an exising server to use it? _______________________________________________ freebsd-isp@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-isp To unsubscribe, send any mail to "freebsd-isp-unsubscribe@freebsd.org"