subversion port 3.7 problem
Hi, when I try to build subversion on 3.7 i386 I get: [] main.o -c /usr/ports/devel/subversion/w-subversion-1.1.3p0/subversion-1.1.3/subversion/svnadmin/main.c cd subversion/svnadmin && /bin/sh /usr/ports/devel/subversion/w-subversion-1.1.3p0/build-i386/libtool --silent --mode=link cc -O2 -pipe-DNEON_ZLIB -DNEON_SSL -L/usr/local/lib/db4 -L/usr/local/lib -rpath /usr/local/lib -o svnadmin main.o ../../subversion/libsvn_repos/libsvn_repos-1.la ../../subversion/libsvn_fs/libsvn_fs-1.la ../../subversion/libsvn_delta/libsvn_delta-1.la ../../subversion/libsvn_subr/libsvn_subr-1.la /usr/local/lib/libaprutil-1.la -ldb -lexpat -liconv /usr/local/lib/libapr-1.la -lintl -liconv -lz /usr/local/lib/libsvn_subr-1.so.0.0: warning: sprintf() is often misused, please use snprintf() main.o(.text+0x90b): In function `subcommand_recover': : undefined reference to `svn_repos_recover2' main.o(.text+0x9c1): In function `subcommand_recover': : undefined reference to `svn_repos_recover2' main.o(.text+0xe27): In function `subcommand_setlog': : undefined reference to `svn_repos_fs_change_rev_prop2' collect2: ld returned 1 exit status *** Error code 1 Stop in /usr/ports/devel/subversion/w-subversion-1.1.3p0/build-i386 (line 355 of /usr/ports/devel/subversion/w-subversion-1.1.3p0/subversion-1.1.3/build-outputs.mk). *** Error code 1 Stop in /usr/ports/devel/subversion (line 1769 of /usr/ports/infrastructure/mk/bsd.port.mk). I have YET to build subversion for OpenBSD, I thought I'd let the port do it for me =( Any ideas? Thanks!
Re: subversion port 3.7 problem
Thank You! I had a version I tried to build from source before upgrading to 3.7 Got it installed now. From: steven mestdagh [mailto:[EMAIL PROTECTED] Sent: Wed 5/25/2005 6:01 PM To: Price, Joe Cc: misc@openbsd.org Subject: Re: subversion port 3.7 problem On Wed, May 25, 2005 at 05:22:54PM -0400, Price, Joe wrote: > Hi, when I try to build subversion on 3.7 i386 I get: > > > [] > > main.o -c > /usr/ports/devel/subversion/w-subversion-1.1.3p0/subversion-1.1.3/subversion/svnadmin/main.c > cd subversion/svnadmin && /bin/sh > /usr/ports/devel/subversion/w-subversion-1.1.3p0/build-i386/libtool --silent > --mode=link cc -O2 -pipe-DNEON_ZLIB -DNEON_SSL -L/usr/local/lib/db4 > -L/usr/local/lib -rpath /usr/local/lib -o svnadmin main.o > ../../subversion/libsvn_repos/libsvn_repos-1.la > ../../subversion/libsvn_fs/libsvn_fs-1.la > ../../subversion/libsvn_delta/libsvn_delta-1.la > ../../subversion/libsvn_subr/libsvn_subr-1.la /usr/local/lib/libaprutil-1.la > -ldb -lexpat -liconv /usr/local/lib/libapr-1.la -lintl -liconv -lz > /usr/local/lib/libsvn_subr-1.so.0.0: warning: sprintf() is often misused, > please use snprintf() > main.o(.text+0x90b): In function `subcommand_recover': > : undefined reference to `svn_repos_recover2' > main.o(.text+0x9c1): In function `subcommand_recover': > : undefined reference to `svn_repos_recover2' > main.o(.text+0xe27): In function `subcommand_setlog': > : undefined reference to `svn_repos_fs_change_rev_prop2' > collect2: ld returned 1 exit status > *** Error code 1 > > Stop in /usr/ports/devel/subversion/w-subversion-1.1.3p0/build-i386 (line 355 > of > /usr/ports/devel/subversion/w-subversion-1.1.3p0/subversion-1.1.3/build-outputs.mk). > *** Error code 1 > > Stop in /usr/ports/devel/subversion (line 1769 of > /usr/ports/infrastructure/mk/bsd.port.mk). > > > > I have YET to build subversion for OpenBSD, I thought I'd let the port do it > for me =( > > Any ideas? works fine here. maybe it's linking in older libraries again (this should not happen) from /usr/local/lib. so, are you sure you don't have any older subversion libraries installed in /usr/local/lib, before starting the build? steven
Upgrade to 4.0 - fsck freezes system.
We're trying our first upgrade to 4.0 and fsck during the upgrade process seems to freeze the machine. I searched the mailing list and found: http://marc.theaimsgroup.com/?l=openbsd-misc&m=116242735913440&w=2 (Upgrading to 4.0 - fsck takes a very long time?), but I don't think that is the same issue due to the facts that (1) we left it for about 20 hours and (2) it appeared to freeze the machine. Note that if we drop to a shell in 4.0 and try to fsck manually, it hangs also. As this is our OpenBSD test machine, it's holding back about ten other potential OpenBSD upgrades to 4.0. Any assistance would be appreciated, we want to upgrade! :-) Pertinent information follows: # fdisk wd0 Disk: wd0 geometry: 30401/255/63 [488392065 Sectors] Offset: 0 Signature: 0xAA55 Starting Ending LBA Info: #: idC H S -C H S [ start: size ] 0: 000 0 0 -0 0 0 [ 0: 0 ] unused 1: 000 0 0 -0 0 0 [ 0: 0 ] unused 2: 000 0 0 -0 0 0 [ 0: 0 ] unused *3: A60 1 1 - 30400 254 63 [ 63: 488392002 ] OpenBSD # disklabel wd0 # Inside MBR partition 3: type A6 start 63 size 488392002 # /dev/rwd0c: type: ESDI disk: ESDI/IDE disk label: HDT722525DLAT80 flags: bytes/sector: 512 sectors/track: 63 tracks/cylinder: 16 sectors/cylinder: 1008 cylinders: 16383 total sectors: 488397168 rpm: 3600 interleave: 1 trackskew: 0 cylinderskew: 0 headswitch: 0 # microseconds track-to-track seek: 0 # microseconds drivedata: 0 16 partitions: # sizeoffset fstype [fsize bsize cpg] a: 47185884963 4.2BSD 2048 16384 328 # Cyl 0*-468113 b: 16533153 471858912swap # Cyl 468114 -484515* c: 488397168 0 unused 0 0 # Cyl 0 -484520 # cat /var/run/dmesg.boot OpenBSD 3.9 (GENERIC) #1: Sat Nov 4 09:42:59 EST 2006 [EMAIL PROTECTED]:/usr/src/sys/arch/i386/compile/GENERIC cpu0: Intel Pentium III ("GenuineIntel" 686-class, 512KB L2 cache) 547 MHz cpu0: FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,F XSR,SSE real mem = 133787648 (130652K) avail mem = 115355648 (112652K) using 1658 buffers containing 6791168 bytes (6632K) of memory mainbus0 (root) bios0 at mainbus0: AT/286+(c2) BIOS, date 11/04/99, BIOS32 rev. 0 @ 0xfd780 apm0 at bios0: Power Management spec V1.2 apm0: AC on, battery charge unknown apm0: flags 30102 dobusy 0 doidle 1 pcibios0 at bios0: rev 2.1 @ 0xfd780/0x880 pcibios0: PCI IRQ Routing Table rev 1.0 @ 0xfdf10/208 (11 entries) pcibios0: PCI Interrupt Router at 000:07:0 ("Intel 82371FB ISA" rev 0x00) pcibios0: PCI bus #1 is the last bus bios0: ROM list: 0xc/0x1 0xd/0x1800 0xd1800/0x2800 0xe4000/0xc000 cpu0 at mainbus0 pci0 at mainbus0 bus 0: configuration mode 1 (no bios) pchb0 at pci0 dev 0 function 0 "Intel 82443BX AGP" rev 0x03 ppb0 at pci0 dev 1 function 0 "Intel 82443BX AGP" rev 0x03 pci1 at ppb0 bus 1 vga1 at pci1 dev 0 function 0 "NVIDIA Vanta" rev 0x15 wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation) wsdisplay0: screen 1-5 added (80x25, vt100 emulation) pcib0 at pci0 dev 7 function 0 "Intel 82371AB PIIX4 ISA" rev 0x02 pciide0 at pci0 dev 7 function 1 "Intel 82371AB IDE" rev 0x01: DMA, channel 0 wired to compatibility, channel 1 wired to compatibility wd0 at pciide0 channel 0 drive 0: wd0: 16-sector PIO, LBA48, 238475MB, 488397168 sectors wd0(pciide0:0:0): using PIO mode 4, Ultra-DMA mode 2 atapiscsi0 at pciide0 channel 1 drive 0 scsibus0 at atapiscsi0: 2 targets cd0 at scsibus0 targ 0 lun 0: SCSI0 5/cdrom removable cd0(pciide0:1:0): using PIO mode 4, Ultra-DMA mode 2 uhci0 at pci0 dev 7 function 2 "Intel 82371AB USB" rev 0x01: irq 9 usb0 at uhci0: USB revision 1.0 uhub0 at usb0 uhub0: Intel UHCI root hub, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered piixpm0 at pci0 dev 7 function 3 "Intel 82371AB Power" rev 0x02: SMI iic0 at piixpm0 "unknown" at iic0 addr 0x18 not configured "unknown" at iic0 addr 0x4e not configured em0 at pci0 dev 14 function 0 "Intel PRO/1000MT (82540EM)" rev 0x02: irq 11, address 00:07:e9:0e:47:c9 ahc0 at pci0 dev 15 function 0 "Adaptec AHA-2940" rev 0x00: irq 10 scsibus1 at ahc0: 8 targets st0 at scsibus1 targ 3 lun 0: SCSI2 1/sequential removable st0: density code 0x13, variable blocks, write-enabled isa0 at pcib0 isadma0 at isa0 pckbc0 at isa0 port 0x60/5 pckbd0 at pckbc0 (kbd slot) pckbc0: using irq 1 for kbd slot wskbd0 at pckbd0: console keyboard, using wsdisplay0 pcppi0 at isa0 port 0x61 midi0 at pcppi0: spkr0 at pcppi0 lpt0 at isa0 port 0x378/4 irq 7 npx0 at isa0 port 0xf0/16: using exception 16 pccom0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo fdc0 at isa0 port 0x
windows -> pf -> inet -> pf -> ftpd [not working]
I have a problem that when a Windows client tries to connect to this ftp site, windows explorer returns 'The operation timed out'. The setup is, windows box behind a openbsd PF (NAT enabled) through the public internet to another openbsd PF (NAT enabled) which has a rdr rule to redirect to another openbsd machine behind it running ftpd. I'm assuming the problem exists on one of the firewalls, or both.. Is this something that ftp-proxy can fix? I know the ftp works because I can connect to it form the far end's openbsd box, just seems that I can't go through two NATs of PFs or something like that. Any help is appreciated. Thanks!
Re: windows -> pf -> inet -> pf -> ftpd [not working]
FYI, I am in passive mode. From: Price, Joe Sent: Thursday, January 19, 2006 5:36 PM To: 'misc@openbsd.org' Subject: windows -> pf -> inet -> pf -> ftpd [not working] I have a problem that when a Windows client tries to connect to this ftp site, windows explorer returns 'The operation timed out'. The setup is, windows box behind a openbsd PF (NAT enabled) through the public internet to another openbsd PF (NAT enabled) which has a rdr rule to redirect to another openbsd machine behind it running ftpd. I'm assuming the problem exists on one of the firewalls, or both.. Is this something that ftp-proxy can fix? I know the ftp works because I can connect to it form the far end's openbsd box, just seems that I can't go through two NATs of PFs or something like that. Any help is appreciated. Thanks!
Re: windows -> pf -> inet -> pf -> ftpd [not working]
On the far end, the pf rules are simply pass all On this end the only rules that apply are: scrub in no-df nat on $ext_if from !($ext_if) -> ($ext_if:0) rdr on $ext_if proto tcp from any to X.X.X.X/32 port ftp -> X.X.X.X port ftp I tried using cuteftp on a windows box behind the far end, using PASV & EPSV.. Still no luck. This must be possible. Below I highlight the fact that they are windows clients connecting from behind the far end's firewall. It very well may be that any connection from any OS from behind the far end does not work. It does however, work when I use an OpenBSD box that is connected directly to thee Internet.. - Original Message - From: "Price, Joe" <[EMAIL PROTECTED]> To: Sent: Thursday, January 19, 2006 6:36 PM Subject: windows -> pf -> inet -> pf -> ftpd [not working] >I have a problem that when a Windows client tries to connect to this ftp > site, windows explorer returns 'The operation timed out'. > > > > The setup is, windows box behind a openbsd PF (NAT enabled) through the > public internet to another openbsd PF (NAT enabled) which has a rdr rule > to redirect to another openbsd machine behind it running ftpd. > > > > I'm assuming the problem exists on one of the firewalls, or both.. Is > this something that ftp-proxy can fix? > > > > I know the ftp works because I can connect to it form the far end's > openbsd box, just seems that I can't go through two NATs of PFs or > something like that. > > > > Any help is appreciated. > > > > Thanks!
Stopped at pf_test_rule+0xa87 [again]
Two different hardware firewall 4.6 machines in the last 24 hours have produced the following: UVM_fault(0xd0891180, 0x0, 0, 3) -> e Kernel: page fault trap, code = 0 Stopped at pf_test_rule+0xa87: movl%ecx,0x4(%ecx) Ddb{0}> Frozen, couldn't type anything... Now, I did some research and found this thread: http://www.mail-archive.com/misc@openbsd.org/msg83853.html from late last year. In summary, it sounds like Henning may have fixed it from this post: http://marc.info/?l=openbsd-cvs&m=124955744915786&w=2 My question is: should I just make my own patch and roll out changes to all our firewalls in our enterprise from some revision of pf.c (1.656, 1.657, 1.??? *which one*) to minimize risk of this crash happening again. We have only had 4.6 in production on one of the two machines [above] for a week and the other about a month, we have about half a dozen other firewalls at 4.6 just in the last week. Also, why didn't this make it to an errata reliability fix?
slow proxy (squid and tinyproxy)
Hello, I'm going to summarize this.. Basically, I have the squid port running on 4.6 i386 GENERIC and it is considerably slow. I have about 8 offices running similar configuration and they all exhibit similar behavior. When I turn off the proxy I get mad download speeds. When I turn the proxy on I get a fraction of my maximum throughput. I have been running tests from speedtest.net and I get ~20M down without proxy turned on, and ~5M down with it on.. My upload stays about the same ~2.5M. I've done these tests quite a few times and it seems very consistent. This doesn't seem acceptable.. I also tried tinyproxy just to compare/contrast and I get the same speeds through that as well. Both were installed from ports. I've done quite a bit of trying different things and reading online, but I don't see any clues to something where it's obviously not squid specific. Any help is greatly appreciated. Some specs from my primary test firewall: cpu0: Intel(R) Xeon(TM) CPU 2.80GHz ("GenuineIntel" 686-class) 2.81 GHz cpu0: FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUS H,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,SSE3,MWAIT,DS-CPL,CNXT-ID,CX16,xTPR real mem = 2146795520 (2047MB) avail mem = 2067058688 (1971MB) Squid.conf (from the machine I did the most testing from, and that has the most bandwidth and users): http_port XXX.XXX.0.108:3128 hierarchy_stoplist cgi-bin ? cache_dir null /tmp cache_access_log /var/squid/logs/access.log cache_store_log none dns_nameservers localhost redirect_children 10 redirect_rewrites_host_header off refresh_pattern ^ftp: 144020% 10080 refresh_pattern ^gopher:14400% 1440 refresh_pattern . 0 20% 4320 acl all src 0.0.0.0/0.0.0.0 acl manager proto cache_object acl localhost src 127.0.0.1/255.255.255.255 acl to_localhost dst 127.0.0.0/8 acl SSL_ports port 443 563 acl Safe_ports port 80 # http acl Safe_ports port 21 # ftp acl Safe_ports port 443 563 # https, snews acl Safe_ports port 70 # gopher acl Safe_ports port 210 # wais acl Safe_ports port 1025-65535 # unregistered ports acl Safe_ports port 280 # http-mgmt acl Safe_ports port 488 # gss-http acl Safe_ports port 591 # filemaker acl Safe_ports port 777 # multiling http acl CONNECT method CONNECT http_access allow manager localhost http_access deny manager http_access deny !Safe_ports http_access deny CONNECT !SSL_ports acl proxy_users_port myport 3128 http_access allow all http_access deny all http_reply_access allow all icp_access allow all tcp_outgoing_address XX.XXX.XX.81 cache_mgr info...@x.xxx coredump_dir /var/squid/cache
Re: slow proxy (squid and tinyproxy)
FAQ 6.6.4 - How can I increase performance on really high-speed, high traffic links? If you are seeing performance limitations when using a high-speed WAN connection transferring lots of data, you may see a performance gain by altering the following sysctls: net.inet.tcp.recvspace net.inet.tcp.sendspace Thanks for the tips. I guess I didn't consider 20M/5M link to be "really high-speed", but I used the valuse below for the sysctl values above and got very good results! -Original Message- From: Pete Vickers [mailto:p...@systemnet.no] Sent: Monday, June 14, 2010 5:46 PM To: Price, Joe Cc: misc@openbsd.org Subject: Re: slow proxy (squid and tinyproxy) I expect I'll get shot down for this, but this is what I run (after a good deal of trail & error) on my squid boxes ( ~700 users). YMMV. $ tail /etc/sysctl.conf #net.inet.tcp.ecn=1 net.inet.ip.ifq.maxlen=512 #net.inet.tcp.ackonpush=1 # net.inet.tcp.recvspace=262144 net.inet.tcp.sendspace=262144 net.inet.udp.recvspace=262144 net.inet.udp.sendspace=262144 # kern.maxfiles=8192 # kern.maxclusters=8192 and login.conf: daemon:\ :ignorenologin:\ :datasize=infinity:\ :maxproc=infinity:\ :openfiles=5000:\ :stacksize=8M:\ :localcipher=blowfish,8:\ :tc=default: /Pete On 14. juni 2010, at 22.43, Price, Joe wrote: > Hello, I'm going to summarize this.. > > Basically, I have the squid port running on 4.6 i386 GENERIC and it is > considerably slow. I have about 8 offices running similar configuration and > they all exhibit similar behavior. When I turn off the proxy I get mad > download speeds. When I turn the proxy on I get a fraction of my maximum > throughput. I have been running tests from speedtest.net and I get ~20M down > without proxy turned on, and ~5M down with it on.. My upload stays about the > same ~2.5M. I've done these tests quite a few times and it seems very > consistent. This doesn't seem acceptable.. > > I also tried tinyproxy just to compare/contrast and I get the same speeds > through that as well. Both were installed from ports. I've done quite a bit of > trying different things and reading online, but I don't see any clues to > something where it's obviously not squid specific. > > Any help is greatly appreciated. > > Some specs from my primary test firewall: > cpu0: Intel(R) Xeon(TM) CPU 2.80GHz ("GenuineIntel" 686-class) 2.81 GHz > cpu0: > FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUS > H,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,SSE3,MWAIT,DS-CPL,CNXT-ID,CX16,xTPR > real mem = 2146795520 (2047MB) > avail mem = 2067058688 (1971MB) > > > Squid.conf (from the machine I did the most testing from, and that has the > most bandwidth and users): > http_port XXX.XXX.0.108:3128 > > hierarchy_stoplist cgi-bin ? > > cache_dir null /tmp > > cache_access_log /var/squid/logs/access.log > > cache_store_log none > > dns_nameservers localhost > > redirect_children 10 > > redirect_rewrites_host_header off > > refresh_pattern ^ftp: 144020% 10080 > refresh_pattern ^gopher:14400% 1440 > refresh_pattern . 0 20% 4320 > > acl all src 0.0.0.0/0.0.0.0 > acl manager proto cache_object > acl localhost src 127.0.0.1/255.255.255.255 > acl to_localhost dst 127.0.0.0/8 > acl SSL_ports port 443 563 > acl Safe_ports port 80 # http > acl Safe_ports port 21 # ftp > acl Safe_ports port 443 563 # https, snews > acl Safe_ports port 70 # gopher > acl Safe_ports port 210 # wais > acl Safe_ports port 1025-65535 # unregistered ports > acl Safe_ports port 280 # http-mgmt > acl Safe_ports port 488 # gss-http > acl Safe_ports port 591 # filemaker > acl Safe_ports port 777 # multiling http > acl CONNECT method CONNECT > > http_access allow manager localhost > http_access deny manager > http_access deny !Safe_ports > http_access deny CONNECT !SSL_ports > > acl proxy_users_port myport 3128 > > http_access allow all > > http_access deny all > > http_reply_access allow all > > icp_access allow all > tcp_outgoing_address XX.XXX.XX.81 > > cache_mgr info...@x.xxx > > coredump_dir /var/squid/cache > Pete Vickers p...@systemnet.no | +47 48 17 91 00 SystemNet AS