WIP: vault implemention #378
Conversation
**WORKING IN PROGRESS, DO NOT MERGE OR USE IN PRODUCTION**
|
Let it go to a separate process. We just need to update the frontend passwords and then serve them to the vault binary |
src/vault.c
Outdated
|
|
||
| client_socket = socket(AF_INET, SOCK_STREAM, 0); | ||
| if (client_socket == -1) { | ||
| perror("Socket creation error"); |
src/vault.c
Outdated
| serverAddress.sin_addr.s_addr = inet_addr("127.0.0.1"); | ||
|
|
||
| if (connect(client_socket, (struct sockaddr *)&serverAddress, sizeof(serverAddress)) == -1) { | ||
| perror("Connection error"); |
src/vault.c
Outdated
|
|
||
| int result = pthread_create(&http_thread, NULL, http_thread_func, NULL); | ||
| if(result != 0) { | ||
| printf("something wrong\n"); |
There was a problem hiding this comment.
Thank you for your feedback. I am aware that there are many flaws in the code I submitted in the PR. I opened this PR to discuss my implementation with you all. Once we have finalized how to implement these features, I will close this PR and submit a clean one.
There was a problem hiding this comment.
You don't need a new pull request.
Just squash and force push
|
I do agree in not using thread right here. |
What do you mean by "it"?
Are you suggesting |
|
No, let |
src/vault.c
Outdated
| if(result != 0) { | ||
| printf("something wrong\n"); | ||
| } | ||
| pthread_create(&https_thread, NULL, https_thread_func, NULL); |
There was a problem hiding this comment.
We should follow the process model instead of using threads
| ev_periodic_init(&rotate_frontend_password, rotate_frontend_password_cb, 0., 60, 0); | ||
| ev_periodic_start (main_loop, &rotate_frontend_password); | ||
|
|
||
| unix_vault_socket = socket(AF_INET, SOCK_STREAM, 0); |
There was a problem hiding this comment.
Why do we need this ? The request for the current frontend password can go over the management port...
fix bug that cause generate same password for all users fix bug that cause cursh on querying non-exist users
|
@jesperpedersen, I have gone through the task and the corresponding files and I wish to continue this task, kindly assign me. Things to be fixed as per discussionspgagroal
pgagroal-vault
Doubts
Any other suggestions... |
|
In pgagroal there should be a pgagroal-vault is its own binary, and is independent of pgagroal. The port configuration should be defined in Think of pgagroal-vault as a "proxy" that speaks HTTP to get the current front end password for a specific user. |
Right, so pgagroal-vault should connect to management port of pgagroal which then handles the
Yeah, but it has to be spawned by pgagroal in the initialization stage of pgagroal if
Can we have a more specific format of
Got it! |
|
There is no
|
I am thinking |
|
Yeah, something like For now, 1 server connection definition is enough... |
|
I have one confusion here, regarding connecting pgagroal-vault with pgagroal, according to the above @jesperpedersen, any suggestions on this. Also what is the purpose of |
|
pgagroal-vault connects to the management port of pgagroal and uses the The user that is specified in the configuration file is an admin user in pgagroal. Follow |
This defines how long a connection will live in seconds - Add a `max_connection_age` member to `struct configuration`. It will be checked upon returned to the pool, or during idle timeout. - Add new STATE, TRACKER, and Prometheus metric for `max_connection_age` - Add documentation for `max_connection_age` - Add a `start_time` member to `struct connection`. Its implementation is similar to `timestamp` [agroal#378] Vault Implementaion [agroal#253][agroal#209] Refactor commands in `pgagroal-cli` and `pgagroal-admin` Now `pgagroal-cli` has a set of "logically" grouped commands and subcommands. For example, all the commands related to shutting down the pooler are under the `shutdown` command, that can operate with subcommands like `gracefully`, `immediate` or `cancel`. In order to provide this capability, new functions have been introduced as utilities: - `parse_command()` accepts the command line and seek for a command, possibly its subcommand, and an optional "value" (often the database or server name). - `parse_command_simple()` is a wrapper around the above `parse_command` that shorten the function call line because it does not require to specify the key and the value (and their defaults). - `parse_deprecated_command()` does pretty much the same thing but against the old command. Thanks to this, old commands can still work and the user will be warned about their deprecation, but the interface of `pgagroal-cli` is not broken. All the above functions require to know the offset at which start seeking for a command, and that depends on the number of options already parsed via `getopt_long()`. Since the `&option_index` is valued only for long options, I decided to use the `optind` global value, see getopt_long(3). This value is initialized with the "next thing" to seek on the command line, i.e., the next index on `argv`. In the case the command accepts an optional database name, the database value is automatically set to '*' (all databases) in case the database name is not found on the command line. Therefore: pgagroal-cli flush idle is equivalent to pgagroal-cli flush idle '*' On the other hand, commands that require a server name get the value automatically set to "\0" (an invalid server name) in order to "block" other pieces of code. Moroever, if the server has not been specified, the command is automatically set to "unknown" so that the help screen is shown. The `pgagroal-cli` has a set of `pgagroal_log_debug()` calls whenever a command is "parsed", so that it is possible to quickly follow the command line parsing. Also, since the `pgagroal-cli` exists if no command line arguments have been specified, the safety check aboutt `argc > 0` around the command line parsing has been removed. In the case the user specified an unknown command, she is warned on stdout before printing the `usage()` help screen. Deprecated commands are notified to the user via a warning message, printed on stderr, that provides some hints about the correct usage of the new command. The warning about deprecated commands is shown only if the currently running version of the software is greater than the version the command has been deprecated onto. In particular these commands have been deprecated since 1.6. This commit also introduces the command refactoring for `pgagroal-admin` in a way similar to the work done for `pgagroal-cli`. New commands are available: - user <what> with <what> being <add>, <del>, <edit>, <ls>. Updated: - documentation - shell completions - help screens - examples Close agroal#290 agroal#253 [agroal#381] Changes to `pgagroal-cli` commands This commit changes two commands in `pgagroal-cli`. The `is-alive` command is deprecated by means of the `ping` command. Documentation has been modified accordingly. The `details` command is now deprecated by the `status details` one. To achieve this, the `status details` is parsed _before_ the `status` one (that has not changed at all). In order to better reflect this change, the internal constant `ACTION_DETAILS` has been renamed to `ACTION_STATUS_DETAIL`. Documentation updated accordingly. Shell completions updated accordingly. Close agroal#381 [agroal#378] Vault Implementation
|
Work is being done on #407 now |
WORKING IN PROGRESS, DO NOT MERGE OR USE IN PRODUCTION
About this coomit
An HTTP server that supports http and https. However, bind port 443 require
sudo setcap CAP_NET_BIND_SERVICE=+eip path/to/pgagroal.vault.ccurrently is an executable for debugging convenience, and will convert to non-executable if needed.generate_passwordfunction moved tosecurity.cand enhanced.New message added for
vault-pgagroalcommunication.rotate_password_cbadded for changing passwords over time.accpet_vault_cbandhandle_vault_cbadded for async io betweenvaultandpgagroalLots of places are hard coded cause the config is not implemented yet.
Bug I dealing with:
I want to implement an async listener and handler in
main.c, there should be a long-lived connection betweenpgagroalandvault, andhandle_vault_cbshould read-write messages whenever it received message fromvault.But this is what I got from gdb:
I don't know why
handle_vault_cbis called, I didn't send anything fromvaulttopgagroal.Also, I am unsure if I am doing the message read-write right.