Jay Paroline's questions

We are working on a major refactor of our site. For the rollout we would like to start sending a small subset of our users to the new version. We don't want them to keep switching back and forth between old and new so we are planning to set a cookie on their first visit and then use that to decide what to do.

We know how to make all of this work except for changing the nginx config based on the cookie. The configurations are mostly the same except we need to use a different root, and try_files is different between the two, as the old version is structured like page_name/index.php and the new version routes everything through one index.php file.

For changing the root based on a cookie I have that working using a map, but I'm not sure what to do about the try_files part. I am trying to avoid using if based on if-is-evil. The old version doesn't use try_files at all, and the new version uses try_files $uri $uri/ /index.php?$args;

What's the best way to proceed without using if, or should we be safe to use if in this case?

On CentOS 7, I am trying to debug an issue where the nginx amplify agent cannot read /proc/$pid/io even though it is owned by the proper user.

One of the nginx worker processes right now is pid 5693:

# ps aux | grep 5693
nginx     5693  0.5  0.0 129000 14120 ?        S    Jul18  16:10 nginx: worker process

the nginx user has permission to read the file:

# ls -lAh /proc/5693/io
-r-------- 1 nginx nginx 0 Jul 20 11:30 /proc/5693/io

...but can't actually read it:

# sudo -u nginx /bin/sh -c 'cat /proc/5693/io'
cat: /proc/5693/io: Permission denied

...even though selinux is disabled:

# sestatus
SELinux status:                 disabled

Root is able to read /proc/5693/io just fine, and the nginx user can read other files in /proc/5693. It seems like there must be some other security mechanism in place that is preventing the access, but I have no idea what it might be.

Note: not sure if this is allowed but I am crossposting this question from U&L as it's not getting attention there and is affecting our production server. The original question is here: https://unix.stackexchange.com/questions/297190/owner-cant-read-proc-pid-io - I would just migrate it but do not see a way to do that.