Negative Reviews are killing your reputation
Dear Hotel Owner, Reviews about your hotel can make or break your hotel's success. If you don't enough positive reviews on Expedia, Google, Tripadvisor, Yahoo Travel and other such sites, you are losing the game. If you have negative reviews about your hotel, you are at serious disdvantage. Allow us to manage your reviews: 1) Our US-based, native English writers will create most effective management response to the negative reviews about your property. 2) We will also assist you in getting more positive reviews on all top portals. 3) We will monitor your reputation to ensure that you get more positive reviews. Respond today to protect your reputation on Internet. Regards, Jigna Patel. Cell : (331) 465-9247
Re: strange X problem after Aug11 snapshot
On Mon, Aug 15, 2011 at 8:02 PM, dsp d...@2f30.org wrote: Hi list :) sorry for not be able to debug this problem a lot but i haven't the slightest idea where to start! after the Aug 11 snapshot i started to experience screen blackenings How old was your previous snapshot? -- Matthieu Herrb
rebuild RAID1
Hi, I'm trying to test softraid. I use OpenBSD 4.8 Release, i have 2 disks : wd0 250G Openbsd is installed ; wd0k slice is part of RAID (200G) wd1 500G wd1k slice is part of RAID (200G) I built my RAID using this : bioctl -c 1 -l wd0k,wd1k softraid0 All is ok, sd0c is mounted in /home (cf /etc/fstab) Now i disconnected wd1, restart computer. /home is available, but RAID1 is degraded. Add wd1, restart computer, try bioctl -R sd0 0:1.0 (give me an error like not part in /dev/bio.) How can i rebuild ? Thank you very much. Wesley.
Re: strange X problem after Aug11 snapshot
On Tue, 16 Aug 2011 09:32:47 +0200
Matthieu Herrb mhe...@gmail.com wrote:
On Mon, Aug 15, 2011 at 8:02 PM, dsp d...@2f30.org wrote:
Hi list :)
sorry for not be able to debug this problem a lot but
i haven't the slightest idea where to start!
after the Aug 11 snapshot i started to experience screen blackenings
How old was your previous snapshot?
dsp told me he had rebuilt devel/sdl with three patches removed and
this made the problem go away. I did what he did and it solved the
problem for me too (amd64 Aug 7 snapshot -- dmesg in previous post).
The patches removed are patch-src_video_x11_SDL_x11{sym_h,video_[ch]}
They're the latest patches in the port dated 2011/05/13 and deal with
XRandR and VidMode.
Thinking back a few snapshots I believe it was around this time that
I first saw ffplay fail in this way, but I made no real notice about
it since I rarely use it and xine and mplayer worked fine anyway.
Thanks to dsp for sharing. Now I can play with qemu again ;-)
Re: rebuild RAID1
I built my RAID using this : bioctl -c 1 -l wd0k,wd1k softraid0 All is ok, sd0c is mounted in /home (cf /etc/fstab) Now i disconnected wd1, restart computer. /home is available, but RAID1 is degraded. Add wd1, restart computer, try bioctl -R sd0 0:1.0 (give me an error like not part in /dev/bio.) from the man page: The following command starts a rebuild of the degraded softraid volume sd0 using a new chunk on wd0d: # bioctl -R /dev/wd0d sd0 so in your case it would be: bioctl -R /dev/wd1k sd0
pf shape download
Hi, I'm having a problem to shape download with PF. I have 2 HFSC queue (main and second) created on my internal NIC. Main is my default queue. If I try to match download traffic to the second queue, it still go trought the main queue. The IP I want to download trought the second queue for my test unit is 10.254.200.2 $ext_if=re0 $int_if=re1 My rule to foward traffic to second queue is : match out on $int_if from any to 10.254.200.2 I also try with pass instead of match Look fine if I check the bob exemple in this faq : http://www.openbsd.org/faq/pf/queueing.html#example1 pfctl -vvsq still show traffic on main queue : queue main on re1 bandwidth 1Mb priority 2 qlimit 100 hfsc( red default upperlimit 97Mb ) [ pkts: 24701 bytes: 37333295 dropped pkts: 0 bytes: 0 ] [ qlength: 0/100 ] [ measured: 236.4 packets/s, 2.86Mb/s ] queue second on re1 bandwidth 1Mb priority 0 qlimit 250 hfsc( red upperlimit 97Mb ) [ pkts: 0 bytes: 0 dropped pkts: 0 bytes: 0 ] [ qlength: 0/250 ] [ measured: 0.0 packets/s, 0 b/s ] pftop -v rules show me that the rule don't match 12 Pass out re1 K 0 0 0 inet from any to 10.254.200.2/32flags S/SA queue second I can see my download with tcpdump : # tcpdump -i re1 host 10.254.200.2 ... 10:49:19.802505 10.254.200.2.49266 hammurabi.acc.umu.se.www: . ack 832200 win 64240 (DF) 10:49:19.802716 hammurabi.acc.umu.se.www 10.254.200.2.49266: . 832200:833660(1460) ack 1 win 6564 (DF) 10:49:19.802911 hammurabi.acc.umu.se.www 10.254.200.2.49266: . 833660:835120(1460) ack 1 win 6564 (DF) 10:49:19.803040 hammurabi.acc.umu.se.www 10.254.200.2.49266: . 835120:836580(1460) ack 1 win 6564 (DF) 10:49:19.803211 10.254.200.2.49266 hammurabi.acc.umu.se.www: . ack 836580 win 64240 (DF) 10:49:19.803248 hammurabi.acc.umu.se.www 10.254.200.2.49266: . 836580:838040(1460) ack 1 win 6564 (DF) 10:49:19.803252 hammurabi.acc.umu.se.www 10.254.200.2.49266: . 838040:839500(1460) ack 1 win 6564 (DF) 10:49:19.803367 hammurabi.acc.umu.se.www 10.254.200.2.49266: . 839500:840960(1460) ack 1 win 6564 (DF) ... I have pass days on this with OpenBSD 4.9 and FreeBSD 8.2 without result. I even tryed every 8 possible rules at the same time and pfctl was still showing traffic trought the main queue on : match in on re0 from any to 10.254.200.2 queue second match in on re1 from any to 10.254.200.2 queue second match out on re0 from any to 10.254.200.2 queue second match out on re0 from any to 10.254.200.2 queue second match in on re0 from 10.254.200.2 to any queue second match in on re1 from 10.254.200.2 to any queue second match out on re0 from 10.254.200.2 to any queue second match out on re0 from 10.254.200.2 to any queue second in this case, pftop was showing that it match out on re0 from 10.254.200.2 to any match on re1 from 10.254.200.2 to any it look like only upload rule match Can somebody help me on this ? Thanks Michel P.S : I have a VoIP queue that I will add after that will need the realtime option, that why I'm using HFSC.
relayd problems
Hi all,
Using a snapshot from Aug 1st I can't get more than one of these relays to run
at the same time with the fallback forward to in there, but up to 3 at once
with that line removed from each relay, with 4 relays though it always fails.
Any idea if this is a bug or configuration issue?
Thanks,
-James
Relayd.conf
# Macros
http_port=80
https_port=443
# Define server/service macros
include /etc/relays/hosts.conf
# Global Configuration
interval 20
timeout 200
prefork 10
log updates
# failover table
table fallback disable { 10.1.0.20 retry 2 }
include /etc/relays/relays.conf
# END
hosts.conf (/etc/relays/hosts.conf)
# www_a
www_a_ext=10. 0.0.193
www_a_01_int=172.20.30.137
table www_a { $www_a_01_int }
# www_b
www_b_ext=10.0.0.194
www_b_01_int=172.20.30.133
table www_b { $www_b_01_int }
# www_c
www_c_ext=10. 0.0.200
www_c_01_int=172.20.30.140
table www_c { $www_c_01_int }
# www_d
www_d_ext=10. 0.0.195
www_d_01_int=172.20.30.142
table www_d { $www_d_01_int }
# END
relays.conf (/etc/relays/relays.conf)
# www_a
relay www_a_com {
listen on $www_a_ext port 80
forward to www_a port 80 check http / code 200
forward to fallback port 80 timeout 300 check tcp
}
# www_b
relay www_b_com {
listen on $www_b_ext port 80
forward to www_b port 80 check http / code 200
forward to fallback port 80 timeout 300 check tcp
}
# www_c
relay www_c_com {
listen on $www_c_ext port 80
forward to www_c port 80 check http / code 200
forward to fallback port 80 timeout 300 check tcp
}
# www_d
relay www_d_com {
listen on $www_d_ext port 80
forward to www_d port 80 check http / code 200
forward to fallback port 80 timeout 300 check tcp
}
# END
# relayd -vvd
startup
socket_rlimit: max open files 1024
socket_rlimit: max open files 1024
socket_rlimit: max open files 1024
warning: macro 'http_port' not used
socket_rlimit: max open files 1024
warning: macro 'https_port' not used
socket_rlimit: max open files 1024
socket_rlimit: max open files 1024
relay_privinit: adding relay www_a_com
protocol -1: name default
flags: used, relay flags:
type: tcp
relay_privinit: adding relay www_b_com
protocol -1: name default
flags: used, relay flags:
type: tcp
relay_privinit: adding relay www_c_com
protocol -1: name default
flags: used, relay flags:
type: tcp
relay_privinit: adding relay www_d_com
protocol -1: name default
flags: used, relay flags:
type: tcp
adding 1 hosts from table www_a:80
relay_launch: running relay www_a_com
adding 1 hosts from table www_b:80
relay_launch: running relay www_b_com
adding 1 hosts from table www_c:80
adding 1 hosts from table www_a:80
relay_launch: running relay www_c_com
adding 1 hosts from table www_d:80
relay_launch: running relay www_d_com
relay_launch: running relay www_a_com
adding 1 hosts from table www_b:80
relay_launch: running relay www_b_com
adding 1 hosts from table www_c:80
relay_launch: running relay www_c_com
adding 1 hosts from table www_d:80
relay_launch: running relay www_d_com
adding 1 hosts from table www_a:80
relay_launch: running relay www_a_com
adding 1 hosts from table www_b:80
adding 1 hosts from table www_a:80
relay_launch: running relay www_b_com
relay_launch: running relay www_a_com
adding 1 hosts from table www_b:80
adding 1 hosts from table www_c:80
relay_launch: running relay www_c_com
relay_launch: running relay www_b_com
adding 1 hosts from table www_d:80
adding 1 hosts from table www_c:80
relay_launch: running relay www_d_com
relay_launch: running relay www_c_com
adding 1 hosts from table www_d:80
relay_launch: running relay www_d_com
adding 1 hosts from table www_a:80
relay_launch: running relay www_a_com
adding 1 hosts from table www_b:80
relay_launch: running relay www_b_com
adding 1 hosts from table www_c:80
relay_launch: running relay www_c_com
adding 1 hosts from table www_d:80
relay_launch: running relay www_d_com
hce_notify_done: 172.20.30.133 (http code ok)
host 172.20.30.133, check http code (2ms), state unknown - up, availability
100.00%
hce_notify_done: 172.20.30.137 (http code ok)
host 172.20.30.137, check http code (2ms), state unknown - up, availability
100.00%
hce_notify_done: 172.20.30.142 (http code ok)
host 172.20.30.142, check http code (2ms), state unknown - up, availability
100.00%
fatal: pfe_dispatch_imsg: invalid host id
hce exiting, pid 28386
lost child: hce exited okay
lost child: pfe exited abnormally
relay exiting, pid 672
relay exiting, pid 13247
relay exiting, pid 30099
relay exiting, pid 11566
relay exiting, pid 16851
parent terminating, pid 28820
Re: relayd problems
What are the spaces in the IP addresses?
On Tue, Aug 16, 2011 at 11:46:26AM -0500, James Flom wrote:
:Hi all,
:
:Using a snapshot from Aug 1st I can't get more than one of these relays to run
:at the same time with the fallback forward to in there, but up to 3 at once
:with that line removed from each relay, with 4 relays though it always fails.
:Any idea if this is a bug or configuration issue?
:
:Thanks,
:-James
:
:Relayd.conf
:# Macros
:http_port=80
:https_port=443
:
:# Define server/service macros
:include /etc/relays/hosts.conf
:
:# Global Configuration
:interval 20
:timeout 200
:prefork 10
:log updates
:
:# failover table
:table fallback disable { 10.1.0.20 retry 2 }
:
:include /etc/relays/relays.conf
:# END
:
:
:hosts.conf (/etc/relays/hosts.conf)
:# www_a
:www_a_ext=10. 0.0.193
:www_a_01_int=172.20.30.137
:table www_a { $www_a_01_int }
:
:# www_b
:www_b_ext=10.0.0.194
:www_b_01_int=172.20.30.133
:table www_b { $www_b_01_int }
:
:# www_c
:www_c_ext=10. 0.0.200
:www_c_01_int=172.20.30.140
:table www_c { $www_c_01_int }
:
:# www_d
:www_d_ext=10. 0.0.195
:www_d_01_int=172.20.30.142
:table www_d { $www_d_01_int }
:# END
:
:
:relays.conf (/etc/relays/relays.conf)
:# www_a
:relay www_a_com {
:listen on $www_a_ext port 80
:forward to www_a port 80 check http / code 200
:forward to fallback port 80 timeout 300 check tcp
:}
:
:# www_b
:relay www_b_com {
:listen on $www_b_ext port 80
:forward to www_b port 80 check http / code 200
:forward to fallback port 80 timeout 300 check tcp
:}
:
:# www_c
:relay www_c_com {
:listen on $www_c_ext port 80
:forward to www_c port 80 check http / code 200
:forward to fallback port 80 timeout 300 check tcp
:}
:
:# www_d
:relay www_d_com {
:listen on $www_d_ext port 80
:forward to www_d port 80 check http / code 200
:forward to fallback port 80 timeout 300 check tcp
:}
:# END
:
:
:
:# relayd -vvd
:startup
:socket_rlimit: max open files 1024
:socket_rlimit: max open files 1024
:socket_rlimit: max open files 1024
:warning: macro 'http_port' not used
:socket_rlimit: max open files 1024
:warning: macro 'https_port' not used
:socket_rlimit: max open files 1024
:socket_rlimit: max open files 1024
:relay_privinit: adding relay www_a_com
:protocol -1: name default
:flags: used, relay flags:
:type: tcp
:relay_privinit: adding relay www_b_com
:protocol -1: name default
:flags: used, relay flags:
:type: tcp
:relay_privinit: adding relay www_c_com
:protocol -1: name default
:flags: used, relay flags:
:type: tcp
:relay_privinit: adding relay www_d_com
:protocol -1: name default
:flags: used, relay flags:
:type: tcp
:adding 1 hosts from table www_a:80
:relay_launch: running relay www_a_com
:adding 1 hosts from table www_b:80
:relay_launch: running relay www_b_com
:adding 1 hosts from table www_c:80
:adding 1 hosts from table www_a:80
:relay_launch: running relay www_c_com
:adding 1 hosts from table www_d:80
:relay_launch: running relay www_d_com
:relay_launch: running relay www_a_com
:adding 1 hosts from table www_b:80
:relay_launch: running relay www_b_com
:adding 1 hosts from table www_c:80
:relay_launch: running relay www_c_com
:adding 1 hosts from table www_d:80
:relay_launch: running relay www_d_com
:adding 1 hosts from table www_a:80
:relay_launch: running relay www_a_com
:adding 1 hosts from table www_b:80
:adding 1 hosts from table www_a:80
:relay_launch: running relay www_b_com
:relay_launch: running relay www_a_com
:adding 1 hosts from table www_b:80
:adding 1 hosts from table www_c:80
:relay_launch: running relay www_c_com
:relay_launch: running relay www_b_com
:adding 1 hosts from table www_d:80
:adding 1 hosts from table www_c:80
:relay_launch: running relay www_d_com
:relay_launch: running relay www_c_com
:adding 1 hosts from table www_d:80
:relay_launch: running relay www_d_com
:adding 1 hosts from table www_a:80
:relay_launch: running relay www_a_com
:adding 1 hosts from table www_b:80
:relay_launch: running relay www_b_com
:adding 1 hosts from table www_c:80
:relay_launch: running relay www_c_com
:adding 1 hosts from table www_d:80
:relay_launch: running relay www_d_com
:hce_notify_done: 172.20.30.133 (http code ok)
:host 172.20.30.133, check http code (2ms), state unknown - up, availability
:100.00%
:hce_notify_done: 172.20.30.137 (http code ok)
:host 172.20.30.137, check http code (2ms), state unknown - up, availability
:100.00%
:hce_notify_done: 172.20.30.142 (http code ok)
:host 172.20.30.142, check http code (2ms), state unknown - up, availability
:100.00%
:fatal: pfe_dispatch_imsg: invalid host id
:hce exiting, pid 28386
:lost child: hce exited okay
:lost child: pfe exited abnormally
:relay exiting, pid 672
:relay exiting, pid 13247
:relay exiting, pid 30099
:relay exiting, pid 11566
:relay exiting, pid 16851
:parent terminating, pid 28820
:
--
Everyone is a genius. It's just that
Only the first nameserver entry in resolv.conf is being queried
Hi misc'ers, I have customised dhclient.conf so I can use nameservers other than my ISP's. The first one on my list is unreliable, but instead of going to the next on the list, ping, xxxterm and firefox are not finding the sites (ie DNS queries are not being answered). I am running Aug 14 -current, amd64. The man page for resolv.conf says Up to MAXNS (currently 3) name servers may be listed, one per line. If there are multiple servers, the resolver library queries them in the order listed. If no nameserver entries are present, the default is to use the name server on the local machine. (The algorithm used is to try a name server, and if the query times out, try the next, until out of name servers, then repeat trying all name servers until a maximum number of retries are performed.) But this is not what seems to happen. --- My /etc/dhclient.conf: # $OpenBSD: dhclient.conf,v 1.2 2011/04/04 11:14:52 krw Exp $ # DHCP Client Configuration supersede domain-name-servers 208.71.35.137, 84.22.100.250, 67.212.90.199; When I run dhclient, it generates this file in /etc/resolv.conf: nameserver 208.71.35.137 nameserver 84.22.100.250 nameserver 67.212.90.199 --- The nameserver at 208.71.35.137 does not seem to be returning DNS queries with the above resolv.conf configuration. If I try to ping, I get: # ping unsw.edu.au ping: unknown host: unsw.edu.au # ping ucla.edu ping: unknown host: ucla.edu Also xxxterm and firefox could not find web pages. eg, xxxterm says: Unable to load page Problem occurred while loading the URL http://public-root.com/root-server-locations.htm Cannot resolve hostname (public-root.com) (Although one time the page did load - presumably the 208.71.35.137 server came online for a few seconds then back offline again). - If I comment out the first line of the above resolv.conf, I get: # ping unsw.edu.au PING unsw.edu.au (149.171.96.60): 56 data bytes 64 bytes from 149.171.96.60: icmp_seq=0 ttl=239 time=201.043 ms ... --- unsw.edu.au ping statistics --- 3 packets transmitted, 3 packets received, 0.0% packet loss round-trip min/avg/max/std-dev = 201.043/201.212/201.372/0.535 ms # ping ucla.edu PING ucla.edu (169.232.33.224): 56 data bytes 64 bytes from 169.232.33.224: icmp_seq=0 ttl=48 time=48.711 ms --- ucla.edu ping statistics --- 1 packets transmitted, 1 packets received, 0.0% packet loss round-trip min/avg/max/std-dev = 48.711/48.711/48.711/0.000 ms - This looks to me like if the first nameserver is not responding, the next on the list is ignored. I looked at the mailing lists and a bunch of man pages: dhclient.conf, dhclient-script, gethostbyname, resolver, resolv.conf, and dhclient and could not see a way to change this behaviour. Am I misinterpreting what is happening when the pings are not finding the hosts, or doing something wrong in my config? Thanks, Brett.
Nuovo messaggio
Benvenuto nel piC9 completo Midi Professionale e supporto mp3 del sito Internet. Con migliaia di Midi top e canzoni mp3. Siete nel posto giusto !! WWW.GIGAMUSIC.EU Midi canzoni Italiane e straniere Musica nuova2011 Cucina italiana Video diversi tutto su www.gigamusic.eu GRAZIE PER LA VOSTRA VISITA E BUONA NAVIGAZIONE!!!
PF tcp sessions/s rate evaluation
Hello everyone, I'm currently a master degree student, and I'd like to benchmark packet filter over the number of tcp sessions per seconds it can handle. So I've got a very basic setup working, consisting of one server running OpenBSD 4.9 with PF (acting as firewall-router), and 2 PC's running Linux, acting respectively as client and webserver (running apache2 for the last). Basically, the client spams standard HTTP requests to the server via the firewall using a basic HTTP injector tool and evaluates the number of sucessful processed requests per seconds. As one can expect, there is an inverse relationship between the number of sessions/s a firewall can sustain and the size of the object of the request. To achieve maximum throughput, you've got to request big size objects (i.e 50KB or more), whereas to achieve maximum sessions rate per second, you've got to make requests with 0 size objects. Prior to this, I've run some tests with a Linux firewall running iptables, and I've come up with an average rate of 11300 sessions/s for 0 size objects (straight up results, no tweaks or improvements made). Moving on to the OpenBSD tests, I only achieved an average rate of 7000 sessions/s for 0 size object (starting up at 8000, slowly decreasing to 7000 - 6500 ...), which is way above the linux/iptables average rate . I then tried to make some tweaks in /etc/sysctl.conf, but no improvement so far. The ruleset I use is the following (copied from the OpenBSD pf tutorial) : set block-policy drop pass out quick pass in on $WAN inet proto tcp port 80 rdr-to $HTTP_SERVER_IP pass in inet proto icmp all pass in on $LAN. So I come here now to know whether you guys have any idea what sort of tweaks I could try to significantly enhance the number of tcp sessions per seconds processed by PF. I'm kind of a PF newbie, so I'm clueless for the moment . Any hints, thoughts or ideas is appreciated !
Re: relayd problems
Typos from me removing the real IP addresses, they were not in there when I
ran the actual test.
-James
-Original Message-
From: owner-m...@openbsd.org [mailto:owner-m...@openbsd.org] On Behalf Of
David Hill
Sent: Tuesday, August 16, 2011 12:18 PM
To: misc@openbsd.org
Subject: Re: relayd problems
What are the spaces in the IP addresses?
On Tue, Aug 16, 2011 at 11:46:26AM -0500, James Flom wrote:
:Hi all,
:
:Using a snapshot from Aug 1st I can't get more than one of these relays to
run :at the same time with the fallback forward to in there, but up to 3 at
once :with that line removed from each relay, with 4 relays though it always
fails.
:Any idea if this is a bug or configuration issue?
:
:Thanks,
:-James
:
:Relayd.conf
:# Macros
:http_port=80
:https_port=443
:
:# Define server/service macros
:include /etc/relays/hosts.conf
:
:# Global Configuration
:interval 20
:timeout 200
:prefork 10
:log updates
:
:# failover table
:table fallback disable { 10.1.0.20 retry 2 }
:
:include /etc/relays/relays.conf
:# END
:
:
:hosts.conf (/etc/relays/hosts.conf)
:# www_a
:www_a_ext=10. 0.0.193
:www_a_01_int=172.20.30.137
:table www_a { $www_a_01_int }
:
:# www_b
:www_b_ext=10.0.0.194
:www_b_01_int=172.20.30.133
:table www_b { $www_b_01_int }
:
:# www_c
:www_c_ext=10. 0.0.200
:www_c_01_int=172.20.30.140
:table www_c { $www_c_01_int }
:
:# www_d
:www_d_ext=10. 0.0.195
:www_d_01_int=172.20.30.142
:table www_d { $www_d_01_int }
:# END
:
:
:relays.conf (/etc/relays/relays.conf)
:# www_a
:relay www_a_com {
:listen on $www_a_ext port 80
:forward to www_a port 80 check http / code 200
:forward to fallback port 80 timeout 300 check tcp
:}
:
:# www_b
:relay www_b_com {
:listen on $www_b_ext port 80
:forward to www_b port 80 check http / code 200
:forward to fallback port 80 timeout 300 check tcp
:}
:
:# www_c
:relay www_c_com {
:listen on $www_c_ext port 80
:forward to www_c port 80 check http / code 200
:forward to fallback port 80 timeout 300 check tcp
:}
:
:# www_d
:relay www_d_com {
:listen on $www_d_ext port 80
:forward to www_d port 80 check http / code 200
:forward to fallback port 80 timeout 300 check tcp
:}
:# END
:
:
:
:# relayd -vvd
:startup
:socket_rlimit: max open files 1024
:socket_rlimit: max open files 1024
:socket_rlimit: max open files 1024
:warning: macro 'http_port' not used
:socket_rlimit: max open files 1024
:warning: macro 'https_port' not used
:socket_rlimit: max open files 1024
:socket_rlimit: max open files 1024
:relay_privinit: adding relay www_a_com
:protocol -1: name default
:flags: used, relay flags:
:type: tcp
:relay_privinit: adding relay www_b_com
:protocol -1: name default
:flags: used, relay flags:
:type: tcp
:relay_privinit: adding relay www_c_com
:protocol -1: name default
:flags: used, relay flags:
:type: tcp
:relay_privinit: adding relay www_d_com
:protocol -1: name default
:flags: used, relay flags:
:type: tcp
:adding 1 hosts from table www_a:80
:relay_launch: running relay www_a_com
:adding 1 hosts from table www_b:80
:relay_launch: running relay www_b_com
:adding 1 hosts from table www_c:80
:adding 1 hosts from table www_a:80
:relay_launch: running relay www_c_com
:adding 1 hosts from table www_d:80
:relay_launch: running relay www_d_com
:relay_launch: running relay www_a_com
:adding 1 hosts from table www_b:80
:relay_launch: running relay www_b_com
:adding 1 hosts from table www_c:80
:relay_launch: running relay www_c_com
:adding 1 hosts from table www_d:80
:relay_launch: running relay www_d_com
:adding 1 hosts from table www_a:80
:relay_launch: running relay www_a_com
:adding 1 hosts from table www_b:80
:adding 1 hosts from table www_a:80
:relay_launch: running relay www_b_com
:relay_launch: running relay www_a_com
:adding 1 hosts from table www_b:80
:adding 1 hosts from table www_c:80
:relay_launch: running relay www_c_com
:relay_launch: running relay www_b_com
:adding 1 hosts from table www_d:80
:adding 1 hosts from table www_c:80
:relay_launch: running relay www_d_com
:relay_launch: running relay www_c_com
:adding 1 hosts from table www_d:80
:relay_launch: running relay www_d_com
:adding 1 hosts from table www_a:80
:relay_launch: running relay www_a_com
:adding 1 hosts from table www_b:80
:relay_launch: running relay www_b_com
:adding 1 hosts from table www_c:80
:relay_launch: running relay www_c_com
:adding 1 hosts from table www_d:80
:relay_launch: running relay www_d_com
:hce_notify_done: 172.20.30.133 (http code ok) :host 172.20.30.133, check http
code (2ms), state unknown - up, availability :100.00%
:hce_notify_done: 172.20.30.137 (http code ok) :host 172.20.30.137, check http
code (2ms), state unknown - up, availability :100.00%
:hce_notify_done: 172.20.30.142 (http code ok) :host 172.20.30.142, check http
code (2ms), state unknown - up, availability :100.00%
:fatal: pfe_dispatch_imsg:
Re: strange X problem after Aug11 snapshot
On Tue, Aug 16, 2011 at 4:54 PM, Thomas Pfaff tpf...@tp76.info wrote:
dsp told me he had rebuilt devel/sdl with three patches removed and
this made the problem go away. I did what he did and it solved the
problem for me too (amd64 Aug 7 snapshot -- dmesg in previous post).
The patches removed are patch-src_video_x11_SDL_x11{sym_h,video_[ch]}
They're the latest patches in the port dated 2011/05/13 and deal with
XRandR and VidMode.
Yes, it's a patch that was added to have working brightness regulation
with openarena.
I confirm the buggy behaviour with 'mplayer -vo sdl' on amd64 and that
removing those patches fixes the issue.
Thinking back a few snapshots I believe it was around this time that
I first saw ffplay fail in this way, but I made no real notice about
it since I rarely use it and xine and mplayer worked fine anyway.
Thanks to dsp for sharing. Now I can play with qemu again ;-)
Thanks.
I think that commit should be reverted...
Ciao,
David
Re: Only the first nameserver entry in resolv.conf is being queried
On Tue, Aug 16, 2011 at 12:05 PM, Brett brett.ma...@gmx.com wrote: I have customised dhclient.conf so I can use nameservers other than my ISP's. The first one on my list is unreliable, but instead of going to the next on the list, ping, xxxterm and firefox are not finding the sites (ie DNS queries are not being answered). When I run dhclient, it generates this file in /etc/resolv.conf: nameserver 208.71.35.137 nameserver 84.22.100.250 nameserver 67.212.90.199 The nameserver at 208.71.35.137 does not seem to be returning DNS queries with the above resolv.conf configuration. If I try to ping, I get: # ping unsw.edu.au ping: unknown host: unsw.edu.au # ping ucla.edu ping: unknown host: ucla.edu Also xxxterm and firefox could not find web pages. eg, xxxterm says: Unable to load page Problem occurred while loading the URL http://public-root.com/root-server-locations.htm Cannot resolve hostname (public-root.com) (Although one time the page did load - presumably the 208.71.35.137 server came online for a few seconds then back offline again). If I comment out the first line of the above resolv.conf, I get: # ping unsw.edu.au PING unsw.edu.au (149.171.96.60): 56 data bytes 64 bytes from 149.171.96.60: icmp_seq=0 ttl=239 time=201.043 ms # ping ucla.edu PING ucla.edu (169.232.33.224): 56 data bytes 64 bytes from 169.232.33.224: icmp_seq=0 ttl=48 time=48.711 ms This looks to me like if the first nameserver is not responding, the next on the list is ignored. I looked at the mailing lists and a bunch of man pages: dhclient.conf, dhclient-script, gethostbyname, resolver, resolv.conf, and dhclient and could not see a way to change this behaviour. Am I misinterpreting what is happening when the pings are not finding the hosts, or doing something wrong in my config? A quick dig @208.71.35.137 shows it is responding, but not providing an answer. I imagine if 208.71.35.137 was not responding at all, resolv.conf would behave as expected.
Re: PF tcp sessions/s rate evaluation
On 2011-08-16, Quentin Aebischer quentin.aebisc...@usherbrooke.ca wrote: Hello everyone, I'm currently a master degree student, and I'd like to benchmark packet filter over the number of tcp sessions per seconds it can handle. So I've got a very basic setup working, consisting of one server running OpenBSD 4.9 with PF (acting as firewall-router), and 2 PC's running Linux, acting respectively as client and webserver (running apache2 for the last). Basically, the client spams standard HTTP requests to the server via the firewall using a basic HTTP injector tool and evaluates the number of sucessful processed requests per seconds. As one can expect, there is an inverse relationship between the number of sessions/s a firewall can sustain and the size of the object of the request. To achieve maximum throughput, you've got to request big size objects (i.e 50KB or more), whereas to achieve maximum sessions rate per second, you've got to make requests with 0 size objects. Prior to this, I've run some tests with a Linux firewall running iptables, and I've come up with an average rate of 11300 sessions/s for 0 size objects (straight up results, no tweaks or improvements made). Moving on to the OpenBSD tests, I only achieved an average rate of 7000 sessions/s for 0 size object (starting up at 8000, slowly decreasing to 7000 - 6500 ...), which is way above the linux/iptables average rate . I then tried to make some tweaks in /etc/sysctl.conf, but no improvement so far. The ruleset I use is the following (copied from the OpenBSD pf tutorial) : set block-policy drop pass out quick pass in on $WAN inet proto tcp port 80 rdr-to $HTTP_SERVER_IP pass in inet proto icmp all pass in on $LAN. So I come here now to know whether you guys have any idea what sort of tweaks I could try to significantly enhance the number of tcp sessions per seconds processed by PF. I'm kind of a PF newbie, so I'm clueless for the moment . Any hints, thoughts or ideas is appreciated ! Make sure your state limits are high enough (set limits states XX; default is 1). Also check sysctl net.inet.ip.ifq; if there are drops then you may want to gradually increase net.inet.ip.ifq.maxlen Note that the ruleset you have shown does not block anything (default if there is *no* matching rule at all is to statelessly pass a packet).
Re: PF tcp sessions/s rate evaluation
There is not much to tweak, performance-wise. OpenBSD avoids such buttons like the plague, and besides: benchmarks should be run with a stock install, which is what 99% of users are going to be doing as well. You can try looking at the output of 'pfctl -si' and see if any of those is increasing a lot, it may give you some more hints. The only thing that jumps to mind is the states limit; if it's getting hit you'll see the memory counter increase. I can't make any suggestion for a good value for 'set limit states' though because you included zero information about the hardware you're testing on. On Tue, Aug 16, 2011 at 02:12:01PM -0400, Quentin Aebischer wrote: Hello everyone, I'm currently a master degree student, and I'd like to benchmark packet filter over the number of tcp sessions per seconds it can handle. So I've got a very basic setup working, consisting of one server running OpenBSD 4.9 with PF (acting as firewall-router), and 2 PC's running Linux, acting respectively as client and webserver (running apache2 for the last). Basically, the client spams standard HTTP requests to the server via the firewall using a basic HTTP injector tool and evaluates the number of sucessful processed requests per seconds. As one can expect, there is an inverse relationship between the number of sessions/s a firewall can sustain and the size of the object of the request. To achieve maximum throughput, you've got to request big size objects (i.e 50KB or more), whereas to achieve maximum sessions rate per second, you've got to make requests with 0 size objects. Prior to this, I've run some tests with a Linux firewall running iptables, and I've come up with an average rate of 11300 sessions/s for 0 size objects (straight up results, no tweaks or improvements made). Moving on to the OpenBSD tests, I only achieved an average rate of 7000 sessions/s for 0 size object (starting up at 8000, slowly decreasing to 7000 - 6500 ...), which is way above the linux/iptables average rate . I then tried to make some tweaks in /etc/sysctl.conf, but no improvement so far. The ruleset I use is the following (copied from the OpenBSD pf tutorial) : set block-policy drop pass out quick pass in on $WAN inet proto tcp port 80 rdr-to $HTTP_SERVER_IP pass in inet proto icmp all pass in on $LAN. So I come here now to know whether you guys have any idea what sort of tweaks I could try to significantly enhance the number of tcp sessions per seconds processed by PF. I'm kind of a PF newbie, so I'm clueless for the moment . Any hints, thoughts or ideas is appreciated ! --
Re: pf shape download
It would be easier to look for what's wrong if you include the whole ruleset On 2011-08-16, Michel Blais mic...@targointernet.com wrote: I'm having a problem to shape download with PF. I have 2 HFSC queue (main and second) created on my internal NIC. Main is my default queue. If I try to match download traffic to the second queue, it still go trought the main queue. The IP I want to download trought the second queue for my test unit is 10.254.200.2 $ext_if=re0 $int_if=re1 My rule to foward traffic to second queue is : match out on $int_if from any to 10.254.200.2 I also try with pass instead of match Look fine if I check the bob exemple in this faq : http://www.openbsd.org/faq/pf/queueing.html#example1 pfctl -vvsq still show traffic on main queue : queue main on re1 bandwidth 1Mb priority 2 qlimit 100 hfsc( red default upperlimit 97Mb ) [ pkts: 24701 bytes: 37333295 dropped pkts: 0 bytes: 0 ] [ qlength: 0/100 ] [ measured: 236.4 packets/s, 2.86Mb/s ] queue second on re1 bandwidth 1Mb priority 0 qlimit 250 hfsc( red upperlimit 97Mb ) [ pkts: 0 bytes: 0 dropped pkts: 0 bytes: 0 ] [ qlength: 0/250 ] [ measured: 0.0 packets/s, 0 b/s ] pftop -v rules show me that the rule don't match 12 Pass out re1 K 0 0 0 inet from any to 10.254.200.2/32flags S/SA queue second I can see my download with tcpdump : # tcpdump -i re1 host 10.254.200.2 ... 10:49:19.802505 10.254.200.2.49266 hammurabi.acc.umu.se.www: . ack 832200 win 64240 (DF) 10:49:19.802716 hammurabi.acc.umu.se.www 10.254.200.2.49266: . 832200:833660(1460) ack 1 win 6564 (DF) 10:49:19.802911 hammurabi.acc.umu.se.www 10.254.200.2.49266: . 833660:835120(1460) ack 1 win 6564 (DF) 10:49:19.803040 hammurabi.acc.umu.se.www 10.254.200.2.49266: . 835120:836580(1460) ack 1 win 6564 (DF) 10:49:19.803211 10.254.200.2.49266 hammurabi.acc.umu.se.www: . ack 836580 win 64240 (DF) 10:49:19.803248 hammurabi.acc.umu.se.www 10.254.200.2.49266: . 836580:838040(1460) ack 1 win 6564 (DF) 10:49:19.803252 hammurabi.acc.umu.se.www 10.254.200.2.49266: . 838040:839500(1460) ack 1 win 6564 (DF) 10:49:19.803367 hammurabi.acc.umu.se.www 10.254.200.2.49266: . 839500:840960(1460) ack 1 win 6564 (DF) ... I have pass days on this with OpenBSD 4.9 and FreeBSD 8.2 without result. I even tryed every 8 possible rules at the same time and pfctl was still showing traffic trought the main queue on : match in on re0 from any to 10.254.200.2 queue second match in on re1 from any to 10.254.200.2 queue second match out on re0 from any to 10.254.200.2 queue second match out on re0 from any to 10.254.200.2 queue second match in on re0 from 10.254.200.2 to any queue second match in on re1 from 10.254.200.2 to any queue second match out on re0 from 10.254.200.2 to any queue second match out on re0 from 10.254.200.2 to any queue second in this case, pftop was showing that it match out on re0 from 10.254.200.2 to any match on re1 from 10.254.200.2 to any it look like only upload rule match Can somebody help me on this ? Thanks Michel P.S : I have a VoIP queue that I will add after that will need the realtime option, that why I'm using HFSC.
OpenBSD 4.9 + Sound Blaster Live!
Hey everyone, I have a question about the emu driver and a sound blaster live. I'm trying to make my sound card work under OpenBSD 4.9, and have managed only to get a bunch of white noise coming through the front speakers. Does anyone have any experience with this card, and if so, would you like to share some configuration tips? :) I've been reading the Multimedia section of the OpenBSD documentation, have made sure to unmute my card and set the master volume level, but I can't get this working. I should also mention that I am VERY new to sound on OpenBSD :-P Thanks! James
Re: Only the first nameserver entry in resolv.conf is being queried
From: Brett brett.ma...@gmx.com To: Daniel Melameth dan...@melameth.com Subject: Re: Only the first nameserver entry in resolv.conf is being queried Date: Tue, 16 Aug 2011 16:46:15 -0700 X-Mailer: Sylpheed 3.1.1 (GTK+ 2.24.5; x86_64-unknown-openbsd5.0) nameserver 208.71.35.137 nameserver 84.22.100.250 nameserver 67.212.90.199 The nameserver at 208.71.35.137 does not seem to be returning DNS queries with the above resolv.conf configuration. On Tue, 16 Aug 2011 13:16:02 -0600 Daniel Melameth dan...@melameth.com wrote: A quick dig @208.71.35.137 shows it is responding, but not providing an answer. I imagine if 208.71.35.137 was not responding at all, resolv.conf would behave as expected. I just tried a putting a couple of random IP addresses as the first nameserver on the list, and now resolv.conf is indeed going through the list when the first one fails to give an answer. Thanks, Daniel! Brett.
Re: PF tcp sessions/s rate evaluation
Thx for the reply. Well I've already increased the state table size to 15 entries, 1 was not enough (there was up to 7 simultaneous state entries during the test). Hardware wise, I'm using a xeon 2.4 GHz monocore with 1 GB of RAM. Since this server is used as firewall only, I've raised the kernel space memory to up to 90% of total memory. I don't want to make hasty conclusion, so I'll keep searching.. Ryan McBride mcbr...@openbsd.org a C)critB : There is not much to tweak, performance-wise. OpenBSD avoids such buttons like the plague, and besides: benchmarks should be run with a stock install, which is what 99% of users are going to be doing as well. You can try looking at the output of 'pfctl -si' and see if any of those is increasing a lot, it may give you some more hints. The only thing that jumps to mind is the states limit; if it's getting hit you'll see the memory counter increase. I can't make any suggestion for a good value for 'set limit states' though because you included zero information about the hardware you're testing on. On Tue, Aug 16, 2011 at 02:12:01PM -0400, Quentin Aebischer wrote: Hello everyone, I'm currently a master degree student, and I'd like to benchmark packet filter over the number of tcp sessions per seconds it can handle. So I've got a very basic setup working, consisting of one server running OpenBSD 4.9 with PF (acting as firewall-router), and 2 PC's running Linux, acting respectively as client and webserver (running apache2 for the last). Basically, the client spams standard HTTP requests to the server via the firewall using a basic HTTP injector tool and evaluates the number of sucessful processed requests per seconds. As one can expect, there is an inverse relationship between the number of sessions/s a firewall can sustain and the size of the object of the request. To achieve maximum throughput, you've got to request big size objects (i.e 50KB or more), whereas to achieve maximum sessions rate per second, you've got to make requests with 0 size objects. Prior to this, I've run some tests with a Linux firewall running iptables, and I've come up with an average rate of 11300 sessions/s for 0 size objects (straight up results, no tweaks or improvements made). Moving on to the OpenBSD tests, I only achieved an average rate of 7000 sessions/s for 0 size object (starting up at 8000, slowly decreasing to 7000 - 6500 ...), which is way above the linux/iptables average rate . I then tried to make some tweaks in /etc/sysctl.conf, but no improvement so far. The ruleset I use is the following (copied from the OpenBSD pf tutorial) : set block-policy drop pass out quick pass in on $WAN inet proto tcp port 80 rdr-to $HTTP_SERVER_IP pass in inet proto icmp all pass in on $LAN. So I come here now to know whether you guys have any idea what sort of tweaks I could try to significantly enhance the number of tcp sessions per seconds processed by PF. I'm kind of a PF newbie, so I'm clueless for the moment . Any hints, thoughts or ideas is appreciated ! --
Group ownership of files at creation time
Hello list. I have a question about the following observed behavior. Let's assume that a user (user_a) belongs to two groups (group_a and group_b.) The user creates a directory called testdir and the ownership permissions are user_a:group_a after the directory is made. The user runs: chown user_a:group_b testdir to change the group ownership to the user's secondary group. When the user changes to the new directory and creates a new file with touch test the new file is created with the following ownership permissions: user_a:group_b On most of the unix / unix-like systems I support, this behavior would be different. The file would be created with user_a:group_a (since group_a is the primary group.) This is true on AIX, Solaris, Linux, and HP-UX per my testing earlier today. On Tru64 and OpenBSD, the group ownership seems to be inherited by the parent directory rather than set by the user's primary group membership. For AIX et.al. the setgid bit on the parent directory would change the behavior such that files created inside that directory would be owned by the parent directory group owner regardless of user's primary group membership. It appears that OpenBSD (and Tru64) treat the directory as setgid (when compared to the other OSes) but it is not. My question is, is this the expected behavior, and what was the reasoning when deciding to implement it this way if it is (expected behavior?) Also, is there a known way to change this behavior to match the default behavior of AIX and friends? Testing of OpenBSD behavior was performed on version 4.8 running on alpha and 4.9 running in qemu emulating i386. Testing was done on mount points with no options running other than rw as well as mounts with nodev and nosuid options set. I know this is a small thing, and comparing OpenBSD to the other systems is kind of moot, I only bring this up because I'm trying to grasp the reasoning for this behavior. Thank you for any responses, Stefan Johnson
Re: PF tcp sessions/s rate evaluation
Just to clarify a bit, I would not be surprised if IPTables performs more quickly than PF in this particular test, for a couple of reasons: - PF uses a red-black tree for the session tracking, while iptables uses a hash table. The red-black tree means performance scales smoothly as the number of sessions increases (and avoids attacks on individual hash buckets), see http://www.benzedrine.cx/pf-paper.html for details, but the insert/delete cost is higher, which is what you're probably seeing here. - PF does full TCP session checking by default (verifying TCP sequence numbers, etc). You could try testing with 'sloppy' state tracking to see if this makes a difference (NOT recommended in production unless you know what you're doing, so please don't report such results in a performance comparison). One problem with the test setup you've described (doing rdr-to for the session to the webserver) is that you can't repeat the tests without the firewall enabled to determine if it's a PF vs. iptables difference or just an OpenBSD vs. Linux difference. Also, if you post a dmesg of the system you're using and tell us what interfaces $WAN and $LAN are, we can check you're not doing tests with some ghastly network cards... I don't know what knob you've twisted to raise the kernel space memory, but such things are not recommended and I would prefer for you to report worse results with a non-tweaked install than report a bunch of settings that shouldn't be touched. In general, the design goals of PF go somewhat in the following order (I'll admit that we have a lot of work to do still on #2 in some areas of PF): 1) Free software 2) Correct, readable code 3) Secure, robust packet filtering 4) Flexible but simple to use 5) Good performance I don't think anyone here cares much if iptables is 'faster' as long as we're ahead on the first 4 items above. We already have enough fast, insecure systems. -- Bruce Schneier On Tue, Aug 16, 2011 at 08:16:02PM -0400, Quentin Aebischer wrote: Thx for the reply. Well I've already increased the state table size to 15 entries, 1 was not enough (there was up to 7 simultaneous state entries during the test). Hardware wise, I'm using a xeon 2.4 GHz monocore with 1 GB of RAM. Since this server is used as firewall only, I've raised the kernel space memory to up to 90% of total memory. I don't want to make hasty conclusion, so I'll keep searching.. Ryan McBride mcbr...@openbsd.org a C)critB : There is not much to tweak, performance-wise. OpenBSD avoids such buttons like the plague, and besides: benchmarks should be run with a stock install, which is what 99% of users are going to be doing as well. You can try looking at the output of 'pfctl -si' and see if any of those is increasing a lot, it may give you some more hints. The only thing that jumps to mind is the states limit; if it's getting hit you'll see the memory counter increase. I can't make any suggestion for a good value for 'set limit states' though because you included zero information about the hardware you're testing on. On Tue, Aug 16, 2011 at 02:12:01PM -0400, Quentin Aebischer wrote: Hello everyone, I'm currently a master degree student, and I'd like to benchmark packet filter over the number of tcp sessions per seconds it can handle. So I've got a very basic setup working, consisting of one server running OpenBSD 4.9 with PF (acting as firewall-router), and 2 PC's running Linux, acting respectively as client and webserver (running apache2 for the last). Basically, the client spams standard HTTP requests to the server via the firewall using a basic HTTP injector tool and evaluates the number of sucessful processed requests per seconds. As one can expect, there is an inverse relationship between the number of sessions/s a firewall can sustain and the size of the object of the request. To achieve maximum throughput, you've got to request big size objects (i.e 50KB or more), whereas to achieve maximum sessions rate per second, you've got to make requests with 0 size objects. Prior to this, I've run some tests with a Linux firewall running iptables, and I've come up with an average rate of 11300 sessions/s for 0 size objects (straight up results, no tweaks or improvements made). Moving on to the OpenBSD tests, I only achieved an average rate of 7000 sessions/s for 0 size object (starting up at 8000, slowly decreasing to 7000 - 6500 ...), which is way above the linux/iptables average rate . I then tried to make some tweaks in /etc/sysctl.conf, but no improvement so far. The ruleset I use is the following (copied from the OpenBSD pf tutorial) : set block-policy drop pass out quick pass in on $WAN inet proto tcp port 80 rdr-to $HTTP_SERVER_IP pass in inet proto icmp all pass in on $LAN. So I come here now to know whether you guys have any idea what sort of tweaks I could
Re: PF tcp sessions/s rate evaluation
Thx for the reply. Well I've already increased the state table size to 15 entries, 1 was not enough (there was up to 7 simultaneous state entries during the test). Hardware wise, I'm using a xeon 2.4 GHz monocore with 1 GB of RAM. Since this server is used as firewall only, I've raised the kernel space memory to up to 90% of total memory. I don't want to make hasty conclusion, so I'll keep searching.. Regardiing this last bit. REALLY! How did you do that? I'd love to know. Whatever you did does not do what you think it does. In fact, I bet it is doing exactly the opposite of what you think it does.
Re: Group ownership of files at creation time
S_ISGID bits on a directory are meaningful in sysv, whereas on bsd open(2) acts as if they were always on
Re: Group ownership of files at creation time
On Tue, Aug 16, 2011, Stefan Johnson wrote: On most of the unix / unix-like systems I support, this behavior would be different. The file would be created with user_a:group_a (since group_a is the primary group.) This is true on AIX, Solaris, Linux, and HP-UX per my testing earlier today. On Tru64 and OpenBSD, the group ownership seems to be inherited by the parent directory rather than set by the user's primary group membership. For AIX et.al. the setgid bit on the parent directory would change the behavior such that files created inside that directory would be owned by the parent directory group owner regardless of user's primary group membership. It appears that OpenBSD (and Tru64) treat the directory as setgid (when compared to the other OSes) but it is not. BSD derived systems always have the setgid directory behavior. The rationale is that if you have users sharing a directory, this is the behavior you want and you shouldn't need to remember to chmod every directory created, especially since you may not be creating directories by hand.
Relayd + pf redirect external ip address + domain name - invalid virtual ip
We've been using pf for a number of years with one pf firewall serving
multiple backend servers (i.e. Load-balanced web farm). Now we've added more
backend servers with their own external ip addresses. It seems a waste to
have one firewall for low volume, specialized sites, forwarding to only one
set of servers only.
We're trying to have the same OpenBSD server redirect traffic based on the
external ip address.
What we're having difficulty with right now is getting relayd and pf to
redirect the same ports, example 80 443 to different backend servers based
on external ip (and domain name). It does work on ip address but not domain
names.
In pf...
We have a relayd anchors where pf will forward based on tagged names.
Nothing special here. Pf filters port range 81:442, only directing 80 443
to 443 (always) to the specified internal server or farm based on the
tagged name
The following works in relayd.conf when the ip addresses are specified (most
macro's and tables have been removed for clarity
redirect webone{
listen on 1.2.3.4 port 80:443 interface $ext_if
tag tag_one
forward to int_ipone port 443 check tcp
}
redirect web2{
listen on 2.3.4.5 port 80:443 interface $ext_if
tag tag_two
forward to int_iptwo port 443 check tcp
}
The following does not work
redirect webone{
listen on sub.sub.domain1.com port 80:443 interface $ext_if
tag tag_one
forward to int_ipone port 443 check tcp
}
redirect web2{
listen on $sub.sub.domain2.com port 80:443 interface $ext_if
tag tag_two
forward to int_iptwo port 443 check tcp
}
When this is entered, relayd -d -vv -f /etc/relayd.conf will complain that
these listen lines have invalid virtual ip
Am I missing something crucial here? Or is this simply a limitation of the
technology?
Any suggestions or working examples would be greatly appreciated.
Q@Q
Re: Group ownership of files at creation time
On Tue, Aug 16, 2011 at 11:09 PM, Ted Unangst t...@tedunangst.com wrote: On Tue, Aug 16, 2011, Stefan Johnson wrote: On most of the unix / unix-like systems I support, this behavior would be different. The file would be created with user_a:group_a (since group_a is the primary group.) This is true on AIX, Solaris, Linux, and HP-UX per my testing earlier today. On Tru64 and OpenBSD, the group ownership seems to be inherited by the parent directory rather than set by the user's primary group membership. For AIX et.al. the setgid bit on the parent directory would change the behavior such that files created inside that directory would be owned by the parent directory group owner regardless of user's primary group membership. It appears that OpenBSD (and Tru64) treat the directory as setgid (when compared to the other OSes) but it is not. BSD derived systems always have the setgid directory behavior. The rationale is that if you have users sharing a directory, this is the behavior you want and you shouldn't need to remember to chmod every directory created, especially since you may not be creating directories by hand. Thank you both for the explanation. I thought it might be a BSD vs SysV situation, but I wasn't positive. The reasoning is sound. I appreciate the quick responses! Stefan Johnson
