Rädda filer från kraschad VMFS-volym ☍
Plötsligt händer det som inte får hända: min primära lagringsenhet la sig på rygg och “dog”. Bidragande kan ha varit att jag tömde en av LUN:en på disk, raderade den gamla volymen tog ut de gamla diskarna
och stoppade i dubbelt så stora diskar (2TB styck), vilket SAN:et enligt dokumentationen ska klara. Jag byggde en ny volym och började packa tillbaka data som skulle ligga på den. Det borde den väl klara?
Det gjorde det inte.
Den nya volymen la sig på rygg mitt under kopieringen av data från en tillfällig lagringsenhet till SAN:et. Givetvis ballade VMware också ur och efter omstart så såg det ut så här:
De två andra volymerna, båda med mindre diskar, gick utmärkt att montera i VMware och tömma på data men den stora volymen gick inte att komma åt. Jag testade en bunt olika kommandon
och kom snart fram till att eftersom volymen inte hade fått ett UUID så kunde jag inte forcera en montering via kommandoradsläget i ESXi.
[root@vh02:/vmfs/volumes] esxcfg-scsidevs -l
eui.22030001556fa704
Device Type: Direct-Access
Size: 11444091 MB
Display Name: Promise Fibre Channel Disk (eui.22030001556fa704)
Multipath Plugin: NMP
Console Device: /vmfs/devices/disks/eui.22030001556fa704
Devfs Path: /vmfs/devices/disks/eui.22030001556fa704
Vendor: Promise Model: VTrak E610f Revis: 0336
SCSI Level: 5 Is Pseudo: false Status: degraded
Is RDM Capable: true Is Removable: false
Is Local: false Is SSD: false
Other Names:vml.01000000003439353334353230303030303030303030303030303030303841413643384544363733424546565472616b20
VAAI Status: unknown
Kort sagt, ESXi vägrade röra diskvolymen. Nu var goda råd dyra eftersom jag till varje pris var tvungen att få bort all data från volymen innan den la sig på rygg igen.
Jag installerade upp CentOS 7 på en server, anslöt den via fibre channel till SAN:et och jodå, volymen listades som en disk:
Disk /dev/sdb: 12000.0 GB, 11999999950848 bytes, 23437499904 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk label type: gpt
Disk identifier: EC06325E-4EF9-48D2-A139-A3A1898A77CC
Start End Size Type Name
1 2048 23437498367 10.9T unknown
WARNING: fdisk GPT support is currently new, and therefore in an experimental phase. Use at your own discretion.
Eftersom volymen är formatterad med VMFS så kan inte Linux montera disken hur som helst, men via ett projekt som heter VMFS-Fuse så gick det faktiskt. Det finns två varianter av detta projekt – orginalet som är en äldre version och som inte klarar VMFS6 och en nyare som gör det.
Installera de dependencies som behövs för att VMFS-Fuse ska starta och sen är det bara att montera upp disken och hämta ut dina data på följande sätt där /dev/sdxx är FC-disken och /fc01 är mountpoint:
vmfs-fuse /dev/sdc1 /fc01/
Inte det roligaste projektet att behöva göra när man är helt sänkt av en influensa men det var ändå förhållandevis enkelt att lösa.
Edgerouter med Cloudflares DynDNS-tjänst ☍
Då jag precis blivit lycklig ägare till två Edgerouter ER-8 från Ubiquity så har jag fått klura ut några saker. Det första är hur man får Cloudflares dynamiska DNS-tjänst att fungera med Edgerouter. Jag har nämligen alla mina domäner hos Cloudflare och deras lysande DNS-tjänst (och nyttjar dem som registrar för de domäner de kan hantera i dagsläget).
Då jag har en extra internetanslutning hem via ADSL (redundans är bra grejer när man bor på landet med halvskakig fiberanslutning) utan statisk IPv4-adress så vill jag kunna uppdatera dess hostnamn i min zonfil hos Cloudflare varje gång jag tvingas byta IP-adress. Det kan vara extra nyttigt om jag är ute och reser eller annat och fibern hem är nere och jag ändå måste komma åt saker, eller om jag sitter och jobbar hemma och IP-Only bestämmer sig för att göra en IP-Only. Värt att understryka är att hela denna guide förutsätter att du redan har minst en domän i Cloudflares DNS-tjänst. Du måste ange värdnamn plus domännamn (exempelvis hemma.domän.tld) i exemplet nedan. Värdnamnet kan vara i princip vad som helst men domännamnet måste alltså redan finnas i Cloudflares DNS-tjänst och du måste ha bytt så din domän har Cloudflare:s DNS:er kopplad till sig.
En annan sak värd att notera är att den API-nyckel du behöver är den globala API-nyckeln i ditt konto hos Cloudflare. Du hittar den genom att logga in, klicka på pilen till höger om den lilla “gubben” i menyn och därefter väljer du “My profile”. Därefter väljer du “API Tokens” och väljer till sist att klicka på “View” på raden för “Global API Key”. Denna nyckel ska du INTE sprida eller på något sätt dela med dig av.
En sista sak värd att notera är att jag utgår från att din internetanslutning sitter på porten eth0 i din brandvägg. Sitter den i en annan port, byt ut eth0 mot det rätta värdet i exemplen nedan.
Du behöver utöver detta också sätta upp en API Token för din domän. Bilden ovan visar hur det går till – det som kvarstår är att välja vilken domän du vill använda för DynDNS-tjänsten.
Sin vana trogen har Ubiquity sett till att detta inte finns med i webbgränssnittet i Edgerouterns operativsystem EdgeOS, men om man SSH:ar in i brandväggen så kan man fixa detta och jag tänkte visa hur man gör. Ubiquity har publicerat en egen guide inom detta ämne men den har ett stort fel som jag vill rätta till med denna bloggpost.
Först och främst SSH:ar du till din brandvägg. Logga in med samma användarnamn och lösenord som du använder när du loggar in via webbgränssnittet.
Därefter skriver du configure och trycker enter.
När du gjort det kan du sätta igång och mata in kommandon:
<br /> set service dns dynamic interface eth0 service custom-cloudflare hostnamn.domän.tld<br /> set service dns dynamic interface eth0 service custom-cloudflare login e-postadressen du loggar in med hos Cloudflare<br /> set service dns dynamic interface eth0 service custom-cloudflare password din API-nyckel hos cloudflare<br /> set service dns dynamic interface eth0 service custom-cloudflare protocol cloudflare<br /> set service dns dynamic interface eth0 service custom-cloudflare options zone=domän.tld<br /> set service dns dynamic interface eth0 service custom-cloudflare server api.cloudflare.com/client/v4/<br />
Ett praktiskt exempel kan se ut som följer:
<br /> set service dns dynamic interface eth0 service custom-cloudflare hemma.jocke.se<br /> set service dns dynamic interface eth0 service custom-cloudflare [email protected]<br /> set service dns dynamic interface eth0 service custom-cloudflare password 1234455678dfgsfsdfasdf<br /> set service dns dynamic interface eth0 service custom-cloudflare protocol cloudflare<br /> set service dns dynamic interface eth0 service custom-cloudflare options zone=jocke.se<br /> set service dns dynamic interface eth0 service custom-cloudflare server api.cloudflare.com/client/v4/<br />
Misstaget Ubiquity gjort i sin guide är att de sagt att den sista raden i exemplet ovan är valfri. Utan att ange den raden fungerar inte den dynamiska DNS-tjänsten hos Cloudflare med Edgerouter.
Du kan verifiera att din uppdatering fungerat genom att skriva show dns dynamic status. I mitt fall ser det ut enligt nedan:
joacim@gw02:~$ show dns dynamic status
interface : eth4
ip address : 217.210.187.50
host-name : adsl.melin.org
last update : Wed Feb 19 17:44:10 2020
update-status: good
När allt ser ut att fungera sparar du inställningarna genom att skriva commit ; save.
Logga till sist ut genom att skriva exit två gånger.
Den perfekta Markdown-editorn för Fedora Linux ☍
I min förra bloggpost nämde jag att jag hade problem med den editor för Markdown, Quilter, som jag hittat. Den hade visserligen en bra funktion, en “fusklapp” för vanliga Markdown-formatteringar som jag tyckte var nyttig men den byggde på att man startade ett nytt dokument varje gång man sparade.
Generellt sett kan man lita på de recensioner en applikation fått i applikationsbutiken för Fedora. Marker, Ghostwriter och Uberwriter är alla bra alternativ, medan Atom (som kombinerar ett oerhört polerat användargränssnitt med en minneshunger som heter duga, tack vare det faktum att det är en Elektron-applikation…) och Quilter snabbt föll bort. Den sistnämnda av anledningarna jag angav ovan och Atom för det enkla faktum att den inte har automatiska radbrytningar när du skriver. Till Atoms försvar ska sägas att det främst är en editor för kodutveckling och inte för bloggande men det är i övrigt en kompetent Markdown-editor.
Den editor jag till slut föll för heter Mark Text. Namnet är kanske inte det vackraste men det är en kraftfull men ändå enkel editor för dig som vill skriva texter i Markdown på Linux. Den integrerar snyggt med Gnome och har en hel del trevliga funktioner. En hel del Markdown-funktioner kan kommas åt via menyerna och man kan också, hör och häpna, snabbspara sina Markdown-texter genom att trycka ctrl-s. Se och lär, Quilter.
Som så många andra applikationer så kostar denna gratis. Jag rekommenderar den varmt.
Här behöver Fedora Linux bli bättre ☍
Detta är den andra versionen av denna text som jag skriver. Den första versionen försvann när jag blev utloggad i Fedora, sannolikt på grund av en krasch av något slag, vem vet. Tydligt var att något var på gång – datorn gick segt och betedde sig underligt men jag tänkte att jag bara skulle skriva klart denna text och sedan spara den…
Den 17 september 2018 publicerade jag en bloggtext kallad Vad Linux behöver för att lyckas på skrivbordet där jag försökte gå till botten med vad som gjort att Linux blivit så fragmenterat och i många avseenden misslyckat som operativsystem för skrivbordsdatorer:
För att Linux verkligen ska bli framgångsrikt på skrivbordet måste man ta bort de valmöjligheter som många har idag. Inget mer KDE, inget i3, inget Xfce, och så vidare, utan bara en enda standard: Gnome. Ska Linux lyckas på skrivbordet kan det inte finnas 40-50 olika fönsterhanterare – det är en valmöjlighet som endast skadeskjuter Linux skrivbordsambitioner ytterligare.
Linuxvärlden måste helt enkelt bli mer som Apple – mindre valfrihet och mer diktatoriskt. Om Linuxvärlden sedan anser att det är ett rimligt offer att göra för att få en bättre och mer hållbar grafisk skrivbordsmiljö med Linux under skalet återstår väl att se men jag tror inte Linuxfolket kommer vilja gå den vägen, och en del av mig är tacksam för det.
Saknas: en röd tråd
Det som saknas i Fedora 31 är en röd tråd, något som håller saker och ting samman. Jag har tidigare berört hur det börjar växa fram, sakta men säkert, men för att Fedora ska erbjuda en mer sammanhängande användarupplevelse krävs det att det hela styrs med en fast hand. Låt oss ta några exempel.
Vi kan börja med exemplet ovan. Detta är tilläggsprogram till fönsterhanteraren Gnome som gör att man får nya fina funktioner installerade. Trevliga grejer detta, förutom det faktum att de flesta inte fungerar. De enda som fungerar av de jag installerat (markerade med en bock i bilden ovan) är tillägget för att ta skärmbilder (användes flitigt i samband med att jag skrev denna bloggpost).
Nästa exempel är de “molnkonton” man kan lägga till i Gnome. Fina grejer på alla sätt och vis men det finns ingenting som tvingar applikationer som körs i Gnome att bry sig om dessa konton. Inte ens Gnomes egna bildvisare Photos gör det.
Photos är en ganska enkel applikation – den tar alla bilder i katalogen ~/Pictures och visar upp dem. Enkelt och bra. Det Photos enligt egen utsago ska kunna göra är att dels kunna ta bilder i katalogen ovan, men dels också kunna använda sig av bilder i de molntjänster man har installerade. Jag tänkte då, glad i hågen, att Photos skulle kunna hantera bilder som fanns i min privata molntjänst som bygger på Nextcloud, men icke. Sannolikt är tanken med kopplingen mellan Photos och molntjänster att använda sig av tjänster som exempelvis Flickr eller kanske Facebook, men ingenstans är detta dokumenterat eller beskrivet utan man får helt enkelt lista ut det på egen hand. Sånt här måste bli bättre. En annan sak med implementationen av stödet för dessa molntjänster är huruvida man kan lita på dem. Jag avslutade Nextcloud-klienten och tänkte att det inbyggda stödet för Nextcloud i Gnome skulle hantera detta åt mig men icke sa nicke. Jag kommer åt alla filer finfint och kan arbeta med dem men ändringar synokroniseras inte upp automatiskt. Faktum är att det inte ens finns ett sätt att kolla status på tjänsten genom Fedoras inbyggda stöd.
Att installera nya applikationer är däremot smidigt. För det mesta. Jag ville installera Audacity via den inbyggda applikationsbutiken Software och fick bara till svar att det inte fungerade. En del applikationer som tidigare fanns i applikationsbutiken i Fedora 30 är borta i Fedora 31, och nu får man installera den via Flathub istället som man lägger till som en mjukvarukatalog i Fedora 31. Det är inte svårt att göra, men informationen om att Flathub finns och vad som där erbjuds nämns inte någonstans i Fedora 31 utan det upptäcker man först när man börjar söka på hur man enklast installerar Spotify eller Skype (den sistnämnda är för övrigt väldigt trasig i Linux överlag just nu, inte enbart i Fedora).
Ett annat exempel är kopplingen till ditt Microsoft-konto. Att det ens finns en koppling är givetvis imponerande bara det, men Microsoft erbjuder ju betydligt fler tjänster än detta genom sitt konto? Onedrive är ett exempel, ett annat är att du också loggar in till Skype via detta konto men det är något som varken Skype eller Red Hat tar någon hänsyn till, åtminstone inte just nu.
De fyra olika gränssnitten
Ett större problem är också hur lite hänsyn externa utvecklare tar till hur Gnome ser ut och fungerar. Jag tänkte ta och visa några exempel på detta.
Här är mitt första exempel – bildvisaren Photos som jag nämnde tidigare. Här består menyn av en enda knapp, en så kallad Hamburgermeny. Det är i sig ett helt acceptabelt sätt att hantera menyfunktionen om detta hade varit det som gällde och som alla använde sig av. Så är tyvärr inte fallet.
Här har vi webbläsaren Firefox, som är standardwebbläsaren i Fedora 31. Inget fel med det – Firefox är sannolikt den bästa webbläsaren på marknaden numera. Även här har vi en Hamburgermeny men den är placerad på ett annorlunda ställe jämfört med Gnomes egna applikation, och till saken hör givetvis också att Firefox ser likadant ut på alla plattformar så Hamburgermenyn är ett lyckligt sammanträffande, inget annat.
Här har vi applikationen jag skriver dessa bloggtexter i: Quilter. Det är på många sätt en ganska usel applikation utan automatisk sparfunktion (eller någon vettig sparfunktion över huvudtaget – ska man spara en text under pågående arbete måste den sparas som en ny text varje gång och samtidigt skriva över den gamla texten) men den får duga så länge. Här har vi en Hamburgermeny till höger, finfint, men här är också applikationens egna namn med i menyraden. Nästa exempel kommer visa varför detta blir både problematiskt och fult.
Exempel nummero fem är den utmärkta, utsökta applikationen Shotwell som jag blivit riktigt förtjust i. Kanske på grund av att den liknar iPhoto till en viss del och det var iPhoto som tillsammans med Unix cementerade min kärlek till Mac OS X. Hur som haver, i bilden ovan ser ni att Shotwell dels har ett traditionellt menysystem i form av File, Edit, View och så vidare. Applikationens namn syns också i översta raden i applikationsfönstret men eftersom Gnome är Gnome finns det en meny till och det är i statusraden i själva Gnome där Shotwell (och alla andra applikationer du kör) kommer visas, dock endast en i taget, kanske för att indikera för användaren vilken applikation du kör… som om det inte vore tydligt nog genom att titta på själva applikationen?
Ska Gnome fungera riktigt bra med sin fönster- och applikationshantering bör alla som utvecklar applikationer för Gnome titta på den enklaste av applikationer: filhanteraren. I bilden ovan ser du hur den fungerar perfekt i Gnome – namnet på applikationen (Files) står i Gnomes egna menyrad, menyn för själva applikationen kunde faktiskt också ha funnits där men nu finns den i en Hamburgermeny i själva applikationsfönstret istället och det fungerar det också.
Detta är således några områden som Fedora kan bli bättre på: en mer stringent hantering av hur applikationer ser ut och fungerar, ett bättre “välkomnande” av nya användare som efter en riktigt bra installationsprocess nästintill kastas i ett badkar med iskallt vatten. Visst – ska man köra Linux på skrivbordet så får man kanske räkna med att en viss smärttröskel måste passeras men för mig som använt Fedora flitigt genom åren tycker fortfarande att en del saker kunde bli betydligt enklare att hantera.
Jag vill att Fedora ska lyckas, för jag trivs så oerhört bra i den här plattformen i övrigt.
Så installerar du Jekyll i Fedora 31 ☍
Världen som Linuxanvändare blir inte enklare ju längre tiden går, snarare tvärt-om. Istället för att ha en gemensam plats för Linuxanvändare som kör Gnome att installera sina applikationer finns det givetvis två. Minst.
Tidigare kunde man som Fedora-användare installera programpaket med hjälp av Snap där applikationer som inte hanterades av Fedoras inbyggda mjukvarubutik. Med Fedora 31 försvann detta och istället använder vi oss numera av Flathub. Det finns, givetvis, inga instruktioner om detta faktum i Fedora när man installerat det utan det upptäcker man först när man vill installera exempelvis Skype eller Atom.
Ett annat problem är att installera bloggmotorn Jekyll. I tidigare version av Fedora var detta relativt enkelt men något har hänt (fråga mig inte vad). Hur som haver är det inte bara att installera Ruby och sen smacka in Jekyll ovanpå det, det krävs en del paket för att det ska fungera.
Börja med att installera dessa paket:
sudo dnf install ruby-devel make gcc g++ -y<br /> sudo dnf install redhat-rpm-config -y<br />
Därefter kan du installera Jekyll:
gem install bundler jekyll<br />
Nu kan du sätta igång och blogga med Jekyll i Fedora 31. Precis som jag gjort med den här lilla texten.
