You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@trafficserver.apache.org by "Miles Libbey (JIRA)" <ji...@apache.org> on 2010/04/19 22:48:50 UTC
[jira] Created: (TS-315) Add switch to disable config file
generation/runtime behavior changing
Add switch to disable config file generation/runtime behavior changing
----------------------------------------------------------------------
Key: TS-315
URL: https://issues.apache.org/jira/browse/TS-315
Project: Traffic Server
Issue Type: Improvement
Reporter: Miles Libbey
Priority: Minor
(was yahoo bug 1863676)
Original description
by Michael S. Fischer 2 years ago at 2008-04-09 09:52
In production, in order to improve site stability, it is imperative that TS never accidentally overwrite its own
configuration files.
For this reason, we'd like to request a switch be added to TS, preferably via the command line, that disables all
automatic configuration file generation or other runtime behavioral changes initiated by any form of IPC other than
'traffic_line -x' (including the web interface, etc.)
Comment 1
by Bjornar Sandvik (bsandvik) 2 years ago at 2008-04-09 09:57:17
A very crucial request, in my opinion. If TS needs to be able to read command-line config changes on the fly, these
changes should be stored in another config file (for example remap.config.local instead of remap.config). We have a
patch config package that overwrites 4 of the config files under /home/conf/ts/, and with all packages
we'd like to think that the content of these files can't change outside our control.
Comment 2
by Bryan Call (bcall) 2 years ago at 2008-04-09 11:02:46
traffic_line -x doesn't modify the configuration, it reloads the configuration files. If we want to have an option for
this it would be good to have it as an option configuration file (CONFIG proxy.config.write_protect INT 1).
It would be an equivalent of write protecting floppies (ahh the memories)...
Comment 3
by Michael S. Fischer (mfischer) 2 years ago at 2008-04-09 11:09:09
I don't think it would be a good idea to have this in the configuration file, as it would introduce a chicken/egg
problem.
Comment 4
by Leif Hedstrom (leif) 19 months ago at 2008-08-27 12:43:17
So I'm not 100% positive that this isn't just a bad interaction. Now, it's only
triggered when trafficserver is running, but usually what ends up happening is that we get a records.config which
looks like it's the default config that comes with the trafficserver package.
It's possible it's all one and the same issue, or we might have two issues.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (TS-315) Add switch to disable config file
generation/runtime behavior changing
Posted by "Miles Libbey (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/TS-315?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Miles Libbey updated TS-315:
----------------------------
Description:
(was yahoo bug 1863676)
Original description
by Michael S. Fischer 2 years ago at 2008-04-09 09:52
In production, in order to improve site stability, it is imperative that TS never accidentally overwrite its own
configuration files.
For this reason, we'd like to request a switch be added to TS, preferably via the command line, that disables all
automatic configuration file generation or other runtime behavioral changes initiated by any form of IPC other than
'traffic_line -x' (including the web interface, etc.)
Comment 1
by Bjornar Sandvik 2 years ago at 2008-04-09 09:57:17
A very crucial request, in my opinion. If TS needs to be able to read command-line config changes on the fly, these
changes should be stored in another config file (for example remap.config.local instead of remap.config). We have a
patch config package that overwrites 4 of the config files under /home/conf/ts/, and with all packages
we'd like to think that the content of these files can't change outside our control.
Comment 2
by Bryan Call 2 years ago at 2008-04-09 11:02:46
traffic_line -x doesn't modify the configuration, it reloads the configuration files. If we want to have an option for
this it would be good to have it as an option configuration file (CONFIG proxy.config.write_protect INT 1).
It would be an equivalent of write protecting floppies (ahh the memories)...
Comment 3
by Michael S. Fischer 2 years ago at 2008-04-09 11:09:09
I don't think it would be a good idea to have this in the configuration file, as it would introduce a chicken/egg
problem.
Comment 4
by Leif Hedstrom 19 months ago at 2008-08-27 12:43:17
So I'm not 100% positive that this isn't just a bad interaction. Now, it's only
triggered when trafficserver is running, but usually what ends up happening is that we get a records.config which
looks like it's the default config that comes with the trafficserver package.
It's possible it's all one and the same issue, or we might have two issues.
was:
(was yahoo bug 1863676)
Original description
by Michael S. Fischer 2 years ago at 2008-04-09 09:52
In production, in order to improve site stability, it is imperative that TS never accidentally overwrite its own
configuration files.
For this reason, we'd like to request a switch be added to TS, preferably via the command line, that disables all
automatic configuration file generation or other runtime behavioral changes initiated by any form of IPC other than
'traffic_line -x' (including the web interface, etc.)
Comment 1
by Bjornar Sandvik (bsandvik) 2 years ago at 2008-04-09 09:57:17
A very crucial request, in my opinion. If TS needs to be able to read command-line config changes on the fly, these
changes should be stored in another config file (for example remap.config.local instead of remap.config). We have a
patch config package that overwrites 4 of the config files under /home/conf/ts/, and with all packages
we'd like to think that the content of these files can't change outside our control.
Comment 2
by Bryan Call (bcall) 2 years ago at 2008-04-09 11:02:46
traffic_line -x doesn't modify the configuration, it reloads the configuration files. If we want to have an option for
this it would be good to have it as an option configuration file (CONFIG proxy.config.write_protect INT 1).
It would be an equivalent of write protecting floppies (ahh the memories)...
Comment 3
by Michael S. Fischer (mfischer) 2 years ago at 2008-04-09 11:09:09
I don't think it would be a good idea to have this in the configuration file, as it would introduce a chicken/egg
problem.
Comment 4
by Leif Hedstrom (leif) 19 months ago at 2008-08-27 12:43:17
So I'm not 100% positive that this isn't just a bad interaction. Now, it's only
triggered when trafficserver is running, but usually what ends up happening is that we get a records.config which
looks like it's the default config that comes with the trafficserver package.
It's possible it's all one and the same issue, or we might have two issues.
> Add switch to disable config file generation/runtime behavior changing
> ----------------------------------------------------------------------
>
> Key: TS-315
> URL: https://issues.apache.org/jira/browse/TS-315
> Project: Traffic Server
> Issue Type: Improvement
> Reporter: Miles Libbey
> Priority: Minor
>
> (was yahoo bug 1863676)
> Original description
> by Michael S. Fischer 2 years ago at 2008-04-09 09:52
> In production, in order to improve site stability, it is imperative that TS never accidentally overwrite its own
> configuration files.
> For this reason, we'd like to request a switch be added to TS, preferably via the command line, that disables all
> automatic configuration file generation or other runtime behavioral changes initiated by any form of IPC other than
> 'traffic_line -x' (including the web interface, etc.)
>
>
> Comment 1
> by Bjornar Sandvik 2 years ago at 2008-04-09 09:57:17
> A very crucial request, in my opinion. If TS needs to be able to read command-line config changes on the fly, these
> changes should be stored in another config file (for example remap.config.local instead of remap.config). We have a
> patch config package that overwrites 4 of the config files under /home/conf/ts/, and with all packages
> we'd like to think that the content of these files can't change outside our control.
>
> Comment 2
> by Bryan Call 2 years ago at 2008-04-09 11:02:46
> traffic_line -x doesn't modify the configuration, it reloads the configuration files. If we want to have an option for
> this it would be good to have it as an option configuration file (CONFIG proxy.config.write_protect INT 1).
> It would be an equivalent of write protecting floppies (ahh the memories)...
>
>
> Comment 3
> by Michael S. Fischer 2 years ago at 2008-04-09 11:09:09
> I don't think it would be a good idea to have this in the configuration file, as it would introduce a chicken/egg
> problem.
>
>
> Comment 4
> by Leif Hedstrom 19 months ago at 2008-08-27 12:43:17
> So I'm not 100% positive that this isn't just a bad interaction. Now, it's only
> triggered when trafficserver is running, but usually what ends up happening is that we get a records.config which
> looks like it's the default config that comes with the trafficserver package.
> It's possible it's all one and the same issue, or we might have two issues.
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.