| 224
|
|
|
Martin Arrieta |
|
9 years ago
|
 |
|
| 223
|
|
|
Alfranio Correia |
release-1.4.2 |
10 years ago
|
|
|
| 222
|
|
|
Alfranio Correia |
|
10 years ago
|
|
|
| 221
|
|
|
Johannes Schlüter |
|
10 years ago
|
|
|
| 220
|
|
|
Mats Kindahl |
|
10 years ago
|
|
|
| 219
|
|
|
Mats Kindahl |
|
10 years ago
|
|
|
| 218
|
|
|
Geert Vanderkelen |
|
10 years ago
|
|
|
| 217
|
|
|
Alfranio Correia |
|
10 years ago
|
|
|
| 216
|
|
WL#7455: Credentials for Fabric
Before, MySQL Fabric did not have any authentication
mechanism. We have added credentials with a role-based
system. Users executing commands will need to provide
a username and password together with a realm.
Setup
-----
The setup command will create new tables managing the
users, roles and permissions. It will also prompt for
a password to be set for the default user 'admin'. The
default realm for XMLRPC will be 'MySQL Fabric' when
it was not specified in the configuration file.
User Management
---------------
Most commands executed using mysqlfabric script will
prompt for a username and password. This can be set in
the configuration file under section [protocol.xmlrpc]
to prevent continuously asking credentials.
Commands like start and setup do not require
authentication.
Users can be managed through the commands found in the
'user' group, see `mysqlfabric help user`:
user add <username> [<option> ...]
user delete <username> [<option> ...]
user password <username> [<option> ...]
user roles <username> [<option> ...]
Any command that needs it, will prompt at least for a
password. See `mysqlfabric help user <command>`.
It is also possible to show the currently available
roles and permissions, but no other management can
be currently done. See `mysqlfabric help role`.
Note that user management is local and is currently
not done through protocols such as XMLRPC.
Authentication
--------------
Authentication can be disabled through the configuration
file by setting 'disable_authentication' to 'yes' in
the [protocol.xmlrpc] section. This can be useful for
testing, but by default authentication is enabled.
Client authenticate through XMLRPC using HTTP/1.1
Digest Authentication. We implemented RFC 2617 with
hashing function MD5. Other mechanisms can be added
later but MD5 is probably easiest to implement by
client libraries.
Connectors will best connect with a user which has
restricted permissions. A role named 'connector' has
been created for this and gives, by default, access
to the 'dump' and 'threat' commands.
SSL Support
-----------
The configuration section [protocol.xmlrpc] has 3 new
options named ssl_ca, ssl_key and ssl_cert. They are
used to enable SSL. When they are commented out or
removed, SSL is not set up. SSLv3 is currently used.
|
Geert Vanderkelen |
|
10 years ago
|
|
|
| 215
|
|
|
Narayanan Venkateswa... |
|
10 years ago
|
|
|
| 214
|
|
|
Alfranio Correia |
|
10 years ago
|
|
|
| 213
|
|
|
Alfranio Correia |
|
10 years ago
|
|
|
| 212
|
|
|
Alfranio Correia |
|
10 years ago
|
|
|
| 211
|
|
|
Alfranio Correia |
|
10 years ago
|
|
|
| 210
|
|
|
Narayanan Venkateswa... |
|
10 years ago
|
|
|
| 209
|
|
|
Alfranio Correia |
|
10 years ago
|
|
|
| 208
|
|
|
Narayanan Venkateswa... |
|
10 years ago
|
|
|
| 207
|
|
|
Alfranio Correia |
|
10 years ago
|
|
|
| 206
|
|
WL#7648: Decoupling provisioning from updates to state store
This patch introduces a new parameter in order to decouple provisioning from
updates to the state store. Any command that executes a provisioning step shall
provide the --update_only option so that users may choose whether they want to
execute the provisioning steps or skip them. By default the option is false
meaning that the provisioning shall be executed. If the option is set to true,
the command will only update the state store.
The --update_only parameter was added to the following commands:
. group.add(server, ..., update_only=False, ...)
. group.promote(group_id, slave_uuid=None, update_only=False, ...)
. group.demote(group_id, slave_uuid=None, update_only=False, ...)
. server.set_status(server, ..., update_only=False, ...)
. sharding.move(shard_id, ..., update_only=False, ...)
. sharding.split(shard_id, ..., update_only=False, ...)
We also took the opportunity to do the following changes in this patch:
. Removed the group.import_topology(...). It required to start servers
with the following options: --report-host and --report-port. This was
not very useful.
. Renamed group.check_group_availability(...) to group.health(...) and
removed the "is_master" from the returned value. Users can check the
same information in the "status" value.
|
Alfranio Correia |
|
10 years ago
|
|
|
| 205
|
|
BUG#71766 BUG#18280004: MYSQLFABRIC GROUP DESTROY COMMAND FAILURE
If you try to destroy a group when the group is used in the shard sub-system,
the following output is printed out:
-bash-4.1$ mysqlfabric group destroy my_group1
Procedure :
{ uuid = 09ea87a2-8255-4856-bd84-d0be4fc25975,
finished = True,
success = False,
return = DatabaseError: ("Command (DELETE FROM groups WHERE group_id =
%s, ('my_group1',)) failed: 1451 (23000): Cannot delete or update a parent
row: a foreign key constraint fails (`fabric`.`shards`, CONSTRAINT
`fk_shards_group_id` FOREIGN KEY (`group_id`) REFERENCES `groups`
(`group_id`))", 1451),
activities =
}
The DatabaseError is not a user-friendly message. In this patch, we check
whether the group is used in the shard sub-system before trying to destroy
(i.e. remove) it. If it is in use, one of the following messages can be
printed out:
raise _errors.GroupError(
"Cannot erase a group (%s) which is associated to a shard (%s)." %
(group_id, shard_id)
)
or
raise _errors.GroupError(
"Cannot erase a group (%s) which is used as a global group in a "
"shard definition (%s)." % (group_id, shard_mapping_id)
)
|
Alfranio Correia |
|
10 years ago
|
|
|
collapse all
