Re: Incorrect NAT translation for sip traffic ?
Well my solution was to switch from OpenBSD to Debian. Drastic maybe, but at least it actually works since then. I'm still trying to figure out why it happened thou, but no success so far. On 2011-07-29 00:14, Stuart Henderson wrote: Whatever this is (and I don't have the slightest clue what that might be), I noticed it on a 4.9 box the other day, upgraded to -current, still see it there. $ sysctl kern.version kern.version=OpenBSD 5.0-beta (GENERIC) #22: Tue Jul 26 06:24:05 MDT 2011 dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC $ head -1 messages;date;grep 187.170.255.239 message Jul 28 19:00:01 bath-gw newsyslog[19970]: logfile turned over Thu Jul 28 23:07:26 BST 2011 Jul 28 19:46:36 bath-gw /bsd: pf: state key linking mismatch! dir=OUT, if=em3, stored af=2, a0: 85.158.44.147:2048, a1: 192.168.0.253:5060, proto=17, found af=2, a0: 99.160.113.24:28952, a1: 187.170.255.239:25504, proto=17 Jul 28 19:54:34 bath-gw /bsd: pf: state key linking mismatch! dir=OUT, if=em3, stored af=2, a0: 85.158.44.147:2048, a1: 192.168.0.253:5060, proto=17, found af=2, a0: 99.160.113.24:28952, a1: 187.170.255.239:25504, proto=17 Jul 28 19:56:36 bath-gw /bsd: pf: state key linking mismatch! dir=OUT, if=em3, stored af=2, a0: 85.158.44.147:2048, a1: 192.168.0.253:5060, proto=17, found af=2, a0: 99.160.113.24:28952, a1: 187.170.255.239:25504, proto=17 Jul 28 20:19:33 bath-gw /bsd: pf: state key linking mismatch! dir=OUT, if=em3, stored af=2, a0: 85.158.44.147:2048, a1: 192.168.0.253:5060, proto=17, found af=2, a0: 99.160.113.24:28952, a1: 187.170.255.239:25504, proto=17 Jul 28 20:21:36 bath-gw /bsd: pf: state key linking mismatch! dir=OUT, if=em3, stored af=2, a0: 85.158.44.147:2048, a1: 192.168.0.253:5060, proto=17, found af=2, a0: 99.160.113.24:28952, a1: 187.170.255.239:25504, proto=17 Jul 28 21:48:33 bath-gw /bsd: pf: state key linking mismatch! dir=OUT, if=trunk0, stored af=2, a0: 85.158.44.147:2048, a1: 192.168.0.253:5060, proto=17, found af=2, a0: 192.168.0.253:5060, a1: 187.170.255.239:2048, proto=17 Jul 28 22:40:35 bath-gw /bsd: pf: state key linking mismatch! dir=OUT, if=trunk0, stored af=2, a0: 85.158.44.147:2048, a1: 192.168.0.253:5060, proto=17, found af=2, a0: 192.168.0.253:5060, a1: 187.170.255.239:2048, proto=17 Jul 28 22:57:35 bath-gw /bsd: pf: state key linking mismatch! dir=OUT, if=trunk0, stored af=2, a0: 85.158.44.147:2048, a1: 192.168.0.253:5060, proto=17, found af=2, a0: 192.168.0.253:5060, a1: 187.170.255.239:2048, proto=17 bath-gw is rdr'ing traffic from 85.158.44.147, a snom 360 on an external network, to 192.168.0.253 which is an asterisk box. 99.160.113.24 is nothing to do with me, 187.170.255.239 (the same address Magnus sees) is also nothing to do with me. On 2011-06-23, Magnus Rixtorpmag...@tokra.org wrote: Lets get some standard stuff out of the way first. # uname -a OpenBSD pbxfw 4.9 GENERIC#671 i386 # dmesg OpenBSD 4.9 (GENERIC) #671: Wed Mar 2 07:09:00 MST 2011 dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC cpu0: Intel(R) Pentium(R) 4 CPU 3.00GHz (GenuineIntel 686-class) 3 GHz cpu0: FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,SSE3,MWAIT,DS-CPL,CNXT-ID,xTPR real mem = 2137120768 (2038MB) avail mem = 2092023808 (1995MB) mainbus0 at root bios0 at mainbus0: AT/286+ BIOS, date 02/09/05, BIOS32 rev. 0 @ 0xffe90, SMBIOS rev. 2.3 @ 0xf0450 (74 entries) bios0: vendor Dell Inc. version A04 date 02/09/2005 bios0: Dell Inc. OptiPlex GX280 acpi0 at bios0: rev 0 acpi0: sleep states S0 S1 S3 S4 S5 acpi0: tables DSDT FACP SSDT APIC BOOT ASF! MCFG HPET acpi0: wakeup devices VBTN(S4) PCI0(S5) PCI1(S5) PCI2(S5) PCI3(S5) PCI4(S5) MOU_(S3) USB0(S3) USB1(S3) USB2(S3) USB3(S3) acpitimer0 at acpi0: 3579545 Hz, 24 bits acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: apic clock running at 199MHz ioapic0 at mainbus0: apid 8 pa 0xfec0, version 20, 24 pins ioapic0: misconfigured as apic 0, remapped to apid 8 acpimcfg0 at acpi0 addr 0xe000, bus 0-255 acpihpet0 at acpi0: 14318179 Hz acpiprt0 at acpi0: bus 4 (PCI1) acpiprt1 at acpi0: bus 2 (PCI2) acpiprt2 at acpi0: bus 3 (PCI3) acpiprt3 at acpi0: bus 1 (PCI4) acpiprt4 at acpi0: bus 0 (PCI0) acpicpu0 at acpi0: C3 acpibtn0 at acpi0: VBTN bios0: ROM list: 0xc/0xa800! 0xca800/0x1800! pci0 at mainbus0 bus 0: configuration mode 1 (bios) pchb0 at pci0 dev 0 function 0 Intel 82915G Host rev 0x04 ppb0 at pci0 dev 1 function 0 Intel 82915G PCIE rev 0x04: apic 8 int 16 (irq 11) pci1 at ppb0 bus 1 vga1 at pci0 dev 2 function 0 Intel 82915G Video rev 0x04 wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation) wsdisplay0: screen 1-5 added (80x25, vt100 emulation) intagp0 at vga1 agp0 at intagp0: aperture at 0xc000, size 0x1000 inteldrm0 at vga1: apic 8 int 16 (irq 11) drm0 at inteldrm0 Intel 82915G Video rev 0x04 at pci0 dev 2 function 1 not configured ppb1 at pci0 dev 28
Building kernel outside /usr/src/sys -- from the FAQ
Hi, http://www.openbsd.org/faq/faq5.html#BldKernel has a section Variation on above process: Read-only source tree, which talks about building a kernel outside src/. Interestingly, when I do a GENERIC.MP build, by following these steps, the name displayed via config is that of the directory in which this kernel has been built. Eg. # cd /home/foo/bar/testbuild # cp /usr/src/sys/arch/i386/conf/GENERIC.MP . # config -s /usr/src/sys -b . GENERIC.MP # make clean make depend make # make install config -e displays the kernel string as: OpenBSD 5.0-beta (testbuild) #2: Fri Jul 29 12:50:00 IST 2011 root@zimbu:/home/foo/bar/testbuild This may confuse, especially when a dmesg is required, as it loses the type of kernel built - GENERIC or GENERIC.MP. Can this be clarified in the FAQ, or did I miss something? -Amarendra
Re: Building kernel outside /usr/src/sys -- from the FAQ
On Fri, Jul 29, 2011 at 10:43:52AM +0200, David Vasek wrote: On Fri, 29 Jul 2011, Amarendra Godbole wrote: Hi, http://www.openbsd.org/faq/faq5.html#BldKernel has a section Variation on above process: Read-only source tree, which talks about building a kernel outside src/. Interestingly, when I do a GENERIC.MP build, by following these steps, the name displayed via config is that of the directory in which this kernel has been built. Eg. # cd /home/foo/bar/testbuild # cp /usr/src/sys/arch/i386/conf/GENERIC.MP . # config -s /usr/src/sys -b . GENERIC.MP # make clean make depend make # make install config -e displays the kernel string as: OpenBSD 5.0-beta (testbuild) #2: Fri Jul 29 12:50:00 IST 2011 root@zimbu:/home/foo/bar/testbuild This may confuse, especially when a dmesg is required, as it loses the type of kernel built - GENERIC or GENERIC.MP. It loses the arch too. It is not easy to distinguish between i386 and amd64 then. Regards, David can't you actually do: # mkdir -p /home/foo/bar/testbuild/`uname -m`/GENERIC.MP # cd /home/foo/bar/testbuild/`uname -m`/GENERIC.MP which would keep the arch and kernel name in the build path just as with a build from the regular path ? Gilles -- Gilles Chehade http://u.poolp.org/~gilles/
[OT] io event triggered file system synchronisation
hi there, sorry for the offtopic but there are probably many knowledgeable admins on this list as well. i am looking for a solution that keeps monitoring file system io for all stuff under a certain path and whenever files change/get added/removed it synchronises these changes with multiple remote locations. basically sql replication for file system :] anybody using something like this? -f -- i may be wrong, but i'm never in doubt!
Re: Building kernel outside /usr/src/sys -- from the FAQ
On Fri, 29 Jul 2011, Gilles Chehade wrote: On Fri, Jul 29, 2011 at 10:43:52AM +0200, David Vasek wrote: On Fri, 29 Jul 2011, Amarendra Godbole wrote: Hi, http://www.openbsd.org/faq/faq5.html#BldKernel has a section Variation on above process: Read-only source tree, which talks about building a kernel outside src/. Interestingly, when I do a GENERIC.MP build, by following these steps, the name displayed via config is that of the directory in which this kernel has been built. Eg. # cd /home/foo/bar/testbuild # cp /usr/src/sys/arch/i386/conf/GENERIC.MP . # config -s /usr/src/sys -b . GENERIC.MP # make clean make depend make # make install config -e displays the kernel string as: OpenBSD 5.0-beta (testbuild) #2: Fri Jul 29 12:50:00 IST 2011 root@zimbu:/home/foo/bar/testbuild This may confuse, especially when a dmesg is required, as it loses the type of kernel built - GENERIC or GENERIC.MP. It loses the arch too. It is not easy to distinguish between i386 and amd64 then. Regards, David can't you actually do: # mkdir -p /home/foo/bar/testbuild/`uname -m`/GENERIC.MP # cd /home/foo/bar/testbuild/`uname -m`/GENERIC.MP which would keep the arch and kernel name in the build path just as with a build from the regular path ? It is what I actually do. I am not complaining. But it is sometimes hard to read dmesgs that come to misc@ from other people right. Regards, David
Re: High interrupt load on 5.0-current
A new day and a new suspend/resume cycle: my laptop has a high interrupt load again. top output yesterday (low interrupt load): 54 processes: 46 idle, 6 stopped, 2 on processor CPU0 states: 1.0% user, 0.0% nice, 3.0% system, 0.0% interrupt, 96.0% idle CPU1 states: 0.0% user, 0.0% nice, 5.0% system, 0.0% interrupt, 95.0% idle Memory: Real: 640M/1049M act/tot Free: 920M Cache: 302M Swap: 0K/2293M systat output yesterday (sorry for the mess, but gmail screwed up the layout and I am in a hurry): 2 usersLoad 2.78 3.53 3.65 Thu Jul 28 07:15:29 2011 memory totals (in KB)PAGING SWAPPING Interrupts real virtual free in out in out 509 total Active 654236654236 924400 ops200 clock All 1092268 1092268 3272108 pages 88 ipi acpi0 Proc:r d s wCsw Trp Sys Int Sof Flt12 forks 60 inteldrm 2 17 226 2661 5636 222 136 2731 fkppw 55 azalia0 fksvm 10 athn0 0.0%Int 3.0%Sys 1.0%Usr 0.0%Nic 96.0%Idle pwait uhci2 ||||||||||| relck ehci0 =rlkok 10 ahci0 noram pckbc0 Namei Sys-cacheProc-cacheNo-cache 622 ndcpy 86 pckbc0 Calls hits%hits %miss % 111 fltcp 360 357 99 2 1 642 zfod 206 cow Disks sd0 16805 fmin seeks 22406 ftarg xfers10 itarg speed 234K 10480 wired sec 0.0 pdfre pdscn pzidle 154 kmapent top output now (high interrupt load): 58 processes: 51 idle, 6 stopped, 1 on processor CPU0: 3.0% user, 0.0% nice, 4.0% system, 92.1% interrupt, 1.0% idle CPU1: 12.9% user, 0.0% nice, 48.5% system, 0.0% interrupt, 38.6% idle Memory: Real: 597M/1392M act/tot Free: 577M Cache: 665M Swap: 0K/2293M systat output now: 3 usersLoad 3.03 3.19 3.30 Fri Jul 29 07:14:10 2011 memory totals (in KB)PAGING SWAPPING Interrupts real virtual free in out in out 483 total Active 612912612912 591980 ops202 clock All 1424688 1424688 2939688 pages 88 ipi acpi0 Proc:r d s wCsw Trp Sys Int Sof Flt13 forks inteldrm 2 16 189 3598 7262 36877 181 3643 fkppw 138 azalia0 fksvm 24 athn0 47.0%Int 11.0%Sys 9.0%Usr 0.0%Nic 33.0%Idle pwait uhci2 ||||||||||| relck ehci0 =rlkok 1 ahci0 noram pckbc0 Namei Sys-cacheProc-cacheNo-cache 794 ndcpy 30 pckbc0 Calls hits%hits %miss % 139 fltcp 406 406 100 983 zfod 248 cow Disks sd0 16805 fmin seeks 22406 ftarg xfers 1 itarg speed 16K 6291 wired sec 0.0 pdfre pdscn pzidle 200 kmapent Comparing these two outputs I can see that azalia interrupt counts are high, but this is only seen sporadically. Most of the time the number is around 60/70, which I guess is normal. Also the total number of interrupts isn't that different between the two cases. What I do see, is that the sluggishness is a lot less when I switch to a desktop with only xterms in it, and it becomes more when I am switching to firefox. Any ideas? On Thu, Jul 28, 2011 at 10:54 PM, Chris Cappuccio ch...@nmedia.net wrote: run 'systat vm 1' or vmstat -i and see who the big consumer is Leroy van Engelen [leroy.vanenge...@gmail.com] wrote: Hi, This week I upgraded the OpenBSD install on my laptop to 5.0-current, and I noticed some applications running very
amd64 snapshot kqemu hangs
Hi list,
I've just tried snapshot version (5.0beta - 27 Jul). I wanted to test bigmem
with qemu and kqemu.
When I tried to load the kqemu module (pkg_add
ftp://mirror/pub/OpenBSD/snapshots/packages/amd64/) my system freezes:
kqemu: kqemu version 0x000103000 loaded, max locked mem=2026212kB
uvm_fault(0xfe816acf0380, 0x0, 0, 1) - e
kernel: page fault trap, code=0
Stopped at namei+0x1c: movq 0x20(%r14),%rax
ddb{1}
I set securitylevel to -1
Is this a bug or did I miss something?
Need dmesg?
Greets
Elmar
Re: amd64 snapshot kqemu hangs
On Fri, Jul 29, 2011 at 11:58 AM, [BG-Consulting] Elmar Bschorer
elmar.bscho...@bugconsulting.de wrote:
Hi list,
I've just tried snapshot version (5.0beta - 27 Jul). I wanted to test bigmem
with qemu and kqemu.
When I tried to load the kqemu module (pkg_add
ftp://mirror/pub/OpenBSD/snapshots/packages/amd64/) my system freezes:
kqemu: kqemu version 0x000103000 loaded, max locked mem=2026212kB
uvm_fault(0xfe816acf0380, 0x0, 0, 1) - e
kernel: page fault trap, code=0
Stopped at namei+0x1c: movq 0x20(%r14),%rax
ddb{1}
I set securitylevel to -1
Is this a bug or did I miss something?
Need dmesg?
It should be better to not lure people into using kqemu: it's buggy
and unmaintained
cheers,
David
Re: Incorrect NAT translation for sip traffic ?
Stuart Henderson s...@spacehopper.org wrote: Whatever this is (and I don't have the slightest clue what that might be), I noticed it on a 4.9 box the other day, upgraded to -current, still see it there. Jul 28 19:46:36 bath-gw /bsd: pf: state key linking mismatch! dir=OUT, if=em3, stored af=2, a0: 85.158.44.147:2048, a1: 192.168.0.253:5060, proto=17, found af=2, a0: 99.160.113.24:28952, a1: 187.170.255.239:25504, proto=17 I used to get such errors for UDP packets when running BitTorrent with DHT. This also involved NAT and redirecting of traffic to an internal host. I think it persisted for several releases. Henning may have some vague memory that I complained to him about it. I stopped using DHT, so I don't know if it would still happen. -- Christian naddy Weisgerber na...@mips.inka.de
Re: very slow writes with softdep enabled on mpi(4)
On Mon, Jul 25, 2011 at 5:54 PM, Mattieu Baptiste mattie...@gmail.com wrote: Hi all, It's really weird. I see very slow writes when softdep is enabled. Write caches seem to be enabled on disks. Utilities like bonnie++ confirm that writes are very slow with softdep enabled (although it helps with lots of file creations). This happens whether I use native disks or RAID 1 volume behind mpi(4) (on which the controller's cache is also enabled). After digging around this problem with help from Pedro, I noticed that a 4.9-release kernel works ok, whereas a 5.0-beta does not. So I tried to identify which commit was responsible and found out this one is responsible of *very* slow writes with softdep (I only have this bug on sparc64): http://marc.info/?l=openbsd-cvsm=130730313107059w=2 I can add that this bug is just affecting softdep: - dd'ing to the raw device is fast, - dd'ing to the file system mounted sync is very fast, - dd'ing to the file system mounted async is very fast, - dd'ing to the file system mounted with softdep is very slow. I can also add that changing a working kernel to bufcachepercent =42 via sysctl is ok too. With softdep: # mount -o softdep /dev/sd2a /mnt # dd if=/dev/zero of=/mnt/test # dd if=/dev/zero of=/mnt/test.dump bs=4k count=1 1+0 records in 1+0 records out 4096 bytes transferred in 16.060 secs (2550321 bytes/sec) # rm /mnt/test.dump # dd if=/dev/zero of=/mnt/test.dump bs=1m count=100 100+0 records in 100+0 records out 104857600 bytes transferred in 3.483 secs (30101713 bytes/sec) Without softdep: # mount /dev/sd2a /mnt # dd if=/dev/zero of=/mnt/test.dump bs=4k count=1 1+0 records in 1+0 records out 4096 bytes transferred in 0.330 secs (123880958 bytes/sec) # rm /mnt/test.dump # dd if=/dev/zero of=/mnt/test.dump bs=1m count=100 100+0 records in 100+0 records out 104857600 bytes transferred in 0.932 secs (112438785 bytes/sec) # scsi -f /dev/rsd2c -m8 IC: 1 ABPF: 0 CAP: 0 DISC: 1 SIZE: 0 WCE: 1 MF: 0 RCD: 0 Demand Retention Priority: 0 Write Retention Priority: 0 Disable Pre-fetch Transfer Length: 65535 Minimum Pre-fetch: 0 Maximum Pre-fetch: 65535 Maximum Pre-fetch Ceiling: 65535 FSW: 0 LBCSS: 0 DRA: 0 Vendor-specific: 0 NV_DIS: 0 Number of Cache Segments: 2 Cache Segment Size: 0 dmesg: console is /pci@1e,60/isa@7/serial@0,3f8 Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. Copyright (c) 1995-2011 OpenBSD. All rights reserved. http://www.OpenBSD.org OpenBSD 5.0-beta (GENERIC.MP) #3: Tue Jul 19 18:20:17 CEST 2011 r...@cognac.brimbelle.org:/usr/src/sys/arch/sparc64/compile/GENERIC.MP real mem = 17179869184 (16384MB) avail mem = 16901693440 (16118MB) mainbus0 at root: Sun Fire V440 cpu0 at mainbus0: SUNW,UltraSPARC-IIIi (rev 2.4) @ 1281 MHz cpu0: physical 32K instruction (32 b/l), 64K data (32 b/l), 1024K external (64 b/l) cpu1 at mainbus0: SUNW,UltraSPARC-IIIi (rev 2.4) @ 1281 MHz cpu1: physical 32K instruction (32 b/l), 64K data (32 b/l), 1024K external (64 b/l) cpu2 at mainbus0: SUNW,UltraSPARC-IIIi (rev 2.4) @ 1281 MHz cpu2: physical 32K instruction (32 b/l), 64K data (32 b/l), 1024K external (64 b/l) cpu3 at mainbus0: SUNW,UltraSPARC-IIIi (rev 2.4) @ 1281 MHz cpu3: physical 32K instruction (32 b/l), 64K data (32 b/l), 1024K external (64 b/l) memory-controller at mainbus0 not configured memory-controller at mainbus0 not configured memory-controller at mainbus0 not configured memory-controller at mainbus0 not configured schizo0 at mainbus0: Tomatillo, version 4, ign 700, bus A 0 to 0 schizo0: dvma map c000-dfff pci0 at schizo0 cas0 at pci0 dev 2 function 0 Sun Cassini rev 0x20: ivec 0x718, address 00:03:ba:a4:90:53 brgphy0 at cas0 phy 1: BCM5421 10/100/1000baseT PHY, rev. 1 ppm at mainbus0 not configured schizo1 at mainbus0: Tomatillo, version 4, ign 740, bus B 0 to 1 schizo1: dvma map c000-dfff pci1 at schizo1 ppb0 at pci1 dev 2 function 0 Intel 21154AE/BE PCI-PCI rev 0x00 pci2 at ppb0 bus 1 cas1 at pci2 dev 0 function 0 Sun Cassini rev 0x20: ivec 0x740, address 00:03:ba:93:1c:a1 brgphy1 at cas1 phy 1: BCM5401 10/100/1000baseT PHY, rev. 3 schizo2 at mainbus0: Tomatillo, version 4, ign 780, bus A 0 to 0 schizo2: dvma map c000-dfff pci3 at schizo2 ebus0 at pci3 dev 7 function 0 Acer Labs M1533 ISA rev 0x00 flashprom at ebus0 addr 0-f, 290-290 not configured rtc0 at ebus0 addr 70-71: m5819p pcfiic0 at ebus0 addr 320-321 ivec 0x1b iic0 at pcfiic0 SUNW,i2c-imax at iic0 addr 0xb not configured SUNW,i2c-imax at iic0 addr 0xc not configured admtemp0 at iic0 addr 0x18: max1617 pca9555 at iic0 addr 0x21 not configured pca9555 at iic0 addr 0x22 not configured pca9555 at iic0 addr 0x23 not configured pca9555 at iic0 addr 0x24 not configured adm1026 at iic0 addr 0x2e not configured admtemp1 at iic0 addr 0x32: max1617
Re: Transparent smtp/pop3 proxy
On 2011-07-28, R0me0 *** knight@gmail.com wrote: Hello misc. I would like to know if is possible do the following: clients--OpenBSD_FWExternal_mail_server when clients send or receive an email, OpenBSD catch this mail and send a copy of this to another email account, it must be transparently to user. Please, anybody, can indicate the correctly way to do this? Thanks in advanced Cheers, dsniff has mailsnarf which claims to do this, it won't handle encrypted sessions even if you have the key material and I have no idea how well it can handle recent SMTP implementations. For SMTP you can run a standard MTA like Postfix and divert all connections to it and use always_bcc or similar. In some places intercepting communications will likely be illegal (at least without consent from one or possibly both parties), so do your own research as to whether you're allowed to do this. Intercepting mail like this is *very easy*. People who want to avoid having their mail intercepted in this way should 1) use encryption and 2) carefully check that they're connecting to the server which they're expecting (check certificates etc).
Re: Building kernel outside /usr/src/sys -- from the FAQ
On Fri, Jul 29, 2011 at 2:28 PM, Gilles Chehade gil...@poolp.org wrote: On Fri, Jul 29, 2011 at 10:43:52AM +0200, David Vasek wrote: On Fri, 29 Jul 2011, Amarendra Godbole wrote: Hi, http://www.openbsd.org/faq/faq5.html#BldKernel has a section Variation on above process: Read-only source tree, which talks about building a kernel outside src/. Interestingly, when I do a GENERIC.MP build, by following these steps, the name displayed via config is that of the directory in which this kernel has been built. Eg. # cd /home/foo/bar/testbuild # cp /usr/src/sys/arch/i386/conf/GENERIC.MP . # config -s /usr/src/sys -b . GENERIC.MP # make clean make depend make # make install config -e displays the kernel string as: OpenBSD 5.0-beta (testbuild) #2: Fri Jul 29 12:50:00 IST 2011 root@zimbu:/home/foo/bar/testbuild This may confuse, especially when a dmesg is required, as it loses the type of kernel built - GENERIC or GENERIC.MP. It loses the arch too. It is not easy to distinguish between i386 and amd64 then. Regards, David can't you actually do: # mkdir -p /home/foo/bar/testbuild/`uname -m`/GENERIC.MP # cd /home/foo/bar/testbuild/`uname -m`/GENERIC.MP which would keep the arch and kernel name in the build path just as with a build from the regular path ? Gilles -- Gilles Chehade http://u.poolp.org/~gilles/ [...] Is it possible to update the FAQ to reflect this? Since cd /somewhere does not accurately indicate this, and dmesg then creates a problem. -Amarendra
Re: [OT] io event triggered file system synchronisation
frantisek holop wrote: hi there, sorry for the offtopic but there are probably many knowledgeable admins on this list as well. i am looking for a solution that keeps monitoring file system io for all stuff under a certain path and whenever files change/get added/removed it synchronises these changes with multiple remote locations. basically sql replication for file system :] anybody using something like this? -f I've never used it, I don't know how well it works, but it might fit your needs: http://en.wikipedia.org/wiki/Andrew_File_System
all libc of my openbsd/i386
(23:24:04) john@pdc:[~]$ du -sh /usr/lib/libc.so.* 704K /usr/lib/libc.so.34.2 704K /usr/lib/libc.so.35.0 704K /usr/lib/libc.so.35.1 704K /usr/lib/libc.so.36.0 720K /usr/lib/libc.so.37.0 720K /usr/lib/libc.so.38.0 720K /usr/lib/libc.so.38.1 688K /usr/lib/libc.so.38.2 688K /usr/lib/libc.so.38.3 3.8M /usr/lib/libc.so.38.4 3.8M /usr/lib/libc.so.39.0 3.8M /usr/lib/libc.so.39.1 3.8M /usr/lib/libc.so.39.2 3.8M /usr/lib/libc.so.39.3 3.8M /usr/lib/libc.so.40.0 3.8M /usr/lib/libc.so.40.1 3.8M /usr/lib/libc.so.40.2 3.8M /usr/lib/libc.so.40.3 3.8M /usr/lib/libc.so.41.0 3.8M /usr/lib/libc.so.42.0 3.8M /usr/lib/libc.so.42.1 3.8M /usr/lib/libc.so.43.0 3.9M /usr/lib/libc.so.44.0 3.9M /usr/lib/libc.so.45.0 3.9M /usr/lib/libc.so.46.0 3.9M /usr/lib/libc.so.47.0 3.9M /usr/lib/libc.so.48.0 4.0M /usr/lib/libc.so.49.0 4.0M /usr/lib/libc.so.50.0 4.0M /usr/lib/libc.so.50.1 4.1M /usr/lib/libc.so.51.0 4.1M /usr/lib/libc.so.51.1 4.1M /usr/lib/libc.so.51.2 4.1M /usr/lib/libc.so.52.0 4.1M /usr/lib/libc.so.53.0 4.1M /usr/lib/libc.so.53.1 4.1M /usr/lib/libc.so.53.2 4.1M /usr/lib/libc.so.54.0 4.1M /usr/lib/libc.so.55.0 2.4M /usr/lib/libc.so.56.0 2.4M /usr/lib/libc.so.57.0 2.4M /usr/lib/libc.so.58.0 2.4M /usr/lib/libc.so.58.1 2.5M /usr/lib/libc.so.58.2 2.5M /usr/lib/libc.so.58.3 2.5M /usr/lib/libc.so.60.0
Re: Transparent smtp/pop3 proxy
Hy Stuart, Is always very good read your mails here at misc :) a friend has done it, and he say to me the same that you, to me use ( always_bcc ) Thank you, I'm read a little more, but the ideias now are fixed Best regards, 2011/7/29 Stuart Henderson s...@spacehopper.org On 2011-07-28, R0me0 *** knight@gmail.com wrote: Hello misc. I would like to know if is possible do the following: clients--OpenBSD_FWExternal_mail_server when clients send or receive an email, OpenBSD catch this mail and send a copy of this to another email account, it must be transparently to user. Please, anybody, can indicate the correctly way to do this? Thanks in advanced Cheers, dsniff has mailsnarf which claims to do this, it won't handle encrypted sessions even if you have the key material and I have no idea how well it can handle recent SMTP implementations. For SMTP you can run a standard MTA like Postfix and divert all connections to it and use always_bcc or similar. In some places intercepting communications will likely be illegal (at least without consent from one or possibly both parties), so do your own research as to whether you're allowed to do this. Intercepting mail like this is *very easy*. People who want to avoid having their mail intercepted in this way should 1) use encryption and 2) carefully check that they're connecting to the server which they're expecting (check certificates etc).
Re: Building kernel outside /usr/src/sys -- from the FAQ
On 07/29/2011 11:18 AM, Amarendra Godbole wrote: On Fri, Jul 29, 2011 at 2:28 PM, Gilles Chehadegil...@poolp.org wrote: On Fri, Jul 29, 2011 at 10:43:52AM +0200, David Vasek wrote: On Fri, 29 Jul 2011, Amarendra Godbole wrote: Hi, http://www.openbsd.org/faq/faq5.html#BldKernel has a section Variation on above process: Read-only source tree, which talks about building a kernel outside src/. Interestingly, when I do a GENERIC.MP build, by following these steps, the name displayed via config is that of the directory in which this kernel has been built. Eg. # cd /home/foo/bar/testbuild # cp /usr/src/sys/arch/i386/conf/GENERIC.MP . # config -s /usr/src/sys -b . GENERIC.MP # make clean make depend make # make install config -e displays the kernel string as: OpenBSD 5.0-beta (testbuild) #2: Fri Jul 29 12:50:00 IST 2011 root@zimbu:/home/foo/bar/testbuild This may confuse, especially when a dmesg is required, as it loses the type of kernel built - GENERIC or GENERIC.MP. It loses the arch too. It is not easy to distinguish between i386 and amd64 then. Regards, David can't you actually do: # mkdir -p /home/foo/bar/testbuild/`uname -m`/GENERIC.MP # cd /home/foo/bar/testbuild/`uname -m`/GENERIC.MP which would keep the arch and kernel name in the build path just as with a build from the regular path ? Gilles -- Gilles Chehade http://u.poolp.org/~gilles/ [...] Is it possible to update the FAQ to reflect this? Since cd /somewhere does not accurately indicate this, and dmesg then creates a problem. -Amarendra When you build your own kernel, OpenBSD developers have very little ability to verify you didn't just edit /conf/GENERIC in some stupid way and blow a huge hole in your foot (and potentially a huge hole in some developers schedule) We all know that. We really don't care what the banner line says at that point. Either someone is going to look at your problem and think, hm. wonder if it is , and see if they can replicate find the error, or they will say, wonder why he was rolling his own kernel and just assume you broke something. You want -current? Grab a snapshot. You want -release? Grab a release. You want -stable? Build it following the simplest possible directions (and if -stable has an issue that has anything to do with hw compatibility or an improved subsystem, you will want to see if you can replicate the problem on -current anyway). Building a kernel just for giggles is often a sign that you broke it. Building a kernel in special ways just increases the odds. I'll update this section. I think you won't like what I'll do with it, but I suspect Theo is about to yell at me about why this is in the FAQ, and this thread pretty well indicates he'll be right to do so. Nick.
Re: all libc of my openbsd/i386
find / -type f -perm -0111 -exec ldd {} 2/dev/null \; -print | awk
'/libc.so/ {print $7}' | sort | uniq
On Fri, Jul 29, 2011 at 8:50 AM, johnw johnw.m...@gmail.com wrote:
(23:24:04) john@pdc:[~]$ du -sh /usr/lib/libc.so.*
704K /usr/lib/libc.so.34.2
704K /usr/lib/libc.so.35.0
[snip]
2.4M /usr/lib/libc.so.57.0
2.4M /usr/lib/libc.so.58.0
2.4M /usr/lib/libc.so.58.1
2.5M /usr/lib/libc.so.58.2
2.5M /usr/lib/libc.so.58.3
2.5M /usr/lib/libc.so.60.0
Re: all libc of my openbsd/i386
On 07/29/11 11:50, johnw wrote: (23:24:04) john@pdc:[~]$ du -sh /usr/lib/libc.so.* 704K /usr/lib/libc.so.34.2 704K /usr/lib/libc.so.35.0 704K /usr/lib/libc.so.35.1 [43 libc's deleted] Go clean your room. --STeve Andre'
Re: all libc of my openbsd/i386
Great stuff!!! These are my kernels (sparc64): 7.0M/bsd 7.0M/bsd.mp 2.5M/bsd.rd Not so many, but still pretty useless, no ? Paul 'WEiRD' de Weerd On Fri, Jul 29, 2011 at 11:50:22PM +0800, johnw wrote: | (23:24:04) john@pdc:[~]$ du -sh /usr/lib/libc.so.* | 704K /usr/lib/libc.so.34.2 | 704K /usr/lib/libc.so.35.0 | 704K /usr/lib/libc.so.35.1 | 704K /usr/lib/libc.so.36.0 | 720K /usr/lib/libc.so.37.0 | 720K /usr/lib/libc.so.38.0 | 720K /usr/lib/libc.so.38.1 | 688K /usr/lib/libc.so.38.2 | 688K /usr/lib/libc.so.38.3 | 3.8M /usr/lib/libc.so.38.4 | 3.8M /usr/lib/libc.so.39.0 | 3.8M /usr/lib/libc.so.39.1 | 3.8M /usr/lib/libc.so.39.2 | 3.8M /usr/lib/libc.so.39.3 | 3.8M /usr/lib/libc.so.40.0 | 3.8M /usr/lib/libc.so.40.1 | 3.8M /usr/lib/libc.so.40.2 | 3.8M /usr/lib/libc.so.40.3 | 3.8M /usr/lib/libc.so.41.0 | 3.8M /usr/lib/libc.so.42.0 | 3.8M /usr/lib/libc.so.42.1 | 3.8M /usr/lib/libc.so.43.0 | 3.9M /usr/lib/libc.so.44.0 | 3.9M /usr/lib/libc.so.45.0 | 3.9M /usr/lib/libc.so.46.0 | 3.9M /usr/lib/libc.so.47.0 | 3.9M /usr/lib/libc.so.48.0 | 4.0M /usr/lib/libc.so.49.0 | 4.0M /usr/lib/libc.so.50.0 | 4.0M /usr/lib/libc.so.50.1 | 4.1M /usr/lib/libc.so.51.0 | 4.1M /usr/lib/libc.so.51.1 | 4.1M /usr/lib/libc.so.51.2 | 4.1M /usr/lib/libc.so.52.0 | 4.1M /usr/lib/libc.so.53.0 | 4.1M /usr/lib/libc.so.53.1 | 4.1M /usr/lib/libc.so.53.2 | 4.1M /usr/lib/libc.so.54.0 | 4.1M /usr/lib/libc.so.55.0 | 2.4M /usr/lib/libc.so.56.0 | 2.4M /usr/lib/libc.so.57.0 | 2.4M /usr/lib/libc.so.58.0 | 2.4M /usr/lib/libc.so.58.1 | 2.5M /usr/lib/libc.so.58.2 | 2.5M /usr/lib/libc.so.58.3 | 2.5M /usr/lib/libc.so.60.0 | -- [++-]+++.+++[---].+++[+ +++-].++[-]+.--.[-] http://www.weirdnet.nl/
Re: all libc of my openbsd/i386
[...] There are many like them, but these are yours?
Novedades de recorridos en China - Transatlantico - Aruba
Novedades de recorridos en China - Transatlantico
Re: very slow writes with softdep enabled on mpi(4)
On Fri, Jul 29, 2011, Mattieu Baptiste wrote: After digging around this problem with help from Pedro, I noticed that a 4.9-release kernel works ok, whereas a 5.0-beta does not. So I tried to identify which commit was responsible and found out this one is responsible of *very* slow writes with softdep (I only have this bug on sparc64): http://marc.info/?l=openbsd-cvsm=130730313107059w=2 I can add that this bug is just affecting softdep: - dd'ing to the raw device is fast, - dd'ing to the file system mounted sync is very fast, - dd'ing to the file system mounted async is very fast, - dd'ing to the file system mounted with softdep is very slow. I can also add that changing a working kernel to bufcachepercent =42 via sysctl is ok too. What happens if you change bufcachepercent to a much smaller value, like the 4.9 default?
Supporting large number of IPSec tunnels
Misc -- Can anyone size hardware that would be required for a IPSec head-end terminating 1 tunnels. The total bandwidth across all the tunnels is about 2mb/s. Is this something that can be done on a single server or is some type of cluster needed. Can this be made to be redundant with sasyncd. Thanks for any help you can provide. Will
Taller de Actualización del Sistema SSPA de PEMEX
[IMAGE] Pms de Mixico Capacitacisn Efectiva de Mixico presenta:Taller del Sistema SSPA: Sistema de Seguridad, Salud, Proteccisn Ambiental de PEMEX.29 de Agosto, Ciudad de Mixico.Expositor: Mtro. Gerardo Coronado L.10 horas de entrenamiento, Conozca los beneficios de capacitarse con los mejores!Empresa Registrada ante la STPS Reg. COLG640205CP30005Smguenos en Twitter@pmscapacitacion o bien en Facebook PMS de Mixico Solicite mas informacisn de este Seminario! Por favor responda este e-mail con los datos siguientes. Empresa: Nombre: Telifono: Email: Nzmero de Interesados: Y en breve le haremos llegar la informacisn completa del evento. O bien comunmquense a nuestros telifonos un ejecutivo con gusto le atendera Telifonos: (0133) 8851-2365, (0133) 8851-2741, (0133) 1589-6156. Copyright (C) 2011, PMS Capacitacisn Efectiva de Mixico S.C. Derechos Reservados. PMS de Mixico, El logo de PMS de Mixico son marcas registradas. ADVERTENCIA PMS de Mixico no cuenta con alianzas estratigicas de ningzn tipo dentro de la Republica Mexicana. NO SE DEJE ENGAQAR - DIGA NO A LA PIRATERIA. Todos los logotipos, marcas comerciales e imagenes son propiedad de sus respectivas corporaciones y se utilizan con fines informativos solamente. Este Mensaje ha sido enviado a misc@openbsd.org como usuario de Pms de Mixico o bien un usuario le refiris para recibir este boletmn. Como usuario de Pms de Mixico, en este acto autoriza de manera expresa que Pms de Mixico le puede contactar vma correo electrsnico u otros medios. Si usted ha recibido este mensaje por error, haga caso omiso de el y reporte su cuenta respondiendo este correo con el subject BAJAPEMEXUnsubscribe to this mailing list, reply a blank message with the subject UNSUBSCRIBE BAJAPEMEX Tenga en cuenta que la gestisn de nuestras bases de datos es de suma importancia y no es intencisn de la empresa la inconformidad del receptor.
Re: very slow writes with softdep enabled on mpi(4)
On Fri, Jul 29, 2011 at 11:58 PM, Ted Unangst t...@tedunangst.com wrote: On Fri, Jul 29, 2011, Mattieu Baptiste wrote: After digging around this problem with help from Pedro, I noticed that a 4.9-release kernel works ok, whereas a 5.0-beta does not. So I tried to identify which commit was responsible and found out this one is responsible of *very* slow writes with softdep (I only have this bug on sparc64): http://marc.info/?l=openbsd-cvsm=130730313107059w=2 I can add that this bug is just affecting softdep: - dd'ing to the raw device is fast, - dd'ing to the file system mounted sync is very fast, - dd'ing to the file system mounted async is very fast, - dd'ing to the file system mounted with softdep is very slow. I can also add that changing a working kernel to bufcachepercent =42 via sysctl is ok too. What happens if you change bufcachepercent to a much smaller value, like the 4.9 default? If I change kern.bufcachepercent via sysctl to 10 or 5, it's still very slow. -- Mattieu Baptiste /earth is 102% full ... please delete anyone you can.
Re: amd64 snapshot kqemu hangs
On Fri, Jul 29, 2011 at 11:58 AM, [BG-Consulting] Elmar Bschorer
elmar.bscho...@bugconsulting.de wrote:
Hi list,
I've just tried snapshot version (5.0beta - 27 Jul). I wanted to test bigmem
with qemu and kqemu.
When I tried to load the kqemu module (pkg_add
ftp://mirror/pub/OpenBSD/snapshots/packages/amd64/) my system freezes:
kqemu: kqemu version 0x000103000 loaded, max locked mem=2026212kB
uvm_fault(0xfe816acf0380, 0x0, 0, 1) - e
kernel: page fault trap, code=0
Stopped at namei+0x1c: movq 0x20(%r14),%rax
ddb{1}
I set securitylevel to -1
Is this a bug or did I miss something?
Need dmesg?
With qemu i'm using
# config -ef /bsd
disable mpbios
quit
try that
Giannis
