Open ze42 opened 9 years ago
Hello ze42,
The output format is driven in this case not by the ZendServerSDK tool, but by the configurationExport WebAPI function being invoked
See the following note on that documentation page:
Response Format: A successful call to the configurationExport method will result in an HTTP response with the configuration snapshot file in the response body.
The content type for the configuration snapshot file is “application/vnd.zend.serverconfig”. In addition, the response will include a “Content-disposition” header specifying a suggested file name for the configuration snapshot file.
This is different from most Web API calls where the content type is expected to be “application/vnd.zend.serverpi+xml; version=…” and the response body payload is expected to be in XML format.
This is why the response body is a zip file; that is what the configurationExport API call does (this is the API function behind the GUI action Administration | Import/Export. See the Exporting Configurations section on the documentation Backing Up and Restoring Settings page.
So, at least at the current time, the output formats xml and json will have no effect on the response body. The kv output format, should, in fact (at least at the current time), yield the same results as xml and json formats (i.e., a zip archive). This may be annoying to you, but the behavior would at least be consistent. So we do have a bug there on kv.
Since the backend produces only zip archives, changing to producing non-zip configuration snapshots is technically an "enhancement issue", not a "bug issue", but now we know that.
I found neither zend.user_name
nor zend.serial_number
in directives.sql, because they are blacklisted from export by default. You may be running a version of Zend Server which by default blacklisted only one of these directives.
One of the parameters to configurationExport is directivesBlacklist
, described here on the documentation page referred to above:
(Added in v1.3) Allows passing an array of blacklist directives which will not be exported. If the parameter is not passed, the list of blacklist directives is taken from
/config/autoload/global.config.php.
Below is the relevant section from that global.config.php file:
'export'=> array(
'directivesBlacklist'=>array(
// Global directives
'zend.serial_number',
'zend.user_name',
'zend.node_id',
// SC directives
'zend_sc.network.hostname',
'zend_sc.allowed_hosts',
'zend_sc.ha.cluster_members',
// zend.database directives
'zend.database.type',
'zend.database.name',
'zend.database.host_name',
'zend.database.port',
'zend.database.user',
'zend.database.password',
// debugger
'zend_debugger.allow_hosts',
'zend_debugger.deny_hosts',
// GUI directives
'zend_gui.defaultServer',
)
),
This means the you should by default see neither of the them exported. You could temporarily override these defaults with an edit to global.config.php file (or adding a local.config.php? I will have to test to see if the merged config arrays would remove the serial number and username from the blacklist.)
This explains why other zend directives are not exported. I'll check for other directives not blacklisted in this config file, and will look at configurationDirectivesList next.
Ok, I confirm that editing directly global.config.php
allows to get all values.
zend.user_name
is in the blacklist but still retrieved, and is the only one in my configuration.
On the documentation you pasted:
If the parameter is not passed, the list of blacklist directives is taken from [...]
I would expect to be able to pass and use that directive.
Trying --directivesBlacklist=date.default_latitude
, but :
date.default_latitude
is still in my exportNote: testing on zend-server-php-5.4 7.0.0+b469
Hello ze42,
I confirmed that, for example, --directivesBlacklist=date.default_latitude
does not keep the directive out of the export.
Neither does --directivesBlacklist="date.default_latitude"
Was worth a shot.
In both cases, most of the default blacklisted directives do not appear in the export, but these do appear: zend.user_name zend_sc.ha.cluster_members zend_debugger.deny_hosts
It seems that directives listed in --directivesBlacklist
option are either ignored or only partially merged with the default blacklist, which itself remains in effect, for the most part. I don't think I'm misunderstanding the documentation, but this is not the behavior I'd expect.
The problem could be in one of three places: zs-client, the WebAPI module it uses, or in the web service itself.
We'll get started looking into it. I'm testing with ZendServer 8.0.1. Will have to look at 7.0, etc. also.
configurationExport
configurationDirectivesList