Joakim Melin
Installera macOS Monteray i äldre iMac ⚓
Jag begåvades ju med en äldre 27" iMac i höstas och efter att ha bytt hårddisk i den så installerades den senaste version av macOS som fungerade på maskinen.
Att denna modell av iMac, en 27"-modell från senare delen av 2013 med en 3,5GHz Core i7-processor med fyra processorkärnor, 16GB internminne och 4GB i grafikminne i grafikkortet av modell GeForce GTX780 M, inte skulle stödja macOS Monterey, som i skrivande stund är den senaste versionen av macOS som släppts i skarp version, kändes således lite fånigt. I synnerhet med tanke på den fantastiska skärm som sitter i datorn. Så jag bestämde mig för att göra något åt saken.
Det finns nämligen massor med knepiga och omständiga metoder för att få detta att fungera, eller så finns det en väldigt enkel dito. Jag valde den senare metoden.
Den metoden bygger på en programvara som heter OpenCore, och det hela är som tidigare nämnts vansinnigt enkelt.
Börja med besöka projektets hemsida (länk ovan) och kontrollera om den Mac-modell du vill installera något nytt och fint på kommer stödja det.
Om du konstaterar att så är fallet kan du gå vidare med att ladda ned programvaran, OpenCore.
Starta denna programvara och du kommer mötas av en meny som ser ut ungefär som den ovan. Kolla så programvaran har identifierat din Macmodell korrekt. Om allt ser bra ut så klickar du sedan på “Create macOS Installer” och sedan klickar du på “Reload with all installers” för att se alla installationsfiler som finns att ladda ned hos Apple.
Välj den senaste versionen av Monterey som är stabil. I mitt fall valde jag 12.4. Filen ska sedan laddas ned och verifieras efter nedladdning vilket kan ta en stund.
Därefter är det dags att välja den version av macOS du just laddat ner och skriva den till USB-minnet. Detta tar också en ganska lång stund. För detta behöver du ha ett USB-minne på 16GB eller mer som är felfritt så se till att du har det innan du drar igång denna process.
När detta är klart väljer du till sist “Build and install OpenCore” i menyn för OpenCore-applikationen. Välj slutligen att skriva OpenCore till USB-minnet du just skapat.
När detta är klart kan du starta om din Mac. Håll nere alt-tangenten när datorn startar upp så du får upp menyn med vilka volymer du kan starta datorn från.
Välj den som heter “EFI Boot” och starta från den. Därefter får du frågan igenom vilken volym du vill starta ifrån, då väljer du “Install macOS Monterey” och kör igenom installationen som vanligt.
När installationen är klar och din Mac startar om ska du låta USB-minnet sitta i. När du slutfört installationen och loggat in startar du OpenCore-applikationen igen och kör “Build and install OpenCore” ännu en gång men denna gång skriver du programvaran till din interna hårddisk som du startar macOS Monterey från. När detta är klart kan du ta ut USB-minnet från din Mac och nu kommer den starta som vanligt igen.
Det kan vara värt att notera att om du installerar en uppgradering av macOS Monterey så kan du behöva installera OpenCore på hårddisken ännu en gång för att kunna starta din dator då uppgraderingen sannolikt skrivit över de filer som OpenCore-patchningen lagt in innan installation.
Hur fungerar det i praktiken då? Jag ska inte ljuga och säga att denna iMac är lika snabbt som en modernare modell av senaste generation med M1-processorn för det är det inte… åtminstone inte jämfört med min Mac mini M1, men det är i allra högsta grad användbart och skulle jag av någon anledning tvingas använda denna iMac som min primära dator så skulle jag inte ha något problem med det över huvudtaget. Visst, man får en liten “chock” emellanåt när fläkten varvar upp (det är ju inget man är direkt van vid från att ha en M1-baserad dator) men annars är det faktiskt trevligt att köra macOS Monterey på denna iMac.
I bilden ovan tittar jag på en korrekt Youtube-video i 1080p-upplösning och inga fläktar drar igång i datorn över huvudtaget. Faktum är att de få gånger som fläktarna gör sig påminda är när man gör något riktigt elakt mot datorn i fråga eller, som i mitt fall, när Spotlight ska indexera om hela hårddisken i datorn och man samtidigt sätter igång och synkronisera ned över 45000 bilder i Photos och lite annat roligt.
Givetvis kommer ju en dag då en äldre iMac av det här slaget inte längre är användbar, det vill säga då Apple förklarar x86-arkitekturen död och begraven vad macOS anbelangar, men tills dess kommer jag njuta av denna iMac lite till. Har du en äldre Mac så föreslår jag att du testar detta – det är vänligt mot både miljön och din plånbok, även om en x86-baserad Mac drar lite mer el än en ARM-baserad dito.
Proxmox-kluster på Raspberry Pi del 4: vad som inte fungerar ⚓
I mina tidigare texter om mitt Pimox-kluster (del 1 ,del 2 och del 3) har jag konstaterat att det mesta faktiskt fungerar riktigt bra. Det finns dock saker som inte fungerar och det är väl inte mer än rätt att ta upp dessa i en text till.
Det första är vilka operativsystem som inte fungerar i Pimox. Åtminstone inte just nu.
Eftersom detta är en portering av x86-versionen av Proxmox som sedan körs på ARM64-artkitekturen ställer det till det en del. Exempelvis fungerar ingenting som har med IDE eller SATA att göra i de virtuella maskinerna vilket gör att vissa operativsystem vägrar låta sig installeras. Det finns exempelvis speciella versioner av FreeBSD för Raspberry Pi-plattformen men de går inte att installera FreeBSD från till en virtuell maskin under Pimox. Den “vanliga” ARM64-varianten av FreeBSD låter sig inte heller installeras, och det av en ganska irriterande anledning: CD/DVD-ROM-spelare (fysiska eller virtuella) som ansluts med SCSI kan inte starta upp installationsprogrammet eller installera FreeBSD på ARM64-plattformen. Endast IDE eller SATA stöds. Detta upptäckte jag dessutom efter att ha lagt till en serieport till en virtuell FreeBSD-maskin och sedan anslutit till denna serieport via kommandot qm terminal id-nummer (där id-nummer är numret på den virtuella maskin som du försöker installera FreeBSD på).
Jag testade också att installera FreeBSD på en äldre Raspberry Pi 3, vilket stöds av operativsystemet, och efter en första omstart efter att ha installerat alla uppgraderingar så ville inte operativsystet boota upp igen. Till det var det oerhört långsamt (långsammare än Linux på samma hårdvara) så jag kan (kanske orättvist) bara utgå från att gänget bakom FreeBSD fortfarnade har en del jobb att göra på denna plattform.
OpenBSD finns även det för ARM64. Det finns en större chans för att detta kan fungera men jag är inte överdrivet hoppfull. Tyvärr finns ingen ISO-distribution av ARM64-versionen av OpenBSD utan de distribueras endast i en .img-fil vilken säkert går att konvertera till motsvarande fil i ISO-format men jag har inte funderat närmare på det eftersom jag inte är överdrivet förtjust i OpenBSD. Jag har också funderat på att installera Windows 10 för ARM men inser snabbt att den skulle kräva på tok för mycket minne och andra resurser för att köra i ett Pimox-kluster. Windows Server för ARM har till och från kunnat laddas ned från Microsoft men just nu går det inte att få fatt på och jag vet i ärlighetens namn inte vad jag skulle med det till – det vore trevligt att köra Active Directory för alla datorerna här hemma men det är ju verkligen inte nödvändigt. Kanske skulle jag testa att sätta upp det med Samba 4?
Det andra är som inte fungerar är en, kanske, mer allvarlig historia: livemigreringar.
För att vara tydlig: livemigreringar fungerar om du är beredd att i princip grilla SD-kortet som sitter i respektive Raspberry Pi. När en livemigrering av en virtuell maskin görs mellan två noder så skrivs data temporärt på den lokala lagringen i respektive Proxmox-maskin. Jag ville inte att livemigreringen skulle göra det.
Jag ville inte att Proxmox skulle röra SD-kortet i varje Raspberry Pi över huvudtaget varför jag helt sonika slog av SD-kortets funktion i Proxmox. Detta gör att alla virtuella maskiner fungerar utmärkt, och migrering av virtuella maskiner går utmärkt om de är avstängda, men att göra migreringen medan en virtuell maskin är igång fungerar inte. Det gör mig egentligen ingenting men det kan vara bra att veta.
Det är säkerligen fullt möjligt att koppla på en USB-ansluten hårddisk eller USB-ansluten sticka som man lägger /var/lib/vz på, men jag har inte orkat tänka mer på saken.
En annan sak som inte fungerar är att slå på hotplug (lägga till eller ta bort) av minne och/ eller processorer. Koden i KVM och därmed Proxmox tycks vara anpassad för x86-arkitekturen.
Som bilden högst upp i denna bloggpost visar så sitter det USB-minnen i varje Raspberry Pi numera. Dessa är formatterade med ext4 och hanterar enbart loggfilerna och är monterade under /var/log och det gör ingenting om USB-minnena går sönder. De sitter enkom där för att minimera skrivningarna till SD-korten på varje Raspberry Pi.
Jag kommer uppdatera denna text vartefter mer saker dyker upp som kan vara värda att hålla koll på – du får gärna titta till den då och då om du som jag experimenterar med Pimox i ett kluster.
Integrera Crowdsec:s blocklista i pfSense ⚓
Crowdsec är ett sånt där företag som gör bra saker lite i det dolda. Genom att driva en molntjänst som underhåller blocklistor med IP-adresser från enheter på Internet som ägnar sig åt dumma saker kan man, om man har rätt brandvägg för det, blockera trafik till sin infrastruktur redan innan den kommer fram till sitt mål. På detta sätt kan man undvika attacker och liknande otrevligheter, och det bästa av allt är att det är gratis för hemanvändare att använda tjänsten.
Man kan också köra en agent på en dator hemma som matar Crowdsec med IP-adresser när attacker och annat dyker upp, vilket väldigt många företag och organisationer redan gör. Kort sagt – det är win-win för alla som är inblandade.
Därmed inte sagt att det är helt enkelt att sätta upp om man har en brandvägg som inte stödjer Crowdsec. Jag kör fortfarande pfSense hemma. Jag har övervägt att byta till OPNSense just för att OPNSense har stöd för exempelvis Crowdsec utan en massa fulhack men har inte orkat komma till skott med mitt byte. Så hur löser man det då? Jag googlade runt och hittade en guide som denna guide delvis är baserad på. Jag har skrivit min varient på den och framför allt utökat den med information om hur man får det hela att fungera på ARM64-arkitekturen och försökt göra det hela tydligare.
Det första är att installera Crowdsec:s synkstjänst för deras IP-lista. Har man en
dator med en x86-processor i så är detta inte överdrivet komplicerat men har man som jag ett
Pimox-kluster så blir det genast en aning mer komplicerat, även
om det inte är omöjligt. Programvaran för att installera Crowdsec-programvaran som regelbundet synkar IP-listan finns för
ARM64 och låter sig installeras utan problem. Det man också behöver installera
är deras repo och sedan själva paketet för Crowdsec för att få en
programvara som heter cscli som krävs för att få en API-nyckel som i sin tur krävs för att kunna hämta hem IP-blocklistan. API-nyckeln får
man fram genom att ge cscli -oraw bouncers add cloudflarebouncer, och därefter lägger man in den i filen
/etc/crowdsec/bouncers/crowdsec-blocklist-mirror.yaml.
På raden lapi_key lägger du in API-nyckeln, och raden lapi_url ska sättas till lapi_url: <a href="http://127.0.0.1:8080/">http://127.0.0.1:8080/</a> om den inte redan är det. Raden listen_uri sätter du till listen_uri: 0.0.0.0:41412 och under trusted_ips lägger du in adressen till din brandvägg.
När detta är inlagt och klart kan man starta tjänsten och samtidigt se till att den startar när servern bootar upp:
systemctl enable crowdsec-blocklist-mirror && systemctl start crowdsec-blocklist-mirror
Det var väl enkelt? Ja, så här långt är det inte så vansinnigt komplicerat. Det knepiga var att hitta rätt paket för ARM64 vilket tog en stund.
Det “roliga” är det som kommer nu: integrationen i pfSense.
Först pch främst skapar man ett alias i brandväggen i pfSense:
URL:en till blocklistan visas när man har installerat Crowdsecs synktjänst, men för att göra det enkelt så ser den ut så här:
http://ip-adress-till-servern:41412/security/blocklist
Därefter får du logga in i pfSense via SSH. Har du inte slagit på den funktionen tidigare så är det dags att göra det nu.
När du befinner dig i shell på pfSense skapar du filen forceupdate.sh (eller vad du nu vill döpa den till) och lägger den i /root eller
var du vill placera den. I filen ska följande text finnas:
/usr/bin/touch -t 1001031305 /var/db/aliastables/CrowdSec.txt
/usr/bin/nice>/usr/bin/nice -n20 /etc/rc.update_urltables now forceupdate
Notera att filnamnet på första raden (CrowdSec.txt) skapas utifrån vad du döpte alias:et till tidigare i brandväggsinställningarna så dessa två måste matcha.
Därefter lägger du in ett jobb i Crontab (installera tillägget Cron i pfSense om du inte redan gjort det) som ser ut så här:
Spara jobbet och sedan kan du titta i loggarna för Crowdsec Blocklist Mirror på servern där du installerade det. Du borde se rader som ser ut så här:
==> crowdsec-blocklist-mirror_access.log <== 10.0.2.1 - - [15/Jul/2022:12:45:00 +0000] “GET /security/blocklist HTTP/1.1” 200 147224 "" “pfSense/2.6.0-RELEASE:f065cfff3e2c15c43528”
Om det inte dyker upp kan du gå in i Firewall -> Aliases -> URLs och sedan klicka på den lilla stapelikonen uppe till höger (bredvid
frågetecknet). Välj därefter CrowdSec som Table och klicka till sist på Update:
Kolla samtidigt i loggen på servern där du installerade Crowdsec för att se att en hämtning gjorts. Loggarna ligger under /var/log och är
fyra till antalet:
crowdsec_api.log crowdsec-blocklist-mirror_access.log crowdsec-blocklist-mirror.log crowdsec.log
Till sist skapar du en blockregel i brandväggens regelverk:
Notera att IP-adresslistan inte dyker upp direkt – det kan ta 30-60 minuter innan den är nedladdad första gången så få inte panik om inget händer direkt.
Det du ser till höger är min statistik ungefär 30 minuter efter att jag implementerat blockregeln för IP-adresserna i Crowdsec:s lista. Detta om något är ett gott bevis på att det Crowdsec gör inte bara är bra utan också direkt nödvändigt och desto fler som är med och nyttjar, och bidrar, till tjänsten gör att vi alla får ett säkrare Internet.
För den som undrar: jodå, Crowdsec är installerat på alla mina publika servrar och både blockerar och rapporterar in attackförsök.
Det tog inte ens fem minuter så hade den första fula fisken fångats och blockerats på en av mina servrar. Långnäsa på dig, var du nu befinner dig.
Elon Musk köper inte Twitter trots allt ⚓
Still, one should remain open to the possibility that he was kidding when he first signed the deal. “Elon Musk had a well-thought-out business and financial plan for Twitter that worked in the economic conditions of early April 2022, but conditions have changed and the model no longer works” does not strike me as the most plausible description of what is going on here. “Elon Musk whimsically thought it might be fun to own Twitter, so he signed a merger agreement without taking it too seriously and then lost interest a week later” feels more true to the situation. My first reaction to his proposal to buy Twitter, that it was a joke, may have been the correct one. He was just a lot more committed to the bit than I expected.
På många sätt är detta det bästa sättet denna affär kunde slutat på. Musk får sig en påminnelse om den verklighet han annars inte tycks tillbringa nämnvärt mycket tid i, Twitters ägare får sig en påminnelse om varför de kanske inte skulle ha investerat i bolaget från första början, och resten av världen kan fortsätta använda Twitter som vanligt (och slippa vissa orange-färgade köttsäckars närvaro).
(via John Gruber)
FTP-servern är tillbaka ⚓
Efter att min Proxmox-installation på min gamla server brakade ihop ordentligt i vintras så flyttade jag webbsajter (inklusive denna) till en virtuell server hos OVH:s datacenter i London. Kvar på servern blev det dock en hel del grejer som jag gärna hade haft kvar i någon form, och en av dessa saker var min FTP-server som innehåller allsköns grejer för retrodatorer, gamla BBS-system och annat.
Idag tog jag mig för att slutligen åka den dryga milen mellan mig och serverhallen där maskinen stod avstängd och hämtade hem den, kopplade upp den på mitt lokala nät hemma och lite hackande för att ta mig in i Proxmox-installationen och en del filkopierande senare (en kopiering som fortfarande pågår när detta skrivs) är nu min FTP-server igång igen, i fortsättningen under namnet ftp.melin.org. Namnet till trots så är det fullt möjligt att det inte går att ansluta till servern via just FTP på grund av begränsningar jag inte har något inflytande över – testa gärna och rapportera vad du kommer fram till.
FTP-servern körs på en virtuell maskin i mitt PiMox-kluster och filerna ligger på min NAS.
Mycket nöje.
© 2000 - 2025 Joakim Melin.
