greg0ire's questions

I have a Shinken setup which tests 2 domains that are behind an HTTP authentication. To do so, I use the following custom macro:

define command {
    command_name new_check_http
    command_line /opt/shinken/libexec/check_http $ARG1$ --warning $ARG2$ --critical $ARG3$
}

The command is called like this

check_command new_check_http!-I my_host -H my_website -p 80 -a "http_user:http_password"!10!30

When I try /opt/shinken/libexec/check_http -I my_host -H my_website -p 80 -a "http_user:http_password --warning 10 --critical 30, I get a 302, like I should. However, Shinken keeps reporting 401 every hour. What could be the problem? How can I see what is actually being done?

Every hour, my team is receiving an email with the following text :

Shinken Notification

Notification Type: PROBLEM

Service: NetworkUsage
Host: Monitor
Address: localhost
State: UNKNOWN

Date/Time: 27-09-2016 Additional Info : Cannot get interface speed with standard MIB, use highperf mib (-g) : UNKNOWN

I think I found the server that has the problem (it's the monitoring server, since the address is localhost), but I can't figure out what to do (I'm a developer and know almost nothing about shinken, nagios or SNMP).

I think I'm missing a MIB that should be able to provide some kind of highperf function that would be able.

This is a very old server I don't know where to find / how to install this MIB.

DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=12.04
DISTRIB_CODENAME=precise
DISTRIB_DESCRIPTION="Ubuntu 12.04.5 LTS"

How can I provide this method? Alternatively, how can I disable this particular check for this particular host?

How can I forward configure my local dnsmasq so requests with hostnames ending with .docker are forwarded to another nameserver, while other requests are still handled locally ?

I have looked for an /etc/dnsmasq.conf file on my system but could not find it (only a dnsmasq.d directory).

EDIT : apparently, dnsmasq is run by network manager, like this :

/usr/sbin/dnsmasq --no-resolv --keep-in-foreground
--no-hosts --bind-interfaces
--pid-file=/run/sendsigs.omit.d/network-manager.dnsmasq.pid
--listen-address=127.0.1.1
--conf-file=/var/run/NetworkManager/dnsmasq.conf
--cache-size=0 --proxy-dnssec
--enable-dbus=org.freedesktop.NetworkManager.dnsmasq
--conf-dir=/etc/NetworkManager/dnsmasq.d

I'm trying to use several nameserver, each one is able to resolve some hosts the other does not.

Here is my resolv.conf :

options timeout:1

# This one is used to resolve hostnames for servers internal to my company
nameserver 127.0.1.1

And this one is used to resolve hostnames for docker hosts I have on my machine
nameserver 172.17.42.1
# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
#     DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
search lmc.universcine.com

When using this order, I cannot resolve the docker hosts. When I put the docker nameserver declaration first, I can. How can I resolve both groups of hostnames ?

We are facing issues with a php-fpm server that spawns too many children. This morning, I set up php-fpm's status page, and got an interesting piece of information : among all the scripts that are executed by the the children, one has a request duration that amounts to 3050111212255 µs which equals roughly to 35 days, which is the uptime of the machine, although we restart php-fpm recently. Here the output of the status page for this script.

pid:                  19998
state:                Idle
start time:           29/Aug/2014:14:48:25 +0200
start since:          578
requests:             244
request duration:     3050444744915
request method:       POST
request URI:          /app.php?_format=json
content length:       96
user:                 jobuser
script:               /home/frontoffice/instances/encoding/current/web/app.php
last request cpu:     0.00
last request memory:  7864320

Do you think this is a bug in php-fpm ?

I have connection problems on my server:

• often, ssh hangs when trying to connect
• sometimes, other commands take too much time, like su - someuser
• when I restart the daemon, it quickly listens on 127.0.0.1, but it takes very much time to listen on our VPN ip address
• when I try to edit the sshd config file, it takes time to get the file to display in vi

I have tried running ssh with more verbosity, and I can see that it hangs after the following message :

debug1: Entering interactive session.

When it hangs and I already have a session opened on the server, I can look at the process list, and I can see like this :

root     19835  0.0  0.0  90308  3948 ?        Ss   10:25   0:00  \_ sshd: root [priv]   
sshd     19836  0.0  0.0      0     0 ?        Z    10:25   0:00      \_ [sshd] <defunct>

When I finally login, the defunct process has disappears and the process with [priv] has a sane child :

root     19835  0.0  0.0  91524  4132 ?        Ss   10:25   0:00  \_ sshd: root@pts/3    
root     20898  3.3  0.1  24244  5264 pts/3    Ss+  10:27   0:00      \_ -bash

Here is what I get after the message that hangs:

debug2: callback start
debug2: fd 3 setting TCP_NODELAY
debug3: packet_set_tos: set IP_TOS 0x10
debug2: client_session2_setup: id 0
debug2: channel 0: request pty-req confirm 1
debug1: Sending environment.
debug3: Ignored env IM_CONFIG_PHASE
debug3: Ignored env GNOME_KEYRING_CONTROL
debug3: Ignored env KONSOLE_DBUS_WINDOW
debug3: Ignored env SESSIONTYPE
debug3: Ignored env XCURSOR_THEME
debug3: Ignored env GTK_MODULES
debug3: Ignored env SESSION
debug3: Ignored env DEFAULTS_PATH
debug3: Ignored env XDG_DATA_DIRS
debug3: Ignored env XDG_SESSION_ID
debug3: Ignored env XDG_GREETER_DATA_DIR
debug3: Ignored env GPG_AGENT_INFO
debug3: Ignored env KDE_SESSION_UID
debug3: Ignored env PATH
debug3: Ignored env GNOME_KEYRING_PID
debug3: Ignored env KDE_FULL_SESSION
debug3: Ignored env CLUTTER_IM_MODULE
debug3: Ignored env DBUS_SESSION_BUS_ADDRESS
debug3: Ignored env UPSTART_INSTANCE
debug3: Ignored env XDG_VTNR
debug3: Ignored env QT_PLUGIN_PATH
debug3: Ignored env SELINUX_INIT
debug3: Ignored env LANGUAGE
debug3: Ignored env GDM_LANG
debug3: Ignored env GS_LIB
debug3: Ignored env SHELL_SESSION_ID
debug3: Ignored env XAUTHORITY
debug3: Ignored env TEXTDOMAIN
debug3: Ignored env DESKTOP_SESSION
debug3: Ignored env GTK_IM_MODULE
debug3: Ignored env KDE_MULTIHEAD
debug1: Sending env LANG = fr_FR.UTF-8
debug2: channel 0: request env confirm 0
debug3: Ignored env SSH_AGENT_PID
debug3: Ignored env SESSION_MANAGER
debug3: Ignored env SPEECHD_PORT
debug3: Ignored env KONSOLE_DBUS_SERVICE
debug3: Ignored env LOGNAME
debug3: Ignored env PWD
debug3: Ignored env SSH_AUTH_SOCK
debug3: Ignored env KONSOLE_PROFILE_NAME
debug3: Ignored env HOME
debug3: Ignored env GTK2_RC_FILES
debug3: Ignored env XDG_SESSION_PATH
debug3: Ignored env XDG_SEAT
debug3: Ignored env UPSTART_JOB
debug3: Ignored env QT4_IM_MODULE
debug3: Ignored env XMODIFIERS
debug3: Ignored env MANDATORY_PATH
debug3: Ignored env QT_IM_MODULE
debug3: Ignored env WINDOWID
debug3: Ignored env KDE_SESSION_VERSION
debug3: Ignored env COLORFGBG
debug3: Ignored env DISPLAY
debug3: Ignored env KONSOLE_DBUS_SESSION
debug3: Ignored env XDG_CURRENT_DESKTOP
debug3: Ignored env XDG_CONFIG_DIRS
debug3: Ignored env UPSTART_SESSION
debug3: Ignored env SHELL
debug3: Ignored env JOB
debug3: Ignored env TEXTDOMAINDIR
debug3: Ignored env SSH_AGENT_LAUNCHER
debug3: Ignored env XDG_RUNTIME_DIR
debug3: Ignored env NODE_PATH
debug3: Ignored env QT_QPA_PLATFORMTHEME
debug3: Ignored env GTK_RC_FILES
debug3: Ignored env PROFILEHOME
debug3: Ignored env XDG_SEAT_PATH
debug3: Ignored env TERM
debug3: Ignored env INSTANCE
debug3: Ignored env GDMSESSION
debug3: Ignored env USER
debug3: Ignored env UPSTART_EVENTS
debug3: Ignored env SHLVL
debug3: Ignored env OLDPWD
debug3: Ignored env GREP_OPTIONS
debug3: Ignored env GREP_COLOR
debug3: Ignored env PAGER
debug3: Ignored env LESS
debug1: Sending env LC_CTYPE = fr_FR.UTF-8
debug2: channel 0: request env confirm 0
debug3: Ignored env LSCOLORS
debug3: Ignored env EDITOR
debug3: Ignored env OLDHISTFILE
debug3: Ignored env OLDPATH
debug3: Ignored env rvm_prefix
debug3: Ignored env rvm_path
debug3: Ignored env __array_start
debug3: Ignored env rvm_uname
debug3: Ignored env rvm_tar
debug3: Ignored env rvm_bin_path
debug3: Ignored env escape_flag
debug3: Ignored env _first
debug3: Ignored env _second
debug3: Ignored env rvm_version
debug3: Ignored env _
debug2: channel 0: request shell confirm 1
debug2: callback done
debug2: channel 0: open confirm rwindow 0 rmax 32768
debug2: channel_input_status_confirm: type 99 id 0
debug2: PTY allocation request accepted on channel 0
debug2: channel 0: rcvd adjust 2097152
debug2: channel_input_status_confirm: type 99 id 0
debug2: shell request accepted on channel 0

What could be the problem ?

UPDATE

strace su toto outputs hangs after the following :

socket(PF_FILE, SOCK_DGRAM|SOCK_CLOEXEC, 0) = 3
connect(3, {sa_family=AF_FILE, path="/dev/log"}, 110) = 0
sendto(3, "<86>Jul 25 11:19:39 su[28347]: S"..., 61, MSG_NOSIGNAL, NULL, 0) = 61
sendto(3, "<86>Jul 25 11:20:14 su[28347]: +"..., 53, MSG_NOSIGNAL, NULL, 0

Description of the problem

Regularly, cron php processes crash on our production server, which result in mails with the following body :

PHP Fatal error: PHP Startup: apc_mmap: mmap failed: in Unknown on line 0 Segmentation fault (core dumped)

I think the Segmentation fault (core dumped) should result in core files being handled by apport and then written in /var/crashes, but the files I can see there are there since yesterday, although the last crash occured today :

-rw-r----- 1 root        whoopsie  1138528 mai   22 04:09 _usr_bin_php5.0.crash
-rw-r----- 1 frontoffice whoopsie  1166373 mai   20 18:00 _usr_bin_php5.1005.crash
-rw-r----- 1 frontoffice whoopsie 81622658 mai   22 00:05 _usr_sbin_php5-fpm.1005.crash

I tried to download the last one anyway, and ran gdb /usr/sbin/php5-fpm /tmp/_usr_sbin_php5-fpm.1005.crash, only to be told that the file is not a core file (its format was not recognized).

Here is the server's apc configuration :

cat /etc/php5/cli/conf.d/20-apc.ini 
extension=apc.so
apc.shm_size=512M
apc.ttl=3600                   
apc.user_ttl=3600                
apc.enable_cli=1

I'm mostly worried about the apc.shm_size… isn't it too high or too low ? I understand it has to do with the size of memory segments.

Question(s)

1. What could be the problem ?
2. How can I troubleshoot it (how can I get a valid core file ?) ?

System information

free
             total       used       free     shared    buffers     cached
Mem:       5081296    4354684     726612          0     374744     959968
-/+ buffers/cache:    3019972    2061324
Swap:       522236     516888       5348

cat /etc/lsb-release 
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=12.04
DISTRIB_CODENAME=precise
DISTRIB_DESCRIPTION="Ubuntu 12.04.2 LTS"

php -v
PHP 5.4.17-1~precise+1 (cli) (built: Jul 17 2013 18:14:06) 
Copyright (c) 1997-2013 The PHP Group
Zend Engine v2.4.0, Copyright (c) 1998-2013 Zend Technologies

php -i excerpt :

Configuration

apc

APC Support => enabled
Version => 3.1.13
APC Debugging => Disabled
MMAP Support => Enabled
MMAP File Mask =>  
Locking type => pthread mutex Locks
Serialization Support => php
Revision => $Revision: 327136 $
Build Date => Nov 20 2012 18:41:36

Directive => Local Value => Master Value
apc.cache_by_default => On => On
apc.canonicalize => On => On
apc.coredump_unmap => Off => Off
apc.enable_cli => On => On
apc.enabled => On => On
apc.file_md5 => Off => Off
apc.file_update_protection => 2 => 2
apc.filters => no value => no value
apc.gc_ttl => 3600 => 3600
apc.include_once_override => Off => Off
apc.lazy_classes => Off => Off
apc.lazy_functions => Off => Off
apc.max_file_size => 1M => 1M
apc.mmap_file_mask => no value => no value
apc.num_files_hint => 1000 => 1000
apc.preload_path => no value => no value
apc.report_autofilter => Off => Off
apc.rfc1867 => Off => Off
apc.rfc1867_freq => 0 => 0
apc.rfc1867_name => APC_UPLOAD_PROGRESS => APC_UPLOAD_PROGRESS
apc.rfc1867_prefix => upload_ => upload_
apc.rfc1867_ttl => 3600 => 3600
apc.serializer => default => default
apc.shm_segments => 1 => 1
apc.shm_size => 512M => 512M
apc.shm_strings_buffer => 4M => 4M
apc.slam_defense => On => On
apc.stat => On => On
apc.stat_ctime => Off => Off
apc.ttl => 3600 => 3600
apc.use_request_time => On => On
apc.user_entries_hint => 4096 => 4096
apc.user_ttl => 3600 => 3600
apc.write_lock => On => On



 php -m
[PHP Modules]
apc
bcmath
bz2
calendar
Core
ctype
curl
date
dba
dom
ereg
exif
fileinfo
filter
ftp
gd
gettext
hash
iconv
imagick
intl
json
ldap
libxml
mbstring
memcache
memcached
mhash
mysql
mysqli
openssl
pcntl
pcre
PDO
pdo_mysql
pdo_pgsql
pdo_sqlite
pgsql
Phar
posix
Reflection
session
shmop
SimpleXML
soap
sockets
SPL
sqlite3
standard
sysvmsg
sysvsem
sysvshm
tidy
tokenizer
wddx
xml
xmlreader
xmlwriter
zip
zlib

[Zend Modules]

ulimit -a
core file size          (blocks, -c) 0
data seg size           (kbytes, -d) unlimited
scheduling priority             (-e) 0
file size               (blocks, -f) unlimited
pending signals                 (-i) 39531
max locked memory       (kbytes, -l) 64
max memory size         (kbytes, -m) unlimited
open files                      (-n) 1024
pipe size            (512 bytes, -p) 8
POSIX message queues     (bytes, -q) 819200
real-time priority              (-r) 0
stack size              (kbytes, -s) 8192
cpu time               (seconds, -t) unlimited
max user processes              (-u) 39531
virtual memory          (kbytes, -v) unlimited
file locks                      (-x) unlimited

I have a VPN with a gateway, and an application server. The app server only knows about the gateway of the VPN. The gateway of the VPN knows about the gateway of the physical network the vms are hosted on.

Problem: I can't reach api.twitter.com from the application server. Observation : the cache is filled with entries showing the physical gateway IP address. Here is an excerpt :

ip -s route show cache 199.16.156.40
199.16.156.40 via 37.59.245.62 dev eth0  src 10.1.4.20 
    cache <redirected>  used 170 age 22sec ipid 0x9e49
199.16.156.40 from 10.1.4.20 via 37.59.245.62 dev eth0 
    cache <redirected>  age 25sec ipid 0x9e49

IPs beginning with 199 are twitter IPs. 37.59.245.62 is the IP of the physical gateway. 10.1.4.20 is the VPN IP of the VPN's gateway.

The IP of the physical gateway only appears for entries dealing with twitter's servers.

Why does this machine cache routes with IPs it does not have direct access to ?

Previous question showing that flushing the cache solves the problem temporarily

I have an issue with private network traffic not being masqueraded in very specific circumstances.

The network is a group of VMware guests using the 10.1.0.0/18 network.

The problematic host is 10.1.4.20 255.255.192.0 and the only gateway it is configured to use is 10.1.63.254. The gateway server 37.59.245.59 should be masquerading all outbound traffic and forwarding it through 37.59.245.62, but for some reason, 10.1.4.20 ends up occasionally having 37.59.245.62 in its routing cache.

ip -s route show cache 199.16.156.40
199.16.156.40 from 10.1.4.20 via 37.59.245.62 dev eth0
    cache  used 149 age 17sec ipid 0x9e49
199.16.156.40 via 37.59.245.62 dev eth0  src 10.1.4.20
    cache  used 119 age 11sec ipid 0x9e49

ip route flush cache 199.16.156.40

ping api.twitter.com
PING api.twitter.com (199.16.156.40) 56(84) bytes of data.
64 bytes from 199.16.156.40: icmp_req=1 ttl=247 time=93.4 ms

ip -s route show cache 199.16.156.40
199.16.156.40 from 10.1.4.20 via 10.1.63.254 dev eth0
    cache  age 3sec
199.16.156.40 via 10.1.63.254 dev eth0  src 10.1.4.20
    cache  used 2 age 2sec

The question is, why am I seeing a public IP address in my routing cache on a private network?

Network information for the app server (without lo) :

ip a

eth0      Link encap:Ethernet  HWaddr 00:50:56:a4:48:20
          inet addr:10.1.4.20  Bcast:10.1.63.255  Mask:255.255.192.0
          inet6 addr: fe80::250:56ff:fea4:4820/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:1523222895 errors:0 dropped:407 overruns:0 frame:0
          TX packets:1444207934 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:1524116772058 (1.5 TB)  TX bytes:565691877505 (565.6 GB)

Network information for the VPN gateway (without lo too) :

 eth0      Link encap:Ethernet  HWaddr 00:50:56:a4:56:e9
           inet addr:37.59.245.59  Bcast:37.59.245.63  Mask:255.255.255.192
           inet6 addr: fe80::250:56ff:fea4:56e9/64 Scope:Link
           UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
           RX packets:7030472688 errors:0 dropped:1802 overruns:0 frame:0
           TX packets:6959026084 errors:0 dropped:0 overruns:0 carrier:0
           collisions:0 txqueuelen:1000
           RX bytes:7777330931859 (7.7 TB)  TX bytes:7482143729162 (7.4 TB)

 eth0:0    Link encap:Ethernet  HWaddr 00:50:56:a4:56:e9
           inet addr:10.1.63.254  Bcast:10.1.63.255  Mask:255.255.192.0
           UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1

 eth0:1    Link encap:Ethernet  HWaddr 00:50:56:a4:56:e9
           inet addr:10.1.127.254  Bcast:10.1.127.255  Mask:255.255.192.0
           UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1

 tun0      Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
           inet addr:10.8.1.1  P-t-P:10.8.1.2  Mask:255.255.255.255
           UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1500  Metric:1
           RX packets:477047415 errors:0 dropped:0 overruns:0 frame:0
           TX packets:833650386 errors:0 dropped:101834 overruns:0 carrier:0
           collisions:0 txqueuelen:100
           RX bytes:89948688258 (89.9 GB)  TX bytes:1050533566879 (1.0 TB)

eth0 leads to the outside world, and tun0 to an openvpn network of VMs on which sits the app server.

ip r for the VPN gateway :

default via 37.59.245.62 dev eth0  metric 100
10.1.0.0/18 dev eth0  proto kernel  scope link  src 10.1.63.254
10.1.64.0/18 dev eth0  proto kernel  scope link  src 10.1.127.254
10.8.1.0/24 via 10.8.1.2 dev tun0
10.8.1.2 dev tun0  proto kernel  scope link  src 10.8.1.1
10.9.0.0/28 via 10.8.1.2 dev tun0
37.59.245.0/26 dev eth0  proto kernel  scope link  src 37.59.245.59

ip r on the app server :

default via 10.1.63.254 dev eth0  metric 100
10.1.0.0/18 dev eth0  proto kernel  scope link  src 10.1.4.20

Firewall rules:

Chain PREROUTING (policy ACCEPT 380M packets, 400G bytes) 
pkts bytes target prot opt in out source destination 

Chain INPUT (policy ACCEPT 127M packets, 9401M bytes) 
pkts bytes target prot opt in out source destination 

Chain OUTPUT (policy ACCEPT 1876K packets, 137M bytes) 
pkts bytes target prot opt in out source destination 

Chain POSTROUTING (policy ACCEPT 223M packets, 389G bytes) 
pkts bytes target prot opt in out source destination 

32M 1921M MASQUERADE all -- * eth0 10.1.0.0/17 0.0.0.0/0

5 minutes ago, my server was unable to find route to api.twitter.com. mtr showed a blank screen. /etc/init.d/networking restart fixed the problem but I would like to understand what went wrong so that I can troubleshoot it more precisely next time. Any ideas ?

UPDATE : here is what the host command shows:

host api.twitter.com
api.twitter.com has address 199.16.156.199
api.twitter.com has address 199.16.156.40
api.twitter.com has address 199.16.156.104

after flushing the cache, one route changes:

host api.twitter.com
api.twitter.com has address 199.16.156.40
api.twitter.com has address 199.16.156.104
api.twitter.com has address 199.16.156.231

I have this configuration:

file { 
     "/tmp/apc.ini":
     source => "puppet:///modules/uc/php/apc.ini",
     require => Package["php-apc"]
  } 

  exec {
    "Add apc.ini to php mods-available":
    command => 'mv /tmp/apc.ini /etc/php5/mods-available/apc.ini',
    onlyif =>  "test -d /etc/php5/mods-available",
    require => File["/tmp/apc.ini"]
  }

  exec { 
    "Add apc.ini to php conf.d":
    command => 'mv /tmp/apc.ini /etc/php5/conf.d/apc.ini',
    unless =>  "test -d /etc/php5/mods-available",
    require => File["/tmp/apc.ini"]
  } 

I'd like to be able to simplify this so that the /tmp/apc.ini file isn't created every time I run puppet agent --test

For the moment, I get the following output:

info: Retrieving plugin
info: Loading facts in /var/lib/puppet/lib/facter/root_home.rb
info: Loading facts in /var/lib/puppet/lib/facter/concat_basedir.rb
info: Loading facts in /var/lib/puppet/lib/facter/postgres.rb
info: Loading facts in /var/lib/puppet/lib/facter/puppet_vardir.rb
info: Caching catalog for frontapp0.demo.infra.universcine.com
info: Applying configuration version '1376302253'
notice: /Stage[main]/Uc::Role::Php/File[/tmp/apc.ini]/ensure: defined content as '{md5}e5f5a158bd83469ce031b20ec72ce717'
notice: /Stage[main]/Uc::Role::Php/Exec[Add apc.ini to php mods-available]/returns: executed successfully
notice: Finished catalog run in 36.12 seconds

What can I try ?

UPDATE The goal is to have apc.ini either in mods-available or in conf.d, depending on whether the former exists or not

I have a server on a VPN. This server has a public address and has a gitlab instance on it. I'd like to be able to connect with any ssh user from the VPN address, but restrict the access to the git user from the public address.

How can I achieve both things at the same time?

I'm already restricting access like this:

# Listen on localhost
ListenAddress 127.0.0.1
# Listen on public address
ListenAddress 1.2.3.4
# Listen on the VPN address
ListenAddress 5.6.7.8

I'm on an Ubuntu server system, using openssh version 1:5.9p1-5ubuntu1

Every time I run puppet on my ubuntu server, I get this:

notice: /Stage[main]/MyCompany::Role::MyApp/Package[ncurses-dev]/ensure: ensure changed 'purged' to 'present'

Every. Single. Time. Why does it do this for this particular package, and not for others, that appear in the same code block?

Package { ensure => present }
package {
    [
    "openjdk-6-jre-headless", # for SOLR
    "ncurses-dev",  # for varnishstat built from buildout, used by munin
    "pkg-config",
    "nfs-common",
    "gettext", # for building PO @deployment
    "libpcre3", "libpcre3-dev", # for varnish build / to be removed
    "libevent-dev", # for beantalk buid / to be removed
    "ffmpeg", # for thumbnails
    "gpac", # contains MP4Box, for making mp4 pseudo-streamables
    ]:;
  }

EDIT: running puppet in verbose/debug mode show this:

debug: Puppet::Type::Package::ProviderApt: Executing '/usr/bin/dpkg-query -W --showformat ${Status} ${Package} ${Version}\n ncurses-dev'

debug: Puppet::Type::Package::ProviderApt: Executing '/usr/bin/apt-get -q -y -o DPkg::Options::=--force-confold install ncurses-dev'

Executing the first command gives this:

n[DEMO]root@ucdb:~#

notice the n before the prompt

Let's admit this is a formatting problem of the debug option, here is what I get when running it with some fixes:

/usr/bin/dpkg-query -W --showformat='${Status} ${Package} ${Version}\n' ncurses-dev

unknown ok not-installed ncurses-dev

Here is what I get when running aptitude search ncurses-dev:

v ncurses-dev

The package is virtual...

I have an NFS share on a server, that belongs to user barack. barack can write in this share, and root can't, because of the root squash feature

I tried creating a directory for barack on the share with puppet 2.7.21, using the file type, but it looks like puppet creates files/directories as root, and then changes the ownership. Obviously, the first step will (and does) fail.

I ended up using exec w/ mkdir.

Is my theory about puppet creating files as root first right? Is there a way to force puppet to create a directory as barack, using the file type?

I want to restrict access to (and only to) http://mysite.com/protected.php using nginx. What can I try? For the moment, I managed to do that but the php file is no longer interpreted by php-fpm.

location ~ \.php($|/) {
    location ~ ^/ws(_dev)?\.php {
      auth_basic "User synchronisation webservice > please login";
      auth_basic_user_file /home/symfony/instances/somesite/ws_access;
    }
    set  $script     $uri;
    set  $path_info  "";

    if ($uri ~ "^(.+\.php)(/.*)") {
      set  $script     $1;
      set  $path_info  $2;
    }
    add_header X-Response-Host somesite.com;
    fastcgi_pass   127.0.0.1:8300;
    include /etc/nginx/fastcgi_params;
    fastcgi_param  SCRIPT_FILENAME  /home/symfony/instances/somesite/service/web$script;
    fastcgi_param  PATH_INFO   $path_info;
    fastcgi_param  SCRIPT_NAME $script;
    fastcgi_param  SERVER_PORT "80";
  }

I have nginx+php-fpm on a server and the messages get truncated at 2048 chars, rendering the message quite unhelpful when a stack trace is logged : I can't see the following fields anymore:

• host (not interesting)
• upstream (not interesting)
• request (very very interesting)
• server (not interesting)
• client (not interesting, always 127.0.0.1 because of our architecture)

How do you overcome this problem? Do you change the format? Or did you find a way to overcome this stupid 2048 chars limitation which I hear is hardcoded? Or to disable this backtrace?