[[["易于理解","easyToUnderstand","thumb-up"],["解决了我的问题","solvedMyProblem","thumb-up"],["其他","otherUp","thumb-up"]],[["很难理解","hardToUnderstand","thumb-down"],["信息或示例代码不正确","incorrectInformationOrSampleCode","thumb-down"],["没有我需要的信息/示例","missingTheInformationSamplesINeed","thumb-down"],["翻译问题","translationIssue","thumb-down"],["其他","otherDown","thumb-down"]],["最后更新时间 (UTC):2025-07-31。"],[],[],null,["Optionally, at the startup of a new Looker customer-hosted instance, you can automatically provision the instance with a license key, a host URL, and an initial user account.\n\nAutomatically provisioning a new instance with an email user\n\nOn initial startup, Looker scans the `looker` directory, where the JAR file resides, for a file that has the name `provision.yml`. The format for this file is as follows: \n\n license_key: \"1234-5678-ABCD-EFGH-IJKL\"\n host_url: \"https://looker.mycompany.com\"\n user:\n first_name: \"Ariel\"\n last_name: \"Q\"\n email: \"arielq@altostrat.com\"\n password: \"password123\"\n\nIf the Looker instance is brand new and has not been set up yet, it will be provisioned with the given license key and a user account with the provided information.\n\nIf the Looker has already been provisioned, the license key and host URL values will override whatever license key and host URL are set in the instance. The user info will be ignored. This approach is useful for updating a staging instance of Looker with a fresh copy of a production instance's internal database, while still maintaining a separate license key and URL for the staging server.\n\nAutomatically provisioning a new instance with an API user\n\nAt the startup of a new Looker instance, you can provision an initial API user programmatically. You can provision an API user *or* an [email user](#automatically-provisioning-a-new-instance-with-an-email-user), but Looker does not support provisioning both an API user and an email user at the same time.\n\nGenerating API credentials\n\nTo provision an API user, generate a client ID and a client secret that Looker will read and save to the database. The requirements for these credentials are as follows:\n\n- The client ID must be 20 characters in length.\n- The client secret must be 24 characters in length.\n- Both strings must be able to be included in the body of a `POST` request; for this reason, we recommend that you use only alphanumeric characters for the client ID and client secret.\n\nFor example, Looker uses the following code to programmatically generate these credentials: \n\n require 'securerandom'\n\n TOKEN_SYMBOLS = \"bcdfghjkmnpqrstvwxyzBCDFGHJKMNPQRSTVWXYZ23456789\".freeze\n\n def generate_token(size)\n Array.new(size).map { TOKEN_SYMBOLS[SecureRandom.random_number(TOKEN_SYMBOLS.size)] }.join\n end\n\nThis code avoids ambiguous characters to make the strings less error-prone.\n\nYou can also use the `openssl` command to generate suitable strings: \n\n openssl rand -hex 10\n\nThe number at the end of the `openssl` command is the number of bytes in the string, so use `10` for the client ID and `12` for the client secret.\n\nProvisioning the API user\n\nTo provision an API user at startup, ensure you have a `provision.yml` file that includes your license key and host URL in the `looker` directory. For example: \n\n license_key: \"1234-5678-ABCD-EFGH-IJKL\"\n host_url: \"https://looker.mycompany.com\"\n\nCreate a file called `api-provision.yml` with the permissions `0600` in the `looker` directory that includes the API user information. For example: \n\n user:\n first_name: \"Ariel\"\n last_name: \"Q\"\n client_id: \"M9hZb8vRh9bSZzdPxw42\"\n client_secret: \"NMnqBVbHqPsPzTvbZk6xZfV3\"\n\n\u003e We recommend that you store these credentials in a secret manager outside of this file, as this file will be removed on startup once the Looker instance has processed and created the user in the database.\n\nAt startup, if the instance has no users, Looker creates a Looker admin API user with these credentials and removes the `api-provision.yml` file from the disk.\n\nOnce you've signed in as the new user, you should create at least one additional admin user, since the provisioned API user will be [automatically deleted by Looker](#deletion).\n\nAutomatic deletion of provisioned credentials\n\nThe provisioned API user is intended only for provisioning a new instance; it isn't intended to remain on your instance indefinitely.\n\nLooker automatically deletes the provisioned API user after one of the following conditions has been met:\n\n- An admin user other than the provisioned API user has logged in to the instance.\n- 50 minutes have passed since the provisioned API user first logged in.\n\nTherefore, it's important that you create at least one additional admin user immediately after you sign in as the provisioned user for the first time."]]