Wool

  • Post author:
  • Post category:Book

Chet bought me this book and demanded I read it, and honestly that was a good call. The book reminds me a bit of  Oryx and Crake, but perhaps that's unfair given I read that one eight years ago and have probably forgotten some important details. The book is well paced and engaging. Despite being as long as many of Neil Stephenson's books, I felt it was a much more approachable read than that. I found the second half of the book a bit harder to read that the first half, because it doesn't pull many punches in terms of the consequences of people's actions and is pretty good at building suspense. There were definitely points where I had to pause because I was pretty sure something bad was going to happen to someone I'd grown fond of. That said, it was still a great read. I've gone and bought the next two in the series because I'm confident I'm going to want to read them now too.

Continue ReadingWool

Understanding Compression

  • Post author:
  • Post category:Book

I bought this book on a whim, because I was trying to understand a compression scheme and had trouble finding good documentation on it. The book overall is written in a quite conversational style that I find a bit distracting from the content, and the introduction is a bit repetitive -- yes I get it, there's some maths involved. Thanks. That said, the content is a solid and quite approchable introduction to the topic area. I haven't ever thought before about entropy in information theory for example, I now feel like I could give a coherent elevator description of the topic. Another example is the description of Huffman codes. Here the topic is introduced with four pages and a few diagrams and I "get it". In the random algorithms book on my shelf (Introduction to Algorithms, third edition by Cormen, Leiserson, Rivest, and Stein), the same content takes ten pages and includes a six page set of lemmas around the code's correctness. Both descriptions would get you there in the end, but Understanding Compression's description is definitely more approachable. Overall, its very rare for me to sit down and actually read a technical book from cover to cover, but this book…

Continue ReadingUnderstanding Compression

Validating a keystone token

  • Post author:
  • Post category:OpenStack

Once again I venture into the lands of poorly documented keystoneauth1 calls. This time, I want to be able to validate if a stored keystone authentication token is valid. Here's the best I could come up with, I'd be interested in others have something better. For this to work, we need a service account to create a keystone client with, and then we can ask that client questions about random other tokens... from keystoneauth1 import exceptions from keystoneauth1.identity import v3 from keystoneauth1 import session from keystoneclient.v3 import client def validate_keystone_token(service_auth, token): """Validate a keystone token. Returns True if the token is valid, False otherwise. """ # We need a keystone client as the service service_session = session.Session(auth=service_auth) service_keystone = client.Client(session=service_session) try: user = service_keystone.tokens.validate(token) except exceptions.http.NotFound: return False # Require that there be an access group with our configured name group = None for g in service_keystone.groups.list(): if g.name == 'mygroup': group = g if not group: return False # Require that the user be in that group try: service_keystone.users.check_in_group(user.user_id, group.id) except exceptions.http.NotFound: return False return True # Authenticate the service user service_auth = v3.Password( auth_url='http://kolla.home.stillhq.com:5000', username='admin', password='...', project_name='admin', user_domain_id='default', project_domain_id='default') # Create a token we can test user_auth =…

Continue ReadingValidating a keystone token

Cult of the Dead Cow

  • Post author:
  • Post category:Book

A very readable history of the early US hacking scene, including the roots of Def Con and Blackhat security conferences. The book is filled with a cast of characters many of whose names and exploits I recognize -- although I've only met one or two in person. The book is definitely US-centric in it's coverage but an interesting way to spend a summer evening or two. Menn (the author) spends a lot of time working through the moral reasoning that led a group formed out of an interest in how things worked and a sense of community among the socially awkward, to a group that made a profound difference to how we think about responsible disclosure of security vulnerabilities and our obligations as technologists while at the same time trying to be funny (the hackers, not the author). The description of how cDc dragged Microsoft kicking and screaming into taking security for their software seriously is both funny and interesting, as well as the discussion of early attempts at responsible disclosure at a time where software vendors would sue instead of fixing their products. I find the descriptions of the various players "going straight" and acquiring actual jobs in order…

Continue ReadingCult of the Dead Cow

Project Hail Mary

  • Post author:
  • Post category:Book

I enjoyed Andy Weir's two previous books, so I guess it's not a surprise that I enjoyed this one too. I feel like this one is closer to The Martian than to Artemis, so perhaps Weir is finding his sweet spot in terms of content choices. This book follows a school science teacher doing foolhardy things to save both himself and those he loves. It's a bloody good read but I don't want to ruin it for you so I'll leave it there.

Continue ReadingProject Hail Mary

Using the openstacksdk with authentication arguments

  • Post author:
  • Post category:OpenStack

I wanted to authenticate against OpenStack recently, and had a lot of trouble finding documentation about how to authenticate just by passing arguments (as opposed to by using clouds.yaml or environment variables). Now that I have a working incantation, I figure I should write it down so I can find it again. Its also disappointing the OpenStack documentation doesn't appear to cover this particularly well... from keystoneauth1.identity import v3 from keystoneauth1 import session from openstack import connection auth = v3.Password( auth_url='http://kolla.home.stillhq.com:5000', username='admin', password='...', project_name='admin', user_domain_id='default', project_domain_id='default') sess = session.Session(auth=auth) conn = connection.Connection(session=sess) print([x.name for x in conn.list_servers()]) This code will authenticate using the arguments provided, and then list all the servers (instances) visible to that user. You're welcome.

Continue ReadingUsing the openstacksdk with authentication arguments

Fetching the most recent GitHub actions runner version

  • Post author:
  • Post category:GitHub

One of the struggles I have with running self-hosted GitHub actions runners is that GitHub releases new versions of the runner quite often and I don't notice. That's fine as long as you ignore the scary warnings on action output, until they drop support for whatever random old runner you're using. They did just that to me this week. The best bit was that the "old runner" was only a month old! I was left wondering if I could automate this. The answer is thankfully yes. Specifically, I wanted to automate it with a GitHub action which downloads the runner and puts it into the self-hosted runner image. That looks like this: - name: Install the github command line run: | sudo apt update sudo apt install -y curl curl -fsSL https://cli.github.com/packages/githubcli-archive-keyring.gpg | sudo dd of=/usr/share/keyrings/githubcli-archive-keyring.gpg sudo chmod go+r /usr/share/keyrings/githubcli-archive-keyring.gpg echo "deb [arch=$(dpkg --print-architecture) signed-by=/usr/share/keyrings/githubcli-archive-keyring.gpg] https://cli.github.com/packages stable main" | sudo tee /etc/apt/sources.list.d/github-cli.list > /dev/null sudo apt update sudo apt install -y gh - name: Lookup latest version of the GitHub actions runner env: GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }} run: | actions_url=$(gh release view --repo actions/runner --json assets | \ jq -r '.assets[].url | select (contains("linux-x64-2")) | select (test("[0-9].tar.gz$"))') echo "GITHUB_ACTIONS_URL=$actions_url" >>…

Continue ReadingFetching the most recent GitHub actions runner version

Turnover of Companies in OpenStack: Prevalence and Rationale

  • Post author:
  • Post category:OpenStack

This paper examines the withdrawal behaviour of corporate contributors to OpenStack, which seems particularly relevant given most contributions in OpenStack are corporately supported, and corporate engagement is declining over time. Its also directly relevant to my own experiences contributing to the project, so seemed like a thing I should read. One interesting aspect of the study is how they define withdrawal from contributions. For each company, they calculate an individual frequency of contribution, and then use that to determine if the company is still making contributions. That is, of a company only ever contributed once a year, we must wait at least a year to know that they have indeed stopped contributing. The paper finds that in more recent OpenStack releases, more companies are leaving contributions than joining. The authors assert that in general engaged developers are now less experienced than previously, which presents risks in terms of developer effectiveness as well as code quality. However, the paper does note that companies with smaller contributions are more likely to disengage than "sustaining companies", however that's largely because there are a huge number of companies contributing only one developer who makes a small number of commits. Unsurprisingly, the paper notes that…

Continue ReadingTurnover of Companies in OpenStack: Prevalence and Rationale

On-demand Container Loading in AWS Lambda

  • Post author:
  • Post category:AWS

My team at work now has a daily personal learning time called “egg time” — its a slightly silly story involving a manager who was good at taking some time to learn things each day, and an egg shaped chair.

Today I decided that I should read this paper about container image loading in AWS lambda, as recommended by Robert Collins on LinkedIn. The paper details the work they had to do to transition from all Lambda functions being packaged as relatively small zip files (250mb), to relatively large Docker containers (10gb+) while maintaining their aggressive target cold-start time of 50ms.

(more…)

Continue ReadingOn-demand Container Loading in AWS Lambda

Holman CLXRGB60 RGB WiFi garden light controllers and tasmota

Today I went forth to Bunnings in the rain to purchase a Holman CLXRGB60 RGB garden light controller so that I too could have fancy lighting in my garden and impress all those guests I never have over. I had been given hope by the Blakadder site that I would be able to flash tasmota onto the controller so it integrated with my Home Assistant home automation. Unfortunately, it was not to be. Despite the device being TYWE3L based, the warning on the blakaddr site was correct, and this is a next-gen Tuya device where the crypto hasn't been broken yet. Then again, I couldn't even get this device to pair in the Holman app, so it clearly hates me. This unfortunately means the excellent instructions from Jon Oxer were unforunately not helpful today. I think there is a theoretical option here to flash using the serial pins on the board, ala this guide. Also, it means my hair got wet for nothing. So as to take revenge for my wet hair I have decided to pivot. The Holman lights seem quite well made, but they're just 12 volt RGB PWM devices. So I can use their lights and build…

Continue ReadingHolman CLXRGB60 RGB WiFi garden light controllers and tasmota

End of content

No more pages to load