You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@trafficserver.apache.org by Nick Berry <ni...@linkedin.com> on 2013/04/20 00:34:32 UTC
Re: why is trafficserver touching it's config at restart?
You can change the owner of the config files to another user (root?) and if you're not using clustering, ATS will just complain a little inside traffic.out on start.
On Mar 10, 2013, at 4:52 AM, Reindl Harald <h....@thelounge.net> wrote:
>
>
> Am 10.03.2013 12:42, schrieb Jan-Frode Myklebust:
>> On Sun, Mar 10, 2013 at 12:01:27PM +0100, Reindl Harald wrote:
>>> why is trafficcserver doing this?
>>>
>>> i had as example empty lines between the config blocks
>>> to make the file more readable which are gone and
>>> generally dislike this _1 files and touching my config
>>
>> Very much agree. I manage the *.config files trough puppet, and every
>> time puppet changes something, ATS will make one additional changes to
>> the files (possibly only change timestamps), and cause a second service
>> reload.
>>
>> Daemons shouldn't have write access to it's configuration files, as
>> that opens them to attacks. A remote file write vulnerability as the
>> ATS-user is automatically a remote root shell since it can f.ex. change
>> the proxy.config.proxy_binary in records.config...
>>
>> Unfortunately I don't expect this to change.. since ATS includes some
>> cluster management where the configuration is supposed to be replicated
>> between the nodes..
>
>
> but with "LOCAL proxy.local.cluster.type INT 3" it should not touch anything
>
Re: why is trafficserver touching it's config at restart?
Posted by Leif Hedstrom <zw...@apache.org>.
On 4/19/13 4:52 PM, Reindl Harald wrote:
> this seems to work and TS is running fine
> thanks
>
> however, it would be nice if clustering is not enabled
> not touch the config files at all
There's at least one bug filed on this
https://issues.apache.org/jira/browse/TS-203
I could have sworn there was another one talking about the alternative of
turning off the config writes when clustering is disabled, but couldn't find it.
-- Leif
Re: why is trafficserver touching it's config at restart?
Posted by Reindl Harald <h....@thelounge.net>.
this seems to work and TS is running fine
thanks
however, it would be nice if clustering is not enabled
not touch the config files at all
[Apr 20 00:50:41.535] Manager {0x7fcf857ee880} NOTE: [Rollback::Rollback] Automatic Roll of Version 1 failed: wpad.dat
[Apr 20 00:50:41.535] Manager {0x7fcf857ee880} NOTE: [Rollback::openFile] Open of wpad.dat failed: Permission denied
[Apr 20 00:50:41.535] Manager {0x7fcf857ee880} NOTE: [Rollback::Rollback] Config file is read-only : wpad.dat
[Apr 20 00:50:41.538] Manager {0x7fcf857ee880} NOTE: [Rollback::internalUpdate] Link failed : Operation not permitted
[Apr 20 00:50:41.538] Manager {0x7fcf857ee880} NOTE: [Rollback::Rollback] Automatic Roll of Version 1 failed:
records.config
[Apr 20 00:50:41.538] Manager {0x7fcf857ee880} NOTE: [Rollback::openFile] Open of records.config failed: Permission
denied
[Apr 20 00:50:41.538] Manager {0x7fcf857ee880} NOTE: [Rollback::Rollback] Config file is read-only : records.config
[Apr 20 00:50:41.540] Manager {0x7fcf857ee880} NOTE: [Rollback::internalUpdate] Link failed : Operation not permitted
[Apr 20 00:50:41.540] Manager {0x7fcf857ee880} NOTE: [Rollback::Rollback] Automatic Roll of Version 1 failed:
vaddrs.config
[Apr 20 00:50:41.540] Manager {0x7fcf857ee880} NOTE: [Rollback::openFile] Open of vaddrs.config failed: Permission
denied
[Apr 20 00:50:41.541] Manager {0x7fcf857ee880} NOTE: [Rollback::Rollback] Config file is read-only : vaddrs.config
[Apr 20 00:50:41.544] Manager {0x7fcf857ee880} NOTE: [Rollback::internalUpdate] Link failed : Operation not permitted
[Apr 20 00:50:41.544] Manager {0x7fcf857ee880} NOTE: [Rollback::Rollback] Automatic Roll of Version 1 failed:
cache.config
[Apr 20 00:50:41.544] Manager {0x7fcf857ee880} NOTE: [Rollback::openFile] Open of cache.config failed: Permission
denied
[Apr 20 00:50:41.544] Manager {0x7fcf857ee880} NOTE: [Rollback::Rollback] Config file is read-only : cache.config
[Apr 20 00:50:41.546] Manager {0x7fcf857ee880} NOTE: [Rollback::internalUpdate] Link failed : Operation not permitted
[Apr 20 00:50:41.546] Manager {0x7fcf857ee880} NOTE: [Rollback::Rollback] Automatic Roll of Version 1 failed:
icp.config
[Apr 20 00:50:41.547] Manager {0x7fcf857ee880} NOTE: [Rollback::openFile] Open of icp.config failed: Permission denied
[Apr 20 00:50:41.547] Manager {0x7fcf857ee880} NOTE: [Rollback::Rollback] Config file is read-only : icp.config
Am 20.04.2013 00:34, schrieb Nick Berry:
> You can change the owner of the config files to another user (root?) and if you're not using clustering, ATS will just complain a little inside traffic.out on start.
>
> On Mar 10, 2013, at 4:52 AM, Reindl Harald <h....@thelounge.net> wrote:
>
>>
>>
>> Am 10.03.2013 12:42, schrieb Jan-Frode Myklebust:
>>> On Sun, Mar 10, 2013 at 12:01:27PM +0100, Reindl Harald wrote:
>>>> why is trafficcserver doing this?
>>>>
>>>> i had as example empty lines between the config blocks
>>>> to make the file more readable which are gone and
>>>> generally dislike this _1 files and touching my config
>>>
>>> Very much agree. I manage the *.config files trough puppet, and every
>>> time puppet changes something, ATS will make one additional changes to
>>> the files (possibly only change timestamps), and cause a second service
>>> reload.
>>>
>>> Daemons shouldn't have write access to it's configuration files, as
>>> that opens them to attacks. A remote file write vulnerability as the
>>> ATS-user is automatically a remote root shell since it can f.ex. change
>>> the proxy.config.proxy_binary in records.config...
>>>
>>> Unfortunately I don't expect this to change.. since ATS includes some
>>> cluster management where the configuration is supposed to be replicated
>>> between the nodes..
>>
>>
>> but with "LOCAL proxy.local.cluster.type INT 3" it should not touch anything