Replacing the front discs on a Saab 93 is simple, however, the rears are a little more work (in fact, they're a pain in the arse), and you're going to some specific tools in order to achieve the job.
This was performed on a 2010 Saab 93 TTID, but the process should be the same for most model years (and may actually be more or less the same on the Vauxhall Vectra).
Be aware: some of the fixings are extremely tight and have limited access, there will almost certainly be periods where you'll wish you let the garage do the job.
Amongst the usual selection of tools and sockets etc, please ensure you have
- A selection of longbars/torque wrenches etc (you're going to need to find something that can fit)
- A E18 Torx socket to fit each of these. You cannot proceed without.
- A E20 Torx socket (just in case)
- A deep 21mm socket
- An electric or air impact driver (you may be able to proceed without, but there's a strong chance of getting stuck)
- A small/pocket blowtorch
- A jack that can lift your car as high as possible (makes more room to work in on the hard bit)
- Brake rewind tool sized to fit a Saab (the "universal" 2 size ones don't) - I have this kit, the Saab needs disc "M" on there.
You will also need to ensure that you've ordered the correct size replacement discs for your car. You can quite easily ascertain what size you will need.
As some may already know, I offer a small public encrypted DNS service at dns.bentasker.co.uk, offering DNS resolution via DNS-over-HTTPS (DoH) and DNS-over-TCP (DoT).
The setup I use is an evolution of that one I described when I published Building and Running your own DNS-over-HTTPS Server 18 months ago, providing ad and phishing blocking as well as encrypted transport.
It was never intended that my DNS service take over the world, in fact, on the homepage it says
A small ad and phishing blocking DNS privacy resolver supporting D-o-H and D-o-T .... This service is, at best, a small hobby project to ensure that there are still some privacy-sensitive DNS services out there.
Not all nodes in my edge even run the DNS service.
The service has always seen some use - much more than I really expected - with queries coming in from all over the globe, and query rates are pretty respectable as a result.
However, recently, query rates changed, and there was such a seismic shift in my daily graphs that the previous "routine" usage started to look like 0:
I'm omitting figures and dates out of an abundance of caution, but the lines represent usage across different days (the vertical grey lines each denoting a day)
You can see that usage increased by several orders of magnitude (the turquoise line is the number of advertising domains blocked, so usually increases roughly proportionately).
The change in traffic rates triggered a few things
- Alarms/notifications from my monitoring
- Notifications from some of my connectivity providers to say they were mitigating an apparent DoS
This post is about the (very few, actually) minor things I found I needed to do to ensure Pi-Hole could keep up with the new load.
There are a wide variety of use-cases for disk encryption, and the idea of automatically mounting an encrypted disk/partition without user intervention is an anathema to many of those - anyone who can take physical possession of your system will have the disk auto-mount for them.
However, there is a very simple use-case which benefits from being able to automount a second encrypted disk.
If you're storing data unencrypted on a drive and it fails, you're now potentially left with something of an issue, particularly if you intend to RMA it (return it under warranty) - could the drive be fixed, allowing someone else to pull that data off the drive (bearing in mind the manufacturer may fix the drive and sell as refurbished)?
Similarly, when you need to expand your storage, you hit a similar conundrum - do you trust disk wipes sufficiently to be willing to sell/pass the disk on (a particular concern with SSDs where data may previously have been written to a now bad block, so won't be overwritten by your wipe), or do you feel you have to physically destroy the disk, un-necessarily generating e-waste.
Using Full Disk Encryption (FDE) addresses both of these situations - the manufacturer might fix the disk, but without the key the data's just random bytes, similarly, for whoever buys your disk off ebay.
But, FDE can quickly become a major inconvenience at boot - your system will stop booting and ask you to provide the decryption passphrase. That's particularly problematic if you're talking about a headless system like a NAS, where you want things to come up working following a power cycle.
It's possible (trivial even) to configure so that the system uses a key stored on another disk (like your root filesystem, or if you prefer, a USB flash drive) so that the partition is automagically mounted.
This documentation details how to set up ecryptfs on a disk (or partition) and add it to
/etc/fstab so that it automatically mounts at boot
All commands are run as root, so use
Quite some time ago, I wrote some documentation on how to stand up a DNS-over-TLS server using a Nginx reverse streams proxy to terminate the SSL.
However, since then (in fact, back in 1.6.7) Unbound released support for directly terminating TLS connections.
This documentation details the (simple) config changes necessary to configure Unbound to service DNS over TLS (RFC 7858) queries.
You will need to have a copy of Unbound >= 1.6.7 installed (and, of course, you should really be running the latest release)
Within the config file (normally
/etc/unbound/unbound.conf) you'll need to add the following within the
interface: 0.0.0.0@853 interface: ::0@853 tls-port: 853 tls-service-key: [path to your SSL Key] tls-service-pem: [path to your SSL cert] access-control: 0.0.0.0/0 allow
You then simply need to restart
unbound and can then confirm it's listening
systemctl restart unbound netstat -lnp | grep 853
As we only want to accept TCP connections (to reduce opportunity for us to be used in a reflection attack, we firewall UDP 853
iptables -I INPUT -p udp --dport 853 -j DROP
Google's Android OS used to have an annoying feature - smart network switch - which would inevitably lead to it sitting there, not using your wireless network, displaying the message "No network access".
This usually happened as you got home, because it had picked up your wifi at the very extreme edge of it's reach, and the test probes had failed as a result.
The functionality works by placing some test HTTP requests when connected to a wifi network - if those requests fail, it's considered that the wifi doesn't have network access. This (fairly flawed) methodology doesn't properly account for a range of possible failures in the test itself.
My site has supported using V3 Onions at the transport layer for quite some time, having implemented Alt-Svc headers to allow Tor to be used opportunistically back in October 2018.
What I hadn't got around to, until now, was actually support direct access via a V3 hostname. I'd put a reasonable amount of effort into generating a personalised V2 address, and making sure it was documented/well used.
However, V2 Onions have been deprecated, and will start generating warnings in a month. Total discontinuation of V2 support is scheduled for July 15th 2021.
So, I figured I should get V3 support up and running, and have today launched the service.
If you're sometimes finding that the remote buttons on your Saab key don't work, it's probably that the battery is coming up for replacement.
The key on both the Saab 93 and Saab 95 is essentially a large plastic sheath around a hidden key, with some rubberised buttons on the front.
Replacement of the battery is quick and easy, and follows much the same process as replacing the keycase itself.
Cars come in a weird and wonderful array of colours, which is great until you need to find out which exact shade of touch-up/repair paint you need to order after an issue.
Most manufacturers give shades both a name and a code - "Black Sapphire" (20R) , "Flame Red" (79L) - but, there may be multiple codes/shades within a name.
This documentation details how to find the paint code for a Vauxhall car. In this case, it's a Corsa but the information is available on all models, it's only the location which may change.