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
