[jira] [Comment Edited] (TC-115) ATS sometimes does not reload the config while receiving a "traffic_line -x"

["John Rushford (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/TC-115?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15887025#comment-15887025 ] 

John Rushford edited comment on TC-115 at 2/28/17 1:37 AM:
-----------------------------------------------------------

@weifensh What OS are you running ats on?  I ask because we ran into an issue where remap.config wasn't loaded and changing the ownership of remap.config from root:root to ats:ats fixed the problem.  Looking at the source code, ats uses link(2) to first back up new configs and then loads them.  I saw in the manager.log these error messages  after the call to link(2):  "[Rollback::internalUpdate] Link failed : Operation not permitted".  I found a change to Cent OS 7.2, security change I think, that refuses to let link(2) create a link unless the file is owned by the effective user calling link(2).  This behavior is different than CentOS 6.5.

Try this on your machine.  change a file in your home directory so that it is owned by root and then try to use the 'ln' command as yourself to link a new name to the file owned by root.  If you get "Operation not permitted", that is whats going on with ATS.

Anyway, I ran across this googling.  There is a sysctl to revert the behavior back to Centos 6.5 that allowed creating links when the effectice user does not own the file.  See, http://unix.stackexchange.com/questions/209309/hard-link-permissions-behavior-different-between-centos-6-and-centos-7.

Anyway, the right thing to do is to make sure the ats config files are all owned by ats.  Just wanted to point out that it's not really a trafficserver issue but a change in the OS.


was (Author: jrushford):
@weifensh What OS are you running ats on?  I ask because we ran into an issue where remap.config wasn't loaded and changing the ownership of remap.config from root:root to ats:ats fixed the problem.  Looking at the source code, ats uses link(2) to first back up new configs and then loads them.  I saw in the manager.log these error messages  after the call to link(2):  "[Rollback::internalUpdate] Link failed : Operation not permitted".  I found a change to Cent OS 7.2, security change I think, that refuses to let link(2) create a link unless the file is owned by the effective user calling link(2).  This behavior is different than CentOS 6.5.

Try this on your machine.  change a file in your home directory so that it is owned by root and then try to using the 'ln' command as yourself to link a new name to the file owned by root.  If you get "Operation not permitted", that is whats going on with ATS.

Anyway, I ran across this googling.  There is a sysctl to revert the behavior back to Centos 6.5 that allowed creating links when the effectice user does not own the file.  See, http://unix.stackexchange.com/questions/209309/hard-link-permissions-behavior-different-between-centos-6-and-centos-7.

Anyway, the right thing to do is to make sure the ats config files are all owned by ats.  Just wanted to point out that it's not really a trafficserver issue but a change in the OS.

> ATS sometimes does not reload the config while receiving a "traffic_line -x"
> ----------------------------------------------------------------------------
>
>                 Key: TC-115
>                 URL: https://issues.apache.org/jira/browse/TC-115
>             Project: Traffic Control
>          Issue Type: Bug
>            Reporter: John Shen
>            Assignee: John Shen
>            Priority: Minor
>
> If the owner of a config file (e.g. ssl_multicert.config) is not ats.ats, ATS does not reload the config while receiving a "traffic_line -x".



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)