Edvard Tengqvist
Projektrapport — Självständigt arbete Studieinriktning: Datateknik
Kurspoäng: 15 hp Termin, år: VT, 2020
Abstract
Managing large quantities of aging nodes can be as burdensome and daun-ting task to an administrator. This is the reality for operation administrators and technicians working with Telias older xDSL network where linecards in nodes behaves irreguarly after a long uptime, resulting in faulty connec-tions for the customers. One of the tasks is simply to restart these linecards when a customer or a technician files a complaint if the uptime of the li-necard is an issue. This project aims to solve this issue by using scripting to take inventory of the linecards in the nodes and the corresponding uptime for these linecards. By storing this information in a database one can then query the database about wich linecards that are in need of a restart, before the customer experiences any trouble. By automating some of these manual management tasks with scripting, one can free up more time for personnel to handle other duties, as well as saving resources and cost for maintenance.
Keywords:Bash, sed, awk, ADSL, VDSL, xDSL, database, SQL, sqlite3,
Sammanfattning
Att administrera stora mängder utav åldrande noder kan vara en betungan-de och skrämmanbetungan-de uppgift. Detta är verkligheten för driftpersonalen och teknikerna som arbetar med Telias äldre xDSL-nätverk där linjekort i noder beter sig oregelbundet efter en lång upptid, något som resulterar i bristfälli-ga anslutninbristfälli-gar för kunderna. En av uppgifterna är helt enkelt att starta om dessa linjekort när en kund eller tekniker lämnar in klagomål om upptiden för linjekortet är ett problem. Detta projekt har som mål att lösa denna pro-blematik genom användandet av scripting för att inventera linjekorten och dess motsvarande upptid. Genom att lagra denna information i en databas kan en sedan fråga databasen angående vilka linjekort som är i behov av omstart, innan kunder upplever problem. Genom att automatisera vissa av dessa manuella administrativa sysslor genom script kan en frigöra tid för personalen att utföra andra sysslor samt att spara in resurser och kostnader för underhåll.
Nyckelord:Bash, sed, awk, ADSL, VDSL, xDSL, databas, SQL, sqlite3,
Sammanfattning ii 1 Introduktion 1 1.1 Bakgrund . . . 1 1.2 Syfte . . . 1 1.3 Mål . . . 1 1.4 Problemformulering . . . 1 1.5 Avgränsningar . . . 2
1.6 Konkreta och verifierbara mål . . . 2
1.7 Översikt . . . 3 2 Teori 4 2.1 xDSL . . . 4 2.2 Linux . . . 5 2.2.1 Bash . . . 5 2.2.2 Scripting i bash . . . 5 2.3 sed . . . 6 2.4 (g)awk . . . 7 2.5 expect . . . 8 2.6 SNMP . . . 9 2.7 Telnet . . . 10 2.8 SSH . . . 10
2.9 Databaser, SQL och SQLite . . . 11
4.4 Urval av linjekort för omstart . . . 28
4.5 Loggning och felhantering . . . 29
1
Introduktion
Denna sektion kommer att avhandla den övergripande bakgrunden för stu-dien. Detta inkluderar syfte, mål, problemformuleringar, avgränsningar för studien, verifierbara mål samt en översikt av dokumentet.
1.1
Bakgrund
Inom samtliga nätverk finns alltid behov av att manuellt underhålla enheter för att dessa skall fungera felfritt. Detta underhåll kan bestå av att konfigu-rera eller omkonfigukonfigu-rera enheter, samt andra administrativa sysslor för att säkerställa att enheterna fungerar som önskat. Detta behov av underhåll gäller i såväl mindre hemmanätverk samt i större nätverk såsom de som återfinns hos en internetleverantör. Att automatisera delar av detta under-håll kan minska arbetsbördan och frigöra resurser för andra typer av arbets-uppgifter.
Oavsett om utrustningen är helt ny eller om det är äldre utrustning krävs underhåll tills produkten nått slutet av sin livslängd. Istället för att inför-skaffa nya enheter med bättre support och serviceavtal kan både företag och miljö dra nytta av använda sig av redan befintlig hårdvara och hitta lösningar för att öka livslängden för dessa.
1.2
Syfte
Detta projekt har som syfte att konstruera ett eller flera script för att samla information om enheter och deras upptid. Detta för att utifrån inventering-en sedan kunna fatta automatiserade beslut kring hanteringinventering-en av dessa.
1.3
Mål
Detta projekt har som mål att minska upptiden hos linjekorten som xDSL-noderna är bestyckade med.
I förlängningen bör detta leda till att Telia tar emot färre felanmälningar från kunder rörande xDSL samt att mindre resurser används för att felsöka dessa noder. Detta medför även att tekniker inte skall sändas ut i onödan för felsökning av linjekort när en omstart hade kunnat genomföras på distans.
1.4
Problemformulering
felanmälningar samt kundfelanmälningar som gått igenom kundtjänst, där sedan en teknisk analys sker för att utreda om det föreligger ett nätfel och i de fallen åtgärda dessa eller skicka ut en tekniker för åtgärd.
För just xDSL innefattar detta arbete cirka 15 000 noder som är bestyckade med ett varierande antal linjekort. Totalt är cirka 85 000 linjekort i drift för-delat mellan dessa noder. Inga nya satsningar kommer att ske då xDSL skall fasas ut, men nuvarande noder behöver fortfarande service tills dessa fasats ut.
När ett linjekort varit uppe mellan 300 – 400 dagar börjar dessa bete sig oberäkneligt, antingen genom att det börjar gå störningar mot kunden eller att hastigheten sjunker.
Att scanna samtliga noder i nätet är även en tidskrävande process, dels då hårdvaran är äldre, men även för att samtliga noder innehar olika mängder linjekort som behöver inventeras.
Ett annat problem är att samtliga noder inte kan startas om direkt, då det-ta kan leda till mer omfatdet-tande störningar. På samma sätt kan omsdet-tart av alltför stor mängd linjekort leda till en mer omfattande störning.
1.5
Avgränsningar
Arbetet är enbart anpassat efter önskemål från Telia NRC, andra typer av lösningar kommer därav inte behandlas. Några av dessa önskemål är att scriptet eller scripten skall vara skrivna i bash för kompabilitet och att lag-ringen skall ske i en lokal databas.
Då det redan finns ett schemalagt script för omstart av enheter kommer det-ta inte inte det-tas med i rapporten. Endast att hämdet-ta ett urval av de inventerade linjekorten och skriva dessa till listan som scriptet läser ifrån för omstarter-na är aktuellt.
1.6
Konkreta och verifierbara mål
• Kan ett script skrivas som inventerar nodernas linjekort?
• Går det att skriva ett script som inventerar linjekortens upptid? • Kan ett script göra urval om vilka linjekort som bör startas om? • Minskar den genomsnittliga upptiden efter exekvering av scripten? • Går det att utveckla en metod som kringår nodens långsamma
swit-chliknande CLI?
1.7
Översikt
• Kapitel 1 beskriver bakgrunden och syftet för projektet. I detta in-kluderas mål, problemformuleringar, avgränsningar samt verifierbara mål.
• Kapitel 2 täcker in den teori som projektet grundar sig på.
• Kapitel 3 visar och beskriver tillvägagångssättet för mätningarna och resultaten på hög nivå samt miljön för studien.
• Kapitel 4 förklarar och visar koden som har använts.
• Kapitel 5 visar resultaten från manuella körningar av scripten, samt mätningen av upptid innan och efter manuell exekvering av script. • Kapitel 6 diskuterar tillförlitligheten i mätningarna samt de etiska
aspek-terna rörande projektet.
• Kapitel 7 reflekterar kring förbättringsområden samt slutsatser för ar-betet.
• Bilaga A innehåller koden för att inventera linjekorten i noderna i sin helhet.
• Bilaga B består av koden som används för att inventera linjekortens upptid.
• Bilaga C visar scriptet för att logga in i noden över ssh, vilket koden i bilaga B anropar för inloggning.
2
Teori
Denna sektion avhandlar teorin som projektet bygger på. Detta för att ge läsaren en övergripande kunskap av komponenterna som projektet bygger på.
2.1
xDSL
DSL - digital subscriber line är en teknik för kommunikation som nyttjar existerande kopparledningar som medium för överföring [1].
Bakom designen av DSL var tanken att ersätta den tidigare ISDN - integra-ted services digital network för att erjuda internetåtkomst med fördelen att tekniken hade en högre hastighet över de redan existerande telefonledning-arna [1].
DSL är inte en specifik digital linjeteknik utan agerar mer övergripande som en digital modemteknik vilket fungerar genom signal processering och mo-dulation [1]. Signalen i sig konverteras inte till analog, utan skickas digitalt från kundens utrustning till leverantörens utrustning [1].
Beroende på leverantörens implementation av DSL kan moduleringstekni-ken variera från CAP - carrierless amplitude and phase modulation eller DMT - discrete multitone modulation [1].
DSL i sig representerar ett flertal olika tjänster som vanligen benämns som ”xDSL”, där DSL är övergripande för dessa [1]. Teknikerna för detta är föl-jande:
• ADSL - asymetric digital subscriber line: Allokerar bandbredden asy-metriskt med en högre hastighet nedströms än uppströms [1].
• HDSL - high-bit-rate digital subscriber line: Stödjer en hög hastighet i full duplex över flera partvinnade kablar [1].
• SDSL - symmetric digital subscriber line: Stödjer standardiserad te-lefonkommunikation över en enda partvinnad kabel [1].
• VDSL - very high-rate digital subscriber line: Stödjer en betydligt högre hastighet, med hastigheter upp till 52 Mb/s nedströms, dock endast över en kortare distans [1].
2.2
Linux
Ett Linuxbaserat operativsystem består av fyra huvuddelar: Linuxkärnan, GNU systemapplikationer, en grafisk skrivbordsmiljö och applikationsmjuk-vara [3, s. 3]. Kärnan eller kernel är den delen som kontrollerar all hårdapplikationsmjuk-vara och mjukvara och allokerar hårdvaruresurser när det är nödvändigt samt exekverar mjukvara när det krävs [3, s. 4].
När Linus Torvalds skrev koden för Linuxkärnan saknades systemapplika-tioner för att hantera filer och program [3, s. 9]. Simultant utvecklade organi-sationen GNU (GNU’s Not Unix) en komplett uppsättning av systemappli-kationer med inspiration från Unix, men de hade ingen kärna för systemet att köras på [3, s. 9].
En speciell systemapplikation är GNU/Linux shell, eller skal som låter an-vändaren att starta program, hantera filer och hantera processer via en in-teraktiv kommandoprompt [3, s. 10]. Kommandon som exekveras tolkas av kärnan direkt, men kan även gruperas i textfiler för att köra flera komman-don i följd som ett skalscript [3, s. 10].
I begynnelsen var Linux endast ett textbaserat gränssnitt men detta ändra-des när Windows lanseraändra-des och användarna förväntade sig mer än endast textbaserade gränssnitt att arbeta med [3, s. 11]. I dagsläget finns ett flertal grafiska skrivbordsmiljöer att välja bland [3, s. 11]. Några av de vanligast förekommande är X Window, KDE, GNOME och Unity [3, s. 11 - 15].
2.2.1
Bash
Det finns ett flertal olika skal att använda i Linuxsystem med lite olika ka-raktärsdrag och tilltänkta användningsområden [3, s. 10]. Som standard an-vänds Bourne again shell, eller bash som standard för de flesta distributio-nerna [3, s. 10].
Vid inloggning i systemet kommer automatiskt ett bash shell startas, oavsett om det är direkt via en kommandoprompt eller via en grafisk skrivborsmil-jös terminal emulator för att få tillgång till kommandoprompten[3, s. 48]. För att få tillgång till olika kommandons manualsidor direkt i terminalen används kommandotman följt av namnet på kommandot [3, s. 48].
2.2.2
Scripting i bash
Finessen med skalscripting är möjligheten att kunna mata in ett flertal kom-mandon och processa resultaten från varje kommando eller skicka resultatet från ett kommando till ett annat kommando[3, s. 269].
in manuellt[3, s. 270]. En annan metod är att använda en textredigerare och gruppera kommandon i en textfil och sedan exekvera textfilen [3, s. 270]. När en scriptfil skapas måste det specificeras vilket skal som skall användas [3, s. 270]. Detta görs med#! följt av sökvägen för skalet [3, s. 270]. Exem-pelvis:
1 #!/bin/bash
Nu kan varje kommando läggas på en egen rad i skalscriptet, eller separeras med semikolon för att processeras i den ordning de framkommer i textfilen [3, s. 270]. I normalfall kommer inte skalet tolka rader som inleds med # utan dessa ses som ett tillfälle att kommentera koden, undantaget för detta är första raden som inleds med#! för att indikera vilket skal som skall tolka scriptet [3, s. 270 - 271].
För att sedan exekvera scripten kan en absolut eller relativ sökväg använ-das, alternativt lägga till katalogen där skriptet ligger till miljövariabeln PATH som är de kataloger skalet kommer leta efter kommandon i [3, s. 271]. För att säkerställa att användaren har rättigheter att exekvera scriptet an-vänds kommandot chmod +x följt av scriptets namn för att sätta exekve-ringsflagga till filen [3, s. 271 - 272].
2.3
sed
Istället för att manuellt manipulera en fils innehåll med en interaktiv tex-tredigerare där användaren använder tangentbordet för att manipulera in-nehållet, så kan strömeditornsed användas [3, s. 505]. För att behandla en ström av text användersed sig utav regler om vad som skall redigeras innan ändringarna äger rum [3, s. 505].
För att manipulera datan läsersed först in datan rad för rad, sedan matchas datan mot kommandon för redigering, efter detta genomförs ändringarna och resultatet skrivs ut [3, s. 506]. Denna process repeteras för varje rad från indatan och när inga fler rader upptäcks avslutas den [3, s. 506]. Som indata accepterarsed både filer eller indata från en pipeline[4].
Syntaxen försed kan bestå av fyra delar, kommandot i sig, argument, script för vad som skall editeras och filen [3, s. 506]. Ett exmepel på hur sed kan användas för att byta ut ordet ”apple” i en fil följer nedan:
1 sed -i 's/apple/raspberry/' test.txt
För att exekvera flera kommandon i sed behöver flaggan -e användas och varje kommando behöver separeras med ett semikolon[3, s. 507 - 508]. Ett annat sätt att skriva flera kommandon i scriptspråketsed utan att sepa-rera med semikolon är att använda sig av prompten i bash [3, s. 508]. Ge-nom att använda sed -e med ett första citationstecken kommer program-met startas och efterfråga input tills den får det stängande citationstecknet [3, s. 508]. Ett exempel på detta kan ses nedan:
1 sed -e '
2 s/apple/raspberry/ 3 s/banana/pi/' test.txt
Samtliga kommandon försed kan lagras i en egen scriptfil och läsas in med argumentet -f, i dessa fall behövs dock inga citationstecken eftersom sed läser in rad för rad [3, s. 508]. Ett exempel på denna syntax kan ses nedan:
1 sed -f script.sed test.txt
För att byta ut specifika tecken kan en ”\” användas före för att se till att exempelvis ”/” tolkas korrekt som ett tecken [3, s. 518]. Ett annat sätt är att använda utropstecken för att markera vilket tecken som skall agera skil-jetecken [3, s. 518]. Exempel på första sättet att undkomma forward slash följer nedan:
1 sed 's/\/home\/dvardo/\/home\/edvard/' /etc/passwd
Exempel på andra sättet att undkomma forward slash:
1 sed 's!/home/dvardo!/home/edvard!' /etc/passwd
Vidare stödjer ävensed att adressera en viss rad genom att ange numret för den, eller ett omfång av rader som kommer beröras av redigeringen [3, s. 518 - 519]. Dessutom finns även stöd för att skapa enklare och avancerade reguljära uttryck för att skapa regler för upptäckt av mönster i text [3, s. 520].
Utöver att ersätta tecken eller mönster kansed även användas för att radera genom att användad för ”delete” [3, s. 521], eller infoga genom att använda i och lägga till rad genom att använda a [3, s. 523].
2.4
(g)awk
bistår med ett programmeringsspråk i sig, istället för endast kommandon för editering [3, s. 509].
Med hjälp avgawk kan en användare utföra följande: • Definiera variabler för lagring av data [3, s. 509].
• Utföra aritmetiska och strängbehandling på datan, genom användan-det av operatorer [3, s. 509].
• Använda programmeringslogik som loopar och villkorssatser [3, s. 509].
• Extrahera data som element och ompositionera dessa i en annan ord-ning eller annat format än tidigare [3, s. 509].
En fördel med att använda gawk är att det finns möjlighet att skriva script för inläsningen av data, behandla denna samt visa resultatet från körningen [3, s. 510]. För att skapa ett script med gawk behöver kommandon placeras mellan en öppnande och en stängande klammerparentes, som i sin tur om-sluts av ett enkelt citationstecken på varje sida [3, s. 510]. För att exekvera flera kommandon i samma script förgawk separeras kommandon med se-mikolon [3, s. 512].
En annan av de större fördelarna medgawk vid manipulering av data från textfiler är att den automatiskt deklarerar variabler för varje element i raden där$0 representerar hela raden, medans följande siffror representerar vilket fält från raden [3, s. 511]. För att skilja på fälten används ett separerande tecken, vilket i standardutförandet är blanksteg eller tabuleringar [3, s. 510].
2.5
expect
Programmetexpect kan användas för att kontrollera interaktiva applikatio-ner där användaren förväntas svara med knapptryckningar[5, s. 1]. Genom att använda sig utav expect kan dessa interaktioner autotmatiseras direkt i script [5, s. 1]. Exempelvis ärtelnet en sådan applikation som kräver re-spons från användaren, vilket kan kringås genom att låtaexpect interagera med dessa interaktiva program och därmed köra interaktiva program utan interaktion [5, s. 2].
En funktion förexpect är att den kan automatisera endast delar av kommu-nikationen för att sedan överlämna kontrollen från scriptet till tangentbor-det [5, s. 2]. Grundläggande använder sig expect av de fyra kommandona expect, send, spawn och interact för att bygga upp den automatiserade dialogen [5, s. 71].
expect läser in tecken som inte är den förväntade strängen fortsätter den att vänta på fler tecken [5, s. 72]. Som svar påexpect används send för att ta emot en textsträng som argument och skicka det till processen [5, s. 71]. För att starta andra program används spawn följt av programmets namn för att starta processen [5, s. 78]. För att ange argument till programmen används sedan en textsträng som argument till programmet som skall bli en process [5, s. 78].
I de fall en användare inte vill automatisera hela dialogen kaninteract an-vändas för att överlämna kontrollen från scriptet till användarens tangent-bord [5, s. 82 - 83]. Ett exempel på hur interaktionen för att automatisera inloggning viatelnet visas nedan:
1 spawn telnet localhost 2 expect "login:" 3 send "user\r" 4 expect "Password:" 5 send "password\r" 6 send "\r" 7 expect "#" 8 interact
2.6
SNMP
Protokollet SNMP - Simple Network Management Protocol, var ett försök att standardisera hanteringen av IP enheter som lanserades 1988 [6, s. 1]. Grunden i protokollet är att bistå användaren med en uppsättning enkla operationer för att kunna hantera och övervaka enheterna i nätverket [6, s. 1].
Operationerna för detta ärsnmpset som används för att ange ett värde till objektet,snmpget som används för att läsa värdet från ett objekt och snmpwalk som används för att hämta en del av trädet som utgör MIB - Management Information Base[6, s. 141].
mjukvara för enheterna som skall hanteras eller övervakas [6, s. 3].
2.7
Telnet
Ett av de tidiga protokollen för fjärråtkomst till datorer varTelnet, som an-vänds som en applikation [7, s. 183]. Syftet med protokollet var att generellt skapa en tvåvägs kommunikation [8]. Protokollet hade som mål att skapa en standard för kommunikation till enheters terminaler genom ett mellanlager, eller till processer i terminaler genom att ansluta till dessa [8].
Protokollet använder en klassisk modell av klient och server, där använda-ren får tillgång till en terminal session till fjärrdatorn över nätverket via en Telnet applikation [9].
För att säkerställa dessa anslutningar och att meddelanden och svar tas emot byggerTelnet på det förbindelseorienterade protokollet TCP - Trans-mission control protocol [8].
En av grunderna iTelnet är idén om ”Network virtual terminal”, även kal-lat NVT [8]. Denna NVT framställs som en egen virtuell enhet, vilket ger en standard över nätverket där terminalen kan representeras [8].
På så sätt behöver inte server och klient-värd hålla reda på information om varandras terminaler, utan detta mappas till den lokala enheten och fram-står som en NVT över nätverket där den andra parten förväntas göra en liknande mappning [8].
I avseende till säkerhet har protokollet ingen inbyggd säkerhet, vilket gör att det rekommenderas att inte använda det över internet eller i nätverk som inte går att lita på fullt ut [9].
Ett tydligt exempel på den bristande säkerheten är att anslutningen mellan klient och server skickas i klartext, vilket för att en angripare kan manipu-lera datan som skickas samt avlyssna denna i realtid [9].
2.8
SSH
För att administration av enheter där lokal åtkomst inte är möjlig finns pro-tokollet SSH - secure shell som tillåter exempelvis just fjärrinloggning [10, s. 1016]. SSH är efterträdaren till det tidigare verktyget för fjärrinloggning, nämligen Telnet [7, s. 183]. Protokollet stödjer även möjligheten att exe-kvera kommandon via fjärranslutningen, ge åtkomst till terminalpromp-ten, filöverföringar, portvidarebefodran, samt nätverkstjänster för VPN och proxy [10, s. 1016].
krypto-grafi rörande autentisering samt för konfidentialiteten och integriteten [10, s. 1016].
Designen av protokollet är modulär och inte beroende av de kryptografiska protokollen som används, något som tillåter olika kryptografiska protokoll att användas [10, s. 1016]. I förlängningen innebär detta att nya kryptogra-fiska protokoll kan införas och åldrade protokoll kan väljas bort [10, s. 1016]. Det finns ett flertal implementationer av SSH, vanligast för Linuxsystem är dockOpenSSH som är inkluderat och aktiverat som standard i de flesta ver-sionerna av Unix [10, s. 1016].
I normalfallet etablerar klienten en ansluting till servern genom att auten-tisera sig, där klient och server måste komma överrens om metod och pre-ferenser för autentiseringen [10, s. 1016]. När anlutningen väl är upprättat verifierar servern sig genom att skicka sin publika nyckel till mottagaren och i de fall servern inte är känd sen tidigare tillfrågas användaren om den vill spara en hash av den publika nyckeln, ofta benämnt som nyckelns fin-geravtryck [10, s. 1017].
Ett fingeravtryck som godkänts sparas sedan efter interaktionen i en lista över kända värdar för det lokala systemet [10, s. 1017].
Tanken är att administratörer i förväg skall kunna distrubera nyckeln innan inloggning och på så sätt behöver endast den jämnföras mot nyckeln för att bevisa identiteten, något som dock oftas slarvas med och användaren litar blint på nyckeln som erbjuds och accepterar denna [10, s. 1017].
När nyckeln väl är accepterad listar servern olika metoder för autentisering som den stödjer[10, s. 1017]. Alltifrån enkla lösenord, publika nycklar, be-trodda värdar, GSSAPI för integration med kerberos, olika challenge/response för integration med PAM-modulen i Linux och engångslösenord [10, s. 1017].
2.9
Databaser, SQL och SQLite
För lagring av större mängder insamlad data kan databaser vara lämpliga, alltså där varje post i databasen relaterar till de övriga posterna [7, s. 416]. En databas i sig är en strukturerad samling av information eller data, som ofta hanteras av en DBMS - database management software [11]. Datan i de vanligaste typerna av databaser organiseras i rader och kolumner, inom en given tabell för att effektivisera förfrågningar mot databasen [11].
För att hantera data i databaser används ofta structured query language -SQL, för att skriva och hämta data från database [11]. Utöver detta gör SQL det även möjligt med åtkomstkontroll till data i databasen [11]. SQL utveck-lades initialt ifrån IBM och har blivit populär hos de flesta databassystem, en av anledningarna till detta är att det standardiserats hos ANSI - American national standards institute [7, s. 430]. I sin grundform kan en SQL-förfågan bestå av tre delar, en ”SELECT”, en ”FROM” och en ”WHERE” [7, s. 430]. Nedan följer ett exempel på hur en förfrågan kan se ut:
1 SELECT nodeIp,cardIp 2 FROM inventory
3 WHERE nodeIP = '192.168.0.1' AND id = inventory.id;
De allra flesta databassystem har en databasmotor med en separat server-process, där ett undantag är SQLite [12]. Just SQLite använder sig av en inbäddad databasmotor och både läser och skriver till vanliga filer lagrade i sekundärminnet [12]. All kod för projektet är publicerad och fri att använda, varesig det gäller privata eller kommersiella lösningar [12].
SQLite lämpar sig även väl för scripting, eftersom SQL-förfrågningarna kan skickas med som argument direkt i terminalen där argumentet omges med citationstecken[13]. Ett exempel på detta går att se nedan:
1 sqlite3 databas.db "SELECT ID, NODIP, CARDIP FROM INVENTORY
WHERE ID=1;"
,→
2.10
Tidigare undersökningar
Sökmotorn scholar.google.se användes med diverse söktermer för att finna liknande studier som denna. Söktermerna network scripting with bash samt managing large networks with bash gav inga relevanta resultat, mer än böcker inom ämnet scripting. Däremot gav söktermen network
automa-tion with bash en relevant studie, nämligen ”Network Automation – the
3
Metod
Denna sektion innehåller utgångsläget för själva studien. Miljön som an-vänds för studien kommer presenteras samt hur frågeställningarna kommer besvaras.
3.1
Inventering av nätverket
För att inventera linjekorten i varje nod kommer ett script att skrivas. Detta kommer ansluta till noden för att hämta ut information om linjekorten via nodens switchliknande CLI - command line interface. Denna information kommer sedan skrivas till en fil för att sedan bearbetas innan den förs in i databasen. I figur ett framgår hur inventeringen av linjekort kommer ske.
Utifrån denna databas kommer sedan upptiderna för respektive linjekort att inventeras genom snmpget, för att sedan manipuleras och föras in i da-tabasen. I figur två framgår hur inventeringen av upptid sker.
Slutligen när både inventeringen av linjekort och inventeringen av upptiden är genomförd kommer SQL användas för att göra ett urval utifrån databa-sen om vilka linjekort som är i behov av omstart att göras. I figur tre framgår hur detta urval genomförs.
3.2
Verktyg
3.2.1
Laborationsmiljö
För att testa fram syntax och skissa på script kommer en virtualiserad Debian 10 användas ifrån en Windows 10 Pro. Virtualiseringen sker genom mjukva-ran Virtualbox 6.0 för att sedan migreras till servern i skarp miljö som skall exekvera script. Nedan följer specifikationerna för de olika maskinerna.
Host OS
• Operativsystem: Windows 10 Pro. • Hårdvara:
– CPU:Intel i5-8600K, 3.60 GHz, 6 kärnor.
– RAM:16 GB, 3000 MHz.
• Mjukvara: VirtualBox 6.0.20.
Guest OS
• Operativsystem: Debian 10. • Hårdvara:
– CPU:Intel i5-8600K, 3.60 GHz, 2 kärnor.
– RAM:2 GB, 3000 MHz.
• Mjukvara: SQLite 3.27.2, SQLitebrowser 3.10.1. • Versioner av protokoll: Net-SNMP 5.7.3.
3.2.2
Produktionsmiljö
Servern (virtualiserad)
• Operativsystem: Red Hat Enterprise Linux Server release 6.10 (Santi-ago).
• Hårdvara:
– CPU:Intel Xeon E5-2690, 2.90 GHz, 1 kärna.
– RAM:11 GB.
• Mjukvara: SQLite 3.27.2.
Noder
VD
• Operativsystem: Wind River Linux Sourcery G++ 4.1-161 • Hårdvara:
– CPU:AuthenticAMD Geode (TM), 498.058 MHz, Integrated
Pro-cessor by AMD PCS, family 5, model 10.
– RAM:118 MB.
• Versioner av protokoll: NET-SNMP 5.4.
BD
• Operativsystem: Linux version 2.4.32 (tedflda@dxdlinuxs2) • Hårdvara:
– CPU:CyrixInstead, 266.655 MHz, family 5, model 9.
– RAM:58.4 MB.
• Versioner av protokoll: NET-SNMP 5.0.8.
3.2.3
Topologi
Figur 4: Förenklad topologi över nätverket.
3.2.4
Programvaror
Nedan följer samtliga programvaror som använts under projektet.
Virtualisering: VirtualBox 6.0.20(i laborationsmiljön).
Textredigerare: Pluma(i laborationsmiljö) samt nano (i laboration och
pro-duktionsmiljö).
SQL: SQlite3(i både laboration och produktionsmiljö) samt SQLitebrowser (i
laborationsmiljö).
Övrigt: LibreOffice Impress(för skapande av stapeldiagram) samt app.diagrams.net
3.3
Bedömningskriterier
3.3.1
Mätning
För att mäta tiden för inventering av både linjekort och upptid kommer kommandot time användas följt av scriptets namn, då detta returnerar ti-den för exekvering [15]. Dessa mätningar kommer ske mot ett urval av no-derna och inte samtliga noder eftersom en sådan mätning skulle vara allt-för tidskrävande. Resultatet av detta kommer sedan divideras med antalet noder i urvalet för att nå ett medelvärde, som sedan multipliceras med to-tala antalet noder för att få en uppskattad exekveringstid för inventering. Samma form av mätningen kommer även göras för inventeringen av linje-kortens upptid som beräknas på samma sätt. Variablerna och formlerna för beräkningarna följer nedan:
Variablerna för uträkningen:
T = Exekveringstiden N = Antalet noder/linjekort M = Medelvärde
Tn = Totala antalet noder/linjekort Tt= Totala exekveringstiden
Formeln för att räkna ut medelvärdet per nod/linjekort:
T/N =M
Formeln för att räkna ut totala exekveringstiden:
M∗Tn =Tt
För att mäta ifall upptidens medelvärde för linjekorten sjunker kommer en testkörning av scripten med ett begränsat urval noder att ske. Antalet linje-kort vars upptid kommer inventeras i testet kommer vara 327 stycken. Ur-valet för omstart kommer vara 3 stycken linjekort. För att beräkna medelvär-det kommer en SQL-fråga användas som räknar ut medelvärmedelvär-det i kolumnen för upptid, men även bortser från upplänkarnas upptid. SQL-frågan ser ut på följande sätt:
1 sqlite3 databas.db "SELECT AVG(UPTIME_DAYS) FROM INVENTORY2
WHERE COMPONENT NOT IN ('ECN330', 'ESN212', 'ECN320');"
,→
3.3.2
Besvarande av frågeställningar
För att besvara frågeställningarna kommer ett antal separata script att skri-vas. Det första scriptet kommer inventera linjekorten i noderna, det andra scriptet kommer inventera upptiden för linjekorten och det tredje scriptet kommer göra ett urval av vilka linjekort som är i behov av en omstart. Scrip-ten kommer skrivas i bash men kommer använda sig av andra språk såsom awk och SQL, samt SNMP för att hämta upptider från linjekorten.
4
Konstruktion
I denna sektion kommer stycken av kod förklaras samt vissa ställningsta-ganden rörande koden. Samtliga script finns även som bilaga i sin helhet.
4.1
Databas
Installera databasen och grafiskt verktyg för att granska databasen:
1 sudo apt install sqlite3
2 sudo apt install sqlitebrowser
Därsudo används för att tilfälligt höja användarens behörigheter [16], me-danapt install tar paketen som skall installeras som argument[17]. Skapa databasen samt tabellen med tillhörande kolumner:
1 sqlite3 databas.db 2
3 CREATE TABLE INVENTORY1(
4 ID INTEGER PRIMARY KEY AUTOINCREMENT, 5 SID TEXT NOT NULL,
6 COMPONENT TEXT NOT NULL, 7 NODIP TEXT NOT NULL, 8 CARDIP TEXT,
9 UPTIME_DAYS INT, 10 UPTIME_HOURS INT 11 );
12
13 CREATE TABLE INVENTORY2(
14 ID INTEGER PRIMARY KEY AUTOINCREMENT, 15 SID TEXT NOT NULL,
16 COMPONENT TEXT NOT NULL, 17 NODIP TEXT NOT NULL, 18 CARDIP TEXT,
19 UPTIME_DAYS INT, 20 UPTIME_HOURS INT 21 );
4.2
Inventering av linjekort
Detta script ämnar att logga in i varje nod var för sig, hämta ut informatio-nen som är nödvändig och bearbeta den datan innan den förs in i databasen. För detta används enfor-loop för att logga in i noderna och hämta datan, samt en nästladwhile-loop för att föra in datan i databasen. För fullständig kod se bilaga A. Nedan följer första stycket av koden med förklaringar av koden efter stycket:
1 for nodeIp in $(cat vdc.txt ) 2 do
3 /usr/bin/expect << EOF 4 log_user 1
5 set timeout 20
6 spawn telnet $nodeIp 7 expect "login:" 8 send "user\r" 9 expect "assword: " 10 send "password\r" 11 exec sleep 3 12 send -- "\r" 13 send -- "a\r" 14 send -- "\r" 15 expect -re {[../#|# ]} 16 send -- "\r" 17 send -- "\r" 18 expect -re {[../#|# ]}
19 log_file -a -noappend logfile_temp
20 expect -re "(\\\$ |# )" { send "show ecn inventory\r" } 21 expect -re "\r\n(.*)\r(.*)(\\\$ |# )"
22 expect -re "(\\\$ |# )" { send "show ecn inventory\r" } 23 expect -re "\r\n(.*)\r(.*)(\\\$ |# )" 24 log_file 25 expect -re {[../#|# ]} 26 send "exit\r" 27 EOF 28 sed -i '/^\./d' logfile_temp
29 sed -i '/^[[:space:]]*$/d' logfile_temp 30 sed -i '/^[A-Za-z]/d' logfile_temp 31 sort -u logfile_temp -o logfile_temp
För att generera output användslog_user 1 likt ifall en användare manuellt matat in detta, vilket är användbart i felsökningssyfte [20]. Sedan används set timeout 20 för att ange att dialogen för expect avbryts om ingen re-spons ges på 20 sekunder [20]. Därefter användsspawn för att starta en ses-sion förTelnet med nodens IP adress som argument [20]. Även exec sleep 3 används för att noden skall hinna med innan dialogen börjar [20].
Efter detta följer dialog därexpect används med en sträng för att förvänta sig input ochsend används för att skicka sträng som svar [20].
Sedan användsexpect -re för att förvänta sig reguljära uttryck [20], detta eftersom de två olika nodtyperna har olika tecken för prompten. Här an-vänds ävenlog_file -a noappend logfile_temp för att skapa en en fil på servern med utdatan från noden [20].
Kommandotshow ecn inventory som skickas är internt för nodernas swit-chliknande CLI. Anledningen till att kommandot skickas två gånger är för att ena typen av nod kräver att kommandot körs två gånger för att generera utdata ilogfile_temp. Slutligen skickar den exit för att avsluta sessionen. Efter detta användssed med flaggan -i för att modifiera filen[4] och i detta fall ta bort eventuella blanka rader, samt rader som inleds med bokstäver och eventuella rader som inleds med en punkt. Slutligen användssort med argumentet -u för att sortera bort dubletter och med hjälp av flaggan -o spara resultatet till samma fil [21].
Nedan följer andra stycket av koden med förklaringar av koden efter styc-ket:
1 awk -v ip="$nodeIp" '{print $1,$3,ip,$5}' logfile_temp >
parsedinventory.txt
,→ 2
3 while IFS= read -r line
4 do
5 sid=$(echo $line | awk '{print $1}' )
6 component=$(echo $line | awk '{print $2}' ) 7 nodeip=$(echo $line | awk '{print $3}' ) 8 cardip=$(echo $line | awk '{print $4}' ) 9
10 sqlite3 databas.db "INSERT INTO
INVENTORY1(SID,COMPONENT,NODEIP,CARDIP) VALUES ('$sid','$component','$nodeip','$cardip');"
,→ ,→
11 done < parsedinventory.txt 12
13 done
14 sqlite3 databas.db "INSERT OR REPLACE INTO INVENTORY2 SELECT
* FROM INVENTORY1;"
Först användsawk med argumentet -v för att ta emot en variabel[22], i det-ta fall tilldelas variabeln värdet från tidigare variabel i scriptet. Efter detdet-ta anges det att den skall skriva ut fälten 1, 3, 5 och variabeln frånlogfile_temp samt omdirigera detta genom att använda> till nya filen [19].
Sedan kommer en nästlad while-loop som använder sig utav IFS= för att ange vilken ”Internal Field Separator” som skall markera skiljetecken för ord [19]. Sedan användsread för att läsa in raden från filen [23].
I själva loopen deklareras variabler genom att tilldela värde från utdatan från kommandon genom att inleda med dollartecken och omsluta dessa med parenteser [19]. Först används echo för att skriva ut variabeln som i detta fall är raden [24], för att senare omdirigera utdatan till nästa pro-gram genom att använda en pipe [19]. Slutligen skriverawk ut rätt fält med print[22] och variablerna används sedan i VALUE för sqlite3 för att föra in dessa i databasen [13]
Avslutningsvis när båda looparna är avslutade användssqlite3 för att in-foga eller ersätta allt innehåll frånINVENTORY1 till INVENTORY2 [13].
4.3
Inventering av upptid
Detta script använder sig utav informationen i databasen för att hämta no-dernas IP adresser samt linjekortens IP adresser för att kunna skapa en ssh-asnlutning till noden och användasnmpget för att hämta linjekortens upptid [25]. För att genomföra detta används nästlade for-loopar där den i första nivån använder sig av den totala mängden linjekort för noden, för att sedan i den andra nivån ansluta till noden och hämta ut upptiden för varje linje-kort. För fullständig kod se bilaga B. Första stycket av koden följer nedan och följs av förklaringar efter stycket:
1 ID=1
2 rows=$(sqlite3 databas.db "SELECT COUNT(*) FROM
INVENTORY2;")
,→ 3
4 for ((i = 1; i <= $rows; i++)) 5 do
6 nodeIp=$(sqlite3 databas.db "SELECT NODEIP FROM
INVENTORY2 WHERE ID=$ID;")
,→
7 cardsNum=$(sqlite3 databas.db "SELECT COUNT(CARDIP) FROM
INVENTORY2 WHERE NODEIP='$nodeIp';")
,→
utav utdatan frånsqlite3 "COUNT(*)" för att räkna varje rad i INVENTORY2 [13].
Efter detta börjar den första loopen med en tillfällig variabeli med värdet 1, som sedan jämförs mot den tidigare variabeln och ökar värdet påi tills villkoret stämmer.
I loopen deklareras sedan två variabler med utdatan frånsqlite3 där den ena hämtar nodens IP adress i de fall ID matchar, medan den andra använ-der sig utav COUNT för att räkna ut antalet linjekort för noden [13]. Andra stycket av koden följer nedan och följs av förklaringar efter stycket:
1 for (( c = 1; c <= cardsNum; c++))
2 do
3 cardIp=$(sqlite3 databas.db "SELECT CARDIP FROM
INVENTORY2 WHERE NODEIP='$nodeIp' AND ID=$ID;")
,→ 4
5 /usr/bin/expect -f ssh.exp user $nodeIp password
$cardIp
,→
6 ticks=`grep Timeticks tempUptime.log | tr -d '()' |
awk '{print$2}'`
,→
7 upDays=$(( $ticks / 8640000 )) 8 upHours=$(( $ticks / 360000 )) 9
10 sqlite3 databas.db "UPDATE INVENTORY2 SET
UPTIME_DAYS = $upDays,UPTIME_HOURS = $upHours
WHERE ID=$ID;"
,→ ,→ 11 rm -rf tempUptime.log 12 ID=$(($ID + 1)) 13 done 14 done
Inledningsvis startar den nästladefor-loopen som använder den tillfälliga varabelnc för att jämföra mot variabeln för antalet linjekort och inkremen-tera värdet förc i varje iteration. Här används återigen sqlite3 för att häm-ta linjekortens IP adress i de fallen där ID och nodens IP överrensstämmer med variablerna för detta [13].
Efter detta startar ettexpect-script med sökvägen för expect och flaggan -f för att ange att den ska läsa kommandon från en fil [20]. Denna fil kom-mer visas sedan och liknar tidigare dialog för telnet. Detta script tar fyra argument där det första är användarnamnet, följt av nodens IP adress uti-från variabeln, lösenordet för användaren och linjekortets IP adress utiuti-från variabeln.
för att kunna behandlas av ett annat program [19], i detta fall används tr med flaggan -d för att radera oönskade tecken [27]. Slutligen omdirigeras även detta vidare till awk som hämtar rätt fält från raden [22]. Allt detta sker i en variabel så att denna variabel sedan kan divideras med antalet ”timeticks” för att få ut upptiden i både dagar och timmar. Dessa variabler förs sedan in i databasen genom att användasqlite3 "UPDATE INVENTORY2 SET" för att endast uppdatera tabellen med det nya innehållet [13].
Sedan användsrm för att radera den tillfälliga loggfilen [28], samt att värdet på variabelnID inkrementeras med 1. Slutligen stängs även de båda loopar-na meddone.
Nedan följerexpect-scriptet som används för att ansluta via ssh och hämta ut upptiden. För fullständig kod se bilaga C. Förklaringar följer efter scrip-tet:
1 #!/usr/bin/expect 2 set timeout 10
3 set user [lindex $argv 0] 4 set nodeip [lindex $argv 1] 5 set password [lindex $argv 2] 6 set cardip [lindex $argv 3] 7 #exp_internal 1
8 log_user 1
9 spawn ssh -o StrictHostKeyChecking=no $user@$nodeip 10 expect "assword: "
11 send "$password\r"
12 log_file -a tempUptime.log 13 expect -re {[../#|# ]}
14 send -- "snmpget -v 2c -c public -Ov $cardip
1.3.6.1.2.1.1.3.0\r"
,→
15 expect "Timeticks" 16 expect -re {[../#|# ]} 17 send "exit\r"
Inledningsvis anges sökvägen tillexpect som skall tolka resterande kom-mandon. En timeout sätts med ett värde på 10 sekunder så att scriptet av-bryts efter den tiden om något oväntat uppstår.
Sedan anges fyra stycken variabler som tar argument direkt när komman-dot körs [20]. För felsökning användsexp_internal 1 och log_user 1 [20]. Efter detta använderexpect sig utav spawn för att starta en session via ssh med de tidigare variablerna som argument[20].
Likt tidigare medTelnet använder sig expect utav expect för att förvänta sig utdata i dialogen ochsend för att skicka svar på detta [20].
För att spara resultaten från noden på den lokala servern användslog_file och flaggan-re används för att förvänta sig reguljära uttryck [20].
För att hämta upptiden användssnmpget med parametrar för version och med linjekortens IP adress utifrån variabel mot korrekt OID [25].
4.3.1
Tidiga tester
Tidigare tester i laborationsmiljön utgick ifrån separata ssh 'snmpget' för att hämta upptiden i en variabel för dagar och en för timmar.
Tester visade att exekveringstiden kunde halveras genom att endast köra en ssh 'snmpget' och sedan utföra beräkningarna lokalt för respektive varia-bel.
4.4
Urval av linjekort för omstart
Detta script använder informationen från databasen för att göra ett urval av linjekorten med högst upptid för att skriva nödvändig information till en omstartsfil. Denna omstartsfil läser sedan Telias script för omstart ifrån. För fullständig kod se bilaga D. Nedan följer koden som används med förkla-ringar efter stycket:
1 sqlite3 databas.db "SELECT NODEIP, SID FROM INVENTORY2 WHERE
COMPONENT NOT IN ('ECN330', 'ESN212', 'ECN320') ORDER BY UPTIME_DAYS DESC LIMIT 3;" | sed 's/|/;/g' >>
restartFile.txt
,→ ,→ ,→ 2
3 sqlite3 databas.db "UPDATE INVENTORY2 SET UPTIME_DAYS =
"0.1337", UPTIME_HOURS = "0.1337" WHERE COMPONENT NOT IN ('ECN330', 'ESN212', 'ECN320') ORDER BY UPTIME_DAYS DESC LIMIT 3;"
,→ ,→ ,→
Inledningsvis användsSELECT för att välja ut nödvändiga celler från data-basen [13], i detta fall hämtas från kolumnernaNODEIP och SID. För att fil-trera bort upplänkar användsWHERE COMPONENT NOT IN där komponenten för upplänkarna filtreras ut [13]. Urvalet sorteras utefter högst upptid i da-gar i fallande ordning genom användandet avORDER BY och kolumnen som innehåller värdet för upptiden i dagar [13]. Urvalet begränsas genom att användaLIMIT vilket i testfallen har varit 3 linjekort, något som kan ändras utefter behov.
program [19]. Programmet som tar emot urvalet ärsed som ersätter skilje-tecknet till ett semikolon[4], eftersom det är detta format scriptet för omstart önskar. Utdatan från detta bifogas till filen genom användandet av[19]. Sedan används en snarlik rad för att göra samma urval, men i detta fall uppdateras innehållet i två av kolumnerna med användandet avUPDATE och SET[13]. Detta för att urvalet inte skall användas igen ifall scriptet för urval exekverar innan scriptet för upptid har hunnit exekvera.
4.5
Loggning och felhantering
För att kunna felsöka och upptäcka problem krävs viss funktionalitet för loggning. Funktionaliteten för att skriva till loggfilen är liknande, i grun-den skrivs information dit och i vissa särskilda fall skrivs felmeddelangrun-den till loggfilen. För fullständig kod se bilaga A, B samt D. Nedan följer hur loggfilen definieras och förklaringar följer efter stycket:
1 DATE=`date "+%Y-%m-%d %H:%M:%S"` 2 LOG="/var/log/xdslRestarter.log"
Inledningsvis definieras en variabel som använder utdatan från komman-dotdate för att få ut dagens datum och klockslag enligt önskat format[30]. På liknande sätt anges att variabeln LOG är den absoluta sökvägen till vart loggfilen befinner sig.
Nedan följer ett exempel på hur information skrivs till loggfilen med förkla-ring efter stycket:
1 echo "[$DATE] [inventoryPoller] INFO: Connecting to node
$nodeIp getting inventory" >> $LOG
,→
Kommandot echo används för att skriva ut variablerna tillsammans med texten med informationen [24]. Detta omdirigeras sedan med för att bifo-gas till variabeln för loggfilen [19].
1 ping -c 1 $nodeIp 2 status=$?
3 if [ $status -ne 0 ]; then
4 echo "[$DATE] [inventoryPoller] ERROR: Could not
ping $nodeIp, skipping" >> $LOG
,→
5 continue
6 fi
Först används ping -c 1 för att skicka en ICMP ECHO REQUEST till nodens IP adress [31]. Sedan deklareras en variabel som tar värdet ifrån en inbyggt bash-variabel, nämligen statuskoden för föregående kommando [19]. Detta används sedan i en villkorssats så om statusen ger en annan statuskod än att den har lyckats så loggas detta och loopen avslutas för aktuell IP adress [19]. Förenklat testar den alltså att pinga noden, om noden inte svarar så går den vidare till nästa nod och genomför samma test.
Nästa form av felhantering är en funktion med villkorssatser som hanterar flertalet eventuella fel genom att kontrollera statuskoden och skriva detta till loggfilen. Eftersom varje script är skrivet i en separat funktion behöver denna funktion för felhantering nästlas i den funktionen. Anledningen till detta är att annars agerar den bara på statuskoden för funktionen och inte de separata statuskoden för varje kommando i funktionen [32]. Nedan följer funktionen för felhantering med förklaring efter stycket:
1 trap 'catch $? $LINENO' ERR 2 catch()
3 {
4 if [ $1 -eq 255 ]; then
5 echo "[$DATE] [uptimePoller] ERROR: Could not
resolve $nodeIp" >> $LOG
,→ 6
7 elif [ $1 -eq 127 ]; then
8 echo "[$DATE] [uptimePoller] ERROR: Command not
found on line $2" >> $LOG
,→ 9
10 else
11 echo "[$DATE] [uptimePoller] ERROR: Error $1 occured
on line $2" >> $LOG
,→
12 fi
13 }
linje-nummer[19]. Sedan användsERR för att endast fånga upp felen och status-koderna [33].
Sedan följer funktionen som använder sig utav villkorssatser där jämförelse sker utifrån kommandot och statuskoden genom att använda specialvaria-beln$1[19]. När en eventuell matchning uppstår skrivs sedan felmeddelan-det till loggfilen. De två första villkoren jämförs mot två specifika statusko-der, medans den tredje är en mer övergripande felhantering.
4.6
Implementation
För att automatisera körningen av scripten kan tjänstencron användas för att exekvera schemalagda kommandon [34]. Denna tjänst läser i sin tur från crontab som agerar som en lista med schemalagda kommandon för varje användare [35]. Innan scripten läggs i crontab behöver dessa göras exe-kverbara, vilketchmod kan användas för [36].
Nedan följer exempel på hur exekveringsflaggan sätts för scriptfilerna följt av förklaringar efter stycket:
1 chmod +x inventoryPoller.sh 2 chmod +x uptimePoller.sh
3 chmod +x /home/edvard/scripts/ssh.exp
4 chmod +x /home/edvard/scripts/decideRestart.sh
I de två första exemplen används relativa sökvägar tillsammans med flag-gan+x för att sätta exekveringsflaggan för filen [36]. I de två senare exemp-len används samma flagga, men istället absoluta sökvägar om användaren inte står i samma katalog som scripten.
För att schemalägga dessa script används crontab -e för att redigera för den aktuella användaren med förvald textredigerare [35]. Nedan följer ex-empel på rader tillagda i schemaläggningen för scripten följt av förklaringar efter stycket: 1 0 0 1 * * /home/lar285/edvardExjobb/./inventoryPoller.sh && /home/lar285/edvardExjobb/./uptimePoller.sh ,→ 2 0 0 * * SUN /home/lar285/edvardExjobb/./uptimePoller.sh 3 0 0 * * * /home/lar285/edvardExjobb/./decideRestart.sh
även upptiden inventeras eftersom scriptet för urval är beroende av att det finns upptider i databasen.
Andra raden schemalägger att scriptet för inventering av upptiden skall exekvera vid midnatt varje söndag [35]. Detta eftersom informationen om upptid inte behöver vara dagsfärsk för att göra ett urval eftersom scriptet för det nollställer urvalet i databasen.
5
Resultat
Denna sektion presenterar och beskriver resultaten.
5.1
Kringå CLI_application.sh
Applikation CLI_application.sh startar så fort en användare loggar in i no-den, såvida inte root-kontot används. Även vid användande avSSH för an-slutning går det inte att skicka med kommandon som argument eftersom CLI_application.sh inte tar några argument. Av denna anledning blevexpect ett krav för att kunna logga in och exekvera kommandon i noderna automa-tiskt för inventering.
5.2
Inventering av linjekort
Manuell exekvering av scriptetinventoryPoller.sh mot 10 stycken noder resulterar i att databasen populerades. Detta går att se i figur fem för tabel-len INVENTORY1 och i figur sex för INVENTORY2. Observera att viss data är censurerad.
Figur 6: Tabellen INVENTORY2 efter manuell exekvering av scriptet inven-toryPoller.sh mot 10 noder.
5.3
Inventering av upptid
Figur 7: Tabellen INVENTORY2 efter manuell exekvering av scriptet upti-mePoller.sh mot de 10 nodernas 327 linjekort.
5.4
Medelvärden upptid
Figur 8: Mätning av upptid innan och efter manuell exekvering av scrip-ten för inventering, upptid, urval och omstart. Totalt valdes 3 linjekort ut i urvalet vilka senare startades om av scriptet för omstart.
5.5
Mätning av exekveringstid
Mätningen av exekveringstiden av den manuella körningen av scripten inventoryPoller.sh samt uptimePoller.sh används för att estimera totala exekveringstiden för samtliga noder respektive linjekort i nätverket. Dessa resultat och beräkningar kan ses i figur nio för noderna samt i figur tio för linjekorten.
5.5.1
inventoryPoller.sh
Figur 9: Mätning av exekveringstid för scriptet inventoryPoller.sh mot 10 noder.
Medelvärde för inventering av linjekort per nod: (5∗60+24, 764)/10 =32, 4764 sekunder per nod.
Uppskattad exekveringstid för samtliga noder:
5.5.2
uptimePoller.sh
Figur 10: Mätning av exekveringstid för scriptet uptimePoller.sh mot 327 linjekort.
Medelvärde för inventering av upptiden per linjekort: (6∗60+30, 426)/327 =1, 1939 sekunder per linjekort.
Uppskattad exekveringstid för samtliga linjekort:
5.6
Loggning
Resultaten utifrån manuell exekvering efter tillagd funktionalitet för logg-ning kan ses i figur elva. Observera att viss data är censurerad.
Figur 11: Urval från loggfilen.
5.7
Felhantering
Manuell exekvering mot en lista av noder där ena noden var avstängd re-sulterade i att scriptet inte kraschade längre utan gick vidare till nästa nod. Detta framgår även av loggfilen i figur tolv. Observera att viss data är cen-surerad.
Manuell exekvering av scriptet för insamling av upptid där ena linjekortet inte returnerade upptiden resulterade i att scriptet inte kraschade längre utan fortsatte inventera nästa linjekort. Detta framgår även i loggfilen i figur tretton. Observera att viss data är censurerad.
6
Diskussion
Denna sektion kommer ge författaren möjlighet att problematisera kring projektet och dess genomförande.
6.1
Implementationen
Till följd av tidsbrist har implementationen inte hunnits genomföras. Inte för att schemaläggningen är tidskrävande att implementera utan för att ex-ekveringstiden för scripten bedöms vara såpass tidskrävande att detta inte hade hunnit generera några resultat inom tidsramen för projektet.
6.2
Mätningarnas tillförlitlighet
Mätningen av medelvärdet för upptiden fungerar mestadels som ett be-vis för att scripten fungerar i relation till varandra. En osäkerhet i denna mätning är att tekniker eller driftpersonalen kan starta om berörda linjekort delaktiga i detta test. Denna sannolikhet är ganska låg men vore teoretiskt möjlig. För att säkerställa att så inte var fallet kontrollerades att just de linje-korten som var valda för omstaret också faktiskt var dessa som förändrades i databasen.
Angående mätningen av exekveringstid så innehåller den en rad försvåran-de omständigheter. Samtliga noförsvåran-der och linjekort som inventeraförsvåran-des befann sig i Umeå, där även testet gjordes ifrån. Svarstider och hastighet kan skilja sig något baserat på avstånd, speciellt om det är störningar i en stad eller om paket tvingas att processeras flera gånger. För ett mer precist medelvär-de hamedelvär-de nomedelvär-derna kunnat spridas geografiskt över lanmedelvär-det.
En större osäkerhet kring medelvärdet är att totala antalet noder i testet var tvunget att begränsas till 10 stycken. Ett betydligt högre urval hade kun-nat resultera i ett mer pricksäkert medelvärde, eller om tiden finns att mäta exekveringstiden för att inventera samtliga noder i nätverket.
En annan faktor som kan påverka resultatet är fördelningen mellan VD och BD-noder i testet. I testet som genomfördes var 6 stycken av noderna BD no-der medans 4 stycken var VD nono-der. Skillnano-derna i dessa är att VD-nono-derna är nyare, snabbare och bättre utrustade hårdvarumässigt. Samtidigt är VD-noderna bestyckade med större antal linjekort än BD-VD-noderna vilket kan påverka tiden det tar att inventera linjekortens upptid. I nätverket är VD-noder dock en majoritet över BD-VD-noderna, där ett test som bättre återspeglar detta hade kunnat ge andra medelvärden.
i exekveringstid.
Mätningarna av exekveringstid ger dock en fingervisning om tiden det kan ta att inventera samtliga noder, något som kan vara användbart när scripten skall schemaläggas i relation till varandra.
6.3
Etiska aspekter
I enlighet med önskemål från uppdragsgivaren har vissa känsliga uppgif-ter maskerats eller ersatts av andra värden. Detta gäller IP adresserna för åtkomst till noderna samt adresserna till linjekorten. Utöver detta har även lösenord utelämnats och ersatts med andra värden.
Denna typ av automation kommer med ett antal etiska aspekter som bör ställas mot varandra. Övergripande finns det fyra intressenter som berörs av dessa script. Dessa är följande:
1. Telia
2. Driftpersonal 3. Tekniker 4. Kunder
För Telia finns möjligheten att effektivare använda sina resurser och att läg-ga mindre penläg-gar på att skicka tekniker. Denna effektivisering kan ställas i relation till att både tekniker och driftpersonal får en minskad arbetsbör-da, vilket kan leda till minskat behov av dessa. Samtidigt behöver varken driftpersonal eller tekniker lägga lika stor tid på felsökning av denna typ av fel, varav denna tid kan spenderas på åtgärder av andra fel eller andra arbetsuppgifter.
Kunderna som berörs av detta kan komma att tappa upptid vid schemalägg-ning av omstart vilket kan upplevas negativt. Samtidigt kommer kunden få minskade problem med anslutningen och hastigheten, vilket gör att kund inte behöver felanmäla upplevda fel.
7
Slutsatser
Denna sektion avhandlar slutsatserna som kan dras utifrån resultaten samt visar på förbättringsområden för framtiden.
7.1
Resultaten
Resultatet av projektet visar att det är fullt möjligt att skriva script för att automatisera inventering av noders linjekort, även att inventera linjekortens upptid och kunna fatta beslut om urval för omstart. Det krävs dock en viss anpassning utefter enheternas förmågor och begränsningar.
7.2
Förbättringsområden
Även om scripten fungerar i sin nuvarande form finns det flera åtgärder som kan förbättra dessa.
Loggrotering:
Samtliga script skriver för närvarande till en enda loggfil genom att bifo-ga nya rader. Eftersom det kommer infobifo-gas en större mängd rader när in-venteringen kommer igång på nätverket borde någon form av loggrotering implementeras. Exempelvis genom att varje dag komprimera loggen till ett arkiv och sedan radera arkiv efter ett visst antal dagar.
Effektivisering:
Scripten agerar i nuläget sekventiellt och förebyggande. Detta hade kunnat effektiviseras genom att parallellisera scripten så att flera noder och linjekort bearbetas samtidigt för att minska exekveringstiden.
Dessutom upprättas i dagsläget en session viaSSH för att inventera linjekor-tens upptid genom att användasnmpget. Ett effektivare sätt att lösa detta på vore att endast upprätta en anslutning per nod och för varje linjekort utföra ensnmpget, för att sedan bearbeta utdatan in i databasen.
Stabilisering:
Källförteckning
[1] Digital Subscriber Line (DSL). Accessed: 2020-04-06. URL: https : / /
networkencyclopedia.com/digital-subscriber-line-dsl/ (se s. 4).
[2] line card. Accessed: 2020-05-03.URL:https://www.pcmag.com/encyclopedia/
term/line-card (se s. 4).
[3] Richard Blum och Christine Bresnahan. Linux Command Line and Shell Scripting Bible. 3. utg. 10475 Crosspoint Boulevard Indianapolis, IN 46256: John Wiley & Sons Inc, 2015.ISBN: 9781118983843 (se s. 5–8).
[4] Jay Fenlason, Tom Lord, Ken Pizzini m. fl. SED(1) User Commands. 2018 (se s. 6, 24, 29).
[5] Don Libes. Exploring Expect. A Tcl-based Toolkit for Automating Interacti-ve Programs. O’Reilly Media, Inc., 1995. ISBN: 976-1-56592-090-3 (se
s. 8, 9).
[6] R Douglas Mauro och J Kevin Schmidt. Essential SNMP. 2. utg. 1005 Gravenstein Highway North, Sebastopol, CA 95472: O’Reilly Media, Inc., 2005.ISBN: 9780596008406 (se s. 9, 10).
[7] J. Glenn Brookshear och Dennis Brylow. Computer Science: An Overvi-ew. 12, global edition. Harlow: Pearson Education, 2015. ISBN:
978-1-292-06116-0 (se s. 10–12).
[8] J. Postel och J. Reynolds. TELNET PROTOCOL SPECIFICATION. Ac-cessed: 2020-04-18. 1983. URL: https : / / tools . ietf . org / html /
rfc854 (se s. 10).
[9] Telnet - and SSH as a Secure Alternative. Accessed: 2020-04-18. URL:
https://www.ssh.com/ssh/telnet (se s. 10).
[10] Evi Nemeth, Garth Snyder, Trent R. Hein m. fl. UNIX and Linux system administration handbook. 5th ed. Upper Saddle River, NJ: Prentice Hall, 2011. ISBN: 978-0-13-427755-4 (pbk. : alk. paper) (se s. 10, 11).
[11] What Is a Database? Accessed: 2020-04-18.URL:https://www.oracle. com/database/what-is-database.html (se s. 11, 12).
[12] About SQLite. Accessed: 2020-04-19.URL:https://sqlite.org/about.
html (se s. 12).
[13] Andreas Rottman, Bill Bumgarner och Laszlo Boszormenyi. SQLITE3(1) General Commands Manual. 2014 (se s. 12, 22, 25–29).
[14] Markus Borgenstrand. Network Automation – the power of Ansible. Ac-cessed: 2020-03-19. 2018. URL: https : / / miun . diva - portal . org / smash/get/diva2:1228644/FULLTEXT01.pdf (se s. 12).
[15] TIME(2) Linux Programmer’s Manual. 2017 (se s. 19).
[17] Jason Gunthorpe. APT-GET(1) APT. 2018 (se s. 22).
[18] Torbjorn Granlund och Richard Stallman. CAT(1) User Commands. 2018 (se s. 23).
[19] Brian Fox och Chet Ramey. BASH(1) General Commands Manual. 2016 (se s. 23, 25, 27, 29–31).
[20] Don Libes. EXPECT(1) General Commands Manual. 1994 (se s. 24, 26– 28).
[21] Mike Haertel och Paul Eggert. SORT(1) User Commands. 2019 (se s. 24). [22] Alfred Aho, Peter Weinberger, Brian Kerningham m. fl. GAWK(1)
Uti-lity Commands (se s. 25, 27).
[23] READ(2) Linux Programmer’s Manual. 2018 (se s. 25).
[24] Brian Fox och Chet Ramey. ECHO(1) User Commands. 2018 (se s. 25, 29).
[25] SNMPGET(1) Net-SNMP. 2007 (se s. 25, 28). [26] GREP(1) User Commands. 2017 (se s. 26).
[27] Jim Meyering. TR(1) User Commands. 2019 (se s. 27).
[28] Paul Rubin, David MacKenzie, Richard Stallman m. fl. RM(1) User Commands (se s. 27).
[29] SSH(1) BSD General Commands Manual. 2018 (se s. 27). [30] David MacKenzie. DATE(1) User Commands. 2019 (se s. 29). [31] PING(8) System Manager’s Manual: iputils. 2019 (se s. 30).
[32] Dirk Avery. The Bash Trap Trap. Accessed: 2020-05-16. 27 febr. 2019.
URL: https://medium.com/@dirk.avery/the- bash- trap-ce6083f36700 (se s. 30).
[33] BASH-BUILTINS(7) Miscellaneous Information Manual. 2001 (se s. 30, 31).
[34] Paul Vixie. CRON(8) System Manager’s Manual. 2010 (se s. 31).
[35] Paul Vixie. CRONTAB(1) General Commands Manual. 2010 (se s. 31, 32). [36] David MacKenzie och Jim Meyering. CHMOD(1) User Commands. 2019
A
inventoryPoller.sh
1 #!/bin/bash
2 DATE=`date "+%Y-%m-%d %H:%M:%S"` 3 LOG="/var/log/xdslRestarter.log" 4 inventoryPoller()
5 { 6
7 trap 'catch $? $LINENO' ERR 8 catch()
9 {
10 if [ $1 -eq 255 ]; then
11 echo "[$DATE] [inventoryPoller] ERROR: Could not
resolve $nodeIp" >> $LOG
,→ 12
13 elif [ $1 -eq 127 ]; then
14 echo "[$DATE] [inventoryPoller] ERROR: Command not
found on line $2" >> $LOG
,→ 15
16 else
17 echo "[$DATE] [inventoryPoller] ERROR: Error $1
occured on line $2" >> $LOG
,→
18 fi
19 } 20
21 sqlite3 databas.db "DELETE FROM INVENTORY1;"
22 sqlite3 databas.db "DELETE FROM sqlite_sequence where
name='INVENTORY1';"
,→ 23
24 for nodeIp in $(cat vdc.txt ) 25 do
26
27 ping -c 1 $nodeIp 28 status=$?
29 if [ $status -ne 0 ]; then
30 echo "[$DATE] [inventoryPoller] ERROR: Could not
ping $nodeIp, skipping" >> $LOG
,→ 31 continue 32 fi 33 34 /usr/bin/expect << EOF 35 log_user 1 36 set timeout 20
38 expect "login:" 39 send "user\r" 40 expect "assword: " 41 send "password\r" 42 exec sleep 3 43 send -- "\r" 44 send -- "a\r" 45 send -- "\r" 46 expect -re {[../#|# ]} 47 send -- "\r" 48 send -- "\r" 49 expect -re {[../#|# ]}
50 log_file -a -noappend logfile_temp
51 expect -re "(\\\$ |# )" { send "show ecn inventory\r" } 52 expect -re "\r\n(.*)\r(.*)(\\\$ |# )"
53 expect -re "(\\\$ |# )" { send "show ecn inventory\r" } 54 expect -re "\r\n(.*)\r(.*)(\\\$ |# )"
55 log_file
56 expect -re {[../#|# ]} 57 send "exit\r"
58 EOF
59 echo "[$DATE] [inventoryPoller] INFO: Connecting to
node $nodeIp getting inventory" >> $LOG
,→
60 sed -i '/^\./d' logfile_temp
61 sed -i '/^[[:space:]]*$/d' logfile_temp 62 sed -i '/^[A-Za-z]/d' logfile_temp 63 sort -u logfile_temp -o logfile_temp 64
65 awk -v ip="$nodeIp" '{print $1,$3,ip,$5}' logfile_temp >
parsedinventory.txt
,→ 66
67 while IFS= read -r line
68 do
69 sid=$(echo $line | awk '{print $1}' )
70 component=$(echo $line | awk '{print $2}' ) 71 nodeip=$(echo $line | awk '{print $3}' ) 72 cardip=$(echo $line | awk '{print $4}' ) 73
74 sqlite3 databas.db "INSERT INTO
INVENTORY1(SID,COMPONENT,NODEIP,CARDIP) VALUES ('$sid','$component','$nodeip','$cardip');"
,→ ,→
75 echo "[$DATE] [inventoryPoller] ADDED: $nodeip $sid
$component $cardip to database" >> $LOG
,→
77
78 done
79 sqlite3 databas.db "INSERT OR REPLACE INTO INVENTORY2 SELECT
* FROM INVENTORY1;"
,→
80 echo "[$DATE] [inventoryPoller] INFO: Updating tables" >>
$LOG
,→ 81 } 82
B
uptimePoller.sh
1 #!/bin/bash
2 DATE=`date "+%Y-%m-%d %H:%M:%S"` 3 LOG="/var/log/xdslRestarter.log" 4 uptimePoller()
5 { 6
7 trap 'catch $? $LINENO' ERR 8 catch()
9 {
10 if [ $1 -eq 255 ]; then
11 echo "[$DATE] [uptimePoller] ERROR: Could not
resolve $nodeIp" >> $LOG
,→ 12
13 elif [ $1 -eq 127 ]; then
14 echo "[$DATE] [uptimePoller] ERROR: Command not
found on line $2" >> $LOG
,→ 15
16 else
17 echo "[$DATE] [uptimePoller] ERROR: Error $1 occured
on line $2" >> $LOG ,→ 18 fi 19 } 20 21 ID=1
22 rows=$(sqlite3 databas.db "SELECT COUNT(*) FROM
INVENTORY2;")
,→ 23
24 for ((i = 1; i <= $rows; i++)) 25 do
26 nodeIp=$(sqlite3 databas.db "SELECT NODEIP FROM
INVENTORY2 WHERE ID=$ID;")
,→
27 cardsNum=$(sqlite3 databas.db "SELECT COUNT(CARDIP) FROM
INVENTORY2 WHERE NODEIP='$nodeIp';")
,→
28 echo "[$DATE] [uptimePoller] INFO: $nodeIp contains
$cardsNum linecards" >> $LOG
,→ 29
30 for (( c = 1; c <= cardsNum; c++))
31 do
32 cardIp=$(sqlite3 databas.db "SELECT CARDIP FROM
INVENTORY2 WHERE NODEIP='$nodeIp' AND ID=$ID;")
34 /usr/bin/expect -f ssh.exp username $nodeIp password
$cardIp
,→
35 echo "[$DATE] [uptimePoller] INFO: Connecting to
node $nodeIp running snmpget on linecard
$cardIp" >> $LOG
,→ ,→ 36
37 ticks=`grep Timeticks tempUptime.log | tr -d '()' |
awk '{print$2}'`
,→ 38
39 if [ ! -n "$ticks" ]; then
40 echo "[$DATE] [uptimePoller] ERROR: Could not
get timeticks for $nodeIp linecard $cardIp"
>> $LOG ,→ ,→ 41 upDays="NULL" 42 upHours="NULL" 43 else 44 upDays=$(($ticks / 8640000)) 45 upHours=$(($ticks / 360000)) 46 fi 47
48 sqlite3 databas.db "UPDATE INVENTORY2 SET
UPTIME_DAYS = $upDays,UPTIME_HOURS = $upHours
WHERE ID=$ID;"
,→ ,→
49 echo "[$DATE] [uptimePoller] ADDING: Node $nodeIp
C
ssh.exp
1 #!/usr/bin/expect 2 set timeout 10
3 set user [lindex $argv 0] 4 set nodeip [lindex $argv 1] 5 set password [lindex $argv 2] 6 set cardip [lindex $argv 3] 7 #exp_internal 1
8 log_user 1
9 spawn ssh -o StrictHostKeyChecking=no $user@$nodeip 10 expect "assword: "
11 send "$password\r"
12 log_file -a tempUptime.log 13 expect -re {[../#|# ]}
14 send -- "snmpget -v 2c -c public -Ov $cardip
1.3.6.1.2.1.1.3.0\r"
,→
D
decideRestart.sh
1 #!/bin/bash
2 DATE=`date "+%Y-%m-%d %H:%M:%S"` 3 LOG="/var/log/xdslRestarter.log" 4
5 decideRestart() 6 {
7 sqlite3 databas.db "SELECT NODEIP, SID FROM INVENTORY2 WHERE
COMPONENT NOT IN ('ECN330', 'ESN212', 'ECN320') ORDER BY UPTIME_DAYS DESC LIMIT 3;" | sed 's/|/;/g' >>
restartFile.txt
,→ ,→ ,→ 8
9 sqlite3 databas.db "UPDATE INVENTORY2 SET UPTIME_DAYS =
"0.1337", UPTIME_HOURS = "0.1337" WHERE COMPONENT NOT IN ('ECN330', 'ESN212', 'ECN320') ORDER BY UPTIME_DAYS DESC LIMIT 3;"
,→ ,→ ,→
10 echo "[$DATE] [decideRestart] INFO: Sending cards to
