Re: fault tolerant web servers on freebsd
Hi, > Let's say i need to run a few php/sql based web sites and I would like > to maintain uptime of about 99,99% per month. > From what You say I need some level of HA system, to maintain the > required uptime. Okay > (i'm skiping (..) network issues at the moment). Then you won't succeed. Four nines availabillity without regarding network outages... sjeesh. > Few people have told me about a setup with linux, drbd and heartbeat > which offers them some level of HA. Has anyone tried anything similar on > FreeBSD? Did you actually *look* around for possible solutions ? I mean, I searched with google and found geom + ggated solutions... Go figure. Depending on your budget, I would build two 'systems', spread over two coloc's. Use two squid/memcached caches, two backend servers with http-daemons and php on it, two sql servers that replicate in realtime, all (maybe exclude the sql servers from that.. depending on writes figures) connected to a NAS. Having caches at the frontend, make sure you fully understand http://www.mnot.net/cache_docs/ (for example, may more resources are available). Then, have that NAS replicate to the other coloc site (don't forget the encryption heh). Pay attention to the switched LAN behind it. Maybe redundant switches would be a very clever investment. At last, have 2 dns A/ pointers to both sites with a reasonable but short TTL that you can change right away. These autoritive dns servers must be as redundant as well. Now we're talking about resiliency. And money, so skip out all what proves to be too expensive. I'm sure you already estimated how many dollars unavailabillity costs you, so invest wisely. If this is a commercial hosting exercise, buy stuff for the upcoming 36 months. After that, redesign may be wise. You wanna learn how other folks are doing this ? Have a look at wikipedia ! And also try to learn from their power outage few weeks ago :-/ You may poke around at http://wikitech.wikimedia.org/view/Main_Page and get some idea's. Goodluck. Robert ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Perennial suggestion to split freebsd-stable into version-specific lists
Hi, > Thus, my suggestion. Split what is currently freebsd-stable into one > list per branch. We could also THINK about whether we want more than 1 stable branch, which is the true case now. Either we relese too often or older releases have a far to long lifecycle before reching EOL. Recalling from memory I more than once read posting by core freebsd dev's stating they dislike keeping track of so many releases. That started with 5. What we really need to THINK about is getting more milestones into a release. Now 5 marked $SMP. 6 was a $better 5. 7 marked $this. 8 should cut the corners on $that. Why not having more milestones into our current release before the next one becomes stable. Then this problem will solve in near future. What's wrong with having releng_8_14 ? I recall 2.2.11 :-) I'm not opposed more -stable mailinglists perse, but this to me seems we are just fighting symptons. Cheers, Robert ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Version nomenclature [was RELENG_7 to 8]
Hi, > STABLE and CURRENT could only point to two things and there were about > 10 potential tags involved. Tags... You say tags. Now, freebsd is an constantly evolving project. It's never finished. And when a branch is, it's EOL. It took me two minutes, back in 97 to get the grasp and at that time the security branch had yet to be introduced, before that I tracked 'stable'. Go figure. You know, that's the beauty of this project: it's 'nix, but different. I agree with you we should find a solution about all this name-bitching: let's encourage them to actualy READ the F. manual. Let's include it in the FAQ ! Or include some pointer in UPDATING for those that like to mess with source code. Or would you like to rename STABLE into UNSTABLE ? Or FIXED ? Or into the $next_upcoming_release_number-ALPHA ? Now that sounds appealing to newcomers not. I occaisionally run a STABLE box in production without any trouble, so it's name is what you get: great software, it's stable enough. We also inject new software releases into our ports collection. I never read anything about it's name scheme. Funny, but very relieving IMO. Cheers. Robert ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: traffic using ISP proxy
Hi, > How should I configure my FreeBSD box to achieve this, what tools I should > use? You can only proxy traffic that the proxyserver itself understands. I suppose that proxyserver from your ISP is an http proxy, so you have to adjust your browser. You cannot proxy smtp or pop3, sip or whatever through, let's say, squid. It doesn't understand any protocol other than http (and ftp). Natting all outbound traffic to that proxyserver will not work as you expect. There is ofcourse other proxyserver software that do understand pop3, smtp, sip, etc etc but I don't think your ISP will offer that service. Otherwise, give them a call and find out. Hth. Regards, Robert ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: gmirror patches
> So far it runs okay. Well a week passed by: - no answer to my question, but - no issues to report either Fwiw. Cheers, Robert ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: gmirror patches
Hi, > Has anybody else had a chance to try the gmirror patches I posted here a > few weeks ago ? > http://www.freebsd.org/cgi/query-pr.cgi?pr=123630 I ran that patch against 7-stable, build flawless. I currently build a kernel, by accident I made a small mistake. I installworld'd but forgot to rebuild/install the kernel, a reboot in between... oh well. That box does collect syslog of abount 8 boxes, mysql in replication modus for backup purposes to a NFS share and is internal fallback mx server so it's somewhat I/O bound. It's a HP LH3 SMP box deployed with gmirror because it lacks scsi raid. So far it runs okay. Any hints I should look for or put into stress ? It's not very important to get this box up ;-) Cheers, Robert ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Error while pxeboot setup FreeBSD 7.0
Hi, Hmm for what's worth: I just upgraded a 6.2 pxe box using cvs to 7.0 release and it boots and runs fine, it seems. The server (still) runs 6.2 . Cheers, Robert ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: The Design and Implementation of the FreeBSD Operating System
Hi Unga, > Is there a 2nd edition coming soon? Third iirc. ISBN 0201549794 was the first, although with a slightly different name. Regards, Robert PS: may I politely remind you of our mailinglist charters phrase: "No posting should be made to more than 2 mailing lists (..) ? ;-) http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/eresources.html#ERESOURCES-MAIL ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: PXE booting issues
Hi,
> 2- the dhcp should tell pxeloader where the root is:
> option root-path "ip:/path"
And next-server
I have a couple of version 6.2 pxe-clients booting of a 4.11 box without a
problem.
A snippet of my dhcpd.conf:
host gister {
hardware ethernet 00:0e:0c:b4:3a:14;
fixed-address 192.168.4.104;
option root-path "192.168.4.105:/var/nixfs/pxe/gister";
next-server 192.168.4.105;
filename "pxeboot";
}
and the kernel config:
#grep -i bootp /usr/src/sys/i386/conf/GISTER
options BOOTP
options BOOTP_NFSROOT
options BOOTP_NFSV3
options BOOTP_COMPAT
options BOOTP_WIRED_TO=fxp0
Hth.
Kind regards,
Robert
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: cvsup error
Hi, > > Have you tried csup(1) ? > what is the different?? csup is a rewrite of cvsup in C instead of relying on Modula 3, that seems to cause some troubles on your system. Hth. Kind regards, Robert PS: a happy csup user pgpZ9DybmS5Wu.pgp Description: PGP signature
Re: FreeBSD 6.1-RELEASE source update fails during compilation
Hi,
---cut!--
> /usr/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc/genattrtab.c:6240:
> internal compiler error: Segmentation fault: 11
> Please submit a full bug report,
> with preprocessed source if appropriate.
> See http://gcc.gnu.org/bugs.html> for instructions.
> {standard input}: Assembler messages:
> {standard input}:14060: Warning: partial line at end of file ignored
> *** Error code 1
> Stop in /usr/src/gnu/usr.bin/cc/cc_tools.
> *** Error code 1
> Stop in /usr/src.
> *** Error code 1
> Stop in /usr/src.
> *** Error code 1
> Stop in /usr/src.
Yeah, I observed this too a few times. All the times on a poor little
pentium 1/150 with 48meg ram (according dmesg). It's somewhat difficult
too check but I suspect I run out of memory every time.
I happened to run make installworld with a DESTDIR pointing to this box
using nfs using a more recent athlon 3000 :-)
That slow box runs postfix and procmail to a nfs-mounted spool. It runs
great without any sign indicating bad memory; did not run a memcheck
though. Increasing swap didn't solve this matter.
Hth.
Cheers,
Robert
PS: recommend to check out releng_6_2 if able; just to be sure.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: imap-uw on FreeBSD 6.2
Hi, > I recommend that you have a look at dovecot. Yeah, and consider maildir instead of mbox. Have a great weekend. Robert ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Possibility for FreeBSD 4.11 Extended Support
Hi, > In that case you can savely mount with the -L option > (a.k.a. "-o nolockd"), an everything will just work. > No need for rpc.lockd at all. Hmm, yes. Fiddling in etc/fstab and /etc/rc.d/initdiskless didn't help. Where am I expected to fiddle to enable this ? Browsig through archives I learned this was told me once before; I already thought -L sounded sooo familiar... Thanks for pointing me once again :-) Kind regards, Robert Joosten ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Possibility for FreeBSD 4.11 Extended Support
Hi, > >From my understanding, rpc.lockd needs substantial work from a fairly > experienced developer, to the point where IIRC we are not in a position > to hold up any releases because of it. Someone will surely correct me > if I am wrong. Afaik all is correct. Someone pointed out to disable rpc.lockd completely but that doesn't help either. Unless the pxe-clients have to do something on their end I'm not aware of. Another stated rpc.lockd is broken for years now and we should implement a dummy one accepting and positively ack all locks while doing nothing actually. That should work as long as you know what you're doing :-D My pxe clients all have separate directories so concurrent locks on one specific file shouldn't occur. The clients do run without rpc.lockd till the moment sendmail starts or you try to run vipw. I didn't observe other quirks but I didn't monitor lockd-less boxen extensively. Thanks for your reply. Kind regards, Robert Joosten ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Possibility for FreeBSD 4.11 Extended Support
Hi Mark, > to find out what ports they are relying on. None are critical, although I usally get bash and cvsup from ports but that's not that important > A note about whether you consider security updates to be a critical > issue would be interesting. At least I want to hear about hem.. Fixes are highly appreciated ofcourse. > Note: I am only interested in the data for machines used as servers. These are nfs servers serving pxe clients.. rpc.lockd trouble is the main reason for not using 6 currently, asr0 performance is secondary not using 5. I admit: I haven't checked the commit-logs for any asr updates on 5 for months now... I know rpc.lockd is PR filed and even offered to help. It stalled; I rest assure re@ is aware of these difficulties and I dind't see any rpc.lockd commit that would be related. Curious for the outcome of your poll. Kind regards, Robert Joosten PS: seasonal wishes for anyone on board :-) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [fbsd] HEADS UP: FreeBSD 5.3, 5.4, 6.0 EoLs coming soon
Hi, ML> We are currently trying to support 4 major CVS branches. EBD> Perhaps work on 7 should have been delayed until 5 and 6 were able to EBD> woo people away from 4 -- or at least not leave valid reasons for RBD> people Eeehm, afaik 5 is an interim for 6, so 5 should be stopped. I know plenty people (including myself having a 4-box serving nfs; well because asr0 is slow on 5 and 6 is not a option due to rpc.lockd) who have already, plan to or are in the process of upgrading from 4 to 6. Work on 7 should not stop. I think we all have lessons learned from 5. On the other hand: freebsd is work in progress... C'mon guys :-D I think indeed we should make 6 a better 4, just as folks from re@ continue to state. Just my opinion though. Regards, Robert ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: bizarre ep (3c509-Combo) behavior: one and a half init, minimalthroughput
Hi, > ep0: <3Com 3C509-Combo EtherLink III> at port 0x300-0x30f irq 5 on isa0 > ep0: Ethernet address 00:a0:24:ca:7c:b0 > then once more as > ep1: <3Com 3C509-Combo EtherLink III> at port 0x300-0x30f irq 5 on isa0 > ep1: No I/O space?! > ep1: ep_alloc() failed! (6) > There is only one network card in the machine, I promise! I know these ep's, they're supported but only work so-so. I found out you must keep the order your kernel-config lists them intact (that's ed0, then ex, and then ep, followed by fe0) and also man keep that fe0 following the ep device. I experimented with this (read: wasted a lot of time) to figure out what and how. I'm running a old '486 running 4.7R with two ep's: Jan 29 13:01:42 t2ja /kernel: ep0: <3Com 3C509-TPO EtherLink III> at port 0x300-0x30f irq 10 on isa0 Jan 29 13:01:42 t2ja /kernel: ep0: Ethernet address 00:20:af:b8:96:8c Jan 29 13:01:42 t2ja /kernel: ep1: <3Com 3C509-TPO EtherLink III> at port 0x310-0x31f irq 11 on isa0 Jan 29 13:01:42 t2ja /kernel: ep1: Ethernet address 00:60:08:c6:a2:77 with only some minor issues: blasting a lot of traffiq through it causes some mbuff trouble which degardes performace to nearly zero, I always shut the interface down, wait a few seconds and the throw it up again. As long as the interface's not threated, performance keeps suffering lasting for hours and maybe days...! A precursor is the appearance of OACTIVE in the ifconfig output regarding that interface. One sysadmin I know told me 3com released various series of these cards. The most recent models suppose to run flawlessly under *nix. The earliest models should be avoided. Windows doesn't care at all. And yes: I know from 1st hand experience Linux supports these cards very well (They did a wonderfull job on my 386xs/25 running Slackware 3.9 (kernel 2.0.37). Rj To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
