Re: broken re(4)
On Thu, 12 Jun 2008 12:22:28 +0900 Pyun YongHyeon <[EMAIL PROTECTED]> wrote about Re: broken re(4): PY> Before checking performance of network controller you had to rule PY> out other factors like disk I/O. Use one of benchmark programs in PY> ports/benchmark. I already did simple benchmarking by using "dd if=/dev/zero of=file" which gave me several 10s of MByte/s under all circumstances. Can you recommend one of the benchmarking programs for more detailed testing? cu Gerrit ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD 7.0 Stable and the CP2101 driver
2008/6/11 Dennis Flynn <[EMAIL PROTECTED]>: [trim] > I tried installing the update, e.g. "freebsd-update -r 7.0-STABLE fetch", > then "freebsd-update -r 7.0-STABLE upgrade". Seemed to work. But I do not > seem to have the device driver loaded when I plug in the USB device. I get > the folowwing in the messages log: > > Jun 10 16:48:02 wx kernel: ugen0: Controller, class 0/0, rev 1.10/1.00, addr 2> on uhub0 > > But I don't see a device that I think I should see, like /dev/ttyU0. If I do > a "uname -a" I see the following: > > FreeBSD wx.dennis-flynn.net 7.0-RELEASE FreeBSD 7.0-RELEASE #0: Sun Feb 24 > 19:59:52 UTC 2008 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC i386 > > That doesn't seem right to me. Shouldn't I see something like 7.0-RELEASE-p1 > or 7.0-STABLE? Did I do something wrong in my update to RELEASE? How do I > know if I'm running the STABLE kernel with the driver I want? How can I tell > if the driver (uslcom) is there and/or loaded? > uslcom(4) appeared somewhere in 7.0-STABLE in GENERIC, and you are running 7.0-RELEASE, that is older. freebsd-update works only with releases (plus sec.patches), and 7.0-STABLE is not a release (obviously because you cannot definitely say to what date it corresponds). So you should update it to STABLE manually or wait until 7.1 is out. wbr, pluknet ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: apachectl gracefult causes Signal 11 crash after 6.3 to 7.0 upgrade [SOLVED]
On Thu, Jun 12, 2008 at 02:45:21PM +0930, Daniel O'Connor wrote: > On Thu, 12 Jun 2008, Jim Pingle wrote: > > I need to see if I can improve the script any (suggestions are most > > welcome) then open a PR to see if it -- or logic like it -- can be > > included in the php-extensions meta port. > > Adding the script to the port seems like the way to go (baring an > upstream fix but it seems like a difficult problem to solve). > > Unfortunately it doesn't help me :( > If I disable everything except either pgsql or mhash (either separately > or together) Apache crashes with.. > > #0 0x28ad6d40 in ?? () > #1 0x281c6f2e in _pthread_main_np () from /lib/libc.so.7 > #2 0x2819fa0c in puts () from /lib/libc.so.7 > #3 0x281a0177 in gethostbyname () from /lib/libc.so.7 > #4 0x08069a12 in ap_get_local_host () > #5 0x08068b9c in ap_fini_vhost_config () > #6 0x0805639c in ap_read_config () > #7 0x0805f133 in standalone_main () > #8 0x08060c1f in main () > > I don't understand why gethostbyname() would call puts() - and why that > would then crash! I can't explain why it's calling puts() directly either. Bad RAM could cause something bizarre like this, or a corrupt/broken binary. The libc code I'm looking at (src/lib/libc/net/gethostnameadr.c and gethostbydns.c) don't call puts) don't appear to call puts() directly. Of course, there may be macros used which do this. There are some places in the resolver code where printing to stdout or stderr can occur. I'd expect to see a longer stack trace (meaning more functions between gethostbyname() and puts()) if that were the case, though. There's a decent document on how to debug httpd below. You'll need to start httpd with -X or with "MaxClients 1", to keep it from forking. You can do that through gdb if you want, or (what I prefer, since I'm not very good with gdb) use truss. http://httpd.apache.org/dev/debugging.html If you go the truss route, be sure to use -a -s 4096. You'd be able to see what actual string is being output via puts(), assuming it gets as far as to start writing data to the fd. -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: apachectl gracefult causes Signal 11 crash after 6.3 to 7.0 upgrade [SOLVED]
On Thu, 12 Jun 2008, Jim Pingle wrote: > I need to see if I can improve the script any (suggestions are most > welcome) then open a PR to see if it -- or logic like it -- can be > included in the php-extensions meta port. Adding the script to the port seems like the way to go (baring an upstream fix but it seems like a difficult problem to solve). Unfortunately it doesn't help me :( If I disable everything except either pgsql or mhash (either separately or together) Apache crashes with.. #0 0x28ad6d40 in ?? () #1 0x281c6f2e in _pthread_main_np () from /lib/libc.so.7 #2 0x2819fa0c in puts () from /lib/libc.so.7 #3 0x281a0177 in gethostbyname () from /lib/libc.so.7 #4 0x08069a12 in ap_get_local_host () #5 0x08068b9c in ap_fini_vhost_config () #6 0x0805639c in ap_read_config () #7 0x0805f133 in standalone_main () #8 0x08060c1f in main () I don't understand why gethostbyname() would call puts() - and why that would then crash! Seems like some threading related wrinkle though as pgsql & mhash are the only extensions I have that are linked to libthr.so -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C signature.asc Description: This is a digitally signed message part.
Under gnome-2.22.2, can not lock the screen
Hi! The version of the freebsd is 7.0-stable(June 9 2008), and the gnome was also updated to 2.22.2. But, I can not lock the screen, when I click the "Lock Screen" button under System Menu(The acpi can works well). I can't find the right way to let it work. Thanks any way ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: apachectl gracefult causes Signal 11 crash after 6.3 to 7.0 upgrade [SOLVED]
Daniel O'Connor wrote: On Thu, 12 Jun 2008, Jeremy Chadwick wrote: I myself haven't ever run into extension ordering issues like those described (and we've done hosting for years), but I don't doubt those who have experienced such. I am currently experiencing this :( In the past I shuffled the order until it worked but that's not a real solution. [snip] I've mentioned this on the lists a couple times, but I have a shell script I worked out that puts the extensions into a known-working order. http://www.pingle.org/2007/09/22/php-crashes-extensions-workaround It's based on things I've come across with respect to this issue over the last couple years. It's not a new problem by a long shot. It's been happening to me for years with PHP4 and PHP5, Apache 1.3.x and 2.x. See also my previous posts on my site: http://www.pingle.org/2006/10/18/php-crashes-extensions http://www.pingle.org/2007/05/13/php-crashes-extensions-2 And some previous threads on the topic: http://lists.freebsd.org/pipermail/freebsd-stable/2006-November/030951.html http://lists.freebsd.org/mailman/htdig/freebsd-ports/2006-November/036849.html (I thought there were more but I can't find them at the moment...) I need to see if I can improve the script any (suggestions are most welcome) then open a PR to see if it -- or logic like it -- can be included in the php-extensions meta port. Jim ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: broken re(4)
On Wed, Jun 11, 2008 at 09:24:57AM +0200, Gerrit K?hn wrote: > On Tue, 10 Jun 2008 20:43:04 +0200 Daniele Bastianini > <[EMAIL PROTECTED]> wrote about Re: broken re(4): > > DB> > - copying large files (more than some 100MB) via ssh/scp drops the > DB> > connection due to "corrupted MAC on input": > DB> > Disconnecting: Corrupted MAC on input. > DB> > lost connection > > DB> I had the same problem. > DB> I fixed it (for now) making a buildworld with > DB> *default date=2008.03.01.00.00.00 in my src csup configuration. > > DB> I'm not so skilled to investigate in the sources but the problem is > DB> after this date. > > For me all versions from cvs and all patches from Pyun are working now, > after I have solved the issue with the bad riser card. I still think it's > funny that the riser causes this kind of trouble for the networking chips. > > On the other hand, I have not been able to get more than about 10MByte/s > through the interfaces of this particular system. I have 1GBit-networking > equipment, and the other systems (which are used as router) have no > problem doing a throughput of >20MB/s. Even bonding the two interfaces > using lagg(4) does not improve the performance - where else could be the > bottleneck? Before checking performance of network controller you had to rule out other factors like disk I/O. Use one of benchmark programs in ports/benchmark. > The only difference here is that I have the extra SATA-controller with > disks in there. However, the disks appear to be as fast as I can expect > from a SATA150-interface. > -- Regards, Pyun YongHyeon ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Areca Raid 6 ARC-1231 Raid 6 Slow LS Listing Performance on large directory
2008/6/12 Paul <[EMAIL PROTECTED]>: > 1) When I do a ls -lh on the raid 6 array with 6 disks in the array it takes > aver 16 seconds before it starts to display anything on the screen. > 2) While running a tar command on another shell, the time goes to 28 seconds > for the same list to start showing. > 3) When I do a ls (with no other options) it starts to list right away. > 4) When I do a ls -ln it displays right away as well pointing to the > slowdown being the mapping of the users in the db lookup. > > I have the same directory with the same number of files on a Raid 5 SCSI > partition on Freebsd 4.X and it only takes 2 seconds to start displaying the > list with the command ls -lh. > > Any ideas why it takes so long for this on Freebsd 7.0 stable? > > The partition this folder is on it /dev/da0s1f with a total size of 1.7T > and a usage of 63G > > Any suggestions or help on this would be greatly appreciated. Could you please do a couple of other tests, if you're able to? I've got a PR to look into this issue. Could you see if using a smaller password file makes the ls start/run quicker? Could you possibly run ls inside "truss" on both FreeBSD-4 and FreeBSD-7 and email me a snippet of the output (say, a few hundred lines) ? Something like: truss ls >foo 2>&1 Thanks, Adrian -- Adrian Chadd - [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: apachectl gracefult causes Signal 11 crash after 6.3 to 7.0 upgrade [SOLVED]
On Thu, 12 Jun 2008, Jeremy Chadwick wrote: > I myself haven't ever run into extension ordering issues like those > described (and we've done hosting for years), but I don't doubt those > who have experienced such. I am currently experiencing this :( In the past I shuffled the order until it worked but that's not a real solution. Also if you have gone from 6.x to 7.x make sure that you don't have any old stuff linked against libc.so.6 loaded into a binary using libc.so.7. It mostly works except with threaded programs and then *kaboom* -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C signature.asc Description: This is a digitally signed message part.
Re: Areca Raid 6 ARC-1231 Raid 6 Slow LS Listing Performance on large directory
On Thu, 12 Jun 2008, Mike Tancsa wrote: > At 04:04 PM 6/11/2008, Paul wrote: > >Changing from compat to files fixes the problem. > > > >It is now superfast when running ls -lh. > > Hi, > Not sure, but a more "proper" fix might be to look at the > nscd caching daemon. Take a look at nscd and nscd.conf. I havent used > it myself, but I seem to recall others suggesting this as a "fix" as > well. Why is 'compat' so slow? (ie what's the difference between it and file anyway) -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C signature.asc Description: This is a digitally signed message part.
Re: Vlan EVENT patch
On Wed, Jun 11, 2008 at 09:52:23AM -0700, Jack Vogel wrote: > On Wed, Jun 11, 2008 at 12:33 AM, Pyun YongHyeon <[EMAIL PROTECTED]> wrote: > > On Tue, Jun 10, 2008 at 09:51:53AM -0700, Jack Vogel wrote: > > > This is a small patch that Sam came up with for me, it will allow > > > drivers to know > > > when a vlan attaches. > > > > > > It is transparent to any code that doesn't want to change, but this > > > will allow my > > > drivers to finally utilize the vlan hardware filter (something Linux > > has had for > > > ever but we lacked). > > > > > > > Just curious, is there any rule how to use that new capability? > > Because drivers will receive events whenever VLAN tags are > > added/removed they would know how to act for these events. If > > promiscuous mode is on for interface, driver should not filter any > > VLAN tagged frames, right? > > If users want to disable VLAN hardware filtering feature what is > > best way to perform this? Introducing a new flag like > > IFCAP_VLAN_HWFILT or add a new sysctl that control this feature? > > I guess VIA Rhine III also have VLAN hardware filtering capability > > so it would be even better if we have a way to share common part. > > All the patch does is have the vlan driver generate events when it attaches > or detaches from a NIC, there are no rules, however I can tell you what > I'm coding into this in the Intel drivers. > > The way it works is the driver registers a callback for each event, I will > call that [igb,em,ixgbe]_register_vlan(), and unregister obviously. > > Right now, the drivers just generically enable VLAN capability because > there is never a trigger to know IF and WHEN you need to do so, but > with this change the VLAN capability will only get turned on by the > registration routine. > > Most significantly, now when the pseudo device it gives the driver > the VLAN tag, this will mean the driver will be able from the start > to use the VFTA, the hardware filter, for each vlan attach the driver > will add the ID into this table. > > The unregister event will turn the table entry off, and if this is the > last VLAN being detached it will then disable the features. > > Oh yes, these routines will also take care of the size change of > the frame due to the tag. I already have the changes in place in > the igb drive, and they are working great. > > I do not understand why you think you need a flag to disable this, > yes it could be done, but why? If you need to do some sort of > debugging won't a system not using vlans and in promiscuous > mode do just fine? > I guess this would be the same reason why FreeBSD have a way to disable checksum offload for buggy hardware. Diabling all hardware VLAN assistance due to broken VLAN filtering doesn't look right. > It just seems to violate the whole reason for doing vlans in the > first place, however perhaps I am missing something? I do not > believe the Linux driver has some way to disable use of the table > but I'll double check on that. > > Remember, this change requires NO driver changes unless they > wish to take advantage of the ability. Yes. > > Cheers, > > Jack Thanks. -- Regards, Pyun YongHyeon ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
PureComponents Ultimate Suite V2008.1 - 79 .NET WinForms Components for $79
PureComponents Ultimate Suite V2008.1 - The cheapest component suite there is! PureComponents offer you component suite for excellent price of 1 USD per component. Purchase the set of 79 components for 79 USD. Purchase 1 year subscription by June 30, and save 30%! http://www.purecomponents.com/ If you would not like to receive these messages, please visit: http://www.purecomponents.com/unsubscribe.aspx ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
CLARITY re: challenge: end of life for 6.2 is premature withbuggy 6.3
On Wed, Jun 11 2008, Robert Watson wrote: On Wed, 11 Jun 2008, Paul Schmehl wrote: >> From a security standport, backporting fixes to previous versions of ports >> creates a difficulty. It's much harder to tell, for example, if a RedHat >> "port" is vulnerable or not, because RedHat uses their own proprietary >> versioning system to define "where" a particular "port" is at. >> >> So, while your system might *say* it's running php version 5.2, it's really >> *not* vulnerable because in RedHatese it's version 5.2.1.6.92000.p-2.1 (I'm >> just making that up.) >> >> If this idea ever gets off the ground, I *hope* the folks involved with find >> a rational, logical way to define the versioning so that it's not >> hieroglyphics to the average person. Egyptian hieroglyphics was a very noble system the secret of which was, in the days of old, in the possession only of the Hierogrammatists, or initiated Egyptian priests. Many occult alphabets and ciphers derived its origin from egyptian sacred ciphers, as also everything we know as cryptography today. I guess our english alphabet would be equally strange and uknown to them. But reading widely available documentation on Redhat's versioning system would definetly help in understanding its details. Everything after second - (dash) like in ftp-0.17-33 is Redhat's release version. In this case this is thirty third release or patch. It is similar to FreeBSD's naming convention. You can check changelog and see what has changed since release 1 by issuing: $ rpm -q --changelog So the system is very clear and precise, just like FreeBSD system. The only difference is that upstream version of the package changes a lot more often than on redhat/centos. > We already do this for some >ports, in that the people involved in adapting and maintaining some of the >larger/more critical parts, such as X.org, KDE, Gnome, and quite a few others, >spend vast amounts of time ensuring that things work well, but largely without >the help of revision control in the ports tree. I'm not proposing we >incorporate X.org into CVS (SVN?) or the like, but perhaps there is a way we >could better present the choices reflected there. That doesn't help users of >random tiny software packages, and I'm not sure anything can, but perhaps we >can provide a smoother incremental maintenance path for some key packages. I think that most system administrators who maintain many FreeBSD servers in data center environments do not really care about "X.org, KDE, Gnome" and other desktop applications having those -SECURITY patches backported. The real concern here is about common server applications. I think that cutting edge users who run FreeBSD on their workstations are perfectly aware that things can sometimes break, and to a degree they accept that risk. But system administrators running mission critical nonstop systems 24/7 cannot accept such risk with the server ports they are using. So if anything can be improved in ease of upgrading, backporting etc. this is the main area to investigate, so as to make FreeBSD the most stable and reliable Unix operating system out there. -- Andy Kosela ora et labora ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Areca Raid 6 ARC-1231 Raid 6 Slow LS Listing Performance on large directory
At 04:04 PM 6/11/2008, Paul wrote: Changing from compat to files fixes the problem. It is now superfast when running ls -lh. Hi, Not sure, but a more "proper" fix might be to look at the nscd caching daemon. Take a look at nscd and nscd.conf. I havent used it myself, but I seem to recall others suggesting this as a "fix" as well. ---Mike ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: apachectl gracefult causes Signal 11 crash after 6.3 to 7.0 upgrade [SOLVED]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jordi Espasa Clofent wrote: | It seems a php-extensions bug. | If you comment the mhash.so in /usr/local/etc/php/extensions.ini as: | | ;entension=mhash.so | | all works fine and you don't get anymore httpd crash (signal 11) if you | use 'apachectl graceful'. | | Maybe will be a good idea to open PR for this? | | I hope it helps someone (I'm very surprised that this isn't a | documented bug in 7.0 yet) It might make more sense to follow up with php. Just b/c it happens in 7.x and not 6.x doesn't mean its a FreeBSD issue. - -- - Philip M. Gollucci ([EMAIL PROTECTED]) o:703.549.2050x206 Senior System Admin - Riderway, Inc. http://riderway.com / http://ridecharge.com 1024D/DB9B8C1C B90B FBC3 A3A1 C71A 8E70 3F8C 75B8 8FFB DB9B 8C1C Work like you don't need the money, love like you'll never get hurt, and dance like nobody's watching. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.8 (FreeBSD) iD8DBQFIUDAgdbiP+9ubjBwRAskiAJ993ELYL3AP5HkVtDSk2JQx9OuJzACfdORO rnTL1Ecdd4MNwlcrNKhwLYM= =lX0o -END PGP SIGNATURE- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Areca Raid 6 ARC-1231 Raid 6 Slow LS Listing Performance on large directory
At 02:11 PM 11/06/2008, Mike Tancsa wrote: Any ideas why it takes so long for this on Freebsd 7.0 stable? The partition this folder is on it /dev/da0s1f with a total size of 1.7T and a usage of 63G Any suggestions or help on this would be greatly appreciated. Couple of things to check In /etc/nsswitch.conf try changing to group: files passwd: files and check to make sure vfs.ufs.dirhash_maxmem is > than vfs.ufs.dirhash_mem. If vfs.ufs.dirhash_mem is hit the max, increase the maxmem value ---Mike Thanks a lot for the quick reply. Changing from compat to files fixes the problem. It is now superfast when running ls -lh. Thanks again! Cheers Paul ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: CLARITY re: challenge: end of life for 6.2 is premature with buggy 6.3
Gary Palmer wrote: I think a large part of the shortcomings of the ports infrastructure when it comes to security releases could be mitigated if there was a rapid building and availability of packages on FTP mirrors to prevent everyone from doing "portupgrade -P" and then having to wait for the build as the packages don't show up for days, and people can't wait that long for the fix. I raised that issue recently on freebsd-ports@ and was told that there are no resources for that right now, although everyone agreed that it is definitely something that would be nice-to-have. Doug -- This .signature sanitized for your protection ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: CLARITY re: challenge: end of life for 6.2 is premature withbuggy 6.3
On Wed, Jun 11, 2008 at 07:36:28PM +0100, Robert Watson wrote: > > On Wed, 11 Jun 2008, Paul Schmehl wrote: > > >From a security standport, backporting fixes to previous versions of ports > >creates a difficulty. It's much harder to tell, for example, if a RedHat > >"port" is vulnerable or not, because RedHat uses their own proprietary > >versioning system to define "where" a particular "port" is at. > > > >So, while your system might *say* it's running php version 5.2, it's > >really *not* vulnerable because in RedHatese it's version > >5.2.1.6.92000.p-2.1 (I'm just making that up.) > > > >If this idea ever gets off the ground, I *hope* the folks involved with > >find a rational, logical way to define the versioning so that it's not > >hieroglyphics to the average person. > > I hope not to offend the ports folks in saying this, but it seems clear to > me that the narrower scope and better-defined components of the base system > have (over time) lead to a much easier incremental upgrade path than ports > and packages. > > It's not clear to me how you could apply the same level of attention to > something as large as the ports collection, except perhaps to select a > subset of ports you care "more" about, and provide a higher quality of > service for them. In effect, try to find a semantically richer middle > ground between "it's someone else's problem, our role is primarily to > bundle" and "it's entirely our problem and in revision control". We > already do this for some ports, in that the people involved in adapting and > maintaining some of the larger/more critical parts, such as X.org, KDE, > Gnome, and quite a few others, spend vast amounts of time ensuring that > things work well, but largely without the help of revision control in the > ports tree. I'm not proposing we incorporate X.org into CVS (SVN?) or the > like, but perhaps there is a way we could better present the choices > reflected there. That doesn't help users of random tiny software packages, > and I'm not sure anything can, but perhaps we can provide a smoother > incremental maintenance path for some key packages. > > Mind you, ports really isn't my area, so I am at significant risk > speculating in this area. Experience with the base system shows that the > real work is always in the details, and hardly ever in the big ideas, and > so only by truly implementing a system and trying it out can you determine > whether it really works in practice. It's easy to wave ones hands at a > high level (as I've done), but it's the proof-of-concept that matters. I think a large part of the shortcomings of the ports infrastructure when it comes to security releases could be mitigated if there was a rapid building and availability of packages on FTP mirrors to prevent everyone from doing "portupgrade -P" and then having to wait for the build as the packages don't show up for days, and people can't wait that long for the fix. I know a discussion was recently started about package distribution and how to address its shortcomings and hopefully the need for rapid security package distribution will be taken into account Regards, Gary ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Areca Raid 6 ARC-1231 Raid 6 Slow LS Listing Performance on large directory
At 01:32 PM 6/11/2008, Paul wrote: Any ideas why it takes so long for this on Freebsd 7.0 stable? The partition this folder is on it /dev/da0s1f with a total size of 1.7T and a usage of 63G Any suggestions or help on this would be greatly appreciated. Couple of things to check In /etc/nsswitch.conf try changing to group: files passwd: files and check to make sure vfs.ufs.dirhash_maxmem is > than vfs.ufs.dirhash_mem. If vfs.ufs.dirhash_mem is hit the max, increase the maxmem value ---Mike ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: CLARITY re: challenge: end of life for 6.2 is premature withbuggy 6.3
On Wed, 11 Jun 2008, Paul Schmehl wrote: From a security standport, backporting fixes to previous versions of ports creates a difficulty. It's much harder to tell, for example, if a RedHat "port" is vulnerable or not, because RedHat uses their own proprietary versioning system to define "where" a particular "port" is at. So, while your system might *say* it's running php version 5.2, it's really *not* vulnerable because in RedHatese it's version 5.2.1.6.92000.p-2.1 (I'm just making that up.) If this idea ever gets off the ground, I *hope* the folks involved with find a rational, logical way to define the versioning so that it's not hieroglyphics to the average person. I hope not to offend the ports folks in saying this, but it seems clear to me that the narrower scope and better-defined components of the base system have (over time) lead to a much easier incremental upgrade path than ports and packages. It's not clear to me how you could apply the same level of attention to something as large as the ports collection, except perhaps to select a subset of ports you care "more" about, and provide a higher quality of service for them. In effect, try to find a semantically richer middle ground between "it's someone else's problem, our role is primarily to bundle" and "it's entirely our problem and in revision control". We already do this for some ports, in that the people involved in adapting and maintaining some of the larger/more critical parts, such as X.org, KDE, Gnome, and quite a few others, spend vast amounts of time ensuring that things work well, but largely without the help of revision control in the ports tree. I'm not proposing we incorporate X.org into CVS (SVN?) or the like, but perhaps there is a way we could better present the choices reflected there. That doesn't help users of random tiny software packages, and I'm not sure anything can, but perhaps we can provide a smoother incremental maintenance path for some key packages. Mind you, ports really isn't my area, so I am at significant risk speculating in this area. Experience with the base system shows that the real work is always in the details, and hardly ever in the big ideas, and so only by truly implementing a system and trying it out can you determine whether it really works in practice. It's easy to wave ones hands at a high level (as I've done), but it's the proof-of-concept that matters. Robert N M Watson Computer Laboratory University of Cambridge ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: CLARITY re: challenge: end of life for 6.2 is premature withbuggy 6.3
--On Wednesday, June 11, 2008 16:54:02 +0100 Robert Watson <[EMAIL PROTECTED]> wrote: On Wed, 11 Jun 2008, Andy Kosela wrote: Redhat/CentOS is more reliable here as backports involves both security and bug fixes, plus even new hardware enhancements. In the FreeBSD environment, we call the place that gets a blend of security and bug fixes, plus new minor feature and driver enhancements "-STABLE", and the releases that pick up these changes "point releases". They happen more requently and with less risk than major releases, but still see enough development to represent functional improvements. I guess here's my concern: we offer a spectrum of choice for "I want the most bleeding edge" to "I want no feature changes, just security fixes", and several points in between. We can argue about the exact placement of this points, but the reality is that the balance we have today seems to work well for many developers and users, and reflects a fairly carefully planned use of the available revision control and distribution technology. The place for volunteers to come in is where they see an obvious niche for improvement -- for example, a few years ago this guy named Colin Percival turned up with a binary update system. After a couple of years of enhancement, breaking it in, etc, it's now a standard tool for maintaining FreeBSD systems, and he's our security officer. Similar opportunities exist for offering easier updates to packages, etc, but require people who have a clear need and the technical ability to do the work to turn up and do it. From a security standport, backporting fixes to previous versions of ports creates a difficulty. It's much harder to tell, for example, if a RedHat "port" is vulnerable or not, because RedHat uses their own proprietary versioning system to define "where" a particular "port" is at. So, while your system might *say* it's running php version 5.2, it's really *not* vulnerable because in RedHatese it's version 5.2.1.6.92000.p-2.1 (I'm just making that up.) If this idea ever gets off the ground, I *hope* the folks involved with find a rational, logical way to define the versioning so that it's not hieroglyphics to the average person. -- Paul Schmehl As if it wasn't already obvious, my opinions are my own and not those of my employer. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Areca Raid 6 ARC-1231 Raid 6 Slow LS Listing Performance on large directory
Hello, I have a RAID-6 Partition with the Areca ARC-1231 card on a S5000PAL Intel system with 6 disks as part of the raid volume. The system has been set up as Write-back cache and the raid card has a 2 GIG memory cache on it. It is installed on Freebsd 7.0 STABLE with SCHED_ULE enabled. I have a folder with a lot of small and big files in it that total 3009 files. In the user system we have 2200 users in the password file. 1) When I do a ls -lh on the raid 6 array with 6 disks in the array it takes aver 16 seconds before it starts to display anything on the screen. 2) While running a tar command on another shell, the time goes to 28 seconds for the same list to start showing. 3) When I do a ls (with no other options) it starts to list right away. 4) When I do a ls -ln it displays right away as well pointing to the slowdown being the mapping of the users in the db lookup. I have the same directory with the same number of files on a Raid 5 SCSI partition on Freebsd 4.X and it only takes 2 seconds to start displaying the list with the command ls -lh. Any ideas why it takes so long for this on Freebsd 7.0 stable? The partition this folder is on it /dev/da0s1f with a total size of 1.7T and a usage of 63G Any suggestions or help on this would be greatly appreciated. Thanks, Paul ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD 7 and Apache 1.3.41 PROBLEM
In httpd-error.log [Wed Jun 11 17:01:04 2008] [info] mod_unique_id: using ip addr 10.10.10.10 [Wed Jun 11 17:01:05 2008] [info] (2)No such file or directory: make_sock: for port 80, setsockopt: (SO_ACCEPTFILTER) [Wed Jun 11 17:01:05 2008] [warn] pid file /var/run/httpd.pid overwritten -- Unclean shutdown of previous Apache run? After hashing out #LoadModule unique_id_module libexec/apache/mod_unique_id.so #AddModule mod_unique_id.c Apache starts normally Can anyone explain this? are you sure you use the same apache version as with 6.*? ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Vlan EVENT patch
On Wed, Jun 11, 2008 at 12:33 AM, Pyun YongHyeon <[EMAIL PROTECTED]> wrote: > On Tue, Jun 10, 2008 at 09:51:53AM -0700, Jack Vogel wrote: > > This is a small patch that Sam came up with for me, it will allow > > drivers to know > > when a vlan attaches. > > > > It is transparent to any code that doesn't want to change, but this > > will allow my > > drivers to finally utilize the vlan hardware filter (something Linux has > had for > > ever but we lacked). > > > > Just curious, is there any rule how to use that new capability? > Because drivers will receive events whenever VLAN tags are > added/removed they would know how to act for these events. If > promiscuous mode is on for interface, driver should not filter any > VLAN tagged frames, right? > If users want to disable VLAN hardware filtering feature what is > best way to perform this? Introducing a new flag like > IFCAP_VLAN_HWFILT or add a new sysctl that control this feature? > I guess VIA Rhine III also have VLAN hardware filtering capability > so it would be even better if we have a way to share common part. All the patch does is have the vlan driver generate events when it attaches or detaches from a NIC, there are no rules, however I can tell you what I'm coding into this in the Intel drivers. The way it works is the driver registers a callback for each event, I will call that [igb,em,ixgbe]_register_vlan(), and unregister obviously. Right now, the drivers just generically enable VLAN capability because there is never a trigger to know IF and WHEN you need to do so, but with this change the VLAN capability will only get turned on by the registration routine. Most significantly, now when the pseudo device it gives the driver the VLAN tag, this will mean the driver will be able from the start to use the VFTA, the hardware filter, for each vlan attach the driver will add the ID into this table. The unregister event will turn the table entry off, and if this is the last VLAN being detached it will then disable the features. Oh yes, these routines will also take care of the size change of the frame due to the tag. I already have the changes in place in the igb drive, and they are working great. I do not understand why you think you need a flag to disable this, yes it could be done, but why? If you need to do some sort of debugging won't a system not using vlans and in promiscuous mode do just fine? It just seems to violate the whole reason for doing vlans in the first place, however perhaps I am missing something? I do not believe the Linux driver has some way to disable use of the table but I'll double check on that. Remember, this change requires NO driver changes unless they wish to take advantage of the ability. Cheers, Jack ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD 7 and Apache 1.3.41 PROBLEM
On Wed, Jun 11, 2008 at 08:54:20AM -0700, Jeremy Chadwick wrote: > The problem in your error logs indicate some sort of issue relating to > the accept filter in FreeBSD, which Apache can use (accf_http). > > I don't think Apache 1.3.x has this functionality (rc-script-wise) It has. Eugene Grosbein ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: CLARITY re: challenge: end of life for 6.2 is premature withbuggy6.3
On Wed, 11 Jun 2008 16:54:02 +0100 (BST), Robert Watson <[EMAIL PROTECTED]> wrote: > The place for volunteers to come in is where they see an obvious niche for > improvement -- for example, a few years ago this guy named Colin Percival > turned up with a binary update system. After a couple of years of > enhancement, breaking it in, etc, it's now a standard tool for maintaining > FreeBSD systems, and he's our security officer. Similar opportunities > exist > for offering easier updates to packages, etc, but require people who have > a > clear need and the technical ability to do the work to turn up and do it. > Very Well Spoken! :) Fact is, that it's okay to ask about a security branch for ports/packages. And if the answer is, no, we don't have enough manpower, then the road is clear. Either throw loads of money around you, or start doing it yourself and see wether someone hops on :) Cheers, ./Marian ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: CLARITY re: challenge: end of life for 6.2 is prematurewithbuggy 6.3
On Wed, 11 Jun 2008 18:50:57 +0300, Anton - Valqk <[EMAIL PROTECTED]> wrote: > Thanks for the answer! > I'm glad someone answered me a human way, > because two times before, I wasn't answered that way > (well... my posts were angry and incomplete but...that's why i didn't > continued to post...my bad). > Well then, lets continue answering in a human way. Which is, funnily enough, usually the more productive way too ;-) > now on topic: > yeah! >> Thats unfortunatly true. >> But there is a way around. As soon as you have several FreeBSD boxes, > I'd >> advise you to install your own FreeBSD box for packages building. >> So if you need to update your php installations, go to your build box >> (which has the very same versions of programs installed as your > production >> boxes), update your ports tree and do a "make package" of your new php >> port. >> If the new php package works fine on your build box, roll it out via >> "pkg_add -r $NEWPHPTHINGY" and off you go. >> >> > I do have a build server(well a jail but works for me), also I have test > eviornment (jailed too). > I use this jail to build all my pkgs and use pkg_add -r (sweeet!!). > For most of the ports this works, but sometimes something in make > package breaks and i get a port installed partially > (last case - apache22 got installed but no /usr/local/etc/rc.d/apache22 > rc script, previous - pg_ctl never got installed) > and in +CONTENTS file the missing files claimed to be there. hm... sounds like a bug to me. On the other hand, you have to try to get it to be reproducable. If it's a one timer then yes, it's annoying, but really really hard to reproduce and therefor to fix. > I've had to rebuild that kind of port so I can install it again (after > pkg_delete) to have the port working. yeah, annoying. > This happens most often when I do make install package-recursive (so I > can get all needed ports installed). If you can reproduce it step by step, it may be worth posting to ports@ again with what you did and what happened. Either you're doing something wrong, or something is broken. However, it needs to be reproducable. At least in your environment. As a starter, so to say :) The more detailed your steps are written down, the more likely someone will either follow those steps or give you a direct hint on "humm, could be something bad over there... hm hm). > Another strange thing is that when I use php-extensions to build all > that I need (this takes most of my time when build/install new php) > breaks because of the ?'bug'? described few lines above. as I said noone > got interested in this problem... I can't say anything specific about the php problem you said. I'm not using php, or well, very rarely. I'll give it a try to update it the make package way next time. Unluckily this is a one-box only system. hmmm... If I find the time to test, I'll drop you mail. But time is rare (admin life vs. normal life). To cut that short: Yeah, I can understand that this is annoying. But I'm sure as hell: - if it's a bug it can be fixed - if it's a user error, it can be changed - and all this has happened to me when trying to build my own debian packages too ;) And it happened to me with Gentoo, too. Nothing new at all. Just the regular annoyances in sysadmins life. IMO :) >>> Another _very important_ thing is that there is no binary support to >>> packages that has vulns, >>> and you have to rebuild them from ports. >>> >>> >> Well, its one time doing a make package... >> Even debian has no plus point there (at least in our environment at > work). >> We pretty much always need our Apache 2 custom build, not the way the >> Debian projects build it. Thus we have a Debian build box around and > build >> our own Apache 2.2 package. >> This is, indeed, the same amount of effort you would have when using >> FreeBSD. >> IMO the overhead in Debian to build a package is higher than in FreeBSD, >> but YMMV. >> > If you build packages from source then debian just sux (much more > complex and long procedure), but there is a tell - "if you do it with > debian - do it THE DEBIAN WAY"... :-). I am doing it the debian way. Using the debian source package and try to update from there. Still its a more complex procedure then upgrading a FreeBSD port. I just can't use the prebuilt debian packages. So where's the Debian way from that point?! > I totally agree with that, but on all debian machines I use packages > provided from debian, because they've made it very modular, > and I was able to config them the way I need and everything is working > for me. You're lucky then :) > In 99.99% of the cases when I do apt-get dist-upgrade the machine works > like a charm after it, and that's a fact (in fbsd when make installworld > too, but not for ports - which is the focus here). Right. One should never mix up, that Debian is, well, a kernel and a whole lot of software, whereas in FreeBSD you really have a line between the base OS and later installed software (ports).
Re: apachectl gracefult causes Signal 11 crash after 6.3 to 7.0 upgrade [SOLVED]
On Wed, Jun 11, 2008 at 05:51:20PM +0200, Jordi Espasa Clofent wrote: > It seems a php-extensions bug. > If you comment the mhash.so in /usr/local/etc/php/extensions.ini as: > > ;entension=mhash.so > > all works fine and you don't get anymore httpd crash (signal 11) if you > use 'apachectl graceful'. > > Maybe will be a good idea to open PR for this? > > I hope it helps someone (I'm very surprised that this isn't a > documented bug in 7.0 yet) Many people have reported that the *order* of the extensions in extensions.ini has adverse (positive) effects on PHP segfaults on FreeBSD. I myself haven't ever run into extension ordering issues like those described (and we've done hosting for years), but I don't doubt those who have experienced such. -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: apachectl gracefult causes Signal 11 crash after 6.3 to 7.0 upgrade [SOLVED]
It seems a php-extensions bug. If you comment the mhash.so in /usr/local/etc/php/extensions.ini as: ;entension=mhash.so all works fine and you don't get anymore httpd crash (signal 11) if you use 'apachectl graceful'. Maybe will be a good idea to open PR for this? I hope it helps someone (I'm very surprised that this isn't a documented bug in 7.0 yet) -- Thanks, Jordi Espasa Clofent ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD 7 and Apache 1.3.41 PROBLEM
On Wed, Jun 11, 2008 at 05:28:26PM +0200, Jack Raats wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On a server I was running FreeBSD 6.3-STABLE together with apache 1.3.41 > without any problem. > > After upgrading FreeBSD to FreeBSD 7.0-STABLE using a source upgrade, > compiling, and a full recompile of all the ports apache refuses to start, or > starts and exits with a .core dump. > > In httpd-error.log > [Wed Jun 11 17:01:04 2008] [info] mod_unique_id: using ip addr 10.10.10.10 > [Wed Jun 11 17:01:05 2008] [info] (2)No such file or directory: make_sock: > for port 80, setsockopt: (SO_ACCEPTFILTER) > [Wed Jun 11 17:01:05 2008] [warn] pid file /var/run/httpd.pid overwritten -- > Unclean shutdown of previous Apache run? > > After hashing out > #LoadModule unique_id_module libexec/apache/mod_unique_id.so > #AddModule mod_unique_id.c > > Apache starts normally > > Can anyone explain this? If by "this" you're referring to the setsockopt() error, yes. If by "this" you're referring to the coredump, no, not without more information. The problem in your error logs indicate some sort of issue relating to the accept filter in FreeBSD, which Apache can use (accf_http). I don't think Apache 1.3.x has this functionality (rc-script-wise), but on 2.2.x on RELENG_6, we use this in rc.conf to load the accept module prior to Apache starting: apache22_http_accept_enable="yes" You can try loading the module yourself using "kldload accf_http.ko", then restarting (stop/start, not graceful or restart!) Apache. P.S. -- I've removed freebsd-questions@ from the CC, since cross- posting is looked down upon. -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: CLARITY re: challenge: end of life for 6.2 is premature withbuggy 6.3
On Wed, 11 Jun 2008, Andy Kosela wrote: Redhat/CentOS is more reliable here as backports involves both security and bug fixes, plus even new hardware enhancements. In the FreeBSD environment, we call the place that gets a blend of security and bug fixes, plus new minor feature and driver enhancements "-STABLE", and the releases that pick up these changes "point releases". They happen more requently and with less risk than major releases, but still see enough development to represent functional improvements. I guess here's my concern: we offer a spectrum of choice for "I want the most bleeding edge" to "I want no feature changes, just security fixes", and several points in between. We can argue about the exact placement of this points, but the reality is that the balance we have today seems to work well for many developers and users, and reflects a fairly carefully planned use of the available revision control and distribution technology. The place for volunteers to come in is where they see an obvious niche for improvement -- for example, a few years ago this guy named Colin Percival turned up with a binary update system. After a couple of years of enhancement, breaking it in, etc, it's now a standard tool for maintaining FreeBSD systems, and he's our security officer. Similar opportunities exist for offering easier updates to packages, etc, but require people who have a clear need and the technical ability to do the work to turn up and do it. Robert N M Watson Computer Laboratory University of Cambridge ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: CLARITY re: challenge: end of life for 6.2 is premature withbuggy 6.3
Thanks for the answer! I'm glad someone answered me a human way, because two times before, I wasn't answered that way (well... my posts were angry and incomplete but...that's why i didn't continued to post...my bad). now on topic: Marian Hettwer wrote: Hi there, some thoughts to your problem in regards to Debian administration time needed vs. FreeBSD administration time needed. I believe I can make a point there, since I have 600 debian boxes under my hood but still am a FreeBSD advocate ;-) On Wed, 11 Jun 2008 12:53:02 +0300, Anton - Valqk <[EMAIL PROTECTED]> wrote: My main drama with FreeBSD is that ports don't have -SECURITY patches, and if I there is a bug in php I have to rerbuild and populate the latest version. Thats unfortunatly true. But there is a way around. As soon as you have several FreeBSD boxes, I'd advise you to install your own FreeBSD box for packages building. So if you need to update your php installations, go to your build box (which has the very same versions of programs installed as your production boxes), update your ports tree and do a "make package" of your new php port. If the new php package works fine on your build box, roll it out via "pkg_add -r $NEWPHPTHINGY" and off you go. I do have a build server(well a jail but works for me), also I have test eviornment (jailed too). I use this jail to build all my pkgs and use pkg_add -r (sweeet!!). For most of the ports this works, but sometimes something in make package breaks and i get a port installed partially (last case - apache22 got installed but no /usr/local/etc/rc.d/apache22 rc script, previous - pg_ctl never got installed) and in +CONTENTS file the missing files claimed to be there. I've had to rebuild that kind of port so I can install it again (after pkg_delete) to have the port working. This happens most often when I do make install package-recursive (so I can get all needed ports installed). I've tried to tell this in ports@ and I was answered that "everything is working for us" or kind of. no one tried to investigate... Another strange thing is that when I use php-extensions to build all that I need (this takes most of my time when build/install new php) breaks because of the ?'bug'? described few lines above. as I said noone got interested in this problem... I have another complain from fbsd but I'll tell about it at the end. Another _very important_ thing is that there is no binary support to packages that has vulns, and you have to rebuild them from ports. Well, its one time doing a make package... Even debian has no plus point there (at least in our environment at work). We pretty much always need our Apache 2 custom build, not the way the Debian projects build it. Thus we have a Debian build box around and build our own Apache 2.2 package. This is, indeed, the same amount of effort you would have when using FreeBSD. IMO the overhead in Debian to build a package is higher than in FreeBSD, but YMMV. If you build packages from source then debian just sux (much more complex and long procedure), but there is a tell - "if you do it with debian - do it THE DEBIAN WAY"... :-). I totally agree with that, but on all debian machines I use packages provided from debian, because they've made it very modular, and I was able to config them the way I need and everything is working for me. In 99.99% of the cases when I do apt-get dist-upgrade the machine works like a charm after it, and that's a fact (in fbsd when make installworld too, but not for ports - which is the focus here). Actually that's what *BSD prouds with - building everything from source (like gentoo), well it's a must to be simplified then (debian where everything is supposed to be used from bin .deb) :). About the bug fixes, I think if that's a SECURITY backport it shouldn't fix bugs, because I've saw few devs deploying an app and the were using 'known bug' in ruby to work with. so they were unable to use higher version of ruby that got this bug fixed. (we'll obviously a developer mistake in design but if it's in a production will take months to redesign - not an option). Which is why maybe it's better not to fix bugs but just vulns in SECURITY backports (according to me of course) - if you need that bug fixed, then install new version. Just a simple example: I have 4-5 fbsd machines and about 15-20 debian stable machines. To administer fbsd machines when there are ports bugs(bugs in ports I use) it takes me at least about 4times more time than update _all_ debian machines... depends on the way you go. Genereally speaking, you really really want a build and test machine before you deploy a security update or even a new version of your software (in this case: php). Even with Debian boxes you really shouldn't just "apt-get upgrade && apt-get update" but test before! Well...I have other things to do too, too many... now guess what I will choose? I'll use debian, and that's not because
Re: CLARITY re: challenge: end of life for 6.2 is premature with buggy 6.3
On Wed, 11 Jun 2008, Anton - Valqk wrote: I fully agree with the lines below. As noticed below there is more attention to developing new features, than making releases rock solid stable. ... Ah, another thing, I'm waiting for virtualization networking layer for jails for quite long. I've tested it on a test server, worked perfect, but on production I don't want to patch my base. there are few other features to jals that never got commited in base, and as I said I don't want to patch it... The reason that the virtualization patches aren't in the tree is precisely *because* we care about stability and are willing to slow down feature development in order to accomplish it. Some features take years to stabilize, and just because a patch works OK in your environment doesn't mean it will work in everyone's. Moderating the rate at which we adopt agressive new features is part of an intentional strategy to avoid letting development trees destabilize to a point where it's unproductive. Robert N M Watson Computer Laboratory University of Cambridge ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
FreeBSD 7 and Apache 1.3.41 PROBLEM
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On a server I was running FreeBSD 6.3-STABLE together with apache 1.3.41 without any problem. After upgrading FreeBSD to FreeBSD 7.0-STABLE using a source upgrade, compiling, and a full recompile of all the ports apache refuses to start, or starts and exits with a .core dump. In httpd-error.log [Wed Jun 11 17:01:04 2008] [info] mod_unique_id: using ip addr 10.10.10.10 [Wed Jun 11 17:01:05 2008] [info] (2)No such file or directory: make_sock: for port 80, setsockopt: (SO_ACCEPTFILTER) [Wed Jun 11 17:01:05 2008] [warn] pid file /var/run/httpd.pid overwritten -- Unclean shutdown of previous Apache run? After hashing out #LoadModule unique_id_module libexec/apache/mod_unique_id.so #AddModule mod_unique_id.c Apache starts normally Can anyone explain this? Jack -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (MingW32) - GPGrelay v0.959 iD8DBQFIT+8bPh5RwW/NzC4RAn9aAKCVKIvHFmFzpeaveqvHYbXjIRrhuACg0vxr f5f3FDGYigHPRaqGz+ZkDok= =TZvG -END PGP SIGNATURE- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: broken re(4)
On Wed, 11 Jun 2008 17:26:29 +0200 (CEST) Oliver Fromme <[EMAIL PROTECTED]> wrote about Re: broken re(4): OF> > On the other hand, I have not been able to get more than about OF> > 10MByte/s through the interfaces of this particular system. I have OF> > 1GBit-networking equipment, and the other systems (which are used OF> > as router) have no problem doing a throughput of >20MB/s. Even OF> > bonding the two interfaces using lagg(4) does not improve the OF> > performance - where else could be the bottleneck? OF> A few questions or hints ... OF> - What is the CPU usage during your network test (user, OF>sys, intr, idle)? I will test and report that tomorrow. OF> - Do you see errors in "netstat -i"? None. OF> - Do you use jumbo frames? No. OF> - Is polling enabled? No. I tested polling on a lot of different machines earlier and never found it to improve performance so far (same for jumbo frames, btw). OF> - Are there any network-related sysctls (/etc/sysctl.conf) OF>or kernel settings? Have you enabled kernel debugging OF>features (INVARIANTS, WITNESS etc.)? No, stock GENERIC, only with a lot of things disabled. OF> - Do you have any packet filter rules (PF, IPF, IPFW)? No, not on this machine. The faster machines are router/firewalls, they do filtering; so it should be something different... cu Gerrit ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: broken re(4)
Gerrit Kühn wrote: > On the other hand, I have not been able to get more than about 10MByte/s > through the interfaces of this particular system. I have 1GBit-networking > equipment, and the other systems (which are used as router) have no > problem doing a throughput of >20MB/s. Even bonding the two interfaces > using lagg(4) does not improve the performance - where else could be the > bottleneck? A few questions or hints ... - What is the CPU usage during your network test (user, sys, intr, idle)? - Do you see errors in "netstat -i"? - Do you use jumbo frames? - Is polling enabled? - Are there any network-related sysctls (/etc/sysctl.conf) or kernel settings? Have you enabled kernel debugging features (INVARIANTS, WITNESS etc.)? - Do you have any packet filter rules (PF, IPF, IPFW)? Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd "C++ is the only current language making COBOL look good." -- Bertrand Meyer ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: CLARITY re: challenge: end of life for 6.2 is premature withbuggy 6.3
Robert, Thank you for your insights. I think that this agreement between users and developers does occur. The proper balance between rapid development vs long term stability is the platform through which such agreement can be achieved. It's up to the Core Team to reasonably steer the Project in such a way as to achieve the greatest results. FreeBSD has always been focused on creating simple, stable and reliable operating system for system administrators and let's keep it that way. Longer term support for -RELEASE gives many companies a stable platform to develop and maintain their infrastructure. I think 5 years support for major FreeBSD release (like major 6 or 7) would be really perfect for many of us. On Wed, Jun 11, 2008 at 1:26 PM, Marian Hettwer <[EMAIL PROTECTED]> wrote: > But there is a way around. As soon as you have several FreeBSD boxes, I'd > advise you to install your own FreeBSD box for packages building. > So if you need to update your php installations, go to your build box > (which has the very same versions of programs installed as your production > boxes), update your ports tree and do a "make package" of your new php > port. > If the new php package works fine on your build box, roll it out via > "pkg_add -r $NEWPHPTHINGY" and off you go. I think Anton raised a valid and reasonable point here by analyzing my previous statements. Every data center environment test the upgrade process before deploying it on production machines, but my point circulated around the whole different theme. Backporting Backporting security and bug fixes to *STABLE* versions of ports would definetly render the whole ports framework infrastructure more solid and trustworthy for organizations that need mission critical stable and reliable environment to work in. Creating -SECURITY branch of ports tree with support *just* for common server applications like apache, postfix, mysql or vsftpd (definetly not for all available ports) would very well encourage more companies now stuck with the only alternative (redhat/centos or debian) to trust this ports tree branch in deploying their applications which very often needs specific versions of the software to run properly. Right now it's sometimes very risky to jump to the latest available upstream version as it very often breaks compatibility with older versions. I've been toying with the idea to create such -SECURITY branch, at least just for ports I use extensively. I'm not aware of no such project (open source, commercial) that is doing that. I'm curious how many people out there would be also interested in such an idea. > If you take a close look onto how the debian project is backporting > security fixes you would probably agree that pretty often it's more > desireable to jump to a newer version of that software than instead just > security fixing it. > Examples needed? > MySQL 4.1.11 was the "stable" MySQL 4.1 in Debian Sarge. Of course it got > security fixed, but not bugfixed. You get a secure version of MySQL 4.1 in > Debian but not a stable one, because important bugfixes are missing. > I'd rather upgrade to the latest MySQL 4.1.xx instead. > And of course, do your testing before jumping version numbers. Redhat/CentOS is more reliable here as backports involves both security and bug fixes, plus even new hardware enhancements. -- Andy Kosela ora et labora ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: CLARITY re: challenge: end of life for 6.2 is premature withbuggy 6.3
Hi there, some thoughts to your problem in regards to Debian administration time needed vs. FreeBSD administration time needed. I believe I can make a point there, since I have 600 debian boxes under my hood but still am a FreeBSD advocate ;-) On Wed, 11 Jun 2008 12:53:02 +0300, Anton - Valqk <[EMAIL PROTECTED]> wrote: > > My main drama with FreeBSD is that ports don't have -SECURITY patches, > and if I there is a bug in php > I have to rerbuild and populate the latest version. Thats unfortunatly true. But there is a way around. As soon as you have several FreeBSD boxes, I'd advise you to install your own FreeBSD box for packages building. So if you need to update your php installations, go to your build box (which has the very same versions of programs installed as your production boxes), update your ports tree and do a "make package" of your new php port. If the new php package works fine on your build box, roll it out via "pkg_add -r $NEWPHPTHINGY" and off you go. > Another _very important_ thing is that there is no binary support to > packages that has vulns, > and you have to rebuild them from ports. > Well, its one time doing a make package... Even debian has no plus point there (at least in our environment at work). We pretty much always need our Apache 2 custom build, not the way the Debian projects build it. Thus we have a Debian build box around and build our own Apache 2.2 package. This is, indeed, the same amount of effort you would have when using FreeBSD. IMO the overhead in Debian to build a package is higher than in FreeBSD, but YMMV. > Just a simple example: > I have 4-5 fbsd machines and about 15-20 debian stable machines. > To administer fbsd machines when there are ports bugs(bugs in ports I > use) it takes me at > least about 4times more time than update _all_ debian machines... depends on the way you go. Genereally speaking, you really really want a build and test machine before you deploy a security update or even a new version of your software (in this case: php). Even with Debian boxes you really shouldn't just "apt-get upgrade && apt-get update" but test before! > Well...I have other things to do too, too many... now guess what I will > choose? > I'll use debian, and that's not because I don't have will to use > freebsd, it's simply because I do my tasks 4 times slower than when I > choose debian. hhmm... I really can't agree on that statement. If you do your admin work in a clean and sane way, most of the time spend for updating boxes is spent on testing the change before upgrading. The difference between a "debuild" for building a new package, and then apt-get upgrade / update them on your box vs. "make package" and pkg_add -r them on your box is really slim... > Someone will say "FreeBSD is not for you, then back off". That's not the I wouldn't say that :) > > Once I've told that there is no binary support (but I didn't expressed > myself correctly). There is no ports VULNS binary support. > If there is (and I've never heard of it), I'll be very happy someone to > point me out this, because I'll continue running fbsd. > If you take a close look onto how the debian project is backporting security fixes you would probably agree that pretty often it's more desireable to jump to a newer version of that software than instead just security fixing it. Examples needed? MySQL 4.1.11 was the "stable" MySQL 4.1 in Debian Sarge. Of course it got security fixed, but not bugfixed. You get a secure version of MySQL 4.1 in Debian but not a stable one, because important bugfixes are missing. I'd rather upgrade to the latest MySQL 4.1.xx instead. And of course, do your testing before jumping version numbers. I hope that my impressions will help you in working with FreeBSD in a server environment. Cheerio, Marian ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: CLARITY re: challenge: end of life for 6.2 is premature with buggy 6.3
Just my 5cents (some thoughts), I fully agree with the lines below. As noticed below there is more attention to developing new features, than making releases rock solid stable. As mentioned in reply posts the 3 branches 6.X 7.X and 8.X takes too many resources and is very hard to support. I, personally, will be waiting for 7.2 release (noticed that .2 over few (3-4 years)) are most stable ones. My main drama with FreeBSD is that ports don't have -SECURITY patches, and if I there is a bug in php I have to rerbuild and populate the latest version. Another _very important_ thing is that there is no binary support to packages that has vulns, and you have to rebuild them from ports. Just a simple example: I have 4-5 fbsd machines and about 15-20 debian stable machines. To administer fbsd machines when there are ports bugs(bugs in ports I use) it takes me at least about 4times more time than update _all_ debian machines... Well...I have other things to do too, too many... now guess what I will choose? I'll use debian, and that's not because I don't have will to use freebsd, it's simply because I do my tasks 4 times slower than when I choose debian. Someone will say "FreeBSD is not for you, then back off". That's not the point, I like fbsd, but as more busy I get, as less I'll be able to use it, takes too much of my time. Once I've told that there is no binary support (but I didn't expressed myself correctly). There is no ports VULNS binary support. If there is (and I've never heard of it), I'll be very happy someone to point me out this, because I'll continue running fbsd. Ah, another thing, I'm waiting for virtualization networking layer for jails for quite long. I've tested it on a test server, worked perfect, but on production I don't want to patch my base. there are few other features to jals that never got commited in base, and as I said I don't want to patch it... in linux (debian for me) there is xen that works with 'new' intel hardware virtualization, that's another red point for debian there are other things that I'll leave unsaidso... that's all for now. sorry for my bad english, it's not my native. these are just my thoughts and don't want to force anyone to agree with them, but I'll be happy to read your thoughts on this. cheers, valqk. Andy Kosela wrote: On 6/8/08, Freddie Cash wrote: On 6/7/08, Jo Rhett wrote: The question I raised is simply: given the number of bugs opened and fixed since 6.3-RELEASE shipped, why is 6.3 the only supported version? Why does it make sense for FreeBSD to stop supporting a stable version and force people to choose between two different unstable versions? Is this really the right thing to do? Define the terms "stable" and "unstable", how you measure said "stability" and "instability", and what you are comparing them against. This whole discussion is really interesting as it clearly showcases two common trends in computing (rapid development vs stability) On the one side we got people (let's call them developers or computer scientists) who are more interested in development than stabilization of the existing code base. It's natural for them to think more about new features, researching new ideas and implementing them. It resembles an academic project, research project.Those computer scientists do not care much about stability, they are mainly interested in hacking on the code for the fun of it. It is open source after all as someone wisely remarked. From my own experience most if not all community based projects are more interested in following this trend than stabilization of the code. Although they do care about stability of their code base, their focus is more on implementing new features and moving rapidly forward. In today's quickly changing world we see this trend as prevailing. On the other hand though, there is a trend which focuses on maximum long term stabilization of the code base. Usually we see this trend in high end commercial companies serving the needs of mission critical businesses where even a minute of downtime can cause loss of thousands of dollars or even loss of lives of people (imagine stock exchanges, banks, financial & insurance institutions, army and police facilities, hospitals, nuclear plants etc.). Those types of businesses/institutions truly needs a maximum stable operating system. They really do not care about "new features", but they do care about maximum stability of the existing code, security, and nonstop business continuity even in the face of natural disasters. There is only one operating system I know of that survived 9/11 attacks - this is OpenVMS. It's not uncommon to see VMS uptimes of more than 10 years (you can ask Amsterdam police for evidence). Now that is a true stability! On the other note though, stability is the direct opposition of development and change. Something which is *stable* cannot change or must change very slowly in the long term. On the othe
Re: Crashes in devfs. Possibly on interface creation/destruction.
Kostik Belousov wrote: > Try the following patch. It is against current, there might be further > races at the device destruction, but may be not. Also, please note that > devfs in RELENG_6 and RELENG_7/CURRENT are diverged enough to make MFC > of most bugfixes to RELENG_6 nearly impossible. > > diff --git a/sys/kern/kern_conf.c b/sys/kern/kern_conf.c > index e9d0f7b..af9a47d 100644 > --- a/sys/kern/kern_conf.c > +++ b/sys/kern/kern_conf.c > @@ -825,9 +825,9 @@ make_dev_alias(struct cdev *pdev, const char *fmt, ...) > va_end(ap); > > devfs_create(dev); > + dev_dependsl(pdev, dev); > clean_unrhdrl(devfs_inos); > dev_unlock(); > - dev_depends(pdev, dev); > > notify_create(dev); Looks reasonable. For RELENG_6 it also applies with minor differences. Put it to the production. As soon as problem shows itself not very often, positive result probably will be seen only after several weeks of successive operation. Thank you. -- Alexander Motin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Vlan EVENT patch
On Tue, Jun 10, 2008 at 09:51:53AM -0700, Jack Vogel wrote: > This is a small patch that Sam came up with for me, it will allow > drivers to know > when a vlan attaches. > > It is transparent to any code that doesn't want to change, but this > will allow my > drivers to finally utilize the vlan hardware filter (something Linux has had > for > ever but we lacked). > Just curious, is there any rule how to use that new capability? Because drivers will receive events whenever VLAN tags are added/removed they would know how to act for these events. If promiscuous mode is on for interface, driver should not filter any VLAN tagged frames, right? If users want to disable VLAN hardware filtering feature what is best way to perform this? Introducing a new flag like IFCAP_VLAN_HWFILT or add a new sysctl that control this feature? I guess VIA Rhine III also have VLAN hardware filtering capability so it would be even better if we have a way to share common part. > My test group has done some basic testing of this and it is working great. > But we wanted to give any vlan users a chance to see, ask questions, or > whatever before its committed. > > Jack -- Regards, Pyun YongHyeon ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: broken re(4)
On Tue, 10 Jun 2008 20:43:04 +0200 Daniele Bastianini <[EMAIL PROTECTED]> wrote about Re: broken re(4): DB> > - copying large files (more than some 100MB) via ssh/scp drops the DB> > connection due to "corrupted MAC on input": DB> > Disconnecting: Corrupted MAC on input. DB> > lost connection DB> I had the same problem. DB> I fixed it (for now) making a buildworld with DB> *default date=2008.03.01.00.00.00 in my src csup configuration. DB> I'm not so skilled to investigate in the sources but the problem is DB> after this date. For me all versions from cvs and all patches from Pyun are working now, after I have solved the issue with the bad riser card. I still think it's funny that the riser causes this kind of trouble for the networking chips. On the other hand, I have not been able to get more than about 10MByte/s through the interfaces of this particular system. I have 1GBit-networking equipment, and the other systems (which are used as router) have no problem doing a throughput of >20MB/s. Even bonding the two interfaces using lagg(4) does not improve the performance - where else could be the bottleneck? The only difference here is that I have the extra SATA-controller with disks in there. However, the disks appear to be as fast as I can expect from a SATA150-interface. cu Gerrit ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
