• Skapa NFS-server i MacOS 10.15

    Elpriserna blir inte direkt lägre och efter att jag stängt av samtliga HP Micoservrar jag har hemma (fyra stycken - är du intresserad av att köpa får du gärna höra av dig) så stod jag med ett problem: jag tar nattliga backuper på ett antal datorer via rsync och NFS och den enda dator jag har kvar som är på dygnet runt utöver min Mac mini M1 är min gamla Mac mini från 2012 som står som server för diverse saker här hemma.

    Kan man använda den som NFS-server? Jo, det kan man faktiskt. Det är inte 100 procent stabilt och det är inte helt enkelt att sätta upp heller. Jag förklarar hur du gör.

    Först skapar du (som root) /etc/exports och delar ut den eller de kataloger du vill dela ut via NFS. Exempel: /Volumes/Share/backup -mapall=användare -network subnät -mask nätmask

    Användaren är den användare som har rätt att skriva på hårddisken och katalogen du delar ut. Subnät är antingen ett helt nätverk eller en enda maskin. Har du en bunt datorer som sitter på 192.168.1.0/24-nätet skriver du 192.168.1.0 som subnät och 255.255.255.0 som nätmask. Sökvägen är samma sökväg som MacOS monterar upp diskarna på - titta under /Volumes om du är osäker.

    Därefter startar du om nfs-demonen med kommandot nfsd restart (som root).

    Du kommer nu kunna montera diskvolymen men du kommer inte kunna skriva till den. Det tog en stund innan jag listade ut det men lösningen är egentligen ganska logisk som ologisk:

    Gå in i System Preferences och välj “Security & Privacy”, välj sedan fliken “Privacy” och scrolla ned till “Full Disk Access” i listan till vänster. Därefter trycker du cmd-shift-g och väljer nfsd i katalogen /sbin. Stäng sedan System Preferences så ska det fungera.

    Bli inte förvånad om NFS-monteringen får problem på sikt. Apple kan inte bry sig mindre om NFS numera, och detta från ett företag som vid en tidpunkt skröt om att de sålt flest Unix-baserade datorer i hela världen…

  • Installera Homebrew, Ruby och Jekyll på MacOS 12.1

    Att installera Homebrew, Ruby och Jekyll på MacOS Big Sur (aka MacOS 11) var inte helt enkelt. Dokumentationen från Homebrew-projektet är inte supertydlig och när jag uppgraderade till MacOS 12 (aka MacOS Monterey) så bestämde jag mig för att styra upp läget lite.

    Först avinstallerade jag Homebrew:

    /bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/uninstall.sh)"

    Avinstallationen kommer klaga över att den inte kunnat ta bort vissa filer, exempelvis /opt/homebrew. Radera allt medelst sudo rm -r -f -v /opt/homebrew. Den som fortfarande kör MacOS på Intel-processorerna kommer notera att den sökvägen inte stämmer överrens med deras installation och detta beror på att /usr/local inte är skrivbar för användare i M1-versionen av MacOS.

    Därefter är det dags att installera om hela klabbet på riktigt. Har du inte installerat XCode ännu så är det dags att göra det först genom att mata in xcode-select --install i terminalen. Sedan kan du ta en fika. En stor fika, för detta kommer ta en stund.

    Därefter är det dags att installera Homebrew igen. Mata in /bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)". Detta ska installera Homebrew i /opt/homebrew. Om så inte är fallet, skapa katalogen /opt/homebrew, ställ dig i den och kör scriptet igen.

    Därefter är det dags att installera Ruby. Ge först brew install rbenv ruby-build och vänta. Därefter ger du följande kommandon:

    rbenv install 3.0.0
    rbenv global 3.0.0

    Kolla så du fått in Ruby version 3.0.0 genom att ge ruby -v. Därefter skriver du rbenv rehash.

    Du behöver lägga till sökvägarna för Ruby och gems i din profil. Öppna ~/.zshrc och mata in följande:

    eval "$(rbenv init - zsh)"
    export PATH="/usr/local/opt/ruby/bin:/usr/local/lib/ruby/gems/3.0.0/bin:$PATH"
    export LANGUAGE=en_US.UTF-8
    export LANG=en_US.UTF-8
    export LC_ALL=en_US.UTF-8

    De tre sista raderna är till för att Jekyll version 4 eller senare ska kunna bygga webbsajter utan att få problem med teckenkonverteringen.

    Öppna sedan ~/.zprofile och mata in följande rad:

    eval "$(/opt/homebrew/bin/brew shellenv)"

    Modifiera också din path så den pekar ut .gem-katalogen i din hemkatalog. I mitt fall ser det ut som nedan:

    export PATH=/usr/local/Cellar/ruby/2.4.1_1/bin:/Users/joacim/.gem/ruby/3.0.0/bin:$PATH

    Nu är det dags att installera Jekyll. Ge gem install --user-install bundler jekyll i terminalen och vänta. Om den klagar på path till dina gems så får du avsluta terminalen och sedan starta den igen för att alla path:ar ska sätta sig ordentligt.

    På M1-Mac:arna kan du behöva göra lite mer. I terminalen ger du följande tre kommandon:

    bundle update --bundler<br>
    bundle add webrick<br>
    bundle install --redownload<br>

    Nu borde Jekyll fungera. Har du en befintlig sajt sedan tidigare kan du behöva installera om alla gems som hör till den sajten.

  • Apple M1-processorn är snabb

    Vännerna på Halon Security är inte bara ödmjuka, trevliga och oerhört smarta. De kan sitt skit också.

    I en ny bloggpost har de gjort en prestandajämförelse med Halons programvara och DKIM-signeringar körandes på Xeon-arkitekturen hos AWS, ARM-arkitekturen hos AWS och en vanlig Mac mini M1-maskin med Halons programvara i en container. Resultatet var ganska slående:

    Plattform Arkitektur Signeringar p/s Verifieringar p/s
    AWS c5.2xlarge x86 1 685 56 671
    AWS c6g.2xlarge ARM 293 10 720
    Mac mini M1 ARM 1 767 73 035


    RSA-prestandan för ARM hos Aws förklaras av Amazon med att det är en “suboptimal användning av Graviton2-plattformen”.

    Oavsett vad så kan man dra en slutsats av detta: Apples M1-plattform är snabb. Ruskigt snabb. Givetvis är det inte så att man ska springa och köpa en pall Mac mini-maskiner med M1-processorn och sätta i ett datacenter men ett sånt här experiment visar att Apple gör någonting rätt. Med lanseringen av M1 Max och M1 Pro visar företaget att de att de också kan sitt skit, oavsett vad Intel säger.

  • Problemet med iCloud+ och egen e-postdomän

    När Apple äntligen lanserade möjligheten att använda sin egna e-postdomän i iCloud blev jag kanske inte extatisk men åtminstone glad - ännu en tjänst jag kan lägga hos Apple och som jag sedan inte behöver hantera själv. Gott så.

    Men sen började problemen. De två primära mailadresser jag använder har jag haft i 10+ år, och det visade sig efter lite meckande att jag registerat iCloud-konton på båda, för många många år sedan, sannolikt för att labba med något.

    Så jag raderade båda kontona. Apple tog givetvis tid på sig att ta bort dem, men häromdagen fick jag mail (ett per konto) om att båda kontona var raderade:

    Your Apple ID, xxx@yyy.zzz, has been deleted. All associated information has been permanently erased from our systems or has been modified so that it no longer identifies you.

    Notera hur de uttrycker sig i mailet ovan. All information kopplad till kontot har raderats från deras system. Fast det är inte helt sant. Jag kommer till det strax.

    Jag försökte nu regga upp adresserna för domänerna i iClouds kontrollpanel men det fungerade inte. Samma felmeddelande. Jag väntade några dagar till, samma fel.

    Till slut bokade jag en samtalstid med Apples support på Irland som ringde mig idag. Jag förklarade problemet och supportpersonen började söka igenom. Efter mycket hummande och funderande säger han att även om kontot och dess innehåll är borta sparar Apple e-postadressen kontot var registrerat med för all framtid. Jag frågar om han kan radera det men nej, det kan han inte - “det går inte”.

    Med andra ord: radera ditt konto, men adressen finns kvar hos Apple för alltid, oavsett om du vill det eller inte.

    I mitt fall innebär det att jag inte kommer kunna använda de e-postadresser jag haft och ägt i många år, i fallet med den domän du besöker nu har jag ägt domänen i över 21 år.

    Om du använt en e-postadress för återställning av konto eller som inloggning till samma konto du använder för iCloud+ så får du byta adresserna för återställning och inloggning så kommer det fungera.

  • Datormagazin Retro nummer 5!

    Det är den där tiden på året då det börjar klia lite i fingrarna: det är dags för ett nytt nummer av Datormagazin Retro. I år satsar vi särskilt på Amiga, Commodore 128 och givetvis Commodore 64. Vi besöker Svenska Commodore-klubben, tittar mer på svenska BBS:er och får utstå spott och spe från Brad S. Bland annat.

    Boka ditt nummer nu! Det finns som vanligt riktigt trevliga paket att välja mellan och årets 1337-paket är särskilt läckert.