Forem: Felix Vaucourt

Proxmox: Resize Your Local (pve) Disk

Felix Vaucourt — Wed, 30 Oct 2024 14:45:24 +0000

Ever wondered how to resize your local (pve) disk after a fresh install or when adding a new disk to your homelab setup?

The storage section for this is located in pve-root, and you can easily extend it using LVM. After that, you'll need to resize your filesystem as follows:

lvresize /dev/pve/root -L +<size>G

# if you are using an ext4 partition
resize2fs /dev/pve/root

# if you are using a xfs partition
xfs_growfs /

Replace <size> with your desired size (in GB)

This process is particularly useful if you have a two-disk setup and want to dedicate one disk solely for local storage, while using the other for all your containers/VMs.

If you have any questions, feel free to hit me up on Twitter.

Happy Coding!

Deploy Your Website with GitHub Actions to Uberspace (the rsync way)

Felix Vaucourt — Tue, 29 Oct 2024 21:30:28 +0000

Deploy Your Website with GitHub Actions to Uberspace (the rsync Way)

I am hosting my website on a personal and sustainable webspace at Uberspace.

As a side note, the content I upload is a static HTML website, which is what we will cover in this guide.

In this tutorial, I’ll show you how to automatically build, deploy, and update my content whenever I push to the main branch of my GitHub repository.

Disclaimer: the tutorial is written for Unix systems

I've been using Uberspace for quite some time now. One feature that initially attracted me was the "pay what you want" model, allowing users to pay any amount per month—even as low as 1€. While any amount is accepted, Uberspace recommends at least 5€/month, as it costs them approximately 10€ per month per user to cover expenses.

In addition to flexible pricing, Uberspace provides daily and weekly backups, SSH and SFTP access, HTTPS for all domains, and most impressively, all their servers run on green energy.

In a nutshell, this hosting provider offers:

a developer-friendly server with excellent documentation
european-based servers, so I don’t have to rely on US-based providers
full control over my personal webspace

Warning: this GitHub Action will overwrite files on Uberspace that are not visible in your GitHub repository. Ensure you back up your data or set up a sub-folder on your webspace before proceeding.

Steps:

Create new SSH keys on your local machine
Create the GitHub Action
Configure GitHub Repository Secrets: user, host, and generated private key
Upload your generated public key to Uberspace
Test the setup

Step 1: Create New SSH Keys on Your Local Machine

To transfer files to our webspace, we need a dedicated pair of SSH keys.

You can create these on your local machine or directly on Uberspace. For simplicity, we’ll create them on our machine.

First, create a new folder in your Documents directory to hold your keys:

cd ~/Documents
mkdir uberspace-ssh-keys
cd uberspace-ssh-keys

Now, generate the key pair. You can rename github-uberspace-keys to something you prefer:

ssh-keygen -f github-uberspace-keys -t ed25519 -a 100

Leave the passphrase blank by simply pressing "enter"

Verify that the keys were generated correctly:

ls -l
-rw-------  1 felvct  staff   399B May  5 23:08 github-uberspace-keys
-rw-r--r--  1 felvct  staff    93B May  5 23:08 github-uberspace-keys.pub

Now we can move on to the exciting part: setting up our GitHub Action!

Step 2: Create the GitHub Action

Open your GitHub repository in your favorite IDE or text editor and create a deploy.yml in .github/workflows:

# in the root of your repository
mkdir -p .github/workflows && touch .github/workflows/deploy.yml

Since we’ll be deploying files to a remote location via rsync over SSH, we’ll use the burnett01/rsync-deployments GitHub Action:

on:
  push:
    branches:
      - main

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Rsync Deployments Action
        uses: Burnett01/rsync-deployments@7.0.1
        with:
          switches: -avzr --delete
          path: static-site/*
          remote_path: /home/${{ secrets.UBERSPACE_USER }}/html/
          remote_host: ${{ secrets.UBERSPACE_HOST }}
          remote_user: ${{ secrets.UBERSPACE_USER }}
          remote_key: ${{ secrets.DEPLOY_KEY_PRIVATE }}

Note: The path is your local path in the repository, and the remote_path is the path on Uberspace.

Step 3: Configure GitHub Repository Secrets: User, Host, Generated Private Key

You’ll need to save the private SSH key you created at the beginning (github-uberspace-keys) in your GitHub repository as the DEPLOY_KEY_PRIVATE secret. This key will act as the deploy key ({{ secrets.DEPLOY_KEY_PRIVATE }}).

Print out the key to copy it:

cat ~/Documents/uberspace-ssh-keys/github-uberspace-keys

Add it as a secret named DEPLOY_KEY_PRIVATE in your repository’s secrets.

The next two secrets — your username and the hostname of your Uberspace server — can be found on your Uberspace Dashboard. Create the following:

A secret named UBERSPACE_HOST, which is your hostname.
A secret named UBERSPACE_USER, which is your Uberspace username.

Step 4: Upload Your Generated Public Key to Uberspace

Finally, we need to upload the generated public key to Uberspace.

Print and copy the public key:

cat ~/Documents/uberspace-ssh-keys/github-uberspace-keys.pub

For the next step, SSH into your Uberspace account. If you haven’t set an SSH password yet, set one on the Uberspace Dashboard under the “Access” tab.

Once SSH is configured, connect to your Uberspace:

ssh <YOUR_UBERSPACE_USERNAME>@<YOUR_UBERSPACE_HOSTNAME>

Replace <YOUR_UBERSPACE_USERNAME> and <YOUR_UBERSPACE_HOSTNAME> with your Uberspace credentials.

Navigate to the .ssh directory and update the authorized_keys file:

cd ~/.ssh
ls -l

If you don’t see an authorized_keys file, SSH may not be fully set up for your account. You can refer to the Uberspace documentation for guidance.

Now, add your public key to authorized_keys and restrict access so it’s only allowed to rsync to your html directory.

Open the file with nano:

nano authorized_keys

Add the following line, replacing <username> with your Uberspace username and <CONTENT_OF_YOUR_PUBLIC_KEY> with your public key:

# GitHub Actions key for <your_repository/project>
<CONTENT_OF_YOUR_PUBLIC_KEY>

Save the file by pressing CTRL + O, confirm with "Enter," and exit nano with CTRL + X.

Step 5: Test the Setup

Push a change to your main branch, and you should see your action automatically running in the “Actions” tab.

If everything went smoothly, you should see a green checkmark next to your latest action, and your content should be live on your webspace.

Once everything is running, it’s a good practice to delete the generated SSH keys from your local machine and store them securely in a password manager (like Bitwarden).

If you have any questions, feel free to hit me up on Twitter or on GitHub.

Happy Coding!

NPM CLI Tips & Tricks

Felix Vaucourt — Mon, 27 Dec 2021 15:44:24 +0000

If you are reading this, I am going on a whim and I will assume that you are using npm.

Even though, this package manager comes with a fair amount CLI commands, the chances are pretty high that you are using the same couple of ones in your day-to-day job.

You are most likely familiar with installing and deleting packages either on a global level (accessible from anywhere on your machine) or on a local level (think of the package.json in your projects).

But do you really know which and how many packages are globally installed on your workstation? To be quite honest, probably not.

Let's dive into it by listing all your global packages:

# for npm v7+
npm list -g

# for npm v6 and less
npm list -g --depth 0

hint: -g is the shorthand for --global. You can execute all of the commands below for your local packages by omitting the -g flag. And instead of using list you can use ls.

Output:

<your_user>/.nvm/versions/node/v16.13.0/lib
├── corepack@0.10.0
└── npm@8.1.0

The installation path of the displayed packages will always be printed out at the top of the list

The --depth 0 flag hides the dependencies of each installed package. Since npm v7, this is the default behavior of the npm list command.

If you wish to see all packages, including their dependencies, simply add the --all flag:

npm list -g --all

Furthermore, the depth flag isn't restricted to 0. In fact, the trailing number represents the level of nested dependencies that you want to see. If you are interested in the top-level dependencies of your global packages, you would use the following command:

npm list -g --depth 1

On a side note, if you installed a package in a custom location, using the --prefix flag, then you will need to add the same flag (including the path) when running the npm list command.

If you are looking for a specific package, either locally or globally, to check its version for example, you can combine npm list with grep:

npm list -g | grep <package>

# example
npm list -g | grep rimraf

Now that we know how to list our packages, wouldn't it be great to see if they are all up-to-date? No worries, there is a command for that as well:

npm outdated -g

Do not forget to add --depth 0 if you are using npm v6 or less

This will output what packages are outdated, what their latest available versions are and where they are installed.

Since we just talked about the outdated function, let's jump right into update.

Thankfully, npm is smart enough to update all the packages to their latest version, respecting any constraints of both the package and its dependencies.

Firstly, let's see how we can update a single package:

npm update -g <package>

# example
npm update -g @angular/cli

By omitting the package name, all packages in the specified location (global or local) will be updated:

npm update -g

That is it. This will update all your packages and install new dependencies if needed. Easy as pie.

Let's take another scenario. Imagine that you are currently developing a project and you know that you need a specific package, let's say express, and you want to see what remote versions are available to you, then you would do:

npm view <package_name> versions

# example
npm view express versions

Be aware that versions is plural. This will give you a full listing of available versions.

On the other hand, if you are only interested in the latest remote version, use:

npm view <package_name> version

# example
npm view express version

Note: version is singular here

Now that we know what package and what version we need, we can install specifically that:

npm install [-E] <package>@<version>

# example for a specific version
npm install [-E] express@4.16.4

# example for the latest version
npm install [-E] express@latest

The optional -E flag (shorthand for --save-exact) will install and save the specific version of a package rather than using npm's default range operator.

Using fixed versions within your projects is generally a good idea. In the unfortunate case that a release of a package ships with breaking changes (spoiler alert, that happened to me once - only a new minor version was released but the API of the package completely changed), this will not affect your builds. Or as we saw in recent events, some npm packages are shipped with malware or other harmful software. Being on fixed version gives you a peace of mind regarding those kind of problems.

Last but not least, if you are in need of doing a clean install of your dependencies (think of continuous integration, deployment, test platforms and so on), take usage of npm ci.

This command is also significantly faster than npm install.

I will not reinvent the wheel for this one, so the upcoming statement is straight from the official documentation:

"In short, the main differences between using npm install and npm ci are:

The project must have an existing package-lock.json or npm-shrinkwrap.json.
If dependencies in the package-lock do not match those in package.json, npm ci will exit with an error, instead of updating the package-lock.
npm ci can only install entire projects at a time: individual dependencies cannot be added with this command.
If a node_modules directory is already present, it will be automatically removed before npm ci begins its install.
It will never write to package.json or any of the package-locks: installs are essentially frozen."

There are quite a few more CLI commands for npm out there. So it doesn't matter if you are new to npm or if you are using it for long time, mastering a tool always comes with a steep learning curve. This is especially true with CLI commands, since it is not a given to know most of the flags and to know what they are telling the underlying tool to do.

Nonetheless, I hope that with those tips & tricks, you will be able to get the most out of your npm experience. Try to keep track of your global packages and to get rid of anything that is no longer needed.

Another good tip for npm users, is the usage of npx but that is a topic for a standalone article.

If you have any questions, feel free to hit me up on Twitter or on GitHub.

Happy Coding!

Get the most out of your (remote) pair programming sessions

Felix Vaucourt — Tue, 14 Dec 2021 17:47:11 +0000

Most of us have heard of it and most of us have used it: pair programming.

In the good old pre-covid days, pair programming involved two developers working simultaneously on the same machine. Nowadays, we tend to make it work with two separate computers, in two separate locations with the help of screen sharing but the principle remains the same. One developer, the driver, should write code while the second developer, the navigator, reviews the typed code in real time. Those roles should be changed frequently in order to keep the dynamic of the pairing session up.

The idea behind this approach is that a higher output is being generated since teammates will be working together to solve an issue rather than working in silos. Furthermore, the constant communication in the pair allows to find the best solution, share knowledge between both parties and therefore quickly move through faced challenges.

Benefits of pair programming

Pairing up can be more than just working on a ticket. It gives team members the opportunity to catch up and talk about their lives outside of work. The social aspect of it shouldn't be neglected, especially now that companies are shifting more and more towards remote work and engineers are getting less and less contact with their teammates.

You know the old saying, two heads are better than one. You should be able to freely share and discuss your thoughts and ideas on how to solve a problem. This will allow you to see the problem more clearly and to pool the knowledge of both parties to get the best outcome possible.

The knowledge sharing that takes place during those sessions is another important aspect of pair programming. It will allow you to either learn or teach coding practices and how to approach and handle problems from another perspective. This will not only increase the efficiency but also the innovation and the code base knowledge while decreasing the silo knowledge within the team.

Last but not least, being on "the same skill level" is not a requirement for pair programming. Pairing up a junior developer with a senior developer will benefit either of them. The junior developer will gain a significant amount of industry knowledge while the senior developer will be rewarded with a teaching experience while sharpening his/her competence to critically think about solutions.

Drawbacks of pair programming

Until now we only spoke about the advantages of pair programming, but overdoing it can lead to inefficiency. Constantly pairing up, even for the smallest tasks and the tiniest bug fixes will lead to the navigator being left out. The communication will be non-existent since the implementation will be straight forward.

A higher output would be generated if both developers would work on different tasks at the same time and not in a pair.

Remote pair programming

Unlike other methods of in-person collaboration, pair programming works really well in a remote context. You don't lose anything of the pairing experience, you may even find it more effective.

Use the advantage of not physically sitting next to your colleague. Thanks to screen sharing you will have more control of what you are looking at instead of working on one persons's screen.

Tips for remote pairing sessions

Know when to pair

Working in an isolated, remote environment is a great experience when one is "in the zone" but having no one to talk to when you really linger on an issue makes the whole experience more difficult and frustrating.

When a task is giving you a hard time and you are not able to generate any output or to create some sort of progress on it, it is time to pair up. Do not be afraid to ask for help.

Keep in mind that anyone can benefit from pairing up when being stuck on a problem.

Agenda

No one likes to waste their time, this is why every meeting should have an agenda and a scheduled pair programming session is no exception to the rule.

Do not spend the first 15 minutes of the session deciding on what to work on or going through several tickets in order to understand the problem to tackle.

Set goals or expectations (this can be as simple as "let's discuss our options and decide on what path to take"), both developers should be on the same page about what to do and about what to focus on during the session.

Communication

Do not be afraid to freely and openly speak your mind. Even if you say something wrong it helps the process, you will tackle the problem more quickly. By being corrected, a new idea may be sparked by you or your partner which will ultimately lead to a solution.

Bounce of each other ideas and pool your knowledge in order to get the best outcome.

Use your tools

Several IDEs and text editors have tools dedicated to remote pair programming. Do yourself a favor and use them. It will give you more interaction than through screen sharing alone and therefore making the whole experience more enjoyable.

Here are some tools and plugins:

Retros after each pairing session

Being a good pair is not easy, regardless of your skill level. Do yourself a favor and finish your pairing session with a short retro in order to understand what worked well, what did not work and how you could improve your future sessions.

If you have any questions, feel free to hit me up on Twitter or on GitHub.

Happy Coding!