InfluxData Blog - Barbara Nelson

Update: Linux Package Signing Key Rotation

Barbara Nelson (InfluxData) — Tue, 24 Jan 2023 07:00:00 +0000

UPDATE 2023-01-26: As of 2023-01-26, InfluxData’s Linux packaging signing key has been rotated. Users should update their configuration to use the new key.

Original 2023-01-24: On January 4th, CircleCI issued an alert recommending that all CircleCI users rotate their secrets. InfluxData is a customer of CircleCI, and so, out of an abundance of caution, we are proactively rotating all secrets stored in CircleCI.

InfluxData uses CircleCI for various products and the Linux packaging signing key with fingerprint 05CE 1508 5FC0 9D18 E99E FB22 684A 14CF 2582 E0C5 was stored in CircleCI during the time of the exposure. InfluxData will be rotating this signing key and as a result, Linux DEB and RPM users must configure their systems to use the new key.

Official InfluxData repositories have not been compromised, and InfluxData has verified that the software signed by this key and retrievable via official repositories has not been modified. Furthermore, while a hypothetical attacker could use this key to sign binaries that look like they come from InfluxData, the attacker does not have access to the official repositories to deliver them to your hosts.

We are rotating the key signing keys in two phases:

On 2023-01-26 we will start using the new Linux package signing key with fingerprint
9D53 9D90 D332 8DC7 D6C8 D3B9 D8FF 8E1F 7DF8 B07E
On 2023-04-27 we will revoke the the old Linux package signing key with fingerprint
05CE 1508 5FC0 9D18 E99E FB22 684A 14CF 2582 E0C5

Once the new key is rolled out to official InfluxData repositories, DEB and RPM-based Linux systems will no longer be able to download and/or verify software coming from InfluxData repositories until the following configuration changes are made. InfluxData will provide an update to this post indicating when the new key is in place.

Configuring Linux hosts to use the new signing key

The fingerprint for the new key is 9D53 9D90 D332 8DC7 D6C8 D3B9 D8FF 8E1F 7DF8 B07E.

DEB-based systems

Obtain and verify the new key:

$ wget -q https://repos.influxdata.com/influxdata-archive_compat.key
$ gpg --with-fingerprint --show-keys ./influxdata-archive_compat.key
pub   rsa4096 2023-01-18 [SC] [expires: 2026-01-17]
  	9D53 9D90 D332 8DC7 D6C8  D3B9 D8FF 8E1F 7DF8 B07E
uid                  	InfluxData Package Signing Key <support@influxdata.com>

Install the new key:

$ cat influxdata-archive_compat.key | gpg --dearmor | sudo tee /etc/apt/trusted.gpg.d/influxdata-archive_compat.gpg > /dev/null

Update your APT sources to use the new key:

$ echo 'deb [signed-by=/etc/apt/trusted.gpg.d/influxdata-archive_compat.gpg] https://repos.influxdata.com/debian stable main' | sudo tee /etc/apt/sources.list.d/influxdata.list

Cleanup the old key:

$ sudo rm -f /etc/apt/trusted.gpg.d/influxdb.gpg

Confirm that sudo apt-get update returns no errors for https://repos.influxdata.com

The above specifies paths to files and configuration from the most recent documentation. Users who use a different file than /etc/apt/sources.list.d/influxdata.list need to update the file to use signed-by=/etc/apt/trusted.gpg.d/influxdata-archive_compat.gpg. Similarly, users who installed the old key in a different location than /etc/apt/trusted.gpg.d/influxdb.gpg need to use that location to remove the old key.

RPM-based systems

Update your YUM repos configuration to use the new key:

$ cat <<EOF | sudo tee /etc/yum.repos.d/influxdata.repo
[influxdata]
name = InfluxData Repository - Stable
baseurl = https://repos.influxdata.com/stable/\$basearch/main
enabled = 1
gpgcheck = 1
gpgkey = https://repos.influxdata.com/influxdata-archive_compat.key
EOF

The next YUM operation that pulls from the repo will update the key:

$ sudo yum update && sudo yum install telegraf
Importing GPG key 0x7DF8B07E:
 Userid     : "InfluxData Package Signing Key <support@influxdata.com>"
 Fingerprint: 9D53 9D90 D332 8DC7 D6C8 D3B9 D8FF 8E1F 7DF8 B07E
 From       : https://repos.influxdata.com/influxdata-archive_compat.key
Is this ok [y/N]: y

Clean up the old key:

$ sudo rpm --erase gpg-pubkey-2582e0c5-56099b04

The above specifies the configuration path from the most recent documentation. Users who use a different file than /etc/yum.repos.d/influxdata.repo need to update the file to use gpgkey = https://repos.influxdata.com/influxdata-archive_compat.key.

Frequently asked questions

Has customer data been compromised?

After a careful investigation, we have no evidence that InfluxData customer data has been compromised as a result of the CircleCI incident.

Was InfluxData source code or binaries modified?

After a careful investigation, we have not found any evidence of unauthorized modification of InfluxData source code or binaries.

What is the difference between influxdata-archive.key and influxdata-archive_compat.key?

The influxdata-archive.key signing key utilizes a modern primary/subkey approach that will be incorporated into future Linux packaging updates. The influxdata-archive_compat.key can verify packages signed with the influxdata-archive.key and has the widest APT and RPM compatibility. Please use the influxdata-archive_compat.key at this time.

Catering to the Bespoke: How InfluxDB Meets Developers Where They Are

Barbara Nelson (InfluxData) — Tue, 06 Dec 2022 07:00:00 +0000

At InfluxData, we pride ourselves on building a platform – InfluxDB – for developers, by developers. It’s not enough to simply “talk the talk.” As an engineering leader, it’s really important to me that InfluxData “walks the walk,” too. This requires a holistic understanding of our users, their familiarity with time series, the environments in which they work, and the problems they’re trying to solve. Only by examining each of these elements can we provide the variety and scope of tools that enable developers to innovate and build cool things quickly.

The following is a look behind the curtain into how and why we work to serve the needs of developers.

Meeting developers where they are

Oftentimes, platform builders need to decide early on what kind of “shop” they are and develop tooling around a particular programming language. On one hand, this makes complete sense. If users rely on JavaScript, for example, and you optimized your platform to process JavaScript code, then that (hopefully!) makes applications more efficient. But what about developers that don’t know or want to use JavaScript? They’re basically shut out of using this fictitious platform.

When we talk about “meeting developers where they are,” this is the kind of situation we’re trying to avoid. And where a developer “is” varies depending on where they are in their time series data journey.

I’d like to lay out some of our ideas about meeting developers where they are by looking at what tools and resources we currently have to achieve this goal, and how we go about building new solutions to meet the needs of our user base.

Getting started with time series data

The first thing we need to understand is someone’s level of comfort with time series data and time series workloads. The characteristics of these differ in some key ways from the world of relational databases, for example. (We don’t need to get into all the details, but if you’re interested, we offer a training course on the basics of time series data.)

We recognize that today, we’re in a very rich environment where there is tooling and packaging to do all sorts of things. And most developers, when they go to solve a problem, the first thing they do is go to the web and look for solutions that already exist. But putting those pieces together isn’t always as straightforward as you may suspect.

In practice, each of those pieces comes with its own particular nuances. Because it’s rare for developers to build something completely from scratch these days, that means there is often a certain amount of retrofitting that is necessary. Developers must consider the trade-offs presented by different pieces, and sometimes they need to choose between selecting a package that would require them to change the rest of their application or to go without it.

That means part of our job is to help developers “glue” things together easily and efficiently. We are very thoughtful about the fact that we have many developers with many different applications that all need to use time series data in some way, shape, or form. With so many bespoke apps and development tools on the market, it’s vital for InfluxDB to give developers a customized experience tailored to their individual preferences.

If a developer is building an application that presents data to end-users, like climate data from a home thermostat, we may recommend a specific set of tools or best practices that differ from a developer building an application that collects data behind the scenes and analyzes that data to make decisions or trigger actions.

Speaking their language

One of the first considerations we think about is what language(s) our developers know. Just like navigating a foreign country is easier if you know the local language, being able to develop in a language you’re comfortable with can make the app development process faster and easier.

This is why we provide client libraries in over a dozen languages, such as Python, JavaScript, Go, Ruby, C#, R, and more. Developers don’t need to learn a completely new language to use InfluxDB, which lowers the barrier to entry.

Getting data into a database is often the most challenging aspect of working with databases. That’s why we offer half-a-dozen different approaches for data collection, from Telegraf, which has 300+ plugins and can collect data from virtually any source, to the aforementioned client libraries, to scrapers, and third-party ecosystem integrations. And, if none of those suit your fancy, you can always use our REST API and build your own.

We also consider where a developer is in their app-building journey and their comfort level with time series data. The idea is for us to fit in their world as opposed to forcing them into ours. What environment are they comfortable working in? What is their skill set? These are all things we think about in our mission to meet developers where they are.

Another major consideration is where the developer wants their data. Do they want to take care of managing time series metrics and databases themselves, and if so, do they have the security requirements necessary in their own environment? If not, perhaps they’d prefer we help manage it in a cloud environment, but which cloud? AWS, Google or Azure? We offer InfluxDB across all three of these major providers, and in multiple regions. As a result, InfluxDB Cloud frees up developers from managing infrastructure and allows them to focus on what they do best: building cool stuff.

How we continue to improve

Anyone in the development space knows that the industry constantly evolves alongside the needs and preferences of developers. That means the tools they use must evolve as well, and for us, it starts with getting direct feedback from users on how they’d like to use InfluxDB.

In this vein, the developer advocates on our developer relations (DevRel) team act as the first-stage filter for reporting user needs back to the larger engineering team. Our DevRels collect user feedback and spot trends and patterns. We’re not promising to solve every problem that a developer mentions to us. But we’re always listening and learning about what we can do to reduce the friction developers may face using time series data at the core of their applications.

There can be a bit of trial-and-error involved in continually improving the product as well. We use tools such as blog posts and community forums to test the waters with various features and capabilities and see what sticks. If momentum builds around a specific idea, we’re able to go back to the drawing board and see if it’s something we can build and implement.

Ultimately, leveraging open source allows us to interact with a much broader set of developers and to help them build applications for a wider set of use cases. It could be a college student who’s playing around with and learning about time series data, a startup CTO who’s doing something really innovative, or an existing enterprise that has a ton of time series data and needs a better way to manage it.

Creating a platform that meets developers where they are enables us to put developers first and provide them with the tools and resources necessary to progress along their time series journey rapidly, achieving that Time to Awesome we always like to talk about, and driving innovation.

Notebook Sharing

Barbara Nelson (InfluxData) — Thu, 18 Nov 2021 04:00:41 -0700

It’s that season of sharing, and in the spirit of sharing, we have a new feature to share with you – notebook sharing. Now you can take your favorite InfluxDB notebooks and share them with whoever you would like. They don’t need to have an InfluxDB Cloud account. They just click on the link you share with them, and they can see the notebook that you shared, for the time range that you selected. Check it out by clicking on this link to see a really cool IFTTT integration that one of our developers, Gene Hynson, built to monitor sound and motion detected from his Wyze camera.

You can learn more here about how he is monitoring his home.

If you’re not familiar with notebooks, they are a recently added feature in the InfluxDB UI to make it easy to build a Flux query, validate the query results, add some visualization, add explanatory notes, and then incorporate your query into a task, your client application, or wherever else you would like to use it. To learn more about notebooks, check out the documentation.

Another cool feature in notebooks is that you can display them in presentation mode. So, you can have a notebook with all sorts of query panels, visualizations, and other commentary, and then flip the presentation mode switch, and we just display the visualizations, the commentary, and we hide the rest of the notebook. Looks like a dashboard, but built into the notebook. Flip the presentation mode switch back, and you can see all your notebook panels again.

So, now that I have built a cool notebook, how do I share it? It’s very straightforward. Login to your InfluxDB Cloud account, and open the notebook that you want to share. If you haven’t saved it already, hit ‘save notebook’. In the upper right corner, there is a new option, circled in red in the screenshot below, to share the notebook.

When you click on the share option, you will need to select a token with read-access to the resources you are referencing in your notebook. That will be used to authenticate access when the shared notebook is displayed.

Once you have selected the token, we generate a URL that you can use to share the notebook with whoever you would like.

Just copy the URL, paste it into your browser so you can see the final result, and then share it to your heart’s content. If you want to stop sharing, just select the ‘delete’ option next to the URL, and that will delete the share link, or deactivate the token you used to generate the URL. After that, anyone who tries to use the link will get an error message.

If you don’t want to share the query, and just want to share the visualization, just flip the notebook into presentation mode, and then generate the share link. Now the shared notebook looks like this – no queries, just a pretty graph.

Give it a try, and you can also send the share link my way (email me at bnelson@influxdata.com), as I’d love to check out your notebooks. We are always looking for interesting uses of time series data.

Here are a few common questions about notebook sharing.

How much does it cost?

It depends on your account. If you have a free account, there is no cost, as long as the total usage stays within the rate limits of your free account. After that, the queries will be rate-limited, just as if you had been looking at the notebook yourself. If you are on a pay as you go (PAYG) or an annual account, you’ll be charged for the queries, each time the shared notebook is rendered, in exactly the same way as if you had hit ‘run’ in the notebook.

How do I stop getting charged for a shared notebook?

If you want to limit access to the shared notebook (maybe that shared notebook link is getting a lot more popular than you had imagined), you can just delete the share link from the notebook, or deactivate the token associated with the share link, and anyone who clicks on it will get an error page.

Can someone use my token to access other data in my account?

No. When you generate the share notebook URL, you are asked to associate a specific token which is then associated with the share URL. In theory, any token in your account with the appropriate bucket access permissions can be used. However, in practice we recommend creating a specific token to use with the share URL – so that you can retire this token if and when you are done sharing. The token is not included in the URL. Instead, behind the scenes we create an access key. When anyone clicks on the link, we match up the access key to your token, and if it is still valid, we run the queries and display the notebook.

What if I modify my notebook after sharing it?

Any changes made to your notebook will be immediately available through your share link. This keeps the share link completely up to date with your notebook so you don’t need to worry about people looking at an out-of-date notebook. One thing to be aware of is that if you switch the notebook to presentation mode, and generate the share link, and then switch back, the share link switches back too, and will display in non-presentation mode. The presentation mode is part of the notebook, and the share link keeps in sync with that too.

Can I have more than one share URL for the same notebook?

Not at this time. Let us know why you might want that, and we can see about adding it in the future.

Can my colleague and I generate different share URLs for the same notebook?

Not at this time. Once the share URL is generated by one user, other users in that organization can see and share the URL, but they can’t generate another URL until the first URL is deleted. Let us know if you have a use case where different users within the same organization might want to have different share URLs.

Can someone who has the share link change or delete my notebook?

No, the link only gives them read-access to the shared notebook, for the time range you selected. They can’t make any changes to the notebook, or modify the time range. They can only see the data you have chosen to show them.

Does my shared notebook always show up-to-date data?

It’s up to you in how you set up the notebook. If the time range in the notebook is relative (e.g. last 6 hours), they’ll see the last 6 hours of data whenever they click on the shared notebook URL. If they click on it tomorrow, they’ll see tomorrow’s data. If the time range is fixed (e.g. October 1, 2021 to October 23, 2021) they will see the same data, for the same time range, no matter when they click on the URL. So, you get to control what data they see – a fixed time period or a relative time range.

If I delete or inactivate the token I used to generate the share URL, will the share URL still work?

No, the share URL only works while the token is valid. If you delete or inactivate the token, you will need to select a new token and re-generate the share URL.

Will the URL still work if I delete the notebook?

No, the URL is associated with the notebook, and if the notebook is gone, there is nothing to show.

What about dashboard sharing?

We started with notebook sharing, and we would love your feedback on how well it works for you. You can use presentation mode in your shared notebook to focus on the visualization of your data. We know it’s not exactly the same as dashboard sharing, but it’s a starting point.

Plant Buddy Part 4: Using the UI

Barbara Nelson (InfluxData) — Fri, 09 Jul 2021 02:00:27 -0700

My colleague, Rick Spencer, has been working on an interesting IoT project, Plant Buddy. This project entailed soldering some sensors to an Arduino, and teaching that device how to communicate directly with InfluxDB Cloud so that he could monitor his plants. Then he developed an app that allows users to visualize and create alerts from their uploaded Plant Buddy device data in a custom user experience.

To understand more about Rick’s project, you can check out Part 1, where he designed the basics of the device and taught it to communicate and add some notifications; Part 2, where he added downsampling and a dashboard; and Part 3, where he built an app for plantbuddy.com.

When I was reading Rick’s blog, I was impressed with how powerful our CLI is, making it easy for Rick to create a bucket, generate a token, write data, query the data, and set up checks and notifications. For someone who is familiar with working at the command line, it’s pretty intuitive. But as the head of the UI team, I wanted to see what the experience would be for someone who wanted to use the UI, not the CLI for the same functionality. So, below is a companion blog to Part 3, using the UI instead of the CLI for those of us who are more UI-centric.

Many thanks to Rick Spencer for doing the work to build a very cool IoT application to manage his growing garden (and keeping an eye on my plants too).

Bootstrapping IoT application development for InfluxDB Cloud

Rick has already created an InfluxDB Cloud Account, so I asked him to invite me to his account so that we could work with the same data. Once I accepted the invitation, I was all set, and I was able to log into his account. As I need a different email address for each InfluxDB Cloud Account that I want to access, I am using bnelson+plantbuddy@influxdata.com for this example.

I will need a token to be able to write my data into this account. Rick already has a token, but I need one for my use as tokens are specific to each user. Rick has created a bucket, plantbuddy, so I need a read/write token to be able to write my data to his bucket. Just like Rick did, I navigate in the UI to Data -> Tokens to generate my token.

I click Generate Token and choose a Read-Write Token for the plantbuddy bucket, and provide it a name, plantbuddy read-write token.

Upload some Line Protocol

Now that I have access to the bucket, I can upload some data to it so that I can start testing right away. Rick gave me a Python script that I could use, so I set the user field to barbara and the device_id to 02, so my metrics could be filtered from Rick’s metrics. I copied the read/write token that I had just generated to my client environment, and ran my Python script to generate and upload some test data.

The line protocol format is well-documented. Here is an excerpt of what my data looked like:

soil_moisture,user=barbara,device_id=02 reading=157i 1623622366752460032
humidity,user=barbara,device_id=02 reading=69i 1623622366752460032
soil_temp,user=barbara,device_id=02 reading=66i 1623622366752460032
light,user=barbara,device_id=02 reading=36i 1623622426752460032
soil_moisture,user=barbara,device_id=02 reading=153i 1623622426752460032
humidity,user=barbara,device_id=02 reading=68i 1623622426752460032
soil_temp,user=barbara,device_id=02 reading=67i 1623622426752460032

I used the write endpoint to write my data from a Python script. I could have used the UI to upload my data, but given that I was using a Python script to generate the test data, it was just as easy to call the write endpoint directly, rather than writing my data to a file and then uploading the file via the UI.

No error was reported, so it looks like it worked, so then I ran a query to make sure.

Run a query

The Data Explorer lets me easily confirm that my data is in the plantbuddy bucket.

Alternatively, I can use the metrics selector in the notebooks UI to see what metrics are in the bucket. I confirmed that my data is there, ready to be analyzed and acted-upon.

Downsampling

Downsampling entails calculating lower-resolution data to display from the high-resolution data, and saving that off pre-computed for displaying or further calculations. Other than making for a snappier user experience, it can also save you storage costs, because you can keep your downsampled data in a bucket with a longer retention period than your raw data. Rick used the CLI to create a downsampling bucket, author his downsampling script, and create a task to run the script. I took an easier approach, and used the notebooks UI to create the task that will downsample my data. I selected my metrics, then added a ‘downsample’ panel to aggregate the data every 10 minutes, and configured an output panel to write the result to the downsampled bucket.

Querying the downsampled bucket, I can see all the data is there.

Create a downsampling task

Once I confirmed that the downsample was working correctly, I took my notebook, and registered it as a task to run every 15 minutes, by adding a schedule panel, and configuring it to run every 15 minutes. I also changed the range to only look back for the last 15 minutes, so that I don’t downsample data more than once.

When I export as a task, I can see the generated Flux code:

And I can see that it ran successfully, along with some other useful information, such as what Flux was actually run.

Notifications

The final feature that Rick added is the ability for plantbuddy.com to notify users if their soil gets too dry. With InfluxDB you can use tasks to create status checks and notification rules that will send a message to your application under whatever conditions you define. I decided to use the UI to set up my status checks and notification rules.

Threshold Check

I go to the Alerts option in the UI to set up my check. There are three parts to it:

Defining the check
Configuring the notification endpoint
Defining the notification rule

To define the check, all I have to do is select the field that I want to check, and the frequency at which I want to check it. I select my soil_moisture field.

I configure the check to run every 10 minutes. I set the status to CRIT if the soil_moisture value is below 35, and set the status to OK if the soil_moisture level is above 35.

The second step is to set up a notification endpoint that can be notified when the plant needs watering. As Rick has already configured a HTTP endpoint, I’ll just use that one, so he can be reminded to water my plants. :-)

I select HTTP as the endpoint, provide the URL and I’m all set.

Now that I have a check and a notification endpoint, I can define my notification rule. I set the rule to check the status every 10 minutes, and notify Rick whenever my plant’s soil_moisture

level is critical.

To test that everything is running, I write some test data with a low value for the soil_moisture, and I can see that the alerts fire.

Whenever the level was critical, a notification was sent to Rick’s HTTP endpoint.

I hope you found this blog useful to show you the power of the InfluxData platform. Whether you choose to use the UI, the CLI, the API or any combination thereof, you should be able to build your own application to gain intelligence and act on your time series data.

Why I Joined InfluxData - Barbara Nelson

Barbara Nelson (InfluxData) — Wed, 04 Dec 2019 07:00:55 -0700

Hi! I am Barbara Nelson, and I joined the engineering team last month, as Head of Applications (I’m Rick Spencer’s peer on the apps side). If you look at my LinkedIn profile, you might wonder how I ended up at a time series DB company, given that for most of my career I’ve been in the Wi-Fi space (except for a brief stint in eCommerce).

When I was growing up, one of my favorite fairy tales was Goldilocks and the Three Bears. Goldilocks gets lost in the forest and stumbles across a home owned by three bears. She tries their porridge (one bowl is too hot, the second is too cold, and the third is just right). She gets tired and lies down on their beds (the first bed is too hard, the second is too soft, and the third is just right so she settles in for a nice nap). I won’t give you the rest of the story, or say too much about the appropriateness of Goldilocks’ behavior (breaking into someone’s home, eating their food and sleeping on their bed is probably not a good idea in this day and age), but as a child it appealed to me as a way to make decisions — consider the alternatives and choose the one that fits you the best.

So how does this relate to InfluxData? I feel that I have found the company that is just right for me — not too big, not too small. InfluxData is just right. I’ve worked in very small companies where everyone knows everyone, and it’s easy to work together without too many processes or procedures. I’ve also worked in a very large company, where there are lots of processes in place to help you navigate the organization, figure out which teams are responsible for which products, and enable you to actually get things done. Lots of people love working in large companies, lots of people love working in very small companies, but for me, InfluxData is just right. We are growing fast (and hiring some great people), so relying on everyone knowing everyone else isn’t working as well as it used to.

I’m excited to be joining the engineering team at a time that we get to figure out what adjustments to make to ensure that all the new additions are just as effective as the engineers who started here a long time ago. We are very fortunate that those earlier engineers are excited to support the new team members, so we can continue to deliver great products, leveraging the skills that the new folks bring, along with the experience of people who have been here for a while. I love working with teams to figure out how best to work together, so that as we continue to grow, the company will continue to be just right for everyone who is here.

We use the phrase “time to awesome” at InfluxData to mean the time it takes a new customer to get an awesome experience with our products. My own “time to awesome” has been the time it has taken me to confirm my first impression that this is an awesome company. With the great welcome that I got from everyone here, my “time to awesome” has been pretty short.

If it sounds like InfluxData could be just right for you, please check out the Careers page and apply.