My Modded Lenovo T430

I’ve had a Lenovo T430 for many years and for most of those years it’s been sat gathering dust. Until I remember I have it, re-install some flavour of Linux on it and then promptly forget all about it again.

Since working from home and recently moving house I’ve been less inclined to stay in my office after work to tinker with various projects, I just feel a bit yucky. Instead I’ve picked ol’ dusty back up again and have started using it on the sofa whilst watching TV. Only this time I’ve picked Fedora Workstation.

What I like about the T430 is that it is built like a tank, the touchpad isn’t atrocious like some laptops and the keyboard is alright to type on as well. The only problem is, it’s just old. It has a pretty nasty 1366 x 768 TN panel which means any UI design work involving colours turns out awful and my particular model is an just an i5-3320M. I did throw an SSD in it some years ago which brought it back to a usable state though.

Some people would just go out and buy a new laptop, and I thought about that as well. Something larger than a 14″ screen would have been nice. Instead I did some googling and came across several threads on Reddit talking about all the possible upgrades you can do with the T430. It turns out you can actually do quite a lot, and so there began my journey…

Continue reading “My Modded Lenovo T430”

Traefik + Cloudflare: Keeping the origin server a secret

I recently started using Cloudflare proxying for all of the services I host under *.benscobie.com to reduce the attack surface on the origin server. In order for this to work effectively we need to ensure we aren’t leaking the origin server’s IP address in any way. This post details the steps I took to mitigate this when using traefik as a reverse proxy.

UPDATE 18/02/2024: Since writing this article I have switched to using Cloudflare Tunnels which removes some complexity mentioned in this article.

Continue reading “Traefik + Cloudflare: Keeping the origin server a secret”

AWS Lambda LocalStack – Cannot assign requested address: HttpRequestException

I found myself hitting the following exception whilst playing around with AWS Lambda and LocalStack when invoking a Lambda function from another Lambda function:

Cannot assign requested address: HttpRequestException
localstack_main  |    at System.Net.Http.ConnectHelper.ConnectAsync(String host, Int32 port, CancellationToken cancellationToken)
localstack_main  |    at System.Net.Http.HttpConnectionPool.ConnectAsync(HttpRequestMessage request, Boolean allowHttp2, CancellationToken cancellationToken)
localstack_main  |    at System.Net.Http.HttpConnectionPool.CreateHttp11ConnectionAsync(HttpRequestMessage request, CancellationToken cancellationToken)
localstack_main  |    at System.Net.Http.HttpConnectionPool.GetHttpConnectionAsync(HttpRequestMessage request, CancellationToken cancellationToken)
localstack_main  |    at System.Net.Http.HttpConnectionPool.SendWithRetryAsync(HttpRequestMessage request, Boolean doRequestAuth, CancellationToken cancellationToken)
localstack_main  |    at System.Net.Http.RedirectHandler.SendAsync(HttpRequestMessage request, CancellationToken cancellationToken)
localstack_main  |    at System.Net.Http.HttpClient.FinishSendAsyncUnbuffered(Task`1 sendTask, HttpRequestMessage request, CancellationTokenSource cts, Boolean disposeCts)
localstack_main  |    at Amazon.Runtime.HttpWebRequestMessage.GetResponseAsync(CancellationToken cancellationToken)
localstack_main  |    at Amazon.Runtime.Internal.HttpHandler`1.InvokeAsync[T](IExecutionContext executionContext)
localstack_main  |    at Amazon.Runtime.Internal.Unmarshaller.InvokeAsync[T](IExecutionContext executionContext)
localstack_main  |    at Amazon.Runtime.Internal.ErrorHandler.InvokeAsync[T](IExecutionContext executionContext)
localstack_main  |    at Amazon.Runtime.Internal.ErrorHandler.InvokeAsync[T](IExecutionContext executionContext)
localstack_main  |    at Amazon.Runtime.Internal.CallbackHandler.InvokeAsync[T](IExecutionContext executionContext)
localstack_main  |    at Amazon.Runtime.Internal.EndpointDiscoveryHandler.InvokeAsync[T](IExecutionContext executionContext)
localstack_main  |    at Amazon.Runtime.Internal.EndpointDiscoveryHandler.InvokeAsync[T](IExecutionContext executionContext)
localstack_main  |    at Amazon.Runtime.Internal.CredentialsRetriever.InvokeAsync[T](IExecutionContext executionContext)localstack_main  |    at Amazon.Runtime.Internal.RetryHandler.InvokeAsync[T](IExecutionContext executionContext)
localstack_main  |    at Amazon.Runtime.Internal.RetryHandler.InvokeAsync[T](IExecutionContext executionContext)
localstack_main  |    at Amazon.Runtime.Internal.CallbackHandler.InvokeAsync[T](IExecutionContext executionContext)
localstack_main  |    at Amazon.Runtime.Internal.CallbackHandler.InvokeAsync[T](IExecutionContext executionContext)
localstack_main  |    at Amazon.Runtime.Internal.ErrorCallbackHandler.InvokeAsync[T](IExecutionContext executionContext)localstack_main  |    at Amazon.Runtime.Internal.MetricsHandler.InvokeAsync[T](IExecutionContext executionContext)
localstack_main  |    at FanOutFunction.Function.FunctionHandler(Stream stream, ILambdaContext context) in C:\Git\MyApp\src\FanOutFunction\Function.cs:line 86

Lambdas in LocalStack run within Docker so the AWS endpoint should to be set to the LocalStack container which wasn’t the case for me. As the LocalStack edge port is typically exposed you can just target the docker host by using host.docker.internal

I am using the .NET LocalStack client so this looks like the following:

// appsettings.json
{
  "LocalStack": {
    "UseLocalStack": true,
    "Session": {
      ...
    },
    "Config": {
      "LocalStackHost": "host.docker.internal",
      "UseSsl": false,
      "UseLegacyPorts": false,
      "EdgePort": 4566
    }
  }
}

Build & deploy ASP.NET Core applications with Jenkins and Octopus Deploy

After recently getting to grips with Jenkins I wanted to expand into deployment automation as that was the only stage missing from my workflow. At my current place of work, we use Octopus Deploy for all of our in-house application deployments and it works flawlessly so I threw up an Octopus VM in Azure to play with. What we want to end up with is Jenkins building our ASP.NET Core application from source, packaging the published output and then pushing that package to Octopus for it to deploy.
Continue reading “Build & deploy ASP.NET Core applications with Jenkins and Octopus Deploy”

jQuery’s hide() and show() slow in Chrome

Whilst working on a project where I’m filtering elements on the client using JavaScript I came across a very interesting issue with Chrome.

I filter elements by running jQuery’s hide() or show() on them depending on what the user entered and there’s around 750 elements that need this filtering. I noticed that this was quite slow in Chrome as it took around 2-3 seconds for the page to become responsive whilst filtering. I tested the page in Internet Explorer 9 to confirm that the code I had written was to blame, but the filtering was instant. What the hell Chrome?

Continue reading “jQuery’s hide() and show() slow in Chrome”

Fixing 500 OOPS: vsftpd: refusing to run with writable root inside chroot ()

After upgrading vsftpd or vsftpd-ext you may be getting the following message when trying to log in.

500 OOPS: vsftpd: refusing to run with writable root inside chroot ()

This is due to the following update:

– Add stronger checks for the configuration error of running with a writeable
root directory inside a chroot(). This may bite people who carelessly turned
on chroot_local_user but such is life.

The problem is that your users root directory is writable, which isn’t allowed when using chroot restrictions in the new update.

To fix this you must either remove write permissions on the users root directory with the following command, replacing the directory with your users root:

chmod a-w /home/user

Or you can work around this security check by adding either of the two below into your configuration file.

For the standard vsFTPd build (vsftpd):

allow_writeable_chroot=YES

For the extended vsFTPd build (vsftpd-ext):

allow_writable_chroot=YES

Removing the write permission on the root isn’t a perfect solution as doing this can cause a few problems with things that need to write to the root directory, such as the bash history file or some graphical environments.

Dmitriy has suggested 3 ways to also overcome this problem, be sure to check them out.