Resolution:

Uppgradering Ubuntu 14.04 till 16.04 LTS

Har du en server med operativsystemet Ubuntu Linux 14.04 LTS och funderar på att uppgradera till den senaste LTS-versionen; Ubuntu 16.04 LTS?

Ubuntus LTS-versioner är ett populärt val för många då det finns mjukvarusupport under mycket lång tid. Inte minst med tanke på säkerhetsuppdateringar, vilket gör LTS-versionerna som ett förstahandsval för många.

Men precis som med tidigare versioner - ni som varit med ett tag minns kanske vad vi rekommenderade för uppdatering från 10.04 -> 12.04 eller från 12.04 till 14.04? Det finns ett antal fallgropar och i vissa fall är det helt enkelt bättre att göra en nyinstallation snarare än att uppgradera en befintlig server.

Många vill spara tid och visst är det enkelt att använda de integrerade verktygen för att uppgradera från en version till en annan men det är faktiskt riktigt stora förändringar som görs och det är trots allt ett totalt annat operativsystem där i bästa fall konfigurationsfiler som redan existerar kan modifieras för att passa de nya versioner av mjukvaror som körs i Ubuntu 16.04. I vissa fall kanske inte ens den mjukvara ni använde under 14.04 finns kvar? I vissa fall kan en mjukvara vara konstruerad för andra versioner av mjukvarubibliotek som tex PHP. Därför är det mycket klokt att göra en testmigrering först (minst en) innan ni ger er på de system ni har som står i produktion.

 

SystemD

Detta har vi - och många andra - skrivit om tidigare. En enorm skillnad i Ubuntu 16.04 mot tidigare versioner och i princip alla andra versioner av Linux är att man nu valt att gå över till en programvarusvit som heter SystemD och som ersäter init-scripten som i princip hängt med sedan 1972.

Många anser att SystemD är ett härke och faktum är att system D gör en helt del andra saker än föregångaren så det är inte bara ett nytt sätt att starta daemoner på osv utan det är ett totalt annat tänk.

De som kritiserar SystemD menar på att det är slött, onödigt komplicerat och oändligt mycket svårare att felsöka medan andra hävdar att det var på tiden att göra något nytt. Hur som helst så är det annorlunda och saker och ting sker inte som du är van vid.

Verktyg som tex sysv-rc-conf går fortfarande att installera men det som sker bakom kulisserna är annorlunda. En god idé att vid första bästa kaffepaus sätta sig ned och läsa lite man-sidor med andra ord!

 

PHP

Just PHP är något som också förändrats rejält. Även PHP har varit omtvistat sedan tidigt 1990-tal och såväl kritik mot säkerhet som prestanda har framförts. En kanske ännu större förändring för dig som har en LAMP-server (standard webserver-installation; Linux Apache MySQL & PHP) är att man nu valt att gå över till PHP version 7.0.

PHP 7 fungerar totalt annorlunda mot version 5 och det är så gott som garanterat att du kommer stöta på patrull om du använder PHP i något sammanhang. Alla bibliotek, libbar, beroenden med andra program, konfiguration och moduler för exempelvis apache är totalt annorlunda.

Många webbaserade verktyg som är beroende av PHP och en databas har dessutom i och med den revolution som version 7 innebär för PHP (kanske största förändringen sedan PHP/FI blev PHP version 1?! för er som minns när PHP betydde Personal Home Pages och var allt annat än stabilt) valt att göra saker på annorlunda sätt mot tidigare. Exempelvis mjukvaror för bloggar, databaskopplingar, lagringsfunktioner eller websideuppdatering är sådant som troligtvis HAR förändrats. Lita inte på att allt "ser ut" att fungera efter en testuppgradering - undersökt och säkerställ att det verkligen gör det. Vi har i princip inte hört talas om en enda migrering från Ubuntu 14.04 till 16.04 där PHP använts som inte stött på mer eller mindre svårlösta problem!

Ett rejält varningens ord här med andra ord för dig som använder PHP.

 

Många verktyg som tidigare använt MySQL verkar dessutom gått över till MariaDB och andra databaslösningar. Vad denna trend beror på vet vi inte i nuläget men båda plattformarna är bra, stabila och gör jobbet men för dig som ska administrera tekniken kan detta innebära att du måste lära nytt även på databassidan.

 

Du som skippar PHP och använder andra mjukvaror är inte heller säker!

Python, CGI, Perl, Java och Ruby?

Även här händer det grejer. Det enda som egentligen är relativt enkelt att hantera i och med uppgraderingen är PERL och CGI, allt annat inklusive Apache Tomcat och java-biblioteken har fått nya versioner, allt ser inte ut och fungerar inte på samma sätt som tidigare. Därmed inte sagt att det blivit sämre - bara annorlunda. Kör du en Java-baserad webblösning är det stor risk att ett antal underliggande bibliotek och funktioner uppdaterats vilket i sin tur kan slå på din kod i värsta fall.

 

SSL

De senaste åren har det varit i princip mer eller mindre kaotiskt för OpenSSL och det har förändrats mycket hela tiden. Av denna anledning fortsätter vi att rekommendera att man placerar SSL för webbplatser och andra webbtjänster utanför sin backend-server. Exempelvis med vår CDN-tjänst och SSL.

 

 

Virtualisering

Här händer det mycket. Du som har en egen virtualiseringsplattform hos oss (där ni själva skapar egna VPS:er) behöver inte själva göra någon uppdatering. Däremot när det blir dags för nyinstallation av era virtualiseringsnoder kommer vi kontakta er på sedvanligt manér.

Ni som själva installerat mjukvaror för virtualisering står inför ett kaos av valmöjligheter. Många tidigare alternativ finns inte alls kvar så en uppgradering är i många fall inte alls möjlig. Det finns ett myller av olika alternativ och de mest långsiktiga är nog tyvärr de minst användarvänliga. Vill ni utnyttja vårt supportavtal för att få rådgivning kring hur ni ska använda virtualisering på ett långsiktigt sätt är det en god idé att utreda detta i god tid innan servrarna uppgraderas.

I och med att i princip alla (alla bra) virtualiseringsplattformar använder djupt liggande funktioner för virtualisering och inte emulerar på ytan (med många underliggande lager av mjukvaror som innebär tröghet, sämre prestanda och färre VPS:er per server) så skulle en remote-uppdatering av era servrar kunna innebära att servern ej kommer upp efter omstart eller att den avbryter mitt under uppgradering om Ubuntus uppgraderingsmjukvara inte klarar av att bena ut alla konflikter mellan olika konfigurationer, mjukvaror av olika versioner och som sagt i och med att de gått över till andra mjukvaror i vissa fall och att de helt enkelt valt att inte vara bakåtkompatibla i alla situationer.

 

 

Utvecklingsserver

Beroende på vad ni har på er server (ju fler mjukvaror desto större risk för komplikationer) så kan det vara mer eller mindre säkert att uppgradera. Gör ett test på en maskin först innan ni migrerar några produktionssystem eller viktiga utvecklingsverktyg.

 

Affärskritiska system

..Bör inte alls uppgraderas förrän ni kunnat torrsimma och utföra lyckade testmigreringar på ett likadant system. Det är stor risk att ni kommer få driftavbrott om ni bara kastar er över uppdateringen och går direkt till 16.04 på era produktionssystem.

Dessutom fungerar Ubuntu 16.04 totalt annorlunda så det är en inlärningströskel. Den kloke systemadministratören sätter sig in i nyheterna och skillnaderna först. Då är det fortfarande relativt enkelt att uppgradera och i många fall till och med möjligt att göra på remote. Torrsim först.

 

Git, CVS, VPN och liknande

Kör ni en, och helst en ganska "enkel" funktion på er server så är det snabbt gjort att utreda om exepelvis Git finns kvar i nya Ubuntu och göra en uppdatering relativt smärtfritt.

Tänk på att vissa mjukvaror kommer i nya versioner och att konfigurationsfiler kan behöva uppdateras. I övrigt är det i regel inga konstigheter.

Gör ett test på en annan, identisk server, först om du vill vara säker på att inget går sönder. För den relativt erfarne systemadministratören är det dock i regel inget konstigt utan vanlig problemlösning, lite googling, manualsidor och lusläsning av loggfiler brukar lösa det allra flesta problem.

 

Skulle du behöva gå tillbaks till 14.04?

Kort svar: Det går inte. Ubuntu har inte gjort det enkelt att nedgradera utan det är i princip en omistallation med 14.04 och uppdatering fram till och med de senaste 14.04-uppdateringarna som gäller. Har du sparat undan data och konfiguration så är det lite pyssel men inget som är omöjligt.

Att uppgradera från 14.04 till 16.04 innebär stora förändringar. Det tar ett tag och du får nedtid. Men det är inte lika enkelt att nedgradera som att uppgradera och att försöka reparera ett halv-uppdaterat system är inget vi rekommenderar - det tar tid. Installera 14.04 och läs in från backup och fundera kring vad som gick snett och försök uppdatera till 16.04 så snart du kan.

 

Måste man uppdatera till 16.04?

Nja. Så småningom kommer Cannonical/Ubuntu sluta erbjuda uppdateringar för 14.04 och då bör man definitivt inte ligga kvar. Att panikuppdatera då kommer garanterat innebära onödiga problem. Planera och uppgradera i god tid. Gärna nu om det går men behöver ni bekanta er med systemet inför uppdatering är vår VPS-tjänst en perfekt möjlighet att prova olika inställningar och komma igång.

 

 

Säkerhetskopiera först

 

Oavsett hur du gör så börja med att göra en säkerhetskopia. Med vår enkla molnlagringstjänst är det enkelt att hantera olika typer av filer, backuper, mappar, olika versioner osv. Läs mer om lagringstjänster här.

 

Lycka till. Vi tror att ni kommer trivas bra med Ubuntu 16.04, som vi skrivit om tidigare ser det ut som ett nytt bra och långsiktigt operativsystem från Ubuntu.

Behöver ni support finns alltid vår personal tillgänglig.

 

 

Alternativ till Ubuntu 16.04?

Skulle ni besluta er för att 16.04 inte möter er organisations krav så finns det inte något exakt identiskt alternativ. LTS är just en Ubuntu-idé men det finns liknande tänk i andra operativsystem som tex RHEL (Red Hat Enterprise Linux, en kommersiell linuxdistribution), CentOS (som är snarlik RHEL och även den RPM-baserad istället för dpkg och atp-get).

På UNIX-sidan är FreeBSD ett populärt alternativ och det är enkelt att med exempelvis ports-trädet i FreeBSD (och NetBSD och OpenBSD också för den delen!) hantera uppdateringar. Faktum är att på sätt och vis är det kanske ännu enklare att hantera RELEASE-uppdateringar (att gå från en större version till en annan, jämförbart med do-release-upgrade i Ubuntu) i FreeBSD än vad det är i många Linux. Kanske är BSD-UNIX ett alternativ för er?

TCP-egenskaperna är mycket bra i framförallt NetBSD och FreeBSD så är det en uppkopplingsintensiv webbtjänst ni sköter så är kanske Unix effektivare? Av denna anledning körs många spelservrar och streamingtjänster på UNIX istället för Linux just eftersom de vid extrem belastning under vissa omständigheter kan stå pall bättre.

Prova en eller ett par VPS:er och utvärdera vilket som möter era behov bäst!

 

Bland Linux-baserade system är kanske Debian nära tillhands för dig som tidiagare jobbat med Ubuntu 14.04. Ubuntu är baserat på Debian så du kommer känna igen i princip allt men - och det här är en stor skillnad - du gör inte helt enkelt distributionsuppgraderingar, dvs går från en stor version (som Debian 7) till en annan (som Debian 8), detta kommer du som Ubuntu-användare tycka är enklare att hantera i Ubuntu än vad det är i Debian. Kanske behöver ni migrera alla system så ofta som en gång per år om ni väljer Debian.

Detsamma gäller i många andra sammanhang, exempelvis Slackware, Arch, Gentoo, Fedora (RPM-baserat), och till och med SuSe blir i många situationer en ominstallation eller migrering till ny server. De flesta operativsystem har någon form av eget (eller Red Hats eller Debians) verktyg för att hantera mjukvaror men alternativet finns också att bygga från källkod.

Måste ni ha just version X (typiskt en äldre version) av en mjukvara så kanske ni kan ha ett nyare operativystem men manuellt kompliera de program ni behöver

Även detta - alternativet att kunna kompilera själv - är enkelt att göra på i princip alla UNIX och Linux-baserade system och i princip aldrig ett alternativ om ni väljer Windows.

 

För er som överväger att migrera till Windows Server vill vi slutligen bara rekommendera möjligheten att använda en robust och snabb linux-plattform och virtualisera windows ovanpå denna istället för att köra Windows "bare metall" (direkt på hårdvaran). Det är i så gott som alla situationer enklare, säkrare, snabbare och betydligt lättare att administrera. Dessutom slipper ni prestandaproblem och mjukvarubegränsningar som Windows (och i viss mån Mac OS även om det är UNIX-baserat) dras med. Det enda skälet att ha en eller ett par "äkta" Windows-servrar är om ni måste köra mjukvaror som i sig kräver Windows. Tex Exchange (som precis som i princip alla andra windows-program går att ersätta med andra, ofta säkrare, enklare och mer kostnadseffektiva, program). Det är en god idé att klustra minst två Windows-maskiner för dessa backend-system och säkra upp dem ordentligt och inte släppa in trafik direkt mot dem utan att ha en frontend (eller flera som vår CDN-tjänst) för att skydda systemen.

Ett stotr problem som många Windows-administratörer känner till alltför väl är uppdateringar, nedtid och behov av omstarter. Ofta långa och flera stycken sådana och med risk för följdproblem. Det är i princip garanterat att du får nedtid men om du klustrar, lastbalanserar eller på annat sätt fördelar trafik, styr om osv så kan du åtminstone minimera problem, nedtid och skador. Säkerhetsrelaterade problem är ett annat problem som många Windows-administratörer måste kunna bemästra. I många fall är mjukvaror inte kompatibla med protokoll, bryter mot standarder mm vilket får svårlösta och i vissa fall helt olösbara följdproblem.

Alla dessa aspekter innebär att en migrering till Windows är det alternativ vi rekommenderar i sista hand (eller snarare avråder ifrån). Det är mycket att sätta sig in i, i många fall krävs många olika servrar (även fysiska) och det är mångdubbla licenser som måste köpas, installeras, konfigureras och förnyas. Om man bortser från kostnadsskillnaden (som är oändligt stor jämfört med Linux och andra kostnadseffektiva operativsystem) så är det administrativa något som ställer helt nya och andra krav på er personal (eller de konsulter ni anlitar). Gör ett par olika experiment med virtuella windows-maskiner hos oss först och utvärdera hur tex WAMP-stacken beter sig osv. Det ÄR stora skillnader och det är inte ett beslut man borde ta över en kafferast.

 

14.04 på lång sikt?

Är det ett alternativ att ligga kvar på 14.04? Nej, i de allra flesta fall är detta en usel "lösning" och innebär säkerhetsproblem på lång sikt.

 

Svårt att förstå om eller hur ni kan uppgradera?

Har ni svårt att hitta den UNIX- eller Linux-baserade plattform som passar era behov? Kontakta gärna vår säljrådgivning så går vi tillsammans igenom för och nackdelar och benar ut olika frågetecken!

 

 

Hur lång tid tar uppgraderingen?

Beroende på hur mycket data som ska gås igenom (hur många program ni har installerade och som ska uppgraderas, konfigurationsfiler som ska konverteras osv) och beroende på vilken typ av lagringsmedia ni valt (mekaniska diskar, flash-diskar, externt monterade filsystem etc) så kan uppdateringen ta från så lite som ca 10 minuter till många timmar.

 

Ett referenssystem som vi haft som exempel är en robust OfficeServer med några år på nacken men inte helt olika den typ av server som är trotjänare på många företag. OfficeServern vi utgått från är en 2008:B, dvs en äldre spec även om det är en långsiktig servermodell som säkerligen har upp emot tio år till kvar i produktion innan den helt måste fasas ut. Server är totalt överbelastad, vilket tyvärr inte är helt ovanligt hos vissa företag och dessutom är hårdvaran underdimensionerad.

Med andra ord vårt referenssystem är något av ett worst-case-scenario och förhoppningsvis inte något i närheten av vad ni har att se fram emot.

 

Till att börja med så har systemet enbart en enkärnig Celeron-CPU. Visserligen en Celeron avsedd för server men fortfarande en Celeron. Med en ensam kärna på 2.66Ghz kommer alla beräkningar som behöver göras att dra ut på tiden rejält. Det finns ingen som helst möjlighet till parallella beräkningar utan varje process ska köras på en och samma kärna.

Detta i sig innebar troligtvis att 1-2 timmar längre tid behövdes än om vi haft en flerkärning server.

 

Varför testar vi på en äldre enkärnig CPU? Jo helt enkelt för att många VPS:er faktiskt körs på en kärna. Kanske är det av kostnadsskäl som beställaren valt en enkärnig virtuell server eller så behövs det helt enkelt inte fler kärnor eftersom man ofta har flera olika små VPS:er som jobbar tillsammans för tex webbsidor.

Här kan det alltså vara värt att uppgradera, åtminstone tillfälligt, så att beräkningar kan utföras mer effektivt. Ni får mindre nedtid och det tar kortare tid att utföra arbetet för er (eller vår!) tekniker!

 

RAM-minne. Även här har vi naturligtvis valt ett ynka 2GB-kort. Även detta innebär att beräkningar tar längre tid och allt som behöver läsas upp i minnet måste vänta. Har ni inget swap-space (virtuellt minne, något som många väljer bort på VPS!) så är 2GB  (eller kanske till och med bara 1GB!) allt ni har. Kontrollera hur mycket minne ni har och uppgradera till åtminstone 1GB per kärna tycker vi. Ju mer desto bättre - allt blir snabbare och fungerar bättre i er server med mer minne!

 

Hårddisk. Självfallet har vårt referenssystem mekaniska hårddiskar. Dessutom mjukvaru-RAID vilket som du kanske känner till innebär rejält försämrad prestanda jämfört med det dyrare och bättre hårdvaru-raid. Diskspeglingen med RAID-1 går alltså via mjukvaror och använder minne, cache-minnen och CPU. Hela tiden ska data synkas mellan diskarna och skriv och läshastigheterna är katastrofalt låga.

 

Mjukvaror. En vanlig LAMP-installation med lite tillägg som mailservrar, git, FTP, ett par oliak webbplatser och både PHP, Java och Tomcat men även vissa PERL och CGI-verktyg. En ganska blandad miljö och inte helt olik en server som stått i drift i många år hos ett företag och där användarna valt att lägga på fler och fler funktioner. Eftersom Ubuntu LTS är just en långsiktig plattform är det troligt att man vill kunna ha denna möjlighet och att det är just därför man valt 14.04 LTS.

 

Tillfället för uppgradering var en vardagskväll. Tanken är att det går trafik men att alla användare kanske inte belastar systemet lika mycket som under kontorstid. Webbplatser har självfallet trafik. Vissa av webbplatserna hade dessutom både audio, video och streaming-innehåll, något som vi såg en rejäl prestandaförsämring för under tiden som uppgraderingen kördes.

Arbetet påbörjades omkring 20:00 och slutfördes omkring midnatt.

 

Ett problem som var särskilt svårt att lösa var den äldre hårdvaruspecen. Här ville Cannonical inte alls acceptera de val som tidigare gjorts och en tidskrävande konvertering av någon form av konfiguration (oklart exakt vad) stod och tuggade på. Ett flertal gånger fick vi avbryta uppgraderingen och starta om, något som vid ett tillfälle faktiskt ledde till olösbara konfilter och att uppgraderingen inte kunde slutföras. Systemet kunde köra med 14.04 men mådde väl inte utmärkt men det gick inte att fortsätta uppgraderingen.

Först när vi fann oss i att kasta ut alla gamla ouppdaterade mjukvaror som tydligen var svårt för uppgradeingsverktyget att hantera gick det att slutförra en uppgradering och prestandan är ungefär lika bra (eller dålig) som tidigare. Dvs trots att System D innebär en del mer komplicerade lösningar än vad som kördes tidigare i 14.04 så var det inte någon märkbar prestandaförsämring utan det gick finfint att köra vidare på 16.04 även med en så pass utdaterad spec! En elgoe till Cannonical, detta hade vi inte förväntat oss faktiskt.

 

 

Gå från 12.04 eller till och med 10.04 till 16.04?

Nej. Utsätt inte dig själv för detta. Beställ en ny server och migrera datat till 16.04-system istället för att joxa med uppgraderingar som så gott som garanterat kommer stanna någonstans mitt i och varken vara kvar på den gamla versionen eller klara att komma till den nya versionen. Att starta om ett system som inte kunnat slutföra en migrering är en chansning. Risken är att din server inte ens kan boota upp ordentligt!

 

Kan problem uppstå?

Absolut. Precis som med i princip varje LTS-version som Ubuntu erbjudit uppgradering för så har vi noterat ett antal mer eller mindre "brickade" maskiner. Dvs risken finns att din server inte startar som den ska eller fungerar dåligt. En nyinstallation är i så fall ert enda alternativ.

Därför är det viktigt att alltid backa upp allt data inkl konfigurationsfiler först samt att aldrig uppgradera ett system som står i drift.

 

Här läser du mer om serverhosting


Nyheter