Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Upgrade path for implicit global account to multi-account configuration #4138

Open
bruth opened this issue May 8, 2023 · 2 comments · May be fixed by #5753
Open

Upgrade path for implicit global account to multi-account configuration #4138

bruth opened this issue May 8, 2023 · 2 comments · May be fixed by #5753
Labels
proposal Enhancement idea or proposal

Comments

@bruth
Copy link
Member

bruth commented May 8, 2023

Feature Request

Use Case:

When a server is configured with the authorization block (implicitly using the global account $G), it is currently not possible to declare a user for the system account. This requires the accounts block to be defined either specifying a user for $SYS (implicit system account name) or a new account declared via the system_account option.

However, migrating from the authorization block to accounts currently not possible (whether the system account is in need or not). Declaring $G as an account in accounts currently errors indicating $G is a reserved account. As a result, a new account name would need to be used when moving to accounts.

This is problematic specifically for JetStream since account names are used as the folders on disk to store stream data. The workaround would be to backup and restore the data from global account to the new account, however this requires downtime (and not a nice user experience).

Proposed Change:

Either support $G in the accounts block to support this migration path or introduce a global_account config option analogous to system_account to explicitly map a new name in accounts to the underlying implicit account, e.g. $G and $SYS.

Who Benefits From The Change(s)?

Anyone who starts out in single account mode and wants to expand to multiple accounts or forgets/is unaware of needing to explicitly enable the system account with users.

Alternative Approaches

Backup and restore JetStream data to a new account.
@AntPAllen
Copy link

Funnily enough we stumbled upon this just today. This would be very helpful. I presumed that imports and exports could be defined on the global account, but no dice.

@bruth bruth added proposal Enhancement idea or proposal and removed 🎉 enhancement labels Aug 18, 2023
@derekcollison
Copy link
Member

I could be wrong but I think this is possible today. This is how the demo server works..

Here is the portion of the demo config that I believe is relevant.

# Allow both TLS and non-TLS to work on same port.
allow_non_tls: true

no_auth_user: demo-user

demo_perms = {
  publish = {
    # Do not allow deletion of MQTT streams
    deny = ["$JS.API.STREAM.DELETE.$MQTT_msgs", "$JS.API.STREAM.DELETE.$MQTT_rmsgs", "$JS.API.STREAM.DELETE.$MQTT_sess"]
  }
}

accounts {
  default: {
    jetstream: {
      max_mem:		8GiB
      max_store:	400GiB
      max_streams:	1024
      max_consumers:	8192
    }
    users = [ { user: demo-user, permissions: $demo_perms} ]
  }
  $SYS: {
    users = [ { nkey: UDEMO3ZANTMUGPSBS3H54WKJN3TNVGQBJUQFCT7H4MUQLCRRQ26CWIIP } ]
  }
}

@bruth bruth linked a pull request Aug 5, 2024 that will close this issue
Draft
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
proposal Enhancement idea or proposal
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Allow $G to be listed in accounts option nats-io/nats-server
4 participants
@derekcollison @bruth @AntPAllen and others