Solution B was to not at any time overwrite values read from the config object
even if they are the same as default and an environment variable with another
value exist. In this solution this shall be detected and a warning shall be
written to the syslog. Making it possible to change some attributes in runtime
can give the user a chance to fix such a problem, at least the limits could be
made possible to change in runtime but security must be taken into
consideration, see (d.) below.
It is NOT OK to change configuration using environment variables without to
also change in the configuration object. Configuration object and the actual
settings must match.
To consider:
a.
If environment variables exist on one SC node but not on the other (or differ)
we end up with different configuration on the nodes.
b.
A system may do a correct configuration in a configuration object but if for
some reason an old logd.conf file containing some old configuration exist the
correct configuration will be overwritten. This means that an upgrade always
must contain a removal of eventually old configuration. Not needed today since
a configuration object always have precedence. I see this as a risk. May have
consequences as in (a.).
c.
If a configuration object exist and is used, some configuration is changed via
environment variables and the configuration object is not updated to reflect
the changes there will be a mismatch between the real configuration and what
can be read using for example immlist. This must be considered to be an error
and is a risk.
d.
To make more configuration attributes possible to change in runtime may be
considered as a security risk. However there is already one attribute that can
be changed, the root path, but there is some security built into that
possibility and that is that it can only be changed to a path that exists. If
the path does not exist the change will be rejected. When this configuration
possibility was implemented the security aspect was a very important issue. I
don’t know how security can be handled in this case but if bad configuration
changes are done it may lead to problems that can affect the system e.g. node
restarts.
e.
If attributes are runtime configurable and environment variables can be used a
situation where a configuration changed in runtime will change back to
something else if the node is restarted may happen. In the current patch a
configuration value coming from the configuration object will always be
replaced by a value in an environment variable if exist, except for
logMaxLogrecsize and logMaxApplicationStreams that must have a value of 1024
and 64 respectively in order to be replaced. The logRootDirecory is not
affected.
This is what was considered when the current construction was made. This I why
configuration using configuration object and environment variables is not mixed
and why only one attribute is runtime configurable. This is also why the
configuration object is always used if it exists even if there are environment
variables.
The current construction:
If a configuration object exists it is used for all configurations.
The class definition for the configuration object provides default values for
all attributes except the root path (logsv_classes.xml). All default values can
be overridden by adding and setting attributes in the logsv_objects.xml file
The log root path can be configured in runtime. For security reasons it can
only be set to an already existing path i.e. a new root path is never created
by the log service when changed in runtime. For security reasons no other
configurations can be changed in runtime.
If a configuration object exists but some attributes are missing e.g. if the
object is an old version hard coded default values are used for the missing
values.
If no configuration object exists environment variables are used (old method
for configuration). If a value is not configured in an environment variable a
hard coded default value is used.
---
** [tickets:#841] LOG: Wrong default logStreamAppHighLimit (1)**
**Status:** fixed
**Milestone:** 4.5.FC
**Created:** Wed Apr 09, 2014 07:07 AM UTC by Hans Feldt
**Last Updated:** Thu Apr 24, 2014 10:32 AM UTC
**Owner:** elunlen
The value is 1 causing writes to be discarded with no buffering.
This was introduced by:
changeset: 4758:2e40297612ec
user: Lennart Lund <[email protected]>
date: Fri Dec 20 13:14:09 2013 +0100
summary: logsv: Handle log files on both active and standby [#152]
Previously the limits were unlimited, this one should be reverted back to 0
(unlimited).
---
Sent from sourceforge.net because [email protected] is
subscribed to https://sourceforge.net/p/opensaf/tickets/
To unsubscribe from further messages, a project admin can change settings at
https://sourceforge.net/p/opensaf/admin/tickets/options. Or, if this is a
mailing list, you can unsubscribe from the mailing list.
------------------------------------------------------------------------------
"Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
Instantly run your Selenium tests across 300+ browser/OS combos. Get
unparalleled scalability from the best Selenium testing platform available.
Simple to use. Nothing to install. Get started now for free."
http://p.sf.net/sfu/SauceLabs
_______________________________________________
Opensaf-tickets mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/opensaf-tickets
