From jhs at berklix.org Mon May 4 22:22:18 2009 From: jhs at berklix.org (Julian Stacey) Date: Mon May 4 22:22:25 2009 Subject: Spamassassin anyone??? In-Reply-To: Your message "Tue, 28 Apr 2009 12:16:14 -0800." <20090428121050.F91785@alpha.tibor.org> Message-ID: <200905042221.n44MLmpI067156@fire.js.berklix.net> Hi, Reference: > From: Mike Tibor > Date: Tue, 28 Apr 2009 12:16:14 -0800 (AKDT) > Message-id: <20090428121050.F91785@alpha.tibor.org> Mike Tibor wrote: > On Tue, 28 Apr 2009, Julian Stacey wrote: > > > My 2c: Bad idea: Moderators. > > Romans knew long before us: "Quis custodes custodiensis?" > > But others with 2c like moderators, sadly. > > > > Moderation is a tedious bike shed argument, comes up on loads of > > FreeBSD lists periodically, for one compromise idea (just moderate > > the unsusbscribed), see suggestion found by google from: Rich > > Kulawiec to hardware list recently: > > http://groups.google.com/group/muc.lists.freebsd.hardware/browse_thread/thread/c698d9cd3ca2bd9e/f74bcf1e3e95bdd9?lnk=raot > > > > However probably all would agree: > > Volunteer to help postmaster@freebsd.org team on automatic tools > > if you have skill & time. > > I can certainly see why moderation wouldn't be practical, but I've always > been curious why the -isp list has had an open posting policy. You would > think that those using FreeBSD in an ISP environment wouldn't be put off > by having to subscribe to the list in order to post a question, but maybe > that's a bad assumption. > > Obviously you wouldn't want that for many of the other lists, but for more > specialized lists like this one, I'm genuinely curious why they're open. > > Mike Personaly, I wouldnt mind if all FreeBSD lists only accepted postings from subscribers ( that's what I do for lists I run on majordomo @ berklix.org ) However: 1) As the postmaster@ team @freebsd.org have achieved pretty good spam rejection most of the time, presumambly they don't feel the need. 2) It wouldn't block all spam, Lists gets archived on various web sites, (not just @freebsd.org) & I recall some webs dont mask senders address. ( & if any people receive lists on MicroS..t, & they get virus scanned, same info there), So spam crawlers could harvest sender addresses & masquerade. (Smaller target audiences, but if enough in aggregate, & using semi recognised senders names ... Fortunately not too much targeted spam ... yet ) Cheers, Julian -- Julian Stacey: BSDUnixLinux C Prog Admin SysEng Consult Munich www.berklix.com Mail plain ASCII text. HTML & Base64 text are spam. www.asciiribbon.org From jakelleydds at sbcglobal.net Fri May 8 10:44:16 2009 From: jakelleydds at sbcglobal.net (Jeff Kelley, DDS) Date: Fri May 8 10:44:23 2009 Subject: Periodontal Disease: Silent and Deadly Message-ID: Greetings from Jeff Kelley, DDS! Periodontal Disease: Silent and Deadly Periodontal disease can go on for years without pain and without detection unless specific examination procedures are performed. Visual oral examination by itself (even by a dentist) will not reliably detect periodontal disease until it has reached an advanced stage. Early detection and adequate diagnosis require measurement of pockets (the crevice between the tooth and gum) with a periodontal probe. Effective prevention and treatment is available, but the damage caused as the disease progresses is irreversible. Early detection and treatment is critical to prevent tooth loss and disfigurement. Although the procedure is simple, painless and requires only a few minutes, millions of American adults have never had it done. Signs of periodontal disease include bleeding gums, redness of gum tissue, swelling of gums around the teeth, breath odor, receding gums, mobility of teeth. If you have questions regarding periodontal disease, please call our office at (817)877-1651 or email us at jakelleydds@sbcglobal.net today. Best Regards, Jeff Kelley, DDS P.S. If you have any friends or family members who you feel could use our services, please don't hesitate to have them call us. We'll be sure to take good care of them. From drleute at familydentistportwashington.com Fri May 8 11:30:14 2009 From: drleute at familydentistportwashington.com (Dr. Josh Leute) Date: Fri May 8 11:30:21 2009 Subject: Periodontal Disease: Silent and Deadly Message-ID: <6a4c4a050d5d454d825e58859bc5f264@1stnewsletters.com> Greetings from Dr. Josh Leute! Periodontal Disease: Silent and Deadly Periodontal disease can go on for years without pain and without detection unless specific examination procedures are performed. Visual oral examination by itself (even by a dentist) will not reliably detect periodontal disease until it has reached an advanced stage. Early detection and adequate diagnosis require measurement of pockets (the crevice between the tooth and gum) with a periodontal probe. Effective prevention and treatment is available, but the damage caused as the disease progresses is irreversible. Early detection and treatment is critical to prevent tooth loss and disfigurement. Although the procedure is simple, painless and requires only a few minutes, millions of American adults have never had it done. Signs of periodontal disease include bleeding gums, redness of gum tissue, swelling of gums around the teeth, breath odor, receding gums, mobility of teeth. If you have questions regarding periodontal disease, please call our office at (262)284-5884 or email us at drleute@familydentistportwashington.com today. Best Regards, Dr. Josh Leute P.S. If you have any friends or family members who you feel could use our services, please don't hesitate to have them call us. We'll be sure to take good care of them. From drz at dentistsherwood.com Fri May 8 12:26:33 2009 From: drz at dentistsherwood.com (Dr. Julian H. Zhitnitsky) Date: Fri May 8 12:26:39 2009 Subject: Periodontal Disease: Silent and Deadly Message-ID: <67c7703ae0a745088f8d5312dfe7d527@1stnewsletters.com> Greetings from Dr. Julian H. Zhitnitsky! Periodontal Disease: Silent and Deadly Periodontal disease can go on for years without pain and without detection unless specific examination procedures are performed. Visual oral examination by itself (even by a dentist) will not reliably detect periodontal disease until it has reached an advanced stage. Early detection and adequate diagnosis require measurement of pockets (the crevice between the tooth and gum) with a periodontal probe. Effective prevention and treatment is available, but the damage caused as the disease progresses is irreversible. Early detection and treatment is critical to prevent tooth loss and disfigurement. Although the procedure is simple, painless and requires only a few minutes, millions of American adults have never had it done. Signs of periodontal disease include bleeding gums, redness of gum tissue, swelling of gums around the teeth, breath odor, receding gums, mobility of teeth. If you have questions regarding periodontal disease, please call our office at (818)785-8388 or email us at drz@dentistsherwood.com today. Best Regards, Dr. Julian H. Zhitnitsky P.S. If you have any friends or family members who you feel could use our services, please don't hesitate to have them call us. We'll be sure to take good care of them. From venture37 at gmail.com Mon May 11 03:13:58 2009 From: venture37 at gmail.com (Sevan / Venture37) Date: Mon May 11 03:14:05 2009 Subject: OpenNMS 1.6.2 port In-Reply-To: <49815205.3020507@gmail.com> References: <497E6AF6.8060802@gmail.com> <497E7714.4010201@gmail.com> <49815205.3020507@gmail.com> Message-ID: <4A07914D.8090706@gmail.com> Port updated to v1.6.4 http://www.geeklan.co.uk/?p=132 http://www.geeklan.co.uk/files/opennms/opennms-164-freebsd-port.tgz Sevan / Venture37 From tonix at interazioni.it Mon May 11 11:13:39 2009 From: tonix at interazioni.it (Tonix (Antonio Nati)) Date: Mon May 11 11:13:55 2009 Subject: Questions on clustered FS + NFS Message-ID: <4A080851.3090101@interazioni.it> I'd love to put all my storage on a clustered NFS (with a ridondant iSCSI controller and storage), FreeBSD based of course, but I see there is not any clustered FS on FreeBSD. So, the solution seems to run a couple of GFS or OCFS2 on some Linux servers, more some NFS servers handled by heartbeat. Is there any FreeBSD solution I could adopt? Thanks, Tonino -- ------------------------------------------------------------ Inter@zioni Interazioni di Antonio Nati http://www.interazioni.it tonix@interazioni.it ------------------------------------------------------------ From tonix at interazioni.it Mon May 11 11:30:37 2009 From: tonix at interazioni.it (Tonix (Antonio Nati)) Date: Mon May 11 11:30:43 2009 Subject: Questions on clustered FS + NFS In-Reply-To: <4A080927.2080307@eenet.ee> References: <4A080851.3090101@interazioni.it> <4A080927.2080307@eenet.ee> Message-ID: <4A080C45.7010003@interazioni.it> Joel Jans ha scritto: > Tonix (Antonio Nati) wrote: >> I'd love to put all my storage on a clustered NFS (with a ridondant >> iSCSI controller and storage), FreeBSD based of course, but I see >> there is not any clustered FS on FreeBSD. >> >> So, the solution seems to run a couple of GFS or OCFS2 on some Linux >> servers, more some NFS servers handled by heartbeat. >> >> Is there any FreeBSD solution I could adopt? >> > > Glusterfs, http://www.gluster.org/docs/index.php/GlusterFS > http://www.freebsdwiki.net/index.php/GlusterFS > > Joel Jans > > GlusterFS looks to be a distribuited FS. What I need is to have two/three servers which are mounting in read/write exactly the same storage (an external iSCSI subsystem), exactly like wonderful old VMS did, or like GFS or OCFS2 seems to do now. Both servers must mount the same iSCSI partitions, so they work on the same data. Tonino -- ------------------------------------------------------------ Inter@zioni Interazioni di Antonio Nati http://www.interazioni.it tonix@interazioni.it ------------------------------------------------------------ From joel.jans at eenet.ee Mon May 11 11:33:00 2009 From: joel.jans at eenet.ee (Joel Jans) Date: Mon May 11 11:33:09 2009 Subject: Questions on clustered FS + NFS In-Reply-To: <4A080851.3090101@interazioni.it> References: <4A080851.3090101@interazioni.it> Message-ID: <4A080927.2080307@eenet.ee> Tonix (Antonio Nati) wrote: > I'd love to put all my storage on a clustered NFS (with a ridondant > iSCSI controller and storage), FreeBSD based of course, but I see > there is not any clustered FS on FreeBSD. > > So, the solution seems to run a couple of GFS or OCFS2 on some Linux > servers, more some NFS servers handled by heartbeat. > > Is there any FreeBSD solution I could adopt? > Glusterfs, http://www.gluster.org/docs/index.php/GlusterFS http://www.freebsdwiki.net/index.php/GlusterFS Joel Jans From john at day-light.com Mon May 11 21:46:15 2009 From: john at day-light.com (John Brooks) Date: Mon May 11 21:46:23 2009 Subject: Compaq Proliant 1600 In-Reply-To: <49F83388.80305@unsane.co.uk> Message-ID: I seem to have inherited a pair of Compaq Proliant 1600 servers and am considering loading freebsd onto them. Has anyone worked with Proliants before and specifically with installing freebsd on them? Is it worth the bother? -- John Brooks john@day-light.com From tibor at tibor.org Mon May 11 22:03:38 2009 From: tibor at tibor.org (Mike Tibor) Date: Mon May 11 22:03:47 2009 Subject: Compaq Proliant 1600 In-Reply-To: References: Message-ID: <20090511140055.G78105@alpha.tibor.org> I've loaded 4.x and 6.x on Compaqs in the past. I don't recall which models, specifically, but I don't recall running into anything out of the ordinary. All were SCSI rackmount boxes, and at least two had RAID controllers installed which FreeBSD recognized and used just fine. Mike On Mon, 11 May 2009, John Brooks wrote: > I seem to have inherited a pair of Compaq Proliant 1600 > servers and am considering loading freebsd onto them. > > Has anyone worked with Proliants before and specifically > with installing freebsd on them? Is it worth the bother? > > -- > John Brooks > john@day-light.com > > > _______________________________________________ > 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 josh at tcbug.org Mon May 11 22:05:59 2009 From: josh at tcbug.org (Josh Paetzel) Date: Mon May 11 22:06:09 2009 Subject: Compaq Proliant 1600 In-Reply-To: References: Message-ID: <038FB70A-BAD9-4F38-BBFC-3ABE0DCB2F4D@tcbug.org> On May 11, 2009, at 4:26 PM, John Brooks wrote: > I seem to have inherited a pair of Compaq Proliant 1600 > servers and am considering loading freebsd onto them. > > Has anyone worked with Proliants before and specifically > with installing freebsd on them? Is it worth the bother? > > -- > John Brooks > john@day-light.com > I'd say they aren't worth the power to turn on. And probably the only versions of FreeBSD that would work on them well aren't supported these days anyways. You are talking about hardware that is like single or dual P3 - 500mhz or thereabouts right? Thanks, Josh Paetzel From coco at executive-computing.de Tue May 12 00:18:45 2009 From: coco at executive-computing.de (Marco Steinbach) Date: Tue May 12 00:18:53 2009 Subject: Compaq Proliant 1600 In-Reply-To: References: Message-ID: <4A08BC22.8050900@executive-computing.de> John Brooks schrieb: > I seem to have inherited a pair of Compaq Proliant 1600 > servers and am considering loading freebsd onto them. > > Has anyone worked with Proliants before and specifically > with installing freebsd on them? Is it worth the bother? We're running some DL380 G1 Models for various internal, low profile purposes. They're equipped with dual PIII 1GHz CPUs and about 1GB of RAM. We're booting off of the Compaq Integrated RAID Controler, and use gmirrored off the shelve SATA drives in the free bays with FreeBSD 6.3. Allthough I have no knowledge about the models you mention, a good start might be to get Compaq Rompaq media in order to bring up the firmware to the latest level. The next step would be to fetch Compaq SmartStart media, and see, what options these offer for your machines. I had one DL380 G1 rebooting randomly on any FreeBSD 6.x I tried, but the other ones are just humming along nicely on 6.3 with some jails running mostly what might be called a standard FAMP. I'm running hpasm 7.22 [1] on all of them. MfG CoCo [1] http://people.freebsd.org/~jcagle/ From nuintari at amplex.net Tue May 12 01:12:40 2009 From: nuintari at amplex.net (Mark E Doner) Date: Tue May 12 01:12:47 2009 Subject: Compaq Proliant 1600 In-Reply-To: References: Message-ID: <4A09029B.70300@amplex.net> John Brooks wrote: > I seem to have inherited a pair of Compaq Proliant 1600 > servers and am considering loading freebsd onto them. > > Has anyone worked with Proliants before and specifically > with installing freebsd on them? Is it worth the bother? I have a 1600 with dual 1.5 ghz p3 procs, and a raid controller, that has run freebsd 6.1, 6.2, 7.0, 7.1, and now, 7.2. Never had a problem with the machine, everything on it simply works. Been a good box. From markus at infocom.co.ug Tue May 12 10:24:35 2009 From: markus at infocom.co.ug (Markus A. Wipfler) Date: Tue May 12 10:24:47 2009 Subject: Etinc & Freebsd retransmit problem Message-ID: <52E5887F-0B3A-4AD2-9736-467ABA60122C@infocom.co.ug> Hi all, we use the ETINC bandwidth manger running on freebsd 7.0. Our setup in a nutshell is: Clients--------FreebsdEtincBox------------ TranspartentSquidBoxes----------Internet. i am using etinc in bridge mode. I have a firewall rule on my external interface (fxp3) that should redirect http traffic to an external squid server: /usr/bwmgr/utils/bwmgr fxp3 -x 101 -name markustest -fw -o -dport 80 - saddr MYIPADDR -proxydev fxp3 -proxyaddr SQUIDMACADDR the http requets is correctly redirected to the proxy: squid log: TCP_MISS/200 6665 GET http://www.google.co.ug/ - DIRECT/ 74.125.39.105 text/html however the page fails to open and firefox displays below error: The connection was reset Running wireshark (on the machine that requested the webpage) to check for traffic on port 80 gives me the below output: 1 TCP Connection establish request (SYN): server port http 2 TCP Connection establish acknowledge (SYN+ACK): server port http 4 HTTP GET /HTTP/1.1\r\n 10 TCP Retransmission (suspected) 11 TCP Duplicate ACK (#1) 12 TCP Connection reset (RST) 13 TCP Connection reset (RST) 14 TCP Retransmission (suspected) ..... when i remove the etinc box between the squid box and the desktop everything works correctly: 1 TCP Connection establish request (SYN): server port http 2 TCP Connection establish acknowledge (SYN+ACK): server port http 4 HTTP GET http://www.google.co.ug/HTTP/1.1\r\n 18 HTTP HTTP/1.0 200 OK\r\n 18 TCP Connection finish (FIN) I opened a trouble ticket with etinc who promptly replied and informed me that etinc doesn't modify the tcp header at all. So my next step is to find out if the problem could be with the under lying OS. Any help is highly appreciated. -- Markus From link at ngc.net.ua Wed May 13 06:56:50 2009 From: link at ngc.net.ua (Zinevich Denis) Date: Wed May 13 06:57:01 2009 Subject: Questions on clustered FS + NFS In-Reply-To: <4A080C45.7010003@interazioni.it> References: <4A080851.3090101@interazioni.it> <4A080927.2080307@eenet.ee> <4A080C45.7010003@interazioni.it> Message-ID: <4A09D839.9040908@ngc.net.ua> The same issue for me. I have SAN connected to 4 servers. I was searching for such fs for about a week several month ago. I have not found anything matching this task. What was close - CODA. Now i do not exactly remember why it was not suitable for me... If you found how to solve this question - mail me please, I`m very interested in it too. Link. Tonix (Antonio Nati) ?????: > Joel Jans ha scritto: >> Tonix (Antonio Nati) wrote: >>> I'd love to put all my storage on a clustered NFS (with a ridondant >>> iSCSI controller and storage), FreeBSD based of course, but I see >>> there is not any clustered FS on FreeBSD. >>> >>> So, the solution seems to run a couple of GFS or OCFS2 on some Linux >>> servers, more some NFS servers handled by heartbeat. >>> >>> Is there any FreeBSD solution I could adopt? >>> >> >> Glusterfs, http://www.gluster.org/docs/index.php/GlusterFS >> http://www.freebsdwiki.net/index.php/GlusterFS >> >> Joel Jans >> >> > GlusterFS looks to be a distribuited FS. > What I need is to have two/three servers which are mounting in > read/write exactly the same storage (an external iSCSI subsystem), > exactly like wonderful old VMS did, or like GFS or OCFS2 seems to do now. > Both servers must mount the same iSCSI partitions, so they work on the > same data. > > Tonino > > From tonix at interazioni.it Mon May 18 10:46:33 2009 From: tonix at interazioni.it (Tonix (Antonio Nati)) Date: Mon May 18 10:46:40 2009 Subject: Questions on clustered FS + NFS In-Reply-To: <4A09D839.9040908@ngc.net.ua> References: <4A080851.3090101@interazioni.it> <4A080927.2080307@eenet.ee> <4A080C45.7010003@interazioni.it> <4A09D839.9040908@ngc.net.ua> Message-ID: <4A113C7C.506@interazioni.it> Actually, we are thinking to test ocfs2 + nfs in ths way: * a couple of Linux servers using ocfs2 sharing the same partition * NFS running on both, with heartbeat enabling only one, because we don't know how NFS can share locks among more NFS servers. To be more complete, we don't like how locks are handled by any of previously mentioned products. Ideally, there sould be a Distribuited Lock Manager (DLM), among all servers, and all layered products, both FS and NFS server, should use that DLM in order to manage/share locks. Is there any idea to develop a DLM on FreeBSD, to be integrated in kernel? Tonino Zinevich Denis ha scritto: > The same issue for me. I have SAN connected to 4 servers. I was > searching for such fs for about a week several month ago. I have not > found anything matching this task. What was close - CODA. Now i do not > exactly remember why it was not suitable for me... > If you found how to solve this question - mail me please, I`m very > interested in it too. > > Link. > > Tonix (Antonio Nati) ?????: >> Joel Jans ha scritto: >>> Tonix (Antonio Nati) wrote: >>>> I'd love to put all my storage on a clustered NFS (with a ridondant >>>> iSCSI controller and storage), FreeBSD based of course, but I see >>>> there is not any clustered FS on FreeBSD. >>>> >>>> So, the solution seems to run a couple of GFS or OCFS2 on some >>>> Linux servers, more some NFS servers handled by heartbeat. >>>> >>>> Is there any FreeBSD solution I could adopt? >>>> >>> >>> Glusterfs, http://www.gluster.org/docs/index.php/GlusterFS >>> http://www.freebsdwiki.net/index.php/GlusterFS >>> >>> Joel Jans >>> >>> >> GlusterFS looks to be a distribuited FS. >> What I need is to have two/three servers which are mounting in >> read/write exactly the same storage (an external iSCSI subsystem), >> exactly like wonderful old VMS did, or like GFS or OCFS2 seems to do >> now. >> Both servers must mount the same iSCSI partitions, so they work on >> the same data. >> >> Tonino >> >> > > _______________________________________________ > 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" > -- ------------------------------------------------------------ Inter@zioni Interazioni di Antonio Nati http://www.interazioni.it tonix@interazioni.it ------------------------------------------------------------ From festusloaninvestment at gmail.com Tue May 19 05:04:31 2009 From: festusloaninvestment at gmail.com (Dr.Barry Smith) Date: Tue May 19 05:04:38 2009 Subject: Do You Need Financial Assistance Message-ID: Do you need financial Assistance? We offer the following financial services 1. Personal Loans Quick & Secure! 2. Unsecured Personal Loans With Bad Credit. No Faxing of Documents and NO Credit Checks. Please send us an email with your contact information as below: * Name Of Applicant: * Country:- * Age: * Sex: * Occupation: * Tel: * Mobile: * Amount Requested : * Loan Duration: * Purpose of the Loan: Dr.Barry Smith For: Smith Financials drbarrysmith002@gmail.com From appointment.dcbr at snappydsl.net Tue May 19 18:35:55 2009 From: appointment.dcbr at snappydsl.net (David B. Kagan, DMD) Date: Tue May 19 18:36:02 2009 Subject: Beach Barbeque Message-ID: Beach Barbeque & Fireworks Dr Kagan and Team Saturday July 4th, 2009 In appreciation for all of our loyal patients, their families and friends we would love you to share a beach barbeque with us. Location: 800 Briny Ave, Pompano Beach Time: 5pm ? ?til fireworks ends!! Please RSVP by June 27th by phone: 561-487-4440 From tonix at interazioni.it Fri May 22 09:06:55 2009 From: tonix at interazioni.it (Tonix (Antonio Nati)) Date: Fri May 22 09:07:02 2009 Subject: Avoiding source code on production servers Message-ID: <4A166B29.1070202@interazioni.it> I'm in the phase of planning my new generation of FreeBSD servers, and I would love to make them more easy to upgrade. Main problem I have currently is I do not want any source code on production server, so freebsd-update is welcome, but... what about packages? I would use packages, but they are not easy to upgrade, while ports can be easy to upgrade, but need to have sources an servers. What do you suggest me? What is currently done on other environments? Thanks, Tonino -- ------------------------------------------------------------ Inter@zioni Interazioni di Antonio Nati http://www.interazioni.it tonix@interazioni.it ------------------------------------------------------------ From odhiambo at gmail.com Fri May 22 10:30:16 2009 From: odhiambo at gmail.com (=?UTF-8?B?T2RoaWFtYm8gIOODr+OCt+ODs+ODiOODsw==?=) Date: Fri May 22 10:30:31 2009 Subject: Avoiding source code on production servers In-Reply-To: <4A166B29.1070202@interazioni.it> References: <4A166B29.1070202@interazioni.it> Message-ID: <991123400905220310hec8f311kca96583e062d1d1b@mail.gmail.com> On Fri, May 22, 2009 at 12:06 PM, Tonix (Antonio Nati) wrote: > I'm in the phase of planning my new generation of FreeBSD servers, and I > would love to make them more easy to upgrade. > Main problem I have currently is I do not want any source code on > production server, so freebsd-update is welcome, but... what about packages? > I would use packages, but they are not easy to upgrade, while ports can be > easy to upgrade, but need to have sources an servers. > > What do you suggest me? What is currently done on other environments? Chicken & Egg situation there! -- Best regards, Odhiambo WASHINGTON, Nairobi,KE +254733744121/+254722743223 _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ "Clothes make the man. Naked people have little or no influence on society." -- Mark Twain From bsam at ipt.ru Fri May 22 11:20:05 2009 From: bsam at ipt.ru (Boris Samorodov) Date: Fri May 22 11:20:12 2009 Subject: Avoiding source code on production servers In-Reply-To: <4A166B29.1070202@interazioni.it> (tonix@interazioni.it's message of "Fri, 22 May 2009 11:06:49 +0200") References: <4A166B29.1070202@interazioni.it> Message-ID: <79934372@serv3.int.kfs.ru> On Fri, 22 May 2009 11:06:49 +0200 Tonix (Antonio Nati) wrote: > I'm in the phase of planning my new generation of FreeBSD servers, and > I would love to make them more easy to upgrade. > Main problem I have currently is I do not want any source code on > production server, so freebsd-update is welcome, but... what about > packages? > I would use packages, but they are not easy to upgrade, while ports > can be easy to upgrade, but need to have sources an servers. > What do you suggest me? What is currently done on other environments? We use ports-mgmt/tinderbox to build custom packages and then install them via "portupgrade -PP". But we are planning to switch to pkg_upgrade from sysutils/bsdadminscripts for package upgrading. The latter needs only INDEX file fetched from a package server. WBR -- bsam From howie at thingy.com Fri May 22 11:24:06 2009 From: howie at thingy.com (Howard Jones) Date: Fri May 22 11:24:14 2009 Subject: [freebsd-isp] Avoiding source code on production servers In-Reply-To: <4A166B29.1070202@interazioni.it> References: <4A166B29.1070202@interazioni.it> Message-ID: <4A1684E7.4050108@thingy.com> Tonix (Antonio Nati) wrote: > I'm in the phase of planning my new generation of FreeBSD servers, and > I would love to make them more easy to upgrade. > Main problem I have currently is I do not want any source code on > production server, so freebsd-update is welcome, but... what about > packages? > I would use packages, but they are not easy to upgrade, while ports > can be easy to upgrade, but need to have sources an servers. > > What do you suggest me? What is currently done on other environments? We have a local build server, which is the source for PXE installation of FreeBSD with our chosen set of packages, and also the server that builds local packages (things that don't have packages in the standard distro). It doesn't have to be anything fancy, and in fact ours is a VM since it gets used fairly rarely. I haven't got a nice way to do distribution of the packages though (like portsnap/freebsd-update/yum). That would make it more useful! As it is, we still update servers the 'old way'. From ericx at ericx.net Fri May 22 14:45:21 2009 From: ericx at ericx.net (Eric W. Bates) Date: Fri May 22 14:45:27 2009 Subject: Avoiding source code on production servers In-Reply-To: <4A166B29.1070202@interazioni.it> References: <4A166B29.1070202@interazioni.it> Message-ID: <4A16B65F.4080603@ericx.net> Tonix (Antonio Nati) wrote: > I'm in the phase of planning my new generation of FreeBSD servers, and I > would love to make them more easy to upgrade. > Main problem I have currently is I do not want any source code on > production server, so freebsd-update is welcome, but... what about > packages? > I would use packages, but they are not easy to upgrade, while ports can > be easy to upgrade, but need to have sources an servers. No source is a nice ideal; but you may not be able to stick to that and still get what you need. e.g. you may not want to always have the default options for every port. Just off the top of my head, I like SSL and English collation for mysql. You might consider using a single machine as your build machine and rsync your binaries out of it. If you really want to get rigorous and are maintaining a number of machines, then cfengine might help. > What do you suggest me? What is currently done on other environments? > > Thanks, > > Tonino > -- Eric W. Bates ericx@ericx.net (please note new address) From fb-isp at psconsult.nl Fri May 22 17:14:49 2009 From: fb-isp at psconsult.nl (Paul Schenkeveld) Date: Fri May 22 17:14:56 2009 Subject: Avoiding source code on production servers In-Reply-To: <4A166B29.1070202@interazioni.it> References: <4A166B29.1070202@interazioni.it> Message-ID: <20090522164719.GA83655@psconsult.nl> On Fri, May 22, 2009 at 11:06:49AM +0200, Tonix (Antonio Nati) wrote: > I'm in the phase of planning my new generation of FreeBSD servers, and I > would love to make them more easy to upgrade. > Main problem I have currently is I do not want any source code on > production server, so freebsd-update is welcome, but... what about > packages? > I would use packages, but they are not easy to upgrade, while ports can be > easy to upgrade, but need to have sources an servers. > > What do you suggest me? What is currently done on other environments? I've spent a lot of time over the last three years trying to automate maintenance of source-free servers. Ports are a real challenge. Other work with embedded systems (Soekris) has brought me the idea of using nanobsd(8) for servers. Although it may sound strange at first, experiments I'm currently undertaking give very promising results. The operating system and all ports are put into a read-only mounted root filesystem. /etc is a malloc-backed memory filesystem which gets filled by "standard" /etc contents part copied into /conf/base/etc in the root filesystem and then gets overlayed by modified files which are saved in a separate /cfg filesystem that you can mount read-write when changing configuration. /var, /home and other filesystems with user data are normal rw filesystems. Each server has two slices holding a root filesystem each, one is active and the other will be used to upload a new image when upgrading or adding software. After upgrading this alternate root slice you have to reboot the server so if you cannot tolerate a reboot, nanobsd is not for you. A roll-back is very easy if the new root does not satisfy you, just reboot and select the old slice to boot. Many of my servers have all applications hidden in jails, this makes this solution even easier as the host operating system ususally is very small on such servers. Each jail can be maintained and upgraded in a similar way, I keep a spare jail around to prepare the upgeade of / and /usr parts of application jails, stopping and restarting an application jail with the new /+/usr slice upgrades the software in the jail, rollbacks are easy as well. -- Paul Schenkeveld From bc979 at lafn.org Fri May 22 22:18:05 2009 From: bc979 at lafn.org (Doug Hardie) Date: Fri May 22 22:18:12 2009 Subject: Avoiding source code on production servers In-Reply-To: <4A166B29.1070202@interazioni.it> References: <4A166B29.1070202@interazioni.it> Message-ID: <3B06A176-1B66-4858-B67B-2D9D832B2104@lafn.org> On 22 May 2009, at 02:06, Tonix (Antonio Nati) wrote: > I'm in the phase of planning my new generation of FreeBSD servers, > and I would love to make them more easy to upgrade. > Main problem I have currently is I do not want any source code on > production server, so freebsd-update is welcome, but... what about > packages? > I would use packages, but they are not easy to upgrade, while ports > can be easy to upgrade, but need to have sources an servers. I maintain one, non-production, servers whose role is to keep the source and build the production kernels, userland, and ports. /usr/ src, /usr/ports, and /usr/obj are setup for NFS access. The production servers have empty directories for /usr/src, /usr/obj, and / usr/ports. For an upgrade I nfs mount those and do the upgrade. For locally developed software, it is maintained and tested on the non- production server. When its ready, there is a makefile entry for each production server that rcps the binary to the production server. This also helps in backups because the production servers only need to have their application data backed up. All the system/port backups are done on the non-production server. From neil at neely.cx Sat May 23 15:09:24 2009 From: neil at neely.cx (Neil Neely) Date: Sat May 23 15:09:31 2009 Subject: Avoiding source code on production servers In-Reply-To: <4A166B29.1070202@interazioni.it> References: <4A166B29.1070202@interazioni.it> Message-ID: <4A1809E2.8020608@neely.cx> Tonix (Antonio Nati) wrote: > I'm in the phase of planning my new generation of FreeBSD servers, and > I would love to make them more easy to upgrade. > Main problem I have currently is I do not want any source code on > production server, so freebsd-update is welcome, but... what about > packages? > I would use packages, but they are not easy to upgrade, while ports > can be easy to upgrade, but need to have sources an servers. The weakness of FreeBSD here is very unfortunate and IMO goes far beyond just source vs binary distribution. Working in a mixed environment where we have begun heavily using CentOS and utilizing yum it's obvious how far behind FreeBSD has fallen in this space. Ports lack any kind of concept of "Long Term Stable", so if you are running anything in ports (like say perl...) then when a security issue comes out you end up having to install new versions - the default is not to patch the older versions. For non-production environments that is likely fine, but for major production services it is a painful scenario. So you aren't just fixing security you are mixing in the concept of adjusting functionality as well. (A recent perl "security" upgrade moved perl to a new version which broke compatibility with the Crypt::CBC module requiring a reinstall - the new version of that from ports forced salting when it hadn't previously and now applications were needing to be recoded to get it all working again.) At the end of the day FreeBSD of course lets you have all the power to just apply the patches yourself to the source and you would be fine. At the cost that you need to be doing all of this work yourself and can't rely on nice management tools to help you. Every problem I've ever encountered with FreeBSD can be easily handled by a FreeBSD expert - but when I bring in a new green admin they have a heck of a time making any sense of it and I'm drug back into the trenches of managing all this. Why the contrast is extra frustrating is that it takes considerable skill and understanding of the details of an environment to safely update a production FreeBSD server. Contrast this with CentOS where an extremely green admin can easily manage it with minimal instruction. Unlike with the FreeBSD process this has no risk that it will cause cascading complex issues that require application modification to restore them to operation. I've been using FreeBSD since the 2.x days in '96 or so, and I love it - my tone is critical because I'm sad to see the state of things and doubly sad that I don't have the time to volunteer with the project to help do something about it. In most ways I consider FreeBSD superior to any linux, however this core issue of maintenance over time has been driving our shift to using CentOS over the last few years. If a "Long Term Stable Port Tree" concept were to come along I think that would plug the hole here. While I lack the time to lead such a charge, I would be happy to assist if such an effort were to get launched. -- Neil Neely http://neil-neely.blogspot.com/ From martes at mgwigglesworth.com Sat May 23 21:31:17 2009 From: martes at mgwigglesworth.com (martes) Date: Sat May 23 21:31:25 2009 Subject: Avoiding source code on production servers References: <4A166B29.1070202@interazioni.it> <4A1809E2.8020608@neely.cx> Message-ID: <0000071356@mail.mgwigglesworth.com> Greetings All. I have just begun to have time to fully investigate this type of topic. Have you not seen it worth the time to apply a patch in a custom package, or creation of such packages in general to resolve these type of issues? I may be off the target however, I just wanted to know what type of milage anyone may have gotten from using a test system for kernel builds ,etc as has been suggested, and is most likely the case for many, including me, however to use the builds to generate your own customized pkgs to install on incident systems to facilitate patches, etc.... How does that solution sound? I have not had a chance to test this however, I thought I saw such a solution on a very old archive when researching automation of kernel builds/installs, and automating system installation using packages. Any thouhgts? >Sat May 23 2009 10:36:18 EDT from Neil Neely to "Tonix (Antonio Nati)" >Subject: Re: Avoiding source code on production servers > >Tonix (Antonio Nati) wrote: > >>> I'm in the phase of planning my new generation of FreeBSD servers, and >>> I would love to make them more easy to upgrade. >>> Main problem I have currently is I do not want any source code on >>> production server, so freebsd-update is welcome, but... what about >>> packages? >>> I would use packages, but they are not easy to upgrade, while ports >>> can be easy to upgrade, but need to have sources an servers. >> >The weakness of FreeBSD here is very unfortunate and IMO goes far beyond >just source vs binary distribution. Working in a mixed environment >where we have begun heavily using CentOS and utilizing yum it's obvious >how far behind FreeBSD has fallen in this space. Ports lack any kind of >concept of "Long Term Stable", so if you are running anything in ports >(like say perl...) then when a security issue comes out you end up >having to install new versions - the default is not to patch the older >versions. For non-production environments that is likely fine, but for >major production services it is a painful scenario. So you aren't just >fixing security you are mixing in the concept of adjusting functionality >as well. > >(A recent perl "security" upgrade moved perl to a new version which >broke compatibility with the Crypt::CBC module requiring a reinstall - >the new version of that from ports forced salting when it hadn't >previously and now applications were needing to be recoded to get it all >working again.) > >At the end of the day FreeBSD of course lets you have all the power to >just apply the patches yourself to the source and you would be fine. At >the cost that you need to be doing all of this work yourself and can't >rely on nice management tools to help you. Every problem I've ever >encountered with FreeBSD can be easily handled by a FreeBSD expert - but >when I bring in a new green admin they have a heck of a time making any >sense of it and I'm drug back into the trenches of managing all this. > >Why the contrast is extra frustrating is that it takes considerable >skill and understanding of the details of an environment to safely >update a production FreeBSD server. Contrast this with CentOS where an >extremely green admin can easily manage it with minimal instruction. >Unlike with the FreeBSD process this has no risk that it will cause >cascading complex issues that require application modification to >restore them to operation. > >I've been using FreeBSD since the 2.x days in '96 or so, and I love it - >my tone is critical because I'm sad to see the state of things and >doubly sad that I don't have the time to volunteer with the project to >help do something about it. In most ways I consider FreeBSD superior to >any linux, however this core issue of maintenance over time has been >driving our shift to using CentOS over the last few years. If a "Long >Term Stable Port Tree" concept were to come along I think that would >plug the hole here. While I lack the time to lead such a charge, I >would be happy to assist if such an effort were to get launched. > >-- >Neil Neely >http://neil-neely.blogspot.com/ > >_______________________________________________ >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 kontakt at offshoreregistracija.com Tue May 26 21:38:04 2009 From: kontakt at offshoreregistracija.com (Offshore Tim) Date: Tue May 26 21:38:11 2009 Subject: Offshore registracija vozila Message-ID: <526231.HSJRTBVE@offshoreregistracija.com> Iskoristite mogucnost da registrujete vase vozilo na cook islands tablice i time izbegnete carinjenje i porez, bilo da se radi o novom ili polovnom vozilu iz uvoza. Takodje ovaj vid registracije vam omogucava da produzenje registracije izvrsite po mnogo povoljnijim uslovima i visestruko jeftinije. Produzenje registracije je fiksno za svu vrstu vozila bez obzira na kubikazu I starost vozila. Kod ovakvog vida registracije vozilo se registruje na vase ime i omogucava vam upravljanje motornim vozilom u zemlji i inostranstvu bez ikakve dodatne dokumentacije. Vise informacija na www.offshoreregistracija.com From tonix at interazioni.it Wed May 27 15:12:28 2009 From: tonix at interazioni.it (Tonix (Antonio Nati)) Date: Wed May 27 15:12:34 2009 Subject: Avoiding source code on production servers In-Reply-To: <4A1809E2.8020608@neely.cx> References: <4A166B29.1070202@interazioni.it> <4A1809E2.8020608@neely.cx> Message-ID: <4A1D5856.2040404@interazioni.it> Tonix (Antonio Nati) wrote: >> I'm in the phase of planning my new generation of FreeBSD servers, >> and I would love to make them more easy to upgrade. >> Main problem I have currently is I do not want any source code on >> production server, so freebsd-update is welcome, but... what about >> packages? >> I would use packages, but they are not easy to upgrade, while ports >> can be easy to upgrade, but need to have sources an servers. Thanks to all which answered, both publicy and privately. It looks to be a topic in which FreeBSD could be improved a lot. Is there any way we can drive/suggest something to do? Could be used Google Summer's code or something similar 8also sponsored by us)? Thanks, Tonino -- ------------------------------------------------------------ Inter@zioni Interazioni di Antonio Nati http://www.interazioni.it tonix@interazioni.it ------------------------------------------------------------ From dougb at FreeBSD.org Wed May 27 16:39:27 2009 From: dougb at FreeBSD.org (Doug Barton) Date: Wed May 27 16:39:33 2009 Subject: Avoiding source code on production servers In-Reply-To: <4A1D5856.2040404@interazioni.it> References: <4A166B29.1070202@interazioni.it> <4A1809E2.8020608@neely.cx> <4A1D5856.2040404@interazioni.it> Message-ID: <4A1D6691.9070006@FreeBSD.org> Tonix (Antonio Nati) wrote: > Tonix (Antonio Nati) wrote: >>> I'm in the phase of planning my new generation of FreeBSD servers, >>> and I would love to make them more easy to upgrade. >>> Main problem I have currently is I do not want any source code on >>> production server, so freebsd-update is welcome, but... what about >>> packages? >>> I would use packages, but they are not easy to upgrade, while ports >>> can be easy to upgrade, but need to have sources an servers. > Thanks to all which answered, both publicy and privately. > It looks to be a topic in which FreeBSD could be improved a lot. > > Is there any way we can drive/suggest something to do? > Could be used Google Summer's code or something similar 8also sponsored > by us)? I've submitted a proposal to the Foundation twice to extend portmaster with similar functionality, but I haven't made the cut yet. I am still interested in obtaining funding for this project, and this looks like as good an opportunity as any to put that idea in front of new eyeballs. Please take a look at the URL below, and anyone who has ideas on how I might go about obtaining funding for this project feel please let me know. Regards, Doug http://dougbarton.us/portmaster-proposal.html From dougb at FreeBSD.org Wed May 27 16:42:04 2009 From: dougb at FreeBSD.org (Doug Barton) Date: Wed May 27 16:42:17 2009 Subject: Avoiding source code on production servers In-Reply-To: <4A1D6691.9070006@FreeBSD.org> References: <4A166B29.1070202@interazioni.it> <4A1809E2.8020608@neely.cx> <4A1D5856.2040404@interazioni.it> <4A1D6691.9070006@FreeBSD.org> Message-ID: <4A1D6C75.6000603@FreeBSD.org> Doug Barton wrote: > ... and anyone who has > ideas on how I might go about obtaining funding for this project feel > please let me know. D'oh! That was going to be "feel free to," and somehow got jumbled between brain and fingers. From 000.fbsd at quip.cz Wed May 27 23:17:52 2009 From: 000.fbsd at quip.cz (Miroslav Lachman) Date: Wed May 27 23:17:59 2009 Subject: Avoiding source code on production servers In-Reply-To: <4A1D6691.9070006@FreeBSD.org> References: <4A166B29.1070202@interazioni.it> <4A1809E2.8020608@neely.cx> <4A1D5856.2040404@interazioni.it> <4A1D6691.9070006@FreeBSD.org> Message-ID: <4A1DC599.6010704@quip.cz> Doug Barton wrote: [...] > I've submitted a proposal to the Foundation twice to extend portmaster > with similar functionality, but I haven't made the cut yet. I am still > interested in obtaining funding for this project, and this looks like > as good an opportunity as any to put that idea in front of new > eyeballs. Please take a look at the URL below, and anyone who has > ideas on how I might go about obtaining funding for this project feel > please let me know. > > > Regards, > > Doug > > http://dougbarton.us/portmaster-proposal.html As I am one of the users waiting for the feature: "H. Add support for shutdown and startup of services." I am suggesting more general interface for deinstall/preinstall/postinstall action hooks. Not just stop & start services, but allow users to define any shell command(s) to be executed in given [de|pre|post]install stage. Similar to BEFOREDEINSTALL, AFTERINSTALL... in pkgtools.conf of portupgrade, where one can define for example: 'security/courier-authlib*' => proc { |origin| cmd_real_restart_rc(origin) + '; chmod 0755 /var/run/authdaemond' }, It will be useful to define any commands, for example some logging patterns, e-mail alerts to operators, or shutdown another depending services (one may want to stop Apache, Postfix etc. if those services depends on MySQL and MySQL is the deinstalled package) I was trying to hack it on my own few month ago, but end up with ENOTIME (+ ENOSKILLS) :o) This is #1 on my wish list for improvements of portmaster. (#2 is support of binary packages) I hope you will succeed with funding. Thank you for your work on portmaster! (my primary ports tool) Miroslav Lachman From nglrossi at gmail.com Thu May 28 10:31:54 2009 From: nglrossi at gmail.com (Angelo) Date: Thu May 28 10:32:01 2009 Subject: Avoiding source code on production servers In-Reply-To: <4A166B29.1070202@interazioni.it> References: <4A166B29.1070202@interazioni.it> Message-ID: <6c1e076a0905280306q3457242q311e0f8a0c2cff38@mail.gmail.com> On Fri, May 22, 2009 at 11:06 AM, Tonix (Antonio Nati) wrote: > I'm in the phase of planning my new generation of FreeBSD servers, and I > would love to make them more easy to upgrade. > Main problem I have currently is I do not want any source code on > production server, so freebsd-update is welcome, but... what about packages? > I would use packages, but they are not easy to upgrade, while ports can be > easy to upgrade, but need to have sources an servers. > > What do you suggest me? What is currently done on other environments? > > Thanks, > > Tonino > > -- > ------------------------------------------------------------ > Inter@zioni Interazioni di Antonio Nati > http://www.interazioni.it tonix@interazioni.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" > Hi, some good solutions have been suggested. I personally like and find easy to maintain these two: - having a build server where to compile code, pkg_create and then distribute the packages and pkg_add them (what I was doing at the last shop where I was working on FreeBSD) - when you need to install/upgrade software you nfsmount volumes from a non critical host that hosts the source code All the installation/upgrades can be pushed with a tool like cfengine; this way you can test the process on testing servers and then decide when and how to push the changes on the other machines in the order you wish. With cfengine you can perform whatever actions you want so you can actually include pre and post installation scripts and checks. This also makes really easy to add new machines, install a fresh OS and apply ALL the changes you applied to the other server without forgetting a single package or setting. To keep things simple I try to have the base freebsd setup as clean as possible on the server and install only the packages that are really needed for infrastructural purposes: monitoring tools, cfengine and a host based firewall. Every non infrastructural service goes on its own into a minimal jail This makes trivial to migrate services from a server to another and prevents to have package conflicts (never tried to make different versions of php or perl coexist?) on the base system. My 2 cents :) Angelo From steve at kcilink.com Thu May 28 16:35:07 2009 From: steve at kcilink.com (Steve Scally) Date: Thu May 28 16:35:23 2009 Subject: Avoiding source code on production servers (Neil Neely) In-Reply-To: <20090524120020.6B42E10656B9@hub.freebsd.org> References: <20090524120020.6B42E10656B9@hub.freebsd.org> Message-ID: > > Tonix (Antonio Nati) wrote: >> I'm in the phase of planning my new generation of FreeBSD servers, >> and >> I would love to make them more easy to upgrade. >> Main problem I have currently is I do not want any source code on >> production server, so freebsd-update is welcome, but... what about >> packages? >> I would use packages, but they are not easy to upgrade, while ports >> can be easy to upgrade, but need to have sources an servers. > The weakness of FreeBSD here is very unfortunate and IMO goes far > beyond > just source vs binary distribution. Working in a mixed environment > where we have begun heavily using CentOS and utilizing yum it's > obvious > how far behind FreeBSD has fallen in this space. Ports lack any > kind of > concept of "Long Term Stable", so if you are running anything in > ports > (like say perl...) then when a security issue comes out you end up > having to install new versions - the default is not to patch the older > versions. For non-production environments that is likely fine, but > for > major production services it is a painful scenario. So you aren't > just > fixing security you are mixing in the concept of adjusting > functionality > as well. > > (A recent perl "security" upgrade moved perl to a new version which > broke compatibility with the Crypt::CBC module requiring a reinstall - > the new version of that from ports forced salting when it hadn't > previously and now applications were needing to be recoded to get it > all > working again.) This seems more like a flaw in the upgrade procedure you have setup and not testing before upgrading. I would assume, being this is the ISP list, you have multiple redundant type boxes of which one can be taken out of production and upgraded and if it fails will not disrupt service. One setup, which I can think of, that can't really be tested is if your hosting sites for customers in that case it would be a bit hard to setup a mirrored test environment for but nothing is impossible. > > At the end of the day FreeBSD of course lets you have all the power to > just apply the patches yourself to the source and you would be > fine. At > the cost that you need to be doing all of this work yourself and can't > rely on nice management tools to help you. Every problem I've ever > encountered with FreeBSD can be easily handled by a FreeBSD expert - > but > when I bring in a new green admin they have a heck of a time making > any > sense of it and I'm drug back into the trenches of managing all this. I am coming from the opposite end, I used to do CentOS work and now work on FreeBSD and after getting over the initial learning curve and methodology of FreeBSD I find it much better than CentOS. It is much easier to screw up a system with a yum upgrade, wrong priority, or a package from the centos-plus repo. Also linux in general doesn't have a centralized place to read pr notices or an automated portaudit system. For me I had to follow a security focus list or CERT list to see which packages were vulnerable then go to the maintainers and get information. Then I had to wait for CentOS to push out an update and that to me is a maintenance nightmare. The only way to get your new admin up to speed is to let them experience the problem and solve it. Internal documentation also helps immensely or a wiki. Without the network specific information available it doesn't matter what OS you use there will be a huge hurtle. In fact if you don't already have this setup why not let your junior guys work on it. In our wiki we have all our procedures for backups, nightly processes, system flows, mail paths, port options, etc. We also have pages listing all issues or steps needed for upgrades of all our specific server types, mail, dns, management and so on. > > > Why the contrast is extra frustrating is that it takes considerable > skill and understanding of the details of an environment to safely > update a production FreeBSD server. Internal documentation would help here as well as a repo for all your one-off configs then multiple changes can be tracked. > Contrast this with CentOS where an > extremely green admin can easily manage it with minimal instruction. > Unlike with the FreeBSD process this has no risk that it will cause > cascading complex issues that require application modification to > restore them to operation. > Yum can be be just as finicky and destructive if not setup or executed correctly. Just my thoughts. > I've been using FreeBSD since the 2.x days in '96 or so, and I love > it - > my tone is critical because I'm sad to see the state of things and > doubly sad that I don't have the time to volunteer with the project to > help do something about it. In most ways I consider FreeBSD > superior to > any linux, however this core issue of maintenance over time has been > driving our shift to using CentOS over the last few years. If a "Long > Term Stable Port Tree" concept were to come along I think that would > plug the hole here. While I lack the time to lead such a charge, I > would be happy to assist if such an effort were to get launched. > > -- > Neil Neely > http://neil-neely.blogspot.com/ From support at eset.com Fri May 29 10:21:02 2009 From: support at eset.com (support@eset.com) Date: Fri May 29 10:21:08 2009 Subject: ESET Customer Care, unknown ticket number In-Reply-To: <20090529095824.CA1F4B3199D5@ocelot.nod.sk> Message-ID: <0000Ma514QD260PC@eset.sk> Dear Valued Customer The e-mail you sent does not contain valid Ticket number. In case you have open support request with ESET Customer Care please use a "Reply" function to respond to any e-mail sent from ESET Customer Care Representative. In case you would like to open a new service request please use technical support form in the "Help and Support" section in your product (recomended ESET Smart Security and ESET NOD32 Antivirus version 3 and higher). Alternatively you may use the technical support form on our webpage: http://www.eset.eu/support/form Kind regards, ESET Customer Care Aupark Tower, 16th floor, 851 01 Bratislava, Slovak Republic www.eset.eu ----- Original Message ----- From: freebsd-isp@freebsd.org Sent: Friday, May 29, 2009 11:55:05 AM GMT+02:00 Subject: Delivery Error (support@nod32.com) > >Mail Delivery Error - This mail contains unicode characters > >------------- failed message ------------- >jsTK1bhOP>yM'!R!k!SpVA:7q22pR*oFuvGWxlnU:S' >w*2~9~-<_Jx*?!#U'9.(94g-zsYHuq?-W9ZYv%t?e1+v0sL?o.AeNTe_Aggeeo:ba+bM2h_U4QO'_PfeiPSlrW >YAO'BZG$Sovys&Tob&vcGl>( > >The message has been sent as a binary attachment. > From copyright at youtube.com Fri May 29 12:58:29 2009 From: copyright at youtube.com (Copyright Service) Date: Fri May 29 12:58:35 2009 Subject: approved In-Reply-To: <20090529124737.EF8094001A@sjl-mbox1.sjl.youtube.com> Message-ID: <#14.1aa9bfd0.945ac5ce.4a1fd992.2577@google.trakken.com> This is an automated response to let you know that your message has been caught by our spam filter. Something in your message set it off, and your message won't be read. Please don't reply to this message -- we won't get your response. We want to hear from you, however, and apologize for this inconvenience! Please try sending your message again, possibly excluding any strange text or images. Sending your message as "Plain Text" is probably a good idea too. Alternately, you can send us a message using the contact form in our help center. http://www.google.com/support/youtube Original Message Follows: ------------------------ From: freebsd-isp@freebsd.org Subject: approved Date: Fri, 29 May 2009 20:47:38 +0800 Your file is attached. ******************************************************************** Original filename: file.pif Virus discovered: W32/Netsky.P@mm ******************************************************************** A file that was attached to this email contained a virus. It is very likely that the original message was generated by the virus and not a person - treat this message as you would any other junk mail (spam). For more information on why you received this message please visit: http://www.corp.google.com/ops/sysops/services/email/filtering/spam-virus/end_user.html#virusoverview For specific questions about this policy, or if this is a matter requiring the attention of a human, open a Helpdesk ticket. ********************************************************************