Jeff Widman's questions

One of my servers has a RAID1 array composed of two 240GB SSDs. It is managed/controlled via Linux, not via a hardware card.

Recently, for no apparent reason, the array needed rebuilding. I rebooted the server a few times recently, so perhaps there was a failed shutdown that forced it.

However, the rebuild took significantly longer than expected (~5 days), which makes me wonder if one of the drives is failing.

cat /proc/mdstat shows:

root@i3261:~# cat /proc/mdstat
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10]
md0 : active raid1 sdb1[1] sda1[0]
      242153280 blocks super 1.2 [2/2] [UU]

md1 : active raid1 sdb5[1] sda5[0]
      7768000 blocks super 1.2 [2/2] [UU]

unused devices: <none>

The delta between the blocks seems very high. Especially since these SSDs are supposedly identical.

Does this indicate a drive failing?

I have a networking issue that I eventually tracked down to an incorrect network prefix setting.

ip addr is reporting that the current prefix is /8 when it should be /24.

However, when I look in /etc/sysconfig/network-scripts/ifcfg-eth0, I see NETMASK correctly set to 255.255.255.0:

[root@ultravps ~]# cat /etc/sysconfig/network-scripts/ifcfg-eth0
# Generated by SolusVM
DEVICE=eth0
BOOTPROTO=static
ONBOOT=yes
IPADDR=xxx.xxx.xx.xxx
GATEWAY=xxx.xxx.xx.x
NETMASK=255.255.255.0

There is no PREFIX setting, and when I add PREFIX, it fixes the issue. Unfortunately, this is inconvenient because whenever SolusVM reconfigures networking, it reverts back to the above config, dropping the PREFIX value.

However, from what I've read, I shouldn't need to specify PREFIX when NETMASK is set.

Why is CentOS 7 ignoring the NETMASK value?

I manage a KVM VPS at 104.143.14.103 that for some reason cannot reach http://pecl.php.net.

When I ping the IP address of the PECL server (104.236.228.160), to make sure that it isn't a DNS problem, and each time I get Destination Host Unreachable.

How can I debug whether the root cause is a misconfiguration of my server, or the ping being rejected by the destination server?

I have no issues pinging PECL from various other servers that I manage, so I know PECL isn't blocking all pings.

I also have no issues pinging any other sites I try from my VPS, the problem is solely with the PECL server.

I used the looking glass of my VPS host (http://lg.las1.ultravps.net/), and it has no issues pinging PECL. I also filed a support ticket with the host, and they logged into the hypervisor for this node and said they could successfully ping PECL.

I ran a traceroute to the PECL server from another server to find the IP address of a next-to-last hop. I can successfully ping that IP (162.243.188.222) from my VPS.

When I run traceroute from the VPS, I get:

[jeffwidman@ultravps ~]$ traceroute pecl.php.net
traceroute to pecl.php.net (104.236.228.160), 30 hops max, 60 byte packets
 1  ultravps.jeffwidman.com (104.143.14.103)  3005.478 ms !H  3005.400 ms !H  3005.270 ms !H
[jeffwidman@ultravps ~]$ traceroute 104.236.228.160
traceroute to 104.236.228.160 (104.236.228.160), 30 hops max, 60 byte packets
 1  ultravps.jeffwidman.com (104.143.14.103)  3005.916 ms !H  3005.877 ms !H  3005.867 ms !H
[jeffwidman@ultravps ~]$

I checked multiple blacklist sites, just to make sure I hadn't inherited a bad IP address... none of them listed my IP. I also don't regularly hit PECL, and this issue has occurred for several days, so I'd be very surprised if I was hitting rate-limiting.

What else can I do to debug whether PECL is blocking my IP address or if I have something misconfigured on my VPS?

Output of ip route:

[jeffwidman@ultravps ~]$ ip route
default via 104.143.14.1 dev eth0  proto static  metric 100
104.0.0.0/8 dev eth0  proto kernel  scope link  src 104.143.14.103  metric 100

Output of ip addr:

[jeffwidman@ultravps ~]$ ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether 00:16:3c:d1:49:f6 brd ff:ff:ff:ff:ff:ff
    inet 104.143.14.103/8 brd 104.255.255.255 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 fe80::216:3cff:fed1:49f6/64 scope link
       valid_lft forever preferred_lft forever
[jeffwidman@ultravps ~]$

What is the difference between the three Nginx variables $host, $http_host, and $server_name?

I have a rewrite rule where I'm not sure which one I should be using:

location = /vb/showthread.php {
    # /vb/showthread.php?50271-What-s-happening&p=846039
    if ($arg_p) {
        return 301 $scheme://$host/forum/index.php?posts/$arg_p/;
        }

I'm looking for an answer that doesn't just say 'use ___ variable in your rewrite rule' but also explains the theoretical differences between them.

I have an Ansible task based on https://github.com/al3x/sovereign/blob/master/roles/tarsnap/tasks/tarsnap.yml#L2 that keeps failing when it should succeed.

I used to run the role with ansible_ssh_user=root, but recently switched to using a non-root user that has passwordless sudo rights and then calling become in my playbooks.

However, now the Ansible task fails even though I've specified become=true. Tarsnap is already installed, but the task still returns stderr: /bin/sh: tarsnap: command not found. I think it's because of something around sudo that I don't quite understand.

When I manually ssh into the server as this non-root user and run sudo tarsnap --version | grep 1.0.35 --color=never, I get sudo: tarsnap: command not found. But if I SSH in as root, that same command gives me tarsnap 1.0.35. Similarly, when I run sudo -i tarsnap --version | grep 1.0.35 --color=never (note the -i), I get tarsnap 1.0.35.

I am using CentOS 7.

1) Why are the results different for sudo vs sudo -i?

2) How do I fix my Ansible task?

I am struggling with some Nginx rewrits for url arguments passed to index.php:

• Old: ?topic=10126.msg36887
• New: ?posts/36887/

My two questions:

1) How do I rewrite to the new argument structure since it uses "parameter/value/" rather than the traditional "parameter=value" structure?

2) My "if" statement isn't triggering, and I can't figure out why... The test url domain.com/forum/index.php?topic=10126.msg36887 should redirect to /success, but it isn't rewritten at all.

Here's my current Nginx config:

location /forum/ {
    index index.php index.html index.htm;
    try_files $uri $uri/ /forum/index.php?$uri&$args;

    location /forum/index.php {

        # I know Nginx 'If is Evil', but it's the only way 
        # to trigger rewrites on url parameters
        if ($arg_topic ~ [0-9]+\.\bmsg([0-9]+) {

            # testing whether 'if' triggers:
            rewrite ^ /success? redirect;

            # full rewrite:
            # rewrite ^\/forum\/index\.php ^\/forum\/index\.php\?posts\/$1\/? redirect;

            }
        }
    }

location ~ \.php$ {
    try_files $uri =404;
    fastcgi_pass    127.0.0.1:9000;
    fastcgi_param   SCRIPT_FILENAME $document_root$fastcgi_script_name;
    include         fastcgi_params;
    }