Neljännet tehtävät – julkisen virtuaalipalvelimen ja domain-nimen vuokraaminen ja käyttö

Aikaisemmista viikoista poiketen suurimman osan tämän viikon tehtävistä teimme jo edellisen oppitunnin aikana. Tästä syystä teen tällä kertaa raportointini suurimmaksi osaksi muistinvaraisesti. Ehdin jo ennen tehtävien lukemista hankkia omalle domainilleni SSL-sertifikaatinkin, ja huomasin vasta myöhemmin sen kuuluvan vapaaehtoisiin tehtäviin. Tämän viikon tehtävät eivät myöskään etene mielestäni missään erityisessä järjestyksessä, joten normaalien tehtävänumeroiden (tai kirjainten) sijasta käytän kuvaavampia väliotsikoita.

Virtuaalipalvelimen vuokraaminen ja käyttöönotto

Virtuaalipalvelimen vuokraaminen on kätevää ja kannattavaa, mikäli haluaa saada omaa sisältöään, kuten kotisivut, nettiin. Korvaava vaihtoehto voisi olla esimerkiksi oman palvelinkoneen kasaaminen ja sen kotona pyörittäminen. Tämä kuitenkin vaatii jonkinlaista rautapuolen osaamista sekä isompaa alkuinvestointia. Tämän lisäksi palvelimen on koko ajan oltava nettiyhteyden päässä ja sähköpistokkeessa kiinni. Tällaisessa tapauksessa esimerkiksi satunnainen sähkökatkos tai koneen rikkoutuminen johtaisivat siihen, etteivät vierailijat pääsisi kotisivulle normaaliin tapaan. Virtuaalipalvelimia vuokraavilla tahoilla puolestaan on omistuksessaan valtavia palvelinsaleja, joiden turvallisuudesta huolehditaan, ja esimerkiksi raudan rikkoutuessa palvelimen käyttäjän ei tarvitse itse ratkaista tilannetta.

Oman palvelimeni vuokrasin DigitalOceanilta, joka kutsuu omia virtuaalipalvelimiaan dropleteiksi. Palvelimen vuokraaminen edellyttää tunnusten luomista ja joko korttitietojen antamista tai Paypal-tunnusten käyttöä. Itse olen opiskelija, joten aktivoin aluksi oman Github Education Pack:ini, jonka mukana tulee mm. viidenkymmenen dollarin kuponki DigitalOceanin sivuille. Tämän kertaluontoisen kupongin saa aktivoitua syöttämällä annetun koodin DigitalOceanin sivuilla olevan Account-välilehden Billing-kohtaan. Kortiltani ei siis velotettu vuokraamisen yhteydessä mitään, vaan maksu otettiin saamastani saldosta.

Education Packia hakiessani täytin lomakkeen, jossa kysyttiin mm. valmistumisvuottani, ja sitä, missä opiskelen. Täytin lomakkeen mielestäni kokonaan, mutta olinkin vahingossa jättänyt yhden kentän tyhjäksi. Yrittäessäni lomakkeen lähetystä sain virheilmoituksen tyhjästä kentästä, ja kyseisen kentän täytettyäni lähetin lomakkeen uudestaan. Samalla sekunnilla kuin painoin lähetyspainiketta huomasin, että esimerkiksi valmistumisvuoteni oli vaihtunut valitsemastani vuodesta 2020 takaisin vuoteen 2019. En tiedä, saako aikaa jatkettua enää myöhemmin, joten halusin mainita tämän törttöilyni varoituksena muille. Olen ilmeisesti liian tottunut siihen, että yleensä virheilmoituksen saamisen yhteydessä virheettömästi täytetyt kentät eivät palaudu oletusarvoihinsa.

Tietojen syöttämisen jälkeen oli aika siirtyä itse palvelimen luomiseen valitsemalla DigitalOcean-sivun yläpalkista create -> new droplet. Suurin osa oletusasetuksista oli ihan käypää kamaa, mutta muutamia asioita muutimme. Käyttöjärjestelmäksi valitsimme jo itsellemme tutun Ubuntu 18.04.01:n ja automaattisesti ehdotetun koon vaihdoimme pienimpään mahdolliseen, sillä pienempi tila riittää peruskäyttöön aivan hyvin ja tarpeen tullessa sitä on helppo hankkia lisää. Datacenterin sijainniksi oli mielekästä valita Frankfurt, sillä ainoa toinen Euroopassa sijaitseva vaihtoehto on Lontoo, ja Brexit-sekoilut kannattaa ottaa tässä tilanteessa huomioon varmuuden vuoksi. Hostname-kohtaan kannattaa valita esimerkiksi jokin yksinkertainen sana. Tämä hostname tulee näkymään esimerkiksi terminaalissa silloin kun olet ottanut SSH-yhteyden kyseiseen palvelimeen. Omaksi host-nimekseni valitsin horsman, sillä se oli edesmenneen kotikoneeni nimi, ja nyt minulle tuli mahdollisuus pitää horsman muisto elossa :D Itselläni näkyisi terminaalissa siis helkera@horsma.

Sen jälkeen kun asetukset on saatu kuntoon, klikataan create-painiketta. Rekisteröityessä käytettyyn sähköpostiin ilmestyy tämän jälkeen viesti, jossa on luodun palvelimen tiedot, esimerkiksi yhteyden muodostamiseen tarvittava root-salasana. Palvelimen käyttöönottoon liittyvät hyvät ohjeet löytyvät opettajamme kotisivuilta, joten en itse kerro kyseisestä prosessista tässä kirjoituksessa. Ohjeissa ei käydä läpi Apachen asentamista, mutta sen taas tein edellisessä päivityksessäni, jossa kerron myös, miten käyttäjille myönnetään Apache-moduulin käyttöoikeus kotihakemistoon. Virtuaalipalvelimelle tein nämä asiat aivan samalla tavalla, joten en kuvaa prosessia enää tässä uudestaan.

Domain-nimen vuokraaminen

Kuten ylempänä linkittämässäni ohjeessa sanotaan, hyviä paikkoja domain-nimen vuokraamiseen ja erilaisten nimien saatavuuden tutkimiseen ovat esimerkiksi Namecheap ja Gandi. Ilmeisesti näistä kahdesta Namecheap on hieman halvempi, ja sieltä vähemmän kysyttyjä vapaina olevia osoitteita vaikuttaa saavan hieman alle kympillä vuodessa. Opettajamme kehotti meitä tarkistamaan, olisiko oma sukunimemme vapaana .com-päätteisissä osoitteissa, sillä tämäntyyppisen domainin omistaja voisi luoda esimerkiksi etunimi@sukunimi.com -tyyppisiä sähköpostiosoitteita vaikka koko suvulle. Juuri .com -päätteiset sivut ovat niitä, joita kannattaa vuokrata, sillä .com on puheessa hyvin vakiintunut pääte, jonka ihmiset tunnistavat ja johon luotetaan.

Moni kurssilaiseni saikin varattua itselleen tämäntyyppisen osoitteen, mutta itseäni ei lykästänyt. Rehellisesti sanottuna olisin ollut äärimmäisen yllättynyt, jos huttunen.com -osoite olisi ollut vielä vapaana, sillä Huttunen on hyvin yleinen sukunimi. Itse en kuitenkaan kokenut tästä mitään erityistä pettymystä, sillä olen aina esiintynyt netissä vakiintuneella nimimerkilläni oikean nimeni sijasta, enkä nää erityistä syytä muuttaa tapojani tässä asiassa. Ehkä yritän alitajuisesti pitää nimimerkkikulttuuria elossa, haha.

Vuokraamisen jälkeen oli vuorossa domain-nimen yhdistäminen virtuaalipalvelimeen, jonka teimme sen tämän ohjeen mukaisesti. Oli hieman omituista, että kummatkin valmiista recordeista olivat turhia ja ne poistettiin ennen omien A recordien lisäämistä. Lopputulos oli, että meillä oli ensimmäisen A recordin hostina @ eli root domain ja toisen A recordin hostina www. Tämä mahdollistaa sen, että vierailija ohjautuu oikealle sivulle riippumatta siitä kirjoittaako hän osoitteen alkuun www vai ei.

Seuraavaksi loin uuden tiedoston kansioon /etc/apache2/sites-available komennolla

$ sudo nano helkera.conf

ja muokkasin sen sisällön seuraavanlaiseksi:

Tallennettuani tiedoston painamalla Ctrl + X ja valitsemalla Y ja Enter annoin myös komennon

  $ sudo a2ensite helkera.conf

, joka lisäsi saman tiedoston myös enabled sites -kansioon aktivoiden samalla sivun käyttöä varten. Seuraavaksi piti tietenkin luoda kuvan mukaiseen hakemistoon index.html -sivu ja käynnistää Apache2 uudestaan komennolla

 $ sudo systemctl restart apache2

Kotisivujen käyttö

Edeltävien toimenpiteiden jälkeen helkera.com-sivullani näkyy kotihakemistossani sijaitseva index.html-tiedosto, joka tässä tapauksessa sattuu edelleen olemaan rakas maskottini, ASCII-kala:

Oikeastaan tein aluksi uuden index.html-tiedoston palvelinkoneellani ja kopioin siihen vanhan koodin, mutta jostain syystä <pre> -tageista huolimatta kala levisi yhdeksi pitkäksi merkkijonoksi. Lopulta siirsin alkuperäisen sivun sellaisenaan palvelimelle scp-komennolla, minkä jälkeen kala näytti taas normaalilta itseltään. Tämän viikon tehtäviin kuuluu nimenomaan scp:llä tiedostojen palvelimelle siirtäminen, mutta myös php-sivun kokeilu, joten lyön nyt kaksi kärpästä yhdellä iskulla ja siirrän jonkin php-koodia sisältävän sivun palvelimelle scp:llä. Ensin minun kuitenkin pitänee asentaa palvelinkoneelle php ja mahdollistaa käyttäjille php:n ajaminen omista kotihakemistoistaan käsin. Kävin myös tämän prosessin läpi viime viikon tehtävien c -kohdassa, joten en käy sitä läpi enää tässä.

Tehtyäni omalla virtuaalikoneellani pienen php-sivun, jonka ideana on tulostaa kävijän IP-osoite, siirsin sen palvelinkoneelleni komennolla

$ scp ipaddr.php helkera@helkera.com:/home/helkera/public_html

Ja nyt helkera.com:ista löytyykin uusi sivu:

Kuvassa Geditissä auki oleva koodi on minun virtuaalikoneellani, sillä palvelinkoneella ei ole graafista käyttöliittymää, jota vaaditaan Geditin käyttöön. Epähuomiossa viime tunnilla yritin vanhasta tottumuksesta käyttää Gedittiä palvelinkoneella ja kun tajusin, ettei sitä ollut, ajattelin että äkkiäkös minä sen asennan. Tajusin virheeni vasta kun olin jo antanut apt-get install -komennon ja näin kun Ubuntu alkoi lataamaan noin tuhatta ja yhtä pakettia. Onneksi sain asennuksen keskeytettyä, mutta hetken aikaa olin hieman huolissani ja häpeissäni. Palvelinkoneellani on tosiaan sen verran vähän muistia, että graafisten ohjelmien pyörittämisessä ei ole mitään mieltä. Mutta kuten äsken demonstroin, on hyvin kätevää tehdä koodi Geditillä omalla koneella ja lähettää vasta valmis tiedosto palvelimelle scp:llä.

Murtautumisyrityksiä

Palvelimen pystyttämisestä lähtien olen tarkkaillut satunnaisesti /var/log -hakemistossa sijaitsevaa auth.log-tiedostoa. Komennolla

$ tail -f auth.log

saa helposti seurattua reaaliajassa lokiin tulevia uusia rivejä. Ja niitä muuten tulee tajuttomalla tahdilla. Opettajamme ei todellakaan liiotellut kun hän totesi, että heti kun palvelin on yhteydessä nettiin, siihen yritetään murtautua. Tahdista päätellen nämä yritykset tulevat todennäköisesti erilaisilta bottiverkoilta. Useimmiten botit yrittävät kirjautua root-käyttäjänä, mikä on juuri se syy, miksi root-käyttäjän salasana deaktivoitiin palvelimen pystytyksen yhteydessä. Mikäli ulkopuolinen taho onnistuisi kirjautumaan palvelimelleni root-käyttäjänä, seuraukset olisivat varmasti äärimmäisen ikävät.

Olen kuitenkin nähnyt bottien yrittävän myös muille tunnuksille kirjautumista. Admin-tunnuksia olen nähnyt muutaman kerran, mikä ei ole yllätys, mutta myös ihmisten nimiä vilahtelee auth.login epäonnistuneissa kirjautumisyrityksissä toisinaan. Selkeästi murtautumisyritykset ovat myös erilaisia päivästä riippuen. Ensimmäisenä iltana palvelimen pystyttämisen jälkeen kaikki kirjautumisyritykset, joiden lähteen tarkistin whois-komennolla, tulivat Venäjältä. Mielestäni erikoista oli se, että kaikissa saamissani whois-tulosteissa mainittiin yksittäisten ihmisten nimiä ja katuosoitteita. Päättelinkin, että nämä käyttäjät saattavat olla normaaleja ihmisiä, joiden koneille hakkerit ovat jollain tapaa päässeet ja heidän koneensa on liitetty osaksi jonkinlaista hyökkäyksiä tehtailevaa bottiverkkoa.

Siinä missä ensimmäisen illan venäläinen bottiverkko vaikutti yrittävän myös satunnaisille tunnuksille kirjautumista, tällä hetkellä auth.logiin tulee pelkkiä root-käyttäjään kohdistuvia kirjautumisyrityksiä ja vain muutamasta eri IP-osoitteesta. Toinen osoitteista kuuluu DigitalOceanille, josta itsekin palvelimeni vuokrasin, ja toinen Chinanetille:

Jos annan whois-komennossa oman palvelimeni IP-osoitteen, niin tuloste on samanlainen kuin ensimmäisessä kuvassa. Tämän illan murtautumisyrityksistä vastuussa olevat tahot ovatkin varmaan hyödyntäneet samaa palveluntarjoajan whois protectionia kuin minäkin. Olisi kyllä kiinnostavaa tietää, tulevatko yritykset useammalta eri koneelta vai vain yhdeltä.

Tähänastisen kokemukseni perusteella vaikuttaa myös, että tietyt vuorokaudenajat ovat suositumpia kuin muut mitä murtautumisen yrittämiseen tulee. Kerran tarkastelin auth.logia päivällä koulussa istuessani ja silloin uusia yrityksiä tuli melko harvakseltaan. Keskimääräisesti arvioisin, että noin muutaman minuutin välein, mutta välillä yritysen väliin saattoi jäädä viisikin minuuttia. Tämä on melko radikaali ero, kun vertaa tahtia tähän hetkeen. Kello on nyt 4.04 lauantain ja sunnuntain välisenä yönä, ja uusia yrityksiä auth.logiin tipahtelee n. 1-20 sekuntin välein, ja monesti yrityksiä tulee lähes kerralla useita peräkkäin.

TLS-sertifikaatin hankkiminen

Kun ensimmäisiä kertoja tarkastelin omia sivujani selaimella, kiinnitin huomiota siihen, ettei sivu ollut Chromen mielestä turvallinen. Pidin tätä hieman tylsänä, joten lähdin selvittämään, kuinka asian saisi muutettua. Päädyin opettajamme suosittelemalle Let’s Encrypt -sivustolle, jonka kautta löysin hyvältä vaikuttavat ohjeet sertifikaatin hankkimiseen. Ilmeisesti prosessi on nykyään automatisoitu, ja sisältää lähinnä certbot-ohjelman sekä oikeanlaisen pluginin lataamisen. Seurasin näitä ohjeita, ja koska olin vuokrannut palvelimeni DigitalOceanilta, oikeaan pluginiin liittyvät ohjeet löytyivät täältä.

Kohtasin kuitenkin asennuksen aikana ongelman. Sain jatkuvasti virheilmoituksen siitä, ettei domain-nimeäni voitu varmistaa. Yritin googlettaa, mitä olin tehnyt väärin, mutta en aluksi löytänyt mitään kovin järkevää. Lopulta päädyin laittamaan oman sivustoni nimen SSL Checker -sivulle, jonka tarkastuksen epäonnistuessa sain virheilmoituksen, jossa viitattiin siihen, etten olisi ehkä sallinut HTTPS-liikennettä palvelimelleni. Ja siitähän ongelma johtuikin. Päädyin käyttämään DigitalOceanin ohjeita, joissa mainittiin myös tarvittava komento HTTPS-liikenteen sallimiselle. Tämän jälkeen certbot sai tehtävänsä hoidettua mallikkaasti ja sain vihdoin sivulleni sertifikaatin.

Linkki sivulle
Linkki sivulle

Asennuksen aikana minulta kysyttiin, haluaisinko ohjata kaiken saapuvan liikenteen turvalliseen osoitteeseen, ja jostain syystä sillä hetkellä vastasin kieltävästi. Myöhemmin tultuani katumapäälle yritin etsiä tapaa muuttaa asetus, ja löysinkin muutamia potentiaaliselta vaikuttavia keinoja, mutta halusin kokeilla asetusten muuttamisen ulkoistamista certbotille. Annoinkin komennon

$ sudo certbot --redirect

ja botti heräsi taas henkiin. Aluksi se pyysi minua valitsemaan, mille osoitteille haluaisin ottaa uudelleenohjauksen käyttöön, ja valitsin sekä juuriosoitteen että www-osoitteen. Tämän jälkeen certbot ilmoitti, että minulla vaikuttaa olevan jo voimassaoleva sertifikaatti, joten valitsin annetuista vaihtoehdoista, että muutos tehtäisiin aikaisempaan sertifikaattiini. Kaikki onnistui hyvin ja certbot teki itsenäisesti tarvittavat muutokset VirtualHost-tiedostooni:

Tämän jälkeen kun yritän selaimella mennä osoitteeseen helkera.com, minut ohjataan sivulle https://helkera.com, ja selain ilmoittaa sivun olevan turvallinen. Kyllä nyt sielu lepää!

Tämän viikon vapaaehtoisiin tehtäviin olisi kuulunut myös lukuisia WordPressiin liittyviä tehtäviä. Halutessani voisinkin siis nyt siirtää tämän WordPress-blogini omalle palvelimelleni. En aio kuitenkaan yrittää sitä operaatiota enää tänään, sillä minulla on vielä tämän illan kuntopyöräilyt tekemättä. Eli siirrynkin nyt ihan perinteisempään hikoiluun tällaisen metaforisen tehtävien parissa hikoilun jälkeen. Hyvää yötä vaan kaikille!

Mainokset

Kolmannet tehtävät – Apache, kotisivut ja lisää lokien analysointia

Aikaisemmilla viikoilla tehtäviä on ollut viisi kappaletta, mutta tällä viikolla niitä on peräti kaksitoista. Ideana kuitenkin on, ettei niistä tarvitse tehdä jokaista:

” Tee viisi vapaavalintaista kohtaa. Säädä vaikeustaso oikeaksi: jos olet ihan alussa ja tämä on haastavaa, tee helpoimmat a b c d i. Jos osaat jo perusteet, tee useampia tai vaikeampia kohtia. Tarkoitus on, että tehtävät tehtyäsi osaat enemmän kuin osasit ennen. ”

Tero Karvinen

Itse opin ensimmäiset tämän viikon aiheeseen liittyvät asiat vasta viime tunnilla, joten taidan suosiolla pitäytyä helpommissa tehtävissä. Sen lisäksi eilisen ncmpcpp-sekoilun jäljiltä yksinkertaisuuden kaipuuni on vahva.

Tehtävä a

Ensimmäisenä on vuorossa palvelinohjelma Apachen asennus ja sen toimivuuden testaaminen kotisivujen avulla. Teimme vastaavan harjoituksen viime tunnilla, mihin liittyen tein tällä kertaa myös muistiinpanoja. Yritänkin nyt seurata ihan omia ohjeitani (tai oikeammin siis Tero Karvisen ohjeita) sen sijaan että normaaliin tapaan alkaisin etsiä ohjeita Googlesta.

Ennen varsinaista Apachen asentamista on hyvä säätää ensin palomuurin asetukset kuntoon. Ubuntun oletustyökalu palomuuriasetusten säätämiseen on UFW eli Uncomplicated Firewall. Oletuksella palomuuri ei ole päällä, joten tämä asetus täytyy vaihtaa. Sitä ennen kuitenkin avataan TCP-portti numero 22, joka mahdollistaa mm. SSH-yhteyksien muodostamisen ja turvallisen tiedostojen siirtämisen scp-komennon avulla (Lähde).

$ sudo ufw allow 22/tcp

Tämän jälkeen palomuuri otetaan varsinaisesti käyttöön komennolla

$ sudo ufw enable

ja seuraavaksi avataan HTTP-liikenteen mahdollistava TCP-portti 80.

$ sudo ufw allow 80/tcp

Nyt kun asetukset on säädetty, katsotaan miltä palomuurin status näyttää.

Ainakin minun silmääni kaikki vaikuttaa olevan kuten pitääkin.

Seuraavaksi asennetaankin itse Apache komennolla

$ sudo apt-get install apache2

, jota ennen ajan myös komennon

$ sudo apt-get update

varmistuakseni siitä, että ladattavat paketit ovat mahdollisimman uusia.

Asennuksen valmistuttua avasin selaimen ja kirjoitin osoitekenttään localhost, jossa näkyi Apachen oletussivu, mistä päättelin asennuksen onnistuneen.

Tämän jälkeen kannattaa mahdollisimman pikaisesti ylikirjoittaa normaali index.html-sivu, sillä hakkerit erikseen etsivät kyseisen sivun perusteella palvelimia, jotka saattavat keskeneräisyydestään johtuen olla otollisempia murtautumiskohteita kuin sellaiset palvelimet, joita ollaan konfiguroitu enemmän. Hyvä komento sivun ylikirjoittamiseen on esimerkiksi

$ echo hei|sudo tee /var/www/html/index.html

, josta nähdään myös, missä hakemistossa index.html-sivu sijaitsee. Tee-komento kirjoittaa echossa annetun tekstin annettuun tiedostoon. Tämän jälkeen selaimen näkymä muuttuu seuraavanlaiseksi:

Seuraavaksi lähdetään tekemään käyttäjille omia kotisivuja. Aluksi käyttäjille pitää myöntää oikeudet tehdä omiin kotihakemistoihinsa public_html-kansiot. Tämä tapahtuu komennolla

$ sudo a2enmod userdir

, joka sallii Apache2-moduulin käytön käyttäjien omissa hakemistoissa (Lähde). Tässä vaiheessa terminaaliin tulostuu

To activate the new configuration, you need to run:
systemctl restart apache2

, joten potkaiskaamme ehdotetulla komennolla Apache uudestaan käyntiin, jotta muutokset tulisivat voimaan.

Seuraavaksi navigoin omaan kotihakemistooni ja loin sinne public_html-kansion ja sen sisään index.html-sivun seuraavilla komennoilla:

$ mkdir public_html
$ cd public_html
$ nano index.html

Index-sivulle voi kirjoittaa, mitä nyt haluaakaan, oma http://localhost/~helkera -osoitteesta löytyvä sivuni näyttää pienen säätämisen jälkeen tältä:

Aluksi hieno ASCII-kala tulostui ilman tyhjiä merkkejä, minkä takia se näytti vaan epämääräiseltä littanalta merkkijonolta. Stackoverflow:sta sain selville, että ASCII-kuvat saa säilymään oikeassa muodossa käyttämällä <pre> -tageja kuvan ympärillä. Kyseinen kala on itseasiassa komentoriviohjelma Fish:n logo, josta joku ystävällinen sielu kyseli tekstinä kopioitavaa versiota GitHubissa.

Tehtävä b

Nyt kun kotisivut on saatu toimimaan, niitä olisi tarkoitus käyttää ja samalla tarkastella, mitä Apachen lokiin ilmestyy.

Apachen lokit ovat hakemistossa /var/log/apache2, ja sieltä löytyvät tiedostot access.log, error.log ja other_vhosts_access.log. Avasin ensin access.login ja aloin tarkastella sen viimeisimpiä rivejä, jotka olivat seuraavanlaiset:

127.0.0.1 - - [03/Feb/2019:17:36:22 +0200] "GET / HTTP/1.1" 304 179 "-" "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:65.0) Gecko/20100101 Firefox/65.0"
127.0.0.1 - - [03/Feb/2019:17:38:49 +0200] "GET / HTTP/1.1" 200 285 "-" "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:65.0) Gecko/20100101 Firefox/65.0"
127.0.0.1 - - [03/Feb/2019:17:38:49 +0200] "GET /favicon.ico HTTP/1.1" 404 500 "-" "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:65.0) Gecko/20100101 Firefox/65.0"
127.0.0.1 - - [03/Feb/2019:17:40:16 +0200] "GET /~jokumuu HTTP/1.1" 404 498 "-" "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:65.0) Gecko/20100101 Firefox/65.0"
127.0.0.1 - - [03/Feb/2019:17:41:17 +0200] "GET /~helkera/ HTTP/1.1" 200 669 "-" "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:65.0) Gecko/20100101 Firefox/65.0"

Ensimmäisenä kussakin lokimerkinnässä näkyy ip-osoite, josta GET-pyyntö on tullut, eli tässä tapauksessa localhost. Seuraavana toisen viivan paikalla voisi olla clientin identiteettiä kuvaava nimi, jota tässä tapauksessa ei ole kuitenkaan saatavilla. Hakasulkeiden sisällä on aika, jolloin palvelinta on kutsuttu. Seuraavaksi lokissa määritellään, että kyse oli juuri GET-pyynnöstä, joka kohdistui yleiseen index.html:ään käyttäen HTTP 1.1 -protokollaa.

Seuraavaksi tuleva koodi kuvaa serverin statusta pyyntöön liittyen. 304 tarkoittaa, että sivuun ei ole tehty muutoksia sen jälkeen kun se on tallennettu client-koneen välimuistiin, joten sivu haetaan välimuistista. 200 puolestaan tulostuu, jos selain ei hae sivua välimuistista, vaan lataa sen onnistuneesti palvelimelta. 404 taas ilmaisee, että haettua kohdetta ei löytynyt. Esimerkiksi sivun faviconin hakeminen tuotti 404-koodin, koska en ole asettanut sivulle faviconia. Myös yrittäessäni mennä osoitteeseen, jota ei ole olemassa, saatu koodi on 404. (Lähde)

Seuraava luku kuvaa pyydetyn objektin kokoa. Tämän jälkeen tuleva lainausmerkkien sisällä oleva viiva tarkoittaa, että käyttäjä tuli sivuille suoraan ilman että häntä olisi ohjattu jostain muualta, eli hän saattoi esimerkiksi kirjoittaa sivuston osoitteen suoraan osoitekenttään, kuten itsekin tein (Lähde). Tämän jälkeen tulee ns. User-agent -elementti, joka kertoo, mitä tietoja pyynnön tehnyt selain on lähettänyt itsestään, eli tässä tapauksessa tiedon siitä, että käytetty selain oli Mozilla Firefox ja käyttöjärjestelmä Ubuntu (Lähde).

Tehtävä c

C-tehtävän tarkoituksena on aiheuttaa virhe palvelimella ajettavaan koodiin ja etsiä lokeista kyseiseen tapahtumaan liittyvät rivit. Edellisessä tehtävässä en vielä tehnyt omalle nettisivulleni minkäänlaista koodia, joten se on edessä nyt. Tunnilla katselimme yhdessä php-koodia, joten pitäydyn tällä kertaa siinä, vaikka Python kiinnostaakin minua.

Hain oikeaa php-pakettia asennettavaksi komennolla:

$ apt-cache search php|grep php|grep -i apache

Aluksi komento siis hakee kaikkia ladattavia paketteja, joiden nimessä tai kuvauksessa mainitaan php. Niitä on kuitenkin valtava määrä, joten lisäämällä grep-komentoja mukaan saadaan rajattua hakutuloksia järkevästi. Edellä ajettu komento tuottaakin neljä hakutulosta, joista latasin Apache2:selle tarkoitetun php-moduulin oletusversion komennolla

$ sudo apt-get install libapache2-mod-php

Seuraavaksi potkaisin vielä Apachen uudestaan käyntiin, jotta tehdyt muutokset tulisivat varmasti voimaan:

$ sudo systemctl restart apache2

Tässä vaiheessa yritin jo ajaa pientä php-koodinpätkää, mutta sivulle tulostuikin pelkkää tyhjyyttä. Sen lisäksi sivun lähdekoodissa näkyi annettu php-koodi suoritetun koodin lopputuloksen sijasta, mikä ei todellakaan ole toivottava tilanne. Melko pitkään asiaa ihmeteltyäni muistin, että oletusasetukset eivät salli php-skriptien ajamista käyttäjien kotihakemistoista käsin, ja niinpä asetuksia pitää muuttaa. Antamalla komento

$ sudoedit /etc/apache2/mods-available/php7.2.conf

päästään muokkaamaan Apachen conf-tiedostoa siten, että muutetaan viisi alinta kuvassa näkyvää riviä kommenteiksi:

Tallentamisen jälkeen polkaisin Apachen käyntiin vielä uudestaan ylempänä mainitsemallani komennolla ja sen jälkeen oli aika luoda php:ta käyttävä sivu kotihakemiston public_html-kansioon. Itse en halunnut lisätä hienolle index.html-kalasivulleni ylimääräistä hässäkkää, joten loin kokonaan uuden tiedoston php:n testaamista varten komennolla

$ gedit hello.php

Olin aikaisemmin ladannut gedit-nimisen tekstieditorin tällaisia tilanteita varten, koska sen avulla on vähän kätevämpää koodailla. Käyttämäni koodinpätkä vaikutti toimivan sivulla, kuten seuraavasta kuvasta näkyy:

Seuraavaksi olikin vuorossa php-koodiin virheen tekeminen. Oletin, että tämä onnistuisi suhteellisen helposti esimerkiksi hankkiutumalla eroon lainausmerkeistä tai suluista. Poistinkin Hello World -tekstin edestä lainausmerkin ja myös laskutoimituksen jälkeisen sulun. Olin avannut jo valmiiksi tekstieditoriin /var/log/apache2-hakemistossa sijaitsevan error.log-tiedoston, ja heti kun tallensin virheellisen koodin ja latasin nettisivun uudestaan, lokiin ilmestyi uusi rivi:

[Sun Feb 03 19:46:08.319395 2019] [php7:emerg] [pid 14330] [client 127.0.0.1:59334] PHP Parse error:  syntax error, unexpected 'World' (T_STRING), expecting ',' or ';' in /home/helkera/public_html/hello.php on line 7

Ensin siis ilmoitetaan, koska kyseinen virhe tapahtui. En ole varma, mitä php7:emerg kokonaisuudessaan tarkoittaa, mutta pid on asianosaisen prosessin id-numero. Seuraavana listalla on ainakin client-koneen IP-osoite ja ilmeisesti myös portti. Sen jälkeen alkaa tarkempi selitys itse virheestä, joka tässä yhteydessä liittyy siihen, ettei koodia saatu parsittua syntaksivirheen vuoksi. Ilmoitus valittaa sanasta World, koska koodi ilmeisesti tyssää juuri siihen kohtaan lainausmerkkien puuttumisen takia. Koska koodin parsija ei tiedä, että kyseessä on tekstinpätkä, se olettaa rivin loppuvan Hello-sanan jälkeen, ja kaipailee siten esimerkiksi puolipistettä tämän merkiksi. Loppuun tulostuu myös, missä hakemistossa virheellinen tiedosto sijaitsee, ja vielä tarkemmin, millä rivillä koodissa virhe tapahtuu.

Tehtävä d

Seuraavaksi häiriötä piti aiheuttaa Apachen config-tiedostoihin. Valitsin kohteekseni /etc/apache2 -kansiossa olevan apache2.config:in. Selailin sitä pitkän aikaa yrittäen miettiä, minkä muuttamisesta tulisi varmasti virheitä. En kuitenkaan ollut ihan varma, joten päädyin siirtämään koko tiedoston pois omasta kansiostaan omaan kotihakemistooni. Sen jälkeen päivitin selaimessani auki olevan sivun ja tutkin, tuliko Apachen error.logiin näkyviin mitään. Yllätyksekseni ei tullut, ja kaikki toimi ihan hyvin ilman config-tiedostoakin. Ajattelin, että ehkä Apache pärjäilee omilla oletusasetuksillaan, vaikkei sillä olisikaan pääsyä config-tiedostoon. Siirsin siis tiedoston takaisin alkuperäiselle paikalleen ja avasin sen uudestaan

$ sudoedit apache2.conf

-komennolla. Tällä kertaa vaihdoin Timeout-kohdassa olevan numeron tekstiksi. Error.logiin ei tämänkään jälkeen ilmestynyt mitään, eikä syslogistakaan löytynyt mitään järkevää. Päätin siis kokeilla tehtävänannossa mainittua apache2ctl configtest -komentoa. Vihdoinkin sain terminaaliin virheilmoituksen:

AH00526: Syntax error on line 92 of /etc/apache2/apache2.conf:
Timeout takes one argument, Timeout duration (sec)
Action 'configtest' failed.
The Apache error log may have more information.

Nopean googletuksen perusteella vaikuttaa siltä, että AH00526 on Apachen syntaksivirheisiin liittyvä koodi, kuten tekstistäkin voi päätellä. Virheessä on myös kerrottu, missä tiedostossa ja millä rivillä kyseinen virhe sijaitsee, ja mukana on myös pienet ohjeet oikean arvon valitsemiseksi. Vaikka virheessä mainitaan, että Apachen virhelokissa saattaa olla lisätietoa, näin ei ainakaan tässä tilanteessa ollut. Viime töikseni editoin vielä config-tiedoston takaisin alkuperäiseen muotoonsa. Ajoin myös uudestaan apache2ctl configtest -komennon, ja vaikka oletin, että virheitä ei pitäisi enää tulla, sain kuitenkin seuraavanlaisen ilmoituksen:

AH00558: apache2: Could not reliably determine the server's fully qualified domain name, using 127.0.1.1. Set the 'ServerName' directive globally to suppress this message
Syntax OK

Tämä ei kuitenkaan ole erityisen ihmeellistä, sillä Apache ei varmaankaan voi määritellä domain-nimeä automaattisesti, enkä minä ole sellaista asettanut. Config-tiedoston syntaksi on sentään nyt kunnossa.

Tehtävä i

Tässä ns. helppojen tehtävien viimeisessä tehtävässä oli tarkoituksena aiheuttaa lokiin mahdollisimman monta erilaista HTTP-statusta. Tehtävässä b sain jo aikaiseksi statukset 200, 304 ja 404, joten nyt lähdin metsästämään muita statuksia. Analysoin aikaisemmin jo aika tarkasti lokitulosteiden yleisen rakenteen, joten kommentoin tässä tehtävässä lähinnä saatuja statuskoodeja.

Aluksi avasin avukseni Wikipedia-sivun HTTP-statuksista ja lukiessani listaa kiinnitin huomiota koodiin 414, joka kertoo siitä, että annettu URI on liian pitkä. Yritin tavoitella tätä virhettä kirjoittamalla selaimen osoitekenttään niin pitkän osoitteen kuin mahdollista, mutta kuten ennakkoon arvelinkin, se ei riittänyt, sillä sain sen sijaan koodin 404:

127.0.0.1 - - [03/Feb/2019:21:08:41 +0200] "GET /~helkera/kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkk HTTP/1.1" 404 718 "-" "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:65.0) Gecko/20100101 Firefox/65.0"

Seuraavaksi ajattelin, että koska en ole määritellyt sivulle mitään, mihin voisi käyttää POST-metodia, sen yrittäminen saattaisi tuottaa jonkinlaisen virheen. Tämäkään ei kuitenkaan toteutunut, ja käytettyäni löytämääni komentoa

wget --post-data "username=Helkera" http://localhost/~helkera/

sain silti statukseksi 200 sekä seuraavan ilmoituksen terminaaliin:

--2019-02-03 22:55:59--  http://localhost/~helkera/
Resolving localhost (localhost)… 127.0.0.1
Connecting to localhost (localhost)|127.0.0.1|:80… connected.
HTTP request sent, awaiting response… 200 OK
Length: 634 [text/html]
index.html: Permission denied

Cannot write to ‘index.html’ (Permission denied).

Lokissakin yritykseni näkyi koodilla 200:

127.0.0.1 - - [03/Feb/2019:22:55:59 +0200] "POST /~helkera/ HTTP/1.1" 200 942 "-" "Wget/1.19.4 (linux-gnu)"

Asioiden liian hyvästä toimivuudesta ärsyyntyneenä päätin yrittää jotain vähän erilaista. Tein kokonaan uuden käyttäjän komennolla

 $ useradd holkura

, jonka jälkeen asetin käyttäjälle salasanan komennolla

$ passwd holkura

Salasanan syötettyäni kirjauduin uusille tunnuksille antamalla komennon

$ su holkura

ja syöttämällä juuri määrittelemäni salasanan. Sen jälkeen yritin seuraavanlaista GET-pyyntöä:

$ wget http://localhost/~helkera

ja vaikka odotin saavani 403-statuksen, joka kertoo että käyttäjällä ei ole lupaa pyydettyyn resurssiin, sainkin seuraavanlaisen vastauksen:

--2019-02-03 23:01:46--  http://localhost/~helkera
Resolving localhost (localhost)… 127.0.0.1
Connecting to localhost (localhost)|127.0.0.1|:80… connected.
HTTP request sent, awaiting response… 301 Moved Permanently
Location: http://localhost/~helkera/ [following]
--2019-02-03 23:01:46-- http://localhost/~helkera/
Reusing existing connection to localhost:80.
HTTP request sent, awaiting response… 200 OK
Length: 634 [text/html]
~helkera: Permission denied

Cannot write to ‘~helkera’ (Permission denied).

En ole varma, miksi sain statuksen, joka kielii siitä, että pyydetty resurssi olisi pysyvästi siirretty muualle kielletyn statuskoodin sijasta. Kuten edelliselläkin yrityksellä, lokitulosteet olivat myös nyt hieman erilaiset:

127.0.0.1 - - [03/Feb/2019:23:01:46 +0200] "GET /~helkera HTTP/1.1" 301 572 "-" "Wget/1.19.4 (linux-gnu)"
127.0.0.1 - - [03/Feb/2019:23:01:46 +0200] "GET /~helkera/ HTTP/1.1" 200 941 "-" "Wget/1.19.4 (linux-gnu)"

Koska tein pari aikaisempaa GET-pyyntöä suoraan terminaalista, tällä kertaa esimerkiksi selaintiedot puuttuvat. Terminaali selkeästi lähettää käyttöjärjestelmästään vähemmän spesifiä tietoa selaimeen verrattuna.

Seuraavaksi päätin tehdä holkura-käyttäjänä seuraavan GET-pyynnön:

$ wget http://localhost/~holkura

Normaalin, toimivan hakemistoni sijasta kutsuin siis sivua, jota ei ole olemassa, koska uudella käyttäjällä ei ole kotihakemistossaan public_html-kansiota, eikä myöskään tarvittavaa index-sivua. Omaan oikeaan kotihakemistooni tällä toisella käyttäjällä ei taas ole oikeuksia. Tällä kertaa lykästi ja sain tavoittelemani statuksen:

--2019-02-03 23:31:59--  http://localhost/~holkura
Resolving localhost (localhost)… 127.0.0.1
Connecting to localhost (localhost)|127.0.0.1|:80… connected.
HTTP request sent, awaiting response… 403 Forbidden
2019-02-03 23:31:59 ERROR 403: Forbidden.

Myös lokiin tulostui oheinen rivi:

127.0.0.1 - - [03/Feb/2019:23:31:59 +0200] "GET /~holkura HTTP/1.1" 403 509 "-" "Wget/1.19.4 (linux-gnu)"

Seuraavaksi päätin yrittää jotain jännittävämpää. Apachen config-tiedostoa tutkiessani näin siellä timeout-attribuutin, ja ajattelin, että jos muuttaisin sen arvon riittävän pieneksi, saattaisin saada jonkinlaisen aikakatkaisuun liittyvän virheen. Vaihdoin sudoeditillä oletusarvon 100:sta 0.0000001:teen, tallensin tiedoston ja potkaisin Apachen uudestaan käytiin. Kaikki toimi kuitenkin aivan entiseen malliin. Tarkistin vielä apache2ctl configtest -komennolla, oliko syöttämässäni asetuksessa jotain vikaa, mistä johtuen asetus ei olisi tullut voimaan, mutta mitään sellaista ei ainakaan tulosteesta ilmennyt. Myös yrittämäni pyynnöt saivat access.logissa statuksekseen 200. Ilmeisesti siis pyynnöt joko toimivat salamannopeasti (mikä tuntuu todennäköiseltä) tai jossain muualla on häikkää. Voi myös olla, että ymmärrän väärin, mihin aikakatkaisua tässä yhteydessä ylipäätäänsä käytetään.

Viimeisenä ajattelin yrittää tehtävänannossa mainittua statusta 500, eli internal server erroria. Tämä on geneerinen virheilmoitus, jota käytetään monesti silloin, kun spesifimpää virheilmoitusta ei voida antaa. Ottaessani selvää kuinka tällaisen virheilmoituksen saisi aikaiseksi kiinnitin huomiota siihen, että monet ihmiset kertoivat saaneensa 500-statuksen virheellisen php-koodin takia. Löysinkin tällaisen keskustelun, jonka innoittamana lisäsin omaan hello.php-tiedostooni olemattoman funktion kutsun seuraavalla tavalla:

Kuten kuvasta näkyy, funktion jälkeinen tekstielementti ei enää tulostu ja access.logiin on ilmaantunut uusi rivi:

127.0.0.1 - - [04/Feb/2019:00:28:54 +0200] "GET /~helkera/hello.php HTTP/1.1" 500 288 "-" "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:65.0) Gecko/20100101 Firefox/65.0"

En olisi ikinä uskonut olevani näin mielissäni saadessani internal server errorin, haha!

Siinä olivat tämän viikon tehtävät. Näin jälkikäteen ajateltuna olisin kyllä ihan hyvin voinut sittenkin tehdä LAMP-stackin pystyttämistehtävän viimeisen tehtävän sijasta. Siihen olisi saattanut mennä vähemmän aikaakin :D Mutta tehty mikä tehty, enköhän minä sen LAMPin tule pystyttäneeksi joka tapauksessa ennemmin tai myöhemmin. Ja olihan tämä tarkoituksellinen virheiden tekeminen omalla tavallaan aika hauskaa.

”Nopea” ncmpcpp-päivitys

Huhhuh. Tein aikaisemmin illalla sen virheen, että ennen kolmansien tehtävien tekemistä päätin nopeasti vilkaista, saisinko jotenkin ratkaistua aikaisemmin mainitsemani VirtualBoxin äänenlaatuongelman. Yllätyksekseni koko homma hoituikin yllättävän nopeasti ja kivuttomasti, ja sisälsi vain audio controllerin vaihtamisen virtuaalikoneen audioasetuksista. Tästä videosta sain sen käsityksen, että aikaisempi asetukseni olisi soveltunut lähinnä vanhoille Windows-käyttöjärjestelmille. Toinen vaihtoehto oli nimeltään Intel HD Audio, ja koska koneessani on Intelin emolevy, ei ole yllättävää, että se oli tässä tapauksessa toimivampi vaihtoehto.

Asetuksen muutettuani laitoin virtuaalikoneeni innoissani päälle testatakseni oliko äänenlaatuongelma korjaantunut. Ncmpcpp ei kuitenkaan löytänyt musiikkikirjastoani ollenkaan, vaikka viimeisellä käyttökerralla kaikki toimi oikein hyvin. Aloin siis selvittämään, mistä tämä voisi johtua. Kovasta yrityksestä huolimatta en päässyt lähellekään ratkaisua tai edes yksiselitteistä teoriaa tilanteesta. Lopulta kyllästyin ja päätin poistaa sekä mpd:n että ncmpcpp:n ja asentaa ne kokonaan uudestaan. Poistin myös kaikki niihin liittyvät hakemistot ja seurasin asentaessani uusia ohjeita.

Ongelmat eivät kuitenkaan siihen loppuneet. Vaikka ncmpcpp käynnistyikin kerran normaalisti, ja pääsin ilokseni havaitsemaan, että ääni ei todella enää pätkinyt, sitä iloa ei kestänyt kauaa. Yleisesti ottaen tuntuu siltä, että ncmpcpp käynnistyy ongelmitta tasan ensimmäisen kerran asennuksen jälkeen, ja uusilla yrityksillä tulee jos jonkinlaisia ongelmia. Usein käy niin, ettei musiikkikirjasto ei lataudu ollenkaan, mutta välillä kun saan sen näkyviin ja alan soittaa kappaleita, muutaman kappaleen jälkeen ncmpcpp:n yhteys mpd:hen katkeaa ja ohjelma vaikuttaa kaatuvan.

Ainoa asia joka vaikuttaa ainakin satunnaisesti auttavan kappaleiden löytymisongelmaan on täällä mainittu tapa tappaa koko mpd-palvelu ja käynnistää se manuaalisesti uudestaan seuraavalla tavalla:

$ sudo service mpd stop

$ mpd

Tämän jälkeen komento

$ ncmpcpp

avaa soittimen niin, että musiikkihakemiston sisältö ja luomani soittolista näkyvät.

Luulisin, että mpd service saattaa lähteä jossain vaiheessa pyörimään jollain tavalla väärin ja uudelleen käynnistäminen nollaa tilanteen. Tämäkään ei kuitenkaan toimi aina. En tiedä, kuinka tästä ongelmasta pääsisi eroon ja aiheutuvatko saamani time out errorit myös tästä, vai onko taustalla joku isompi asia, josta en tiedä mitään.

Mutta niin. Audio ei rahise enää, mutta sain tilalle noin viisitoista muuta ongelmaa, joiden ratkaiseminen on huomattavasti hankalampaa :D Sen lisäksi en ole edes aloittanutkaan oikeiden tehtävien tekemistä. Ja kello on 04.09. Miksi olen tällainen.

Ja nyt vaikuttaa myös siltä, etten saa enää mpd-prosesseja edes tapettua.

Yritin seuraavaksi myös tarkastella tilannetta htop:in avulla.

Kuvan alalaidassa näkyy vaikka kuinka monta mpd-nimistä prosessia, mutta en saa hankkiuduttua niistä eroon edes htop:illa. Kiinnostavaa on myös, että vaikka pidof mpd -komento tulostaa koko ajan 1473, htopin listalta ei löydy sillä prosessi-id:llä mitään. Ehkä on aika jättää tämä mysteeri tältä päivältä tähän ja paneutua asiaan uudestaan joskus myöhemmin. Jos joku hullu mpd/ncmpcpp -guru tätä sattuisi lukemaan, niin apua otetaan mielellään vastaan.

… Kovasta yrityksestä huolimatta en kuitenkaan kyennyt lopettamaan hyvän sään aikana, vaan käynnistin virtuaalikoneen uudelleen ja hain htopilla uudestaan prosesseja mpd-hakusanalla. Ja nyt command-kohdassa pelkän mpd-sanan sijasta on /usr/bin/mpd –no-daemon. Ja näitä prosesseja löytyy noin seitsemän kappaletta. En tiedä, onko tämä normaalia, mutta muistan käyttäneeni –no-daemon -komentoa yrittäessäni kaikkia mahdollisia ehdoitettuja ratkaisuja ongelmiini. Voi olla, että olen sössinyt jotain ja minun olisi parasta koittaa asennusta kokonaan uudestaan. Tällä kertaa ncmpcpp lähti käyntiin ihan reippaasti, mutta hyytyi taas soittolistan toiseen kappaleeseen saatesanoilla ncmpcpp: Timeout while connecting. Eli jotain mätää tässä nyt selkeästi on.

Poistettuani sekä mpd:n että ncmpcpp:n komennolla

$ sudo apt-get remove mpd ncmpcpp

olisin olettanut, että pidof mpd ei olisi enää palauttanut mitään, mutta näin ei ollut. Sen lisäksi aikaisemmat /usr/bin/mpd-prosessit elivät ja voivat hyvin edelleen. Poistin siis sekä .mpd että .ncmpcpp -kansiot että mpd:n startupista ja käynnistin koneen uudelleen. Tämän operaation jälkeen htop ei enää löytänyt mpd-nimisiä prosesseja.

Seuraavaksi asensin ohjelmat uudelleen komennolla

$ sudo apt-get install mpd ncmpcpp

ja kopioin talteen ottamani config-kansiot takaisin omille paikoilleen. Tämän jälkeen ncmpcpp lähti taas normaalisti käyntiin ja nyt nähtäväksi jää, kuinka kauan tätä iloa kestää. Ja sieltähän se ensimmäinen timeout error tulikin heti ensimmäisen kappaleenvaihdon aikana. Kuitenkin kun vaihdoin seuraavaan kappaleeseen, ohjelma toipui ja aloitti kappaleen toistamisen. Onkohan mahdollista, että kappaleissani tai soittolistassani on jotain vikaa? Pitäisi varmaankin yrittää luoda uusi soittolista ja katsoa, jatkuvatko ongelmat senkin jälkeen.

Jos nämä ongelmat olisivat jotenkin systemaattisempia, niitä olisi helpompi ratkoa :D Nyt sain soitettua useamman kappaleen peräkkäin, vaikka soitin vaikuttaakin päättävän täysin mielivaltaisesti, alkaako se toistaa seuraavaa kappaletta automaattisesti vai ei. Välillä voin manuaalisesti laittaa seuraavan kappaleen soimaan, välillä sen yrittäminen taas tuottaa timeout errorin. Myös saman kappaleen sisällä eri kohtiin skippaaminen tuottaa saman lopputuloksen. Ja jos käynnistän ncmpcpp:n uudelleen se toimii äärimmäisen hitaasti ja heittää uudestaan Timeout while connecting -errorin.

Nyt kyllä pakotan itseni lopettamaan. Voisin yrittää rauhoittua syömällä vähän iltapalaa ja sen jälkeen menen kyllä vihdoinkin nukkumaan. Huomisen piti olla mukava ja rauhallinen päivä, mutta nyt siitä tuleekin työntäyteinen. Viime sunnuntaina kirosin sitä, että jätin tehtävät sunnuntaihin ja lupasin itselleni, että seuraavat tehtävät tekisin rauhassa lauantaina. Vaan kuinkas sitten kävikään…

Toiset tehtävät – loki, SSH-demoni ja lisää ohjelmien asennusta

Tehtävä 1

Tämän viikon ensimmäisenä tehtävänä on aiheuttaa lokiin kaksi eri tapahtumaa, joista toisen pitäisi olla onnistunut ja toisen joko epäonnistunut tai kielletty. Onnistuneen tapahtuman kandidaatiksi mieleeni tuli ensimmäiseksi normaali uusien päivitysten hakeminen apt-getin avulla, sillä virtuaalikoneeni ilmoitti saatavilla olevista päivityksistä kun kirjauduin sisään.

Kirjoitinkin siis terminaaliin komennon sudo apt-get update, ja salasanan syöttämisen jälkeen päivitykset asentuivat normaalisti. Lähdin seuraavaksi etsimään tekemistäni päivityksistä lokiin kirjattuja tietoja hakemistosta /var/log. Syslog-niminen tiedosto vaikutti lupaavimmalta, joten tutkin sen sisältöä komennolla less syslog ja menin lokitiedoston loppuun painamalla shift + g. En kuitenkaan ensisilmäyksellä löytänyt mitään päivityksiin viittaavaa, joten koitin vielä hakea relevantteja mainitoja komennolla grep -i update syslog. Sain vain seuraavanlaisen tuloksen:

Jan 27 19:28:11 helkera-VirtualBox anacron[6311]: Updated timestamp for job `cron.weekly' to 2019-01-27

Tämä ei kuitenkaan kuulostanut etsimältäni tiedolta, joten palasin tutkimaan, millaisia muita kansioita /var/log -hakemistosta löytyy ja kiinnitin huomiota kansioon nimeltä apt. Koska päivitykset tehdään APT:illa eli Automatic Packaging Toolilla, tuntui järkevältä, että päivityksiin liittyvät lokit saattaisivat sittenkin löytyä kyseisestä hakemistosta. Avattuani history.log -tiedoston löysin kyllä useampia mainintoja tänään tehdyistä päivityksistä, mutta lokissa mainitut ajat eivät täsmänneet vaan heittivät muutamalla tunnilla alaspäin.

Päivityksiä tehdessäni tunnistin päivitettävien ohjelmien nimet, mutta tässä lokitiedostossa mainitut nimet ovat minulle vieraita. Olettaisinkin siis, että päivittämäni ohjelmat kuuluvat lokin listaamiin paketteihin. En tosin osaa sanoa, mistä virheelliset ajat saattavat johtua. Muuten olisin valmis sanomaan, että aika-asetuksissa on jotain vikaa, mutta kohta vastaan tulevassa auth.logissa ajat taas jostain syystä täsmäävät.

Seuraavaksi vuorossa on epäonnistuneen tai kielletyn toimenpiteen tekeminen. Ensimmäiseksi mieleeni tuli, että voisin yrittää tehdä jotakin korotettuja käyttöoikeuksia vaativaa toimenpidettä ilman sudo-komentoa. Yritinkin asentaa Gimp-kuvankäsittelyohjelman ilman korotettuja käyttöoikeuksia, mikä ei oletetusti onnistunut.

Tämän jälkeen piti taas selvittää, minne kyseiseen tapahtumaan liittyvät lokitiedot oikein tallentuivat. En löytänyt syslog-tiedostosta mitään selkeästi aiheeseen liittyvää, joten päättelin, että nämäkin lokitiedot saattaisivat olla tallentuneet eri paikkaan samaan tapaan kuin edelliset päivityksiin liittyvät tiedot. Tämän artikkelin avulla päättelin, että koska tekemäni toimenpide liittyi käyttäjän autentikointiin, tietojen tulisi luultavasti löytyä auth.log -tiedostosta. Löysinkin muutaman lokirivin, jotka vaikuttivat vastaavan tekemääni operaatiota. Ne eivät kuitenkaan olleet erityisen informatiivisia, joten päätin tehdä toisen testin siinä toivossa, että lokiin tulostuisi jotain hieman yksityiskohtaisempaa. Yritin siis Gimpin asennusta uudestaan, mutta tällä kertaa käytin sudo-komentoa ja annoin virheellisen salasanan. Ja toden totta, lokiin ilmestyi uutta tietoa, jossa tällä kertaa mainittiin ”authentication failure”. Seuraavassa kuvassa ensimmäiset kaksi korostettua tapahtumaa liittyvät oletettavasti ensimmäiseen yritykseeni ja viimeisin korostettu rivi taas puolestaan virheelliseen salasanaan:

Kahdesta ensimmäisestä tapahtumasta ei mielestäni käy edes selkeästi ilmi, että olisi tapahtunut jonkinlainen ei-sallittu toiminto. Mutta aikaleimoja katsomalla näkyy ainakin, että root-käyttäjän sessio, joka oletettavasti liittyy asennukseen, suljetaan samalla sekunnilla kuin se avataan. En kyllä ole varma, minkä takia root-sessiota ylipäätäänsä yritetään avata kun en missään vaiheessa syöttänyt sudo-komentoa. Ehkä install-komento olettaa, että käyttäjä on syöttänyt sudo-tunnukset ja asennus loppuu heti, kun havaitaan, ettei näin ole?

Väärään salasanaan liittyvä autentikointivirhe on onneksi hieman yksiselitteisempi. Lokissa todetaan, ettei autentikointi onnistunut, ja ohessa on tiedot mm. siitä, mistä käyttäjästä on kyse. Pam_unix on moduuli, joka huolehtii salasanojen autentikoinnista. On vähän erikoista, että logname, eli sisäänkirjautuneen käyttäjän nimi on tyhjä. Uid on käyttäjälle annettava tunnistenumero. Minulla ilmeisesti helkera-tunnuksen uid on 1000 kun taas root-käyttäjän uid on yleensä 0, kuten ylemmillä riveillä näkyy. Euid ilmeisesti tulee sanoista effective user id, ja vaihtuu prosessien mukaan. Tty=/dev/pts/1 taas liittyy käytettävään terminaaliemulaattoriin. En ole varma, mistä userin ja hostin alussa olevat r-kirjaimet juontavat juurensa, ja tällä kertaa edes Googlesta ei tunnu löytyvän suoraa mainintaa asiasta.

Tehtävä 2

Seuraavana on vuorossa ns. SSH-demonin asennus. Demoni on nimenä sen verran hauska, että halusin ottaa selvää sen etymologiasta. Ilmeisesti termi juontaa juurensa ns. Maxwellin demonista, eli termodynamiikkaan liittyvästä ajatuskokeesta, jossa kuvitellaan, että demoni erottelee nopeita ja hitaita molekyylejä toisistaan. Tämän lisäksi kreikkalaisessa mytologiassa demoni on nähty taka-alalla toimivana hahmona, jolla ei ole erityistä preferenssiä hyvään tai pahaan. Demonilla tietotekniikassa tarkoitetaankin ohjelmaa, jota ajetaan taka-alalla, ja jota käyttäjä ei suoraan kontrolloi interaktiivisesti. (Lähde)

Ensitöikseni tein Google-haun hakusanoilla ”how to install ssh daemon on ubuntu 18.04” ja olin hieman pettynyt, kun tuloksissa ei puhuttukaan demoneista, vaan ihan vain servereistä. Lähdin kuitenkin ensimmäisen linkin takana olleita ohjeita seuraamalla yrittämään asennusta seuraavilla komennoilla:

$ sudo apt install tasksel

$ sudo tasksel install openssh-server

Asennuksen jälkeen annoin komennon

$ service ssh status

ja saatuani ohjeiden mukaiset tulosteet, päätin kokeilla opettajan ehdottamia komentoja.

Komennot ssh-copy-id, sshfs, scp ja git tarjosivat erilaisia käyttövinkkejä, mutta en ollut varma, mitä osaisin tai haluaisin yrittää. Tehtävään opettajamme on kirjoittanut vinkiksi ” Helpoin lienee scp: ‘scp foo.txt tero@example.com:’”, joten aloin miettiä, mihin kyseistä komentoa saatettaisiin käyttää. Tiesin, että scp on lyhenne sanoista secure copy, eli ilmeisesti tarkoituksena olisi siirtää vapaavalintainen tiedosto virtuaali-Xubuntultani jollekin muulle palvelimelle. Ensimmäisenä mieleeni tuli oma koulun myy-asemani, mutta en oikein ymmärtänyt, kuinka tiedonsiirto sinne onnistuisi. Sain kuitenkin vinkin Lauri Niiniskorvelta, minkä ansiosta sain siirrettyä tekstitiedoston palvelimelle kuvan osoittamalla tavalla. Siirron jälkeen otin terminaalin kautta myös SSH-yhteyden palvelimelle varmistaakseni, että siirtämäni tiedosto pääsi määränpäähänsä. Lopuksi annoin vielä komennon exit, jolloin palasin takaisin omalle virtuaalikoneelleni.

Tehtävä 3

Tämän viikon kolmas tehtävänanto on seuraavanlainen: ”Tee unelmien apt-get -komento: yksi komentorivi, joka asentaa suosikkiohjelmasi.”

En ole täysin varma, tarkoitetaanko tällä, että asennetaan yksi ohjelma, jonka install-komentoon sisällytetään ”yes”, joka normaalisti pitää syöttää asennuksen keskivaiheessa, vai että asennetaan useita eri ohjelmia samalla install-komennolla. Mikään ei tosin estä minua toteuttamasta molempia tulkintoja samassa apt-get -komennossa. Annoin siis komennon

$ sudo apt-get install gimp rhythmbox -y

, joka asensi kerralla sekä Gimp-kuvankäsittelyohjelman että Rhythmbox-musiikinkuunteluohjelman ilman että minua pyydettiin asennuksen aikana hyväksymään tietyt toimenpiteet.

Seuraavaksi testasin asentamiani ohjelmia, ja kumpikin vaikutti toimivan oletetulla tavalla, joskin VirtualBoxin ääni pätkii edelleen. Gimpin käyttäminen puolestaan oli näin Photoshopiin tottuneelle kyllä yllättävän vaikeaa!

Rhythmbox suoriutui myös korealaisista kirjaimista oikein hyvin.

Tehtävä 4

Seuraavaksi oli tarkoituksena asentaa vapaavalintaisia komentorivillä toimivia ohjelmia ja testata niitä. Pitkän googletuksen jälkeen valitsin kolme ohjelmaa, joista osa vaikutti hyödyllisiltä ja osa hieman vähemmän hyödyllisiltä, joskin epäilemättä kriittisen tärkeiltä!

Ohjelma 1 – Cowsay

Ensimmäiseksi asensin Cowsay:n komennolla

$ sudo apt-get install cowsay

, minkä jälkeen asensin myös fortunen komennolla

$ sudo apt-get install fortune

Näin jälkikäteen ajateltuna olisin voinut asentaa ohjelmat samalla komennolla, mutta tajusin vasta ensimmäisen asennuksen jälkeen, että saadakseni näiden ohjeiden esimerkkiä vastaavan tulosteen tarvitsisin myös fortunen. Mutta näiden askelten jälkeen kun kirjoitan terminaaliin komennon

$ fortune | cowsay

ruudulle tulostuu jotain maagista.

Lehmän voi myös halutessaan laittaa sanomaan, mitä itse haluaa, mutta tulevaisuusennusteita kertova lehmä miellyttää minua erityisesti.

Ohjelma 2 – ncmpcpp

Seuraavaksi ohjelmaksi valitsin erityisen tarttuvalla nimellä varustetun ohjelman, musiikinkuunteluun suunnitellun ncmpcpp:n. Tämän ohjelman asennus osoittautui hieman monimutkaisemmaksi kuin olisin odottanut, mutta löytämieni ohjeiden ja tämän Youtube-videon suosiollisella avustuksella sain hommat pyörimään.

Tiivistetysti sanottuna siis ensin asensin mpd:n (music player daemon!) komennolla

$ sudo apt-get install mpd

ja sen jälkeen asensin ncmpcpp:n (ilmeisesti lyhenne tulee sanoista NCurses Music Player Client Plus Plus) komennolla

$ sudo apt-get install ncmpcpp 

Tämän asennusprosessin jälkeen minun piti luoda kotihakemistooni kansiot .mpd ja .ncmpcpp. Molempien kansioiden sisälle luotiin config-tiedostot, joihin pastesin suoraan ohjeissa ehdotetun sisällön sillä erotuksella, että vaihdoin ncmpcpp:n config-tiedostoon musiikkikirjaston poluksi oman musiikkikansioni.

Ohjeissa neuvottiin myös lisäämään mpd-käyttäjätunnus sudo-komennolla, eikä minulla ollut pienintäkään aavistusta, miksi sellaista tarvittaisiin, saatikka sitten mistä sellaisin saisin. Päädyin siis jättämään kyseisen kohdan väliin. Asiaa selvittäessäni löysin yllä mainitsemani Youtube-videon, joka vaikutti jossain määrin selkeämmältä, joten siirryin noudattamaan siinä esitettyjä ohjeita. Config-tiedostojen jälkeen luotiin vielä mpd-kansioon muutama tiedosto, joita mpd:n toimiminen ilmeisesti edellyttää. Käyttämäni komento oli seuraavanlainen:

$ touch mpd.db mpd.log mpd.pid

Nähdäkseni tässä luodaan siis tietokanta, lokitiedosto ja tiedosto, jonne mpd:n käyttämä prosessi-id kirjataan.

Tämän jälkeen oli enää jäljellä ohjelman käynnistäminen komennolla ncmpcpp. Koska omat config-asetukseni olivat erilaiset kuin Youtube-videon kuvaajalla, oma soittimeni näytti hieman erilaiselta ja toimi eri komennoilla, mikä oli hieman hämmentävää. Esimerkiksi videossa mainittua help-ikkunaa en saanut auki millään. Aluksi en myöskään nähnyt kappaleitani ollenkaan, mutta u:ta (update) painettuani kappalelista tuli näkyviin. Tämän jälkeen pääsin itsekin navigoimaan listaa mukavasti nuolinäppäimillä ja kappaleet lähtivät soimaan enterillä.

Vaikka ncmpcpp:n (kuinkakohan monta vuotta tulee menemään siihen, että a) opin muistamaan tuon kirjainyhdistelmän ulkoa b) kykenen kirjoittamaan sen edes etäisen sujuvasti) asentaminen oli aikamoinen prosessi, sanoisin että se oli ehdottomasti kaiken vaivan arvoinen. Ncmpcpp on simppelin mutta söpön näköinen, vaikuttaa toimivan kivasti ja config-tiedostoa on helppo käydä muokkaamassa itse. Soittimessa on myös hieno visualisoija, jonka seuraavassa kuvassa avasin erilliseen ikkunaan, sillä halusin nähdä, miltä ohjelma näyttää ilman cool-retro-terminaalia.

Ohjelma 3 – htop

Seuraava ohjelma listallani on htop, jota käytetään prosessien tarkkailuun. Sen asentamiseen liittyvät ohjeet löysin täältä. Aloitin kirjoittamalla terminaaliin seuraavan komennon:

$ sudo apt-get install htop

Asennuksen jälkeen ohjelman sai pyörimään komennolla htop.

Prosesseja saa yläpalkista lajiteltua kätevästi esimerkiksi käyttäjien perusteella, kuormittavuuden mukaan tai sen perusteella, kuinka kauan prosessi on ollut käynnissä. Kun tein selvitystyötä siitä, mitä ohjelmia haluaisin ladata, Ubuntun foorumeilla muistaakseni kehuttiin tätä ohjelmaa siitä, että sen avulla on helppo tappaa kerralla useita eri prosesseja. Ei mitenkään erityisen kriittinen ominaisuus minulle, mutta hyvähän se on olla olemassa.

Siinä olivatkin tämän viikon raportoitavat tehtävät. Tehtävänämme oli myös opetella erilaisia yleisiä terminaalikomentoja ulkoa, ja suurimman osan niistä jo muistakin melko hyvin, mutta muutamia harvemmin käyttämiäni komentoja joutuisin ehkä äkkiseltään hieman miettimään. Esimerkiksi komentoja cp (copy), mv (move), ja rm (remove) en ole käyttänyt muuta kuin harjoituksen vuoksi muutaman kerran, kun taas erilaiset luonti-, navigointi- ja asennuskomennot ovat olleet tähän mennessä hyvin olennaisia jos jonkinlaisessa puuhailussa.

Ensimmäiset tehtävät – livetikun luonti, ohjelmien asennus ja lisenssit

1. tehtävä – livetikun luonti

Ensimmäisenä kurssin tehtävänä on ns. livetikun tekeminen, eli Xubuntun levykuvan asentaminen erillisen ohjelman avulla USB-tikulle, minkä jälkeen kyseistä tikkua käyttämällä voi käynnistää Xubuntun millä tahansa koneella. Vaikka ns. normaalit livetikut ovat käteviä siinä mielessä, että niitä voi käyttää missä vaan, niiden huonompi puoli on se, että kaikki tehdyt muutokset nollautuvat kun kone sammutetaan. Itse koen tämän ajatuksena hieman hankalaksi, koska pidän siitä että voin säätää kaikki asetukset juuri sellaisiksi kuin haluan, ja ajatus niiden jatkuvasta nollautumisesta tuntuu ainakin tässä vaiheessa melko turhauttavalta. Suunnitelmanani onkin siis tällä hetkellä tehdä livetikku, jota voin käyttää tarpeen vaatiessa, mutta muuten haluaisin käyttää luomaani virtualisoitua Xubuntu-konetta aina kun mahdollista.

Nopealla googlettamisella löysin hyvältä vaikuttavat ohjeet livetikun tekemiseen Rufus-ohjelmalla, jonka käyttöä tunnillakin suositeltiin. Latasin Rufus-version 3.4.1430, joka näyttää hieman erilaiselta kuin ohjeissa käytettävä Rufus-versio, mutta erilaisuudet vaikuttavat liittyvän lähinnä kenttien ryhmittelyyn.

Ohjeita lukiessani kiinnitin ensimmäiseksi huomiota siihen, että ilmeisesti on mahdollista tehdä myös livetikku, joka käyttää pysyvää tallennustilaa. Tämä vaihtoehto kiinnostaa minua enemmän, ja voi olla, että seuraavan kerran kaupassa käydessäni ostan vähän isomman USB3-tikun, mutta tämä tehtävä nyt menköön vanhemmalla USB2-tikulla. Pääsen samalla testaamaan, kuinka hitaasti USB2-livetikku oikein toimii.

Lähes kaikki asetukset olivat jo oletuksella oikeassa muodossa, valitsin ainoastaan USB-tikun ja Xubuntu-levykuvan. Ohjeissa Cluster size-kohdassa on oletusarvona 8192 bittiä, kun taas minulla oletusarvo on 4096 bittiä. Tämä johtuu todennäköisesti siitä, että oma tikkuni on kooltaan noin puolet pienempi ohjeissa käytettyyn tikkuun verrattuna. Tai ainakin sen johtopäätöksen olen valmis vetämään tämän artikkelin nopeasti silmäiltyäni.

Start-painiketta painettuani seuraavanlainen ohjeissakin esiintynyt huomioikkuna pomppasi esiin:

Painettuani ”Yes” valitsin vielä suositellun ISO-levykuva -vaihtoehdon, ja painoin ”OK” varoitukseen, jossa ilmoitettiin operaation tuhoavan kaiken tikulla olevan datan.

Tämän jälkeen Rufus alkoi hommiin, ja yhdentoista minuutin kuluttua livetikkuni oli valmis käytettäväksi. Päätin kokeilla sen käyttöä koululäppärilläni. Sainkin käynnistettyä live-istunnon ilman hankaluuksia. Seuraavaa tehtävää varten otin ruutukaappauksen, jossa näkyi koneeni rauta. Kuvan otettuani tajusin että siirtääkseni sen pääkoneelleni, jossa tätä päivitystä kirjoitan, tarvitsen tietenkin nettiyhteyden. Ihmettelin, minkä takia Xubuntun Network Center ei tunnistanut puhelimeni hotspot -yhteyttä ollenkaan, ja päädyinkin lopulta laittamaan koneen suoraa piuhan päähän. Vaikka langallinen yhteys toimikin hyvin, asia jäi kaivelemaan minua ja yritin googlettamalla löytää, miten langattomat verkot saisi näkyviin. Päädyin aluksi Xubuntun omalle dokumentaatiosivulle, joka kuitenkin minun tilanteessani osoittautui suurimmaksi osaksi merkittävän hyödyttömäksi. Kiinnitin kuitenkin huomiota siihen, että ohjeissa mainittua ”Enable Wi-fi” -kohtaa ei oman Network Managerini notifikaatioalueella näkynyt ollenkaan.

Päädyinkin seuraavaksi googlettamaan hakusanalla ”Xubuntu 18.04 Enable Wi-fi”, mikä johti minut tähän videoon, jonka ohjeita noudattamalla asia selvisi. Minun täytyi itse asentaa ajurit langattomia verkkoja varten, mutta onneksi tämä prosessi osoittautui yllättävän yksinkertaiseksi. En saanut koko tulostetta mahdutettua yhteen kuvakaappaukseen, joten yhdistin kaksi erillistä palasta Photoshopissa ladattuani ne netin välityksellä pääkoneelleni:


2. tehtävä – ohjelmien asennus + omia teemapohdintoja

Seuraavana tehtävänä oli vuorossa kolmen omavalintaisen ohjelman asentaminen. Päätin tässä vaiheessa vaihtaa suosiolla konetta. Asennan mielummin ohjelmia omalle virtuaaliselle Xubuntulleni, sillä livetikulle asentaminen tuntuu omituiselta kun kaikki sinne asennettu kuitenkin katoaa. Sen lisäksi suhtaudun melko nihkeästi ajatukseen siitä, että jokaisen käyttökerran alussa joutuisin asentamaan langattoman verkon ajurit ja säätämään esimerkiksi hiiren asetukset kuntoon aina uudestaan.

Olen säätänyt virtuaalikoneeni siten, että voin copy-pasteta Windowsista käsin asioita Xubuntuun ja päinvastoin sekä tehnyt jaetun hakemiston, jonka avulla voin siirtää tiedostoja koneiden välillä. Tähän mennessä nämä toimenpiteet ovat kätevöittäneet Xubuntun pyörittämistä huomattavasti.

Viikonlopun aikana olen myös lataillut jo kaikenlaisia Xubuntun ulkonäköä piristäviä teemoja ja ikonipaketteja. Olen melko pettynyt siihen, että yksikään löytämäni ikonipaketti ei miellytä minua täysin. Kännykkääni olen ladannut mukavan minimalistiset ikonit, jotka näkyvät seuraavan kuvakaappauksen alalaidassa:

Kovasta etsimisestä huolimatta en kuitenkaan löytänyt vastaavaa ikonipakettia Linuxille, ja sen sijaan suurin osa tarjolla olevista paketeista sisälsi vaikka minkälaisia riemunkirjavia palluroita, joista en välittänyt ollenkaan. Mutta vaikka nämä visuaaliset jutut nyt ovatkin sydäntäni lähellä niin palataanpa itse aiheeseen.

Ohjelma 0 – cool-retro-term

En tiedä, lasketaanko terminaaliemulaattoreita tässä yhteydessä ohjelmiksi, mutta haluan kuitenkin esitellä löytämääni retroterminaalia, jonka onnistuin pitkällisen hampaiden kiristelyn myötä asentamaan eilen. Kurssimme raportointisääntöjen mukaan tätä ei kuitenkaan lasketa, sillä raportointi pitäisi aina tehdä reaaliajassa eikä jälkikäteen. Alla olevassa kuvassa näkyy retroterminaalin lisäksi myös virtuaalikoneeni ”rauta”.

Halukkaat voivat hankkia cool-retro-term:in esimerkiksi täältä.

Löytämieni ohjeiden perusteella (jotka luonnollisesti löysin vasta kun olin asentanut kyseisen terminaalin suoraan lähdekoodista) sain sen käsityksen, että retroterminaali olisi mahdollista käynnistää myös suoraan työpöydältä, mutta yrittäessäni saan virheilmoituksen, jossa sanotaan ”Failed to execute child process ”cool-retro-term” (No such file or directory)”. Epäilen, että ohjeissa mainittu komento

  $ sudo cp cool-retro-term.desktop /usr/share/applications 

edellyttää, että terminaali on asennettu eri hakemistoon, kuin mihin sen itse asensin. Täytynee yrittää selvittää asiaa joskus tuonnempana. Tällä hetkellä saan retroterminaalin auki vain Xubuntun omasta terminaalista käsin, ja minun pitää kääntää ohjelma ennen sen ajamista.

Ohjelma 1 – Nethack

Mutta nyt muihin ohjelmiin. Kävin uteliaisuuttani vilkuilemassa jo ensi viikon materiaaleja, jotka liittyivät komentoihin. Esimerkeissä asennettiin Nethack-niminen peli, jonka koukuttavuudesta opettajamme Tero Karvinen varoittelee sivuillaan kovasti. Koska elän elämääni veitsen terällä, halusin ottaa selvää, millaisesta pelistä on kyse.

Asensin pelin komennolla

$ sudo apt-get install nethack-console

 ja navigoin kansioon /usr/lib/games/nethack, jossa annoin komennon ”nethack”. Harkitsin valitsevani roolikseni turistin omasta kokemattomuudestani johtuen, mutta tulin toisiin aatoksiin kun ajattelin, miten tulisin pärjäämään taistelussa. Valitsinkin siis Rangerin, koska kaukaa hyökkääminen tuntui suhteellisesti turvallisemmalta vaihtoehdolta. Tein myös muut valinnat, ja lopulta hahmokseni tuli chaotic male orcish Ranger.

Peli vaikutti kiinnostavalta, mutta ongelmakseni muodostui se, ettei omassa näppäimistössäni ole kirjaimia näppäinhatuissa. Normaalia kirjoitusta niiden puuttuminen ei haittaa, mutta yksittäisten symbolien käyttö on hieman hankalaa. Kaipailin jonkinlaista manuaalia, jossa olisi selitetty erilaiset komennot, mutta en saanut sellaista auki. Onnistuin kuitenkin saamaan pelin roastaamaan minua: ”This ugly creature is called helkera and cannot be renamed”. Tämä jo yksinään teki pelistä loistavan kokemuksen, vaikken kunnolla pelaamaan päässytkään. Ehkä näin oli parempi, ja addiktion muodostumiselta vältyttiin.

Löysin googlettamalla Nethackin komentoja, ja epäilen, että koneeni virtuaalisuus saattoi olla osatekijänä siihen, että esimerkiksi lopetuskomento, jonka wikin mukaan pitäisi olla alt + q, ei toiminut minulla ollenkaan.

Ohjelma 2 – VLC media player

Seuraavaksi päätin kokeilla VLC-playerin asentamista, koska se on lempiohjelmani videoiden toistamiseen. Vaikka olisin voinut päätellä asentamisprosessin kulun, googletin silti ohjeen varmuuden vuoksi. Jaoin myös Windowsista käsin yhden omista videotiedostoistani testin vuoksi Xubuntulle. Olin varautunut siihen, että minun olisi pitänyt erikseen asettaa VLC-player oletussoittimeksi, mutta niin minun ei tarvinnut tehdä. Videota katsellessani huomasin, että ääni ei kuulostanut täysin normaalilta ja se pätki hieman. Luulisin, että tämä saattoi ehkä liittyä koneen virtuaalisuuteen tai mahdollisesti ajurien puutteeseen.

Ohjelma 3 – QMMP

Halusin tutkia tätä ääniasiaa enemmän, joten seuraavaksi päätin asentaa Winampin, jota yleensä käytän esimerkiksi audiokirjojen kuuntelemiseen. Nopean googletuksen jälkeen huomasin kuitenkin, että ilmeisesti Winamp ei sellaisenaan toimi Linuxilla, mutta sitä korvaamaan on tehty QMMP-niminen soitin. Päätin siis kokeilla sen asentamista löytämieni ohjeiden perusteella. Ohjeissa jostain syystä tästä soittimesta käytetään kuitenkin Winamp-nimitystä ilmeisesti yksinkertaisuuden vuoksi.

Käyttämäni komennot olivat siis:


$ sudo add-apt-repository ppa:forkotov02/ppa
$ sudo apt-get update
$ sudo apt-get install qmmp qmmp-plugin-pack
$ qmmp


Ohjeet ovat melkein kolme vuotta vanhat, joten omaan terminaaliini tuleet tekstit olivat hieman erilaiset, mutta ohjelma lähti toimimaan ongelmitta. Oma soittimeni oli tosin pienen pieni, ja niin tumma, että siitä oli hyvin vaikeaa saada mitään selvää. Koko-ongelman sain ratkaistua, mutta siinä missä Winampilla on useampi teema ja noin miljoona värivaihtoehtoa, QMMP-soittimella ei vaikuttanut olevan kuin yksi. Niitä saisi lataamalla ilmeisesti lisää, mutta kaikki löytämäni olivat vielä rumempia, joten näillä mennään. Linuxilla on varmasti parempia musiikkisoittimia, perehdyn mielummin niihin tulevaisuudessa ja tyydyn nyt vain QMMP:n testaamiseen kun sen nyt satuin jo asentamaan.

Jaoin Xubuntulle kappaleen ja avasin sen QMMP:llä. Valitettavasti tulokset olivat äänen suhteen samanlaiset kuin aikaisemmin videota katsellessani. Ääni siis pätki ja särkyi ja kuulosti omituisen lattealta. Päätin googlettaa, onko muilla ollut vastaavia ongelmia, ja ainakin tämän sivun perusteella vaikuttaisi siltä, että aavistukseni virtualisoinnin osallisuudesta tässä ongelmassa osui oikeaan. Vaikuttaa siltä, että VirtualBoxilla on yleisesti ottaen ongelmia ääniajureihin liittyen. Minua tämä nyt ei varsinaisesti haittaa, sillä voin kuunnella musiikkia omalla koneellani samalla kun pyörittelen virtuaalista Xubuntua toisessa näytössä.

Tehtävä 3 – lisenssit

Seuraava tehtävä käsittelee lataamieni ohjelmien lisenssejä, ja sitä millaisia oikeuksia ja velvollisuuksia niihin liittyy.

Nethackin Wikipedia-artikkelin mukaan Nethack käyttää omaa avoimen lähdekoodin Nethack General Public -lisenssiä, joka pohjautuu Richard Stallmanin kirjoittamaan GNU bison -lisenssiin, joka puolestaan on GNU General Public -lisenssin edeltäjä. Tämä tarkoittaa siis sitä, että Nethackin lähdekoodia voi vapaasti jakaa ja muokata. Lisenssiin on myös kirjattu kohta, joka varmistaa, ettei alkuperäisiä tekijöitä voida haastaa Nethackin koodin tiimoilta oikeuteen.

VLC-playerin lisenssikuviot vaikuttavat huomattavasti mutkikkaammilta. Mikäli nyt luen VLC:n Wikipedia-artikkelia oikein, ainakin osa VLC:stä käyttää nykyään GNU Lesser General Public -lisenssiä. Ilmeisesti VLC:tä vaivasivat vanhan vapaamman lisenssin alaisuudessa yhteensopivuusongelmat esimerkiksi Applen App Storen kanssa. GNU General Public-lisenssiin verrattuna tämä uusi rajatumpi lisenssi mahdollistaa loppukäyttäjälle tiettyjen ohjelmiston osien lähdekoodin muokkaamisen, mutta ei sen täyttä vapaata käyttöä.

QMMP-soitin puolestaan käyttää yksiselitteisesti GNU General Public -lisenssiä, joka mahdollistaa sen, että loppukäyttäjä voi käyttää, opiskella, jakaa ja muokata ohjelmistoa haluamallaan tavalla. GNU GPL:ää käyttävä taho ei saa asettaa ohjelmansa käytölle rajoituksia, jotka ovat ristiriidassa lisenssin kanssa, tätä rikkova tapaus saattaisi esimerkiksi olla ohjelmiston levitys salassapitovelvollisuuden alaisuudessa.

Tehtävä 4 – käyttämieni ohjelmien Linux-vastineet

Seuraavana ja viimeisenä (virallisena) tämän viikon tehtävänä on listata, mitä ohjelmia normaalisti Windows-ympäristössä käyttää, ja etsiä niille vapaat Linux-vastineet. Löysin googlettamalla kivan aiheeseen liittyvän Wiki-sivun, josta haen hieman inspiraatiota.

Koulutöitä tehdessäni tulen normaalisti käyttäneeksi Office-paketin tuotteita, joille Linux-vastineen tarjoaa Libre Office. Tekstinkäsittelystä vastaa LibreOffice Writer, taulukkolaskennasta LibreOffice Calc, ja kalvosulkeisia voi kehitellä LibreOffice Impressillä. Ilmeisesti Microsoft Teamsin kanssa tilanne on kuitenkin hankalampi. Ainakaan tämän artikkelin mukaan mitään varmaa ei asiaan liittyen Microsoftin taholta ole luvattu, ja vaikuttaa siltä, että Linux-natiivi Teams client saattaa joko olla tulossa tahi sitten ei. Slackilla puolestaan on Linux client, mutta se ei paljoa lämmitä, mikäli muut tiimiläiset käyttävät Microsoft Teamsia kollaboraatiotyökalunaan.

Nettiä olen tottunut selailemaan Chromella ja se toimii onneksi myös Linuxilla. Windowsilla käytän tiedostojen lataamiseen uTorrenttia, jonka lupaavimmalta vaikuttava korvaaja Linuxin puolella on mielestäni Ktorrent. Skypeä en mielellään käyttäisi edes aseella uhattaessa, mutta onneksi Discord on saatavilla myös Linuxille.

Photoshopia vastaava kuvien muokkaamiseen tarkoitettu avoimen lähdekoodin Linux-ohjelma on GIMP, josta olen kuullut paljon, mutta jota en ole kunnolla ikinä käyttänyt. Muistaakseni testasin sitä kerran noin kymmenen vuotta sitten, jolloin se ei ainakaan tehnyt minuun erityistä vaikutusta, mutta kymmenessä vuodessa mikä tahansa tuote voi kehittyä vaikka kuinka paljon, joten ehkä minun pitäisi antaa GIMPille uusi mahdollisuus lähitulevaisuudessa.

Ilmeisesti Linuxilla pelaaminen on hieman kinkkisempi juttu. Vaikka Steam itsessään toimii Linuxilla, kaikista Steamin peleistä ei voi sanoa samaa (Lähde). Itse kuitenkin käytän Steamia lähinnä chattaamiseen, joten sen toimivuus ei ole minulle erityisen kriittistä. Samaa taas en voi sanoa World of Warcraftin toimivuudesta. Tämän artikkelin mukaan Blizzard ei ole koskaan virallisesti tukenut Linuxia, ja DirectX 11:sta siirtymisen jälkeen erilaiset graafiset ja toiminnalliset bugit, Battle.netin toimimattomuus ja huono framerate ovat vaivanneet WoWia pelaavia Linux-käyttäjiä. Nykyään WoWin toiminta edellyttää Linuxilla erillisen Lutris-nimisen väliohjelman käyttöä, ja vaikka tämä mahdollistaa ilmeisesti hyvän pelikokemuksen, ainakin asennusvaihe vaikuttaa mielestäni hieman mutkikkaalta. Artikkelissa ei myöskään kommentoida mahdollisia addonien asentamiseen liittyviä hankaluuksia.

Huh! Kylläpä tästä päivityksestä tuli pitkä. Varmasti vähän liiankin pitkä, mutta olen aina ollut poikkeuksellisen huono kirjoittamaan mitään lyhyesti, varsinkin silloin kun olen innoissani jostain. Ja Linux kieltämättä vaikuttaa hyvin kiinnostavalta jo tämän lyhyen pintaraapaisun jälkeen! Tietyllä tavalla koen jopa halua vaihtaa Linuxiin, mutta en osaa sanoa, kuinka suuri osa tästä tunteesta liittyy siihen, että ruoho on aina vihreämpää aidan toisella puolella. Käytännössä vaihtaminen voisi olla hankalaa, ja todennäköisesti edellyttäisi joka tapauksessa virtuaalisen Windowsin ajamista niitä tilanteita varten, kun pitää tehdä jotain sellaista, mikä ei Linuxin puolella onnistu. Saas nähä!

Hello World!

Tässä blogissa tulen käsittelemään juuri aloittamani Linux-palvelimet -kurssin sisältöä ja raportoimaan, miten kurssitehtävien tekeminen sujuu. Kurssin jälkeen (tai sen aikana, en lupaa mitään) saatan kehittää blogia myös muihin suuntiin mikäli tässä parin kuukauden aikana pääsen bloggaamisen makuun uudestaan kiinni. En ole kirjoittanut vapaamuotoista blogitekstiä pitkään aikaan, joten olen hieman ruosteessa, mutta eiköhän tämä tästä lutviudu kunhan pääsen alkuun.

Tänään keskityin lähinnä laittamaan blogin pystyyn, tehtäviä alan tutkailemaan tarkemmin vasta lähipäivinä. Nyt ainakin blogin yleinen ulkoasu näyttää suhteellisen järkevältä. Tyylilleni uskolliseen tapaan en voinut vastustaa puoliabstraktin rakeisen taustakuvan käyttöä. Siitä ei ehkä huou erityisen tietoteknistä tunnelmaa, mutta sen ei pitäisi menoa haitata.

Unohdin tänään ostaa kaupasta USB3-tikun, jota voisin kurssin aikana käyttää Xubuntu-livetikkuna. Kirosin asiaa kotiin tullessani, mutta myöhemmin tajusin, ettei minun wanhassa läppärissäni ole edes USB3-portteja, joten tuskin hyötyisin ekstranopeudesta muutenkaan.

Ajattelin, että voisin kokeilun vuoksi asentaa kotikoneelleni VirtualBoxin ja sen kautta Ubuntua pyörittävän virtuaalikoneen Linux-kurssin tehtävien tekemistä varten. Virtualisoinnista ei kuitenkaan ollut puhetta ensimmäisellä tunnilla, enkä tajunnut asiasta vielä kysyä, joten en ole täysin varma, onko virtualisointi toivottua tässä yhteydessä. En näe syytä, miksei, mutta Linux-tietouteni on sen verran olematonta, että minun on epäilemättä parempi varmistaa asia ensi tunnilla.

Perehdyin tänään omaksi ilokseni hieman myös erilaisiin Linuxin työpöytäympäristöihin. Tunnilla opettaja kertoi suosivansa Xubuntua, joka tuo mukanaan Xfce-työpöytäympäristön. Kaikenlaisista kustomointimahdollisuuksista innostuvana henkilönä haluaisin kuitenkin kokeilla ehkä muutamaa muutakin työpöytäympäristöä Xfce:n lisäksi siltä varalta että jokin niistä tuntuisi joko luotevammalta käyttää tai miellyttäisi silmääni enemmän. Hölmönä haikailen lähinnä tämäntyyppisen estetiikan perään:

Lähde: https://awesomewm.org/images/screen.png

Tiedostan kuitenkin, että en ole sellaisessa tilanteessa, jossa minun olisi relevanttia pitää noin montaa äärimmäisen informatiivista ikkunaa auki, mutta kyllähän tuo nyt siistiltä näyttää. Kyseessä ei itseasiassa teknisesti ottaen ole edes varsinainen työpöytäympäristö, vaan ikkunoidenhallintatyökalu, jota kuitenkin voi ilmeisesti käyttää alkeellisemman työpöytäympäristön tavoin.

Rehellisesti sanottuna minusta tuntuu, etten ole ikinä oikeasti päässyt yli siitä, kun teinimpänä pääsin naapurin koneella leikkimään WindowBlinds-ohjelmalla. Muistan vaihtaneeni koneen kursorin animoiduksi pikselidinosaurukseksi, joka ei ollut erityisen käytännöllinen, mutta sitäkin viihdyttävämpi.