Looker set-up and management
We have very sensitive fields that we have locked down using a user attribute. This works well, but users with sudo permissions can sudo as a user with the required permissions and then see the sensitive data. We don’t want to remove our Looker Superuser’s ability to sudo as they use it a lot to support their teams. Can you limit which users a user can sudo as? We could then only allow Superusers to sudo as their own team members. Can you prevent fields from being displayed when the user is being sudoed? We are aware that sudos are logged but this isn’t very accessible and we would have to setup a process to monitor this on a regular basis. Any suggestions appreciated!
Hey Guys, I have been playing around with the new feature access_grant released in Looker 6.0. This feature could make security on our side a lot more manageable but it lacks the ability to mask the dimensions/measures and instead removes these from the users model explore/dashboards completely. Our current setup allows us to mask the attributes we desire instead of removing them - this uses the user_attribute feature and is applied specifically to the applicable dimension/measure we need to mask. Cheers Will
Background When a user runs a query in Looker, a connection is opened from the user’s browser to the Looker server, and from the Looker server to the database to execute that query. If a user closes that browser tab, there is a mechanism that detects this and then in turn initiates a cancel or kill on that query on the database. The way this works is when a query is run from a dashboard, look, or explore page, there is a connection opened to the server that stays open for the duration of the query or queries depending on it is coming from a single query page, such as a look, or a page that runs multiple queries such as a dashboard. Problems can occur if either: Some network device such as a reverse proxy or firewall is timing out and closing that connection prematurely causing queries to be undesirably cancelled before completion Some network device is not properly forwarding the closing connection to the looker server causing a query a user stopped or abandoned from the front end to
My team is currently using DBT to build models against custom schemas in Redshift. This allows us to avoid overwriting each other’s changes in the public schema (which is where DBT builds models by default) while we’re testing out model changes. However, this has introduced challenges in Looker because there isn’t an easy way for data analysts using Looker to reference the models in these custom schemas. Our team has a few ideas for solving this, but none of them are as user-friendly or automated as we’d like. Does anyone have experience setting up a multi-user development workflow in Looker, or ideas for how this could be addressed without a lot of recurring manual configuration? For reference, we’re currently running a “test” Looker environment alongside our “prod” one so we can connect the test environment to our “test” Redshift database. This is helpful as it allows us to perform user acceptance testing in Looker before deploying DBT model updates. Ideas we’re currently considering
I have tried downloading Java APM agent and configured to run with looker jar file. However the looker application didn’t start after configuring newrelic. As suggested here I have tried passing newrelic jar file path as java argument https://docs.newrelic.com/docs/agents/java-agent/installation/install-java-agent#h2-install-agent Got below error in looker.log when I start Looker: 2018-11-02 18:43:59.219 +0000 [WARN|007d0|ruby:stderr] :: NotImplementedError: getppid unsupported or native support failed to load; see http://wiki.jruby.org/Native-Libraries ppid at org/jruby/RubyProcess.java:1114 ppid at org/jruby/RubyProcess.java:1111 &lt;class:SystemUniversal&gt; at uri:classloader:/gems/systemu-2.6.5/lib/systemu.rb:28 &lt;main&gt; at uri:classloader:/gems/systemu-2.6.5/lib/systemu.rb:13 require at org/jruby/RubyKernel.java:955 &lt;main&gt; at uri:classloader:/helltool-component-build/lib/helltool/initializers/001_requires.class:1 load at org/jruby/RubyKern
I would love to be able to nest model sets to be able to solve this situation: I want the whole company to have view permissions on all models yet certain teams developer access on their own models. I want to set it up as so… Finance Model set -> finance_models Marketing Model set -> marketing_models View permissions set -> viewer Dev permissions set -> developer Finance Role -> finance_developer (combo of finance_models + developer) Marketing Role -> marketing_developer (combo of marketing_models + developer) This is all good so far but I want marketing to be able to have viewer on finance and vice versa. To do this I need a new role (Company Viewer -> company_viewer). This will use the viewer permission set and then I need to combine it with a model set. This extra model set (lets call it company_models) will be the sum of all the other model sets, at the moment I have to select these manually and when a new model is created (eg finance) then it needs to be added
Hi We recently migrated our Looker backend database from the in-memory HyperSQL setup to an instance of MySQL running in AWS RDS. We weren’t experiencing any performance issues with HyperSQL, but we wanted to go ahead and make the switch not only for eventual demand, but also for easier backup, DR planning, more selective migration of data between environments, etc etc. I configured the MySQL instance according to this Discourse post: Migrating Looker Backend Database to MySQL Administration NOTE: This procedure assumes a deployment in AWS EC2. For local deployments, systems should be sized comparably to the equivalent AWS instances. By default, Looker uses a HyperSQL in-memory database to store its configuration, users, and other data. On a busy instance this database can grow to be gigabytes in size, which leads to performance issues, Java memory pressure, and extremely long startup times. In these cases it’s best to replace HyperSQL with a full MySQL b
The instructions to setup a MySQL database for lookerdb don’t specify character-set or collation. We attempted to convert an existing lookerdb to utf8mb4 but a few columns failed the new length constraints. I was curious if anyone was successfully able to start as utf8mb4 and if it caused any odd behavior or issues. Thanks!
Note this tutorial is heavily adapted from this fantastic Medium post by Stephinmon Antony. Thanks Stephinmon! Motivation Scheduling content to Amazon S3 is one of the many great ways to extract data from Looker. Simply provide your S3 keys, and you send a dashboard, a Look’s visualization, or a Look’s data to your Amazon S3 bucket. In order to enforce uniqueness and to ensure that Looker is not overwriting data in your S3 bucket, Looker appends a timestamp and a unique hash to every piece of content that is sent to S3. So for example, if you’re exporting a Look named User segments to s3, the name of the file in your S3 bucket might be called User_segments_2018-07-23T2014_pVDvGw.csv This is a great way to amass historical snapshots of your data over time. However, you may wish to take the most recent piece of content and do something with it. Looker customers use S3 extracts to programmatically push data to other tools like Salesforce, Gainsight, or Redshift. The ability to do so is co
I’ve noticed that view names longer than ~30 characters get truncated in the project view. Anyone else notice this behavior? Is this new, or has this always acted this way? Because of our naming convention, we have some long names, so to differentiate between files you need to mouse-over currently.
We are using a clustered looker on-premise setup in AWS using an EFS cluster and RDS Database. We have 3 environments: test, stage, and prod. Our developers have been using looker in our test environment and are ready to start using it in the “stage” environment. How do I migrate the looker configuration (views/models/everything) from the test environment to the stage environment? I assume I can zip up everything in the NFS drive in the test env and unzip in the stage? What about the data that is in the RDS DB? Do I even need to mess with that at all? If so, what SQL command do I need to run to save a dump file? Thanks, Alex
Hi, It would be great if under account-> history the HistoryID from Looker was displayed. Having the HistoryID makes it really simple to dig out the query from BigQuery logs. For non admins its really the only way to see their previous query runs (unless they are very quick looking at the queries page since it soon disappears).
Use this post together with the Looker Document Setting Up Version Control to configure your version control with AWS Code Commit. We recommend connecting over HTTPS following these steps: To use AWS Code Commit, you will first need to set up an IAM User with Code Commit Access Sign in to the AWS Management Console and open the IAM console at https://console.aws.amazon.com/iam/ In Users click “Add user” Give your user a name and check the box for AWS Management Console access Choose how you want to set up the password, then click Next: Permissions Under ‘Set Permissions’ choose Attach existing policies directly and search for and select AWSCodeCommitFullAccess then Next: Review Finish creating user with the “create user” button Go find your new user in the Users tab in the IAM Console and click on them Under the Security credentials tab, scroll down to HTTPS Git credentials for AWS CodeCommit and click Generate Download your credentials Next we will log in to Code
Question: Is it possible (or will it become possible) to share a view among multiple sub-spaces? Scenario: One of your sub-spaces is an “Executive Summary” sub-space in which you would like to show high level metrics that would allow the end user to then drill into a look or dashboard in another sub-space (say “Finance” sub-space) with additional details. Current State: If you want to use a single look across multiple sub-spaces, (i.e. a “Top level Revenue” look in the “Finance” sub-space to be displayed in the “Executive Summary” sub-space as well) you would need to copy the look from the “Finance” sub-space and put the copy in the “Executive Summary” subspace then forcing you to maintain two separate copies of the same look whenever making changes. Desired State: A look from one sub-space (or Space) could be displayed in multiple sub-spaces to allow consistency between dashboards and looks, as well as a single look to maintain when changes are required. This would allow for the organ
Hi all, I have the following problem: I’ve shared the “shared” space with all groups in the company. If I don’t do this, then I can’t share the spaces within the “shared” folder with groups that don’t have access to the root (i.e. the “shared” space). This leads to a weird default state where all newly created spaces are by default shared with everyone (if people forget to exclude groups) I would like to have one Looker group (e.g. Investors) that has access only to one space unless it’s explicitly added to a different space by somebody. I can set it up easily. But every time somebody creates a new space, it ends up being shared with all group. Maybe I’m just not doing it right 🙂 Would appreciate any advice. Best, Dimitri
I’m having difficulty getting looker to startup in a clustered configuration. I’ve had looker running off an AWS EFS mount for some time without issues, and now I’m trying to reconfigure it to allow multiple nodes to join. I’ve updated my LOOKERARGS env var to be: LOOKERARGS="-d looker-db.yml --clustered --hostname 220.127.116.11 --shared-storage-dir /mnt/efs/looker/releases/current --scheduler-threads=0" (The current machine I’m trying to start looker on has the IP of 18.104.22.168) When trying to start looker, the console output looks like this: $ ./looker start Starting Looker: Version 5.10.11-cf2e04..................................................ERROR loading provision.yml: User hash is missing or empty. A user is required if no users exist on the Looker instance. .............................................................................................................................................................................................................................
We have a daily report that is emailed out from looker that summarizes yesterday’s data using relative date filters (past 1 complete day). If a user clicks on the “View this data in Looker” link in an older (ex. 3 days ago) email they are brought to the look with yesterday’s data. This is confusing because while the none of the filters have changed, the relative date range is now different and they have to manually change the date range filters in order to look at the same historical range of data (3 days ago for 1 day). If Looker had an option to send out a “permanent” form of a link which turns relative date filters into absolute, a user going through historical data via email link would be able to get looker data consistent with when the email was sent without having to mess with the filters.
Most of the clients I work with find the “grid view” much more intuitive / appealing than the “table view” when browsing content. I’d love to see the default be configurable by each user (personalization), or at a minimum have a global setting for administrators. Right now there is no way to change the “table view” default.
We are using a clustered looker on-premise setup in AWS. In regions that don’t support EFS, we are using our own NFS server as the shared file system for looker. When the NFS server goes down, it negatively affects the looker cluster. I can still hit the login page, even if the NFS server is down, so the login page is not really a good endpoint to tell us if looker is “healthy”. Ideally, we would like to hit a looker health-check endpoint that would let us know if looker is “not healthy”, for whatever reason. (We already have an alert if the looker instances cannot access the NFS mount, but ideally having a health check endpoint would be better, since it can cover more things than just the NFS mount)
Use this post together with the Looker Document Setting Up Version Control to configure your version control with GitLab. Refer to the instructions in the Setting Up Version Control document. You can create a new repository in GitLab by clicking the + icon in the upper right corner of any page and selecting “New Project,” then follow these instructions: https://docs.gitlab.com/ee/gitlab-basics/create-project.html Get the SSH URL for your GitLab repo. The format should look like this: email@example.com:<organization-name>/<repository-name>.git ￼ You can see the SSH URL by clicking on the project’s Details tab. Refer to Step 3 in the Setting Up Version Control document Looker will detect your Git provider and display a deploy key for your repo. (If Looker does not successfully detect your Git provider, it will ask you to choose from a dropdown.) Select the entire Deploy Key and copy it to your clipboard, then click the link under “Add the SSH Key” to visit the SSH K
In Looker 5.18 we are moving away from having a hardcoded bundle of Certificate Authority (CA) root certificates used for outbound SSL certificate verification. Instead, we will be using the Java maintained and supplied CA certificate bundle going forward. What is a Certificate Authority bundle and why does it matter? SSL and TLS are used for end to end encryption over a public channel and to verify that you are talking to who you think you’re talking to. The mechanism that these protocols use to verify the authenticity of the host they are talking to is by certificate signing and verification. A certificate authority is a trusted third party that issues certificates to entities verifying that that entity is who they say they are. By examining an entity’s certificate, you can see which CA signed that certificate and if was signed by one of the CAs that you trust, you can verify that you’re talking to who you think you are. Determining which CAs you trust is done by keeping around a fil
If you are connecting to a git repository via HTTPS and you have Two-Factor Authentication enabled on your git repository account, you will need to use an access key as your password, rather than your account password with username. To set up these access keys: In GitHub: 1. In the upper-right corner of any page, click your profile photo, then click Settings. In the left sidebar, click Developer settings. In the left sidebar, click Personal access tokens. Click Generate new token. Give your token a name. Select repo permissions. Click Generate token. Click to copy the token to your clipboard. For security reasons, after you navigate off the page, you will not be able to see the token again. Use this token instead of your password, with your username, to connect to your repository in Looker. In GitLab 1. In the upper-right corner of any page, click your profile photo, then click Settings. In the left sidebar, click Access Tokens Give your token a name Select api permissions.
Already have an account? Login
Login to the community
No account yet? Create an account
Enter your username or e-mail address. We'll send you an e-mail with instructions to reset your password.