Posted on
by

As part of (one of) my day jobs, I have had to yet again bash together a set of REST APIs. This is so we can start wiring up some proper micro services AWS style scalable architecture into the monolithic beast that is the current incarnation of the software I’m working on.

Anyway, here are a few gotchas for this if you intend to start using proper REST style HTTP verbs (PUT/PATCH/DELETE), rather than doing everything via GET and POST like most everyone.

No easy way to access variables

If you’re familiar with the standard $_POST mechanism to access passed variables, you’ll be disappointed that PHP doesn’t by default provide a nice way of access these for PUT and PATCH.

So, you’re going to have to extract them yourself. Not overly tricky, but irritating:

So, for example:

parse_str(file_get_contents('php://input'), $patch);
if (is_array($patch)) {
  $this->data = array_merge($this->data, $patch);
}

Requests not coming through

If you find that your APIs work fine on your local machine but break when deployed, you might want to check your server configuration.

It is quite common for web servers (especially on shared hosts) to block access to HTTP verbs other than most common GET and POST. Modsecurity’s default config definitely blocks these methods.

You should also check that any proxies or load balancers that you have in front of your REST endpoint. These may need some configuration tweaks as well.

Hopefully this will save you some time and frustration!

Posted on
by

The Known Open Collective, which was set up last year, is continuing to grow.

This is fantastic, and I’m ever grateful for those who use Known, contribute to the community in whatever way, and especially to those who vote for Known with their hard earned dollars!

The collective has built up a reasonable war chest now, and I’m keen to start using it to really start pushing the project forward and increase momentum.

Right now I’m thinking of maybe suggesting we use some of the money to fund tactically useful developments focussed on really knocking out blockers for people picking up the project.

Off the top of my head I’m thinking things like paying for development of installers for various hosting platforms, and maybe Known – Known import/export.

I’d be curious to hear your thoughts!

Posted on
by

tl:dr – Kernel headers for 5.3.0 have changed so modules for older Nvidia cards no longer build. Downgrade to the last known good kernel (e.g. 5.0.0-37-generic) and you should be good.

So, I woke up this morning (blues riff), extra early in order to bash out some client work before heading to the gym. I turned on my computer and was greeted by the sight of my login screen, low res, and only on one monitor.

Nothing with computers, it seems, is going to be easy.

I remembered that I had done an apt-get upgrade the previous night, and this has in the past knocked the Nvidia drivers out of whack, so I reinstalled the drivers for my card apt-get remove nvidia-driver-390; apt-get install nvidia-driver-390 and restarted.

No joy.

Fine, I’ll install the official drivers from the Nvidia binary. Never failed before.

Bang. Wouldn’t build.

Ok. Time to dig a little deeper.

I went back to the distro drivers, and this time removed them completely; apt-get remove nvidia-driver-390 --purge; apt-get autoremove; apt-get install nvidia-driver-390.

Still no joy.

However, picking apart the build logs, and we have our first clue. A bunch of build errors to do with the Nvidia modules. Seems that the drivers were not able to build against the current kernel.

Looking at my /boot/ I can see that a new kernel (5.3.0) was installed as part of the upgrade. It looks like the kernel headers have been changed about, and this has broken older drivers.

So, there are two possible solutions – use a newer version of the Nvidia drivers (which isn’t possible for me since I have a pretty old GForce card installed), or roll back to the previous kernel.

First, remove the 5.3.0 kernel: apt-get remove linux-image-5.3.0-26; apt-get remove linux-headers-5.3.0-26

You’ll get a warning if you’re currently running this kernel, don’t worry, we’ll sort that out now.

Make sure you’ve got the working kernel installed apt-get install linux-image-5.0.0-37 linux-headers-5.0.0-37

Now, make sure grub boots this module. Edit /etc/default/grub and change GRUB_DEFAULT to GRUB_DEFAULT="Advanced options for Ubuntu>Ubuntu, with Linux 5.0.0-37-generic" (or whatever the particulars of your last working kernel was – ls -larth /boot to show the history).

Update your boot, update-grub

Reboot, and then log in to the console, and reinstall your Nvidia drivers: apt-get remove nvidia-driver-390 --purge; apt-get autoremove; apt-get install nvidia-driver-390

All being well, the Nvidia drivers should build this time. Reboot one last time, and you’re good!

Hope this helps.

UPDATE Jan 21

If you are running Focal or later, you may find that this stops working, and reinstalling the drivers as above doesn’t resolve the problem. This is because the 5.0.0-37 headers have been removed from the repo.

The solution I found was to install the headers (generic, and all) from the Bionic (18.04 LTS) repo.