ipfw nat 1 config not_good_anymore? (FreeBSD 9.0-RC2)
somebody else experience problems with ipfw nat? even the most simple ruleset as ipfw add nat 1 ip from any to any via em0 ipfw nat 1 config if em0 reset ipfw add pass proto ip is not working anymore, funny is the counter of each rule increase (ipfw show) but there is no traffic outgoing on the LAN_IF neither get some to the client machine (yeah, the IFs are up and cable is plugged in :) tcpdump captures 0 (zero) returning traffic on the LAN I can access normally from the machine any destiny on either side of it please don't ask for IPFIREWALL_FORWARD, IPFIREWALL_NAT LIBALIAS and IPDIVERT nor sysctls .. unless there is an undocumented change. thank's HM signature.asc Description: This is a digitally signed message part.
disk access seems unitask and ant-slow
Hi I have 9-Stable on one partition of my SATAII disk, with kde4, to be sure I compiled yesterday sources world and kernel happens that any secondary task with diskaccess is so very slow that it is inacceptable for example, compiling firefox and then trying to open an image with gimp, I am sitting here for over 5 minutes and the open image dialog still do not show the directory content ..., same with dolphin or any other diskaccess I have enough cpu and ram, I go back to 8.2 and everything runs smooth and fast as usual, same on fedora10 partition my disk is good and found as ada, no fault anywhere system is almost sleeping CPU: 2.6% user, 0.0% nice, 3.6% system, 1.3% interrupt, 92.5% idle I would be glad to get any good hint how to change that thank's -- H +55 (17) 4141. signature.asc Description: OpenPGP digital signature
Re: disk access seems unitask and ant-slow
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ronald Klop wrote: > On Sat, 18 Feb 2012 12:44:12 +0100, H wrote: > >> Hi >> >> I have 9-Stable on one partition of my SATAII disk, with kde4, to >> be sure I compiled yesterday sources world and kernel >> >> happens that any secondary task with diskaccess is so very slow >> that it is inacceptable >> >> for example, compiling firefox and then trying to open an image >> with gimp, I am sitting here for over 5 minutes and the open >> image dialog still do not show the directory content ..., same >> with dolphin or any other diskaccess >> >> I have enough cpu and ram, I go back to 8.2 and everything runs >> smooth and fast as usual, same on fedora10 partition >> >> my disk is good and found as ada, no fault anywhere >> >> system is almost sleeping CPU: 2.6% user, 0.0% nice, 3.6% >> system, 1.3% interrupt, 92.5% idle >> >> >> I would be glad to get any good hint how to change that >> >> >> >> thank's > > Please post the output of dmesg so people have some information > about your system. And /etc/sysctl.conf, /boot/loader.conf and the > output of 'mount -v' are interesting also. > > Ronald. thank's for your attention but it would not help and of course, first thing I did was disabling all custom settings, I have no setting which could influence disk access, it's a desktop ... other then loading glabel,sem,tmpfs I do not have no any fancy settings in loader.conf either please don't start on the machine, it runs fine and is ok well, for the piece what you asked for: mount -v /dev/label/root on / (ufs, local, journaled soft-updates) devfs on /dev (devfs, local, multilabel) /dev/label/var on /var (ufs, local, journaled soft-updates) /dev/label/usr on /usr (ufs, local, journaled soft-updates) procfs on /proc (procfs, local) linprocfs on /compat/linux/proc (linprocfs, local) dmesg Copyright (c) 1992-2012 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 9.0-STABLE #8: Fri Feb 17 07:00:02 BRST 2012 h...@pop1.hm.net.br:/usr/obj/usr/src/sys/WIPMINI i386 CPU: AMD Athlon(tm) 64 X2 Dual Core Processor 5000+ (2611.94-MHz 686-class CPU) Origin = "AuthenticAMD" Id = 0x40fb2 Family = f Model = 4b Stepping = 2 Features=0x178bfbff Features2=0x2001 AMD Features=0xea500800 AMD Features2=0x1f real memory = 1073741824 (1024 MB) avail memory = 1030991872 (983 MB) Event timer "LAPIC" quality 400 ACPI APIC Table: <042910 APIC1103> FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs FreeBSD/SMP: 1 package(s) x 2 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 ioapic0 irqs 0-23 on motherboard kbd1 at kbdmux0 cryptosoft0: on motherboard acpi0: <042910 XSDT1103> on motherboard acpi0: Power Button (fixed) acpi0: reservation of fec0, fed4 (3) failed acpi0: reservation of 0, a (3) failed acpi0: reservation of 10, 3ff0 (3) failed Timecounter "ACPI-fast" frequency 3579545 Hz quality 900 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x508-0x50b on acpi0 cpu0: on acpi0 cpu1: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pci0: at device 0.0 (no driver attached) isab0: port 0x900-0x9ff at device 1.0 on pci0 isa0: on isab0 pci0: at device 1.1 (no driver attached) pci0: at device 1.2 (no driver attached) ohci0: mem 0xdfcff000-0xdfcf irq 21 at device 2.0 on pci0 usbus0: on ohci0 ehci0: mem 0xdfcfec00-0xdfcfecff irq 22 at device 2.1 on pci0 usbus1: EHCI version 1.0 usbus1: on ehci0 pcib1: at device 4.0 on pci0 pci1: on pcib1 ath0: mem 0xdfdf-0xdfdf irq 16 at device 6.0 on pci1 ath0: AR5413 mac 10.5 RF5413 phy 6.1 hdac0: mem 0xdfcf8000-0xdfcfbfff irq 23 at device 5.0 on pci0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xffa0-0xffaf at device 6.0 on pci0 ata0: at channel 0 on atapci0 ata1: at channel 1 on atapci0 nfe0: port 0xc480-0xc487 mem 0xdfcfd000-0xdfcfdfff irq 20 at device 7.0 on pci0 miibus0: on nfe0 rlphy0: PHY 1 on miibus0 rlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto, auto-flow nfe0: Ethernet address: 48:5b:39:af:5e:2b atapci1: port 0xc400-0xc407,0xc080-0xc083,0xc000-0xc007,0xbc00-0xbc03,0xb880-0xb88f mem 0xdfcfc000-0xdfcfcfff irq 21 at device 8.0 on pci0 ata2: at channel 0 on atapci1 ata3: at channel 1 on atapci1 pcib2: at device 9.0 on pci0 pci2: on pcib2 vgapci0: port 0xd800-0xd8ff mem 0xc000-0xcfff,0xdfef-0xdfef irq 17 at device 0.0 on pci2 drm0: on vgapci0 info: [drm] MSI enabled 1 message(s) info: [drm] Initialized radeon 1.31.0 20080613 hdac1: mem 0xdfeec000-0xdfee irq 18 a
Re: disk access seems unitask and ant-slow
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Doug Barton wrote:
> First, please don't start a new thread by replying to an existing
> message and changing the subject line. That screws up threading
> for those of us who use threaded mail readers, and may cause your
> message to be ignored.
>
> On 02/18/2012 03:44, H wrote:
>
>> Hi
>
>> I have 9-Stable on one partition of my SATAII disk, with kde4, to
>> be sure I compiled yesterday sources world and kernel
>
>> happens that any secondary task with diskaccess is so very slow
>> that it is inacceptable
>
>> for example, compiling firefox and then trying to open an image
>> with gimp, I am sitting here for over 5 minutes and the open
>> image dialog still do not show the directory content ..., same
>> with dolphin or any other diskaccess
>
> Please try compiling a custom kernel with the 4BSD scheduler
> instead of SCHED_ULE and see if that helps.
>
>
Hi
no idea what you referring to in your "top post" but since we are both
"newcomers" here we're still learning and skip it ok :)
now, 4FBSD really changed for me the face of the system, generally, I
have much better response, thank you for the hint, it is ok now
can you tell if it is worth checking this out on amd64 servers also?
but seems that the principal delay came as present from a pkg
maintainer who dares piping shit into the system config without
telling or asking:
echo 'fusefs_enable="YES"' >> ${LOADER_CONFIG}
fusefs-kmod I'm talking about, where LOADER_CONF is rc.conf for his script
- --
H
+55 (17)4141.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.18 (FreeBSD)
iEYEARECAAYFAk9A+MoACgkQvKVfg5xjCDzsDQCcC5GScZyOc6tFxag5IU5Fy9E2
Vt0AoJAXa23jc+qXJnL2kZV88vdokJVW
=TpKf
-END PGP SIGNATURE-
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: FreeBSD9 and the sheer number of problem reports
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Mark Felder wrote: > On Thu, 23 Feb 2012 12:25:01 -0600, Damien Fleuriot > wrote: > >> >> Now, I find the number of problem reports regarding 9.0-RELEASE >> alarming and I'm growing more and more fearful towards it. > > Then stick with the 8.x train until it's no longer supported. > Also, don't you know the rule about running .0 releases in > production? :) > > 9.0 had LOTS of changes. They were very important. It's going to > take a while for the community to fully absorb them and bugs to be > worked out. We don't have enough testers of -CURRENT to prevent > this. Everything seemed stable (ie, no release blockers) for the > people running -CURRENT and -PRERELEASE, BETAs, and RCs, so it was > released. > > But as always, TEST TEST TEST and please have a proper > staging/test environment before you throw your production into > 9.x. > that is all understandable but the point should not be forgotten ... I mean certainly -RELEASE __is__ the production release so, few testers is no excuse, still more when that is a known issue, so a bigger time frame would be the solution until the var _seemed_stable change into _is_stable of course, that is not always so easy but also think of side effects, few_testers could change into still_less when FreeBSD prove to have unstable releases - -- H -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAk9J83UACgkQvKVfg5xjCDw7ggCfTpMhHuGqetRHUbKmBmCfRMwn d04An3f8UIdfvtee47NYCS+EjqCk+1t7 =fJbU -END PGP SIGNATURE- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: FreeBSD9 and the sheer number of problem reports
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Erich Dollansky wrote: > Hi, > > On Sunday 26 February 2012 15:55:17 H wrote: >> Mark Felder wrote: >>> On Thu, 23 Feb 2012 12:25:01 -0600, Damien Fleuriot >>> wrote: >> >> that is all understandable but the point should not be forgotten >> ... >> >> I mean certainly -RELEASE __is__ the production release > > there is not the production release here. There are always at least > two. whatever, the question is not the how many, it is the word BETA or PRE change to RELEASE and we should not turn this into some word-fiddling important is maintain the understanding for that word, because there are lot of not_developer_people out what seems forgotten is what is here in the second part: http://www.freebsd.org/doc/en_US.ISO8859-1/articles/releng/lessons-learned.html what developers understand, mean or think does not matter, the _user_ should be able to understand and believe in this word RELEASE, what IMO is pretty clear so please do not argument with me or anybody else, it is merely a pretty fair and neutral opinion about RELEASE meaning backed on what is stated on the page above, it seems to be the procedure, which eventually needs revision, because we humans always will fail somewhere H >> >> so, few testers is no excuse, still more when that is a known >> issue, so a bigger time frame would be the solution until the >> var _seemed_stable change into _is_stable > > Stable has here a different meaning. It just means that nothing > will change at the interfaces anymore as long the error is not > hidden there. 5.2 and 5.21 was such an example if I remember > right. >> >> of course, that is not always so easy but also think of side >> effects, few_testers could change into still_less when FreeBSD >> prove to have unstable releases > > No matter what effort you put into testing, you can never achieve > the robustness of an older release. I still have 7.4 running on > one. This can stay until next year. > > So, why do you want to run the latest release on an important > machine? You can, but you are not in a position to complain then. > > Erich - -- H -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAk9KBosACgkQvKVfg5xjCDz/6QCglZ7CI24iBYcicY7X1Qsffdwt 3T8AnA5SVaESL7m3TYCuznJAu2usw9nW =x/DV -END PGP SIGNATURE- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: FreeBSD9 and the sheer number of problem reports
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Erich Dollansky wrote: > Hi, > > On Sunday 26 February 2012 17:16:43 H wrote: >> Erich Dollansky wrote: >>> >>> On Sunday 26 February 2012 15:55:17 H wrote: >>>> Mark Felder wrote: >>>> >>>> I mean certainly -RELEASE __is__ the production release >>> >>> there is not the production release here. There are always at >>> least two. >> >> whatever, the question is not the how many, it is the word BETA >> or PRE change to RELEASE and we should not turn this into some >> word-fiddling >> > it is just logic. 10 is currently ALPHA, 8.3 is currently BETA, > there might be soon a RC1 and the release. > this is going into the wrong direction and I should hold my peace but will say my piece this is about 9.0-RELEASE only and wishfully about future releases, not beta, rc or pre- -current or - -stable ... H >> important is maintain the understanding for that word, because >> there are lot of not_developer_people out > > What should developer do after no errors have been reported anymore > in an RC? I would suggest that they release their stuff. why do you ask? it is very easy to answer: nothing! it is release engineering who could establish a little bit more time between code-freeze and RELEASE as in practice we can see 2-3 month or so would be something reasonable >> >> what seems forgotten is what is here in the second part: >> >> http://www.freebsd.org/doc/en_US.ISO8859-1/articles/releng/lessons-learned.html >> >> >> what developers understand, mean or think does not matter, the _user_ >> should be able to understand and believe in this word RELEASE, >> what IMO is pretty clear >> > Release means that developers either state the errors in the README > or believe that there are no known errors. It does not mean that > there are no more errors in there. > >> so please do not argument with me or anybody else, it is merely >> a pretty fair and neutral opinion about RELEASE meaning >> >> backed on what is stated on the page above, it seems to be the >> procedure, which eventually needs revision, because we humans >> always will fail somewhere > > You can do the same as I do. I run currently a 8.3 BETA. You can > encourage people to do so too to make it easier for the developers > to spot as many errors as possible before the release. > it is not about you and me it is about FreeBSD and the meaning, importance and reliability of - -RELEASE for all people the word -RELEASE is what encourage people :) > Still, FreeBSD has always at least one more release out there which > was hardened in real life. > > If then take into account that odd numbers are known to have a > higher risk of errors plus the fact that 9.0 was the first release > of the new branch, I do not see a need to change much to the > advantage except of putting more load onto the people who actually > make it happen. > > Erich - -- H -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAk9KJU4ACgkQvKVfg5xjCDzxXQCgoNRlf3pjOjQ2ZzjQBbFJtMby KEwAmwahSUftP5LT8EPei9Q7oZsc9ddE =GBIW -END PGP SIGNATURE- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: FreeBSD9 and the sheer number of problem reports
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Mark Linimon wrote: > On Sun, Feb 26, 2012 at 09:27:58AM -0300, H wrote: >> it is release engineering who could establish a little bit more >> time between code-freeze and RELEASE > > As you will see from the (very) long discussion that you are about > to read, there has to be a compromise. As it was, the release > process was too long, not too short. > > Yes, we would like to get more testers pre-release, but that seems > to be more easily said than done. Ideas appreciated. > > You will also see in the thread that: > > - it is not possible to release bug-free code, and in fact > > - it is not possible to release code with no regressions > whatsoever > > if you are to ever release anything at all. > > To summarize: yes, we do care: and yes, these are classical > software engineering problems that can only be dealt with, not > solved completely. > well said, of course a dead-line is necessary, as well as pursuing perfection is dangerous matter :) anyway, this thread brought little suggestion or possible solutions but lots of declaration of facts and personal interest on the table IMO such a discussion should be strictly FreeBSD oriented and so I see a or the missing point, a declaration of FreeBSD, what is it, for whom is it and what does it, this statement is nonexistent, or not clear enough. This miss affect not only users opinion but also developers work. furthermore, plans or schedules may be perfect within it's own restrictions, but only as good as the outcome so the outcome must be controlled How? ... setting the goal are you interested in bumping the version number up or do you want to come up with something better than the former version? If yes, what is it? Without goal nobody can deliver predictable and defined results steeling a good comparison from that thread you mentioned, I would say, with the right goal you _CAN_ herd cats, instead of pied pipers put some mice on the street :) again IMO the version number race is suspicious and could(should) be changed into a goal-race, then, when the goal is achieved, the the version number may go up with goal the outcome can be controlled, without it is loose end it should exist a dead-line, but goal-oriented and so should be extendable in case of failure Resuming, I would do - [re]define FreeBSD - setting the next release goal - scheduling - go then accompanying the ongoing work (control), assuring that the sub-projects are within the limits, new ideas only can go into the next schedule, a no-matter-what position of engineering is important of course we deal with FreeBSD source, ports is a different matter and can not be merged tester? I would say it could be easier to have more of them, eventual they are already there, but they are unknown, quiet for certain reasons, language, skills, etc when a problem appears, point of sight is often missing, the user who pops up has a problem, he has no interest in blaming somebody or whatever, he like to solve the problem, so giving advices as RTFM or similar does not help a bit, neither how to use, how to write, how to spell or whatever other personal issue are arising. Most do not come back after RTFM or do not even post because they heard it already once so I would say, it does not matter how wired the PR arrives, it should be handled by same criteria as above. What is the goal? Finding problems in the FreeBSD code. So it does not matter which language the guy talks, if he knows C+/- or whatever bothers you, be smart and find out what the problem is there are several related issues, I would start by splitting the mailing list page on FreeBSD. Confusing for a user, he wouldn't know which list. Directing people on first sight to a general mailing list, perhaps no developers in it, or who has people-skills only and drain the results you want ... under any cost of selfishness before the bullets fly, I am not criticizing anybody, the tech-syndrome is natural, techs and users do not speak the same language, techs always will classify users as stupid and users always will classify techs as arrogant, or at least friction is natural. That is a global unchangeable fact and we have to live with it. So mix it up or separate it in prole of better results. It is very easy, with machines we do it already, we write drivers ... As above, what do you want? More PRs? ok, then again it is answered by the goal you set. Well treated a lot of testers will appear. - -- H -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAk9LTgoACgkQvKVfg5xjCDw8tgCfSU/IsV7S22d5AaNKiLYYwh7Z W40An1OKxF2T275x3pMwZBXTFpGYzuBQ =2ucy -END PGP SIGNATURE- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: FreeBSD9 and the sheer number of problem reports
On 02/27/12 10:41, Erich Dollansky wrote: > Hi, > > On Monday 27 February 2012 16:34:02 H wrote: >> Mark Linimon wrote: >>> On Sun, Feb 26, 2012 at 09:27:58AM -0300, H wrote: >> furthermore, plans or schedules may be perfect within it's own >> restrictions, but only as good as the outcome >> >> so the outcome must be controlled >> >> How? ... setting the goal >> > could it be that you want to replace them? > > http://www.freebsdfoundation.org/ > > Erich I know it is not polite answering with a question, so I beg your pardon and do it anyway do you really believe somebody (user, future user, curious) go to this site when looking for freebsd description, download and install? further, where is it? we all are working with software, we know very well what we do with grey-zone-matter ... it is 0|1 ... all between is >/dev/null ... or exit ... so do not assume that people do like guessing very much, they find it by banging their head on it or they go home -- H signature.asc Description: OpenPGP digital signature
Re: flowtable usable or not
Doug Barton wrote: > ... and here is the crux of the problem. The vast majority of our > developers don't use FreeBSD as their regular workstation. So it has > increasingly become an OS where changes are being lobbed over the wall > by developers who don't run systems that those changes affect. That's > no way to run a railroad. Doug wow since it is not April 1st it must be revelation's day ...:) is this then the bottomline ? if [ $using_ports=YES ]; get_screwed($big_time); fi -- H signature.asc Description: OpenPGP digital signature
Re: flowtable usable or not
Doug Barton wrote: > Just looking at the committers, of which we have over 300, only a > couple dozen at most have ever identified as actually using FreeBSD as > a desktop at my count. Taking the larger development community into > account I think the numbers are a little better, but not much. Sure, > our strength is servers, and that is not going to change. eventually that could be a good starting point, good question is, why not? > But how many real-life bugs have I personally uncovered in -current as > a result of actually running it (mostly) daily? I'm not the only one, > certainly, but if the numbers were flipped and the vast majority of > our developers *did* use FreeBSD routinely, how much better off would > we be? again, why? let's face some reality. Forever installing FreeBSD Desktop, either KDE or Gnome, was a nightmare process, or better, to make it appear on screen was a nightmare. Even if somebody got all packages into his system (by miracle?), it still did not popped up. Without some special knowledge _no_chance_. who knows, the guys who created and battled on area51 knew why they chose this name :) Still now, kde4, hours of install, missing packages, compiling and still nothing, somewhere over the process, flies over the screen please set kdm4_enable="YES" ... I guess that will not be noticed by any user Even if some smart guy figures out that he needs xorg-server, the port or package do not select all it needs for running, its own drivers and so. How a user should know that? There is a windeco which installs hundreds of deps, even sound what do not work on FreeBSD, but xorg do not have deps for its functionality? god ... ohhh I forgot, that has nothing to do with the desktop itself , sorry for mentioning ... Anybody can tell how somebody can find all this out? Don't say by reading because we need to look at the real facts and that is nobody want to read, they want a desktop nothing else, something silly and easy to read email and write docs and surf on the net, listen to a CD, they need to put a cd into the drive, running install process, reboot, using, nothing else and such a thing ... we do not have so where this potential users should come from? Only from heaven ... > And before anyone bothers to point it out, yes, I happen to be using > Windows at this exact moment. I have some layer 9 work to get done and > I need tools that are only available to me in Windows (more's the > pity). The sad thing is, judging by the activity on the -ports@ list, > the traffic in #bsdports, and just talking to/interacting with FreeBSD > users, a lot of *them* are not only interested in FreeBSD as a desktop > OS, they are actually doing it. IMO the weakest point is that we do not have the packages ready. Even if lots of you do not like it to hear, fact is that we must look around and see how others do it. Windows, whatever it is, it is easy to install for everybody. Same for Fedora, in order to stay with a Unix system, package handling, update with YUM on Fedora hardly fails. ALL packages are compiled, you never need to compile anything. Even if you need 800MB of packages, yum picks them all, installs them all, and all is fine up top date. Such a process is where we need to get orientation from. If it was my decision, it should be go to ports=no_no, packages=YES I mean, as long as the packages are not complete and ready, no new port version should be released or announced So who dares,understand and can or like adventures, compiles from ports Such a decision would help FreeBSD in all means and would help the users as well, in any case it will create more users Why somebody should chose FreeBSD as his daily desktop, oh man, only some die-hard-guys like you and me, but you know, that is not hours of work, that is days, weeks and constant setbacks for whatever reasons ... that is not for anybody. And you are right, no traffic on the specific lists, why? because the three on the list, two can help themselves (you and me) and the other is the moderator ... :) not even the port maintainer/packager is on that list ... :) ps. the last statement might be exaggerated and might not be valid in all cases, so please do not shoot -- H signature.asc Description: OpenPGP digital signature
Re: flowtable usable or not
Andriy Gapon wrote: > on 03/03/2012 08:44 H said the following: >> let's face some reality. > Let's do that. > >> Forever installing FreeBSD Desktop, either KDE or Gnome, was a nightmare >> process, or better, to make it appear on screen was a nightmare. > This has not been my experience (reality). > of course not! but you do not count as well other developers and insiders do not, this kind of people we have a lot, BTW very capable people, if not the best ... but it depends on the angle of view and the question to be answered ... why we do not have more desktops out, why normal technicians and administrator do prefer Linux or Windows Workstations/server? because we do not attract them, it is to hard for them to find their way through so it is their eyes we have to look with -- H signature.asc Description: OpenPGP digital signature
Re: flowtable usable or not
Bas Smeelen wrote: > On 03/02/2012 07:42 PM, H wrote: >> Doug Barton wrote: >>> ... and here is the crux of the problem. The vast majority of our >>> developers don't use FreeBSD as their regular workstation. So it has >>> increasingly become an OS where changes are being lobbed over the wall >>> by developers who don't run systems that those changes affect. That's >>> no way to run a railroad. Doug >> wow >> >> since it is not April 1st it must be revelation's day ...:) >> >> is this then the bottomline ? >> >> if [ $using_ports=YES ]; get_screwed($big_time); fi >> >> > Hey people > > There are still a lot of us which might not be smart enough or lack > the resources to help you debug issues but we still use and depend on > FreeBSD, and we test, and hopefully give you some debugging hints > > I have some production servers running on STABLE and even some on > CURRENT to stress our developers, but most run RELEASE and use > freebsd-update > > Keep up the good work, it makes me a more confident sysadmin > Ports is the best thing happening to me after going through al the apt > and other stuff you talk like the wind blows my friend ... remembering your own most recent words in another occasion what certainly do not match your last sentence ... >/ On Mon, Jan 30, 2012 at 3:58 PM, Bas Smeelen <http://lists.freebsd.org/mailman/listinfo/freebsd-questions>> wrote: />/ />/ > On Mon, 30 Jan 2012 12:52:07 -0500 />/ > David Jackson http://lists.freebsd.org/mailman/listinfo/freebsd-questions>> wrote: />/ > />/ > > I have tried endlessly to no avail to upgrade binary the packages />/ > > on Freebsd to the latest version. I have tried: />/ > > /... >/ > > />/ > > All fail miserably and totally and have left the system in an />/ > > unuseable state. />/ > / >/ />/ />/ I wish to use binary packages and I specifically do not want to />/ compile anything, it tends to take far too long to compile programs />/ and would rather install some packages and have it all work right />/ away. Binary packages are a big time saver and are more efficient. It />/ should be easy for FreeBSD to make it easy to install the most recent />/ versions of all binary packages, its beyond belief they cannot pull />/ off such a simple ans straight forward, and basic part of any OS. / -- H signature.asc Description: OpenPGP digital signature
Re: flowtable usable or not
Bas Smeelen wrote: > />/ away. Binary packages are a big time saver and are more efficient. It > />/ should be easy for FreeBSD to make it easy to install the most recent > />/ versions of all binary packages, its beyond belief they cannot pull > />/ off such a simple ans straight forward, and basic part of any OS. / come on, you really think I need lecturing about how to read threads? and I did not misquoted nothing, you are trying to save your ass here :) in the above excerpt _YOU_ are talking about packages and how easy it is ... and this "cannot pull off" thing ... then you tell us today that ports is the best ever happened to you > Ports is the best thing happening to me after going through al the apt and other stuff but look my friend, either way, you're confirming this thread, as long as conflicts are in place, something needs improvement //* the following comment is not related to any living person, only a quote with personal note :) please lord forgive them, they don't know what they are doing (or talking about) *// -- H signature.asc Description: OpenPGP digital signature
Re: flowtable usable or not
o not need to learn to compile or read Makefiles, but of course, he tells his wife how stupid this nerd is which do not know the name of the wood he uses :) so let skip this part >> > >> > Why somebody should chose FreeBSD as his daily desktop, oh man, only >> > some die-hard-guys like you and me, but you know, that is not hours of >> > work, that is days, weeks and constant setbacks for whatever reasons ... >> > that is not for anybody. And you are right, no traffic on the specific >> > lists, why? because the three on the list, two can help themselves (you >> > and me) and the other is the moderator ... :) not even the port >> > maintainer/packager is on that list ... :) >> > > Well, these days dying on FreeBSD is much quicker than years before - in > my special case. in any case :) > Linux is faster in (our) network. Linux response faster in (our) NFSv4 > (environment). Linux has a better scalability (NUMA awareness seems to > be better on our 2-socket servers). Linux adopt faster new architectures well, if or not, it's another case, developer level case > due to a better maintaining of the necessary compiler(s). And I'm going > to face another development that will let FreeBSD die faster in certain > scientific areas (were the BSD has been born!). This is mainly due to > the lack of the support of modern GPGPU stuff. I'm forced to replace > several FreeBSD servers now by Suse Linux machines. Reason: GPGPU. We > can use OpenCL/CUDA on the TESLA boards we obtained, we can use > OpenCL/CUDA on the desktop boxes equipted with expensive and fast GPU > hardware (and we do this very intensive now). We modell, simulate and > optimize on GPGPU code developed by scientists in our depeartment, based > on OpenCL. > Since we are also dependend on funding from the government (we have to > present so called "PR products" which include scientifically prepared > and rendered products of solar system objects like Mars or the Saturnian > icy moons), we need to build up a "render cluster", which we do with a > well known open source rendering software which has now GPGPU support. > Even on "out of the box server Linux" this can not be performed "out of > the box" and need "die hard" people. But they do not die hard on FBSD > anymore. > yooo, certainly you say it all, all this communication devices (space ships) are difficult to build and have some dependencies still more difficult, but nobody cares but the building staff and it's sponsor and some other crazy people the normal guy do not even assist anymore the launch and change to the MMA channel and he buys a firework-rocket, lit a match and blows it into the sky ... he do not care and do not need to know how it works, he only needs it to work, and now, when it fails, he does what? takes another one ... -- H signature.asc Description: OpenPGP digital signature
Re: Request for flowtable testers and actionable feedback RE: flowtable usable or not
K. Macy wrote: > I'm re-sending this portion of another mail as it will inevitably not > be read by most readers by virtue of having been part of a long and > digressive thread. > this is exactly one of this statements which makes users (normal people) stay away a person-person understand this as "shut up fuckers, you're disturbing my privileged thinking, how do you dare you little nothings" and certainly not going along with your quoted anti-nazi statement below, well, thinking better, the last paragraph may apply ... what you said here before >... any progress, any improvements, any > advancements will only happen because *we* made it happen. bravo!!! hurray!!! Mr. *WE* Sir Judge of the poor souls... you have really balls to write such a thing, do you? in modern people conversations, this what you call digressive, we call it brainstorming and it is _highly_ desirable, because talking together leads to new ideas, what you apparently refuse to acknowledge you do shit when you have a close mind some people simply do not get the big picture because they only see themselves, their interests and personal reflection in the pretended egomaniac outcome and that my friend, certainly is no progress at all ... ohh you know what is funny? At the end, you are one of these in your own quote: > The real damage is done by those millions who want to 'get by.' because you don't care about what really matters, people, users, you do not even know how to talk to them I might go with Doug's frustration > Clearly you are either unable or unwilling to see my point, so I wish > you all the best. and what he said gently in another thread, I still did not agreed that time, but now I'm coming closer >That's only true if the project leadership agrees with your goals Sooo all you Mr. *WEs* good work! we worship you until the rest of your days and beyond H > -- >“The real damage is done by those millions who want to 'get by.' > The ordinary men who just want to be left in peace. Those who don’t > want their little lives disturbed by anything bigger than themselves. > Those with no sides and no causes. Those who won’t take measure of > their own strength, for fear of antagonizing their own weakness. Those > who don’t like to make waves—or enemies. > >Those for whom freedom, honour, truth, and principles are only > literature. Those who live small, love small, die small. It’s the > reductionist approach to life: if you keep it small, you’ll keep it > under control. If you don’t make any noise, the bogeyman won’t find > you. > >But it’s all an illusion, because they die too, those people who > roll up their spirits into tiny little balls so as to be safe. Safe?! > >From what? Life is always on the edge of death; narrow streets lead to > the same place as wide avenues, and a little candle burns itself out > just like a flaming torch does. > >I choose my own way to burn.” > >Sophie Scholl > ___ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" -- H signature.asc Description: OpenPGP digital signature
Re: Request for flowtable testers and actionable feedback RE: flowtable usable or not
Mark Linimon wrote: > On Mon, Mar 05, 2012 at 02:28:37AM -0300, H wrote: >> because you don't care about what really matters, people, users, you >> do not even know how to talk to them > I've been criticized for saying this to a user before, but I'm going to > repeat it here regardless of consequences. > > I'm sorry, you (as a user) do not have the right to flame someone in > this manner and then expect them to listen to further input from you, > no matter how reasonable your further contributions are. > > We are not paid employees, who might have to simply continue to work with > you because their business requires it. > > I am not speaking for Kip here but I will state that I myself am happy > to work with users up until I feel I am getting treated like this, at > which point I feel no further obligation whatsoever to try to help them. > > Executive summary: you are being very rude here. > > mcl well, as they say, as you shout into the woods it comes back ... who can not stand the echo better hold his peace ... not withstanding the annulment of my rights ... I grant you the right to criticize me as you wish do you mean rude or direct? I have the right, even the obligation to point out what I think is wrong if you think it's not, then make your point but telling me what I can or not is kind of lame, don't you think so? -- H signature.asc Description: OpenPGP digital signature
Re: Request for flowtable testers and actionable feedback RE: flowtable usable or not
Daniel Kalchev wrote: > On Mar 5, 2012, at 9:11 AM, H wrote: > >> I have the right, even the obligation to point out what I think is wrong > So, you see yourself as speaking for others? You certainly do not speak for > me! Never authorized you for this, never ever knew you actually exist. For > various historical reasons, I don't particularly like the kind of people who > self-elect themselves to defend other's "rights". OK? :-) don't try to sell your silly deductions as assumptions ... who says "I" usual means I not they, we or for them but you're funny, must be a ghost typing here :) perhaps I'm just behind your back right now huhhh :) H > So unlike you, Kip at least tries to achieve something. For the good of > others. Even if he didn't do it in the most humble, democratic and whatever > way. Even if he appears for many as being arrogant or whatever. People are > different, some might actually prefer Kip's way, did you imagine that? > > I happen to share the opinion and the experience of Mark Linimon in > situations like this and yes, I do believe you have been rude here. For no > reason whatsoever. > > You either make the choice to help Kip in his experiment, or not. For me, > personally, as long as you don't stay on my way, I don't really care what > your position is. > > Daniel > > PS: In any case, this is an open forum, so you have your opinion heard. By a > lot of people.___ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" -- H +55 11 4249. signature.asc Description: OpenPGP digital signature
Re: Request for flowtable testers and actionable feedback RE: flowtable usable or not
Adam Strohl wrote: > On 3/5/2012 15:00, Daniel Kalchev wrote: >> I happen to share the opinion and the experience of Mark Linimon in >> situations like this and yes, I do believe you have been rude here. >> For no reason whatsoever. > > I agree. This "H" person has been hijacking threads over the last > week or so, and all of the messages I've seen from them boil down > trolling. > > This is in contrast to the patient, well thought out replies from the > rest of the list. > > I'm at a loss as to what "H's" endgame is, but it probably has more to > do with writing poorly executed metaphors than it does with helping > FreeBSD or its users (whom he/she implies they represent). > ___ you also do not have a clew, have you? now we're changing to girl-talk ? If you are curious about something, ask, right away ... clear and straight -- H signature.asc Description: OpenPGP digital signature
Re: Heavy fs corruption with 9.0-RELEASE
David Thiel wrote: > On Fri, Mar 09, 2012 at 01:53:59AM -0800, Adrian Chadd wrote: >> PR ? > The original thread was here: > > http://marc.info/?t=13250246001&r=1&w=2 > > Ignore the part where it takes me a while to figure out fsck isn't > softupdate-aware. > > There was further followup off-list with the associated SUJ developers > with clearer test results, but no definitive resolution as of yet, as > far as I know. I didn't get a chance to test the write cache disabling > approach or do further testing before I had to turn off SUJ. > > Arnaud: Would you be able to record a few test cases with SUJfsck and > then regular fsck, both using the -v flag (with output piped to some > other fs)? Can you also see if: have you ever thought about that the real problem could be that fsck can not determine the fs type soon the partition is dirty? in my experience it does not matter if it is SU or SUJ, the problem is that fsck bails out and the system boots normally even with bad blocks, because of this fatality the errors are dragged from boot to boot and things are getting worse since I added -t ufs to /etc/rc.d/fsck I have no problems anymore with this issue background fsck of course must be disabled and fsck_yes enabled H > kern.cam.ada.write_cache=0 > hw.ata.wc=0 > > while leaving SUJ enabled helps at all? > >> On 8 March 2012 11:07, David Thiel wrote: >>> On Mon, Mar 05, 2012 at 05:12:16PM -0500, Arnaud Lacombe wrote: >>>> I've been running a couple of system with 9.0-RELEASE since it is out. >>>> All the system were installed through the standard installation >>>> procedure. After unclean reboot, either crash or power-failure, I get >>>> a huge amount of really bad filesystem corruption (read: "silent", >>>> fs-wide, corruptions). This happens with either i386 or amd64 build. >>>> Systems involved use compact flash as their system permanent storage >>>> medium. >>> I have had this same behavior on every SUJ system I've built, both on >>> SSDs and otherwise, on i386, PPC and amd64. Remove SUJ and revert to >>> plain softupdates, and I strongly suspect your problems will disappear. >>> >>> ___ >>> freebsd-stable@freebsd.org mailing list >>> http://lists.freebsd.org/mailman/listinfo/freebsd-stable >>> To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" > ___ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" -- H +55 11 4249. signature.asc Description: OpenPGP digital signature
Re: Why Are You NOT Using FreeBSD ?
Adam Strohl wrote: > On 6/9/2012 3:34, Steve Franks wrote: >> Every time libjpeg or >> perl or python bumps the rev, I have to explain to my boss that I >> won't be using my computer for 48 hours. > > Why is this? And why are you updating every time there is a rev bump? > certainly the worse question ever why is there an update, would be a little bit better but a real good question would be, why is there a not working/compiling update released to the ports tree Hans -- H +55 11 4249. signature.asc Description: OpenPGP digital signature
Re: Why Are You NOT Using FreeBSD ?
On Monday 11 June 2012 20:59 Chuck Swiger wrote: > Hi, Dave-- > > On Jun 11, 2012, at 4:35 PM, Dave Hayes wrote: > [ ... ] > > > Do I have this wrong? Anyone see a problem with this picture? > > What can we do to "just upgrade" in a safe fashion when we want to? > > Two things help tremendously: > > #1: Have working backups. If you run into a problem, roll back the > system to a working state. If you cannot restore a working system > easily, fix your backup solution until you can rollback easily. > > #2: Have a package-building box and test builds before installing > new package builds to other boxes. Your downtime for upgrades > to the rest of your boxes become minimized. > > Regards, of course it helps ... but please do not forget that most people just want their desktop up to date and have a working kde (or any other) environment I believe the ports tree simply must? should? be seen as it is, partially good working, and partially a jorney to very dark places , depends on which ports and how many you have installed in any case it is for somebody who knows what he does and can find his way out, or is courageous, a "normal desktop user" probably is not able to upgrade kde4 properly and ends up with an unusable machine On Monday 11 June 2012 20:20 Dave Hayes wrote: > Rainer Duffner writes: > > Sometimes, options only make sense in context of the selection of > > options of other ports and it thus may no be easily explainable in one > > line. > > I don't understand Are you saying this is a reason not to document what > these options do? both here deepen the "lead into the dark" theory On Sunday 10 June 2012 14:10 O. Hartmann wrote: > "portmaster" does even more damage. Sometimed a port reels in some newly > updates, a port gets deleted. if on of the to be updated prerquisits > fail, the port in question isn't there anymore. this is caused of ports tree's install script maior logic failure, BTW by portmaster AND portupgrade and it happens quite often, as already commented, nobody sits in front of the screen and watch the compile process so this problems go under at first sight I think, correcting this, would help a lot and may solve a lot of existing [hidden] problems. I see only one way, having a complete package collection for easy upgrade most of you do not like it, but you must look at the competitors, Fedoras upgrade system works, user do not need the newest features and none of them are essential for a desktop to work properly of course the package collection needs then something similar to portversion, but not based on ports tree versions, in order to find available updates who then wants to customize or learn or who dares, can use the ports tree after all I guess any further effort on ports goes nowhere because it depends at the end on the maintainer and/or committer and people use to fail, that is so and nobody can change that. Of course It would be nice to find this "eval" behaviour of deleting accidentially installed ports corrected what is worth working on is a complete package collection and a propper update tool for it Hans signature.asc Description: This is a digitally signed message part.
Re: Why Are You NOT Using FreeBSD ?
On Tuesday 12 June 2012 07:10 Chris Rees wrote: > > > are essential for a desktop to work properly > > > > of course the package collection needs then something similar to > > portversion, > > > but not based on ports tree versions, in order to find available updates > > > > who then wants to customize or learn or who dares, can use the ports tree > > You have hit the nail right on the head there, and that is the intention > with pkgng. Please feel free to have a go with it using the beta repos :) > > Chris yooo ... but I unfortunately since some time pkgng completes the ports tree novell :) cc -O2 -pipe -march=athlon-mp -fno-strict-aliasing -march=athlon-mp -std=c99 -I/dados/ports/ports-mgmt/pkg/work/pkg-1.0-beta15/libpkg - I/dados/ports/ports-mgmt/pkg/work/pkg-1.0-beta15/libpkg/../external/sqlite - I/dados/ports/ports-mgmt/pkg/work/pkg-1.0- beta15/libpkg/../external/libyaml/include -DPREFIX=\"/usr/local\" -g -O0 - std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls - Wold-style-definition -Wno-pointer-sign -c usergroup.c -o usergroup.o cc1: warnings being treated as errors In file included from usergroup.c:36: private/gr_util.h:27: warning: redundant redeclaration of 'gr_copy' /usr/include/libutil.h:165: warning: previous declaration of 'gr_copy' was here private/gr_util.h:28: warning: redundant redeclaration of 'gr_fini' /usr/include/libutil.h:168: warning: previous declaration of 'gr_fini' was here private/gr_util.h:29: warning: redundant redeclaration of 'gr_init' /usr/include/libutil.h:169: warning: previous declaration of 'gr_init' was here private/gr_util.h:30: warning: redundant redeclaration of 'gr_lock' /usr/include/libutil.h:170: warning: previous declaration of 'gr_lock' was here private/gr_util.h:31: warning: redundant redeclaration of 'gr_mkdb' /usr/include/libutil.h:172: warning: previous declaration of 'gr_mkdb' was here private/gr_util.h:32: warning: redundant redeclaration of 'gr_tmp' /usr/include/libutil.h:173: warning: previous declaration of 'gr_tmp' was here *** Error code 1 Stop in /dados/ports/ports-mgmt/pkg/work/pkg-1.0-beta15/libpkg. *** Error code 1 Stop in /dados/ports/ports-mgmt/pkg/work/pkg-1.0-beta15. *** Error code 1 Hans -- H +55 17 4141. signature.asc Description: This is a digitally signed message part.
Re: How to bind a route to a network adapter and not IP
Hans Petter Selasky wrote: > On Friday 15 June 2012 19:02:27 animelo...@gmail.com wrote: >> Perhaps you can ask the very same question in another way so its easier >> to understand why you losing packets? All in all I always thought TCP/IP >> was the basic unit in Internet based networking but feel free to correct >> me if you have any news I might have missed... :) >> >> Also do you have any idea why AMD based CPUs could be vulnerable to this >> alternative networking scheme and cause a remote denial service in fbsd >> stable but not in CURRENT? >> >> Thanks, >> >> Etienne > > Hi, > > I loose packets because I use a WLAN adapter. Sometimes the link is down for > various reasons, and then the routes start changing for manually created > routes, and I want to prevent that. > well that is certainly not a reason for changing routes I have the feeling you are not explaining good enough what really is going on and it may help sending your configurations and an example of routes and IP addresses before and after this route change Hans -- H +55 11 4249. signature.asc Description: OpenPGP digital signature
Re: How to bind a route to a network adapter and not IP
sth...@nethelp.no wrote: >>> I loose packets because I use a WLAN adapter. Sometimes the link is down >>> for >>> various reasons, and then the routes start changing for manually created >>> routes, and I want to prevent that. >> >> well that is certainly not a reason for changing routes >> >> I have the feeling you are not explaining good enough what really is >> going on and it may help sending your configurations and an example of >> routes and IP addresses before and after this route change > > Why is this so hard to understand? "Link down" leads to "static route > is deleted". This is standard FreeBSD behavior, and has been this way > for as long as I can remember (btw, I believe this behavior is from > the original BSD, not FreeBSD specific). > > You can show this by having a static default route pointing to an > address on an Ethernet interface which has link. And then pulling the > TP cable from the Ethernet interface. Observe that the default route > is automatically removed. may be you have not understood your own problem yet because so far is nothing to be understood because none of your statements is correct, it is also not FreeBSD's standard behavior and never has been as long as there is the valid IP address on the related interface, no static route will be deleted, you can even boot without cable and the [default] static route is there so you need to explain better your problem in order to understand it probably you have some other stuff running, thirdparty network manager or something, incorrect or incomplete ppoe or dhc configuration or whatever leads to the problem FYI static routes usually are the manually configured routes, so what you say is redundant and not correct, I guess you're loosing some kind of dynamic route since WL networks usually do not run RIP/OSPF/BGP I guess the route you apparently loose is coming from some dhcp server and may be your dhclient configuration is incomplete or none existent, but here now it would be useful to see your config -- H +55 11 4249. signature.asc Description: OpenPGP digital signature
Re: How to bind a route to a network adapter and not IP
On Monday 18 June 2012 12:54 Hans Petter Selasky wrote: > On Monday 18 June 2012 00:00:51 H wrote: > > sth...@nethelp.no wrote: > > >>> I loose packets because I use a WLAN adapter. Sometimes the link is > > >>> down for various reasons, and then the routes start changing for > > >>> manually created routes, and I want to prevent that. > > >> > > >> well that is certainly not a reason for changing routes > > >> > > >> I have the feeling you are not explaining good enough what really is > > >> going on and it may help sending your configurations and an example of > > >> routes and IP addresses before and after this route change > > > > > > Why is this so hard to understand? "Link down" leads to "static route > > > is deleted". This is standard FreeBSD behavior, and has been this way > > > for as long as I can remember (btw, I believe this behavior is from > > > the original BSD, not FreeBSD specific). > > > > > > You can show this by having a static default route pointing to an > > > address on an Ethernet interface which has link. And then pulling the > > > TP cable from the Ethernet interface. Observe that the default route > > > is automatically removed. > > > > may be you have not understood your own problem yet > > > > because so far is nothing to be understood because none of your > > statements is correct, it is also not FreeBSD's standard behavior and > > never has been > > > > as long as there is the valid IP address on the related interface, no > > static route will be deleted, you can even boot without cable and the > > [default] static route is there > > > > so you need to explain better your problem in order to understand it > > > > probably you have some other stuff running, thirdparty network manager > > or something, incorrect or incomplete ppoe or dhc configuration or > > whatever leads to the problem > > > > FYI static routes usually are the manually configured routes, so what > > you say is redundant and not correct, I guess you're loosing some kind > > of dynamic route > > > > since WL networks usually do not run RIP/OSPF/BGP I guess the route you > > apparently loose is coming from some dhcp server and may be your > > dhclient configuration is incomplete or none existent, but here now it > > would be useful to see your config > > Hi, > > I think we need to distinguish between two matters. One is where the route > is directly reachable on the local-net of the network adapter, and ARP is > valid/responding. The second case is when the route is not directly > reachable. The second case is where the problem happens, like Stian kindly > explained. > > # For example: > > ifconfig wlan0 10.0.0.2 255.255.255.0 up > > # Assume the router is at 10.0.0.1 > # And we want to reach a certain destination through 10.0.0.1 > # Then we do: > > route add 10.22.1.1 10.0.0.1 > no no no my friend, wrong again that is a static route and it goes away same way it was created, manually or by deleting the IP address 10.0.0.2 from the related interface wether there is or not an active link on that interface does not matter Hans > # > # First the FreeBSD network stack will resolve the ethernet address for > # 10.0.0.1, and all 10.22.1.1 IP packets will get sent to 10.0.0.1. > # > > However, if the wlan0 link goes down, which sometimes happen, then the > route for 10.22.1.1 is deleted. This is sometimes very annoying, and also, > if it happens that the 10.22.1.1 is reachable from another network > adapter, then traffic sometimes can end up mis-routed. > > --HPS > ___ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" -- HM +55 17 8111.3300 signature.asc Description: This is a digitally signed message part.
Re: How to bind a route to a network adapter and not IP
On Monday 18 June 2012 18:07 Hans Petter Selasky wrote: > On Monday 18 June 2012 23:03:34 H wrote: > > On Monday 18 June 2012 12:54 Hans Petter Selasky wrote: > > > On Monday 18 June 2012 00:00:51 H wrote: > > > > sth...@nethelp.no wrote: > > > > >>> I loose packets because I use a WLAN adapter. Sometimes the link > > > > >>> is down for various reasons, and then the routes start changing > > > > >>> for manually created routes, and I want to prevent that. > > > > >> > > > > >> well that is certainly not a reason for changing routes > > > > >> > > > > >> I have the feeling you are not explaining good enough what really > > > > >> is going on and it may help sending your configurations and an > > > > >> example of routes and IP addresses before and after this route > > > > >> change > > > > > > > > > > Why is this so hard to understand? "Link down" leads to "static > > > > > route is deleted". This is standard FreeBSD behavior, and has been > > > > > this way for as long as I can remember (btw, I believe this > > > > > behavior is from the original BSD, not FreeBSD specific). > > > > > > > > > > You can show this by having a static default route pointing to an > > > > > address on an Ethernet interface which has link. And then pulling > > > > > the TP cable from the Ethernet interface. Observe that the default > > > > > route is automatically removed. > > > > > > > > may be you have not understood your own problem yet > > > > > > > > because so far is nothing to be understood because none of your > > > > statements is correct, it is also not FreeBSD's standard behavior and > > > > never has been > > > > > > > > as long as there is the valid IP address on the related interface, no > > > > static route will be deleted, you can even boot without cable and the > > > > [default] static route is there > > > > > > > > so you need to explain better your problem in order to understand it > > > > > > > > probably you have some other stuff running, thirdparty network > > > > manager or something, incorrect or incomplete ppoe or dhc > > > > configuration or whatever leads to the problem > > > > > > > > FYI static routes usually are the manually configured routes, so what > > > > you say is redundant and not correct, I guess you're loosing some > > > > kind of dynamic route > > > > > > > > since WL networks usually do not run RIP/OSPF/BGP I guess the route > > > > you apparently loose is coming from some dhcp server and may be your > > > > dhclient configuration is incomplete or none existent, but here now > > > > it would be useful to see your config > > > > > > Hi, > > > > > > I think we need to distinguish between two matters. One is where the > > > route is directly reachable on the local-net of the network adapter, > > > and ARP is valid/responding. The second case is when the route is not > > > directly reachable. The second case is where the problem happens, like > > > Stian kindly explained. > > > > > > # For example: > > > > > > ifconfig wlan0 10.0.0.2 255.255.255.0 up > > > > > > # Assume the router is at 10.0.0.1 > > > # And we want to reach a certain destination through 10.0.0.1 > > > # Then we do: > > > > > > route add 10.22.1.1 10.0.0.1 > > > > no no no my friend, wrong again > > > > that is a static route and it goes away same way it was created, manually > > or by deleting the IP address 10.0.0.2 from the related interface > > > > wether there is or not an active link on that interface does not matter > > Hi, > > Can it be that dhclient which I'm running on this interface with manual > routes disrupts stuff then ?? > so now we're coming to the point ... on renewal of the IP address the interface is set do down, old IP removed and the new one (even if the same as before) is associated and the IF comes up again means, any route associated get lost, you may get a new one (default) from the dhcp server you could set some options in your /etc/dhclient.conf to match your needs you could request a longer lease time, eventually reduce the retry time to get less down time check your log what the dhcp server send to you may be you try something like: timeout 60; retry 60; send dhcp-lease-time 36000; (or more to cover your longest up time) if the longer lease time does not work, then I guess then you could use the 'script "name"' option to set your special route after renewal Hans -- HM +55 17 8111.3300 signature.asc Description: This is a digitally signed message part.
Re: release documentation confusing for 9.1
Aristedes Maniatis wrote: > Could I ask that someone with appropriate access rights review the state > of release documentation for 9.1 beta. It is very confused. > > > 1. This page is the best information available: > http://www.freebsd.org/releases/9.1R/schedule.html > > 2. The link from the front page ( http://www.freebsd.org/ ) is labelled > "Upcoming: 9.1-BETA1" but goes to a page which is mostly about existing > releases, not the next release. http://www.freebsd.org/where.html#helptest > > 3. Clicking on the "view" link for the 9.1 information on that page > takes you to http://wiki.freebsd.org/Releng/9.1TODO which looks a lot > like the information in point [1] but wrong/old. > > 4. On http://www.freebsd.org/where.html#helptest there is a link to > "FreeBSD Snapshot Releases" for people interested in "FreeBSD-CURRENT > (AKA 10.0-CURRENT)". But following the link takes you to a page where > you get linked to "9-CURRENT, 8-STABLE, 7-STABLE, and 6-STABLE" snapshots. > > > > It is possible I'm just stuck in the past, but I've never been able to > navigate the 'new' bowling ball branded FreeBSD site nearly as well as > the older incarnation. And yes, I can eventually figure it all out... > but this information could be a whole lot clearer. I design information > presentation for a living, so perhaps I'm picky about these things, but > I do think that confusion could turn people away from my favourite > operating system. > Hi I can not agree more about what you say, but the pages you mention still let you find what you want and this pages do have a release/modify date stamp somewhere and they are not thaaat old worse and worse it gets when looking for documentation all this pages do not have a date or indication to what version they refer to, most are old, some even wrong for actual releases even if recognizing the work spent by all to write the pages, also recognizing that all docs are well written, organized and understandable, all of it is worthless when not up to date, wrong or incomplete for actual releases (either OS or ports) or merely theoretical this is still more important because a lot of general product docs for, lets say for example xorg or kde, do not apply fully to their FreeBSD ports, forcing the user finding his way elsewhere or getting stuck with eventually not working system or as you say leading to turn away from freeBSD one step forward would be, adding at least the last modified date to each document, but not in tiny light grey chars at the bottom, but big and fat on top of the doc, so at last the user would have the possibility to consider it being old or new documentation []s Hans -- H +55 11 4249. signature.asc Description: OpenPGP digital signature
Re: bce related panic on 8.3-STABLE
On 03/09/2012 11:10, Krassimir Slavchev wrote: > Hi All, > > Today, after upgrading an HP Proliant DL380 G6 to 8.3-STABLE we had the > following panic few minutes after going to multiuser mode: > > http://193.194.156.21/bce_crash.jpg > here are crashing all amd64 8.3 machines with panic on current process=dummynet machines without dummynet apparently are running stable kernel with source from 20120721 is fine Hans > dmesg from 8.3-STABLE kernel (Note the link up/down events): > ... > Sep 3 14:19:54 m kernel: bce0: Server Adapter (C0)> mem 0xf400-0xf5ff irq 16 at device 0.0 on pci2 > Sep 3 14:19:54 m kernel: miibus0: on bce0 > Sep 3 14:19:54 m kernel: brgphy0: PHY > 1 on miibus0 > Sep 3 14:19:54 m kernel: brgphy0: 10baseT, 10baseT-FDX, 100baseTX, > 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, > 1000baseT-FDX-master, auto, auto-flow > Sep 3 14:19:54 m kernel: bce0: Ethernet address: 00:26:55:52:27:06 > Sep 3 14:19:54 m kernel: bce0: [ITHREAD] > Sep 3 14:19:54 mkernel: bce0: ASIC (0x57092003); Rev (C0); Bus (PCIe > x2, 2.5Gbps); B/C (4.6.4); Bufs (RX:2;TX:2;PG:8); Flags (SPLT|MSI|MFW); > MFW (NCSI 1.0.3) > Sep 3 14:19:54 m kernel: Coal (RX:6,6,18,18; TX:20,20,80,80) > ... > Sep 3 14:19:54 m kernel: Trying to mount root from ufs:/dev/da0s1a > Sep 3 14:19:57 m kernel: bce0: > Sep 3 14:19:57 m kernel: bce0: link state changed to UP > Sep 3 14:19:57 m kernel: Gigabit link up! > Sep 3 14:19:57 m kernel: bce0: Gigabit link up! > Sep 3 14:19:58 m kernel: bce1: > Sep 3 14:19:58 m kernel: bce1: link state changed to UP > Sep 3 14:19:58 m kernel: Gigabit link up! > Sep 3 14:19:58 m kernel: bce1: Gigabit link up! > Sep 3 14:20:01 m kernel: bce1: Gigabit link up! > Sep 3 14:20:27 m kernel: bce0: Gigabit link up! > Sep 3 14:24:25 m syslogd: kernel boot file is /boot/kernel/kernel > ... > > > The previous kernel from the middle of May last year (8.2-STABLE): > > $sysctl dev.bce.0 > dev.bce.0.%desc: HP NC382i DP Multifunction Gigabit Server Adapter (C0) > dev.bce.0.%driver: bce > dev.bce.0.%location: slot=0 function=0 > dev.bce.0.%pnpinfo: vendor=0x14e4 device=0x1639 subvendor=0x103c > subdevice=0x7055 class=0x02 > dev.bce.0.%parent: pci2 > dev.bce.0.l2fhdr_error_count: 0 > dev.bce.0.mbuf_alloc_failed_count: 0 > dev.bce.0.mbuf_frag_count: 0 > dev.bce.0.dma_map_addr_rx_failed_count: 0 > dev.bce.0.dma_map_addr_tx_failed_count: 51 > dev.bce.0.unexpected_attention_count: 0 > dev.bce.0.stat_IfHcInOctets: 8862469148 > dev.bce.0.stat_IfHCInBadOctets: 329986 > dev.bce.0.stat_IfHCOutOctets: 89884604332 > dev.bce.0.stat_IfHCOutBadOctets: 0 > dev.bce.0.stat_IfHCInUcastPkts: 47972963 > dev.bce.0.stat_IfHCInMulticastPkts: 0 > dev.bce.0.stat_IfHCInBroadcastPkts: 301 > dev.bce.0.stat_IfHCOutUcastPkts: 72217877 > dev.bce.0.stat_IfHCOutMulticastPkts: 0 > dev.bce.0.stat_IfHCOutBroadcastPkts: 45 > dev.bce.0.stat_emac_tx_stat_dot3statsinternalmactransmiterrors: 0 > dev.bce.0.stat_Dot3StatsCarrierSenseErrors: 0 > dev.bce.0.stat_Dot3StatsFCSErrors: 0 > dev.bce.0.stat_Dot3StatsAlignmentErrors: 0 > dev.bce.0.stat_Dot3StatsSingleCollisionFrames: 0 > dev.bce.0.stat_Dot3StatsMultipleCollisionFrames: 0 > dev.bce.0.stat_Dot3StatsDeferredTransmissions: 0 > dev.bce.0.stat_Dot3StatsExcessiveCollisions: 0 > dev.bce.0.stat_Dot3StatsLateCollisions: 0 > dev.bce.0.stat_EtherStatsCollisions: 0 > dev.bce.0.stat_EtherStatsFragments: 0 > dev.bce.0.stat_EtherStatsJabbers: 0 > dev.bce.0.stat_EtherStatsUndersizePkts: 0 > dev.bce.0.stat_EtherStatsOversizePkts: 0 > dev.bce.0.stat_EtherStatsPktsRx64Octets: 28900335 > dev.bce.0.stat_EtherStatsPktsRx65Octetsto127Octets: 11130062 > dev.bce.0.stat_EtherStatsPktsRx128Octetsto255Octets: 94457 > dev.bce.0.stat_EtherStatsPktsRx256Octetsto511Octets: 268122 > dev.bce.0.stat_EtherStatsPktsRx512Octetsto1023Octets: 6647988 > dev.bce.0.stat_EtherStatsPktsRx1024Octetsto1522Octets: 932300 > dev.bce.0.stat_EtherStatsPktsRx1523Octetsto9022Octets: 0 > dev.bce.0.stat_EtherStatsPktsTx64Octets: 2695217 > dev.bce.0.stat_EtherStatsPktsTx65Octetsto127Octets: 2635924 > dev.bce.0.stat_EtherStatsPktsTx128Octetsto255Octets: 2697153 > dev.bce.0.stat_EtherStatsPktsTx256Octetsto511Octets: 4127448 > dev.bce.0.stat_EtherStatsPktsTx512Octetsto1023Octets: 2505593 > dev.bce.0.stat_EtherStatsPktsTx1024Octetsto1522Octets: 57556587 > dev.bce.0.stat_EtherStatsPktsTx1523Octetsto9022Octets: 0 > dev.bce.0.stat_XonPauseFramesReceived: 0 > dev.bce.0.stat_XoffPauseFramesReceived: 0 > dev.bce.0.stat_OutXonSent: 0 > dev.bce.0.stat_OutXoffSent: 0 > dev.bce.0.stat_FlowControlDone: 0 > dev.bce.0.stat_MacControlFramesReceived: 0 > dev.bce.0.stat_XoffStateEntered: 0 > dev.bce.0.stat_IfInFramesL2FilterDiscards: 4331 > dev.bce.0.stat_IfInRuleCheckerDiscards: 0 > dev.bce.0.stat_IfInFTQDiscards: 0 > dev.bce.0.stat_IfInMBUFDiscards: 0 > dev.bce.0.stat_IfInRuleCheckerP4Hit: 301 > dev.bce.0.stat_CatchupInRuleCheckerDiscards: 0 > dev.bce.0.stat_CatchupInFTQDiscards: 0 > dev.bce.0.stat_CatchupInMBUFDiscards: 0 > dev.bce.
Re: Please be nice to the newbie....
Derek C. wrote: > So, what I am asking, is there any advice that you would care to > impart to this FreeBSD newbie (aside from RTFM, which I have done... > FreeBSD's docs Just follow (yes, it is part of the FM :) http://www.freebsd.org/handbook/kernelconfig-building.html Perhaps nice is to familiarize yourself with booting another kernel than /kernel (during the kernel install the old /kernel will be renamed to /kernel.old) so that in case of a failing new kernel you know how to revert to the old one. Or did you want advice on what to modify/tune to the kernel config itself ? Hans Lambermont -- http://lambermont.webhop.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: ICQ with NAT problems
Kal Torak wrote: > There is a problem with NAT and ICQ that causes you to go > offline/online constantly, you probably wont notice this your self if > you have a high speed connection, but trust me its happining!!! Just to back you up: I see the same behaviour (that is, I get complaints from others about going offline/online very regularly). But I always thought it was my Licq acting strange. I'd like to see this problem solved too. Hans Lambermont -- http://lambermont.webhop.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: important NFS client patch for FreeBSD8.n
Greetings, and thank you for the "heads up". On Mon, January 10, 2011 2:22 pm, Rick Macklem wrote: > I just commited a patch (r217242) to head. Anyone who is using client > side NFS on FreeBSD8.n should apply this patch. It is also available at: > http://people.freebsd.org/~rmacklem/krpc.patch > > > It fixes a problem where the kernel rpc assumes that 4 bytes of data > exists in the first mbuf without checking. If the data straddles multiple > mbufs, > it uses garbage and then a typical case will wedge for a minute or so until it > times out and establishes a new TCP connection. It also replaces m_pullup() > with > m_copydata(), since m_pullup() can fail for rare cases when there is data > available. (m_pullup() uses MGET(, M_DONTWAIT,) which can fail when mbuf > allocation is constrainted, for example.) > > Thanks to john.gemignani at isilon.com for spotting this problem, rick I just fired a message off to @amd64 && @net because I am seeing messages like: nfe0: tx v2 error 0x6204 on a recent 8.1/amd64 install which is connected to an 8.0/i386 via NFS. They both run NFS client && server, and they both utilize mount points on each other. They are only 2 of several interconnected servers. The others are all 7x/i386. But I only see these messages on the 8.1/amd64, and only when connected to, and utilizing mounts on the 8.0/i386, and even then, only when the data exceeds ~1.5Mb. I guess I'm asking if the messages I'm receiving are related to the corrections your patch provides. Or should I keep looking for the answer for the messages I am seeing. Thank you for all your time and consideration. --Chris > ___ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" > > -- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: important NFS client patch for FreeBSD8.n
Hello Jeremy, and thank you for your reply. On Tue, January 11, 2011 12:17 am, Jeremy Chadwick wrote: > On Mon, Jan 10, 2011 at 11:40:37PM -0800, Chris H wrote: > >> Greetings, and thank you for the "heads up". >> On Mon, January 10, 2011 2:22 pm, Rick Macklem wrote: >> >>> I just commited a patch (r217242) to head. Anyone who is using client >>> side NFS on FreeBSD8.n should apply this patch. It is also available at: >>> http://people.freebsd.org/~rmacklem/krpc.patch >>> >>> >>> >>> It fixes a problem where the kernel rpc assumes that 4 bytes of data >>> exists in the first mbuf without checking. If the data straddles multiple >>> mbufs, it uses garbage and then a typical case will wedge for a minute or so >>> until it times out and establishes a new TCP connection. It also replaces >>> m_pullup() with m_copydata(), since m_pullup() can fail for rare cases when >>> there is data available. (m_pullup() uses MGET(, M_DONTWAIT,) which can fail >>> when mbuf allocation is constrainted, for example.) >>> >>> Thanks to john.gemignani at isilon.com for spotting this problem, rick >>> >> >> I just fired a message off to @amd64 && @net because I am seeing messages >> like: >> >> >> nfe0: tx v2 error 0x6204 >> >> >> on a recent 8.1/amd64 install which is connected to an 8.0/i386 via NFS. They >> both run NFS client && server, and they both utilize mount points on each >> other. They are only 2 of several interconnected servers. The others are all >> 7x/i386. But I only see these messages on the 8.1/amd64, >> and only when connected to, and utilizing mounts on the 8.0/i386, and even >> then, only when the data exceeds ~1.5Mb. I guess I'm asking if the messages >> I'm receiving are related to the >> corrections your patch provides. Or should I keep looking for the answer for >> the messages I am seeing. > > The above message is coming from the nfe(4) NIC driver, not from NFS. > It's possible that NFS tickles some kind of I/O throughput quirk in > drivers such as nfe(4), given that they're intended for cheap desktops. Well, I'd argue that point given I'm happily running an AM3 XIII 6-core 4Ghz motherboard that is military grade, which /also/ sports the nfe(4). Oh, and it wasn't cheap. :) However, the one I'm working with here is only an AM2 with a 2-core. > > CC'ing Yong-Hyeon Pyun to assist in debugging/explaining the above > error. Yong-Hyeon Pyun kindly responded to my message to @amd64 || @net, and requested much the same info - which I provided. I /assumed/ that it was an amd64 issue, as this box is the only amd64 of the lot, that, or because it was the only 8.1 - the others are all <= 8.0. After posting/ responding @amd64 && @net, I noticed the NFS patch in the @stable, and figured it worth asking about. > > In the interim, can you please provide output from the following > commands: > > > # uname -a > # dmesg (please include relevant nfe details and miibus) SEE ATTACHED FILE: dmesg.boot.udns0 > # pciconf -lvcb (please only include nfe-related output) n...@pci0:0:10:0: class=0x068000 card=0x73101462 chip=0x005710de rev=0xf3 hdr=0x00 vendor = 'NVIDIA Corporation' device = 'NVIDIA Network Bus Enumerator (CK804)' class = bridge bar [10] = type Memory, range 32, base 0xf9ffb000, size 4096, enabled bar [14] = type I/O Port, range 32, base 0xc080, size 8, enabled cap 01[44] = powerspec 2 supports D0 D1 D2 D3 current D0 > # netstat -ind(you can XX-out MACs and/or IPs) NameMtu Network Address Ipkts Ierrs IdropOpkts Oerrs Coll Drop nfe0 1500 00:19:db:22:74:87 729801 0 0 529029 182 00 nfe0 1500 XXX.XXX.XXX.0 XXX.XXX.XXX.26 695750 - - 631781 - -- nfe0 1500 fe80:1::219:d fe80:1::219:dbff:0 - -6 - -- plip0 15000 0 00 0 00 lo0 16384 315 0 0 315 0 00 lo0 16384 127.0.0.0/8 127.0.0.1 313 - - 313 - -- lo0 16384 ::1/128 ::1 0 - -2 - -- lo0 16384 fe80:3::1/64 fe80:3::10 - -0 - -- > # ifconfig -a (you can XX-out MACs and/or IPs) nfe0: flags=8843 metric 0 mtu 1500 options=8010b ether 00:19:db:22:74:87 inet XXX.XXX.XXX.26 netmask 0xffe0 broadcast XXX.XXX.XXX.31 inet6 fe80::219:dbff:fe22:7487%nfe0 prefixlen 64 scopeid 0x1 nd
Re: sed is broken under freebsd?
On Wed, January 12, 2011 2:32 pm, Bob Willcox wrote: > On Tue, Jan 11, 2011 at 09:00:09PM -1000, Clifton Royston wrote: > >> On Wed, Jan 12, 2011 at 02:32:52AM +0100, Oliver Pinter wrote: >> >>> hi all! >>> >>> The freebsd versions of sed contained a bug/regression, when \n char >>> can i subsitue, gsed not affected with this bug: >> >>> FreeBSD xxx 8.1-RELEASE FreeBSD 8.1-RELEASE #0: Mon Jul 19 02:55:53 >>> UTC 2010 r...@almeida.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC >>> i386 aa@xxx ~> echo axa | sed s/x/\n/g ana aa@xxx ~> echo axa | sed >>> s/x/'\n'/g >>> ana >> >> Different than GNU is not a bug. >> >> >> I have 7.3 here. It behaves as the above, which is how the man page says it >> should work. The following is how the man page specifies you can substitute >> a >> newline, by prefacing a quoted actual newline with a backslash: >> >> $ echo axa | sed 's/x/\ >> >>> /g' >>> >> a a >> >> That's how I remember classic sed behaving (Unix v7 or thereabouts.) >> -- Clifton >> > > FWI, AIX 6.1 sed works as the FreeBSD sed does. FWIW On a hunch, I just performed an experimentwith sed(1) against gsed on 50,000 html documents. My mission; to replace all instances of: with: http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd";> http://www.w3.org/1999/xhtml"; xml:lang="en" dir="ltr"> in an effort to see how long it would take to perform the operation for each of the two versions. The results? sed(1) (as provided by the BSD family of operating systems): ~2 seconds gsed: ~4.5 seconds Apologies for the extra noise on the list, but I do a tremendous amount of editing with sed(1) on almost a daily basis. It's a _fantastic_ tool, that saves me _zillions_ of hours. So I'm afraid I become a bit defensive when hearing anyone defame it - it's been like a trusted friend to me. :) --Chris > > > -- > Bob Willcox When the ax entered the forest, the trees said, > b...@immure.com "The handle is one of us!" Austin, TX > -- Turkish proverb > ___ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" > > -- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: sed is broken under freebsd?
On Thu, January 13, 2011 11:45 am, Alban Hertroys wrote: > On 13 Jan 2011, at 6:10, Chris H wrote: > >> FWIW On a hunch, I just performed an experimentwith sed(1) >> against gsed on 50,000 html documents. My mission; to replace all instances >> of: >> >> >> >> >> with: >> >> >> >> > "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd";> >> http://www.w3.org/1999/xhtml"; xml:lang="en" dir="ltr"> >> > > > I do hope you didn't orphan a -tag there? LOL Good catch! Nope. I guess my copy/paste skills aren't so good, when it comes to my mail reader. :) This is the actual script I used: fixem.sh #!/bin/sh - # WARNING - there is NO turning back! for name in $(find . -type f -name '*.html') do sed -f fixem.sed <$name >temp.txt mv temp.txt $name done rm -f temp.txt fixem.sed /\/d s/\/\<\?xml\ version\=\"1\.0\"\ encoding\=\"UTF\-8\"\?\>\ \<\!DOCTYPE\ html\ PUBLIC\ \"\-\/\/W3C\/\/DTD\ XHTML\ 1\.0\ Strict\/\/EN\"\ \ \"http\:\/\/www\.w3\.org\/TR\/xhtml1\/DTD\/xhtml1\-strict\.dtd\"\>\ \\ \/s --Chris > > > Alban Hertroys > > > -- > If you can't see the forest for the trees, > cut the trees and you'll see there is no forest. > > > !DSPAM:74,4d2f565011879296619823! > > > > ___ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" > > -- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: sed is broken under freebsd?
On Fri, January 14, 2011 12:01 am, Chris H wrote: > > On Thu, January 13, 2011 11:45 am, Alban Hertroys wrote: > >> On 13 Jan 2011, at 6:10, Chris H wrote: >> >> >>> FWIW On a hunch, I just performed an experimentwith sed(1) >>> against gsed on 50,000 html documents. My mission; to replace all instances >>> of: >>> >>> >>> >>> >>> >>> with: >>> >>> >>> >>> >>> >> "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd";> >>> http://www.w3.org/1999/xhtml"; xml:lang="en" dir="ltr"> >>> >>> >> >> >> I do hope you didn't orphan a -tag there? >> > > LOL Good catch! > Nope. I guess my copy/paste skills aren't so good, when it comes > to my mail reader. :) > > This is the actual script I used: > > > fixem.sh #!/bin/sh - > # WARNING - there is NO turning back! > for name in $(find . -type f -name '*.html') do sed -f fixem.sed <$name > >temp.txt > mv temp.txt $name done rm -f temp.txt > > fixem.sed /\/d > s/\/\<\?xml\ version\=\"1\.0\"\ encoding\=\"UTF\-8\"\?\>\ \<\!DOCTYPE\ > html\ PUBLIC\ \"\-\/\/W3C\/\/DTD\ XHTML\ 1\.0\ Strict\/\/EN\"\ \ > \"http\:\/\/www\.w3\.org\/TR\/xhtml1\/DTD\/xhtml1\-strict\.dtd\"\>\ > \ dir\=\"ltr\"\>\ \/s OK I'm clearly crap when it comes to mail readers. Before someone points this out, I'll mention it now: the last line has a mistake dir\=\"ltr\"\>\ \/s should have been dir\=\"ltr\"\>\ \/g _^ in other words; should have ended with a "g" 'nuf said. --Chris > > > > --Chris > > > > > > >> >> >> Alban Hertroys >> >> >> >> -- >> If you can't see the forest for the trees, >> cut the trees and you'll see there is no forest. >> >> >> !DSPAM:74,4d2f565011879296619823! >> >> >> >> >> ___ >> freebsd-stable@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-stable >> To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" >> >> >> > > > -- > > > > ___ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" > > -- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: bind 9.6.2 dnssec validation bug
On Thu, February 10, 2011 2:47 pm, Ollivier Robert wrote: > According to Russell Jackson: > >> Looks like I should just suck it up and start using the bind97 port. >> > > Or switch to unbound. Unless you need/allow recursion for your internal || stealth || seconds/slaves In fact, that's the _only_ reason I haven't already switched to unbound. --Chris > > > -- > Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- robe...@keltia.freenix.fr > In memoriam to Ondine : http://ondine.keltia.net/ > ___ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" > > -- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: ATI Radeon LW RV200 Mobility 7500 M7 locks up on X exit
On Fri, February 11, 2011 11:12 am, Ted Faber wrote: > For the last couple weeks (maybe more) I've been having an intermittent > problem on my Thinkpad T42 where exiting X causes my screen to lock up and the > system seems to stop doing anything. Lately it's happening about every 3rd > time. > > The usual failure mode is that I select shutdown from the gnome menu and > it logs out with the console showing (text mode), but non responsive. The disk > LED lights intermittently, as can the LAN LED (though sometimes > it comes on solid). Sometimes it sort of shakes itself awake after a minute > or > so, but often the shutdown doesn't complete and I have to force a power cycle > and fsck everything. > > I don't get anything useful in /var/log/messages > > > I run a recent -STABLE > $ uname -a > FreeBSD praxis.lunabase.org 8.2-PRERELEASE FreeBSD 8.2-PRERELEASE #62: Sun Feb > 6 18:02:17 PST 2011 r...@praxis.lunabase.org:/usr/obj/usr/src/sys/GENERIC > i386 > > > I've attached a verbose boot dmesg and my xorg.conf, and the > /var/log/Xorg.0.log from a login. > > > Any help would be great. I noticed a potential issue in the output of your attached Xorg.conf. But as I don't have an immediate solution for that, I /will/ offer you some advice based on my experiences with recent versions of Xorg(1) on nVidia based cards. All the docs will advise the following two entries in your rc.cconf(5): hald_enable="YES" dbus_enable="YES" However, _unless_ I use the following, I will _always_ run into some sort of problem; hald_enable="NO" dbus_enable="YES" I have no idea what's going on with hald(8), but frankly, it appears nothing. Research on forums related to issues on nVidia & ATI video cards have many threads that ultimately point at issues using hald(8). Bottom line (for me anyway) has been that if I disable hald(8), I have nearly no (video related) issues. This is both on x86 && amd64 systems. HTH --Chris > > > > -- > http://www.lunabase.org/~faber > Unexpected attachment? http://www.lunabase.org/~faber/FAQ.html#SIG > > -- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: ATI Radeon LW RV200 Mobility 7500 M7 locks up on X exit
On Mon, February 14, 2011 10:21 am, Ted Faber wrote: > On Fri, Feb 11, 2011 at 10:52:43PM -0800, Chris H wrote: > >> I noticed a potential issue in the output of your attached Xorg.conf. >> > > Can you tell me what looked fishy? I'm happy to poke it it. > > >> Bottom line (for me anyway) has been that if I disable hald(8), I have nearly >> no (video related) issues. This is both on x86 && amd64 systems. > > When I turn off hald, X xan no longer find the mouse and keyboard. I > can probably hard wire them down, but I get the impression that lots of other > gnome-ish things will get confused w/o hald. dbus is still available, and should help here (still enabled). I'm /not/ on a GENERIC kernel, but here are some relevant pieces from my setup that might help; rc.conf(5) hald_enable="NO" dbus_enable="YES" xorg.conf(5) Section "ServerLayout" Identifier "X.org Configured" ... InputDevice"Mouse0" "CorePointer" InputDevice"Keyboard0" "CoreKeyboard" Section "ServerFlags" Option "AllowEmptyInput" "false" Option "AutoAddDevices""true" Option "AutoEnableDevices" "true" ... Section "InputDevice" Identifier "Keyboard0" Driver "kbd" EndSection Section "InputDevice" Identifier "Mouse0" Driver "mouse" Option "Protocol" "auto" Option "Device" "/dev/sysmouse" Option "ZAxisMapping" "4 5 6 7 8" ... I run Gnome && KDE(4.x) w/o any issues using this setup (no hald(8). I don't have your dmesg(8) output in front of me, at the momment. So I can't comment on what I felt might be "suspect". I might also note, that for awhile there, there were issues on laptops w/FreeBSD. I can't remember exactly, but I think it was related to (ACPI?). Essentially, it's related to the suspend/resume support in the FreeBSD kernel. Perhaps some additional "tweaks" might be found in the laptop section(s) in the FreeBSD docs, or list(s). HTH --Chris OH, one other thing that comes to mind; Did you let Xorg(1) create your xorg.conf(8) file? and if so (you /should/ have), what was the output? Again, if so, is that the conf file you're using now? > > -- > Ted Faber > http://www.isi.edu/~faber PGP: http://www.isi.edu/~faber/pubkeys.asc > Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#SIG > > -- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: ATI Radeon LW RV200 Mobility 7500 M7 locks up on X exit
On Mon, February 14, 2011 2:35 pm, Warren Block wrote: > On Mon, 14 Feb 2011, Chris H wrote: > > >> I'm /not/ on a GENERIC kernel, but here are some relevant pieces from >> my setup that might help; rc.conf(5) hald_enable="NO" dbus_enable="YES" > > Half a dozen machines here (roughly, it varies) say that hal is fine. > One of those machines is a T42, but needs updating to the latest > 8-stable. Apparently I put the significant files on the FLCL site a > while back: > http://laptop.bsdgroup.de/freebsd/index.html?action=show_laptop_detail&laptop=1 > 2947 > > >> xorg.conf(5) Section "ServerLayout" >> Identifier "X.org Configured" >> ... >> InputDevice"Mouse0" "CorePointer" >> InputDevice"Keyboard0" "CoreKeyboard" >> >> >> Section "ServerFlags" >> Option "AllowEmptyInput" "false" >> > > No, please stop doing that. See > http://www.wonkity.com/~wblock/docs/html/aei.html > > >> Option "AutoAddDevices""true" >> Option "AutoEnableDevices" "true" >> > > These are defaults. > > >> OH, one other thing that comes to mind; >> Did you let Xorg(1) create your xorg.conf(8) file? and if so (you /should/ >> have), what was the output? Again, if so, is that the conf file you're using >> now? > > Sorry, must disagree with that. -configure creates outmoded xorg.conf > files, with older options that are either no longer needed or outright > obsolete. > It also leaves out useful settings. So basically, Your saying it's all a "crap shoot", a "roll of the dice". The rule is; there is no rule. RTFM does not apply here. I was only speaking from my own experiences with this same problem. I own, and operate 30 FreeBSD boxes here. They range from 7.x-8.x, with the exception of 1 6.x. This problem began at RELENG_7 for me. I wrestled with it for quite some time - much of it on this mailing list. The only consistent thing I could find, was that DISabling hald(8) eliminated most of the issues I ran into. I discovered this was the same for many others, while reading about others with similar problems on the nVidia/ATI news forums. In fact the same consensus was had on the freebsd forums as well. As far as the Xorg(1) -configure goes. It's interesting that when I choose nvidia-xconfig to create the xorg.conf(5) file, with the exception of the additional nVidia specific options added, the rest looks nearly identical to those produced by Xorg(1) -configure. Well, that's how it all works out for me. Just thought I'd mention it. --Chris > ___ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" > > -- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: ATI Radeon LW RV200 Mobility 7500 M7 locks up on X exit
On Tue, February 15, 2011 12:21 pm, Warren Block wrote: > On Tue, 15 Feb 2011, Warren Block wrote: > > >> There are people who have difficulty with hal, and a much larger number who >> dislike it. I'd contend that problems with hal are not very widespread, or >> there would be a call for the Handbook X11 configuration section to change. > > Just to add something I should have mentioned in the first message: > > > One reason for problems with hal is the use of AllowEmptyInput "Off". > Usually it causes the "sticky mouse pointer" problem, but not always. > So many people were using AEI that I decided to write an article about > it: http://www.wonkity.com/~wblock/docs/html/aei.html Fun reading, thanks for sharing. :) purely a question of semantics; I notice you consistently use "On" || "Off" Xorg(1) -configure emits "true"||"false" Do you, or anyone else know conclusively whether it's simply a matter of: On||Off||true||false||1||0 or is it /only/ one, or more of the above pairs? Just curious. In your defense to an earlier comment I made; it essentially /is/ a "crap shoot" when it comes to setting up Xorg(1). While Xorg(1) -configure is intended to get a "functional" version of X(7) up, and running. Hardware, is not Hardware, is not Hardware. So a lot of "trial, and error" /will/ be required to obtain an "optimal" X(7) environment for a specific combination of hardware. :) --Chris > > > The short version of that: don't use AEI at all. If you want to > disable hal device detection in xorg, use AutoAddDevices Off, or build > xorg-server without hal support. > > If anyone has the lockup-on-x-exit problem and is using AEI Off, please > change it to AutoAddDevices Off and see if it makes a difference. It may > also be > due to window manager/desktop environment, or 32- or 64-bit OS. Mine have > mostly been xfce4 on 32-bit 8-stable, which may be why I haven't seen it. > ___ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" > > -- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: ATI Radeon LW RV200 Mobility 7500 M7 locks up on X exit
On Tue, February 15, 2011 4:05 pm, Warren Block wrote: > On Tue, 15 Feb 2011, Chris H wrote: > > >> On Tue, February 15, 2011 12:21 pm, Warren Block wrote: >> >>> So many people were using AEI that I decided to write an article about >>> it: http://www.wonkity.com/~wblock/docs/html/aei.html >>> >> Fun reading, thanks for sharing. :) >> > > Thanks! > > >> purely a question of semantics; I notice you consistently use "On" || "Off" >> Xorg(1) -configure emits "true"||"false" >> Do you, or anyone else know conclusively whether it's simply a matter of: >> On||Off||true||false||1||0 >> or is it /only/ one, or more of the above pairs? Just curious. > > "On" and "Off" are more readable to me, but you can use any of those. See > % man xorg.conf | less +/Boolean > > >> In your defense to an earlier comment I made; it essentially /is/ >> a "crap shoot" when it comes to setting up Xorg(1). While Xorg(1) -configure >> is >> intended to get a "functional" version of X(7) up, and running. Hardware, is >> not Hardware, is not Hardware. So a lot of "trial, and error" /will/ be >> required to obtain an "optimal" X(7) environment for a specific combination >> of >> hardware. :) > > Agreed, particularly for older hardware like this Dell 4300 with a > GeForce 440 card in it. Well, the box I'm writing this message from is running a G98 [GeForce 8400 GS] + 3Gb videoram, while not the "latest and greatest", it isn't really "legacy" either. I was /sure/ it'd be a "snap" to setup, but while "functional", it isn't the optimal experience I had hoped for. I guess that's the price one pays for choosing a "closed source" piece of hardware. :( --Chris > ___ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" > > -- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: ATI Radeon LW RV200 Mobility 7500 M7 locks up on X exit
> On Wed, Feb 16, 2011 at 12:07 PM, Chris H wrote: >> >> On Wed, February 16, 2011 1:34 am, Tom Evans wrote: >>> On Wed, Feb 16, 2011 at 12:19 AM, Chris H wrote: >>> >>>> Well, the box I'm writing this message from is running a >>>> G98 [GeForce 8400 GS] + 3Gb videoram, while not the "latest and greatest", >>>> it >>>> isn't really "legacy" either. I was /sure/ it'd be a "snap" to setup, but while >>>> "functional", it isn't the optimal experience I had hoped for. >>>> >>>> >>>> I guess that's the price one pays for choosing a "closed source" piece of >>>> hardware. :( >>>> >>>> --Chris >>>> >>>> >>> >>> I've used this card for 2 years with FreeBSD + hald, never had the >>> slightest issues, truly plug and play. >>> >>> nvidia0: on vgapci0 >>> nvidia-driver-256.53 NVidia graphics card binary drivers >> That's great news. I don't suppose you'd be willing to share your >> setup with me (xorg.conf, and anything else you think might help). I'd >> really love to get the most out of this card, but always felt a bit >> deprived. >> >> --Chris >> >> >> Sure, its attached. I should probably note that this isn't used as a >> 'PC', its hooked up to my TV, without a mouse or keyboard, and plays >> movies via mplayer (with vdpau acceleration). I also use a Geforce >> 7200 GS in my desktop machine (with keyboard + mouse!), for 3 years >> with no problems (no vdpau with that mind). >> >> Cheers >> >> Tom Well, I just wanted to report back that after comparing your settings in Xorg.conf(5) to my own, that /really/ the only significant difference was the omission of the following: InputDevice"Mouse0" "CorePointer" InputDevice"Keyboard0" "CoreKeyboard" Section "ServerFlags" Option "AllowEmptyInput" "false" Option "AutoAddDevices""true" Option "AutoEnableDevices" "true" EndSection Section "InputDevice" Identifier "Keyboard0" Driver "kbd" EndSection Section "InputDevice" Identifier "Mouse0" Driver "mouse" Option "Protocol" "auto" Option "Device" "/dev/sysmouse" Option "ZAxisMapping" "4 5 6 7 8" EndSection So I simply comment all of those lines from my own xorg.conf(5) file, changed the rc.conf(5) line: hald_enable="NO" to hald_enable="YES" rebooted > startx && all was well. Thanks for taking the time to share your conf file Tom, now I can live harmoniously with hald(8) :) --Chris -- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: FreeBSD partitioning
On Tue, March 22, 2011 2:24 pm, Jason Hsu wrote: > How does partitioning work in FreeBSD? GParted recognizes FAT16, FAT32, NTFS, > ext2, ext3, ext4, swap, and many other formats but labels the FreeBSD > partition > as unknown. Then there are the sub-partitions within the main FreeBSD > partition. GParted is not a "native" *BSD utility. It is mostly found on Linux recovery/ utility CD/DVD's. It is developed more with Linux in mind, and has always lacked ufs||ffs modules. So is not suitable for use on *BSD systems. It would be fairly trivial to create the modules to provide *BSD native support. But those who use the BSD family of operating systems fave found that sysinstall(8), fdisk(8) and related, are more than adequate to get the job done. There are also some very informative docs related to these tasks installed as part of your system, as well as available from: http://www.freebsd.org/docs.html It's hard to imagine needing anything else -- even if it's ones very first time. --Chris > > I'm finding it much more difficult to learn BSD than it was to learn Linux. > However, I'm sure it will be worth it, as BSD is legendary for stability and > is > the basis for Mac OS and other proprietary systems. > > -- > Jason Hsu > ___ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" > > -- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Constant rebooting after power loss
On Fri, April 1, 2011 6:29 am, Marko Lerota wrote: > George Kontostanos writes: > > >> Not with the same behavior and it depends on what your server is doing at >> the time of the power interruption. > > It was in stage of booting after first power loss. > > >> but ZFS is not the solution to your problem. ZFS is not designed to replace >> the needs of a UPS. > > I read that ZFS don't need fsck because the files are always consistent on filesystem regardless > of power loses. That the corruption can occur only if disks are damaged. But > not > when power goes down. Complete nonsense. The information you read was false. > > -- > Marko Lerota > Sent from my Gnus Mailer > ___ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" > > -- If only Western Electric had found a way to offer binary licenses for the UNIX system back in 1974, the UNIX system would be running on all PC's today rather than DOS/Windows. --en UNIX veritas! ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Constant rebooting after power loss
On Fri, April 1, 2011 10:38 am, Adam Vande More wrote: > On Fri, Apr 1, 2011 at 12:02 PM, Chris H wrote: > > >> On Fri, April 1, 2011 6:29 am, Marko Lerota wrote: >> >>> I read that ZFS don't need fsck because the files are always consistent >>> >> on filesystem regardless >>> of power loses. That the corruption can occur only if disks are damaged. >> But not >> >>> when power goes down. >> >> Complete nonsense. The information you read was false. >> >> > > No, it's really not. ZFS's lack of recovery tools at least in the > beginning were basically non existent. This is because ZFS uses a COW model > with an atomic data management unit design which by it's nature addresses > thing > like fsck, and sudden power loss. However, things outside of a FS's control > still allow corrution to happen so as UPS is just as important with ZFS as > your > traditional FS. Perhaps more important because the difficulty from recovering > from some types of pool corruption. > Greetings, Not to sound disagreeable, but if I interrupt the power during a disk write, no amount of ZFS will insure that the hardware completes it's write without electricity. Nor will any amount of ZFS prevent data corruption as a result of that interrupted write. > -- > Adam Vande More > > -- If only Western Electric had found a way to offer binary licenses for the UNIX system back in 1974, the UNIX system would be running on all PC's today rather than DOS/Windows. --en UNIX veritas! ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Masoom Shaikh invited you to Dropbox
Come on mate, that is low, this is a FreeBSD list, not an advertising list. On Wed, Apr 20, 2011 at 12:15 PM, Dropbox wrote: > Masoom Shaikh wants you to try Dropbox! Dropbox lets you bring all your > photos, docs and videos with you anywhere and share them easily. > > Get started here: > http://www.dropbox.com/link/20.f0ibMeMfFG/Njg3MzIzMzY1Nw?src=referrals_bulk9 > > - The Dropbox Team > > > To stop receiving invites from Dropbox, please go to > http://www.dropbox.com/bl/162777a02941/stable%40freebsd.org > ___ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" > ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
about thumper aka sun fire x4500
I have been beating on of these a few days, i have udes freebsd 9.0 and 8.2 Both fails when i engage > 10 disks, the system craches and messages : "Hyper transport sync flood" will get into the BIOS errorlog ( but nothing will come to syslog since reboot is immediate) Using a zfs radz of 25 disks and typing "zpool scrub" will bring the system down in seconds. Anyone using a x4500 that can comfirm that it works ? Or is this box broken ? -- Peter Håkanson There's never money to do it right, but always money to do it again ... and again ... and again ... and again. ( Det är billigare att göra rätt. Det är dyrt att laga fel. ) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: about thumper aka sun fire x4500
On Tuesday 17 January 2012 23.15, Ronald Klop wrote: > On Tue, 17 Jan 2012 18:59:08 +0100, peter h wrote: > > > I have been beating on of these a few days, i have udes freebsd 9.0 and > > 8.2 > > Both fails when i engage > 10 disks, the system craches and messages : > > "Hyper transport sync flood" will get into the BIOS errorlog ( but > > nothing will > > come to syslog since reboot is immediate) > > > > Using a zfs radz of 25 disks and typing "zpool scrub" will bring the > > system down in seconds. > > > > Anyone using a x4500 that can comfirm that it works ? Or is this box > > broken ? > > Does it work if you make 3 raid groups of 8 disks and 1 spare? No, i did not test this. I did some simple ones ( 5 disks in a raidz ) but what i wanted this box to do is a more powerful work. For smaller stuff i use simple hardware I guess i'll buy some supermicro box instead. > > Ronald. > ___ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" > > -- Peter Håkanson There's never money to do it right, but always money to do it again ... and again ... and again ... and again. ( Det är billigare att göra rätt. Det är dyrt att laga fel. ) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: about thumper aka sun fire x4500
On Tuesday 17 January 2012 22.52, Patrick M. Hausen wrote: > Hi, all, > > Am 17.01.2012 um 18:59 schrieb peter h : > > > I have been beating on of these a few days, i have udes freebsd 9.0 and 8.2 > > Both fails when i engage > 10 disks, the system craches and messages : > > "Hyper transport sync flood" will get into the BIOS errorlog ( but nothing > > will > > come to syslog since reboot is immediate) > > > > Using a zfs radz of 25 disks and typing "zpool scrub" will bring the system > > down in seconds. > > > > Anyone using a x4500 that can comfirm that it works ? Or is this box broken > > ? > > Well, I hate to write that, but ... does it work with the vendor supported > [tm] OS? > If yes, you can rule out a hardware defect. I would at least try Solaris for > this reason. > If no, the HW is broken and there is no need to look for a fault on FreeBSD's > side. > > Kind regards, > Patrick > today i installed nexenta ( 134) , built a simular raidz and it _seems_ to stay up. I'll come back when i have made the same pressure on it. -- Peter Håkanson There's never money to do it right, but always money to do it again ... and again ... and again ... and again. ( Det är billigare att göra rätt. Det är dyrt att laga fel. ) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: about thumper aka sun fire x4500
On Wednesday 18 January 2012 18.15, Adam McDougall wrote: > On 01/17/12 17:09, Jeremy Chadwick wrote: > > On Tue, Jan 17, 2012 at 06:59:08PM +0100, peter h wrote: > >> I have been beating on of these a few days, i have udes freebsd 9.0 and 8.2 > >> Both fails when i engage> 10 disks, the system craches and messages : > >> "Hyper transport sync flood" will get into the BIOS errorlog ( but nothing > >> will > >> come to syslog since reboot is immediate) > >> > >> Using a zfs radz of 25 disks and typing "zpool scrub" will bring the > >> system down in seconds. > >> > >> Anyone using a x4500 that can comfirm that it works ? Or is this box > >> broken ? > > > > I've seen what is probably the same base issue but on multiple x4100m2 > systems running FreeBSD 7 or 8 a few years ago. For me the instant > reboot and HT sync flood error happened when I fetched a ~200mb file via > HTTP using an onboard intel nic and wrote it out to a simple zfs mirror > on 2 disks. I may have tried the nvidia ethernet ports as an > alternative but that driver had its own issues at the time. This was > never a problem with FFS instead of ZFS. I could repeat it fairly > easily by running fetch in a loop (can't remember if writing the output > to disk was necessary to trigger it). The workaround I found that > worked for me was to buy a cheap intel PCIE nic and use that instead of > the onboard ports. If a zpool scrub triggers it for you, I doubt my > workaround will help but I wanted to relate my experience. The problem i had was most likley the disc-io itself. It was always there whenever a larger number of discs was in motion.It was never there as violent networking ( i even used myri2000 to increase traffic, never a problem) A scrub on the 20-or-so zpool was all that was needed, andn when rebooting the scrub continued and whoops - a new reboot. Sometimes the bios reported not even 16G mem but 10.5 ( which also freebsd noticed) Right now i am torturing the box with same load ( minus myri2000) and sunk-os, i'll report if it does show simular problems. > > > Given this above diagram, I'm sure you can figure out how "flooding" > > might occur. :-) I'm not sure what "sync flood" means (vs. I/O > > flooding). > > As I understand it, a sync flood is a purposeful reaction to an error > condition as somewhat of a last ditch effort to regain control over the > system (which ends up rebooting). I'm pulling this out of my memory > from a few years ago. > ___ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" > -- Peter Håkanson There's never money to do it right, but always money to do it again ... and again ... and again ... and again. ( Det är billigare att göra rätt. Det är dyrt att laga fel. ) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: about thumper aka sun fire x4500
On Tuesday 17 January 2012 22.52, Patrick M. Hausen wrote: > Hi, all, > > Am 17.01.2012 um 18:59 schrieb peter h : > > > I have been beating on of these a few days, i have udes freebsd 9.0 and 8.2 > > Both fails when i engage > 10 disks, the system craches and messages : > > "Hyper transport sync flood" will get into the BIOS errorlog ( but nothing > > will > > come to syslog since reboot is immediate) > > > > Using a zfs radz of 25 disks and typing "zpool scrub" will bring the system > > down in seconds. > > > > Anyone using a x4500 that can comfirm that it works ? Or is this box broken > > ? > > Well, I hate to write that, but ... does it work with the vendor supported > [tm] OS? > If yes, you can rule out a hardware defect. I would at least try Solaris for > this reason. > If no, the HW is broken and there is no need to look for a fault on FreeBSD's > side. > > Kind regards, > Patrick Yes, this computer stayus alive and works well with nexenta core ( a clone of sun-os) The conclusion is that something is missing in the dealing with hypertransport. A valid question might be : will other systems using hypertransport work or fail ? Is it a smb-issue ? Or is the problem specific for thumper hardware ? > -- Peter Håkanson There's never money to do it right, but always money to do it again ... and again ... and again ... and again. ( Det är billigare att göra rätt. Det är dyrt att laga fel. ) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
installworld: check your date/time - Installworld NOT possible...
Greetings, I've spent the morning grooming a fresh kernel on a freshly installed 8.1 amd64, from the DVD. I cvsup'd src && ports last night. Build world && kernel && installkernel went as anticipated. HOWEVER, a reboot to single user, followed by a mergemaster -p, followed by cd /usr/src && make installworld, returned: "/usr/src/Makefile", line 177: check your date/time: WTF? Should I simply comment lines 174-178? Why does make(1) refuse to installworld? My date and time are correct (in sync). Any insight into this error would be GREATLY appreciated. --Chris -- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: installworld: check your date/time - Installworld NOT possible...
Greetings, and thank you for your reply. On Thu, December 30, 2010 4:38 pm, Rob Farmer wrote: > On Thu, Dec 30, 2010 at 16:06, Chris H wrote: > >> Greetings, >> I've spent the morning grooming a fresh kernel on a freshly installed >> 8.1 amd64, from the DVD. I cvsup'd src && ports last night. >> Build world && kernel && installkernel went as anticipated. >> HOWEVER, a reboot to single user, followed by a mergemaster -p, followed by >> cd /usr/src && make installworld, returned: "/usr/src/Makefile", line 177: >> check your date/time: >> >> WTF? Should I simply comment lines 174-178? >> Why does make(1) refuse to installworld? My date and time are correct (in >> sync). Any insight into this error would be GREATLY appreciated. >> >> > > Did you run "adjkerntz -i" to set your timezone in single user? It > starts up with the assumption that your hardware clock is UTC - depending on > where you are (east/west of that), this can lead to files created in the > "future," which confuses make. Well, turns out that was the answer. I've got to tell you; I've performed _well_ over 1200 build/install world/kernel's over the last 30 years, and this was the _first_ time I've ever been required to do this extra step. In fact, I just finished 4 last week on the same ARCH. The only difference was that I used the 8.0 DVD for the initial install. Everything else was the same. Cvsupping src && ports brought them to 8.1-CURRENT, prior to the build/install world/kern. If I had to guess, I'd say that something changed on the 8.1 DVD, or _very_ recently on src. I didn't see anything in NOTES || README || UPDATING. Well, I _greatly_ appreciate your response, and wish you a _very_ happy new year! :) --Chris > > > -- > Rob Farmer > ___ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" > > > -- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Replace Cisco IOS/CBOS with freebsd - possible?
Greetings, I'm RP for a fairly large chunk of IP real estate. I carved out a /27 segment for my home network. Which is currently running over a cisco 837 GW (adsl/router). I'm not really keen on it (the router/modem). So I thought to myself that it couldn't be /that/ hard to build a box with FBSD that could replace it - am I crazy? Wouldn't it be possible to upload a minimal build of FBSD to the modem, not unlike one would tftp a new version of cisco's IOS, or CBOS? I searched the projects area to see if anyone had tried it. But the only thing that came anywhere near was netperf. But the only similarity is that it is network related. Anyway, this seems quite feasable as far as I can tell. So I thought I'd ask in hopes someone might enlighten me further. Maybe someones already tried it? Thank you for all your time and consideration in this matter. --Chris ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
RE: Replace Cisco IOS/CBOS with freebsd - possible?
Hello, and thank you for your reply. While it's not /exactly/ what I was looking for - it's close. :) The "filtering" capability is my biggest gripe on the Cisco *DSL products. They're just not as /capable/ as is offered in FBSD. DNS is another plus (pfDNS). But I don't think I'd be modify pfDNS to accomodate BIND, or unbound. Although tinydns might be able to fit the bill. Oh well, it's close - thanks for the pointer. :) --Chris Quoting Lawrence Farr : Have a look at pfsense, don't think it's what you want tho. -Original Message- From: owner-freebsd-sta...@freebsd.org [mailto:owner-freebsd- sta...@freebsd.org] On Behalf Of Chris H Sent: 29 January 2009 09:51 To: freebsd-stable@freebsd.org Subject: Replace Cisco IOS/CBOS with freebsd - possible? Greetings, I'm RP for a fairly large chunk of IP real estate. I carved out a /27 segment for my home network. Which is currently running over a cisco 837 GW (adsl/router). I'm not really keen on it (the router/modem). So I thought to myself that it couldn't be /that/ hard to build a box with FBSD that could replace it - am I crazy? Wouldn't it be possible to upload a minimal build of FBSD to the modem, not unlike one would tftp a new version of cisco's IOS, or CBOS? I searched the projects area to see if anyone had tried it. But the only thing that came anywhere near was netperf. But the only similarity is that it is network related. Anyway, this seems quite feasable as far as I can tell. So I thought I'd ask in hopes someone might enlighten me further. Maybe someones already tried it? Thank you for all your time and consideration in this matter. --Chris ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable- unsubscr...@freebsd.org" ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Replace Cisco IOS/CBOS with freebsd - possible?
Hello Michael, and thank you for your reply. Yes, OpenWRT is pretty much was what I was asking about. Being /exclusively/ FBSD I hadn't run across it - thanks. :) Of course it doesn't support any Cisco products, but hey, like you said; I can just choose one that it /does/, or write a driver myself. I was also looking at Sangoma's (http://www.sangoma.com) wanpipe (ftp://ftp.sangoma.com/FreeBSD/wanpipe/) as a possible base point. It already supports BSD and works with nearly all HW. But now - in an effort to stay on a BSD platform, I'm thinking of using a combination of nanobsd, and OpenWRT as a framework to build a FreeBSD based equivalent (or better) version of OpenWRT. I think I'll fly a page now to announce the project - look for it in a ports section near you. ;) Thank you again for the reply. --Chris Quoting Michael Grant : Check out OpenWRT, this is essentially linux (busybox on a linux kernel I believe) that you can load on a router and it runs on more than a handfull of routers. It's not freebsd. Not sure if the Cisco 837 is supported though, but many other routers are. If not supported, just go out and buy a cheap router that is supported and replace your cisco. Michael Grant On Thu, Jan 29, 2009 at 10:50 AM, Chris H wrote: Greetings, I'm RP for a fairly large chunk of IP real estate. I carved out a /27 segment for my home network. Which is currently running over a cisco 837 GW (adsl/router). I'm not really keen on it (the router/modem). So I thought to myself that it couldn't be /that/ hard to build a box with FBSD that could replace it - am I crazy? Wouldn't it be possible to upload a minimal build of FBSD to the modem, not unlike one would tftp a new version of cisco's IOS, or CBOS? I searched the projects area to see if anyone had tried it. But the only thing that came anywhere near was netperf. But the only similarity is that it is network related. Anyway, this seems quite feasable as far as I can tell. So I thought I'd ask in hopes someone might enlighten me further. Maybe someones already tried it? Thank you for all your time and consideration in this matter. --Chris ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Replace Cisco IOS/CBOS with freebsd - possible?
Hello, and thank you for your reply. Quoting Michael Grant : On Thu, Jan 29, 2009 at 2:15 PM, Chris H wrote: Hello, and thank you for your reply. While it's not /exactly/ what I was looking for - it's close. :) The "filtering" capability is my biggest gripe on the Cisco *DSL products. They're just not as /capable/ as is offered in FBSD. DNS is another plus (pfDNS). But I don't think I'd be modify pfDNS to accomodate BIND, or unbound. Although tinydns might be able to fit the bill. Oh well, it's close - thanks for the pointer. :) You can run iptables on openwrt. Actually, I was thinking more along the lines of pf(4). I think it's more efficient - especially combined with all the network tuning that has been done recently by Robert Watson, John Baldwin, Mohan Srinivasan, Peter Wemm, and others. Another reason I'm so inclined to be FBSD centric on this. :) You can compile most anything for it, you're only limited by it's memory and cpu. I'm not familiar with pfDNS. But if it runs on freebsd, it probably can be made to run on openwrt as well. Indeed, it's running a FreeBSD base. But like you said; CPU, and Memory are the only boundries here. Will need to do more research to compare limits against a /desired/ install base. Thanks again for the reply. --Chris Michael ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Replace Cisco IOS/CBOS with freebsd - possible?
Hello, and thank you for your reply. Quoting Chris Peterson : Pfsense sounds like exactly what you're looking for. It's a stripped down freeBSD Don't get me wrong, I think pfSense goes a long way to my intended goal - not the least of which, is pfDNS. I haven't written it off by any means. with a fancy web interface (well, not too fancy, To be honest - the first thing I'd do, is strip the (any) GUI stuff out. I have no issue with opening a terminal shell via cu - tip(1). In fact, for security reasons, I'd prefer to insure that the only access available is over a serial port (local). Not to mention the size/space savings gains. :) it's been incredibly stable for me). I've deployed it a couple times in pseudo production environments and it's been holding up well for the last 1.5years+. You can also check out http://www.netgate.com/product_info.php?cPath=60_84&products_id=492 for a nice PIX-sized chasis for pfsense if you need a small box. Looks intriguing. The only real advantage I see here, would be the amount of ram available. The 837 I propose to use, only supports 64Mb. Thanks again for your infoamative response. --Chris On Jan 29, 2009, at 6:02 AM, Chris H wrote: Hello, and thank you for your reply. Quoting Michael Grant : On Thu, Jan 29, 2009 at 2:15 PM, Chris H wrote: Hello, and thank you for your reply. While it's not /exactly/ what I was looking for - it's close. :) The "filtering" capability is my biggest gripe on the Cisco *DSL products. They're just not as /capable/ as is offered in FBSD. DNS is another plus (pfDNS). But I don't think I'd be modify pfDNS to accomodate BIND, or unbound. Although tinydns might be able to fit the bill. Oh well, it's close - thanks for the pointer. :) You can run iptables on openwrt. Actually, I was thinking more along the lines of pf(4). I think it's more efficient - especially combined with all the network tuning that has been done recently by Robert Watson, John Baldwin, Mohan Srinivasan, Peter Wemm, and others. Another reason I'm so inclined to be FBSD centric on this. :) You can compile most anything for it, you're only limited by it's memory and cpu. I'm not familiar with pfDNS. But if it runs on freebsd, it probably can be made to run on openwrt as well. Indeed, it's running a FreeBSD base. But like you said; CPU, and Memory are the only boundries here. Will need to do more research to compare limits against a /desired/ install base. Thanks again for the reply. --Chris Michael ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org " ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Replace Cisco IOS/CBOS with freebsd - possible?
Hello, and thank you for your reply. Quoting Oliver Pinter : http://m0n0.ch/wall/ ? Good candidate. Thanks for mentioning it. On the up side - it's FreeBSD based. :) I guess my only disappointments would be that configuration is done by way of PHP. But of course I could fix that. Doesn't provide swap space - this seems like this could be a real liability under heavy load/outside abuse, even with a decent amount of RAM/Memory. Thanks again for the reply. --Chris On 1/29/09, Chris H wrote: Greetings, I'm RP for a fairly large chunk of IP real estate. I carved out a /27 segment for my home network. Which is currently running over a cisco 837 GW (adsl/router). I'm not really keen on it (the router/modem). So I thought to myself that it couldn't be /that/ hard to build a box with FBSD that could replace it - am I crazy? Wouldn't it be possible to upload a minimal build of FBSD to the modem, not unlike one would tftp a new version of cisco's IOS, or CBOS? I searched the projects area to see if anyone had tried it. But the only thing that came anywhere near was netperf. But the only similarity is that it is network related. Anyway, this seems quite feasable as far as I can tell. So I thought I'd ask in hopes someone might enlighten me further. Maybe someones already tried it? Thank you for all your time and consideration in this matter. --Chris ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Replace Cisco IOS/CBOS with freebsd - possible?
Hello Bruce, and thank you for your reply. Quoting "Bruce M. Simpson" : SDH Support wrote: Seconded for Pfsense -- although I doubt the Cisco hardware would be compatible with FreeBSD, and even if it is , I wouldn't want to use it in a production environment without thorough testing. If someone can provide more detailed hardware specs, including the chipsets and processor details of the cisco hardware , im sure we could realistically evaluate the feasibility. Please see: https://bsdforge.net/cisco-data/ for a list of manuals I have available for download on these (and similar). I'm very, very happy with pfSense. It's a case of the folk behind it having followed an software appliance-style model and that's what makes it stable. I know Peter Grehan was looking at getting FreeBSD onto the Cisco 827 a while back. That's good news. I'll have to see if I can get more info on that. I just purchased a "lot" of cisco *DSL/routers on ebay, in an effort to push this project forward (I can experiment on these with less concern). So my list of HW now includes: * 3 - 802's * 2 - 1604's * 1 - 1721 * 2 - 837's Thank you again for your input. --Chris The PowerPC port has gone some way towards this, but I don't see folk installing it on old Cisco hardware yet... unless the knowledge gets out there. cheers BMS ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Replace Cisco IOS/CBOS with freebsd - possible?
Hello Bruce, and thank you for your reply. Quoting "Bruce M. Simpson" : Chris H wrote: ... I know Peter Grehan was looking at getting FreeBSD onto the Cisco 827 a while back. That's good news. I'll have to see if I can get more info on that. I just purchased a "lot" of cisco *DSL/routers on ebay, in an effort to push this project forward (I can experiment on these with less concern). IMHO pfSense beats the pants off OpenWRT from a user/deployment point of view, and often that is ultimately what counts. I guess I'd have to agree, except if it weren't for the fact I always have a zillion things going simultaneously, I wouldn't even know what X was - I can't get enough VC's (virtual consoles), so I'm forced to use X. But, of course for most "end users" /convenience/ is everything, and most don't want to any more that how to turn it on. :) Thing is, it's "only" for x86-based PCs. I had the foresight to purchase some relatively quiet 1U boxes, but they're still too noisy to have in a room where people sleep live or socialise -- they belong to the computer nook at the front of the apartment (I have a very odd C-shaped apartment). Yes, the (older) cisco's CPU's were MIPS - aka - Motorola, and ran AUX. I've got the latest version of AUX, which is a newer version than they ran. In fact, it wouldn't be a bit surprised if I could load AIX on it. I believe something that could really make pfSense fly, would be a viable port to mass-market, low-power consumer hardware. Then again, old Ciscos "sort of" fit the bill. Funny you bring that up. I was thinking the very same. As a matter of fact I have been contemplating whipping something up myself, and doing just that. While psSense initially seems appealing. The more I look into it, the more I find it's laking - where a simple roll-out is concerned. There isn't anything in the way of documentation. What's there is /horribly/ unorganized. It's scattered all over the place. What's more, the front page of the wiki suggests that reading the m0n0wall documentation would probabl;y be a better choice. Make no mistake, I know how daunting and hectic an opensource project can be, and am grateful to /anyone/ whom is willing to share the fruits of their labor at no cost. But I think I could do better, that's all. Repurposing old vendor hardware is just as subject to engineering process as anything else, in some cases, the varying Bill-of-Materials may make the economic cost too high to do things on a mass scale. I think I have a solution for that. I'll elaborate further when I can confirm that. If people would be reasonably expected to use such a system, they should not have to understand the mechanisms, in great detail, of how firmware is loaded onto a device. This is one of the main stumbling blocks behind mass uptake -- we can't just say "fire up this tool and click this 1 button" to extend/build new network infrastructure. Given the current economic and ecological situation, though, devising systems which allow people to do this might be something worth investigating, and funding to that effect may be available "out there". I /quite/ agree, and intend to persue just that. I've already commissioned the artwork - and it looks GREAT. :) I'll elaborate further as things firm up. Thanks again Bruce, for taking the time to respond. --Chris cheers BMS ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Replace Cisco IOS/CBOS with freebsd - possible?
Hello Patrick, and thank you for your reply. Quoting Patrick Mahan : Chris H presented these words - circa 1/30/09 7:03 AM-> Hello Bruce, and thank you for your reply. Quoting "Bruce M. Simpson" : Chris H wrote: ... I know Peter Grehan was looking at getting FreeBSD onto the Cisco 827 a while back. That's good news. I'll have to see if I can get more info on that. I just purchased a "lot" of cisco *DSL/routers on ebay, in an effort to push this project forward (I can experiment on these with less concern). IMHO pfSense beats the pants off OpenWRT from a user/deployment point of view, and often that is ultimately what counts. I guess I'd have to agree, except if it weren't for the fact I always have a zillion things going simultaneously, I wouldn't even know what X was - I can't get enough VC's (virtual consoles), so I'm forced to use X. But, of course for most "end users" /convenience/ is everything, and most don't want to any more that how to turn it on. :) Thing is, it's "only" for x86-based PCs. I had the foresight to purchase some relatively quiet 1U boxes, but they're still too noisy to have in a room where people sleep live or socialise -- they belong to the computer nook at the front of the apartment (I have a very odd C-shaped apartment). Yes, the (older) cisco's CPU's were MIPS - aka - Motorola, and ran AUX. I've got the latest version of AUX, which is a newer version than they ran. In fact, it wouldn't be a bit surprised if I could load AIX on it. Yes, most of the core CPU's used by Cisco were MIPS, however, they were not made by Motorola Please take no offense. But as I look inside, the CPU does, in fact say Motorola. The documentation for it also confirms that most of (if not all) of the 800 series also used the Motorola RISC. and didn't run AUX (if by AUX you mean Apples Unix OS). I probably stand corrected on this. :) But I'll bet - given the CPU, it wouldn't be much of a streatch to run either AUX, or AIX on it. Thanks again for your response. --Chris Instead they ran Cisco's own IOS kernel/software. Patrick Mahan I believe something that could really make pfSense fly, would be a viable port to mass-market, low-power consumer hardware. Then again, old Ciscos "sort of" fit the bill. Funny you bring that up. I was thinking the very same. As a matter of fact I have been contemplating whipping something up myself, and doing just that. While psSense initially seems appealing. The more I look into it, the more I find it's laking - where a simple roll-out is concerned. There isn't anything in the way of documentation. What's there is /horribly/ unorganized. It's scattered all over the place. What's more, the front page of the wiki suggests that reading the m0n0wall documentation would probabl;y be a better choice. Make no mistake, I know how daunting and hectic an opensource project can be, and am grateful to /anyone/ whom is willing to share the fruits of their labor at no cost. But I think I could do better, that's all. Repurposing old vendor hardware is just as subject to engineering process as anything else, in some cases, the varying Bill-of-Materials may make the economic cost too high to do things on a mass scale. I think I have a solution for that. I'll elaborate further when I can confirm that. If people would be reasonably expected to use such a system, they should not have to understand the mechanisms, in great detail, of how firmware is loaded onto a device. This is one of the main stumbling blocks behind mass uptake -- we can't just say "fire up this tool and click this 1 button" to extend/build new network infrastructure. Given the current economic and ecological situation, though, devising systems which allow people to do this might be something worth investigating, and funding to that effect may be available "out there". I /quite/ agree, and intend to persue just that. I've already commissioned the artwork - and it looks GREAT. :) I'll elaborate further as things firm up. Thanks again Bruce, for taking the time to respond. --Chris cheers BMS ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send a
Re: Replace Cisco IOS/CBOS with freebsd - possible?
Quoting Łukasz Bromirski : On 2009-01-30 03:18, Chris H wrote: Please see: https://bsdforge.net/cisco-data/ for a list of manuals I have available for download on these (and similar). What's the sense of downloading it from Your site, if cisco.com contains the files? Because I was asked for more info on my hardware, and I /knew/ where my documentation was. Why try to discover (or ask others to) where the docs were on Cisco's site - which would assume it still existed. I guess I could have summarized in one word - convenience. ;) Go to cisco.com->Products and choose from routers. Or go to cisco.com/univercd and look for older interface to manuals. Thanks for the pointers. -- "Don't expect me to cry for all the | Łukasz Bromirski reasons you had to die" -- Kurt Cobain |http://lukasz.bromirski.net ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
ACPI Error: A valid RSDP was not found 20090521 tbxfroot-309
Greetings, I am receiving the following in dmesg (verbose) during boot in 8-RELEASE (GENERIC) cvsuped 2009-12-08 @1am: ACPI Error: A valid RSDP was not found 20090521 tbxfroot-309 As I create the KERNCONF for this machine, I want to confirm that this message is caused by the fact that APM is shut off in the BIOS, and won't cause any averse problems. We're having issues with "timeout" errors on some 50 TYAN server MB's since 7-RELEASE regarding the disk media (no matter how many different drives we use). So as I attempt to create a STABLE - in the sense that the servers are reliable, I want to eliminate any potential issues. more (informational) "noise" follows: CPU: Intel Pentium III Origin = "GenuineIntel" Id = 0x686 Stepping = 6 kernel: Features=0x387fbff Instruction TLB: 4 KB pages, 4-way set associative, 32 entries Instruction TLB: 4 MB pages, fully associative, 2 entries Data TLB: 4 KB pages, 4-way set associative, 64 entries 2nd-level cache: 256 KB, 8-way set associative, 32 byte line size 1st-level instruction cache: 16 KB, 4-way set associative, 32 byte line size Data TLB: 4 MB Pages, 4-way set associative, 8 entries 1st-level data cache: 16 KB, 4-way set associative, 32 byte line size real memory = 1073741824 (1024 MB) Physical memory chunk(s): 0x1000 - 0x0009efff, 647168 bytes (158 pages) 0x0010 - 0x003f, 3145728 bytes (768 pages) 0x01026000 - 0x3edb4fff, 1037627392 bytes (253327 pages) avail memory = 1036378112 (988 MB) ACPI Error: A valid RSDP was not found 20090521 tbxfroot-309 MP Configuration Table version 1.4 found at 0xc00f0db0 APIC: Using the MPTable enumerator. SMP: Added CPU 0 (BSP) SMP: Added CPU 1 (AP) MPTable: INTR: Adding local APIC 1 as a target FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs FreeBSD/SMP: 2 package(s) x 1 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 bios32: Found BIOS32 Service Directory header at 0xc00fdb90 bios32: Entry = 0xfdba0 (c00fdba0) Rev = 0 Len = 1 pcibios: PCI BIOS entry at 0xf+0xdbc1 pnpbios: Found PnP BIOS data at 0xc00f4c50 pnpbios: Entry = f:3954 Rev = 1.0 Other BIOS signatures found: ULE: setup cpu 0 ULE: setup cpu 1 ioapic0: Assuming intbase of 0 ioapic0: Routing external 8259A's -> intpin 0 ioapic1: Assuming intbase of 16 ioapic0: intpin 10 bus PCI ioapic0: intpin 10 trigger: level ioapic0: intpin 10 polarity: low ioapic0: Routing IRQ 0 -> intpin 2 lapic: Routing ExtINT -> LINT0 lapic: LINT0 trigger: edge lapic: LINT0 polarity: high lapic: Routing NMI -> LINT1 lapic: LINT1 trigger: edge lapic: LINT1 polarity: high ioapic0 irqs 0-15 on motherboard ioapic1 irqs 16-31 on motherboard cpu0 BSP: ID: 0x VER: 0x00040011 LDR: 0x DFR: 0x lint0: 0x00010700 lint1: 0x0400 TPR: 0x SVR: 0x01ff timer: 0x000100ef therm: 0x err: 0x0001000f pcm: 0x00010400 wlan: <802.11 Link Layer> kbd: new array size 4 kbd1 at kbdmux0 mem: Pentium Pro MTRR support enabled null: random: nfslock: pseudo-device io: hptrr: RocketRAID 17xx/2xxx SATA controller driver v1.2 ACPI Error: A valid RSDP was not found 20090521 tbxfroot-309 ACPI: Table initialisation failed: AE_NOT_FOUND ACPI: Try disabling either ACPI or apic support. npx0: INT 16 interface pci_open(1): mode 1 addr port (0x0cf8) is 0x8070 pci_open(1a): mode1res=0x8000 (0x8000) pci_cfgcheck: device 0 [class=06] [hdr=80] is there (id=00091166) pcibios: BIOS version 2.10 pcib0: pcibus 0 on motherboard pci0: on pcib0 pci0: domain=0, physical bus=0 found-> vendor=0x1166, dev=0x0009, revid=0x06 domain=0, bus=0, slot=0, func=0 class=06-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0006, statreg=0x2200, cachelnsz=8 (dwords) lattimer=0x20 (960 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x1166, dev=0x0009, revid=0x06 domain=0, bus=0, slot=0, func=1 class=06-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0007, statreg=0x0200, cachelnsz=8 (dwords) lattimer=0x10 (480 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x1002, dev=0x4752, revid=0x27 domain=0, bus=0, slot=1, func=0 class=03-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0080, statreg=0x0290, cachelnsz=8 (dwords) lattimer=0x40 (1920 ns), mingnt=0x08 (2000 ns), maxlat=0x00 (0 ns) intpin=a, irq=255 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type Memory, range 32, base 0xfb00, size 24, memory disabled map[14]: type I/O Port, range 32, base 0xd800, size 8, port disabled map[18]: type Memory, range 32, base 0xfcaff000, size 12, enabled found-> vendor=0x8086, dev=0x1229, revid=0x08 domain=0, bus=0, slot=4, func=0 class=02-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0117, statreg=0x0290, cachelnsz=8 (dwords) lattimer=0x40 (1920 ns), mingnt=0x08 (2000 ns), maxlat=0x38 (14000 ns) intpin=a, irq=10 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type Memory, range 32, base 0xfcafe000, size 12, enabled map[14]: type I/O Port, range 32, base 0xd400, size 6, enabled map[18]: type Memory, range 32, base
Re: ACPI Error: A valid RSDP was not found 20090521 tbxfroot-309
On Wed, December 9, 2009 6:50 am, John Baldwin wrote: > On Tuesday 08 December 2009 7:06:18 pm Chris H wrote: > >> Greetings, >> I am receiving the following in dmesg (verbose) during boot in 8-RELEASE >> (GENERIC) >> cvsuped 2009-12-08 @1am: ACPI Error: A valid RSDP was not found 20090521 >> tbxfroot-309 >> >> As I create the KERNCONF for this machine, I want to confirm that this >> message is caused by the fact that APM is shut off in the BIOS, and won't >> cause any averse problems. We're having issues with "timeout" errors on some >> 50 TYAN server MB's >> since 7-RELEASE regarding the disk media (no matter how many different drives >> we use). So as I attempt to create a STABLE - in the sense that the servers >> are reliable, I want to eliminate any potential issues. >> >> more (informational) "noise" follows: > > You can ignore the message, I do think it is due to disabling ACPI in your > BIOS. Do you have problems when ACPI is enabled? ACPI is generally going to > be more reliable than !ACPI in the future as it seems many BIOS vendors no > longer > test the !ACPI case as much (e.g. I've seen Intel motherboards with incomplete > or incorrect MP Tables because no commercial OS uses the MP Table anymore). Hello, and thank you very much for your reply. So the message is simply "informative" - good to know. As to the ACPI. Closer examination seemed to indicate the BIOS was incomplete. While I could have flashed it, assuming that it 1) would have all current updates 2) it would then also be complete I opted to simply take another new board off the shelf and try again. This time, taking your advice, and /enabling/ full ACPI. I performed an install, and just now cvsupped src && ports. It's in the process of building world/kernel as I write this reply. Hope all turns out well - "Fingers crossed". :) If you (or anyone else) can tell me... I have had issues with periodic "timeouts" with disks (SCSI,ATA && CD/DVD ROMS) ever since late 6. After experimenting with /many/ kernels. I'm left with the suspicion the it has to do with SCHED_4BSD vs. SCHED_ULE. In other words, ever since SCHED_ULE became default/preferred most of the PIII based boards have exhibited this anomaly. Often the "retries" aren't exhausted, and they recover. But many times they don't which will lead to freeze that requires "bouncing" the machine, and performing FSCK(8). I haven't seen anything in UPDATING. But wonder; should I assume that anything in the PIII category /requires/ SCHED_4BSD. Or would it be better to tune a kernel via SYSCTL(8)? Thank you again for all your time and consideration --Chris H > > -- > John Baldwin > > ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: RELENG_8 buildworld broken?
On Wed, December 9, 2009 3:33 pm, Pieter de Goeje wrote: > On Wednesday 09 December 2009 23:14:13 ocean wrote: > >> Pieter de Goeje wrote: >> >>> Actually, the way you specified CFLAGS overrides CPUTYPE. AFAIK you >>> should set CFLAGS/CPUTYPE like this: CPUTYPE?= >>> CFLAGS+=... >>> >>> >>> Though bothering with CPUTYPE or CFLAGS is actually a waste of time if >>> you ask me. I've never observed any measurable improvement in the speed of >>> the system by setting these. Note that most ports which DO benefit from >>> specialized CFLAGS (mplayer comes to mind) have an option called >>> WITH_OPTIMIZED_CFLAGS. >>> >> >> i specified it with CPUTYPE?=... and wasn't working for buildworld, had to >> add >> it in CFLAGS. also doing "make buildworld CPUTYPE=..." didn't work. > It works for me. Just tried with CPUTYPE?=nocona and CFLAGS+=-O3 which > resulted in these CFLAGS: -O2 -pipe -O3 -march=nocona when building tcsh for > example. Not everything build during buildworld honors these settings btw. > > > My point still stands though, I can't see how any of the base tools would > benefit from higher optimization levels. The only thing that could possibly > benefit is the kernel, but the kernel uses COPTFLAGS (and CPUTYPE). I think OPENSSL is another. I have always polluted /etc/make.conf for this purpose. As memory serves, the following was the "advised" method. For example I use: make.conf: CPUTYPE?=cray bulildworld && kernel: make -DALWAYS_CHECK_MAKE buildworld && kernel Still works for me ( <=7-RELEASE; 8_RELEASE is building as I write this ). --Chris H > >> >> on my (old) notebook i noticed good improvements in the boot process, it was >> taking lot of time to start maybe one minute, with a recompiled kernel with >> ipv6. without ipv6 with tweaked CFLAGS boots in less than 30 seconds (~24 >> seconds). > Most likely the difference was cause by leaving out IPv6, not by the CFLAGS. > > > - Pieter > ___ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" > > ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: ACPI Error: A valid RSDP was not found 20090521 tbxfroot-309
Hello, and thank you very much for your reply. On Thu, December 10, 2009 5:48 am, John Baldwin wrote: > On Wednesday 09 December 2009 8:52:06 pm Chris H wrote: > >> On Wed, December 9, 2009 6:50 am, John Baldwin wrote: >> >>> On Tuesday 08 December 2009 7:06:18 pm Chris H wrote: >>> >>> >>>> Greetings, >>>> I am receiving the following in dmesg (verbose) during boot in 8-RELEASE >>>> (GENERIC) >>>> cvsuped 2009-12-08 @1am: ACPI Error: A valid RSDP was not found 20090521 >>>> tbxfroot-309 >>>> >>>> As I create the KERNCONF for this machine, I want to confirm that this >>>> message is caused by the fact that APM is shut off in the BIOS, and won't >>>> cause any averse problems. We're having issues with "timeout" errors on >>>> some 50 TYAN server MB's >>>> since 7-RELEASE regarding the disk media (no matter how many different >>>> drives we use). So as I attempt to create a STABLE - in the sense that the >>>> servers are reliable, I want to eliminate any potential issues. >>>> >>>> more (informational) "noise" follows: >>> >>> You can ignore the message, I do think it is due to disabling ACPI in your >>> BIOS. Do you have problems when ACPI is enabled? ACPI is generally going >>> to be more reliable than !ACPI in the future as it seems many BIOS vendors >>> no longer test the !ACPI case as much (e.g. I've seen Intel motherboards >>> with incomplete or incorrect MP Tables because no commercial OS uses the MP >>> Table anymore). >>> >> >> Hello, and thank you very much for your reply. >> So the message is simply "informative" - good to know. >> As to the ACPI. Closer examination seemed to indicate the BIOS was >> incomplete. >> While I could have flashed it, assuming that it 1) would have all current >> updates 2) it would then also be complete >> I opted to simply take another new board off the shelf and try again. This >> time, taking your advice, and /enabling/ full ACPI. I performed an install, >> and just now cvsupped src && ports. It's in the process of building >> world/kernel as I write this reply. Hope all turns out well - "Fingers >> crossed". :) > > Ok. > FreeBSD 8.0-STABLE FreeBSD 8.0-STABLE #0: Thu Dec 10 01:10:25 PST 2009 i386 All completed as intended. only 1 timeout error at the /very/ beginning. Which was very short, and recovered immediately. > >> If you (or anyone else) can tell me... >> I have had issues with periodic "timeouts" with disks (SCSI,ATA && CD/DVD >> ROMS) >> ever since late 6. After experimenting with /many/ kernels. I'm left with the >> suspicion the it has to do with SCHED_4BSD vs. SCHED_ULE. In other words, >> ever since SCHED_ULE became default/preferred most of the PIII based boards >> have exhibited this anomaly. Often the "retries" aren't exhausted, and they >> recover. But many times they don't which will lead to freeze that requires >> "bouncing" the >> machine, and performing FSCK(8). I haven't seen anything in UPDATING. But >> wonder; should I assume that anything in the PIII category /requires/ >> SCHED_4BSD. Or >> would it be better to tune a kernel via SYSCTL(8)? > > Hmmm, there isn't anything CPU-specific in ULE vs 4BSD, and I would expect > ULE to work fine on a PIII. I would generally expect device timeouts to be > more of a driver issue than a scheduler issue. > Ahh, I see. Good to know. I'm not sure where to try and "tune" things in this regard. I can say that the timeouts /only/ occur during writes, and even then, only during "bursts" of large, or many writes. Example output emitted from one of the drives: (da1:ahc0:0:2:0): Request Requeued (da1:ahc0:0:2:0): Retrying Command (da1:ahc0:0:2:0): Request Requeued (da1:ahc0:0:2:0): Retrying Command (da1:ahc0:0:2:0): Request Requeued (da1:ahc0:0:2:0): Retrying Command (da1:ahc0:0:2:0): Request Requeued (da1:ahc0:0:2:0): Retrying Command (da1:ahc0:0:2:0): Queue Full (da1:ahc0:0:2:0): Retrying Command (da1:ahc0:0:2:0): tagged openings now 64 While this new install seems to be better that previous installs in this regard. I experimented with several drives on this board. ATA disks seemed to be more problematic than SCSI. So I opted to only use SCSI drives on this board with the exception of 1 DVDRW, and 1 CDROM - each as master on ports 0, and 1. I should probably mention that the SCSI ports are driven by Adaptec onboard controllers . The Drives were both "blanked" (formatted
MTRR failure revisited (nVidia) 8-STABLE/RELEASE
Greetings, I brought this same error to the list back in May 2009. Under: failed to set mtrr: invalid argument. Well, I'm back using the same card: GeForce4 MX 440-SE - VideoRam 65536 - BusID PCI:1:3:0. The driver is different, I'm using: nvidia-driver-96.43.13 out of ports on a custom 8-STABLE kernel. Xorg starts up, and produces a desktop. But it's "dog slow", and the nvidia driver emits the following error: NVIDIA: failed to set MTRR 0xf000, 0M (write-combining) several times. I understand John Baldwin provided some "invaluable" help some time ago: http://lists.freebsd.org/pipermail/freebsd-hackers/2006-June/016995.html and I was wondering if anyone has gained any further "insight" with these cards, and how to better "interface" them in BSD. Last I spoke on the topic, I was informed that the memory was basically "untouchable" - or perhaps in other words; can't be manipulated. Has this changed? Surely someone else has had to deal with this besides me. It seems crazy to spend a "boat load" of $$ on these high performers, and not be able to use them on a high performing OS - no? :) Sure, the one I'm working with now is "legacy". But I have 3 near new, top of their line cards, and thus far it appears that if I ever hope to use them, I'll be forced to... hack, choke.. spin up a WIN CD. :( Thank you for all your time, consideration, and insight. --Chris H ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: MTRR failure revisited (nVidia) 8-STABLE/RELEASE
On Sat, December 12, 2009 6:36 am, Robert Noland wrote: > On Sat, 2009-12-12 at 03:47 -0800, Chris H wrote: > >> Greetings, >> I brought this same error to the list back in May 2009. >> Under: failed to set mtrr: invalid argument. >> Well, I'm back using the same card: >> GeForce4 MX 440-SE - VideoRam 65536 - BusID PCI:1:3:0. >> The driver is different, I'm using: nvidia-driver-96.43.13 out of ports on a >> custom 8-STABLE kernel. Xorg starts up, and produces a desktop. But it's "dog >> slow" UPDATE: Disabling HAL /greatly/ increased performance eg; hal_enable="YES" --> hal_enable="NO" in /etc/rc.conf More specifically, response times are now closer to what one would anticipate/ expect now that HAL has been dis-abled in rc.conf. >> , and the nvidia driver emits the following error: NVIDIA: failed to set >> MTRR 0xf000, 0M (write-combining) >> several times. I understand John Baldwin provided some "invaluable" help some >> time ago: >> http://lists.freebsd.org/pipermail/freebsd-hackers/2006-June/016995.html >> and I was wondering if anyone has gained any further "insight" with these >> cards, and how to better "interface" them in BSD. Last I spoke on the topic, >> I >> was informed that the memory was basically "untouchable" - or perhaps in >> other >> words; can't be manipulated. Has this changed? Surely someone else has had to >> deal with this besides me. It seems crazy to spend a "boat load" of $$ on >> these high performers, and not be able to use them on a high performing OS - >> no? :) Sure, the one I'm working with now is "legacy". But I have 3 near new, >> top of their line cards, and thus far it appears that if I ever hope to use >> them, I'll be forced to... hack, choke.. spin up a WIN CD. :( >> >> Thank you for all your time, consideration, and insight. >> Greetings Robert, and thank you for taking the time to respond. > > The mtrr issue has to do with the system / bios, not the graphics card. > While I've not used the blob driver, the issue in Nouveau and other drm > drivers is that on many systems if you run "memcontrol list", you will see a > line > something like this: > > 0x0/0x1 BIOS write-back set-by-firmware active I see the following (condensed for brevity): 0x0/0x1 BIOS write-back fixed-base fixed-length set-by-firmware active 0x1/0x1-0x7/0x1 BIOS write-back fixed-base fixed-length set-by-firmware active 0x8/0x4000 BIOS-0x9c000/0x4000 write-back fixed-base fixed-length set-by-firmware active 0xa/0x4000-0xbc000/0x4000 BIOS uncacheable fixed-base fixed-length set-by-firmware active 0xc/0x1xc7000/0x1000 BIOS write-protect fixed-base fixed-length set-by-firmware active 0xc8000/0x1000-0xff000/0x1000 BIOS uncacheable fixed-base fixed-length set-by-firmware active 0x0/0x4000 BIOS write-back set-by-firmware active 0xe000/0x2000 BIOS uncacheable set-by-firmware active While I could pull the BIOS out of it's socket after POST. I don't suppose I could read it's contents to file, and then allow manipulation of the regions currently "off limits"? > > > This says that all of memory defaults to write-back. We aren't allowed > to overlap write-combined on top of write-back, so the setting of mtrr fails. Isn't it /best/ to choose write-back, so as to mark the memory dirty? I /could/ choose write-ahead, or write-through. > I've looked at ways to try to fix this in the past, but > generally found it more practical to use PAT than try to override/fix bios > behavior. Marius Nünnerich also mentioned this in a response to this thread. Would you be willing to share any additional information, based on your experiences using PAT? > > I've been told that linux does apply some BIOS fixups to address this > issue, which I might look into again, but I make no promises. Is there anything I could do that would help you in this regard? There are also a > very limited number of variable mtrr registers (7 on most hardware, iirc) for > managing caching. Thank you again for taking the time to respond. --Chris H > > robert. > >> --Chris H >> >> >> >> ___ >> freebsd-stable@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-stable >> To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" >> > -- > Robert Noland > FreeBSD > > > ___ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" > > ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: MTRR failure revisited (nVidia) 8-STABLE/RELEASE
On Sun, December 13, 2009 6:04 am, Robert Noland wrote: > On Sat, 2009-12-12 at 20:08 -0800, Chris H wrote: > >> On Sat, December 12, 2009 6:36 am, Robert Noland wrote: >> >>> On Sat, 2009-12-12 at 03:47 -0800, Chris H wrote: >>> >>> >>>> Greetings, >>>> I brought this same error to the list back in May 2009. >>>> Under: failed to set mtrr: invalid argument. >>>> Well, I'm back using the same card: >>>> GeForce4 MX 440-SE - VideoRam 65536 - BusID PCI:1:3:0. >>>> The driver is different, I'm using: nvidia-driver-96.43.13 out of ports on >>>> a custom 8-STABLE kernel. Xorg starts up, and produces a desktop. But it's >>>> "dog >>>> slow" >> UPDATE: >> Disabling HAL /greatly/ increased performance >> eg; hal_enable="YES" --> hal_enable="NO" in /etc/rc.conf More specifically, >> response times are now closer to what one would anticipate/ expect now that >> HAL has been dis-abled in rc.conf. >> >>>> , and the nvidia driver emits the following error: NVIDIA: failed to set >>>> MTRR 0xf000, 0M (write-combining) >>>> several times. I understand John Baldwin provided some "invaluable" help >>>> some time ago: >>>> http://lists.freebsd.org/pipermail/freebsd-hackers/2006-June/016995.html >>>> and I was wondering if anyone has gained any further "insight" with these >>>> cards, and how to better "interface" them in BSD. Last I spoke on the >>>> topic, I was informed that the memory was basically "untouchable" - or >>>> perhaps in other words; can't be manipulated. Has this changed? Surely >>>> someone else has had to deal with this besides me. It seems crazy to spend >>>> a "boat load" of $$ on these high performers, and not be able to use them >>>> on a high performing OS - no? :) Sure, the one I'm working with now is >>>> "legacy". But I have 3 near new, >>>> top of their line cards, and thus far it appears that if I ever hope to >>>> use them, I'll be forced to... hack, choke.. spin up a WIN CD. :( >>>> >>>> Thank you for all your time, consideration, and insight. >>>> >>>> >> Greetings Robert, and thank you for taking the time to respond. >> >>> >>> The mtrr issue has to do with the system / bios, not the graphics card. >>> While I've not used the blob driver, the issue in Nouveau and other drm >>> drivers is that on many systems if you run "memcontrol list", you will see a >>> line something like this: >>> >>> 0x0/0x1 BIOS write-back set-by-firmware active >>> >> I see the following (condensed for brevity): >> 0x0/0x1 BIOS write-back fixed-base fixed-length set-by-firmware active >> 0x1/0x1-0x7/0x1 BIOS write-back fixed-base fixed-length >> set-by-firmware active 0x8/0x4000 BIOS-0x9c000/0x4000 write-back >> fixed-base >> fixed-length set-by-firmware active 0xa/0x4000-0xbc000/0x4000 BIOS >> uncacheable fixed-base fixed-length set-by-firmware active >> 0xc/0x1xc7000/0x1000 BIOS write-protect fixed-base fixed-length >> set-by-firmware active 0xc8000/0x1000-0xff000/0x1000 BIOS uncacheable >> fixed-base fixed-length set-by-firmware active 0x0/0x4000 BIOS write-back >> set-by-firmware active Hello Robert, and thank you for your thoughtful response. > > The above entry is the one that causes setting write-combine MTRR to > fail. > >> 0xe000/0x2000 BIOS uncacheable set-by-firmware active >> >> >> While I could pull the BIOS out of it's socket after POST. I don't suppose >> I could read it's contents to file, and then allow manipulation of the >> regions currently "off limits"? > > This is more easily achieved in our MTRR code I expect, certainly than > BIOS hacking all of the effected machines. Frankly, all of my more > modern machines have this issue. > Ahhh, OK. >>> >>> This says that all of memory defaults to write-back. We aren't allowed >>> to overlap write-combined on top of write-back, so the setting of mtrr >>> fails. >> Isn't it /best/ to choose write-back, so as to mark the memory dirty? I >> /could/ >> choose write-ahead, or write-through. >>> I've looked at ways to try to fix this in the past, but >>> generally found it more practical to use PAT than try to override/fix bios >&
SSL appears to be broken in 8-STABLE/RELEASE
Greetings, A recent (cvs checkout of src/ports on 2009-12-09) install of 8 seems to indicate that changes in SSL have made it virtually unusable. I've spent the past 3 days attempting to (re)create an SSL enabled virtual host that serves web based access to local mail. Since it's local, I'm using self-signed certs following a scheme that has always worked flawlessly for the past 9 yrs. However, now having installed 8, it isn't working. The browser(s) throw "ssl_error_handshake_failure_alert" (ff-3.56). Other gecko based, and non-gecko based UA's throw similar, as well as openssl's s_client. After immense research, the only thing I can find that might best explain it is a recent SA patch applied to FreeBSD's src (SA-09:15). After reading what the patch provides. I am able to better understand the error messages thrown to /var/messages when attempting to negotiate a secure session in a UA: kernel: TCP: [web.server.host.IP]:59735 to [web.server.host.IP]:443 tcpflags 0x18; tcp_do_segment: FIN_WAIT_2: Received 37 bytes of data after socket was closed, sending RST and removing tcpcb kernel: TCP: [web.server.host.IP]:59735 to [web.server.host.IP]:443 tcpflags 0x11; syncache_expand: Segment failed SYNCOOKIE authentication, segment rejected (probably spoofed) kernel: TCP: [web.server.host.IP]:52153 to [web.server.host.IP]:443 tcpflags 0x18; tcp_do_segment: FIN_WAIT_2: Received 37 bytes of data after socket was closed, sending RST and removing tcpcb kernel: TCP: [web.server.host.IP]:52153 to [web.server.host.IP]:443 tcpflags 0x11; syncache_expand: Segment failed SYNCOOKIE authentication, segment rejected (probably spoofed) kernel: TCP: [web.server.host.IP]:60382 to [web.server.host.IP]:443 tcpflags 0x18; tcp_do_segment: FIN_WAIT_2: Received 37 bytes of data after socket was closed, sending RST and removing tcpcb kernel: TCP: [web.server.host.IP]:60382 to [web.server.host.IP]:443 tcpflags 0x11; syncache_expand: Segment failed SYNCOOKIE authentication, segment rejected (probably spoofed) So, if I understand things correctly. The patch prevents (re)negotiation. Making the likelihood of a successful "handshake" near null (as the log messages above show). I'm sure that some may be quick to point the finger at the self-signed cert being more likely the cause, I should add that while in fact quite unlikely, I too didn't completely rule that out. So I purchased one from startssl - money wasted. The results were the same. So it would appear that until something else is done to overcome the hole in current openssl, my only recourse is to back the patch out, and rebuild openssl && all affected ports - no? Thank you for all your time and consideration in this matter. --Chris H ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: SSL appears to be broken in 8-STABLE/RELEASE
Hello Peter, and thank you for the reply. > On 2009-12-18 05:32:41PM -0800, Chris H wrote: > >> Greetings, >> A recent (cvs checkout of src/ports on 2009-12-09) install of 8 seems to >> indicate that changes in SSL have made it virtually unusable. I've spent the >> past 3 days attempting to (re)create an SSL enabled virtual host that serves >> web based access to local mail. Since it's local, I'm using self-signed certs >> following a scheme that has always worked flawlessly for the past 9 yrs. >> However, now having installed 8, >> it isn't working. The browser(s) throw "ssl_error_handshake_failure_alert" >> (ff-3.56). >> Other gecko based, and non-gecko based UA's throw similar, as well as >> openssl's s_client. After immense research, the only thing I can find that >> might best explain it is a recent SA patch applied to FreeBSD's src >> (SA-09:15). After reading what the >> patch provides. I am able to better understand the error messages thrown to >> /var/messages when attempting to negotiate a secure session in a UA: >> >> >> kernel: TCP: [web.server.host.IP]:59735 to [web.server.host.IP]:443 tcpflags >> 0x18; tcp_do_segment: FIN_WAIT_2: Received 37 bytes of data after >> socket was closed, sending RST and removing tcpcb kernel: TCP: >> [web.server.host.IP]:59735 to [web.server.host.IP]:443 tcpflags >> 0x11; syncache_expand: Segment failed SYNCOOKIE authentication, >> segment rejected (probably spoofed) kernel: TCP: [web.server.host.IP]:52153 >> to >> [web.server.host.IP]:443 tcpflags >> 0x18; tcp_do_segment: FIN_WAIT_2: Received 37 bytes of data after >> socket was closed, sending RST and removing tcpcb kernel: TCP: >> [web.server.host.IP]:52153 to [web.server.host.IP]:443 tcpflags >> 0x11; syncache_expand: Segment failed SYNCOOKIE authentication, >> segment rejected (probably spoofed) kernel: TCP: [web.server.host.IP]:60382 >> to >> [web.server.host.IP]:443 tcpflags >> 0x18; tcp_do_segment: FIN_WAIT_2: Received 37 bytes of data after >> socket was closed, sending RST and removing tcpcb kernel: TCP: >> [web.server.host.IP]:60382 to [web.server.host.IP]:443 tcpflags >> 0x11; syncache_expand: Segment failed SYNCOOKIE authentication, >> segment rejected (probably spoofed) >> >> So, if I understand things correctly. The patch prevents (re)negotiation. >> Making >> the likelihood of a successful "handshake" near null (as the log messages >> above show). I'm sure that some may be quick to point the finger at the >> self-signed cert being more likely the cause, I should add that while in fact >> quite unlikely, I too didn't completely rule that out. So I purchased one >> from >> startssl - money wasted. The results were the same. So it would appear that >> until something else is done to overcome the hole in current openssl, my only >> recourse is to back the patch out, and rebuild openssl && all affected ports >> - >> no? On Fri, December 18, 2009 8:43 pm, Peter C. Lai wrote: > This might have something to do with a libthr discussion I was CCed on. > Someone mentioned something about removing a link to libthr in openssl > but I can't remember if this was in the port or base openssl... > Please pardon the pun; but was that /thread/ on _this_ list? Or, did you mean that you were CC's from a different list? If a different list, which one? Thank you again for taking the time to respond. --Chris H >> >> Thank you for all your time and consideration in this matter. >> >> >> --Chris H >> >> >> >> ___ >> freebsd-stable@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-stable >> To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" >> > > -- > === > Peter C. Lai | Bard College at Simon's Rock > Systems Administrator| 84 Alford Rd. > Information Technology Svcs. | Gt. Barrington, MA 01230 USA > peter AT simons-rock.edu | (413) 528-7428 > === > > > ___ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" > > ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
SSL appears to be broken in 8-STABLE/RELEASE
First my apologies for breaking the thread. We also had this issue and tried to find an acceptable solution. To make a long story short: Please try to compile your application against the version of openssl available in the ports tree. As you already mentioned (SA-09:15) breaks renegotiation with base system's openssl by fixing a security issue ( it actually does). Prerequisite for the following is, of course, to install /usr/ports/security/openssl which will give you openssl 0.9.8l . (You do not necessarily have to remove the base openssl) You may then set 'WITH_OPENSSL_PORT=YES' to /etc/make.conf and rebuild your application(s) with via the ports, they should then be compiled correctly against the ports-version. Or, but this will only work if if your application's configure script has a switch to set the path to ssl or openssl to the ports-openssl's location, something like # setenv LD_LIBRARY_PATH /usr/local/lib ## this actually may be removed after build and configure with the appropriate option maybe alike # ./configure --openssl-path=/usr/local/lib Just make sure it compiled properly. The output of ldd should show (apart from other): # ldd application /app/li/cation .. libssl.so.5 => /usr/local/lib/libssl.so.5 (0x881bc000) libcrypto.so.5 => /usr/local/lib/libcrypto.so.5 (0x8820) . For the applications we use, this works with both versions of openssl on the same box, without any i interference. Considerations about this ? HTH ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: SSL appears to be broken in 8-STABLE/RELEASE
Greetings Clifton, and thank you for your reply. On Sat, December 19, 2009 12:16 am, Clifton Royston wrote: > On Fri, Dec 18, 2009 at 05:32:41PM -0800, Chris H wrote: > >> Greetings, >> A recent (cvs checkout of src/ports on 2009-12-09) install of 8 >> seems to indicate that changes in SSL have made it virtually unusable. I've >> spent the past 3 days attempting to (re)create an SSL enabled virtual host >> that serves web based access to local mail. Since it's local, I'm using >> self-signed certs following a scheme that has always worked flawlessly for >> the >> past 9 yrs. However, now having installed 8, it isn't working. The browser(s) >> throw "ssl_error_handshake_failure_alert" (ff-3.56). Other gecko based, and >> non-gecko based UA's throw similar, as well as openssl's s_client. After >> immense research, the only thing I can find that might best explain it is a >> recent SA patch applied to FreeBSD's src (SA-09:15). After reading what the >> patch provides. I am able to better understand the error messages thrown to >> /var/messages when attempting to negotiate a secure session in a UA: >> > ... > >> So, if I understand things correctly. The patch prevents >> (re)negotiation. Making the likelihood of a successful "handshake" >> near null (as the log messages above show). I'm sure that some may be quick >> to >> point the finger at the self-signed cert being more likely the cause, I >> should >> add that while in fact quite unlikely, I too didn't completely rule that out. >> So I purchased one from startssl - >> money wasted. The results were the same. So it would appear that until >> something else is done to overcome the hole in current openssl, my only >> recourse is to back the patch out, and rebuild openssl && all affected ports >> - >> no? > > You might want to check up on a security list to get a full > understanding of the issue, and indeed depending on your application and > network > you may conclude that the best solution for your environment is to reverse out > the patch. > > However, it's unlikely that the patch will be removed from > circulation - most OSes and applications using TLS/SSL are undergoing a > similar > experience - because the security problem it prevents is both genuine and, as > I > understand it, an inherent design error in the protocol specification. If you > allow renegotiation during the session, you also allow a man-in-the-middle > attack to inject arbitrary data into the session. Depending on your app, the > likelihood of this could be anywhere from small to huge, and the impact could > be > anywhere from negligible to disastrous. Indeed. I /do/ understand that the patch was an effort to thwart a potential "hole" in current openssl's implementation. I also took some time comparing the patch against the code's /former/ state. While the patch /does/ "plug" the hole. It also /nearly/ closes the intended entry point for it's intended target - the client initiating communication. As it is, it /won't/ permit communication as it was intended to. So it can't be used as a reliable protocol for secure communication. I fully realize that the hole needed to be plugged ASAP. But until the source has been "re-worked", it's of nearly no value. I discovered I'm not the only one w/o the ability to use SSL after the "patch". I spent quite some time trying to track down the reason communication shut down immediately after accepting the cert in my UA. Searching the web, and newsgroups indicates that /many/ others are w/o the ability to use SSL for their needs either - unless, reverting to a "pre-patchd" state. Given an extremely reliable DNS, and well secured network, the only immediate solution seems to be to check out the pre-2009-12-03 source, and re-build it, and all affected. Then, of course monitor openssl for a "new improved" version. So as to be able to lift a HOLD on the back-patched version in my current tree. Thank you again Clifton, for taking the time to respond. --Chris H > > -- Clifton > > > -- > Clifton Royston -- clift...@iandicomputing.com / clift...@lava.net > President - I and I Computing * http://www.iandicomputing.com/ > Custom programming, network design, systems and network consulting services > ___ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" > > ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: SSL appears to be broken in 8-STABLE/RELEASE
Greetings Matthew, and thank you very much for your reply. On Sat, December 19, 2009 12:33 am, Matthew Seaman wrote: > Chris H wrote: > >> Greetings, >> A recent (cvs checkout of src/ports on 2009-12-09) install of 8 seems to >> indicate that changes in SSL have made it virtually unusable. I've spent the >> past 3 days attempting to (re)create an SSL enabled virtual host that serves >> web based access to local mail. Since it's local, I'm using self-signed certs >> following a scheme that has always worked flawlessly for the past 9 yrs. >> However, now having installed 8, >> it isn't working. The browser(s) throw "ssl_error_handshake_failure_alert" >> (ff-3.56). >> Other gecko based, and non-gecko based UA's throw similar, as well as >> openssl's s_client. After immense research, the only thing I can find that >> might best explain it is a recent SA patch applied to FreeBSD's src >> (SA-09:15). After reading what the >> patch provides. I am able to better understand the error messages thrown to >> /var/messages when attempting to negotiate a secure session in a UA: >> > > Your analysis is correct. You've hit the exact problem used as the test case > in all the investigations into the SSL injection attach mitigated in SA-09:15. > Essentially what happens is that your clients make an initial anonymous (on > the > client side) connection to the SSL site. Then (as a consequence perhaps of > user actions), the SSL site requires the user side to authenticate itself by > presenting a certificate. This authentication process entails renegotiating > the > whole client -> server SSL connection, and that is precisely what was diked > out > of openssl-0.9.6m as it is the route to exploiting the security flaw. > > There is an update to the SSL protocol in the works that will properly close > the vulnerability and still allow useful things like renegotiation -- see > > https://datatracker.ietf.org/idtracker/draft-ietf-tls-renegotiation/ > > > This has taken what seems like a veritable age for the IETF to process, but in > reality it is moving with all dispatch to get the fix in place. > > So, at the moment, we have a band-aid that fixes the vulnerability, but that > breaks some sites. In the future we will have a correct fix that restores the > desirable functionality. Between now and then, your site is going to have > difficulties. > > Options: > > > * Just wait. Leave the site broken (but invulnerable to the attack) until > the proper fix comes out. I somehow doubt that this will be acceptable. > > * Temporarily (or permanently) switch to some other form of authentication > than using SSL client certificates. Likely to require significant > re-engineering > of your site, and probably quite a lot of user re-education and other chores. > > * Accept the risk of the SSL injection attack, downrev to openssl-0.8.6l > and put in place whatever other mitigation you can think of to protect the > site. > For instance, fire-walling off all access except to known > good IP numbers. > > To find out more about the attack, see Marsh Ray's blog at > http://extendedsubset.com/ > which has links to many useful resources. > > Cheers, > > > Matthew WOW. I am /extremely/ grateful for your thoughtful, and very informative reply. All points well taken. Given an already well secured network. I'll opt for "door number 3" - back-patch openssl, and flag that section of the tree as HOLD. While closely monitoring openssl for the "new and improved" version. :) In all honesty, I'm quite impressed with openssl - that it took /so/ long for this "hole" to be found. Just wish a better "plug" could have been found during the interim. :) Thank you again Matthew, for taking the time to provide such an informative, and thoughtful response. --Chris H > > > -- > Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard > Flat 3 > PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate > Kent, CT11 9PW > > > ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: SSL appears to be broken in 8-STABLE/RELEASE
Greetings, and thank you for taking the time to respond. On Sat, December 19, 2009 12:58 am, H. Ingow wrote: > First my apologies for breaking the thread. > We also had this issue and tried to find an acceptable solution. > To make a long story short: > > > Please try to compile your application against the version of openssl > available in the ports tree. > > As you already mentioned (SA-09:15) breaks renegotiation with base system's > openssl by fixing a security issue ( it actually does). > > Prerequisite for the following is, of course, to install > /usr/ports/security/openssl which will give you > openssl 0.9.8l . (You do not necessarily have to remove the base openssl) > > You may then set 'WITH_OPENSSL_PORT=YES' to /etc/make.conf > and rebuild your application(s) with via the ports, they should then be > compiled > correctly against the ports-version. > > Or, but this will only work if if your application's configure script has a > switch to set the path to ssl or openssl to the ports-openssl's location, > something like > > # setenv LD_LIBRARY_PATH /usr/local/lib ## this actually may be > removed after build > > and configure with the appropriate option maybe alike > > # ./configure --openssl-path=/usr/local/lib > > > Just make sure it compiled properly. > The output of ldd should show (apart from other): > # ldd application > /app/li/cation > .. > libssl.so.5 => /usr/local/lib/libssl.so.5 (0x881bc000) libcrypto.so.5 => > /usr/local/lib/libcrypto.so.5 (0x8820) > . > > > For the applications we use, this works with both versions of openssl on the > same box, without any i interference. Excellent suggestion! I hadn't /yet/ compared the ports version against base. Your suggestion has a great deal less overhead than my initial thoughts to "back-patch" to pre-2009-12-03-openssl, and flagging that portion of the tree as HOLD. I like your suggestion /much/ better. Thank you very much for taking the time to share it. :) Best wishes. --Chris H > > Considerations about this ? > > > HTH > ___ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" > > ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: SSL appears to be broken in 8-STABLE/RELEASE
Hello Maxim, and thank you for taking the time to reply. On Sat, December 19, 2009 2:14 am, Maxim Dounin wrote: > Hello! > > > On Fri, Dec 18, 2009 at 05:32:41PM -0800, Chris H wrote: > > >> Greetings, >> A recent (cvs checkout of src/ports on 2009-12-09) install of 8 seems to >> indicate that changes in SSL have made it virtually unusable. I've spent the >> past 3 days attempting to (re)create an SSL enabled virtual host that serves >> web based access to local mail. Since it's local, I'm using self-signed certs >> following a scheme that has always worked flawlessly for the past 9 yrs. >> However, now having installed 8, >> it isn't working. The browser(s) throw "ssl_error_handshake_failure_alert" >> (ff-3.56). >> Other gecko based, and non-gecko based UA's throw similar, as well as >> openssl's s_client. After immense research, the only thing I can find that >> might best explain it is a recent SA patch applied to FreeBSD's src >> (SA-09:15). After reading what the >> patch provides. I am able to better understand the error messages thrown to >> /var/messages when attempting to negotiate a secure session in a UA: >> > > [...] > > >> So, if I understand things correctly. The patch prevents (re)negotiation. >> Making >> the likelihood of a successful "handshake" near null (as the log messages >> above show). I'm sure that some may be quick to point the finger at the >> self-signed cert being more likely the cause, I should add that while in fact >> quite unlikely, I too didn't completely rule that out. So I purchased one >> from >> startssl - money wasted. The results were the same. So it would appear that >> until something else is done to overcome the hole in current openssl, my only >> recourse is to back the patch out, and rebuild openssl && all affected ports >> - >> no? > > If you are using Apache as server, you may consider using > server-wide SSLVerifyClient (instead of per-location ones which require > renegotiation). Indeed. I tried that on an Apache server, but "no joy". :( SSLVerifyClient provides the following options: 0 - Verify the client:no 1 - Verify the client:optional 2 - Verify the client:required 3 - Verify the client:required - but CA is optional However, none of the options worked - even with the purchased cert. The problem appears (after examining the patch), is that it is not possible to be presented with the option to accept the cert, and /then/ continue with the session. As it is, you are permitted to initiate communication, but /any/ "decision making" may /only/ be made to determine a mutually acceptable crypt - eg; AES;DES;ETC... So Apache (or any other cryptographically aware server) using /current/ openssl, has no say in the matter - period. Thanks again Maxim, for your thoughtful reply. --Chris H > > Maxim Dounin > ___ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" > > ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: SSL appears to be broken in 8-STABLE/RELEASE
On Sat, December 19, 2009 3:13 am, Maxim Dounin wrote: > Hello! > > > On Sat, Dec 19, 2009 at 09:58:49AM +0100, H. Ingow wrote: > > > [...] > > >> Please try to compile your application against the version of openssl >> available in the ports tree. >> >> As you already mentioned (SA-09:15) breaks renegotiation with base system's >> openssl by fixing a security issue ( it actually does). >> >> Prerequisite for the following is, of course, to install >> /usr/ports/security/openssl which will give you >> openssl 0.9.8l . (You do not necessarily have to remove the base openssl) > > OpenSSL 0.9.8l has renegotiation disabled too, this won't help. > > > The only difference is that 0.9.8l has some means to re-enable > legacy renegotiation which may be utilized by applications which are aware of > the > problem. Which is exactly what's required to implement your previous suggestion. :) --Chris H > > Maxim Dounin > ___ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" > > ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: SSL appears to be broken in 8-STABLE/RELEASE
Sorry if my proposal won't fit in this case and thanks, Maxim for clearing out what exactly to be aware of to have applications run with openssl .0.9.8l But for the sake of completeness /usr/ports/security/tor-devel is very well capable of handling re-negotiation. see src/common/tortls.c and grep for ALLOW_UNSAFE_LEGACY_RENEGOTIATION you'll get [..] #ifdef SSL3_FLAGS_ALLOW_UNSAFE_LEGACY_RENEGOTIATION /* Yes, we know what we are doing here. No, we do not treat a renegotiation * as authenticating any earlier-received data. */ tls->ssl->s3->flags |= SSL3_FLAGS_ALLOW_UNSAFE_LEGACY_RENEGOTIATION; #else (void)tls; #endif [.] and#ifdef SSL3_FLAGS_ALLOW_UNSAFE_LEGACY_RENEGOTIATION tls->ssl->s3->flags&=~SSL3_FLAGS_ALLOW_UNSAFE_LEGACY_RENEGOTIATION; #else (void)tls; #endif [.] So that' the second one . Hopefully more to come . Sorry for the confusion I may have caused, but it was tempting to believe it was easy dealing with hat matter. On 12/19/09, Maxim Dounin wrote: > Hello! > > On Sat, Dec 19, 2009 at 03:23:57AM -0800, Chris H wrote: > >> On Sat, December 19, 2009 3:13 am, Maxim Dounin wrote: >> > Hello! >> > >> > >> > On Sat, Dec 19, 2009 at 09:58:49AM +0100, H. Ingow wrote: >> > >> > >> > [...] >> > >> > >> >> Please try to compile your application against the version of openssl >> >> available in the ports tree. >> >> >> >> As you already mentioned (SA-09:15) breaks renegotiation with base >> >> system's >> >> openssl by fixing a security issue ( it actually does). >> >> >> >> Prerequisite for the following is, of course, to install >> >> /usr/ports/security/openssl which will give you >> >> openssl 0.9.8l . (You do not necessarily have to remove the base >> >> openssl) >> > >> > OpenSSL 0.9.8l has renegotiation disabled too, this won't help. >> > >> > >> > The only difference is that 0.9.8l has some means to re-enable >> > legacy renegotiation which may be utilized by applications which are >> > aware of the >> > problem. >> Which is exactly what's required to implement your previous suggestion. :) > > No, my previous suggestion is unrelated. > > Additionally, to re-enable renegotiation in openssl 0.9.8l you > need an application which is able to set > SSL3_FLAGS_ALLOW_UNSAFE_LEGACY_RENEGOTIATION in s->s3->flags. I > haven't seen any yet, and google codesearch is able > to find only one such app (proftpd). > > Maxim Dounin > ___ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" > ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: SSL appears to be broken in 8-STABLE/RELEASE
Hello Maxim, and thank you again for your reply. On Sat, December 19, 2009 3:54 am, Maxim Dounin wrote: > Hello! > > > On Sat, Dec 19, 2009 at 03:18:21AM -0800, Chris H wrote: > > >> Hello Maxim, and thank you for taking the time to reply. >> On Sat, December 19, 2009 2:14 am, Maxim Dounin wrote: >> >>> Hello! >>> >>> >>> >>> On Fri, Dec 18, 2009 at 05:32:41PM -0800, Chris H wrote: >>> >>> >>> >>>> Greetings, >>>> A recent (cvs checkout of src/ports on 2009-12-09) install of 8 seems to >>>> indicate that changes in SSL have made it virtually unusable. I've spent >>>> the past 3 days attempting to (re)create an SSL enabled virtual host that >>>> serves web based access to local mail. Since it's local, I'm using >>>> self-signed certs following a scheme that has always worked flawlessly for >>>> the past 9 yrs. However, now having installed 8, >>>> it isn't working. The browser(s) throw "ssl_error_handshake_failure_alert" >>>> (ff-3.56). >>>> Other gecko based, and non-gecko based UA's throw similar, as well as >>>> openssl's s_client. After immense research, the only thing I can find that >>>> might best explain it is a recent SA patch applied to FreeBSD's src >>>> (SA-09:15). After reading what the >>>> patch provides. I am able to better understand the error messages thrown >>>> to /var/messages when attempting to negotiate a secure session in a UA: >>>> >>>> >>> >>> [...] >>> >>> >>> >>>> So, if I understand things correctly. The patch prevents (re)negotiation. >>>> Making >>>> the likelihood of a successful "handshake" near null (as the log messages >>>> above show). I'm sure that some may be quick to point the finger at the >>>> self-signed cert being more likely the cause, I should add that while in >>>> fact quite unlikely, I too didn't completely rule that out. So I purchased >>>> one from startssl - money wasted. The results were the same. So it would >>>> appear that until something else is done to overcome the hole in current >>>> openssl, my only recourse is to back the patch out, and rebuild openssl && >>>> all affected ports - no? >>> >>> If you are using Apache as server, you may consider using >>> server-wide SSLVerifyClient (instead of per-location ones which require >>> renegotiation). >> Indeed. I tried that on an Apache server, but "no joy". :( >> >> >> SSLVerifyClient provides the following options: >> 0 - Verify the client:no 1 - Verify the client:optional >> 2 - Verify the client:required >> 3 - Verify the client:required - but CA is optional >> >> >> However, none of the options worked - even with the purchased cert. >> > > It doesn't matter what you specify in option. The thing that > matters is where you specify option itself. > > The following won't work: > > > > ... > > SSLVerifyClient required > > > > > as SSLVerifyClient in Location context requires renegotiation. But moving it > to > VirtualHost level should resolve the issue, as > certificate exchange will happen in initial handshake. The following should > work: > > > > ... > SSLVerifyClient required > > > > [...] Indeed. I understand that. In fact my OP (original post) indicated my use was in a "vhost" - eg; NameVirtualHost host.ip.add.ress:443 SSLEnable SSLVerifyClient (options 0-3;none work) SSLRequireSSL SSLNoV2 SSLCACertificatePath /path/to/ca-file SSLCertificateFile /path/to/cert-file SSLCertificateKeyFile /path/to/key-file [...] Thank you again Maxim, for taking the time to respond. --Chris H > > > Maxim Dounin > ___ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" > > ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Failure during GENERIC (i386) kernel build at r200721
On Sat, December 19, 2009 5:35 am, David Wolfskill wrote: > Attempted clean kernel build, running > > > FreeBSD freebeast.catwhisker.org 7.2-STABLE FreeBSD 7.2-STABLE #11 r200664: > Fri > Dec 18 05:18:46 PST 2009 > r...@freebeast.catwhisker.org:/common/S2/obj/usr/src/sys/GENERIC i386 > > > [Immediately following a "make buldworld"...] > >>>> Kernel build for GENERIC started on Sat Dec 19 05:05:56 PST 2009 >>>> > ... > >>>> stage 3.2: building everything > ... > cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs > -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual ---8<---8<---[big snip]---8<---8<--- Greetings, What are the chances you made no declaration as to your CPU type in your KERNCONF? eg; 1386 HTH --Chris H > > > Was a definition or two overlooked? > > > Peace, > david -- > David H. Wolfskillda...@catwhisker.org > Depriving a girl or boy of an opportunity for education is evil. > > > See http://www.catwhisker.org/~david/publickey.gpg for my public key. > > ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Failure during GENERIC (i386) kernel build at r200721
On Sat, December 19, 2009 5:54 am, Chris H wrote: > On Sat, December 19, 2009 5:35 am, David Wolfskill wrote: > >> Attempted clean kernel build, running >> >> >> >> FreeBSD freebeast.catwhisker.org 7.2-STABLE FreeBSD 7.2-STABLE #11 r200664: >> Fri >> Dec 18 05:18:46 PST 2009 >> r...@freebeast.catwhisker.org:/common/S2/obj/usr/src/sys/GENERIC i386 >> >> >> >> [Immediately following a "make buldworld"...] >> >> >>>>> Kernel build for GENERIC started on Sat Dec 19 05:05:56 PST 2009 >>>>> >>>>> >> ... >> >> >>>>> stage 3.2: building everything >> ... >> cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs >> -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline >> -Wcast-qual >> > ---8<---8<---[big snip]---8<---8<--- > > > Greetings, > What are the chances you made no declaration as to your CPU type in your > KERNCONF? > > > eg; 1386 Just for clarity; from /usr/src/sys/i386/conf/GENERIC: machine i386 #cpuI486_CPU #cpuI586_CPU cpu I686_CPU in the example above I've chosen i386 as machine type, and I686_CPU as cpu type. If you did /not/ make similar choices in /your/ KERNCONF, the error you reported will insue. HTH --Chris H > > > HTH > > > --Chris H > >> >> >> Was a definition or two overlooked? >> >> >> >> Peace, >> david -- David H. Wolfskill da...@catwhisker.org >> Depriving a girl or boy of an opportunity for education is evil. >> >> >> >> See http://www.catwhisker.org/~david/publickey.gpg for my public key. >> >> >> > > > ___ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" > > ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Failure during GENERIC (i386) kernel build at r200721
On Sat, December 19, 2009 9:31 am, David Wolfskill wrote: > On Sat, Dec 19, 2009 at 06:05:33AM -0800, Chris H wrote: > >> ... >> >>> Greetings, >>> What are the chances you made no declaration as to your CPU type in your >>> KERNCONF? >>> >>> >>> >>> eg; 1386 >> >> Just for clarity; from /usr/src/sys/i386/conf/GENERIC: >> >> >> machine i386 > > With respect, that is not correct, at least for stable/7 as of r200721. Indeed. My mistake. I only suspected that to be your issue, as the output of uname -a at the top of your OP didn't contain the machine type at the end. For example the one I am writing this reply from outputs: udns 8.0-STABLE FreeBSD 8.0-STABLE #0: Thu Dec 10 01:10:25 PST 2009 r...@udns:/usr/obj/usr/src/sys/UDNS01 i386 Please note the i386 at the end. :) I'm afraid I'm at a bit of a loss then. Except to note that freebsd build machines all reported failure to build for all arc types. So if yous is from a recent copy of cvs. That may explain it. You may want to wait a week, and checkout a new copy of src && ports then. Best wishes. --Chris H > > > Rather, the line in question is in /sys/i386/conf/DEFAULTS: > > > g1-119(7.2-S)[2] cd /sys/i386/conf/ g1-119(7.2-S)[3] grep '^machine' * > DEFAULTS:machinei386 > g1-119(7.2-S)[4] > > Indeed; that appears to have gone into DEFAULTS as of r152865: > > > > r152865 | ru | 2005-11-27 15:17:00 -0800 (Sun, 27 Nov 2005) | 3 lines > > - Allow duplicate "machine" directives with the same arguments. > - Move existing "machine" directives to DEFAULTS. > > > > > > I note, too, that stable/6, stable/8 and head each built and ran > successfully on this machine this morning -- each using an unmodified GENERIC > kernel, as is the kernel I was unable to build for stable/7. > > And I had another occurrence of the "make buildkernel" failure on my > laptop (as a reality check) -- though that was not a GENERIC kerenl. > >> ... >> > > Peace, > david -- > David H. Wolfskillda...@catwhisker.org > Depriving a girl or boy of an opportunity for education is evil. > > > See http://www.catwhisker.org/~david/publickey.gpg for my public key. > > ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
RE: Hacked - FreeBSD 7.1-Release
On Tue, December 22, 2009 8:35 am, Andresen, Jason R. wrote: > Squirrel wrote: > >> most likely could be some kind of remote code execution or SQLi executed in >> the context of some php scripts, you should audit php code of your web >> interface and of the websites you host. also consider the strenght of your >> passwords, lots of login attempts to ssh/ftp may mean a he has tried a >> bruteforce (or a dictionary attack maybe). you should also check webmin logs, >> there are a few bruteforcer for webmin out there, (*hint*) consider the >> lenght >> of your average password if it's more than 7-8 characters aplhanumeric with >> simbols most likely this isn't the case. > > While it's true that it's a good idea to check your password strength, pretty > much any host connected to the internet is going to be hit daily by bots > looking for weak passwords. It's one area where you logs don't help much > because there is too much noise. That's why there's GREP(1), AWK(1), FIND(1), TAIL(1), and CAT(1) Consider the following... adding the following to your /etc/rc.conf: # SECURITY RELATED syslogd_flags="-ss" log_in_vain="YES" tcp_keepalive="YES" now your log file will /really/ sing (log_in_vain="YES"). Of course, unless you have a great deal of time on your hands, visually parsing that "noisy" log will be quite tedious, and time consuming. So you have a few options... If your running X11, simply run tail in a root window - there are quite a few utilities in ports for doing just this - some that'll only write messages you want to see. You could also create a script out of cron that will only produce messages you are interested in, for example: ~# cat /var/log/messages | ssh will emit any attempt to ssh into your box you can also redirect the messages to a file: ~# cat /var/log/messages | ssh >>~/EVIL_DOERS You could also add en entry to PERIODIC(8) that will provide a daily report on any attempts you are interested in. HTH --Chris H > ___ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
RE: Hacked - FreeBSD 7.1-Release
On Mon, December 28, 2009 7:44 am, Andresen, Jason R. wrote: >> From: Chris H >> >> >> On Tue, December 22, 2009 8:35 am, Andresen, Jason R. wrote: >> >>> Squirrel wrote: >>> >>> >>>> most likely could be some kind of remote code execution or SQLi >> executed in >>>> the context of some php scripts, you should audit php code of your >> web >>>> interface and of the websites you host. also consider the strenght of >> your >>>> passwords, lots of login attempts to ssh/ftp may mean a he has tried >> a >>>> bruteforce (or a dictionary attack maybe). you should also check >> webmin logs, >>>> there are a few bruteforcer for webmin out there, (*hint*) consider >> the lenght >>>> of your average password if it's more than 7-8 characters >> aplhanumeric with >>>> simbols most likely this isn't the case. >>> >>> While it's true that it's a good idea to check your password strength, >>> >> pretty >>> much any host connected to the internet is going to be hit daily by >> bots >>> looking for weak passwords. It's one area where you logs don't help >> much >>> because there is too much noise. >> That's why there's GREP(1), AWK(1), FIND(1), TAIL(1), and CAT(1) >> Consider the following... >> adding the following to your /etc/rc.conf: >> >> # SECURITY RELATED >> >> syslogd_flags="-ss" log_in_vain="YES" tcp_keepalive="YES" >> >> >> now your log file will /really/ sing (log_in_vain="YES"). Of course, unless >> you have a great deal of time on your hands, visually parsing that "noisy" >> log >> will be quite tedious, and time consuming. So you have a few options... If >> your >> running X11, simply run tail in a root window - there are quite a few >> utilities >> in ports for doing just this - some that'll only write messages you want to >> see. You could also create a script out of cron that will only produce >> messages you are interested in, for example: >> >> ~# cat /var/log/messages | ssh >> >> >> will emit any attempt to ssh into your box you can also redirect the messages >> to a file: >> >> ~# cat /var/log/messages | ssh >>~/EVIL_DOERS >> >> >> You could also add en entry to PERIODIC(8) that will >> provide a daily report on any attempts you are interested in. >> >> HTH >> >> > > Your solution to excessive noise in the security log is to greatly increase > the > noise level?!? > > The point is, if your machine is on the internet, then bots are going to try > password attacks on any open port they can find. It's just the sad fact of > life on the current internet. Unfortunately, this activity will also make it > much more difficult to determine when you are under attack from an actual > person, which was my point earlier. It's one that is not going to be easy to > solve either, unless you're willing to rewrite SSH to require every connection > attempt to pass a Turing test or something. My point here was that by increasing the verbosity, you will more easily be able to grep against login /failures/, and more easily discover dictionary/ brute-force attacks. It's certainly made my job easier, and hasn't required any modifications to our current policies. You /have/ considered PF(4), haven't you? It's /really/ an excellent strategy for securing your network. --Chris H > ___ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: 7-PRERELEASE Xorg - Fatal server error:could not open default font 'fixed'[SOLVED]
Quoting Kimi <[EMAIL PROTECTED]>: On 20/01/2008, Chris H. <[EMAIL PROTECTED]> wrote: Quoting Kimi <[EMAIL PROTECTED]>: > On 20/01/2008, Chris H. <[EMAIL PROTECTED]> wrote: >> Greetings, >> Well, after not having any luck with Xorg after a fresh install >> of 7. I decided to try a more recent cvsup of the ports tree and > [...] > > you need ports/x11-fonts/font-alias Thank you! You rock! That did it. You're the best. :) I can't believe I overlooked that. it bugged me like crazy when I could not find what it was causing the problem, even after installing all the misc fonts. ports should handle this dependency better, which means I should open a PR but never got around to it. You know, I'm /quite/ embarrassed about this one. Last year I wrote a /very/ long, and informative "how-to" for adding fonts to X. I gave a fair amount of background on the whole process too - including "debugging" the results of each step. You'd think I'd have figured this out on my own. :P Problem was - I /assumed/ that installing xorg-server, xorg-apps, and xorg-libraries would have /included/ all the prerequisites - D'oh! Anyway, looks like I have something else to add to that "how-to". :) Thanks again for taking the time to help me out on this one. --Chris --Chris -- panic: kernel trap (ignored) -- Regards, Kimi ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]" -- panic: kernel trap (ignored) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Apache13-ssl fails on 7-PRERELEASE
Greetings, On an SMP system (2 CPU) running 7 cvsupped on 2008-01-15 with a build/install world/kernel on the same. I built/installed www/apache13-ssl. It built/installed expected. However, after testing with an httpsdctl configtest, apache emitted the following: Syntax error on line 208 of /usr/local/etc/apache/httpsd.conf: Cannot load /usr/local/libexec/apache/mod_mmap_static.so into server: /usr/local /libexec/apache/mod_mmap_static.so: Undefined symbol "ap_null_cleanup" Commenting the offending module only caused apache to complain about the next one in the list. This is a terrible loss to the FreeBSD ports. Has anyone a suggestion/patch for this? Has anyone else experienced this problem? All of our other servers have built/ ran this version without complaint/trouble. All the conf files have been carefully crafted over many yrs. and I have no interest in using a newer version of Apache, so as to have to re-craft the configs. Thank you for all your time and consideration in this matter. P.S. I realize that this should normally be directed to apache-freebsd@ and I /did/ do so. However, after having been on the list for quite some time. It appears that I am the only one subscribed to it. Further, as this is on CURRENT, I felt that there must be some difference. As I had no trouble with this on a 6-CURRENT box/install. Thanks again. --Chris H -- panic: kernel trap (ignored) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Apache13-ssl fails on 7-PRERELEASE
Quoting "Chris H." <[EMAIL PROTECTED]>: Greetings, On an SMP system (2 CPU) running 7 cvsupped on 2008-01-15 with a build/install world/kernel on the same. D'ho! Forgot to mention this is on an i386. I built/installed www/apache13-ssl. It built/installed expected. However, after testing with an httpsdctl configtest, apache emitted the following: Syntax error on line 208 of /usr/local/etc/apache/httpsd.conf: Cannot load /usr/local/libexec/apache/mod_mmap_static.so into server: /usr/local /libexec/apache/mod_mmap_static.so: Undefined symbol "ap_null_cleanup" Commenting the offending module only caused apache to complain about the next one in the list. This is a terrible loss to the FreeBSD ports. Has anyone a suggestion/patch for this? Has anyone else experienced this problem? All of our other servers have built/ ran this version without complaint/trouble. All the conf files have been carefully crafted over many yrs. and I have no interest in using a newer version of Apache, so as to have to re-craft the configs. Thank you for all your time and consideration in this matter. P.S. I realize that this should normally be directed to apache-freebsd@ and I /did/ do so. However, after having been on the list for quite some time. It appears that I am the only one subscribed to it. Further, as this is on CURRENT, I felt that there must be some difference. As I had no trouble with this on a 6-CURRENT box/install. Thanks again. --Chris H -- panic: kernel trap (ignored) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]" -- panic: kernel trap (ignored) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: "ad0: TIMEOUT - WRITE_DMA" type errors with 7.0-RC1
it should /definitely/ display a diagnostic which encourages the admin to use /etc/rc.d/hostid Ahhh, rather, display a diagnostic which encourages the use of "zpool import -a". --JH ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: "ad0: TIMEOUT - WRITE_DMA" type errors with 7.0-RC1
Richard Todd wrote: Workaround: always make sure you run /etc/rc.d/hostid start in single-user before doing any ZFS tinkering. Good advice -- thank you. But it still sounds like Jeremy's assessment, "it's a bug", is accurate. ZFS could certainly check for zero hostid. If zero, it should /definitely/ display a diagnostic which encourages the admin to use /etc/rc.d/hostid (or a printout of it). If zero, it /might/ additionally do some reads in case a likely-looking /etc/rc.d/hostid is available, and display the hostid, perhaps even speculatively start using it. It would save some needless "no datasets available" hair pulling. Cheers, JH ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
/usr/bin/objformat is missing
Hello, After a failed install of www/apache-ssl - dies with the following error: Syntax error on line 208 of /usr/local/etc/apache/httpsd.conf: Cannot load /usr/local/libexec/apache/mod_mmap_static.so into server: /usr/local /libexec/apache/mod_mmap_static.so: Undefined symbol "ap_null_cleanup" I did a little research, and wondered if the fact that I am missing: /usr/bin/objformat has anything to do with it. Doesn't this add an elf format to libraries? Do I need it? All of my 6-CURRENT boxes have this. But this is a 7-PRERELEASE ( FreeBSD 7.0-PRERELEASE i386 ) using 2 CPU's. If I /do/ need it, how do I create it? Thank you for all your time and consideration in this matter. --Chris H -- panic: kernel trap (ignored) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: /usr/bin/objformat is missing
Quoting Daniel Eischen <[EMAIL PROTECTED]>: On Mon, 28 Jan 2008, Chris H. wrote: Quoting Jeremy Chadwick <[EMAIL PROTECTED]>: On Mon, Jan 28, 2008 at 09:33:49AM -0800, Chris H. wrote: Hello, After a failed install of www/apache-ssl - dies with the following error: Syntax error on line 208 of /usr/local/etc/apache/httpsd.conf: Cannot load /usr/local/libexec/apache/mod_mmap_static.so into server: /usr/local /libexec/apache/mod_mmap_static.so: Undefined symbol "ap_null_cleanup" I did a little research, and wondered if the fact that I am missing: /usr/bin/objformat has anything to do with it. Very unlikely. Are you using the binary package of www/apache-ssl, rather than building the port from source? Building from source that was cvsupped 2008-01-18 Have you at any time migrated from Apache 1.3.x Nope. It's a brand new install. Why don't you use a newer version of Apache, as opposed to 1.3.x? Because I have over 50 conf files carefully crafted from years of refining. So I have no interest in starting over. From your error messages, it seems obvious, though you never state it, that you are using apache13. Sorry, my bad. It's easy to overlook a detail sometimes, and given that this thread was primarily a question of /usr/bin/objformat didn't help me to think of asserting the apache version either. :) So, for the record; it's a build from the source in www/apache13-ssl Continued make deinstalls and tweaking and make && make installs all still fail with the same errors. I have noticed a couple of threads that relate to this. One indicates that copying www/apache13/files/patch-ae to www/apache-ssl/files/patch-az worked. Didn't work for me. Second one indicated that creating /usr/bin/objformat with the contents of objformat being #!/bin/sh echo elf worked for them. I'm about to try that, since it isn't possible to build from source a working version. I'll report back if it does. --Chris H -- DE ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]" -- panic: kernel trap (ignored) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: /usr/bin/objformat is missing
Quoting Jeremy Chadwick <[EMAIL PROTECTED]>: On Mon, Jan 28, 2008 at 09:33:49AM -0800, Chris H. wrote: Hello, After a failed install of www/apache-ssl - dies with the following error: Syntax error on line 208 of /usr/local/etc/apache/httpsd.conf: Cannot load /usr/local/libexec/apache/mod_mmap_static.so into server: /usr/local /libexec/apache/mod_mmap_static.so: Undefined symbol "ap_null_cleanup" I did a little research, and wondered if the fact that I am missing: /usr/bin/objformat has anything to do with it. Very unlikely. Are you using the binary package of www/apache-ssl, rather than building the port from source? Building from source that was cvsupped 2008-01-18 Have you at any time migrated from Apache 1.3.x Nope. It's a brand new install. to Apache 2.x or vice-versa without cleaning out old ports or rebuilding other ports? The problem seems to stem from the fact that the Apache 1.3.x module format is completely different than 2.x. Thanks, I also read that. :) The advice seen posted previously is to rebuild all related Apache modules from source. The last time I saw this reported was in late 2007... http://lists.freebsd.org/pipermail/freebsd-ports/2007-August/043136.html Yep. I read that too. But as mentioned above, this is a fresh install from ports. :) Doesn't this add an elf format to libraries? Do I need it? All of my 6-CURRENT boxes have this. But this is a 7-PRERELEASE ( FreeBSD 7.0-PRERELEASE i386 ) using 2 CPU's. If I /do/ need it, how do I create it? You don't. :-) Look at /usr/src/usr.bin/objformat/objformat.sh for some details (see comments at top of file). objformat allowed a script or surrounding program to determine whether or not the executable format was ELF or (ancient) a.out. Kewl. I /did/ take the time to do a man objformat, && man brandelf. Where I see all of this is to become/has already obsolete. But given that all of my /working/ web servers have /usr/bin/objformat and this /non/ working box doesn't, I had to ask. :) But I'd /really/ like to get the web server working. So I'm looking under everything in hopes of finding the "golden egg". :) Thank you very much for taking the time to respond. --Chris H -- | 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]" -- panic: kernel trap (ignored) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Apache13-ssl fails on 7-PRERELEASE [SOLVED]
Quoting "Chris H." <[EMAIL PROTECTED]>: Quoting "Chris H." <[EMAIL PROTECTED]>: Quoting "Chris H." <[EMAIL PROTECTED]>: Greetings, On an SMP system (2 CPU) running 7 cvsupped on 2008-01-15 with a build/install world/kernel on the same. D'ho! Forgot to mention this is on an i386. I built/installed www/apache13-ssl. It built/installed expected. However, after testing with an httpsdctl configtest, apache emitted the following: Syntax error on line 208 of /usr/local/etc/apache/httpsd.conf: Cannot load /usr/local/libexec/apache/mod_mmap_static.so into server: /usr/local /libexec/apache/mod_mmap_static.so: Undefined symbol "ap_null_cleanup" Commenting the offending module only caused apache to complain about the next one in the list. This is a terrible loss to the FreeBSD ports. Has anyone a suggestion/patch for this? Has anyone else experienced this problem? All of our other servers have built/ ran this version without complaint/trouble. All the conf files have been carefully crafted over many yrs. and I have no interest in using a newer version of Apache, so as to have to re-craft the configs. Thank you for all your time and consideration in this matter. P.S. I realize that this should normally be directed to apache-freebsd@ and I /did/ do so. However, after having been on the list for quite some time. It appears that I am the only one subscribed to it. Further, as this is on CURRENT, I felt that there must be some difference. As I had no trouble with this on a 6-CURRENT box/install. Thanks again. OK. After much research and trials and errors. I was able to find a solution. In spite of the man page information regarding objformat being obsolete and discontinued. It is still required (at least for a few things). As it happens, it is quite easy to overcome the problem building a /working/ www/apache13-ssl from recent src on a FreeBSD 7.0-PRERELEASE i386 box. It is a matter of creating: /usr/bin/objformat eg; # touch /usr/bin/objformat Edit /usr/bin/objformat and add the following: #!/bin/sh echo elf Now perform the following: # chmod +r +x -w /usr/bin/objformat You're done. :) Happy building! --Chris H D'OH! Forgot to add [SOLVED] to the Subject. :) --Chris H -- panic: kernel trap (ignored) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]" -- panic: kernel trap (ignored) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]" -- panic: kernel trap (ignored) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]" -- panic: kernel trap (ignored) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: /usr/bin/objformat is missing
Quoting "Chris H." <[EMAIL PROTECTED]>: Quoting Daniel Eischen <[EMAIL PROTECTED]>: On Mon, 28 Jan 2008, Chris H. wrote: Quoting Jeremy Chadwick <[EMAIL PROTECTED]>: On Mon, Jan 28, 2008 at 09:33:49AM -0800, Chris H. wrote: Hello, After a failed install of www/apache-ssl - dies with the following error: Syntax error on line 208 of /usr/local/etc/apache/httpsd.conf: Cannot load /usr/local/libexec/apache/mod_mmap_static.so into server: /usr/local /libexec/apache/mod_mmap_static.so: Undefined symbol "ap_null_cleanup" I did a little research, and wondered if the fact that I am missing: /usr/bin/objformat has anything to do with it. Very unlikely. Are you using the binary package of www/apache-ssl, rather than building the port from source? Building from source that was cvsupped 2008-01-18 Have you at any time migrated from Apache 1.3.x Nope. It's a brand new install. Why don't you use a newer version of Apache, as opposed to 1.3.x? Because I have over 50 conf files carefully crafted from years of refining. So I have no interest in starting over. From your error messages, it seems obvious, though you never state it, that you are using apache13. Sorry, my bad. It's easy to overlook a detail sometimes, and given that this thread was primarily a question of /usr/bin/objformat didn't help me to think of asserting the apache version either. :) So, for the record; it's a build from the source in www/apache13-ssl Continued make deinstalls and tweaking and make && make installs all still fail with the same errors. I have noticed a couple of threads that relate to this. One indicates that copying www/apache13/files/patch-ae to www/apache-ssl/files/patch-az worked. Didn't work for me. Second one indicated that creating /usr/bin/objformat with the contents of objformat being #!/bin/sh echo elf worked for them. I'm about to try that, since it isn't possible to build from source a working version. I'll report back if it does. Whoo Hoo! Yep! That did it. In case you're wondering, objformat /is/ required - at leas for www/apache13-ssl. So the trick is to create the following /usr/bin/objformat: #!/bin/sh echo elf Make sure to set perms to +r +x -w Should I initiate a sendpr? Thanks to all for your comments/suggestions/advice. --Chris H --Chris H -- DE ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]" -- panic: kernel trap (ignored) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]" -- panic: kernel trap (ignored) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: /usr/bin/objformat is missing
Quoting "Chris H." <[EMAIL PROTECTED]>: Quoting Daniel Eischen <[EMAIL PROTECTED]>: On Mon, 28 Jan 2008, Chris H. wrote: Quoting Jeremy Chadwick <[EMAIL PROTECTED]>: On Mon, Jan 28, 2008 at 09:33:49AM -0800, Chris H. wrote: Hello, After a failed install of www/apache-ssl - dies with the following error: Syntax error on line 208 of /usr/local/etc/apache/httpsd.conf: Cannot load /usr/local/libexec/apache/mod_mmap_static.so into server: /usr/local /libexec/apache/mod_mmap_static.so: Undefined symbol "ap_null_cleanup" I did a little research, and wondered if the fact that I am missing: /usr/bin/objformat has anything to do with it. Very unlikely. Are you using the binary package of www/apache-ssl, rather than building the port from source? Building from source that was cvsupped 2008-01-18 Have you at any time migrated from Apache 1.3.x Nope. It's a brand new install. Why don't you use a newer version of Apache, as opposed to 1.3.x? Because I have over 50 conf files carefully crafted from years of refining. So I have no interest in starting over. From your error messages, it seems obvious, though you never state it, that you are using apache13. Sorry, my bad. It's easy to overlook a detail sometimes, and given that this thread was primarily a question of /usr/bin/objformat didn't help me to think of asserting the apache version either. :) So, for the record; it's a build from the source in www/apache13-ssl Continued make deinstalls and tweaking and make && make installs all still fail with the same errors. I have noticed a couple of threads that relate to this. One indicates that copying www/apache13/files/patch-ae to www/apache-ssl/files/patch-az worked. Didn't work for me. Second one indicated that creating /usr/bin/objformat with the contents of objformat being #!/bin/sh echo elf worked for them. I'm about to try that, since it isn't possible to build from source a working version. I'll report back if it does. --Chris H -- DE ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]" -- panic: kernel trap (ignored) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]" -- panic: kernel trap (ignored) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Apache13-ssl fails on 7-PRERELEASE
Quoting "Chris H." <[EMAIL PROTECTED]>: Quoting "Chris H." <[EMAIL PROTECTED]>: Greetings, On an SMP system (2 CPU) running 7 cvsupped on 2008-01-15 with a build/install world/kernel on the same. D'ho! Forgot to mention this is on an i386. I built/installed www/apache13-ssl. It built/installed expected. However, after testing with an httpsdctl configtest, apache emitted the following: Syntax error on line 208 of /usr/local/etc/apache/httpsd.conf: Cannot load /usr/local/libexec/apache/mod_mmap_static.so into server: /usr/local /libexec/apache/mod_mmap_static.so: Undefined symbol "ap_null_cleanup" Commenting the offending module only caused apache to complain about the next one in the list. This is a terrible loss to the FreeBSD ports. Has anyone a suggestion/patch for this? Has anyone else experienced this problem? All of our other servers have built/ ran this version without complaint/trouble. All the conf files have been carefully crafted over many yrs. and I have no interest in using a newer version of Apache, so as to have to re-craft the configs. Thank you for all your time and consideration in this matter. P.S. I realize that this should normally be directed to apache-freebsd@ and I /did/ do so. However, after having been on the list for quite some time. It appears that I am the only one subscribed to it. Further, as this is on CURRENT, I felt that there must be some difference. As I had no trouble with this on a 6-CURRENT box/install. Thanks again. OK. After much research and trials and errors. I was able to find a solution. In spite of the man page information regarding objformat being obsolete and discontinued. It is still required (at least for a few things). As it happens, it is quite easy to overcome the problem building a /working/ www/apache13-ssl from recent src on a FreeBSD 7.0-PRERELEASE i386 box. It is a matter of creating: /usr/bin/objformat eg; # touch /usr/bin/objformat Edit /usr/bin/objformat and add the following: #!/bin/sh echo elf Now perform the following: # chmod +r +x -w /usr/bin/objformat You're done. :) Happy building! --Chris H --Chris H -- panic: kernel trap (ignored) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]" -- panic: kernel trap (ignored) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]" -- panic: kernel trap (ignored) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: /usr/bin/objformat is missing
Quoting Mark Linimon <[EMAIL PROTECTED]>: On Mon, Jan 28, 2008 at 04:55:01PM -0800, Jeremy Chadwick wrote: I don't agree with any port creating a file in /usr/bin, and it's safe to say others will not agree with it either. In particular, portmgr will mark such a port as BROKEN :-) or perhaps REQUIRES+= compat-6 || compat-5 :) mcl ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]" -- panic: kernel trap (ignored) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: /usr/bin/objformat is missing
Quoting Peter Jeremy <[EMAIL PROTECTED]>: On Mon, Jan 28, 2008 at 02:41:56PM -0800, Chris H. wrote: In case you're wondering, objformat /is/ required - at leas for www/apache13-ssl. objformat was created at around FreeBSD 3.0 as a temporary tool to handle the a.out to ELF transition and has been obsolete for nearly 8 years. Unfortunately, it's continued presence misled third-party developers. Yes, this is what I gathered from the man pages. Too bad the Vendors don't read the man pages. :) So the trick is to create the following /usr/bin/objformat: #!/bin/sh echo elf Make sure to set perms to +r +x -w The correct fix is to patch the configure script to not need objformat. Indeed. Couldn't agree more. It's my understanding that this is a linker issue. Is it possible that it only shows up now because the default gcc is now 4.1? Note that as others have suggested, Apache 1.3 is now a legacy version. Even if you don't move to Apache 2.2 now, I suggest your future plans include provision for migration off Apache 1.3. To quote the Apache website: "We strongly recommend that users of all earlier versions, including 1.3 family release, upgrade to to the current 2.2 version as soon as possible." According to the Apache developers, 1.3's appeal is IJW (It Just Works). But your point is well taken. :) --Chris H -- Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. -- panic: kernel trap (ignored) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
