Kör du VPN .run-filen igen varje gång? Det är installationsprogrammet
Nedladdningen lade ett program på disken och nu ligger det där och ser ut som programmet. Anslut från det installerade programmet och spara installationsprogrammet till senare.
Du dubbelklickar på filen du laddade ner förra veckan, anslutningen fungerar och vanan håller i sig: varje gång VPN:t faller kör du samma fil igen. Ingenting går sönder direkt, och det är därför mönstret överlever. Det du faktiskt gör är att installera om programmet ovanpå sig självt och sedan öppna det igen från slutet av installationsprogrammet.
När installationsprogrammet är klart bor programmet någon annanstans på disken och har sin egen ikon, sina egna inställningar och sin egen bakgrundstjänst. Nedladdningen var leveransmekanismen, och att behålla den är helt okej, men det är inte det du ansluter med.
Vad nedladdningen faktiskt lade på disken
En .run-fil är en namngivningskonvention, inte en filtyp. Den kan vara ett shell-skript, ett självutpackande arkiv, en kompilerad binärfil eller något som avgör vid körning vilket av dessa det är. Ändelsen säger dig ingenting om vem som publicerade den eller om du bör lita på den, och därför börjar installationsanvisningar med att hämta den från en verifierad kanal i stället för med ett kommando.
För en leverantör som levererar så här packar installationsprogrammet upp sin nyttolast, skriver programmet och dess stödfiler och registrerar i skrivbordsmiljön vad det behöver. När det är klart är de intressanta artefakterna programmets binärfil, en skrivbordspost och ofta en tjänst som programmet startar. Ingen av dem är filen du laddade ner. Titta i mappen som installationsprogrammet anger i sin sista utskrift, och du ser skillnaden direkt.
Vanan att köra det igen döljer också en diagnos. Om appen öppnas efter en full ominstallation men inte från menyn, lär du dig ingenting om vilken del som saknades, eftersom installationsprogrammet byggde om dem alla.
Installera en gång, med leverantörens eget anrop
Följ det dokumenterade anropet exakt, inklusive tolken det anger. För PIAs Linux-klient anropar guiden installationsprogrammet via sh, så kommandots form är tolken följd av filen du faktiskt laddade ner.
sh ./pia-linux-VERSION.run
VERSION är en platshållare för vilken build du än hämtade, inte en rekommendation att leta efter ett visst nummer. Behandla kommandot som kodkörning med konsekvenser på systemnivå, för det är vad det är: det är inte ett sätt att inspektera filen, och att köra det två gånger lär dig ingenting som den första inte lärde dig.
En detalj från samma guide är lätt att hoppa över och värd att upprepa: sätt inte sudo framför installationsprogrammet. Det ber själv om den administrativa behörighet det behöver, och att bädda in det i ett root-skal ändrar vilken användares miljö installationen landar i. Av samma skäl är «gör varje nedladdning körbar och kör den» inte en allmän regel; att be en tolk läsa ett skript och att köra en fil direkt är två olika operationer med olika felmoder.
När installationsprogrammet är klart dokumenterar leverantören inloggning och anslutning via programmet som just installerades. Varje senare anslutning hör dit. Om du fortfarande skriver installationsprogrammets sökväg för att komma online har du av misstag gjort installationsprogrammet till en del av ditt arbetsflöde.
Startare, butik och systemfält är tre olika platser
Programmenyn, en katalog från en programbutik och systemfältsområdet är separata gränssnitt som underhålls av olika komponenter, och ett installationsprogram kan fylla ett utan att röra de andra. Ett fristående installationsprogram skriver oftast en skrivbordspost, vilket bara är startarintegration och inget mer. Det gör inte appen till en butiksstyrd installation och garanterar inte en systemfältsikon.
En systemfältsindikator behöver stöd från båda håll: programmet som kör måste exportera en, och skrivbordet måste tillhandahålla en värd för den. På skrivbord som har tagit bort det traditionella systemfältet kan en app som förväntar sig ett köra perfekt och inte visa något, och det är en integrationslucka snarare än en misslyckad installation. Att rapportera skrivbordets version och appens version är det som gör luckan hanterbar.
Så när appen öppnas men ikonen saknas ska du inte installera om. Kontrollera om en process kör, om fönstret är dolt bakom en bakgrundsstart och om skrivbordet alls stöder sådana indikatorer. En saknad indikator på ett skrivbord utan systemfältsvärd är förväntat beteende, inte ett fel. Att installera om samma nedladdning en femte gång fräscha bara upp det som redan fungerade.
Skriv ner installationens ägare
Skriv ner vilken kanal som installerade programmet, vilken komponent som uppdaterar det och vad som tar bort det. De tre svaren är oftast inte samma program, och en maskin där ingen känner till dem är en maskin där två kopior av en VPN-klient till slut bråkar om samma rutter.
Att radera den nedladdade installationsfilen avinstallerar ingenting, och att stänga fönstret stoppar inte nödvändigtvis tjänsten eller den blockeringspolicy den installerade. Ta reda på vad som körs vid inloggning och vad som överlever en omstart innan du städar.
När installationsprogrammet har gjort sitt jobb lägger du det i en mapp du kommer ihåg och slutar behandla det som appen. Nästa gång tunneln uppför sig illa börjar du med det installerade programmet, och låter nedladdningen förbli en artefakt från dagen du installerade den. PIAs installationsguide för Linux är referensen för anropet och de första startstegen som beskrivs ovan.