Re: Using ipfw table names instead of numbers.
I'd argue that DNS clue pushes the firewall out from a packet inspection thing and into a user-space application inspection thing. DNS entries in filter rules doesn't work as well in all situations as you'd like. :) Adrian (who has done this, and it doesn't quite work right in all situations thanks to split-horizon, per-user, geo-location, server-balancing DNS..) On 6 September 2010 08:31, jhell jh...@dataix.net wrote: On 09/05/2010 11:53, Luigi Rizzo wrote: whereas one might want a more dynamic behaviour (e.g. refresh whenever the DNS response expires). Lord that would be nice! if only PF had this ;) -- jhell,v ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Using ipfw table names instead of numbers.
On 09/05/2010 11:47 PM, Adrian Chadd wrote: I'd argue that DNS clue pushes the firewall out from a packet inspection thing and into a user-space application inspection thing. It also opens up an attack vector on your firewall. Doug -- Improve the effectiveness of your Internet presence with a domain name makeover!http://SupersetSolutions.com/ Computers are useless. They can only give you answers. -- Pablo Picasso ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
significantly slow IPFW + NATD + amd64
Hello, I tried setup NAT with IPFW, compiled my kernel and I found that there is very slow connection. After I disabled NAT and IPFW then speed was increased. 64-bit FreeBSD 9-CURRENT : With IPFW: 1.2 MB/sec Without IPFW: 33 MB/sec my ipfw work with i386 (stable) without speed decreasing: fw.test.conf: -f flush add 00050 divert 8668 ip4 from any to any via re0 add 00100 allow ip from any to any via lo0 add 00200 deny ip from any to 127.0.0.0/8 add 00300 deny ip from 127.0.0.0/8 to any -- peter ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: significantly slow IPFW + NATD + amd64
Peter Reo Molnar wrote: Hello, I tried setup NAT with IPFW, compiled my kernel and I found that there is very slow connection. After I disabled NAT and IPFW then speed was increased. 64-bit FreeBSD 9-CURRENT : With IPFW: 1.2 MB/sec Without IPFW: 33 MB/sec my ipfw work with i386 (stable) without speed decreasing: fw.test.conf: -f flush add 00050 divert 8668 ip4 from any to any via re0 add 00100 allow ip from any to any via lo0 add 00200 deny ip from any to 127.0.0.0/8 add 00300 deny ip from 127.0.0.0/8 to any This looks like you're using the old style NAT - divert to userland. That has always performed poorly. Perhaps not as poorly as this though. How much CPU is natd consuming? Have you considered using in-kernel NAT? See the 'NETWORK ADDRESS TRANSLATION' section in the ipfw manual. It's worth a try. Ian -- Ian Freislich ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
[head tinderbox] failure on mips/mips
TB --- 2010-09-06 10:40:14 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-09-06 10:40:14 - starting HEAD tinderbox run for mips/mips TB --- 2010-09-06 10:40:14 - cleaning the object tree TB --- 2010-09-06 10:40:41 - cvsupping the source tree TB --- 2010-09-06 10:40:41 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup18.freebsd.org /tinderbox/HEAD/mips/mips/supfile TB --- 2010-09-06 10:46:16 - WARNING: /usr/bin/csup returned exit code 1 TB --- 2010-09-06 10:46:16 - ERROR: unable to cvsup the source tree TB --- 2010-09-06 10:46:16 - 1.57 user 24.16 system 362.63 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-mips-mips.full ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: significantly slow IPFW + NATD + amd64
Ian FREISLICH wrote: Peter Reo Molnar wrote: Hello, I tried setup NAT with IPFW, compiled my kernel and I found that there is very slow connection. After I disabled NAT and IPFW then speed was increased. 64-bit FreeBSD 9-CURRENT : With IPFW: 1.2 MB/sec Without IPFW: 33 MB/sec my ipfw work with i386 (stable) without speed decreasing: fw.test.conf: -f flush add 00050 divert 8668 ip4 from any to any via re0 add 00100 allow ip from any to any via lo0 add 00200 deny ip from any to 127.0.0.0/8 add 00300 deny ip from 127.0.0.0/8 to any This looks like you're using the old style NAT - divert to userland. That has always performed poorly. Perhaps not as poorly as this though. How much CPU is natd consuming? Have you considered using in-kernel NAT? See the 'NETWORK ADDRESS TRANSLATION' section in the ipfw manual. It's worth a try. i never managed to figure out how to convert my pppoe nat config to ipfw natting. foo: set device PPPoE:vr0 set MTU 1454 accept CHAP enable lqr add default HISADDR nat enable yes nat port tcp 192.168.0.33:51332 51332 nat port udp 192.168.0.33:51332 51332 set authname blogovitch set authkey vitchoblog loop: set log phase chat connect lcp ipcp command set device localhost:pptp set dial set login set ifaddr 192.168.0.200 192.168.0.201 255.255.255.255 clue bat solicited randy ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: significantly slow IPFW + NATD + amd64
Am 06.09.2010 um 13:08 schrieb Randy Bush: i never managed to figure out how to convert my pppoe nat config to ipfw natting. I did not see a significant improvement going from ppp(8)+9 and ipfw to ppp(8) and pf+nat. Since ppp(8) already incurs the kernel/userland cost, having it handle NAT on top does not increase latency. I've recently switched to mpd (and pf), and things feel snappier. I haven't benchmarked it though, and my router box is rather oversized for the task anyway (C2D). Friends using a Soekris swear that it helps a lot though. The switchover is fairly painless, and the excellent mpd manual helps a lot. Using one of the many examples, I managed to set up the mpd.conf rather quickly; the only real adaptation was in the up and down scripts I was using (my ISP kicks the connection every 24 hours, and I get a new IP, so I like to bounce a couple of things when the connection comes up again.) Stefan -- Stefan Bethke s...@lassitu.de Fon +49 151 14070811 mpd.conf: # # Default configuration is dialup default: load hansenet hansenet: # # PPPoE client: only outgoing calls, auto reconnect, # ipcp-negotiated address, one-sided authentication, # default route points on ISP's end # create bundle static hansenet #set bundle yes ipv6cp set iface route default set iface up-script /etc/ppp/hansenet.up set iface down-script /etc/ppp/hansenet.down set iface enable tcpmssfix create link static hansenet pppoe set pppoe iface vlan2 set pppoe service set link action bundle hansenet set link max-redial 0 set link keep-alive 10 60 set auth authname 04012345678 #set auth password MyPass set ipcp ranges 0.0.0.0/0 0.0.0.0/0 open My old ppp.conf: hansenet: set device PPPoE:vlan2: set mru 1492 set mtu 1492 set speed sync enable lqr enable echo set lqrperiod 5 set cd 5 set dial set login set timeout 0 set authname 04012345678 add default HISADDR ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: ZFS v28 is ready for wider testing.
Hi everyone, I have put together a slightly improved patch of Pawel's that compiles correctly and supports booting from ZFS v19 pools. You can download the patch here: http://people.freebsd.org/~mm/patches/zfs/head-zfs-v28-20100831.patch For users who don't want to compile I have created a mfsBSD ISO image with a zfs-only install of 9-CURRENT-amd64: http://mfsbsd.vx.sk/iso/mfsbsd-se-head-zfsv28-amd64.iso You can read more about all of this here: http://blog.vx.sk/archives/9-Help-testing-ZFS-v28-in-FreeBSD.html More information about ZFS pool and filesystem versions: http://blog.vx.sk/archives/4-ZFS-pool-and-filesystem-versions.html Thanks to everybody participating in testing, mm ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: patch for topology detection of Intel CPUs
on 29/08/2010 12:25 Andriy Gapon said the following: The below patch is against sources in FreeBSD tree, it should be applied either to sys/amd64/amd64/mp_machdep.c or sys/i386/i386/mp_machdep.c depending on the desired architecture: http://people.freebsd.org/~avg/intel-cpu-topo.diff I see that I am not getting as many testers as I expected, so I am going to commit the patch. You still have a short while to either objectively object to the patch or to voluntary test it :-) -- Andriy Gapon ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: patch for topology detection of Intel CPUs
On Mon, Sep 06, 2010 at 03:17:42PM +0300, Andriy Gapon wrote: on 29/08/2010 12:25 Andriy Gapon said the following: The below patch is against sources in FreeBSD tree, it should be applied either to sys/amd64/amd64/mp_machdep.c or sys/i386/i386/mp_machdep.c depending on the desired architecture: http://people.freebsd.org/~avg/intel-cpu-topo.diff I see that I am not getting as many testers as I expected, so I am going to commit the patch. You still have a short while to either objectively object to the patch or to voluntary test it :-) I would gladly assist in testing this, except there doesn't appear to be an authoritative statement that it will apply to RELENG_8; when I see WIP, I assume -CURRENT/HEAD only. Let me know, since all the systems I have are Intel multi-core. -- | Jeremy Chadwick j...@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-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
At r212060, but /usr/bin/drace and /usr/sbin/lockstat still depend on libz.so.5
On sparc64 after updating to r212060, libz.so.5 came up as old library. I rebuit all ports to use libz.so.6 instead, but libchk still shows that Binaries that are linked with: /lib/libz.so.5 /usr/sbin/dtrace /usr/sbin/lockstat What did I do wrong that resulted in these 2 programs still linked against the old version of libz? many thanks anton -- Anton Shterenlikht Room 2.6, Queen's Building Mech Eng Dept Bristol University University Walk, Bristol BS8 1TR, UK Tel: +44 (0)117 331 5944 Fax: +44 (0)117 929 4423 ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: patch for topology detection of Intel CPUs
on 06/09/2010 15:23 Jeremy Chadwick said the following: On Mon, Sep 06, 2010 at 03:17:42PM +0300, Andriy Gapon wrote: on 29/08/2010 12:25 Andriy Gapon said the following: The below patch is against sources in FreeBSD tree, it should be applied either to sys/amd64/amd64/mp_machdep.c or sys/i386/i386/mp_machdep.c depending on the desired architecture: http://people.freebsd.org/~avg/intel-cpu-topo.diff I see that I am not getting as many testers as I expected, so I am going to commit the patch. You still have a short while to either objectively object to the patch or to voluntary test it :-) I would gladly assist in testing this, except there doesn't appear to be an authoritative statement that it will apply to RELENG_8; when I see WIP, I assume -CURRENT/HEAD only. patch -C is much better than any statement :) Let me know, since all the systems I have are Intel multi-core. Yes, the patch should be applicable to stable/8 without any issues. -- Andriy Gapon ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: At r212060, but /usr/bin/drace and /usr/sbin/lockstat still depend on libz.so.5
On 6 September 2010 16:50, Anton Shterenlikht me...@bristol.ac.uk wrote: On sparc64 after updating to r212060, libz.so.5 came up as old library. I rebuit all ports to use libz.so.6 instead, but libchk still shows that Binaries that are linked with: /lib/libz.so.5 /usr/sbin/dtrace /usr/sbin/lockstat What did I do wrong that resulted in these 2 programs still linked against the old version of libz? Hi, Anton. After r210693, these utilities are built for i386 and amd64 only. Thereby you have stale binaries installed from older sources. -- wbr, pluknet ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: bge(4) problem on sparc64 between r204991M and r212097
On Fri, Sep 03, 2010 at 11:25:34AM -0700, Pyun YongHyeon wrote: On Fri, Sep 03, 2010 at 09:42:04AM +0100, Anton Shterenlikht wrote: On Thu, Sep 02, 2010 at 11:36:03AM -0700, Pyun YongHyeon wrote: On Thu, Sep 02, 2010 at 06:03:16PM +0100, Anton Shterenlikht wrote: On Thu, Sep 02, 2010 at 11:00:14AM +0100, Anton Shterenlikht wrote: I just updated world and kernel from r204991M to r212097 on sparc64. Now I can't ping my gateway. If I boot kernel.old, then the network works fine. As far as I could see mergemaster didn't update any network files. Please advise In the meantime I'll try intermediate revisions. I narrowed down the problem to between r212050 and r212080. Will continue tomorrow. Thanks for reporting. There was a big change in r212061, so try backing out that revision and see whether this makes differences or not. yes, r212061 is the offending revision, r212060 works fine. Please let me know if you want any further information. Thanks for narrowing down guilty revision. Would you show me verbose boot message? First here's diff between dmesg outputs from r212060 and r212061: 8c8 FreeBSD 9.0-CURRENT #0 r212060: Fri Sep 3 09:06:59 BST 2010 --- FreeBSD 9.0-CURRENT #0 r212061: Fri Sep 3 09:32:25 BST 2010 11c11 Preloaded elf kernel /boot/kernel.old/kernel at 0xc08ee000. --- Preloaded elf kernel /boot/kernel/kernel at 0xc08ee000. 333,334c333,334 ct_to_ts([2010-09-06 13:57:13]) = 1283781433.0 rtc0: current time: 1283781433.0 --- ct_to_ts([2010-09-06 13:51:20]) = 1283781080.0 rtc0: current time: 1283781080.0 340c340 uart1: 16550 or compatible at port 0x2e8-0x2ef irq 44 on isa0 --- uart1: Non-standard ns8250 class UART with FIFOs at port 0x2e8-0x2ef irq 44 on isa0 435c435 ct_to_ts([2010-09-06 13:57:16]) = 1283781436.0 --- ct_to_ts([2010-09-06 13:51:23]) = 1283781083.0 437d436 bge0: link UP 439d437 ts_to_ct(1283781463.0) = [2010-09-06 13:57:43] 442c440 2nd 0xf80001557600 dirhash (dirhash) @ /usr/src/sys/ufs/ufs/ufs_dirhash.c:283 --- 2nd 0xf8000155f400 dirhash (dirhash) @ /usr/src/sys/ufs/ufs/ufs_dirhash.c:283 This is full dmesg from r212060, below that is r212061. GDB: no debug ports present KDB: debugger backends: ddb KDB: current backend: ddb Copyright (c) 1992-2010 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-CURRENT #0 r212060: Fri Sep 3 09:06:59 BST 2010 r...@mech-anton240.men.bris.ac.uk:/usr/obj/usr/src/sys/QOF sparc64 WARNING: WITNESS option enabled, expect reduced performance. Preloaded elf kernel /boot/kernel.old/kernel at 0xc08ee000. real memory = 2147483648 (2048 MB) avail memory = 2079604736 (1983 MB) machine: SUNW,Sun-Blade-1500-S cpu0: Sun Microsystems UltraSparc-IIIi Processor (1503.00 MHz CPU) mask=0x34 maxtl=5 maxwin=7 snd_unit_init() u=0x00ff8000 [512] d=0x7c00 [32] c=0x03ff [1024] feeder_register: snd_unit=-1 snd_maxautovchans=16 latency=5 feeder_rate_min=1 feeder_rate_max=2016000 feeder_rate_round=25 null: null device, zero device random: entropy source, Software, Yarrow nfslock: pseudo-device mem: memory openfirm: Open Firmware control device nexus0: Open Firmware Nexus device nexus0: memory-controller mem 0x400-0x407 type memory-controller (no driver attached) pcib0: Sun Host-PCI bridge mem 0x4000f60-0x4000f60afff,0x4000f41-0x4000f41701f,0x7fe-0x7fe00ff,0x4000f78-0x4000f78 irq 1970,1968,1969,1972,1953 on nexus0 pcib0: Tomatillo, version 4, IGN 0x1e, bus A, 33MHz Timecounter pcib0 frequency 16700 Hz quality -100 pcib0: DVMA map: 0xc000 to 0xdfff 65536 entries pcib0: PROM IOTSB size: 1 (2048 entries) pcib0: adding PROM IOTSB slot 0 (kernel slot 63488) TTE: 0x80023fdc0012 pcib0: adding PROM IOTSB slot 1 (kernel slot 63489) TTE: 0x80023fdc2012 pcib0: adding PROM IOTSB slot 2 (kernel slot 63490) TTE: 0x80023fdc4012 pcib0: adding PROM IOTSB slot 3 (kernel slot 63491) TTE: 0x80023fdc6012 pcib0: adding PROM IOTSB slot 4 (kernel slot 63492) TTE: 0x80023fdc8012 pcib0: adding PROM IOTSB slot 5 (kernel slot 63493) TTE: 0x80023fdca012 pcib0: adding PROM IOTSB slot 6 (kernel slot 63494) TTE: 0x80023fdcc012 pcib0: adding PROM IOTSB slot 7 (kernel slot 63495) TTE: 0x80023fdce012 pcib0: adding PROM IOTSB slot 8 (kernel slot 63496) TTE: 0x80023fdd0012 pcib0: adding PROM IOTSB slot 9 (kernel slot 63497) TTE: 0x80023fdd2012 pcib0: adding PROM IOTSB slot 10 (kernel slot 63498) TTE: 0x80023fdd4012 pcib0: adding PROM IOTSB slot 11 (kernel slot 63499) TTE: 0x80023fdd6012 pcib0: adding PROM IOTSB slot 12 (kernel slot 63500) TTE: 0x80023fdd8012 pcib0: adding PROM IOTSB slot 13 (kernel slot 63501) TTE:
Re: At r212060, but /usr/bin/drace and /usr/sbin/lockstat still depend on libz.so.5
On Mon, Sep 06, 2010 at 05:03:31PM +0400, pluknet wrote: On 6 September 2010 16:50, Anton Shterenlikht me...@bristol.ac.uk wrote: On sparc64 after updating to r212060, libz.so.5 came up as old library. I rebuit all ports to use libz.so.6 instead, but libchk still shows that Binaries that are linked with: /lib/libz.so.5 /usr/sbin/dtrace /usr/sbin/lockstat What did I do wrong that resulted in these 2 programs still linked against the old version of libz? Hi, Anton. After r210693, these utilities are built for i386 and amd64 only. Thereby you have stale binaries installed from older sources. oh, I see. There is an ongoing thread on DTrace in -current. It's probably related to my issue? many thanks anton -- Anton Shterenlikht Room 2.6, Queen's Building Mech Eng Dept Bristol University University Walk, Bristol BS8 1TR, UK Tel: +44 (0)117 331 5944 Fax: +44 (0)117 929 4423 ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: significantly slow IPFW + NATD + amd64
Randy Bush wrote:
Ian FREISLICH wrote:
Peter Reo Molnar wrote:
Hello,
I tried setup NAT with IPFW, compiled my kernel and I found that there
is very slow connection.
After I disabled NAT and IPFW then speed was increased.
64-bit FreeBSD 9-CURRENT :
With IPFW: 1.2 MB/sec
Without IPFW: 33 MB/sec
my ipfw work with i386 (stable) without speed decreasing:
fw.test.conf:
-f flush
add 00050 divert 8668 ip4 from any to any via re0
add 00100 allow ip from any to any via lo0
add 00200 deny ip from any to 127.0.0.0/8
add 00300 deny ip from 127.0.0.0/8 to any
This looks like you're using the old style NAT - divert to userland.
That has always performed poorly. Perhaps not as poorly as this
though. How much CPU is natd consuming?
Have you considered using in-kernel NAT? See the 'NETWORK ADDRESS
TRANSLATION' section in the ipfw manual. It's worth a try.
i never managed to figure out how to convert my pppoe nat config to ipfw
natting.
foo:
set device PPPoE:vr0
set MTU 1454
accept CHAP
enable lqr
add default HISADDR
nat enable yes
nat port tcp 192.168.0.33:51332 51332
nat port udp 192.168.0.33:51332 51332
set authname blogovitch
set authkey vitchoblog
loop:
set log phase chat connect lcp ipcp command
set device localhost:pptp
set dial
set login
set ifaddr 192.168.0.200 192.168.0.201 255.255.255.255
clue bat solicited
I should have prefaced this with last used ipfw in 2005. One of the
reasons for this was poor NAT performance because of all the kernel-user
and back again copies. I've always done it your way for 2 reasons:
1. In this country, PPPoE means you're using ADSL or some broadband
connection, and you can't get them fast enough that filling your
line will use more than 1% CPU doing NAT in userland.
2. The broadband in this country assigns a dynamic IP address and
until recently reset the connection every 24h, so your NAT had
to be aware of these changes and restart itself.
You can use the ppp.linkup and ppp.linkdown files to make scripts
for your ppp profiles to add and delete NAT rules and restart natd.
For instance I used to run a PPP over UDP tunnel over my PPPoE
connection to get a static IP address at home. The ppp profile
that was always on was called adsl. I had a seperate profile called
tunnel that would start only when the adsl profile had link:
ppp.linkup
---
adsl:
! sh -c pppctl -p pass 127.0.0.1:3001 quit all; sleep 30;
/usr/sbin/ppp -unit 1 -quiet -ddial tunnel
---
ppp.linkdown
---
[brane] /etc/ppp # cat ppp.linkdown
adsl:
! sh -c pppctl -p pass 127.0.0.1:3001 quit all
---
I'm sure you could coax these scripts to do what you want, but
unless you have more than 50mbps I doubt it's worth the effort.
pf just makes so much more sense for NAT, but it suffers the same
static addressing problem:
nat on vlan2 from { 41.154.7.0/24 } - 41.161.16.1
Ian
--
Ian Freislich
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: patch for topology detection of Intel CPUs
on 06/09/2010 16:12 Jeremy Chadwick said the following: Great, thanks! I'll be testing this out on two separate systems, both RELENG_8: - Supermicro X7SBA + Intel C2D E8400 (stepping 10) - Supermicro X7SBL-LN2 + Intel C2D E6600 (stepping 6) I'll make sure to provide what the topology looks like before and after. Is CPU-relevant dmesg output sufficient? If you mean something like the below, then yes. Thanks! CPU: Intel(R) Core(TM)2 Duo CPU E7300 @ 2.66GHz (2653.35-MHz K8-class CPU) Origin = GenuineIntel Id = 0x10676 Family = 6 Model = 17 Stepping = 6 Features=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE Features2=0x8e39dSSE3,DTES64,MON,DS_CPL,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1 AMD Features=0x20100800SYSCALL,NX,LM AMD Features2=0x1LAHF TSC: P-state invariant [snip] 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 -- Andriy Gapon ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: significantly slow IPFW + NATD + amd64
I'm sure you could coax these scripts to do what you want, but unless you have more than 50mbps I doubt it's worth the effort. i live in a first world country. 100/100 for 3250yen/mo (that's about 35usd. randy ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: At r212060, but /usr/bin/drace and /usr/sbin/lockstat still depend on libz.so.5
On Mon, 6 Sep 2010, jhell wrote: After r210693, these utilities are built for i386 and amd64 only. Thereby you have stale binaries installed from older sources. Lol this is the first I have read about this comes as quite the surprise that its not being built on top of the platform/arch that it was designed to work on. Given this is FreeBSD and !*Solaris its understandable to a certain point but still... I for one eagerly look forward to the day where we can get DTrace working on MIPs, which is a widely-used architecture in the network device / appliance / etc community. Robert ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: patch for topology detection of Intel CPUs
On Mon, Sep 06, 2010 at 03:56:01PM +0300, Andriy Gapon wrote: on 06/09/2010 15:23 Jeremy Chadwick said the following: On Mon, Sep 06, 2010 at 03:17:42PM +0300, Andriy Gapon wrote: on 29/08/2010 12:25 Andriy Gapon said the following: The below patch is against sources in FreeBSD tree, it should be applied either to sys/amd64/amd64/mp_machdep.c or sys/i386/i386/mp_machdep.c depending on the desired architecture: http://people.freebsd.org/~avg/intel-cpu-topo.diff I see that I am not getting as many testers as I expected, so I am going to commit the patch. You still have a short while to either objectively object to the patch or to voluntary test it :-) I would gladly assist in testing this, except there doesn't appear to be an authoritative statement that it will apply to RELENG_8; when I see WIP, I assume -CURRENT/HEAD only. patch -C is much better than any statement :) Let me know, since all the systems I have are Intel multi-core. Yes, the patch should be applicable to stable/8 without any issues. Great, thanks! I'll be testing this out on two separate systems, both RELENG_8: - Supermicro X7SBA + Intel C2D E8400 (stepping 10) - Supermicro X7SBL-LN2 + Intel C2D E6600 (stepping 6) I'll make sure to provide what the topology looks like before and after. Is CPU-relevant dmesg output sufficient? -- | Jeremy Chadwick j...@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-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: patch for topology detection of Intel CPUs
on 06/09/2010 19:22 Jeremy Chadwick said the following: On Mon, Sep 06, 2010 at 04:28:02PM +0300, Andriy Gapon wrote: on 06/09/2010 16:12 Jeremy Chadwick said the following: Great, thanks! I'll be testing this out on two separate systems, both RELENG_8: - Supermicro X7SBA + Intel C2D E8400 (stepping 10) - Supermicro X7SBL-LN2 + Intel C2D E6600 (stepping 6) I'll make sure to provide what the topology looks like before and after. Is CPU-relevant dmesg output sufficient? If you mean something like the below, then yes. Thanks! [...] All done. Good news (I think): there's no difference in the CPU-related topology on either system with your patch, aside from kernel build date. The topologies are still detected correctly. In case you want them: Thanks a lot for the test! [test results snipped] All other systems I have are C2D and C2Q-based, but I can't easily test on those given their production roles. If there's a particular Intel processor family/model you're interested in, let me know and I can dig around to see if I have access to one. No particular models in mind. If you have systems with more complex topologies, like multiple physical packages or HTT enabled, I will be interested in seeing test results for those. Thanks again. -- Andriy Gapon ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
system locks up after a few unsuccessful attempts to create a snapshot of /
hi there, i was trying to create a snapshot of my root fs. the commands i used were 1) mksnap_ffs /.snap/snap1 and 2) mount -u -o snapshot /.snap/snap1 / both command failed with EAGAIN and the following was output to the console: Sep 6 18:05:56 otaku kernel: fsync: giving up on dirty Sep 6 18:05:56 otaku kernel: 0xff000552dd20: tag devfs, type VCHR Sep 6 18:05:56 otaku kernel: usecount 1, writecount 0, refcount 1372 mountedhere 0xff0005650a00 Sep 6 18:05:56 otaku kernel: flags () Sep 6 18:05:56 otaku kernel: v_object 0xff000568fbd0 ref 0 pages 5486 Sep 6 18:05:56 otaku kernel: lock type devfs: EXCL by thread 0xff006b473840 (pid 48144) Sep 6 18:05:56 otaku kernel: dev ufs/rootfs Sep 6 18:08:19 otaku sudo: arundel : TTY=pts/0 ; PWD=/usr/src/sbin/mksnap_ffs ; USER=root ; COMMAND=/sbin/mksnap_ffs /.snap/snapshot1 Sep 6 18:08:29 otaku sudo: arundel : TTY=pts/0 ; PWD=/usr/src/sbin/mksnap_ffs ; USER=root ; COMMAND=/sbin/mksnap_ffs /.snap/snapshot1 Sep 6 18:09:13 otaku kernel: fsync: giving up on dirty Sep 6 18:09:14 otaku kernel: 0xff000552dd20: tag devfs, type VCHR Sep 6 18:09:14 otaku kernel: usecount 1, writecount 0, refcount 1373 mountedhere 0xff0005650a00 Sep 6 18:09:14 otaku kernel: flags () Sep 6 18:09:14 otaku kernel: v_object 0xff000568fbd0 ref 0 pages 5482 Sep 6 18:09:14 otaku kernel: lock type devfs: EXCL by thread 0xff0059000840 (pid 48159) Sep 6 18:09:14 otaku kernel: dev ufs/rootfs Sep 6 18:09:14 otaku kernel: fsync: giving up on dirty Sep 6 18:09:14 otaku kernel: 0xff000552dd20: tag devfs, type VCHR Sep 6 18:09:14 otaku kernel: usecount 1, writecount 0, refcount 1373 mountedhere 0xff0005650a00 Sep 6 18:09:14 otaku kernel: flags () Sep 6 18:09:14 otaku kernel: v_object 0xff000568fbd0 ref 0 pages 5482 Sep 6 18:09:14 otaku kernel: lock type devfs: EXCL by thread 0xff0059000840 (pid 48159) Sep 6 18:09:14 otaku kernel: dev ufs/rootfs Sep 6 18:11:50 otaku sudo: arundel : TTY=pts/6 ; PWD=/usr/home/arundel ; USER=root ; COMMAND=/sbin/mount -u -o snapshot /.snap/snap1 / Sep 6 18:12:33 otaku kernel: fsync: giving up on dirty Sep 6 18:12:34 otaku kernel: 0xff000552dd20: tag devfs, type VCHR Sep 6 18:12:34 otaku kernel: usecount 1, writecount 0, refcount 1383 mountedhere 0xff0005650a00 Sep 6 18:12:34 otaku kernel: flags () Sep 6 18:12:34 otaku kernel: v_object 0xff000568fbd0 ref 0 pages 5514 Sep 6 18:12:34 otaku kernel: lock type devfs: EXCL by thread 0xff006bd6f000 (pid 48194) Sep 6 18:12:34 otaku kernel: dev ufs/rootfs Sep 6 18:12:34 otaku kernel: fsync: giving up on dirty Sep 6 18:12:34 otaku kernel: 0xff000552dd20: tag devfs, type VCHR Sep 6 18:12:34 otaku kernel: usecount 1, writecount 0, refcount 1383 mountedhere 0xff0005650a00 Sep 6 18:12:34 otaku kernel: flags () Sep 6 18:12:34 otaku kernel: v_object 0xff000568fbd0 ref 0 pages 5514 Sep 6 18:12:34 otaku kernel: lock type devfs: EXCL by thread 0xff006bd6f000 (pid 48194) Sep 6 18:12:34 otaku kernel: dev ufs/rootfs after about 4 attempts my system stopped responding. after a reboot both commands succeed without any issues. i'm running HEAD (r212123; amd64). otaku% mount -p /dev/ufs/rootfs / ufs noatime 1 1 devfs /devdevfs rw 0 0 devfs /usr/compat/linux/dev devfs rw 0 0 linprocfs /usr/local/gentoo-stage3/proc linprocfs rw 0 0 linsysfs/usr/local/gentoo-stage3/sys linsysfs rw 0 0 devfs /usr/local/gentoo-stage3/dev devfs rw 0 0 otaku% tunefs -p / tunefs: POSIX.1e ACLs: (-a)disabled tunefs: NFSv4 ACLs: (-N) disabled tunefs: MAC multilabel: (-l) disabled tunefs: soft updates: (-n) enabled tunefs: soft update journaling: (-j) enabled tunefs: gjournal: (-J) disabled tunefs: maximum blocks per file in a cylinder group: (-e) 2048 tunefs: average file size: (-f)16384 tunefs: average number of files in a directory: (-s) 64 tunefs: minimum percentage of free space: (-m) 8% tunefs: optimization preference: (-o) time tunefs: volume label: (-L) rootfs otaku% df -h Filesystem SizeUsed Avail Capacity Mounted on /dev/ufs/rootfs218G186G 14G93%/ devfs 1.0K1.0K 0B 100%/dev devfs 1.0K1.0K 0B 100%/usr/compat/linux/dev linprocfs 4.0K4.0K 0B 100%/usr/local/gentoo-stage3/proc linsysfs 4.0K4.0K 0B 100%/usr/local/gentoo-stage3/sys devfs 1.0K1.0K 0B 100%
Re: patch for topology detection of Intel CPUs
On Mon, Sep 06, 2010 at 04:28:02PM +0300, Andriy Gapon wrote: on 06/09/2010 16:12 Jeremy Chadwick said the following: Great, thanks! I'll be testing this out on two separate systems, both RELENG_8: - Supermicro X7SBA + Intel C2D E8400 (stepping 10) - Supermicro X7SBL-LN2 + Intel C2D E6600 (stepping 6) I'll make sure to provide what the topology looks like before and after. Is CPU-relevant dmesg output sufficient? If you mean something like the below, then yes. Thanks! [...] All done. Good news (I think): there's no difference in the CPU-related topology on either system with your patch, aside from kernel build date. The topologies are still detected correctly. In case you want them: Supermicro X7SBA Intel C2D E8400 (stepping 10) === Copyright (c) 1992-2010 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 8.1-STABLE #0: Mon Sep 6 09:06:52 PDT 2010 r...@icarus.home.lan:/usr/obj/usr/src/sys/X7SBA_RELENG_8_amd64 amd64 Timecounter i8254 frequency 1193182 Hz quality 0 CPU: Intel(R) Core(TM)2 Duo CPU E8400 @ 3.00GHz (2992.52-MHz K8-class CPU) Origin = GenuineIntel Id = 0x1067a Family = 6 Model = 17 Stepping = 10 Features=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE Features2=0x408e3fdSSE3,DTES64,MON,DS_CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,XSAVE AMD Features=0x20100800SYSCALL,NX,LM AMD Features2=0x1LAHF TSC: P-state invariant real memory = 4294967296 (4096 MB) avail memory = 4112097280 (3921 MB) ACPI APIC Table: PTLTD APIC 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 Version 2.0 irqs 0-23 on motherboard ioapic1 Version 2.0 irqs 24-47 on motherboard kbd1 at kbdmux0 ichwd module loaded acpi0: PTLTDXSDT on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) Timecounter ACPI-fast frequency 3579545 Hz quality 1000 acpi_timer0: 24-bit timer at 3.579545MHz port 0x1008-0x100b on acpi0 cpu0: ACPI CPU on acpi0 cpu1: ACPI CPU on acpi0 Supermicro X7SBL-LN2 Intel C2D E6600 (stepping 6) == Copyright (c) 1992-2010 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 8.1-STABLE #1: Mon Sep 6 07:59:49 PDT 2010 r...@gujoja.home.lan:/usr/obj/usr/src/sys/X7SBL_RELENG_8_amd64 amd64 Timecounter i8254 frequency 1193182 Hz quality 0 CPU: Intel(R) Core(TM)2 CPU 6600 @ 2.40GHz (2394.01-MHz K8-class CPU) Origin = GenuineIntel Id = 0x6f6 Family = 6 Model = f Stepping = 6 Features=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE Features2=0xe3bdSSE3,DTES64,MON,DS_CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM AMD Features=0x20100800SYSCALL,NX,LM AMD Features2=0x1LAHF TSC: P-state invariant real memory = 8589934592 (8192 MB) avail memory = 8261648384 (7878 MB) ACPI APIC Table: PTLTD APIC 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 Version 2.0 irqs 0-23 on motherboard kbd1 at kbdmux0 ichwd module loaded acpi0: PTLTDXSDT on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) Timecounter ACPI-fast frequency 3579545 Hz quality 1000 acpi_timer0: 24-bit timer at 3.579545MHz port 0x1008-0x100b on acpi0 cpu0: ACPI CPU on acpi0 cpu1: ACPI CPU on acpi0 All other systems I have are C2D and C2Q-based, but I can't easily test on those given their production roles. If there's a particular Intel processor family/model you're interested in, let me know and I can dig around to see if I have access to one. -- | Jeremy Chadwick j...@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-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: patch for topology detection of Intel CPUs
2010/9/6 Andriy Gapon a...@freebsd.org: on 06/09/2010 19:22 Jeremy Chadwick said the following: On Mon, Sep 06, 2010 at 04:28:02PM +0300, Andriy Gapon wrote: on 06/09/2010 16:12 Jeremy Chadwick said the following: Great, thanks! I'll be testing this out on two separate systems, both RELENG_8: - Supermicro X7SBA + Intel C2D E8400 (stepping 10) - Supermicro X7SBL-LN2 + Intel C2D E6600 (stepping 6) I'll make sure to provide what the topology looks like before and after. Is CPU-relevant dmesg output sufficient? If you mean something like the below, then yes. Thanks! [...] All done. Good news (I think): there's no difference in the CPU-related topology on either system with your patch, aside from kernel build date. The topologies are still detected correctly. In case you want them: Thanks a lot for the test! Here is mine : no difference before and after the patch : FreeBSD 8.1-STABLE #0 r212258M: Mon Sep 6 18:36:00 CEST 2010 r...@q.gid0.org:/usr/obj/usr/src/sys/QUAD amd64 Timecounter i8254 frequency 1193182 Hz quality 0 CPU: Intel(R) Core(TM)2 Quad CPU Q9450 @ 2.66GHz (2999.87-MHz K8-class CPU) Origin = GenuineIntel Id = 0x10677 Family = 6 Model = 17 Stepping = 7 Features=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE Features2=0x8e3fdSSE3,DTES64,MON,DS_CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1 AMD Features=0x20100800SYSCALL,NX,LM AMD Features2=0x1LAHF TSC: P-state invariant real memory = 2147483648 (2048 MB) avail memory = 2029350912 (1935 MB) ACPI APIC Table: A_M_I_ OEMAPIC FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs FreeBSD/SMP: 1 package(s) x 4 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 cpu2 (AP): APIC ID: 2 cpu3 (AP): APIC ID: 3 The only thing I noticed is this, after the patch : ada1 at ahcich1 bus 0 scbus1 target 0 lun 0 ada1: SAMSUNG HD161HJ JF100-19 ATA-7 SATA 2.x device ada1: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada1: Command Queueing enabled ada1: 152627MB (312581808 512 byte sectors: 16H 63S/T 16383C) SMP: AP CPU #1 Launched!cd0 at ahcich2 bus 0 scbus2 target 0 lun 0 cd0: LITE-ON DVDRW LH-20A1S 9L08 Removable CD-ROM SCSI-0 device cd0: 150.000MB/s transfers (SATA 1.x, UDMA5, ATAPI 12bytes, PIO 8192bytes) cd0: Attempt to query device size failed: NOT READY, Medium not present SMP: AP CPU #3 Launched! SMP: AP CPU #2 Launched! Trying to mount root from zfs:tank/freebsd Before the patch, all the SMP: AP CPU #X Launched! were correctly displayed, with carriage returns. Yes, I use options PRINTF_BUFR_SIZE=128. And I don't know if that's related to the patch. Cheers, Olivier [test results snipped] All other systems I have are C2D and C2Q-based, but I can't easily test on those given their production roles. If there's a particular Intel processor family/model you're interested in, let me know and I can dig around to see if I have access to one. No particular models in mind. If you have systems with more complex topologies, like multiple physical packages or HTT enabled, I will be interested in seeing test results for those. Thanks again. -- Andriy Gapon ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org -- Olivier Smedts _ ASCII ribbon campaign ( ) e-mail: oliv...@gid0.org - against HTML email vCards X www: http://www.gid0.org - against proprietary attachments / \ Il y a seulement 10 sortes de gens dans le monde : ceux qui comprennent le binaire, et ceux qui ne le comprennent pas. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
RFC: pefs - stacked cryptographic filesystem
Hello, I would like to ask for feedback on a kernel level stacked cryptographic filesystem. It has started as Summer Of Code'2009 project and matured a lot since then. I've recently added support for sparse files and switched to XTS encryption mode. I've been using it to encrypt my home directory for almost a year already, and use fsx, dbench and blogbench for testing. So it should be fairly stable. Tested on top of ZFS, UFS and tmpfs on amd64 and i386; both 9-CURRENT and 8-STABLE supported. Please email me separately if you're willing to help testing on big endian machine, XTS code doesn't look endian correct. At this point all of the project goals complete and I'd like it to get wider coverage in terms of tests and reviews and hope to see it commited to HEAD soon. Installation instructions: 1a. Clone git repository: # git clone git://github.com/glk/pefs.git pefs # cd pefs 1b. Or download latest snapshot from github: http://github.com/glk/pefs/archives/master 2. Build and install: # make obj all # make install 3. Mount pefs filesystem: # pefs mount ~/Private ~/Private 4. Enter passphrase: # pefs addkey ~/Private 5. Test it and report back. There is also a man page available. 6. Example how to save your key in keychain database. pefs has to be mounted and key specified to make fs writable, create keychain with single entry (keychain -Z option): # pefs addchain -Z ~/Private Don't encrypt .pefs.db: # mv ~/Private/.pefs.db /tmp # umount ~/Private # mv /tmp/.pefs.db ~/Private # pefs mount ~/Private ~/Private Use -c option to verify key is in database # pefs addkey -c ~/Private 7. You can setup pam_pefs (not compiled by default) to add key to home directory and authenticate against keychain database on login, e.g. by adding the following line to /etc/pam.d/system before pam_unix.so: authsufficient pam_pefs.so try_first_pass The following is a list of its most important features: * Kernel level file system, no user level daemons needed. Transparently runs on top of existing file systems. * Random per file tweak value used for encryption, which guaranties different cipher texts for the same encrypted files. * Saves metadata only in encrypted file name, but not in file itself. * Supports arbitrary number of keys per file system, default directory key, mixing files encrypted with different keys in same directory. * Allows defining key chains, can be used to add/delete several keys by specifying only master key. * Uses modern cryptographic algorithms: AES and Camellia in XTS mode, PKCS#5v2 and HKDF for key generation. Github repository: http://github.com/glk/pefs More details on my blog: http://glebkurtsou.blogspot.com/search/label/pefs Thanks, Gleb. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Using ipfw table names instead of numbers.
Em 5/9/2010 12:53, Luigi Rizzo escreveu: On Sat, Sep 04, 2010 at 10:58:44AM -0300, Anderson Eduardo wrote: Hello developers, I use the ipfw firewall with many tables and, I would like of able to use it with name/alias instead of just numbers. E.g: lab# ipfw table 1 name lanetwork Setting table 1 to lanetwork lab# ipfw table lanetwork add 192.168.0.0/24 lab# ipfw table lanetwork list 192.168.0.0/24 0 lab# I think a good idea a patch to do that. if you have a patch feel free to post it. the main issue is that internally, for efficiency reason, the name must be translated to a number anyways, so before implementing it one must decide where the name-number translation table is stored and how it is managed The same applies to any name vs. number issue in ipfw/dummynet Service, protocol and host names solve these issues because there is a well defined place for the translation table. But, for instance, hostname mappings are static (translated at rule insertion time) whereas one might want a more dynamic behaviour (e.g. refresh whenever the DNS response expires). cheers luigi Luigi, I did some changes just in user-land, I didn't touch in kernel. I will check if I can do that, I'm not a good developer. Thanks. -- Anderson Eduardo Diretor Geral Tel.: +55 (71) 3641-6450 Secover - Serviços em Tecnologia e Segurança da Informação http://www.secover.com.br ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: ZFS v28 is ready for wider testing.
To avoid user and developer confusion, my patch was just a chain of pjd's patch + pjd's atomic.h fix + my v19 boot patch. I have removed (= split) the chained patch in my posting and altered my blog article with updated build instructions that actually just summarize what has been written on this list. Thanks for understanding! Dňa 6. 9. 2010 13:50, Martin Matuska wrote / napísal(a): Hi everyone, I have put together a slightly improved patch of Pawel's that compiles correctly and supports booting from ZFS v19 pools. You can download the patch here: http://people.freebsd.org/~mm/patches/zfs/head-zfs-v28-20100831.patch For users who don't want to compile I have created a mfsBSD ISO image with a zfs-only install of 9-CURRENT-amd64: http://mfsbsd.vx.sk/iso/mfsbsd-se-head-zfsv28-amd64.iso You can read more about all of this here: http://blog.vx.sk/archives/9-Help-testing-ZFS-v28-in-FreeBSD.html More information about ZFS pool and filesystem versions: http://blog.vx.sk/archives/4-ZFS-pool-and-filesystem-versions.html Thanks to everybody participating in testing, mm ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: RFC: pefs - stacked cryptographic filesystem
Sorry for replying to myself, I've realized I put wrong download link: http://github.com/downloads/glk/pefs/pefs-2010-09-06.tar.gz On (06/09/2010 21:38), Gleb Kurtsou wrote: Hello, I would like to ask for feedback on a kernel level stacked cryptographic filesystem. It has started as Summer Of Code'2009 project and matured a lot since then. I've recently added support for sparse files and switched to XTS encryption mode. I've been using it to encrypt my home directory for almost a year already, and use fsx, dbench and blogbench for testing. So it should be fairly stable. Tested on top of ZFS, UFS and tmpfs on amd64 and i386; both 9-CURRENT and 8-STABLE supported. Please email me separately if you're willing to help testing on big endian machine, XTS code doesn't look endian correct. At this point all of the project goals complete and I'd like it to get wider coverage in terms of tests and reviews and hope to see it commited to HEAD soon. Installation instructions: 1a. Clone git repository: # git clone git://github.com/glk/pefs.git pefs # cd pefs 1b. Or download latest snapshot from github: http://github.com/glk/pefs/archives/master Or use direct download link: http://github.com/downloads/glk/pefs/pefs-2010-09-06.tar.gz 2. Build and install: # make obj all # make install 3. Mount pefs filesystem: # pefs mount ~/Private ~/Private 4. Enter passphrase: # pefs addkey ~/Private 5. Test it and report back. There is also a man page available. 6. Example how to save your key in keychain database. pefs has to be mounted and key specified to make fs writable, create keychain with single entry (keychain -Z option): # pefs addchain -Z ~/Private Don't encrypt .pefs.db: # mv ~/Private/.pefs.db /tmp # umount ~/Private # mv /tmp/.pefs.db ~/Private # pefs mount ~/Private ~/Private Use -c option to verify key is in database # pefs addkey -c ~/Private 7. You can setup pam_pefs (not compiled by default) to add key to home directory and authenticate against keychain database on login, e.g. by adding the following line to /etc/pam.d/system before pam_unix.so: auth sufficient pam_pefs.so try_first_pass The following is a list of its most important features: * Kernel level file system, no user level daemons needed. Transparently runs on top of existing file systems. * Random per file tweak value used for encryption, which guaranties different cipher texts for the same encrypted files. * Saves metadata only in encrypted file name, but not in file itself. * Supports arbitrary number of keys per file system, default directory key, mixing files encrypted with different keys in same directory. * Allows defining key chains, can be used to add/delete several keys by specifying only master key. * Uses modern cryptographic algorithms: AES and Camellia in XTS mode, PKCS#5v2 and HKDF for key generation. Github repository: http://github.com/glk/pefs More details on my blog: http://glebkurtsou.blogspot.com/search/label/pefs Thanks, Gleb. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
[head tinderbox] failure on ia64/ia64
TB --- 2010-09-07 01:39:25 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-09-07 01:39:25 - starting HEAD tinderbox run for ia64/ia64 TB --- 2010-09-07 01:39:25 - cleaning the object tree TB --- 2010-09-07 01:40:08 - cvsupping the source tree TB --- 2010-09-07 01:40:08 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup18.freebsd.org /tinderbox/HEAD/ia64/ia64/supfile TB --- 2010-09-07 01:40:51 - building world TB --- 2010-09-07 01:40:51 - MAKEOBJDIRPREFIX=/obj TB --- 2010-09-07 01:40:51 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-09-07 01:40:51 - TARGET=ia64 TB --- 2010-09-07 01:40:51 - TARGET_ARCH=ia64 TB --- 2010-09-07 01:40:51 - TZ=UTC TB --- 2010-09-07 01:40:51 - __MAKE_CONF=/dev/null TB --- 2010-09-07 01:40:51 - cd /src TB --- 2010-09-07 01:40:51 - /usr/bin/make -B buildworld World build started on Tue Sep 7 01:40:51 UTC 2010 Rebuilding the temporary build tree stage 1.1: legacy release compatibility shims stage 1.2: bootstrap tools stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3: cross tools stage 4.1: building includes stage 4.2: building libraries stage 4.3: make dependencies stage 4.4: building everything World build completed on Tue Sep 7 03:09:57 UTC 2010 TB --- 2010-09-07 03:09:57 - generating LINT kernel config TB --- 2010-09-07 03:09:57 - cd /src/sys/ia64/conf TB --- 2010-09-07 03:09:57 - /usr/bin/make -B LINT TB --- 2010-09-07 03:09:57 - building LINT kernel TB --- 2010-09-07 03:09:57 - MAKEOBJDIRPREFIX=/obj TB --- 2010-09-07 03:09:57 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-09-07 03:09:57 - TARGET=ia64 TB --- 2010-09-07 03:09:57 - TARGET_ARCH=ia64 TB --- 2010-09-07 03:09:57 - TZ=UTC TB --- 2010-09-07 03:09:57 - __MAKE_CONF=/dev/null TB --- 2010-09-07 03:09:57 - cd /src TB --- 2010-09-07 03:09:57 - /usr/bin/make -B buildkernel KERNCONF=LINT Kernel build for LINT started on Tue Sep 7 03:09:57 UTC 2010 stage 1: configuring the kernel stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3.1: making dependencies stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/vm/vm_kern.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/vm/vm_map.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/vm/vm_meter.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/vm/vm_mmap.c /src/sys/vm/vm_mmap.c: In function 'munmap': /src/sys/vm/vm_mmap.c:601: error: 'uintptr' undeclared (first use in this function) /src/sys/vm/vm_mmap.c:601: error: (Each undeclared identifier is reported only once /src/sys/vm/vm_mmap.c:601: error: for each function it appears in.) *** Error code 1 Stop in /obj/ia64.ia64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-09-07 03:28:16 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-09-07 03:28:16 - ERROR: failed to
[head tinderbox] failure on powerpc/powerpc
TB --- 2010-09-07 03:28:16 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-09-07 03:28:16 - starting HEAD tinderbox run for powerpc/powerpc TB --- 2010-09-07 03:28:16 - cleaning the object tree TB --- 2010-09-07 03:29:01 - cvsupping the source tree TB --- 2010-09-07 03:29:01 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup18.freebsd.org /tinderbox/HEAD/powerpc/powerpc/supfile TB --- 2010-09-07 03:33:41 - building world TB --- 2010-09-07 03:33:41 - MAKEOBJDIRPREFIX=/obj TB --- 2010-09-07 03:33:41 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-09-07 03:33:41 - TARGET=powerpc TB --- 2010-09-07 03:33:41 - TARGET_ARCH=powerpc TB --- 2010-09-07 03:33:41 - TZ=UTC TB --- 2010-09-07 03:33:41 - __MAKE_CONF=/dev/null TB --- 2010-09-07 03:33:41 - cd /src TB --- 2010-09-07 03:33:41 - /usr/bin/make -B buildworld World build started on Tue Sep 7 03:33:42 UTC 2010 Rebuilding the temporary build tree stage 1.1: legacy release compatibility shims stage 1.2: bootstrap tools stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3: cross tools stage 4.1: building includes stage 4.2: building libraries stage 4.3: make dependencies stage 4.4: building everything World build completed on Tue Sep 7 05:19:15 UTC 2010 TB --- 2010-09-07 05:19:15 - generating LINT kernel config TB --- 2010-09-07 05:19:15 - cd /src/sys/powerpc/conf TB --- 2010-09-07 05:19:15 - /usr/bin/make -B LINT TB --- 2010-09-07 05:19:15 - building LINT kernel TB --- 2010-09-07 05:19:15 - MAKEOBJDIRPREFIX=/obj TB --- 2010-09-07 05:19:15 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-09-07 05:19:15 - TARGET=powerpc TB --- 2010-09-07 05:19:15 - TARGET_ARCH=powerpc TB --- 2010-09-07 05:19:15 - TZ=UTC TB --- 2010-09-07 05:19:15 - __MAKE_CONF=/dev/null TB --- 2010-09-07 05:19:15 - cd /src TB --- 2010-09-07 05:19:15 - /usr/bin/make -B buildkernel KERNCONF=LINT Kernel build for LINT started on Tue Sep 7 05:19:15 UTC 2010 stage 1: configuring the kernel stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3.1: making dependencies stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/vm/vm_kern.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/vm/vm_map.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/vm/vm_meter.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/vm/vm_mmap.c /src/sys/vm/vm_mmap.c: In function 'munmap': /src/sys/vm/vm_mmap.c:601: error: 'uintptr' undeclared (first use in this function) /src/sys/vm/vm_mmap.c:601: error: (Each undeclared identifier is reported only once /src/sys/vm/vm_mmap.c:601: error: for each function it appears in.) *** Error code 1 Stop in /obj/powerpc.powerpc/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-09-07
