• Logga in säkert med SSH

    Jag skriver som bekant denna blogg i Markdown, ett sätt att skriva text med exempelvis länkar, punktlistor och annat i som sedan konverteras till HTML för att webbläsare ska förstå det. När man skriver i Markdown och dessutom använder Jekyll som “bloggmotor” har man två alternativ - antingen laddar man upp sin artikel i markdown-format till sin server och låter servern bygga filen åt dig, eller så bygger man hela sajten på sin dator och laddar sedan endast upp förändringarna i sajten till servern. Jag föredrar det senare, eftersom förändringarna oftast innefattar en eller ett par bilder och några kilobyte text.

    Att sitta hemma och ladda upp detta till en server hemma är ju ingen större grej egentligen, men kanske har du inte servern hemma utan någon annanstans, eller så är du ute och flänger och därmed befinner dig i samma situation. Eller så kanske du bara vill kunna logga in via SSH till en server på Internet utan att behöva oroa dig för säkerheten.

    Oavsett anledning så är detta egentligen inte överdrivet komplicerat att sätta upp. Jag kör mina servrar hemma och därmed kan jag själv bestämma rätt mycket om hur det ska se ut. Jag hade givetvis kunnat sätta upp en VPN-server men det är bökigt och omständigt och, om sanningen ska fram, inte alltid nödvändigtvis säkrare. Så jag gjorde slag i saken och installerade en virtuell OpenBSD-server, en Unixdistribution som avgjort får anses vara en av de säkraste som går att installera. Därefter konfigurerade kopierade jag över min SSH-nyckel från min bärbara dator till filen .ssh/authorized_keys. Efter att jag kontrollerat att jag faktiskt kan logga in den vägen (bra att kolla innan man ger sig ut på fältet…) så kan jag redigera filen /etc/ssh/sshd_conf och se till att följande rader ser ut som följer:

    PermitRootLogin no
    AuthorizedKeysFile .ssh/authorized_keys
    PasswordAuthentication no
    ChallengeResponseAuthentication no
    AllowTCPForwarding yes

    Att jag har med AllowTCPForwarding yes är helt enkelt för att jag vill kunna tunnla exempelvis RDP-trafik över SSH. Trevligt och smidigt.

    Ett tips är att inte öppna detta via port 22 i din brandvägg, vilket är den vanliga porten för SSH. Lägg detta hellre på en port över 1024 och kör en port forward i din brandvägg till port 22 i servern du ska använda som SSH-maskin.

    Om du som jag vill ladda upp din sajt via rsync över ssh då? Så här kan det se ut om du scriptar det lite enkelt:

    cd /bloggkatalog
    jekyll build
    rsync -avz -e "ssh -p portnummer" /blogg_katalog/site/ användarnamn@server:/path/till/bloggen/

    Du kan läsa mer om hur du konfigurerar din SSH-server här!

    Lycka till!


  • Datormagazin Retro nummer 3!

    Förhandsbeställning av vårt tredje nummer av Datormagazin Retro är nu öppnad och du är mer än välkommen att beställa något av de fantastiska paket som finns att köpa.

    Vad ska vi skriva om? Här är några av artiklarna vi jobbar på till Datormagazin Retro #3:

    Amiga-acceleratorn som alla kan bygga Demodaxx och spelrecensioner ABC80: Den svenska datorn som tog världen med storm – ett litet tag CDTV – mastodontfloppen AmigaOS 3.1.4 - vi har testat! Hoarders – vi pratar allvar med de som staplar sina retrodatorer på hög

    Med mera – minst sagt. Förslagen på artiklar är många, och listan är lång.

    Nummer ett av Datormagazin Retro är slutsåld sedan länge, och nummer två är inte långt från att ta slut för gott. Just det – vi trycker inga fler nummer av denna tidning så passa på att beställa idag innan den är borta för gott.

    Läs mer och beställ här. Tack för ditt stöd!

  • Därför ska du äga dina data

    Flickr är en bildtjänst jag haft konto hos sedan tjänsten grundades och senare blev en del av Yahoo. Efter att ett krisande Yahoo sålde av Flickr till SmugMug i april 2018 så har världen i princip bara väntat på att förändringar ska ske. När nyheten väl slog ner så var det egentligen inte så underligt att gratissegmentet, med en terabyte fri lagringsyta för icke-betalande användare, försvinner och ersätts med en övre gräns max 1000 bilder för de som tycker det är okej att köra gratis.

    Vad värre är så kommer Flickr helt sonika att radera alla bilder för alla gratisanvändare som överskjuter den gränsen på 1000 bilder. Flickr och deras nya ägare har presenterat alla dessa ändringar som bolaget avser genomföra, och jag tycker som sagt att de är helt rimliga, men det gör också att det precis som när det gäller e-posthantering och annat måste handlar om hur man som konsumen antingen betalar för sig eller så får man bygga en hantering av den här typen av information själv. Flickr vill ha 49.95 dollar, alltså drygt 500 kronor, per år för att du ska kunna lagra obegränsat med bilder hos deras tjänst. Detta kan jämföras med Apple och Googles motsvarande tjänster som kostar dryga hundralappen i månaden om du vill lagra en terabyte information (bilder, filmer, med mera) på deras servrar, och utifrån det perspektivet är inte Flickrs prislapp så vansinnigt blodig egentligen.

    Jag lagrar mina bilder hos Apple via Photos-applikationen, men jag har under alla år också haft tusentals bilder hos Flickr som backuplagring ifall något skulle hända med Apples molnlagring. Nu ska det sägas att bildhanteringen i iCloud varit i princip skottsäker sedan dag ett så jag är inte så vansinnigt orolig för att nåt ska gå fel där men samtidigt så lever jag också efter samma princip som hanteringen av min e-post, mina domäner, med mera: jag äger, driver och tar ansvar själv för att min information är säker, tillgänglig och har säkerhetskopior. Mina bilder lagrar jag på två olika, fysiskt åtskilda, ställen utöver iCloud och min Macbook Pro. Överdrivet paranoid kanske jag verkar framstå som, och i så fall bjuder jag på det, men om inte jag tar ansvar för min egna information vem ska då göra det?

    Jag förstår givetvis att alla inte kan, eller vill, installera och driftsätta servrar hemma, men man kan åtminstone betala för en backuplösning i molnet oavsett om den heter Dropbox, OneDrive eller Backblaze, och utöver detta lägga all känslig information på en extern hårddisk som man sen låser in på ett bra ställe. Det är en bra början, och ett bra sätt att ta ansvar för sina egna data för till sist och syvende kommer ingen annan göra det åt dig och i synnerhet inte om du inte är beredd att betala för det.

  • Tack och adjö, Red Hat

    Nyheten slog bokstavligen talat ned som en bomb i IT-världen: IBM köper Red Hat. På marknadsföringsspråk heter det att “Red Hat går samman med IBM”, men låt oss inte för ett ögonblick betvivla hur saker och ting egentligen ligger till: IBM ser chansen att växa till en vansinnigt stor spelare inom plattformar för molntjänster och med Red Hat blir de just det - åtminstone just nu. Framtiden får utvisa hur villiga Amazon, Microsoft, Google och Alibaba är att förhandla med stora IBM framför mer hanterliga Red Hat.

    Egentligen är ju Red Hat och IBM en matchning som är svårslagen - två tekniktunga företag med tekniktunga kunder som gärna arbetar med virtualisering, lagring, applikationslager och, givetvis, support och annat som de gärna tar bra betalt för. Mitt problem med detta är att IBM traditionellt är ett företag som inte nödvändigtvis varit så bra på att ta hand om de bolag de köpt, eller ens ta hand om sin egna teknik som de byggt upp och utvecklat. Teknik och tjänster som är ganska enkla att arbeta med tenderar att bli oerhört komplexa, trögjobbade och det blir rörigt.

    Kort sagt: kan man göra något överdrivet komplicerat och rörigt så kan man räkna med att IBM kommer göra just det. Åtminstone är det så ur ett historiskt perspektiv, och om det är något IBM har gott om så är det historia. Jag återkommer till det lite senare.

    Visst, vi kanske inte ska påminna IBM om OS/2 (något som än idag är något av en öm tå för bolaget), eller om hur de tog en gruppvaruplattform i form av Lotus Notes och på några år förvandlade det till en salig röra med stöd för olika operativsystem med en än mer salig röra av tillhörande filer för uppgraderingar, nedgraderingar och annat. Även om du exempelvis körde en Lotus Notes-server på AIX så var du tvungen att installera en Lotus Notes-server på Windows för att kunna åstadkomma en koppling till iPhone 3G, för att ta ett exempel. Varför inte bygga in stöd för ActiveSync direkt i den i Lotus Notes inbyggda webb/applikationsservern, frågar du? Äsch, det vore väl dumt att stödja en industristandard när man kan bygga något eget, onödigt komplicerat, system istället. IBM gav oss Lotus Traveler (numera IBM Traveler), och den var då, och troligen också nu, på pappret en smidig och enkel lösning men i praktiken raka motsatsen.

    IBM har säkert fixat det är med pushstöd för iPhone och andra ActiveSync-enheter vid det här laget. Eller inte - detta är ett supportdokument från september i år, och om du som Red Hat-kund funderar på hur din framtid ser ut när det gäller supportdokumentation så rekommenderar jag att du läser det här dokumentet både en och tre gånger så förstår du lite hur IBM fungerar: ActiveSync-anslutningar fungerar inte efter att iOS 12 förändrat hur det autentiserar sig mot servern, i det här fallet IBM Traveler. Istället för att IBM bara fixar problemet med en patch eller liknande (det finns gott om dem så det är ju inte som att IBM inte vet hur man tar fram en patch) så publicerar de först ett dokument som förklarar problemet, som kan läsas så här: “IBM gör saker på ett sätt. iOS 12 gör saker på ett annat sätt. Vi anser att vårt sätt är rätt”. Om du ändå envisas med att vilja få de här grejerna att fungera finns ytterligare ett supportdokument som förklarar hur du löser problemet.

    Kanske. Som gammal ärrad Notes/Domino-administratör var det i princip alltid 50/50 att den dokumentation som IBM publicerade faktiskt stämde överrens med verkligheten.

    Raden av olika system och applikationer som IBM köpt upp genom åren och sedan döpt till “Tivoli nånting-nånting” är lång och tyvärr kantad med produkter som ena året var det nya heta och ett par år senare glömts bort helt.

    IBM behöver Red Hat mer än det motsatta förhållandet. IBM nöjer sig nämligen inte med att bara använda en teknik som redan finns där, exempelvis KVM för virtualisering, man måste äga hela kedjan och antingen bygger man upp det själva, vilket IBM som bekant inte är något vidare på eftersom det, åter igen, alltid blir oerhört komplicerat när IBM ska bygga något, eller så köper man ett bolag eller en produkt som redan listat ut allt och har en fungerande affärsmodell som man, om man heter IBM, kan sätta tänderna i.

    Det bästa som kan hända är att IBM låter Red Hat fortsätta arbeta som de gjort nu. Det är nog inte helt sannolikt i mina ögon - istället kommer bolagen arbeta sida vid sida under ett par år och sedan kommer integrationen gradvis att ske tills Red Hat är helt integrerat i IBM, de flesta nyckelpersonerna från Red Hat är borta och vi står där med samma sörja som IBM lyckades förvandla Notes/Domino till efter köpet av Lotus.

    När vi nu kan börja förbereda oss på att säga adjö till Red Hat så kan vi, tyvärr, också börja förbereda oss på att säga adjö till CentOS och Fedora. Jag kan se en liten möjlighet att IBM försöker använda Fedora som ett skrivbordsalternativ till Windows men bolaget har redan försökt detta tidigare och det gick verkligen inget vidare då så de har nog gett upp tanken på att erövra skrivbordet en gång för alla.

    IBM har över åren faktiskt haft en ganska bra och generös syn på öppen källkod men det finns exempelvis ingen anledning att de ska ge bort ett system som Spacewalk när de istället kan ta betalt för Red Hat Satellite server. IBM måste, och kommer också, att fortsätta publicera källkod de ändrat i enlighet med licensmodellen för Linux men precis som Apple så kommer de om några år inte publicera en gnutta mer än de absolut behöver. Detta kan komma att göra livet väldigt svårt för CentOS som å ena sidan ofta fungerar som en inkörsport för företag till Red Hat:s kommersiella modell - man kör CentOS gratis och inser sen att det vore trevligt med ett supportnummer att ringa när saker går sönder - men det IBM som många av oss känner behöver ingen “inropare” - de är IBM i deras ögon väljer man IBM för att de är IBM och väljer man nåt annat så har man inget förstått. Är jag orättvis att skriva på det sättet?

    Kanske - men IBM:s traditioner sitter väldigt hårt i väggarna på det där bolaget. När jag besökte IBM i Kista en gång i tiden pratade man inte om Linux, man pratade inte om Windows och man pratade definitivt inte om OS/2. Tog man upp ett sådant ämne själv så byttes det ämnet raskt ut mot något annat. IBM pratade gärna TSM (Tivoli Storage Manager), AIX, Power-processorn, databasservern DB/2 och en rad andra produkter som de faktiskt var och är duktiga på men IBM skulle åtminstone då aldrig erkänna att de misslyckats. I ärlighetens namn har IBM som alla andra gamla teknikbolag förändrats de senaste åren - mycket av deras affärsmodell har ställts på ända i och med “molnet” men jag, och många med mig, kommer för alltid att förknippa IBM med en stor, grå (eller blå, beroende på vem du frågar) koloss som man aldrig riktigt kan få grepp om. Man ska också ha klart för sig att IBM helst jobbar med företag i samma storlek som de själva - små och medelstora företag är inte nödvändigtvis en perfekt matchning för IBM och det är om något inte särskilt goda nyheter för alla de som kör Red Hat:s Enterprise Linux idag.

    När nyheten om IBM:s köp av Red Hat dök upp på min radar så satte jag direkt igång med att titta på alternativen för mina servrar jag driver hemma. Det är trots allt 20-25 virtuella maskiner som körs på CentOS, inget man byter ut i en handvändning direkt. Jag landade i FreeBSD och har redan satt igång med att konvertera mina webbservrar och min lastbalanserare till denna plattform. Kanske är det alldeles för tidigt att agera men jag vill vara förberedd och det borde du också vara.


  • Figlet

    När man arbetar med ett större antal servrar och sitter och loggar in via SSH så kan man i ett stressat läge inte alltid uppfatta vilken server man loggat in på. Det har hänt mig en och annan gång och efter att en av lyssnarna till min och Fredrik Björemans podcast berättade att han med hjälp av en text-till-ascii-konvertering alltid la in servernamnet i filen /etc/motd, som står för message of the day, vilket traditionellt varit ett enkelt sätt för en systemadministratör att meddela andra användare i ett Unix-baserat system om exempelvis kommande uppdateringar eller andra nyheter som de behöver veta.

    /etc/motd är helt textbaserad så man kan i praktiken skicka in vilken information man vill i den texten. I mitt fall vill jag automatisera detta, exempelvis via Ansible och ett script jag kör på nyinstallerade CentOS-servrar som gör en rad saker (sätter mitt lokala repo som det som servern laddar ner paket och uppdateringar från, ställer in min syslog-server, med mera). Via ett program kallat Figlet, som finns i CentOS 7-repot, kan man generera “ascii-logotyper” från vanlig text. I mitt fall vill jag ta hostnamnet på servern men inte dess domännamn och skicka in i /etc/motd genom ett script. Följande enkla kommando löser detta:

    figlet ${HOSTNAME%%.*} > /etc/motd

    Detta kan givetvis också scriptas så kommandot körs via SSH eller via en kickstart-server om så önskas.

    Avslutningsvis: Figlet kan en hel del andra massa roliga saker som jag rekommenderar alla att titta närmare på.



CC BY-NC-SA 4.0