doas.conf

Det här är vad du vill lägga in i din /etc/doas.conf:

permit persist :wheel
permit nopass keepenv root

Så, klart. Nu slapp du gå in på Ted Unangsts blogg och acceptera hens egensignerade certifikat. Varsågod.


PS. doas är som sudo, fast skapat av OpenBSD-folket i hopp om att reducera komplexiteten i sudo för att göra den säkrare. Jag använder doas när jag sköter om FreeBSD- eller OpenBSD-system.

less *is* more

Jag använder unix-programemt less i princip dagligen, men har inte läst manualsidan för den förr än väldigt nyligen – och efter detta tänkte jag nu författa en liten hyllningstext till detta mångsidiga verktyg. 🙂

På jobbet läser jag mycket loggfiler och använder less för att kunna hoppa fram och tillbaka i den, men hade gärna sluppit byta fram och tillbaka mellan tail och less då jag ibland vill se loggen glida förbi, och ibland lusläsa den.

Båda dessa går givetvis att göra utan problem i less.

  • För att söka nedåt i en fil, tryck / och det du söker.
  • För att söka uppåt i en fil, tryck ?
  • För att följa filen som med tail, tryck F (stora f), och för att avbryta Ctrl-c

En av mina favoriter är om jag söker efter en specifik term (”upgrade complete”) som borde dyka upp lite senare, så kan jag söka efter termen (/ följt av termen och Enter) och trycka Esc följt av F. Då kommer less följa filen när den uppdateras, och när raden jag tidigare sökt dyker upp så signallerar less detta och slutar följa filen.

Om jag vill hitta tillbaka till en specifik plats i filen kan jag trycka m följt av en bokstav. Vill jag sedan hitta tillbaka till samma punkt igen trycker jag ' (”enkelfnutt”) följt av samma bokstav, och vill jag hoppa fram och tillbaka mellan mina två senaste markerade punkter trycker jag bara enkelfnutt två gånger ('').

Det finns sjukt många fler sätt att använda less på, men tangentbordsgenvägarna ovan kommer hjälpa mig signifikant med tanke på hur mycket tid av min tid som tillbringas i samma program.


Som alltid finns det fantastiskt mycket fint att upptäcka om en bara tittar lite mer noga runt sig, typ i en manualsida.

tinkergate

Min router har kraschat ett antal gånger på sistone, så jag tänkte jag skulle prova att använda mig av en pyttedator för att skyffla data mellan mig och det stora, läskiga internetet. Jag kan ha sett till att ha en Tinkerboard S tillgänglig, tillsammans med ett no-name USB-baserat nätverkskort. För att göra livet lite svårare ville jag även testa att sätta upp en brandvägg med hjälp av nftables då det ändå är Framtiden(tm).

TL;DR, en Tinkerboard S är helt överdimensionerad uppgiften att skyffla data givet mina väldigt enkla brandväggsregler och överföringshastigheter i allmänhet. Köp en om du behöver den, den kostar bara några hundra kronor!

Read More

Homeassistant + Monit = ?

Jag fick för mig att testa monit då jag sett namnet dyka upp här och där på sistone, och kom på att jag verkligen behövde sätta upp monitorering för min HomeAssistant-instans. Då det var en förvånadsvärt trevlig upplevelse att sätta upp tänkte jag dela med mig hur det blev. Innehållet nedan är förresten applicerbart för att köra alla möjliga tjänster med.

Hade jag kört på ett Linux-system hade jag satt upp en systemd-tjänst istället för att använda monit, men den datorn som används för att köra HomeAssistant hemma hos mig kör OpenBSD. Om du skulle använda något av de uppskattningsvis tre distributioner som inte använder systemd är nedan relevant för dig. 🙂

Read More

Home assistant, sätta upp sensorer

Jag har använt en del automatisering hemmavid sista halvåret eller så. Det är rätt kul, om än onödigt och av begränsad nytta – men jag slipper iaf tänka lampan när jag kommer hem! Givet att min presence detection funkar, annars blir det att komma hem till mörker och felsökande.[^1]

Om någon skulle vara nyfiken på hur en sätter upp en sensor tycker jag följande artikel var rätt trevlig – Monitoring Internet Speed with Home Assistant.

Även om artikeln behandlar speedtest-modulen är den applicerbar för de flesta andra tillgängliga sensorerna, och den går även igenom hur en gör presentationen lite trevligare med grupper och skapa egna etiketter.

[^1]: Tur att jag är van vid att stå i mörkrum, vi kan nöja oss med att säga att det här har hänt några gånger för mycket.

TSB

Det här med data är rätt svårt, särskilt när det ska bli rätt också! Även om det kan tyckas vara uppenbart att förändringar i komplexa system körandes i komplexa miljöer borde skötas med (extrem) försiktighet så verkar detta inte riktigt…fastna…inom branschen.

I skrivande stund har problemen inom den brittiska banken TSB pågått i drygt en vecka, och verkar ha stört rätt många procent av bankens kunder på ett bitvis allvarligt sätt, med bristande funktionalitet, läckande personliga data och vilseledande kommunikation utåt.

Nedan är huvudsakligen spekulationer utifrån andras diton, så ta med en sedvanlig nypa salt.

  • Problemen började med en migrering från en äldre till en nyutvecklad platform.
  • Den nya platformen verkar ha utvecklats under tidspress (18 månader)…
  • …utan tillräcklig förståelse att den äldre miljön med allt bagage det detta innehöll…
  • …av utvecklare i ett annat land (Spanien) som inte delar modersmål med förvaltarna av det äldre systemet.
  • Dessutom verkar det ha varit en big bang-migrering utan samkörning av system för att säkerställa att den nya platformen verkligen fungerar på ett tillförlitligt sätt.
  • Utöver detta är mitt intryck att företagskulturen inom åtminstone TSB har varit prestigeladdad och grabbig.

Herregud.


Det är alltid lätt att vara efterklok, men förutsättningarna ovan tycks vara ett perfekt recept för problem. Det är också lätt att peka på och tro att en redan har lärt sig nog av att läsa om det för att själv inte begå samma misstag.

Spoiler: vi kommer aldrig att lära oss. Den här typen av elände kommer fortsätta men förhoppningsvis är det inte samma typ av elände, utan nya & mer exotiska detaljer!

Länkar

Petoi

Det här var väldigt coolt, och aningens skrämmande.

Dagens bugg: Incheckningen Bromma

På avdelningen för oväntade features hittade jag idag något nytt och spännande — nämligen hur självincheckningsautomaterna på Bromma flygplats verkar hantera identifierare om en skannar sitt pass för att hämta ut sina biljetter. Det var också ett underhållande sätt att vakna till på inför resan utomlands. 🙂

Att reproducera var enkelt, det var bara att skanna mitt pass och kontrollera att mina bokningar dök upp på skärmen — tyvärr var det inte mina bokningar som dök upp!

Mjukvaran som körs på självincheckningsautomaterna är garanterat testad och dokumenterad av en människa innan den installerades på automaten, och helt enligt de bestämmelser som gäller inom flygbranchen, men ändå råkar jag ut för en avvikelse av denna magnitud? Hur gick det till? Här är min teori.

Då de flesta som testar mjukvara gör det i en klassisk blackbox-anda (inklusive undertecknad) där vi inte bryr oss om implementationsdetaljer så kan jag tänka mig hur testningen här gick till.

  1. Testaren får tillgång till senaste mjukvaran installerad på en typisk hårdvara (motsvarande en självincheckningsautomat på plats, hoppas jag) och har en lapp om att testa att det går att skanna ens pass för att få upp sina bokningar. Mjukvaran levereras i regel en aning sent i projektet/sprinten och det är givetvis rätt bråttom
  2. Testaren förbereder sin verifiering och får tag på en samling testpass, sätter upp ett antal flygningar och bokningar till dessa i sin testmiljö
  3. Testaren verifierar funktionaliteten utan problem, och i bästa fall gör det med ett antal edge cases, typ diplomatpass, skyddade identiteter etc
  4. Testaren skriver någon typ av rapport enligt sin arbetsmetod (testrapport, testsessionsanteckningar etc)

Allt bra såhär långt, förutom att implementationen tycks vara helt knasig då den tycks använda resenärens namn som nyckel för att plocka fram bokningar!

När en inte bryr sig om implementationsdetaljer kan det bli såhär tokigt om beställaren inte själv tänker till eller vet vad hen egentligen behöver, kravställaren bara översätter kundens beställning till krav eller uppgifter för utvecklarna, utvecklarna tänker snett och/eller implementerar enligt kravställarens leverabler, ingen fångar problemet vid kodgranskning och testaren inte har tid eller intresse att gräva ner sig tillräckligt för att notera detta.

Frågan är också vad som hade varit en bättre lösning — för jag misstänker att det här med personliga identifierare är ett klurigare problem än en lätt tror.

  • I Sverige har vi våra personnummer vilket är väldigt praktiskt och ovanligt, och så av vad jag vet finns inte detta system på så många fler platser i världen.
  • Det är rimligt att anta att det första namnet i ett pass även är det namn som passinnehavaren använder sig av till vardags…förutom i Sverige där det inte alls behöver vara så (som för mig)
  • Pass ska ha ett passnummer, men hur kopplar du det till en fysisk person om du t.ex. inte är i ditt hemmaland? Att tillåta vilka datorer som helst att komma åt ett API för att hämta ut persondata baserat på en nyckel som är så pass enkel att gissa som ett passnummer låter nämligen direkt farligt.
  • Hur skapar du ens en identifierare för pass som är globalt unik, svår att gissa men lätt för en människa att kontrollera och som alla kan enas kring? UUID uppfyller första kravet men inte andra, och att uppfylla det tredje kravet kan vi bara drömma om. 🙂

Det här med data är svårare än vad en tror.


Själv är jag givetvis felfri. Strax efter att jag upptäckt ovan noterade jag att jag tagit på mig byxorna med synliga genanta hål — och att jag inte packade några andra byxor då jag ändå bara skulle vara borta en natt…

Alltid nära

Bilden ovan är en historia jag gillar att beklaga mig över. Den är (enligt mig) finurlig då den inte är helt uppenbar, den har inslag av banalitet och den var dessutom geotaggad med rätt plats.

Bilden har dock bara 6 lajks på instagram. Och då är den sjätte lajken inkommen för inte alls särskilt länge sen, och då enbart av sympati efter att jag berättat denna historia.

Bilden är tagen på parkeringen till ICA Nära Riksgränsen.

Note to self: NixOS och paket från master

Jag har börjat använda NixOS på rätt många av mina datorer och jag gillar det verkligen, även om det huvudsakligen är känslomässiga argument jag använder mig av. Mer om detta i ett annat inlägg, detta inlägg är mest för att själv komma ihåg hur jag gjorde för att installera hugo (som tidigare byggde denna hemsida) från mästergrenen för nixpkgs.

nix-env -f https://github.com/NixOS/nixpkgs/archive/master.tar.gz -iA hugo

Klart.

En deklarativ uppdatering

Ett lite mer deklarativt sätt att göra det på är såhär:

environment.systemPackages =
let
  unstableSrc = pkgs.fetchFromGitHub {
    owner = "NixOS";
    repo = "nixpkgs";
    rev = "b332924e6aac9e34168f43cf7db5181bcd01f0e5";
    sha256 = "025vac8h89jvikm6c2mlrzv7p57j9rwkkpnshaq1fw63pcn8dpqf";
  };
  unstable = import unstableSrc {};
  stable = import <nixpkgs> {};
in [
  unstable.hugo
  stable.wget stable.curl
];

Det här är fortfarande så pass nytt och obekant att jag behövde rätt lång tid på mig för att klura ut det här. Jag misstänker att det även går att lösa på ett betydligt elegantare sätt, men dit har jag inte riktigt kommit än. 🙂

Det går även att göra såhär:

environment.systemPackages =
  let
    stable = import <nixpkgs> {};
    unstable = import (fetchTarball "https://nixos.org/channels/nixos-unstable/nixexpr
s.tar.xz") {};
  in [ stable.wget stable.curl unstable.hugo ];

Lite mindre stök, men även lite mindre deterministiskt vilket annars är lite av styrkan med denna distribution.

Närmare nirvana

Den här varianten är förvisso lite längre än den senaste, men känns ändå lite…bättre! Varianten nedan är givetvis stulen från någon annan vänlig själ på StackOverflow.

Namnet inom vinkeljärnen nedan ska motsvaras av namnet på en kanal, som du exempelvis kan definiera såhär:

nix-channel --add https://nixos.org/channels/nixos-unstable nixos-unstable
nix-channel --update

Och sedan, i din /etc/nixos/configuration.nix:

# Credit: https://stackoverflow.com/a/47571488
nixpkgs.config = 
{
    # Allow proprietary packages
    allowUnfree = true;

    # Create an alias for the unstable channel
    packageOverrides = pkgs: 
    {
        unstable = import <nixos-unstable> 
            { 
                # pass the nixpkgs config to the unstable alias
                # to ensure `allowUnfree = true;` is propagated:
                config = config.nixpkgs.config; 
            };
    };
};

Nu är det bara att använda unstable som prefix för de paket du vill ha från den ostadiga grenen. Om du inte kört en nix-channel --update är det värt att göra det innan du försöker dig på en nixos-rebuild dry-run, annars kommer det inte går att bygga om systemet.

Vill du förresten göra livet lite bekvämare rekommenderar jag följande:

environment.systemPackages = with pkgs; [ wget curl unstable.hugo ];

Nu slipper du även skriva prefixet för de stadiga paketen!