DEV Community: Alex Antsiferov

VS Code devcontainer with an external terminal: SSH agent howto

Alex Antsiferov — Sat, 31 Jan 2026 14:52:48 +0000

I'm not a huge fan of VS Code's internal terminal.

I keep bumping into its various bugs, like disappearing characters, cmd-V pasting into the wrong window, or the terminal getting closed when switching branches (with scm.workingSets feature enabled).
And really, I find a terminal an unnecessary bloat for a code editor.

That said, we do use VS Code and devcontainers at work.
I won't get into the advantages and disadvantages, let's say it's a given.

In order to use an external terminal with a devcontainer we need something like this, works just fine:

CONTAINER_ID=$(docker ps --format "table {{.ID}}\t{{.Names}}" | grep "my-container-name" | awk '{print $1}')

docker exec -ti -w /workspaces/my-project "$CONTAINER_ID" /bin/zsh

But there's one thing I couldn't get to work in an external terminal -- the SSH agent. Not being able to git pull is annoying!

VS Code mounts the host SSH agent's socket to the container. It also sets SSH_AUTH_SOCK var, but only for the internal terminal:

vscode ➜ /workspaces/my-project (main) $ echo $SSH_AUTH_SOCK
/tmp/vscode-ssh-auth-e85d0936-746e-465d-8382-cbf0bb69b476.sock

So here's the workaround: we find it in /tmp and set SSH_AUTH_SOCK in our docker exec command:

CONTAINER_ID=$(docker ps --format "table {{.ID}}\t{{.Names}}" | grep "my-container-name" | awk '{print $1}')

docker exec -ti \
  -w /workspaces/my-project \
  "$CONTAINER_ID" \
  sh -lc '
    for sock in /tmp/vscode-ssh-auth-*.sock; do
      [ -S "$sock" ] || continue
      SSH_AUTH_SOCK="$sock" ssh-add -l >/dev/null 2>&1 && {
        export SSH_AUTH_SOCK="$sock"
        echo "Using SSH_AUTH_SOCK=$SSH_AUTH_SOCK"
        break
      }
    done

    if [ -z "$SSH_AUTH_SOCK" ]; then
      echo "No working VS Code SSH agent socket found"
    fi

    exec /bin/zsh
  '

A bit hacky, but it does the job! Enjoy working from your favorite terminal!

On comparing time intervals

Alex Antsiferov — Sun, 09 Feb 2025 15:21:55 +0000

Here's an edge case to keep in mind when querying the database for something that has duration (for example, events) using a from..to date/time filter: long events can start before from and end after to.
So if we check only that the start or end time of the event fall within the interval, we can miss an event, even though it overlaps ("covers") the required interval.

Tracing a Ruby method call in production

Alex Antsiferov — Sun, 05 Jan 2025 12:08:39 +0000

Sometimes, we can't reproduce the issue in development and need to trace a method call in production console:

def trace
  trace = TracePoint.new(:call) do |tp| 
    p([tp.path, tp.lineno, tp.event, tp.method_id])
  end
  trace.enable
  yield
  trace.disable
end

trace { some_method(args) }

In most cases, we want to see our own code only, so let's exclude libraries:

def trace
  trace = TracePoint.new(:call) do |tp|
    p([tp.path, tp.lineno, tp.event, tp.method_id]) unless /gems|ruby/.match?(tp.path)
  end
  trace.enable
  yield
  trace.disable
end

There are also other events to trace, for example, :raise.

Rails: passing data to the browser with

Alex Antsiferov — Sun, 05 Jan 2025 11:56:37 +0000

I'll be posting code snippets like this -- solutions to little problems that I come across in everyday work.

This one is one of the simplest ways to share some structured data with the front end using content_for helper and meta element.

# .erb

<% content_for :head do %>
  <meta name="project-prices" content=<%=prices.to_json%> />
<% end %>

// .js

const meta = document.querySelector('[name="project-prices"]')
JSON.parse(meta.content)

Moving Mongo Out of the Container | MongoDB Atlas Hackathon 2022 on DEV

Alex Antsiferov — Wed, 07 Dec 2022 15:36:39 +0000

What I built

I have a pet project that I started some time ago, while studying programming. It's a Telegram bot for people learning German, called Dasbot.
I'm pretty proud of its daily audience of a few hundred users who have collectively answered more than 300k quiz questions 😎, but I must confess: until now its database has been residing in a Docker container 📦. Like, not even on a mounted volume 🤦‍♂️.
This hackaton motivated me to amend this gruesome mistake.

Also, now that I know about change streams, I can display some real time stats on the bot's web page, yay!

Category Submission:

No idea! Just wanted to share some life lessons :)

App Link

https://dasbot.yak.supplies

You're welcome to use the bot and answer its questions! (Especially if you're struggling with German like I do). If it annoys you, just ban it 😊

Screenshots

Description

German language is difficult! Especially terrible are its grammatical genders which defy any logic, so you just have to memorize them.
Dasbot actually helps you do this, with a simple spaced repetition algorithm.

It's written in Python, because I was studying Python at that time.
And it's using MongoDB for database, because I didn't need much structure in my documents.
(There should be a photo of my desk here, covered with all the bureaucratic papers they send you twice a day here in Germany 📩).

In the database I keep everyone's scores neeeded for the repetition system. I also collect stats (user, word, answer, time) -- there could be some useful insights in there.

Link to Source Code

https://github.com/wetterkrank/dasbot -- main app
https://github.com/wetterkrank/dasbot-docs-live -- web app with the new /stats page

Permissive License

MIT License

Background

So, I used Docker.
It's a great tool! And I guess it's ok for a study project to spawn a database in a container. But when you do it in "production", you start collecting some gotchas. Here's a couple of mine.

  mongo:
    ports:
      - "0.0.0.0:27017:27017"

-- this was a part of my docker-compose.yml.

After the launch, everything worked fine for a few days, and then I found my database empty!
I checked the Mongo logs and found some dropDatabase calls coming from unknown IPs. Hacked! 🪓 But how!? I knew my ufw rules by heart! What I didn't know is that Docker keeps its own iptables and will not be trammelled by a mere firewall.
So when you expose the port using 0.0.0.0, you share it with the world full of people with port scanners.

Fast forward to this November. I just updated a config setting and decided to restart the containers manually.
Then I pinged the bot and was slightly surprised that it didn't recognise me. So I looked at the db collections... interesting... 0 documents... 😰
After scrolling up the shell history, I noticed that I typed docker-compose down instead of docker-compose stop. Here goes my data! Luckily, I had a backup 😅.

How I built it

As for the moving to Atlas part: this was simple!
I would have loved to use the live migration service but I decided to start with M0 cluster so didn't have the opportunity and just used mongorestore instead:

DB_CONTAINER="dasbot_db"
RESTORE_URI="mongodb+srv://$DB_USERNAME:$DB_PASSWORD@mydb.smth.mongodb.net/"

echo "Piping mongodump to mongorestore with Atlas as destination..."
docker exec $DB_CONTAINER mongodump --db=dasbot --archive | mongorestore --archive --drop --uri="$RESTORE_URI"

One notable hiccup was the speed of mongorestore -- a pitiful 50Mb of data took several minutes to load! However, increasing the number of workers (numInsertionWorkersPerCollection) helped.

For the change streams (real time stats) exercise I had to refresh my knowledge of aggregation pipelines and write some JS code. I already mentioned stats collection above, it can be used to build all kinds of reports.

So I've added a couple of triggers which are responsible for aggregating this data and publishing the updates to a separate database, and an Atlas app that lets users access this database anonymously.

// Scheduled to run twice per day
// Updates correct / incorrect counters in answers_total
exports = function() {
    const mongodb = context.services.get("DasbotData");
    const collection = mongodb.db("dasbot").collection("stats");
    const pipeline = [
      { $group: {
          _id: { $cond: [ { $eq: ["$correct", true] }, 'correct', 'incorrect' ] },
          count: { "$sum": 1 }
        }
      },
      {
        $out: { db: "dasbot-meta", coll: "answers_total" }
      }
    ]
    collection.aggregate(pipeline);
};

// This runs on every `stats` insert and updates the aggregated results
exports = function(changeEvent) {  
  const db = context.services.get("DasbotData").db("dasbot-meta");
  const answers_total = db.collection("answers_total");

  const fullDocument = changeEvent.fullDocument;
  const key = fullDocument.correct ? "correct" : "incorrect";
  const options = { "upsert": true };

  answers_total.updateOne( { "_id": key }, { "$inc": { "count": 1 } }, options); // { _id:, value: }
};

To display the data, I made a simple React app that uses the Realm Web SDK. Now, when someone answers the bot's question, you can immediately see it ⚡.

Additional Resources/Info

This tutorial was quite handy!

Ruby 3.1.x and OpenSSL::Digest::DigestError

Alex Antsiferov — Tue, 15 Nov 2022 23:02:58 +0000

Came across this issue after upgrading Ruby to 3.1.0 in one of the apps I'm working on.

I use rbenv to manage Ruby versions, and it turns out they recently started building Ruby with OpenSSL 3.0 instead of OpenSSL 1.1.

OpenSSL 3.0, in turn, has retired a number of algorithms (including MD4 function, which was used in that app).

And hello! After the update, we call OpenSSL::Digest::MD4.hexdigest() and get this:
OpenSSL::Digest::DigestError, message: Digest initialization failed: initialization error

So, if you're using rbenv to update Ruby to 3.1.x and your code uses one of the retired algorithms, there's a chance you'll come across a similar issue.

A temporary workaround if you can't get rid of legacy code right away:

install Ruby with OpenSSL 1.1 (note I'm using brew here): export RUBY_CONFIGURE_OPTS="--with-openssl-dir=$(brew --prefix openssl@1.1)" && rbenv install 3.1.0
as an alternative, look into re-enabling MD4 in OpenSSL (this looks useful)

Another alternative would be to use an MD4 implementation in pure Ruby.

unexpected EF BB BF

Alex Antsiferov — Sat, 26 Feb 2022 22:58:23 +0000

Got this funny little hiccup while setting up a remote Ubuntu server from a Windows machine.

As soon as I created the user account, I decided to add my public key to authorized_keys so I could log in without password. Since Windows doesn't have ssh-copy-id, I ran this nifty command in PowerShell:

type $env:USERPROFILE\.ssh\id_rsa.pub | ssh {SERVER} "cat >> .ssh/authorized_keys"

My public key was copied to authorized_keys, perfect! But on the next login I still got the password prompt. What the..?

I ran ssh with -vv key to get more info, rechecked everything twice, and finally noticed that the newly added key had some extra characters.
And no, these were not CRLF. This time it was a mysterious EF BB BF sequence also known as BOM:

> 00000000: efbb bf73 7368 2d72 7361 2041 4141 4142  ...ssh-rsa AAAAB

After I removed them, ssh recognized my key and everything worked as expected. Don't I just love this stuff!

A couple more useful commands:

xxd myfile # hex dump myfile
diff -y <(xxd myfile1.bin) <(xxd myfile2.bin) # compare binaries

Building LineageOS in WSL2

Alex Antsiferov — Wed, 03 Nov 2021 20:49:58 +0000

A few days ago, I needed an Android phone for some experiments, so I fished out an old Nexus 5 "Hammerhead" from a drawer where I keep the assorted lengths of wires.

However, it had a pretty outdated Android 6 OS, and some apps refused to install. So I decided to get it a slightly newer LineageOS 14.1 (based on Android 7). Feeling adventurous, I decided to build one myself instead of downloading a ready build (from god-knows-where, by the way).

I used this guide. Overall, it was surprisingly comprehensive. Still, I encountered a few obstacles, writing them down here for reference.

Notable hiccups

Preparing tools

libwxgtk3.0-dev was renamed to libwxgtk3.0-gtk3-dev in Ubuntu 20.04
to access USB devices in WSL, I had to run adb in tcp bridge mode (see https://github.com/microsoft/WSL/issues/4619#issuecomment-596990676)

Getting the source files in place

I'm using zsh, and it doesn't normally execute .profile, so my $HOME/bin wasn't included in the path -- repo didn't run. Being lazy, I just dropped it in the sources folder, and was punished on one of the next steps: failure to execute repo was breaking the breakfast pipeline. Luckily, the error was logged so I figured it out and fixed properly.
Proprietary blobs for the device: this seemed like a Catch-22 situation; then I realised that I could get those from TheMuppets (https://github.com/TheMuppets/proprietary_vendor_lge/tree/cm-14.1); note the branch in the path.
TheMuppets repo must be included in the .repo/local_manifests/roomservice.xml like this:

<?xml version="1.0" encoding="UTF-8"?>
<manifest>
  <project name="LineageOS/android_device_lge_hammerhead" path="device/lge/hammerhead" remote="github" />
  <project name="LineageOS/android_kernel_lge_hammerhead" path="kernel/lge/hammerhead" remote="github" />
  <project name="TheMuppets/proprietary_vendor_lge" path="vendor/lge" remote="github" revision="cm-14.1" />
</manifest>

After rerunning repo sync the blobs were added to the source files.

Building

The build process was inexplicably failing somewhere around 2%. I ran jack-diagnose tool from prebuilts/sdk/tools, but it wasn't detecting any issues. Neither the jack-server logs had anything of note in them.
I suspected that jack-server was quietly crashing due to insufficient memory, and did several things at once:
- increased WSL memory limit from 6Gb to 8Gb (my laptop has 16Gb total),
- in ~/.jack-server/config.properties, set jack.server.max-service to 1 instead of 4,
- set -Xmx5G instead of -Xmx4G in ANDROID_JACK_VM_ARGS,
- and upgraded jack-server package as suggested here.

Not sure which exact part was crucial, but after doing this the build went on smoothly.

Loading the firmware

The TWRP recovery wouldn't start from the bootloader, so I had to use this command: fastboot boot <recovery.img> instead.
I had to install the "pico" (smallest) Google Apps package along the OS ROM, otherwise it wouldn't fit in without repartitioning.

Finally

The first boot of LineageOS took a while, and I had to reboot it once when it got stuck at "looking for updates" step.
After the initial setup, it has been working pretty well! On with the experiments!

Setting up incremental backups for WSL2

Alex Antsiferov — Sat, 10 Apr 2021 22:50:16 +0000

Since I've started using WSL, most of my dev projects have migrated there.
And while the code is mostly stored on GitHub, there's still a question of backing up the rest of the files (dotfiles, auxiliary scripts, data etc). Basically, I want to run daily incremental backups of my home dir, preferably encryped.

In Windows I have a nice open-source tool called Duplicati which makes daily incremental encrypted backups to a NAS. So, I was hoping to use it for WSL, too.

Fail: The Windows way

As the first shot, I tried accessing WSL files from Duplicati running in Windows, and added this path to my backup: \\wsl$\Ubuntu\home

The performance was horrendous, just as I expected. ⛔
(Maybe I should have excluded all those node_modules after all... 🤔)

The next experiment was grabbing the whole WSL file system image file. It's located at %LOCALAPPDATA%\Packages\ CanonicalGroupLimited.UbuntuonWindows_79rhkp1fndgsc\LocalState\ext4.vhdx

However, at some point WSL wouldn't start; I guess the file got locked by the backup process. Bad idea! Having one big file isn't good for incremental backups anyway, so I dropped this plan. ⛔

The "official" method with wsl.exe –export also doesn't suit me, since it requires shutting down WSL and produces another big file. ⛔

Well, it looks like I'll have to do everything from inside WSL! And it has plenty of tools to choose from.

Success: The Linux way

The first candidate is rsync:

rsync -av -e ssh /home rsync@192.168.1.200::/backup/wsl-files/

(On the NAS, I've added the user 'rsync' with proper privileges).

This does the job pretty quickly and can be automated. To avoid the interactive password prompt, I'd need a key- or a password file (both require some effort to set up). 🛠

However, I wanted to have my files in the destination folder encrypted. So I decided to use duplicity. As a quick test, I ran this:

export PASSPHRASE=MySuperPassphrase
duplicity /home sftp://duplicity:MySuperPassword@192.168.1.200/home/wsl-backup

The PASSPHRASE is used to encrypt the files.
By default, duplicity creates full backup on the 1st run and incremental backups after. 🎯

There are more advanced script examples in the Ubuntu help. Following them, I came to something like this:

#! /bin/bash
BASEDIR=$(dirname "$0")

# Export vars from .env (no spaces or = in values). Required:
# NAS_HOST=
# NAS_USER=
# NAS_PASSWORD=
# PASSPHRASE=

export $(egrep -v '^#' $BASEDIR/.env | xargs)

duplicity --full-if-older-than 1M /home/alex/ sftp://${NAS_USER}:${NAS_PASSWORD}@${NAS_HOST}/home/wsl-backup
duplicity remove-older-than 3M --force sftp://${NAS_USER}:${NAS_PASSWORD}@${NAS_HOST}/home/wsl-backup

The variables used in the script are kept in the .env file located in the same dir as the script.

Now I just need to schedule my backup script like this, right? (crontab -e to edit the current user's cron table)

0 21 * * * /home/alex/nas-backup/backup.sh >>/home/alex/nas-backup/duplicity.log

Not so fast! It's WSL for you, so somebody has to start the cron service. 👷‍♂️

There are different ways to do it, I was lazy and added this "autostart" to my .zshrc file:

service cron status || sudo service cron start

This means the backup won't run if I'm not using WSL, but that's only logical.
Windows scheduler can be used as an alternative, as described here.

One last step. Since I'm starting the cron service as a superuser, I have to enter the password every time. To avoid this, I created a rule in /etc/sudoers.d/service, disabling the password request for this case:

alex ALL=NOPASSWD:/usr/sbin/service cron start

And here's a bonus script to run once in a while and verify the files:

#! /bin/bash

export $(egrep -v '^#' .env | xargs)
duplicity verify -vInfo sftp://${NAS_USER}:${NAS_PASSWORD}@${NAS_HOST}/home/wsl-backup /home/alex/

Now we're all set! ✅
But wait, what about the databases and Docker containers? Well, maybe next time...

Pixel art in Excel

Alex Antsiferov — Sun, 21 Mar 2021 11:51:57 +0000

One day, I had this weird idea of displaying an animation in Excel using the cells as pixels.
First of all, I had to check if it was possible at all, and also how fast Excel would render the "pixels".

So I grabbed a 320x200 image of Dangerous Dave here and set off...
To convert a PNG file to CSV I used this PHP tool.

VBA code:

'Canvas reset button
Sub Button2_Click()
    Range("A1:LH200").ColumnWidth = 0.25
    Range("A1:LH200").RowHeight = 2
    Range("A1:LH200").Interior.ColorIndex = 0
End Sub

'Draw button
Sub Button1_Click()
    DrawCSVFile
End Sub

`The draw subroutine itself
Public Sub DrawCSVFile()
    Dim FilePath As String
    FilePath = ActiveWorkbook.Path & "\title1.csv"
    Open FilePath For Input As #1

    Y = 1
    Do Until EOF(1)
        Line Input #1, LineFromFile
        LineItems = Split(LineFromFile, ",")
        For X = 1 To 320
            RGBString = LineItems(X - 1)
            R = Val("&H" & Mid(RGBString, 1, 2))
            G = Val("&H" & Mid(RGBString, 3, 2))
            B = Val("&H" & Mid(RGBString, 5, 2))
            RGBExcel = RGB(R, G, B)
            Cells(Y, X).Interior.Color = RGBExcel
        Next
        Y = Y + 1
    Loop

    Close #1
End Sub

The result: well, it works :)

But the image above took a full whopping minute to draw.
Reading the CSV line by line and painting individual pixels turned out to be really slow!

I guess some day I should try the range copy method :)

A couple of things I learned along the way:

while reading a text file, VBA expects the lines to end with CR or CRLF (in Windows at least); LF is not recognized as the line end
RGB in Excel is actually BGR

Troubleshooting WSL + localhost:3000 'connection refused' issue

Alex Antsiferov — Tue, 02 Mar 2021 23:33:34 +0000

Just spent an hour trying to figure out why the browser wouldn't open localhost:3000 (served by Webpack/create-react-app in WSL2).

Normally, a server running in WSL should be accessible from the Windows (host) machine without any issues.

My troubleshooting steps, roughly:

check /windows/system32/drivers/etc/hosts file --nothing special here...
check Windows firewall rules, just in case
shut down WSL VM with wsl --shutdown command and restart it
run another app in WSL using a different port -- hmm, this works...
change the port of the app in question in Webpack config: PORT=3006 react-scripts start -- also works... so the problem is in the specific port!
see if some process is holding the port 3000 in Linux: ss -tulpn
check if a process is holding the port in Windows: netstat -ano | findstr :3000 or Resource Monitor -> Network tab -> Listening ports -- aha! there is one!
find the process name by PID in the Task Manager -> Services

Turns out, the port was taken by IP Helper service (iphlpsvc).

I could not find a way to reconfigure it, and some quick research showed that it wasn't a critical service (at least in my case), so I just disabled it in the Services.