Files
c12aa812c9f434d4584e65d48c8f77b6c8c37862
swift /test /sample.conf

144 lines
4.9 KiB
Plaintext
Raw Normal View History

[s3api_test]
# You just enable advanced compatibility features to pass all tests. Add the
# following non-default options to the s3api section of your proxy-server.conf
# s3_acl = True
# check_bucket_owner = True
endpoint = http://127.0.0.1:8080
#ca_cert=/path/to/ca.crt
region = us-east-1
# First and second users should be account owners
access_key1 = test:tester
secret_key1 = testing
access_key2 = test:tester2
secret_key2 = testing2
# Third user should be unprivileged
access_key3 = test:tester3
secret_key3 = testing3
[func_test]
# Sample config for Swift with tempauth
auth_uri = http://127.0.0.1:8080/auth/v1.0
# Sample config for Swift with Keystone v2 API.
# For keystone v2 change auth_version to 2 and auth_prefix to /v2.0/.
# And "allow_account_management" should not be set "true".
#auth_version = 3
#auth_uri = http://localhost:5000/v3/
2010年07月12日 17:03:45 -05:00
# Used by s3api functional tests, which don't contact auth directly
#s3_storage_url = http://127.0.0.1:8080/
#s3_region = us-east-1
# Primary functional test account (needs admin access to the account)
account = test
username = tester
password = testing
Import swift3 into swift repo as s3api middleware This attempts to import openstack/swift3 package into swift upstream repository, namespace. This is almost simple porting except following items. 1. Rename swift3 namespace to swift.common.middleware.s3api 1.1 Rename also some conflicted class names (e.g. Request/Response) 2. Port unittests to test/unit/s3api dir to be able to run on the gate. 3. Port functests to test/functional/s3api and setup in-process testing 4. Port docs to doc dir, then address the namespace change. 5. Use get_logger() instead of global logger instance 6. Avoid global conf instance Ex. fix various minor issue on those steps (e.g. packages, dependencies, deprecated things) The details and patch references in the work on feature/s3api are listed at https://trello.com/b/ZloaZ23t/s3api (completed board) Note that, because this is just a porting, no new feature is developed since the last swift3 release, and in the future work, Swift upstream may continue to work on remaining items for further improvements and the best compatibility of Amazon S3. Please read the new docs for your deployment and keep track to know what would be changed in the future releases. Change-Id: Ib803ea89cfee9a53c429606149159dd136c036fd Co-Authored-By: Thiago da Silva <thiago@redhat.com> Co-Authored-By: Tim Burke <tim.burke@gmail.com>
2017年10月16日 21:39:12 +09:00
s3_access_key = test:tester
s3_secret_key = testing
# User on a second account (needs admin access to the account)
account2 = test2
username2 = tester2
password2 = testing2
# User on same account as first, but without admin access
username3 = tester3
password3 = testing3
Import swift3 into swift repo as s3api middleware This attempts to import openstack/swift3 package into swift upstream repository, namespace. This is almost simple porting except following items. 1. Rename swift3 namespace to swift.common.middleware.s3api 1.1 Rename also some conflicted class names (e.g. Request/Response) 2. Port unittests to test/unit/s3api dir to be able to run on the gate. 3. Port functests to test/functional/s3api and setup in-process testing 4. Port docs to doc dir, then address the namespace change. 5. Use get_logger() instead of global logger instance 6. Avoid global conf instance Ex. fix various minor issue on those steps (e.g. packages, dependencies, deprecated things) The details and patch references in the work on feature/s3api are listed at https://trello.com/b/ZloaZ23t/s3api (completed board) Note that, because this is just a porting, no new feature is developed since the last swift3 release, and in the future work, Swift upstream may continue to work on remaining items for further improvements and the best compatibility of Amazon S3. Please read the new docs for your deployment and keep track to know what would be changed in the future releases. Change-Id: Ib803ea89cfee9a53c429606149159dd136c036fd Co-Authored-By: Thiago da Silva <thiago@redhat.com> Co-Authored-By: Tim Burke <tim.burke@gmail.com>
2017年10月16日 21:39:12 +09:00
# s3api requires the same account with the primary one and different users
# one swift owner:
s3_access_key2 = test:tester2
s3_secret_key2 = testing2
# one unprivileged:
s3_access_key3 = test:tester3
s3_secret_key3 = testing3
2010年07月12日 17:03:45 -05:00
Restrict keystone cross-tenant ACLs to IDs The keystoneauth middleware supports cross-tenant access control using the syntax <tenant>:<user> in container ACLs, where <tenant> and <user> may currently be either a unique id or a name. As a result of the keystone v3 API introducing domains, names are no longer globally unique and are only unique within a domain. The use of unqualified tenant and user names in this ACL syntax is therefore not 'safe' in a keystone v3 environment. This patch modifies keystoneauth to restrict cross-tenant ACL matching to use only ids for accounts that are not in the default domain. For backwards compatibility, names will still be matched in ACLs when both the requesting user and tenant are known to be in the default domain AND the account's tenant is also in the default domain (the default domain being the domain to which existing tenants are migrated). Accounts existing prior to this patch are assumed to be for tenants in the default domain. New accounts created using a v2 token scoped on the tenant are also assumed to be in the default domain. New accounts created using a v3 token scoped on the tenant will learn their domain membership from the token info. New accounts created using any unscoped token, (i.e. with a reselleradmin role) will have unknown domain membership and therefore be assumed to NOT be in the default domain. Despite this provision for backwards compatibility, names must no longer be used when setting new ACLs in any account, including new accounts in the default domain. This change obviously impacts users accustomed to specifying cross-tenant ACLs in terms of names, and further work will be necessary to restore those use cases. Some ideas are discussed under the bug report. With that caveat, this patch removes the reported vulnerability when using swift/keystoneauth with a keystone v3 API. Note: to observe the new 'restricted' behaviour you will need to setup keystone user(s) and tenant(s) in a non-default domain and set auth_version = v3.0 in the auth_token middleware config section of proxy-server.conf. You may also benefit from the keystone v3 enabled swiftclient patch under review here: https://review.openstack.org/#/c/91788/ DocImpact blueprint keystone-v3-support Closes-Bug: #1299146 Change-Id: Ib32df093f7450f704127da77ff06b595f57615cb
2014年03月28日 02:46:08 +00:00
# Fourth user is required for keystone v3 specific tests.
# Account must be in a non-default domain.
#account4 = test4
#username4 = tester4
#password4 = testing4
#domain4 = test-domain
# Fifth user is required for service token-specific tests.
# The account must be different from the primary test account.
# The user must not have a group (tempauth) or role (keystoneauth) on
# the primary test account. The user must have a group/role that is unique
# and not given to the primary tester and is specified in the options
# <prefix>_require_group (tempauth) or <prefix>_service_roles (keystoneauth).
#account5 = test5
#username5 = tester5
#password5 = testing5
# The service_prefix option is used for service token-specific tests.
# If service_prefix or username5 above is not supplied, the tests are skipped.
# To set the value and enable the service token tests, look at the
# reseller_prefix option in /etc/swift/proxy-server.conf. There must be at
# least two prefixes. If not, add a prefix as follows (where we add SERVICE):
# reseller_prefix = AUTH, SERVICE
# The service_prefix must match the <prefix> used in <prefix>_require_group
# (tempauth) or <prefix>_service_roles (keystoneauth); for example:
# SERVICE_require_group = service
# SERVICE_service_roles = service
# Note: Do not enable service token tests if the first prefix in
# reseller_prefix is the empty prefix AND the primary functional test
# account contains an underscore.
#service_prefix = SERVICE
# Sixth user is required for access control tests.
# Account must have a role for reseller_admin_role(keystoneauth).
#account6 = test
#username6 = tester6
#password6 = testing6
collate = C
# Only necessary if a pre-existing server uses self-signed certificate
insecure = no
Allow domain remap storage_domain to be configured for func tests Previously some tests in /test/functional/test_staticweb.py assumed that domain_remap middleware was configured with the default storage_domain 'example.com'. As a result those tests would fail if run against a cluster with domain_remap middleware installed but not having an 'example.com' storage_domain. This patch allows a storage_domain to be configured in the test.conf file so that the tests may be successfully run against any cluster. If the option is not set then the tests will be skipped. To ensure that the in process test job func-domain-remap-staticweb still runs all the tests in test_staticweb.py, its config loader is modified to add the required storage_domain option to the test config with the same value used by the domain_remap middleware. Related-Change: I6bc70039c1b99b8a5bf5a30e9c6877d4f0aa638d Co-Authored-By: Tim Burke <tim.burke@gmail.com> Change-Id: Ifab84fc3ef66b9790e96ebb8e5c8061a12636045
2018年06月07日 11:35:34 +01:00
# Tests that are dependent on domain_remap middleware being installed also
# require one of the domain_remap storage_domain values to be specified here,
# otherwise those tests will be skipped.
storage_domain =
[unit_test]
fake_syslog = False
[probe_test]
# check_server_timeout = 30
2024年11月12日 09:25:14 -08:00
# subprocess_wait_timeout = 30
# validate_rsync = false
# proxy_base_url = http://localhost:8080
[swift-constraints]
# The functional test runner will try to use the constraint values provided in
# the swift-constraints section of test.conf.
#
# If a constraint value does not exist in that section, or because the
# swift-constraints section does not exist, the constraints values found in
# the /info API call (if successful) will be used.
#
# If a constraint value cannot be found in the /info results, either because
# the /info API call failed, or a value is not present, the constraint value
# used will fall back to those loaded by the constraints module at time of
# import (which will attempt to load /etc/swift/swift.conf, see the
# swift.common.constraints module for more information).
#
# Note that the cluster must have "sane" values for the test suite to pass
# (for some definition of sane).
#
swift constraints are now settable via config Change previously hard-coded constants into config variables. This allows deployers to tune their cluster more specifically based on their needs. For example, a deployment that uses direct swift access for public content may need to set a larger header value constraint to allow for the full object name to be represented in the Content- Disposition header (which browsers check to determine the name of a downloaded object). The new settings are set in the [swift-constraints] section of /etc/swift/swift.conf. Comments were also added to this config file. Cleaned up swift/common/constraints.py to pass pep8 1.3.3 Funtional tests now require constraints to be defined in /etc/test.conf or in /etc/swift/swift.conf (in the case of running the functional tests against a local swift cluster). To have any hope of tests passing, the defined constraints must match the constraints on the tested cluster. Removed a ton of "magic numbers" in both unit and functional tests. Change-Id: Ie4588e052fd158314ddca6cd8fca9bc793311465
2012年09月05日 20:49:50 -07:00
#max_file_size = 5368709122
#max_meta_name_length = 128
#max_meta_value_length = 256
#max_meta_count = 90
#max_meta_overall_size = 4096
2014年03月06日 00:03:03 -05:00
#max_header_size = 8192
#extra_header_count = 0
swift constraints are now settable via config Change previously hard-coded constants into config variables. This allows deployers to tune their cluster more specifically based on their needs. For example, a deployment that uses direct swift access for public content may need to set a larger header value constraint to allow for the full object name to be represented in the Content- Disposition header (which browsers check to determine the name of a downloaded object). The new settings are set in the [swift-constraints] section of /etc/swift/swift.conf. Comments were also added to this config file. Cleaned up swift/common/constraints.py to pass pep8 1.3.3 Funtional tests now require constraints to be defined in /etc/test.conf or in /etc/swift/swift.conf (in the case of running the functional tests against a local swift cluster). To have any hope of tests passing, the defined constraints must match the constraints on the tested cluster. Removed a ton of "magic numbers" in both unit and functional tests. Change-Id: Ie4588e052fd158314ddca6cd8fca9bc793311465
2012年09月05日 20:49:50 -07:00
#max_object_name_length = 1024
#container_listing_limit = 10000
#account_listing_limit = 10000
#max_account_name_length = 256
#max_container_name_length = 256
# Newer swift versions default to strict cors mode, but older ones were the
# opposite.
#strict_cors_mode = true