Getting Started with LuaRocks and Cloudsmith

A short demo of how to get started with LuaRocks modules and Cloudsmith, including uploading a LuaRocks module to a private Cloudsmith repository and then downloading and installing it.

https://help.cloudsmith.io/docs/luarocks-repository

At Cloudsmith we love playing video games, everything from Super Meat Boy to Halo, Fortnite to Candy Crush. We’ve got a big Pac Man money box sitting on the office shelf. Steve Collins, of Havok fame, is on our Board of Directors. Quite simply, gaming is in our DNA.

When we started Cloudsmith we made a list of customers we’d love to work with someday and there were numerous games studios on the list. It was a proud moment for the team when the first games company signed up to distribute its software globally. Since then more major studios have followed suit. It’s truly exciting to be a part of the deployment and delivery process for companies we really admire.

We pay homage to a few video game greats with our pop culture banners in our documentation; see 

. Can you guess the games on which each is based?

Cloudsmith can solve many problems for games companies, but what is most unique about a games company is that they are the software companies that can make use of all three of our primary use cases:

The beating heart of any games company is its Intellectual Property. Now, of course, this consists of game characters, themes, and franchises, but it also consists of a lot of proprietary code, libraries and packages, game engine components, and sound and graphic assets. Protecting this IP, while also granting globally distributed internal development teams easy access so that they can work with it is a major challenge. Cloudsmith private repositories allow a games company to centrally manage its software assets, provide secure access for development teams worldwide, and also deliver performant global availability.

A games company requires a lot of infrastructure to operate effectively. Significant resources are required to facilitate both internal development teams and any customer-facing environments for matchmaking and multiplayer services. This may take the shape of on-prem servers or cloud-based environments, but building and managing this infrastructure is a complex task. Even when automated through tools such as Terraform, Ansible, Puppet, Chef, and others, it still requires that these tools have a central source-of-truth for the packages and modules that they require. The universal package support offered by Cloudsmith means that it is easier for internal DevOps teams to manage these builds and deployments.

Games companies often need distribution of software assets and packages for a few different use cases, like distribution of software assets to licensed customers or distribution of packages and libraries to 3rd party development partners. To do this, they require fine-grained control over access, and visibility into download activity and usage. Cloudsmith’s extremely flexible Entitlement Token system allows the creation of unique, read-only access tokens that grant access to specific packages or assets. These tokens can have multiple restrictions attached, such as limiting access to specific packages, for a specific timeframe, from specific locations, and even a maximum number of downloads or bandwidth use. Any read activity on the repository is attributed and associated with an Entitlement Token and therefore users can be precisely monitored and analyzed.

As an example, we’re solving two use-cases for one such customer:

Supporting the management of Debian deployments to their IT infrastructure, including isolating public packages through our recently launched Upstream Proxy & Caching feature,

Enabling the distribution of private core dependencies to their partners, which utilizes our Entitlement token system.

As we mentioned, we love playing video games, and being part of the deployment and delivery process for companies that create them is something we’ll be forever excited about. Whether it’s 

, or the full trifecta, Cloudsmith is here to help support and solve many of the problems games companies face all in one platform.

Don’t just take our word for it though - 

Games are in our DNA

Just when you thought it was safe to go back in the water...

Is there anything more frightening than the unknown? Anything the mind can conjure up is frequently scarier than something realized. The shark in Jaws is terrifying because you don’t see it until it’s too late. It’s a silent, relentless death machine, hiding in the water.

A software vulnerability is the unknown, hidden deep within an ocean of code, packages and container dependencies. Once exposed, you’ve no protection, you may have already lost data, or given someone continued access to sensitive information or processes. Even worse, do you know if you are exposed?

Software, by its very construction is like a boarded up wooden house in a Zombie movie. You’re trapped, zombies are roaming around outside trying to get in, clawing at the doors and windows, ripping off hastily nailed-on boards, creeping under the floors in the crawlspace, searching for an opening. It’s a living (dead) nightmare.

Why would you want to be the one tasked with securing the house, patching the holes, letting the frightened neighbors in? Who wants the responsibility of ensuring everyone's survival?

It happens to all of us eventually. You make one tiny change. The PR is approved. It passes QA. It gets rolled out to staging. Everything looks healthy. It’s good to go. It gets rolled out to production late on a Friday afternoon. It's a simple change. What could go wrong?

A few moments later, the app seems slow. The processing queues are backed up a little, but are within the margins. A warning pops up that you haven’t seen before. You start to investigate. A few minutes later, the first error is flagged. A few moments after that, the first customer asks if there is anything wrong. Then the second.

Suddenly, the database is running hot. The queues are backed up beyond acceptable levels. Something is broken. Badly broken. But it just couldn’t be that simple change, could it?

Deep down, in the darkness and silence, you know the truth. These problems are systemic and common. You need to address these concerns; a control plane for security vulnerabilities, a way to quell the total cost of ownership of running a key part of your automated workflows, and the assurance of building repeatable DevOps processes to make sure that final deployment is trivial and quick to rollback if needed. You need a weapon built for the times.

DevOps Horror Stories: Repository of Horror

Getting Started with Maven and Cloudsmith

A short demo of how to get started with Maven packages and Cloudsmith, including deploying a Maven package to Cloudsmith and then downloading it as a dependency.

https://help.cloudsmith.io/docs/cran-repository

The following is a true story. It doesn’t have a happy ending.

Horrors lurk beneath the trap door, for there is always something down there, in the dark, waiting to come out...

The Thing Upstairs glares across the conference table, already knowing the horrible truth, “What license does it have?”

Berk confidently replies, “GPL version 3.”

Berk is an experienced software developer at a well-known consultancy firm, TrapDoor Inc. He’s worked his way up the ranks, paid his dues, and has been given his first solo project.

A customer has asked TrapDoor Inc. to architect and build a software tool. The problem specification is well-defined, but the solution design, architecture, and implementation details can all be decided by Berk.

The high-level design gets approved, and Berk gets to work. The agreement with the customer is to release often and early as they too are a software consultancy and can run tests internally and externally on their customers’ sites.

After about five weeks of development, the first alpha is released.

A week after that, the third iteration is released to much fanfare. Good, steady progress is being made.

Only then does The Thing Upstairs stir and decide to code review Berk’s solution. The findings are shocking. Berk’s solution relies heavily on an open-source project with a copyleft GPL v3.0 license.

Copyleft is the practice of granting the right to freely distribute and modify intellectual property with the requirement that the same rights be preserved in derivative works created from that property.

Berk has spent seven weeks writing logic that is attached to the original license, not fit for commercial handover, and now likely being run illegally on customer sites, without the proper license or attribution.

Worst of all, the original source code for the dependency was copied into a TrapDoor Inc. repository and modified with Berk having explicitly deleted the license file.

Little could be done without a page-one, clean-room rewrite, using a dependency with a more permissive license. But we’ll never know. This story doesn’t have a happy ending. Trust was lost. The six-figure project was canceled. The customer refused to pay.

All because Berk didn’t think licensing was important.

DevOps Horror Stories: Software License to Kill

In keeping with our vision of offering a universal feature set across all the package formats we support, we are delighted to announce that we are now offering configurable upstream proxying and caching support for 

As we touched upon when announcing the same for Debian and 

 packages, there are a lot of reasons why this is a really 

, so instead of going over those again, let’s jump straight into how you can set this up in you Cloudsmith repository.

We don’t think that we could have made this much easier to configure (but, of course, we would love to hear 

In your Cloudsmith repository, you’ll see a menu item called “Upstream Proxying”. This is where we will configure our upstreams. Simply click the “Create Upstreams” button and select “RedHat” to create a new RedHat upstream:

You will then see the “Create RedHat Upstream” form:

You just need to add a Name for the upstream, the upstream URL, and a priority weighting – If you have multiple upstreams this will determine the order in which they are used.

We can choose to fetch and cache any requested package (instead of just fetching them), and to verify the SSL certificates provided by the upstream. Then, we select the individual distribution for this upstream.

Optionally - we can also add a GPG key, if required, for package signing, authentication headers for private repositories that require authentication and also some arbitrary headers if you wish to send something custom along with your request.

And that’s it, we have now added a new Redhat upstream to our Cloudsmith repository.

So now, the next request for a package that isn’t present in this repository will be passed through to the upstream and the package fetched it if it is available there. If you also enabled “fetch and cache”, the package will be cached in your Cloudsmith repo for any future requests.

By adding Redhat upstream proxying and caching, we are moving forwards towards our goal of being the most universal package management solution for your development, deployment and distribution workflows. We would love you to join us on this journey, and we are very excited about the platform we have built, the service that we provide, and where we are going to next. Sign up for free today, and experience Cloudsmith for yourself!

Caching and Upstream Proxying for RedHat Packages

Teams and Access Controls

A short video to show how to set up teams and configure access permissions in an organization on Cloudsmith.