Re: [HEADS UP] change in devfs path matching logic
On 29/08/2013 08:47, Andriy Gapon wrote: on 28/08/2013 20:29 Jase Thew said the following: I'm getting a similar panic with r254986 on stable/8 when starting up jails : Thank you very much for the report. Somehow I missed Toomas'es report on the mailing list. It looks like I should have done more investigation on the state of devfs in stable/8 before MFC-ing the change. There are several earlier big commits that have not been MFC-ed. So, now I can either revert the MFC and be done with it. Or we can try to investigate the crash and see if it's easy to fix it. Do you guys have crashdumps from the panic? Hi Andriy, After some fiddling about, I've obtained a crashdump of this panic : http://goo.gl/sRXjo4 If you need anything else, please let me know. Regards, Jase. -- Jase Thew j...@freebsd.org FreeBSD Ports Committer ___ 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: [HEADS UP] change in devfs path matching logic
On 29/08/2013 11:11, Andriy Gapon wrote: on 29/08/2013 12:07 Jase Thew said the following: After some fiddling about, I've obtained a crashdump of this panic : http://goo.gl/sRXjo4 If you need anything else, please let me know. Obviously, I can't do anything with the vmcore without the matching kernel (and perhaps modules). Also, kgdb and libkvm.so from the matching system can be needed. Perhaps you could try examining the devfs_rule_run frame to give a start? Like listing the source code line and examining all local variables. Thank you. Hi Andriy, Unless I'm doing something wrong, there doesn't appear to be any useful information contained in the frame other than source line. kgdb script is available at http://goo.gl/ZS8Mjj I'll try merging r211847 as you suggested and will report back. Regards, Jase. -- Jase Thew j...@freebsd.org FreeBSD Ports Committer ___ 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: [HEADS UP] change in devfs path matching logic
On 29/08/2013 11:24, Andriy Gapon wrote: on 29/08/2013 10:47 Andriy Gapon said the following: It looks like I should have done more investigation on the state of devfs in stable/8 before MFC-ing the change. There are several earlier big commits that have not been MFC-ed. So, now I can either revert the MFC and be done with it. Or we can try to investigate the crash and see if it's easy to fix it. In fact, I am not sure but I hope that the fix could be as simple as MFC-ing r211847: http://svnweb.freebsd.org/base?view=revisionrevision=211847 http://svnweb.freebsd.org/base/head/sys/fs/devfs/devfs_vnops.c?view=patchr1=211847r2=211846pathrev=211847 Hi Andriy, I've merged that change, rebuilt the kernel and that appears to have resolved the panic. Jails are now starting up correctly with devfs rules being successfully applied. Thanks very much! Regards, Jase. -- Jase Thew j...@freebsd.org FreeBSD Ports Committer ___ 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: [HEADS UP] change in devfs path matching logic
On 24/08/2013 21:03, Toomas Aas wrote: Hello! On Fri, 23 Aug 2013 Andriy Gapon a...@freebsd.org wrote: This change is about to be MFC-ed. on 26/07/2013 17:39 Andriy Gapon said the following: I have just committed a significant change to devfs path matching logic http://svnweb.freebsd.org/changeset/base/253677 I just rebuilt my 8-STABLE i386 system to r254796 and now receive a kernel panic on boot. If I remove my /etc/devfs.rules file, the panic does not happen. Can anyone point out what is wrong with my devfs.rules what the new path matching logic doesn't like? $ cat /etc/devfs.rules.old [localrules=10] add path da* mode 0660 group operator add path usb/1.2.0 mode 0660 group uucp add path usb/4.3.0 mode 0660 group operator The panic, as transcribed from screen: Fatal trap 12: page fault while in kernel mode fault virtual address = 0x0 fault code= supervisor read, page not present instruction pointer = 0x20:0xc06dde21 stack pointer = 0x28:0xe8690a48 frame pointer = 0x28:0xe8690a80 code segment = base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, iopl = 0 current process = 577 (ln) trap number = 12 panic: page fault KDB: stack backtrace: #0 0xc0670ece at kdb_backtrace+0x50 #1 0xc06449fa at panic+0x132 #2 0xc07eb1d2 at trap_fatal+0x21e #3 0xc07eb4e0 at trap_pfault+0x1c2 #4 0xc07ec251 at trap+0x3c1 #5 0xc07d95fc at calltrap+0x6 #6 0xc05c7001 at devfs_rule_run+0x13d #7 0xc05c70c3 at devfs_ruleset_applyde+0x25 #8 0xc05c71b3 at devfs_rules_apply+0x73 #9 0xc05cad51 at devfs_symlink+0x124 #10 0xc080d084 at VOP_SYMLINK_APV+0x4a #11 0xc06d2985 at kern_symlinkat+0x38b #12 0xc06d29da at kern_symlink+0x2e #13 0xc06d2a05 at symlink+0x29 #14 0xc07eb7c7 at syscall+0x1a1 #15 0xc07d9661 at Xint0x80_syscall+0x21 Thanks in advance! I'm getting a similar panic with r254986 on stable/8 when starting up jails : # cat /var/crash/version.txt FreeBSD 8.4-STABLE #1 r254986M: Wed Aug 28 16:26:23 BST 2013 root@jailhost.localdomain:/usr/obj/usr/src/sys/JAILHOST # cat /etc/devfs.rules [devfsrules_jailzfs=5] add include $devfsrules_jail add path 'zfs' unhide [devfsrules_jail_tinderbox=6] add include $devfsrules_jail add path 'zfs' unhide add path 'mem' unhide add path 'kmem' unhide # awk '/Fatal trap/,0' /var/crash/msgbuf.txt Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x0 fault code = supervisor read data, page not present instruction pointer = 0x20:0x806f8e46 stack pointer = 0x28:0xff812375b670 frame pointer = 0x28:0xff812375b6d0 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 1028 (ln) trap number = 12 panic: page fault cpuid = 0 KDB: stack backtrace: db_trace_self_wrapper() at 0x8020466a = db_trace_self_wrapper+0x2a kdb_backtrace() at 0x80684df7 = kdb_backtrace+0x37 panic() at 0x806510ce = panic+0x1ce trap_fatal() at 0x809e8eb0 = trap_fatal+0x290 trap_pfault() at 0x809e923e = trap_pfault+0x23e trap() at 0x809e970e = trap+0x3ce calltrap() at 0x809cf894 = calltrap+0x8 --- trap 0xc, rip = 0x806f8e46, rsp = 0xff812375b670, rbp = 0xff812375b6d0 --- fnmatch() at 0x806f8e46 = fnmatch+0x66 devfs_rule_run() at 0x805d255b = devfs_rule_run+0x17b devfs_ruleset_applyde() at 0x805d2621 = devfs_ruleset_applyde+0x31 devfs_rules_apply() at 0x805d274a = devfs_rules_apply+0x6a devfs_symlink() at 0x805d624e = devfs_symlink+0x13e VOP_SYMLINK_APV() at 0x80a78f58 = VOP_SYMLINK_APV+0x68 kern_symlinkat() at 0x806edc9e = kern_symlinkat+0x38e amd64_syscall() at 0x809e8484 = amd64_syscall+0x1f4 Xfast_syscall() at 0x809cfb8c = Xfast_syscall+0xfc --- syscall (57, FreeBSD ELF64, symlink), rip = 0x8006a08bc, rsp = 0x7fffd838, rbp = 0x7fffed27 --- Uptime: 2m39s Regards, Jase. -- Jase Thew j...@freebsd.org FreeBSD Ports Committer ___ 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: FTPS Server?
On 05/01/2012 13:30, Gót András wrote: Hi, You can easily set up FTPS with pure-ftpd, but AFAIK only the authentication will be secured. This is also called FTP-TLS. Regards, Andras Hi, pure-ftpd offers configurable TLS support including control *and* data channel encryption. http://download.pureftpd.org/pub/pure-ftpd/doc/README.TLS Please refer to the ACCEPTING TLS SESSIONS section. Regards, Jase. ___ 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: Big problem still remains with 7.2-STABLE locking up
NAKAJI Hiroyuki wrote: Note that this is a lot of printout so you won't be able of collecting all these informations if not with a serial connection. The box does not have any serial port. Is there any other way? Is it possible to use dcons(4) for that purpose, if I add firewire PCI board? http://wiki.freebsd.org/DebugWithDcons may be of use to you. Regards, Jase Thew. ___ 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: apache 2.0.63 and php5
Barry Pederson wrote: I've been burned by this a fair number of times, wish there was some good way of having things starting from /usr/local/etc/rc.d to have /usr/local/bin and sbin in the path on a consistent basis. Barry Hi, /etc/profile is the system wide profile for sh shell. So, should you need to do this for all sh scripts ( including /usr/local/etc/rc.d/ scripts), simply add a PATH line to /etc/profile, eg: PATH=/foo/bar:/bar/baz:$PATH; export PATH or PATH=$PATH:/foo/bar:/bar/baz; export PATH depending on whether you want your additional directories to be searched before or after the default path. Regards, Jase. ___ 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.0 release to stable
Brian wrote: It turns out, as I look at the below, I was testing a unique process and didn't realize it. [...] So, I was migrating not only from a release to stable, but more specifically from a release to a prerelease. Hi, I think you misunderstand - 7.1-PRERELEASE is just the name [1] which has been given to RELENG_7 (aka 7-stable) in preparation for the code freeze leading up to 7.1-RELEASE. There is nothing special or unique about it :) Regards, Jase. [1] http://www.freebsd.org/cgi/getmsg.cgi?fetch=268263+0+current/cvs-src ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: CPUTYPE weirdness
Jeremy Chadwick wrote: On Thu, Aug 14, 2008 at 04:13:51PM +0200, Johan Hendriks wrote: Jeremy Chadwick wrote: On Thu, Aug 14, 2008 at 02:35:46PM +0200, Pascal Hofstee wrote: I just installed a fresh FreeBSD/amd64 7.0-RELEASE and trying to update to RELENG_7_0. I added CPUTYPE ?= core2 to my /etc/src.conf and every call to make in /usr/src now gives me the error /usr/src/Makefile.inc1, line 142: CPUTYPE global should be set with ?=. *** Error code 1 Anyone has any idea what i am doing wrong here ... this same mechanism has worked flawlessly on several other systems (although they were not RELENG_7_0) ? 1) Remove the space after the word CPUTYPE, e.g.: CPUTYPE?=core2 You can put a tab after the = if you want, e.g.: CPUTYPE?= core2 2) According to some very old mail I have (will dig it up if you want), Core2Duo users should be using CPUTYPE?=nocona. This should be fixed long time ago. core2 is alias for nocona but the idea is users to be ready when additional optimization for core2 are added. If you install amd64 then you need nocona if you install i386 you will need presscot. Or use core2 and FreeBSD itself looks at the arch and use nocona or presscot. That?s what I understand from what I read on the net 1) It's prescott, not presscot. 2) You can use nocona on both i386 and amd64 -- I speak from experience. I'm referring to RELENG_7 by the way; I don't think nocona is recognised by the base system gcc on RELENG_6. nocona is definitely supported by base gcc in RELENG_6_3 and is listed in the gcc manpage : nocona Improved version of Intel Pentium4 CPU with 64-bit extensions, MMX, SSE, SSE2 and SSE3 instruction set support. I have it in my /etc/make.conf for 6.3-REL/amd64 and it works a charm. Regards, Jase. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Don't recognizing SMP...
Alexander Sack wrote: On Tue, Apr 1, 2008 at 5:43 AM, Andrei Kolu [EMAIL PROTECTED] wrote: On Monday 31 March 2008 12:31:49 ??? wrote: I installed FreeBSD 7.0 on HP DL 380. This is a mptable result. # mptable Processors: APIC ID Version State Family Model Step Flags 0 0x14BSP, usable 6 2 1 0x0381 6 0x14AP, usable 15 2 9 0xbfebfbff 2 way cpus are same as 3.0GHz Xeon CPU. But they have different Family, Step, and Flags. SMP does NOT work with cpus with different steppings. You should find other matching pair for smp to work. Then this needs to be FIXED because MANY OEMs ship mixed stepping processors as Intel now supports it But does Intel support mixing different families and models? I was under the impression that as long as the families and models were the same, the stepping can be different. Regards, Jase. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD 7, Razer Copperhead mouse patch
John Baldwin wrote: On Saturday 23 February 2008 03:32:41 pm Dominic Fandrey wrote: Oliver Herold wrote: Hi the Razer Copperhead mouse did work in FreeBSD 7 (current) for a long time, but after some period it stopped working. This patch from Uwe Grohnwaldt: http://www.freebsd.org/cgi/query-pr.cgi?pr=usb/118670 fixes this wrong behaviour (it's detected as keyboard) and makes the mouse work in FreeBSD 7 again. Would be imho a nice addition for RELENG_7 (stable) or even Release. Cheers, Oliver Being a Razer fan and user I totally agree. Can you try this patch instead? Index: ums.c === RCS file: /usr/cvs/src/sys/dev/usb/ums.c,v retrieving revision 1.97 diff -u -r1.97 ums.c --- ums.c 26 Dec 2007 14:31:16 - 1.97 +++ ums.c 27 Feb 2008 21:40:48 - @@ -198,7 +198,10 @@ if (err) return (UMATCH_NONE); - if (id-bInterfaceClass == UICLASS_HID + if (hid_is_collection(desc, size, + HID_USAGE2(HUP_GENERIC_DESKTOP, HUG_MOUSE))) + ret = UMATCH_IFACECLASS; + else if (id-bInterfaceClass == UICLASS_HID id-bInterfaceSubClass == UISUBCLASS_BOOT id-bInterfaceProtocol == UIPROTO_MOUSE) ret = UMATCH_IFACECLASS; Hi, Out of curiosity, what was wrong with the way I did it in my patch? Regards, Jase. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD 7, Razer Copperhead mouse patch
Jase Thew wrote: John Baldwin wrote: On Saturday 23 February 2008 03:32:41 pm Dominic Fandrey wrote: Oliver Herold wrote: Hi the Razer Copperhead mouse did work in FreeBSD 7 (current) for a long time, but after some period it stopped working. This patch from Uwe Grohnwaldt: http://www.freebsd.org/cgi/query-pr.cgi?pr=usb/118670 fixes this wrong behaviour (it's detected as keyboard) and makes the mouse work in FreeBSD 7 again. Would be imho a nice addition for RELENG_7 (stable) or even Release. Cheers, Oliver Being a Razer fan and user I totally agree. Can you try this patch instead? Index: ums.c === RCS file: /usr/cvs/src/sys/dev/usb/ums.c,v retrieving revision 1.97 diff -u -r1.97 ums.c --- ums.c 26 Dec 2007 14:31:16 - 1.97 +++ ums.c 27 Feb 2008 21:40:48 - @@ -198,7 +198,10 @@ if (err) return (UMATCH_NONE); - if (id-bInterfaceClass == UICLASS_HID + if (hid_is_collection(desc, size, + HID_USAGE2(HUP_GENERIC_DESKTOP, HUG_MOUSE))) + ret = UMATCH_IFACECLASS; + else if (id-bInterfaceClass == UICLASS_HID id-bInterfaceSubClass == UISUBCLASS_BOOT id-bInterfaceProtocol == UIPROTO_MOUSE) ret = UMATCH_IFACECLASS; Hi, Out of curiosity, what was wrong with the way I did it in my patch? Regards, Jase. ___ Ah, I see John has described why in the PR. As the hid collection test doesn't seem to be working fully, what would be the downside of testing the descriptor directly but removing the SubClass test, as the spec defines only two available values - 1 for using Boot Protocol and 2 for Unknown. As we can't test for a SubClass of 0 (due to the reason you mention above), removing the SubClass test will reintroduce full support for mice that report as not using boot protocol (such as the various Razor mice). Regards, Jase. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD 7, Razer Copperhead mouse patch
Jase Thew wrote: Jase Thew wrote: John Baldwin wrote: On Saturday 23 February 2008 03:32:41 pm Dominic Fandrey wrote: Oliver Herold wrote: Hi the Razer Copperhead mouse did work in FreeBSD 7 (current) for a long time, but after some period it stopped working. This patch from Uwe Grohnwaldt: http://www.freebsd.org/cgi/query-pr.cgi?pr=usb/118670 fixes this wrong behaviour (it's detected as keyboard) and makes the mouse work in FreeBSD 7 again. Would be imho a nice addition for RELENG_7 (stable) or even Release. Cheers, Oliver Being a Razer fan and user I totally agree. Can you try this patch instead? Index: ums.c === RCS file: /usr/cvs/src/sys/dev/usb/ums.c,v retrieving revision 1.97 diff -u -r1.97 ums.c --- ums.c 26 Dec 2007 14:31:16 - 1.97 +++ ums.c 27 Feb 2008 21:40:48 - @@ -198,7 +198,10 @@ if (err) return (UMATCH_NONE); - if (id-bInterfaceClass == UICLASS_HID + if (hid_is_collection(desc, size, + HID_USAGE2(HUP_GENERIC_DESKTOP, HUG_MOUSE))) + ret = UMATCH_IFACECLASS; + else if (id-bInterfaceClass == UICLASS_HID id-bInterfaceSubClass == UISUBCLASS_BOOT id-bInterfaceProtocol == UIPROTO_MOUSE) ret = UMATCH_IFACECLASS; Hi, Out of curiosity, what was wrong with the way I did it in my patch? Regards, Jase. ___ Ah, I see John has described why in the PR. As the hid collection test doesn't seem to be working fully, what would be the downside of testing the descriptor directly but removing the SubClass test, as the spec defines only two available values - 1 for using Boot Protocol and 2 for Unknown. As we can't test for a SubClass of 0 (due to the reason you mention above), removing the SubClass test will reintroduce full support for mice that report as not using boot protocol (such as the various Razor mice). Regards, Jase. Doh. I misread the John's comment in the PR the first time around. In light of what John mentions about the Protocol and SubClass, the suggestion above makes no sense and can be safely ignored :) Regards, Jase. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD 7.0-RC2 Available
Abdullah Ibn Hamad Al-Marri wrote: How about RELENG_7? will we still get PRERELEASE? Regards, -Abdullah Ibn Hamad Al-Marri Arab Portal http://www.WeArab.Net/ I imagine RELENG_7 will stay at PRERELEASE until 7.0-RELEASE is out of the door, at which point it will become 7.0-STABLE. Rgds, Jase. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: latest Intel Core 2 Duo processors are buggy as hell
Andrei Kolu wrote: According to Theo de Raadth http://marc.info/?l=openbsd-miscm=118296441702631 latest Intel Core 2 Duo processors are buggy as hell. What counter-measures are taken within FreeBSD community? ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] Well personally, the first counter-measure I take is to run Theo's posts through a drama-queen filter - this usually diffuses the points made back down to the mole hills that the original mountains were made out of ;) Baz. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: portdowngrade/portupgrade question
Par Leijonhufvud wrote: Pertti Kosunen [EMAIL PROTECTED] [2007.01.18] wrote: What have I missed? Update your ports tree, that version of fetchmail has vulnerabilities. I know that. But fetching with fetchmail stopped working when I did that (when the new port came I did a portupgrade, forgot to kill restart fetchmail, when I did so a day or so later it just dumped core), and I'm trying to pin down exactly what is going wrong. As part of that I want to try to go back to the old fetchmail and try it *fully knowing that it has vulnerabilities*. Which appears to be either obscure, difficult or impossible. /Par portupgrade -f -m '-DDISABLE_VULNERABILITIES' fetchmail ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Attention Julian Stacey
Julian H. Stacey wrote: Julian, meet Kris. Kris has been the head of the FreeBSD ports team for Long enough without peer review. Leaders don't post flame bait. - Below _Not_ personal criticism of any individual. - Ideas of Automatic peer review, rotations etc are used by clubs, companies, governments. I'm not aware if FreeBSD has adopted them yet. - Reviews detects burn out, raised frequency of agression attitudes etc. Sabaticals, holidays etc are good for volunteers too, not just employees. - Core are now elected by commiters, but when I suggested elections way back, it was flamed on high, so peer review could happen too. - 7 day suspensions for flamers could also help, unless they apologise within eg 48 hours to list (not necessarily recipient) for abuse of list. The problem's not even really list abuse, but that tolerating spurious alienating agression (by list or private mail) over years from a tiny minority will have reduced code etc received in consequence from numerous others deterred. We have no employing boss to knocks heads, just the opposite, a few whose periodic implicit challenge is: Tolerate my periodic agression or I'll take my toys leave. Perhaps most wouldn't leave. If they did, we'd still survive, FreeBSD even survived when John (swap) Dyson very unfortunately got deterred left, probably no threatened skill loss would be harder to replace. No disrespect intended, but I think you need to obtain a sense of humour. J. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FTPd recommendation?
Chris H. wrote: Quoting Iantcho Vassilev [EMAIL PROTECTED]: My vote goes to PureFtpd.. It`s ideal server.. But is not *nearly* as secure as vsftpd. Hi, I'm curious - do you have any empirical evidence to support this? A trawl of a few vulnerabilty databases would suggest your comment is not entirely accurate. NVD NIST [1] shows 4 entries for vsftpd (latest 2005-12) , 1 for pureftpd (latest 2004-08) SecurityFocus [2] shows 1 entry for vsftpd (latest 2004-05), 2 for pureftpd (latest 2004-07) ISS X-Force [3] shows entries 3 for vsftpd (latest 2004-05), for 1 pureftpd (latest 2004-07) Regards, Jase. [1] http://nvd.nist.gov/nvd.cfm [2] http://www.securityfocus.com/vulnerabilities [3] http://xforce.iss.net/xforce/search.php ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Strange crashing/rebooting problem
Jayton Garnett wrote: Hello, You should be using the IA-64 version of FreeBSD as these are Intel chips and nor AMD chips? FreeBSD 5.4 IA-64 is for the Intel EM64T/Xeon/Itainium CPU's, FreeBSD 5.4 AMD64 is for the AMD 64/x2/Opteron/FX CPU's. You will have more luck using the IA-64 release, I am not sure if you can cvsup the source and rebuild the IA-64 version so you might have to do a fresh install, and since you have backups of your databases it should not take you longer than 1hour to get it all running smoothly again. Kind regards, Jayton Garnett Hiyas, This is incorrect. The IA-64 builds are for Intel Itanium and Itanium-2 processors only [1]. The AMD64 builds are the correct ones to use for both AMD64 and Intel EM64T processors when 64-bit support is required [2]. Regards, Jase Thew. [1] http://www.freebsd.org/releases/5.4R/hardware-ia64.html#PROC-IA64 [2] http://www.freebsd.org/releases/5.4R/hardware-amd64.html#PROC ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
