ngingx+php-fpm issue

2014-03-29 Thread Adam Thompson
I'm trying to install Cacti 0.8.8b from source, on 5.4-RELEASE using 
nginx (from base) + php-fpm-5.3 from packages.
I've got nginx working.
I've got SlowCGI working (now that I realized it's chroot'ed... duh).
I've got PHP-FPM kind of working, but not fully.

Basic things like "" work just fine, but anything 
complex dies with no messages, no errors, no logs, nothing useful, not 
even with debug-level logging enabled.

When I try to retrieve Cacti's default index.php, I see these three 
lines in the log file.
/var/log/php-fpm.log: [30-Mar-2014 00:26:40.168716] DEBUG: pid 22020, 
fpm_pctl_perform_idle_server_maintenance(), line 379: [pool www] 
currently 0 active children, 2 spare children, 2 running children. 
Spawning rate 1
/var/www/log/access.log: 2620:42:c000:1::21 - - [30/Mar/2014:00:26:40 
-0500] "GET /cacti-0.8.8b/index.php HTTP/1.1" 500 5 "-" "Mozilla/5.0 
(X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) 
Chrome/33.0.1750.152 Safari/537.36"
/var/log/php-fpm.log: [30-Mar-2014 00:26:41.178666] DEBUG: pid 22020, 
fpm_pctl_perform_idle_server_maintenance(), line 379: [pool www] 
currently 0 active children, 2 spare children, 2 running children. 
Spawning rate 1

and in the browser window, I see absolutely nothing - no error message, 
no output, nada.

I'm guessing it's not chroot-related, since if I disable chroot, I do 
get some output: "File not found."
I've confirmed that it's not a (obvious) permissions-related problem.

I've turned display_errors on, log_errors on, and catch_workers_output 
on.  What else can I try to find out what php-fpm is trying (and 
presumably failing) to do??  Any other debugging steps I should try?

FYI - I think I have confirmed that PHP Bug #61045 is *not* the culprit, 
as phpinfo() logs some timezone-related warnings.

-- 
-Adam Thompson
  athom...@athompso.net



Re: pf to redirect local dns traffic to another port

2014-03-29 Thread Nick Holland
On 03/29/14 17:09, Stéphane Guedon wrote:
> Hello
> 
> I am currently trying to run two nameserver on the same Openbsd 
> server.
> 
> The first one is an autoritative (let's say bind or nsd, no one cares).
> the second will be dnsmasq.
> 
> You guess the objective of the construction : give local answers from 
> dhcp leases to local requests, and give autoritatives for the internet 
> requests.

you are getting sloppy with terms here.  You aren't being authoritative
for Internet requests -- you are doing recursive resolution.  You are
authoritative on your internal stuff only.

Also...  for -current, BIND has been replaced by NSD and Unbound, so you
might wish to run -current for this project to minimize changes in the
near future.

> That's for the presentation.
> 
> I can run dnsmasq on a different port, but how do I give my local hosts 
> the idea of interrogating a non standard dns port ?
> Then I though I could drive the traffic from my LAN to the port where 
> dnsmasq is running on.

The easier way is to run your DNS resolver on a different IP Address,
not a different port, than your authoritative DNS.  BIND is something of
an address slut, it connects with every address by default, so you will
have to restrict it in the config to just the ports you want.  I don't
recall what NSD/Unbound do by default, but they are at least
configurable to not be stupid and connect up with just the address you
want them to connect to.

So...run your resolver on the external port, run the authoritative on
localhost, configure the resolver to query the authoritative (on
127.0.0.1) for local info, and the general Internet DNS for everything
else.  Your DHCP server populates your authoritative server, your
machines query the external address, and all Just Works.

And remember: if you wish to get more complicated, you can have lots of
localhosts. (127.0.0.2, 127.0.0.3 ...) and attach different services to
each.

Nick.



Re: OpenBGPd - iBGP next-hop translation using IGP (OSPF)

2014-03-29 Thread Andy Lemin
On further thought, using option 1 and randomising the next hop used wouldn't 
provide a very good distribution of load as it would be on a per network route 
basis and not on a per IP basing like proper multipath.
Would also be costly in route look ups etc.

So looks like we would need to use 'maximum-paths n' in OpenBGP to insert 
multiple routes into the kernel FIB and use next-hop-self on the iBGP neighbour 
ASBR routers connecting to the exchange etc, to achieve full load balancing 
across ASBRs.

That would provide a good load distribution but means we also have to wait for 
BFD (Bidirectional Forward Detection) support on BGP to address the convergence 
issues of using next-hop-self.

What do people think?

Thanks for your thoughts :)
Andy 

Sent from my iPhone

> On 29 Mar 2014, at 21:45, Andy  wrote:
> 
> Hi,
> 
> Is OpenBGPD capable of inserting equal cost multi-path routes into the 
> kernel FIB like OpenOSPFD can?
> 
> 
> I have equal cost routes being received into OpenOSPFD's RIB from two 
> different OSPF ASBR neighbors, for accessing the same IXP network to 
> which we are connected. These two multi-path routes are inserted into 
> the Kernel FIB fine.
> If I ping various routers on the IXP network I can see that multi-path 
> is being used and a different ASBR neighbor is used for each IP etc.. 
> Great :)
> 
> [LIVE]root@mg131:~# ospfctl show rib | grep 5.57.80
> 5.57.80.0/22 185.25.30.2   Type 1 ext   Network 21  01w1d09h
> 5.57.80.0/22 185.25.30.1   Type 1 ext   Network 21  01w0d04h
> 
> [LIVE]root@mg131:~# netstat -rn | grep 5.57.80
> 5.57.80/22 185.25.30.2UGP0   42 -32 vlan202
> 5.57.80/22 185.25.30.1UGP0   77 -32 vlan202
> 
> 
> 
> I therefore of course also have equal cost routes being received into 
> OpenBGPD's RIB from the two different iBGP peers (the same two ASBR 
> neighbors as above), for all the networks received via our IXP BGP peerings.
> OpenBGPd by default only selects one path to the remote networks, the 
> nexthop in the IXP network for the path is translated into a directly 
> connected nexthop (using the OSPF routes for the IXP network).
> 
> [LIVE]root@mg131:~# bgpctl show rib | more
> flags: * = Valid, > = Selected, I = via IBGP, A = Announced, S = Stale
> origin: i = IGP, e = EGP, ? = Incomplete
> 
> flags destination  gateway  lpref   med aspath origin
> I*>   1.0.0.0/24   5.57.80.136   1000 0 15169 i
> I*1.0.0.0/24   5.57.80.136   1000 0 15169 i
> I*>   1.0.4.0/24   5.57.80.128100 1 6939 7545 56203 i
> I*1.0.4.0/24   5.57.80.128100 1 6939 7545 56203 i
> I*>   1.0.5.0/24   5.57.80.128100 1 6939 7545 56203 i
> I*1.0.5.0/24   5.57.80.128100 1 6939 7545 56203 i
> .
> .
> 
> [LIVE]root@mg1311:~# netstat -rn | more
> Routing tables
> 
> Internet:
> DestinationGatewayFlags   Refs  Use   Mtu Prio Iface
> 1.0.0/24   185.25.30.2UG 00 -48 vlan2302
> 1.0.4/24   185.25.30.2UG 00 -48 vlan2302
> 1.0.5/24   185.25.30.2UG 00 -48 vlan2302
> .
> .
> 
> However it always chooses the same directly connected ASBR for every 
> route during the next-hop translation step and no load balancing is 
> achieved. :(
> 
> Even if I use 'next-hop-self' on the ASBR's to remove the nexthop 
> translation step, the same ASBR is always chosen (due to BGP best path 
> selection always matching for each route).
> 
> I also don't want to use next-hop-self anyway as that would *destroy* 
> convergence times should an ASBR be unavailable, as in the absence of 
> BFD it would be relying on BGP long timers to change the route, instead 
> of having OSPF's fast convergence to change the next-hop in less than a 
> second.
> 
> 
> From my understanding the only options are;
> 1) Randomize the directly connected nexthop used during in the next-hop 
> translation step.
> 2) Use next-hop-self on the ASBR's to insert two routes into the RIB 
> with different next-hops (one for each ASBR) (requiring BFD for BGP to 
> not destroy convergence), and also enable BGP multi-hop 
> (http://www.cisco.com/c/en/us/support/docs/ip/border-gateway-protocol-bgp/13753-25.html#bgpmpath)
>  
> to insert both RIB routes into the FIB, so the kernel can perform 
> equal-cost multi-path routing.
> 
> 
> Thanks for your time and for reading.
> Cheers, Andy.
> 
> 
> 
> 
> /**/



Re: upgrades no longer allow ftp for sets

2014-03-29 Thread Ted Unangst
On Sat, Mar 29, 2014 at 08:47, Craig R. Skinner wrote:

> 
> Eventually, will base ftpd be removed?

The program (some might say pogrom) to delete old shit doesn't really
need any more suggestions at this time. The situation is well in hand
(some might say out of hand).



Re: pf to redirect local dns traffic to another port

2014-03-29 Thread System Administrator
On 29 Mar 2014 at 22:10, Stéphane Guedon wrote:

> Hello
> 
> I am currently trying to run two nameserver on the same Openbsd 
> server.
> 
> The first one is an autoritative (let's say bind or nsd, no one
> cares).
> the second will be dnsmasq.
> 
> You guess the objective of the construction : give local answers from
> dhcp leases to local requests, and give autoritatives for the internet
> requests.
> 
> That's for the presentation.
> 
> I can run dnsmasq on a different port, but how do I give my local
> hosts 
> the idea of interrogating a non standard dns port ?
> Then I though I could drive the traffic from my LAN to the port where
> dnsmasq is running on.
> 
> so here is pf conf (obviously expurged) :
> 
> ###
> 
> table  { local addresses }
> 
> # common
> pass in log on egress proto { tcp, udp }  from any to re0 port domain
> 
> # local
> pass in quick log on re0 inet proto { udp,tcp }   from  
> port domain rdr-to 127.0.0.1 port 5353

unless I'm severly mistaken (and someone will correct me), the rule as 
written will match only packets whose SOURCE port is domain ... you are 
missing a "to (self)" or "to any" in front of the port specification to 
achieve your objective.

> #pass in quick log on re0 proto { udp,tcp }   from  port 
> domain divert-packet port 5353
> 
> ###
> 
> I first tried to use the divert-packet rule (that way I don't have to
> care if the traffic is ipv6 or ipv4), then I tried to redirect using
> rdr-to 127... like most tutorials I found regarding rdr.
> 
> I move the local rules before or after the common one, place a quick
> on the common or removed it...
> 
> Nothing : the common rule is always the one that applies according to
> the logs.
> Can you tell me what I am doing wrong ?



OpenBGPd - iBGP next-hop translation using IGP (OSPF)

2014-03-29 Thread Andy
Hi,

Is OpenBGPD capable of inserting equal cost multi-path routes into the 
kernel FIB like OpenOSPFD can?


I have equal cost routes being received into OpenOSPFD's RIB from two 
different OSPF ASBR neighbors, for accessing the same IXP network to 
which we are connected. These two multi-path routes are inserted into 
the Kernel FIB fine.
If I ping various routers on the IXP network I can see that multi-path 
is being used and a different ASBR neighbor is used for each IP etc.. 
Great :)

[LIVE]root@mg131:~# ospfctl show rib | grep 5.57.80
5.57.80.0/22 185.25.30.2   Type 1 ext   Network 21  01w1d09h
5.57.80.0/22 185.25.30.1   Type 1 ext   Network 21  01w0d04h

[LIVE]root@mg131:~# netstat -rn | grep 5.57.80
5.57.80/22 185.25.30.2UGP0   42 -32 vlan202
5.57.80/22 185.25.30.1UGP0   77 -32 vlan202



I therefore of course also have equal cost routes being received into 
OpenBGPD's RIB from the two different iBGP peers (the same two ASBR 
neighbors as above), for all the networks received via our IXP BGP peerings.
OpenBGPd by default only selects one path to the remote networks, the 
nexthop in the IXP network for the path is translated into a directly 
connected nexthop (using the OSPF routes for the IXP network).

[LIVE]root@mg131:~# bgpctl show rib | more
flags: * = Valid, > = Selected, I = via IBGP, A = Announced, S = Stale
origin: i = IGP, e = EGP, ? = Incomplete

flags destination  gateway  lpref   med aspath origin
I*>   1.0.0.0/24   5.57.80.136   1000 0 15169 i
I*1.0.0.0/24   5.57.80.136   1000 0 15169 i
I*>   1.0.4.0/24   5.57.80.128100 1 6939 7545 56203 i
I*1.0.4.0/24   5.57.80.128100 1 6939 7545 56203 i
I*>   1.0.5.0/24   5.57.80.128100 1 6939 7545 56203 i
I*1.0.5.0/24   5.57.80.128100 1 6939 7545 56203 i
.
.

[LIVE]root@mg1311:~# netstat -rn | more
Routing tables

Internet:
DestinationGatewayFlags   Refs  Use   Mtu Prio Iface
1.0.0/24   185.25.30.2UG 00 -48 vlan2302
1.0.4/24   185.25.30.2UG 00 -48 vlan2302
1.0.5/24   185.25.30.2UG 00 -48 vlan2302
.
.

However it always chooses the same directly connected ASBR for every 
route during the next-hop translation step and no load balancing is 
achieved. :(

Even if I use 'next-hop-self' on the ASBR's to remove the nexthop 
translation step, the same ASBR is always chosen (due to BGP best path 
selection always matching for each route).

I also don't want to use next-hop-self anyway as that would *destroy* 
convergence times should an ASBR be unavailable, as in the absence of 
BFD it would be relying on BGP long timers to change the route, instead 
of having OSPF's fast convergence to change the next-hop in less than a 
second.


 From my understanding the only options are;
1) Randomize the directly connected nexthop used during in the next-hop 
translation step.
2) Use next-hop-self on the ASBR's to insert two routes into the RIB 
with different next-hops (one for each ASBR) (requiring BFD for BGP to 
not destroy convergence), and also enable BGP multi-hop 
(http://www.cisco.com/c/en/us/support/docs/ip/border-gateway-protocol-bgp/13753-25.html#bgpmpath)
 
to insert both RIB routes into the FIB, so the kernel can perform 
equal-cost multi-path routing.


Thanks for your time and for reading.
Cheers, Andy.




/**/



typo in games/fortunes/datfiles/fortune

2014-03-29 Thread Josh Grosse
Noticed today..


Index: fortunes
===
RCS file: /cvs/src/games/fortune/datfiles/fortunes,v
retrieving revision 1.44
diff -u -r1.44 fortunes
--- fortunes10 Feb 2013 15:21:28 -  1.44
+++ fortunes29 Mar 2014 21:17:45 -
@@ -6338,7 +6338,7 @@
 "I'd love to go out with you, but the last time I went out, I never
 came back."
 %
-"I'd love to go out with you, but the man on television told me to say
+"I'd love to go out with you, but the man on television told me to stay
 tuned."
 %
 "I'd love to go out with you, but there are important world issues that



pf to redirect local dns traffic to another port

2014-03-29 Thread Stéphane Guedon
Hello

I am currently trying to run two nameserver on the same Openbsd 
server.

The first one is an autoritative (let's say bind or nsd, no one cares).
the second will be dnsmasq.

You guess the objective of the construction : give local answers from 
dhcp leases to local requests, and give autoritatives for the internet 
requests.

That's for the presentation.

I can run dnsmasq on a different port, but how do I give my local hosts 
the idea of interrogating a non standard dns port ?
Then I though I could drive the traffic from my LAN to the port where 
dnsmasq is running on.

so here is pf conf (obviously expurged) :

###

table  { local addresses }

# common
pass in log on egress proto { tcp, udp }from any to re0 port domain

# local
pass in quick log on re0 inet   proto { udp,tcp }   from  
port domain rdr-to 127.0.0.1 port 5353
#pass in quick log on re0 proto { udp,tcp } from  port 
domain divert-packet port 5353

###

I first tried to use the divert-packet rule (that way I don't have to 
care if the traffic is ipv6 or ipv4), then I tried to redirect using 
rdr-to 127... like most tutorials I found regarding rdr.

I move the local rules before or after the common one, place a quick 
on the common or removed it...

Nothing : the common rule is always the one that applies according to 
the logs.
Can you tell me what I am doing wrong ?



OpenBSD SCSI not working with very fast clock

2014-03-29 Thread turha turha
Hi,

I'm not sure if the subject is accurate or not, but it seems that SCSI
hangs during boot if the RTC (BIOS clock) runs too fast.

A bit of backstory:
I had issues with one server, after reboot it wouldn't work, BIOS was very
sluggish so I reset it. After that for some reason the RTC is ticking way
too fast (around 600x, which might be related to bad CMOS battery), but the
BIOS itself is working properly now, it's not sluggish anymore. Also
Symbios SCSI "BIOS" works ok, but boot hangs at:
siop0 at pci0 dev 11 function 0 "Symbios Logic 53c875" rev 0x26: apic 1 int
19 (irq 6), using 4K of on-board RAM
scsibus1 at siop0: 16 targets, initiator 7

I removed the SCSI drives and added normal old PATA drive, it boots just
fine and works normally, except for the BIOS clock being fast. Booting from
the PATA drive with the SCSI connected hangs at the same place. In the
Symbios SCSI BIOS I can detect the drives normally and they appear
functional.

I think the issue is with the boot process trying to access the SCSI drives
but failing because the clock is too fast.

Any suggestions on how to gain access to the drives? I don't have spare
SCSI controllers. I don't really care about the server itself as it's old
and going to be replaced anyway.

First guess is that this might be caused by a timeout (though no error is
displayed), can those timeouts simply be increased to 600x to test? Is this
normal operation of the SCSI driver? Since the Symbios SCSI controller
seems to be fine with the clock being fast, why isn't the SCSI driver?



Re: upgrades no longer allow ftp for sets

2014-03-29 Thread Theo de Raadt
> > > Eventually, will base ftpd be removed?
> > 
> > Unlikely.
> 
> Why not? You got rid of base telnetd a while back.

Because telnet is a protocol that people chose to use, and actively
could decide to move to the ssh server protocol.

Whereas ftp is a protocol that is often used in scripts.  So there
are lots of ftp-based things hiding in the background.

If we removed the our ftp server (which I think is a pretty safe ftp
server) from action, people would go into the ports tree and have to
install one of those.

They are probably worse.

People get hurt.  Noone benefits.



Re: upgrades no longer allow ftp for sets

2014-03-29 Thread Shawn K. Quinn
On Sat, Mar 29, 2014, at 09:44 AM, Theo de Raadt wrote:
> > Eventually, will base ftpd be removed?
> 
> Unlikely.

Why not? You got rid of base telnetd a while back.

-- 
  Shawn K. Quinn
  skqu...@rushpost.com



Re: upgrades no longer allow ftp for sets

2014-03-29 Thread Theo de Raadt
> Eventually, will base ftpd be removed?

Unlikely.



Re: upgrades no longer allow ftp for sets

2014-03-29 Thread Andy Lemin
Couldn't agree more! :)
Andy

Sent from my iPhone

> On 29 Mar 2014, at 09:10, Eric Oyen  wrote:
> 
> geez! there are better technologies out here. SUre, if a technology works for 
> 20 years, then go with it. However, there are loads faster ways (and a lot 
> more secure too). Why not use bit torrent? Its fast, reliable and really only 
> needs a half dozen seeds at various places across the net . THe problem with 
> FTP is that you can have only so many connections before the bandwidth the 
> host uses gets jammed. It also doesn't have very good resume functionality. 
> 
> If the guys at OpenBSD decide to change technologies, thats their choice. 
> Besides, I would rather be able to get the distribution and ports trees at my 
> full internet connection, not some slower speed limited by old technology. 
> So, when are the rest of you lot going to get with the 21st century?
> 
> -eric
> 
> 
>> On Mar 29, 2014, at 1:47 AM, Craig R. Skinner wrote:
>> 
>>> On 2014-03-26 Wed 16:06 PM |, Craig R. Skinner wrote:
 On 2014-03-25 Tue 18:34 PM |, Theo de Raadt wrote:
 
 The 5.5 release will support FTP releases, but after that we are
 disabling FTP and thus pushing people to use HTTP installs.
 
 In this day and age, it is somewhat irresponsible for us to put
 people into a situation where they might install new FTP servers on
 the internet.  We've known it is a dangerous protocol for over 20
 years.  Use a HTTP server to serve the sets, please.
>>> 
>>> Would these pages summarise it?
>>> 
>>> http://cr.yp.to/ftp/security.html
>>> http://tools.ietf.org/html/rfc2577
>>> http://en.wikipedia.org/wiki/File_Transfer_Protocol#Security
>>> http://daniel.haxx.se/docs/ftp-vs-http.html
>> 
>> Eventually, will base ftpd be removed?
>> 
>> e.g: telnetd, rshd, uucpd, rmail,...



Re: upgrades no longer allow ftp for sets

2014-03-29 Thread Craig R. Skinner
On 2014-03-29 Sat 02:10 AM |, Eric Oyen wrote:
> 
> .
> 
> > On 2014-03-26 Wed 16:06 PM |, Craig R. Skinner wrote:
> > 
> > Eventually, will base ftpd be removed?
> > 

*BASE*



Re: upgrades no longer allow ftp for sets

2014-03-29 Thread Eric Oyen
geez! there are better technologies out here. SUre, if a technology works for 
20 years, then go with it. However, there are loads faster ways (and a lot more 
secure too). Why not use bit torrent? Its fast, reliable and really only needs 
a half dozen seeds at various places across the net . THe problem with FTP is 
that you can have only so many connections before the bandwidth the host uses 
gets jammed. It also doesn't have very good resume functionality. 

If the guys at OpenBSD decide to change technologies, thats their choice. 
Besides, I would rather be able to get the distribution and ports trees at my 
full internet connection, not some slower speed limited by old technology. So, 
when are the rest of you lot going to get with the 21st century?

-eric


On Mar 29, 2014, at 1:47 AM, Craig R. Skinner wrote:

> On 2014-03-26 Wed 16:06 PM |, Craig R. Skinner wrote:
>> On 2014-03-25 Tue 18:34 PM |, Theo de Raadt wrote:
>>> 
>>> The 5.5 release will support FTP releases, but after that we are
>>> disabling FTP and thus pushing people to use HTTP installs.
>>> 
>>> In this day and age, it is somewhat irresponsible for us to put
>>> people into a situation where they might install new FTP servers on
>>> the internet.  We've known it is a dangerous protocol for over 20
>>> years.  Use a HTTP server to serve the sets, please.
>>> 
>> 
>> Would these pages summarise it?
>> 
>> http://cr.yp.to/ftp/security.html
>> http://tools.ietf.org/html/rfc2577
>> http://en.wikipedia.org/wiki/File_Transfer_Protocol#Security
>> http://daniel.haxx.se/docs/ftp-vs-http.html
>> 
> 
> Eventually, will base ftpd be removed?
> 
> e.g: telnetd, rshd, uucpd, rmail,...



Re: upgrades no longer allow ftp for sets

2014-03-29 Thread Craig R. Skinner
On 2014-03-26 Wed 16:06 PM |, Craig R. Skinner wrote:
> On 2014-03-25 Tue 18:34 PM |, Theo de Raadt wrote:
> > 
> > The 5.5 release will support FTP releases, but after that we are
> > disabling FTP and thus pushing people to use HTTP installs.
> > 
> > In this day and age, it is somewhat irresponsible for us to put
> > people into a situation where they might install new FTP servers on
> > the internet.  We've known it is a dangerous protocol for over 20
> > years.  Use a HTTP server to serve the sets, please.
> > 
> 
> Would these pages summarise it?
> 
> http://cr.yp.to/ftp/security.html
> http://tools.ietf.org/html/rfc2577
> http://en.wikipedia.org/wiki/File_Transfer_Protocol#Security
> http://daniel.haxx.se/docs/ftp-vs-http.html
> 

Eventually, will base ftpd be removed?

e.g: telnetd, rshd, uucpd, rmail,...