Spämm läbi Magento uue kliendi tervituskirja

Viimasel ajal on sagenenud Magento e-poe kliendikontode registreerimise vormi kasutamine spämmi saatmiseks: nimeks pannakse kuni 255 tähemärki teksti ning e-postiks soovitud adressaat, kohale toimetab selle aga uue kliendi tervituskiri.

Avastasime selle probleemi, kuna enamus spämmist oli suunatud Venemaale ning posti kohaletoimetamine mail.ru aadressidele häiritud. Parema spämmituvastuse rakendamisel ja veebiservitest kirjade saatmist piirates tulid esile nimelt Magento 1.x kasutavate e-poodide domeenid.

Tegemist ei ole seejuures klassikalise nõrkusega koodis, samuti ei ole vaja karta, et keegi oleks poodi sisse häkkinud: lihtsalt üks vajalik funktsionaalsus on osutunud ärakasutatavaks ja selle turvalisusega seotud vaikesätted liiga nõrgaks.

Magento klientide halduses näeb ühe kampaania spämm välja selline:

Siht-veebina on nimelahtris olevas tekstis osavalt ära kasutatud Google “I feel lucky” funktsionaalsus ja spetsiifilisele märksõnale optimeeritud saidid, mistõttu ei tundu ka link spämmifiltritele kahtlane (allolevat näidet on turvaline klikkida, piltidel olevaid mitte):

https://www.google.ee/#btnI=koli-suveks-meile&q=zone%20virtuaalserver

Kuidas see sind mõjutab?

Kui meie jaoks on probleemiks väljuva spämmi ohjeldamine ning teiste klientide posti kohaletoimetamise tagamine, siis poodniku jaoks on lugu hullem:

  • serverist e-posti saatmise piiramisel ei lähe kohale ka tellimused, parooli-vahetuse kirjad jms teavitused;
  • spämm saadetakse välja e-poe domeenilt, tõenäoliselt mõjutab see spämmifiltrite tööd mitmetes e-postisüsteemides;
  • tagasipõrkav post võib ummistada poodniku postkasti.

Kuidas ennast spämmi-bottide eest kaitsta?

Kliente ei registreeri mõistagi keegi käsitsi, vaid seda tehakse skriptidega, mis postitavad vajalikud andmed otse veebirakendusse (POST /customer/account/createpost/). Sellise ründe vastu kaitsmiseks sobib hästi CAPTCHA robotilõksu lahendamise nõue.

Magento CAPTCHA (võib olla ebapiisav)

Osade allikate väitel võib olla abi Magento enda CAPTCHAst (olemas versioonist 1.7), kui see on piisavalt rangeks seadistatud. Admin-paneelis tuleb selleks minna System -> Configuration -> Customer Configuration -> CAPTCHA valikusse ja panna paika:

  • Enable CAPTCHA on FrontendYes
  • Forms – vali ainult Create User
  • Displaying ModeAlways
  • Number of Symbols – võib olla vaja suurendada

Tulemuseks on selline lisaväli registreerimisvormil.

Kuna enamus kliente registreerub ostuprotsessi käigus ja Register during checkout pole valitud, siis ei tohiks CAPTCHA oluliselt müüki mõjutada ning selle võiks peale panna nüüd ja kohe, sest pärast spämmirahe alla sattumist tegutsema hakates on osa kahju juba tehtud ning kliendibaas vajab puhastamist.

Amasty Google invisible reCaptcha (tasuline, töötab kontrollitult)

Kuivõrd Magento CAPTCHA pole eriti inimsõbralik ja osade rünnete osaks pidavat olema ka selle pealt teksti tuvastamine, siis tasuks eelistada tasulist lahendust ja reCaptcha’t. Nii Magento 1.x kui ka 2.x jaoks on saadaval Amasty Google invisible reCaptcha, mis maksab vastavalt 45 või 65€. Seda on kasutanud mitmed arendajad meie juures olevate Magentode kaitsmiseks ning tulemus on siiamaani olnud positiivne.

Spämm-kasutajate kustutamine

Kui spämmi saatmine on juba toimunud, siis tuleks tuhanded loodud kasutajad ka ära kustutada. Sonassi veebis on viide selleks sobilikule shelliskriptile (see on käivitatav käsurealt, mitte veebist) ning selle kasutamisõpetus.

Mida veel teha saaks?

Kui arendajal on sinu pood juba ette võetud, siis tasuks samasse töökäsku panna ka Magento ja kõikide lisade uuendamine, sest eriti just 1.x puhul on aastate jooksul ilmnenud rida probleeme, mis lubavad kurikaeltel nii adminnina sisse logida kui ka neile meelepärast koodi käivitada (mõlemal puhul on tulemuseks poe täielik ülevõtmine).

Hetkel värskeima versiooni leiad muudatuste logist:

Oma Magento turva-auke saab tasuta skannida MageReport abil. See ei pruugi alati anda täpset tulemust, küll aga on teaduslikult tõestatud, et punaste hoiatuste nägemine aitab leida uuenduste tegemiseks vajalikku raha.

Ja loomulikult HTTP “pole turvaline” ehk kuidas veeb HTTPS peale suunata?  (sealt leiab viite ka Magento seadistamise juhendile ja videole).

HTTP “pole turvaline” ehk kuidas veeb HTTPS peale suunata?

Google on võtnud eesmärgiks jõuda 2018 aasta lõpuks olukorrani, kus turvaline HTTPS ühendus on standard mida ei pea brauseri aadressi-ribal eraldi esile tooma. Sellega kaasneb paraku see, et ebaturvalist HTTP-ühendust kasutavad veebid saavad endale külge märke “Pole turvaline”.

Sellist teadet hakkab kuvama juba juulis ilmuv Google Chrome versioon 68:

Oktoobris ilmuvas Chrome versioonis  70 saab see teade olema ka punasega esile toodud, kui kasutaja veebilehel midagi sisestama hakkab:

Midagi uut selles ei ole, näiteks 2017 jaanuaris oleme kirjutanud blogis Chrome 56, “Not Secure” HTTP ja kuidas kolida HTTPS peale ning makseandmeid käsitlevate veebide puhul nõutakse juba ka HTTPS puhul vanemate standardite välistamist:  30. juunist jõustub e-kaubanduse jaoks oluline HTTPS nõue. Kuigi meie serverite liiklusest on üle poole HTTPS, kasutab umbes 2/3 meie (väiksemate) klientide veebidest endiselt HTTP-ühendust.

Miks HTTPS vajalik on?

Turvamata ühenduse puhul on näiteks WiFis võimalik salvestada kõik kasutaja brauseri ja serveri vahel liikunud info, sh kasutajanimed ja paroolid, samuti on mitmeid võimalusi kasutaja võlts-lehele suunamiseks. See pilt on tehtud salvestades WiFi-liiklust:

Kuidas HTTPS veebiühendust kaitseb?

Kahel moel:

  1. veebibrauseri ja serveri vaheline side krüpteeritakse (šifreeritakse)
  2. enne iga ühenduse loomist kontrollib brauser, et ta suhtleks ikka õige serveriga – sest kui liiklust saab “pealt kuulata”, siis saab ilmselt ka “vahele rääkida”

Kuidas oma veeb turvalise HTTPS peale suunata?

Me oleme proovinud kõik HTTPS kasutuselevõtuga seonduva võimalikult lihtsaks teha ja ära automatiseerida. Enamus järgmistest sammudest tähendab vaid ühte klõpsu Minu Zone iseteeninduses:

  1. TLS sertifikaati tellimine – me toetame tasuta Let’s Encrypt sertifikaate, nende väljastamine ja uuendamine on täielikult automatiseeritud. Kas aga tasuta on piisavalt hea? Sama sertifikaati kasutab näiteks Majandus- ja Kommunikatsiooniministeerium, seega kui sobib valitsusasutusele sobib ka Sulle!
  2. Veebiserveri seadistamine selle sertifikaadi ja HTTPS ühenduse kasutamiseks. Automatiseeritud!
  3. Veebirakenduse (WordPress, Magento jt) seadistamine võib vajada veidike seadistuste muutmist ja teatavatel puhkudel ka pisiparandusi koodist. Vaata allolevaid juhiseid ja kui hätta jääd, kirjuta info@zone.ee (hüva nõu saame jagada niisama, aga kui on reaalselt vaja aega panustada, siis küsime tunnihinda).

Me oleme teinud üksikasjalikud juhised levinumate veebirakenduste seadistamiseks mis sisaldavad nii punkt-haaval lahti kirjutatud tegevusi kui video-õpetust:

Erijuhendita rakenduste puhul võib alustada nupust Suuna liiklus HTTPS peale:

Sertifikaadi tellimine ja aktiveerimine võtab reeglina umbes 10 minutit aega. Kui see ei õnnestu või veeb uues olukorras ei toimi, saab suunamise samast välja lülitada, veeb jätkab tööd HTTP ühenduse peal ning HTTPS korda tegemisega võib rahulikult edasi tegeleda.

Kui täis-automaatne protsess riskantne tundub, siis võib mõistagi ka lisada Let’s Encrypt sertifikaadi, veenduda ca 10 minuti pärast HTTPS toimimises, teha veebirakenduses muudatused ja seejärel lisada kogu liikluse suunamise:

Ja nagu öeldud – kui tekib küsimus, siis võid kasutada postituse kommentaare või kirjutada info@zone.ee ja nõu küsida. Aga võid tulla ka meie help-zone Slack’i chatti 😉

30. juunist jõustub e-kaubanduse jaoks oluline HTTPS nõue

Käesolev blogipostitus on peatähtis läbi lugeda neil, kes tegelevad oma kodulehe vahendusel kaubandusega, kuid see on kindlasti oluline teadmiseks võtta ka teistele.

30. juunist ei luba Payment Card Industry Data Security Standard (PCI DSS) makseandmeid käsitlevate veebilehtede omanikel enam kasutada aegunud SSL/TLS turvastandardeid.

Selliste lehtede haldajad peaksid 30. juuniks veenduma, et nende HTTPS ühendused oleksid seadistatud järgmiselt:

1) SSL standardi kasutus peab olema täielikult keelatud;
2) kasutusel olev TLS protokoll peab olema vähemalt 1.1 või uuem.

Zone klientidel on hetkel seis selline:

1) SSL standardi kasutus on täielikult keelatud;
2) vaikimisi kasutusel olev TLS protokoll on 1.0 või uuem.

Rõhutan, jutt on konkreetselt SSL standardist! SSL-i terminit kasutatakse nii meil kui mujal (valesti) iseloomustamaks paljusid turvatud ühendusi, kuigi enamik neist põhineb tänapäeval juba TLS standardil.

Meie hoolsatel, turvateadlikel ja standardiga ühilduvust soovivatel klientidel on aga võimalus haldusliideses paari klikiga keelata vanemate TLS versioonide kasutamine. Selleks tuleb Virtuaalserveri haldusliideses Veebiserveri seadete alt muuta sätet “Luba aegunud TLS versioonide kasutamine”.

Võib kerkida küsimus, miks me TLS 1.0 kasutust üldiselt ära ei keela? Põhjus peitub selles, et interneti sügavustes eksisteerib veel mitu kihti internetti, üks neist on nö “asjade internet” ja teine “skriptide internet”. Need on internetikihid, millel püsib hoomamatu hulk meid ümbritsevaid protsesse ja milles iga suurem muudatus tähendab meie klientide jaoks ettearvamatuid tagajärgi.

Asjad, mis TLS 1.0 keelamisega võivad näiteks veebile ligipääsu kaotada:

* vanemad mobiiltelefonid;
* vanemad või odavamad käsiterminalid;
* vanemad või odavamad multimeediakeskused;
* vanemad operatsioonisüsteemid ja nende veebilehitsejad;
* vanemad skriptid ja programmid.

Ülevaatlikku tabelit erinevate seadmete TLS ühilduvusest üritab pakkuda muuhulgas GlobalSign.

Üks sarnane varasem iidvana protokolli toe lõpetamine on meie jaoks  näiteks lõppenud kõnega ühest logistikafirmast, mille käsiterminalid lõpetasid lennujaamas töö.

Erinevatel andmetel moodustab TLS 1.0 liiklus hetkel 5-11% kogu HTTPS-i abil turvatud ühenduste mahust.

Seetõttu oleme otsustanud, et jätame vanema TLS versiooni (TLS 1.0) kasutamise keelamise esialgu kliendi otsustada ning lükkame selle vaikimisi välja lülitamise veidi edasi, kuni teadlikkus on klientide hulgas veidi kasvanud.

Põhjus, miks PCI on otsustanud vanemate turvastandardite toetamise keelata peitub nende vanuses.

SSL (Secure Sockets Layer) on standardina olnud maha kantud juba tükk aega tagasi, kuid lühend ise elab turvatud ühendusi sümboliseeriva terminina inimeste teadvuses veel edasi. Reaalsuses lasti selle standardi viimane suurem versioon välja 1996. aastal ning aastast 2015 on selle kasutus sisuliselt keelatud (https://tools.ietf.org/html/rfc7568).

SSL-i asendas 1999. aastal standard TLS (Transport Layer Security) versiooniga 1.0 ning sellele on järgnenud versiooniuuendused 1.1 (2006 aastal) ja 1.2 (2008 aastal). 2018. aasta märtsist eksisteerib, peale pikka ja vaidlusterohket arendustööd, standardi mustandina ka TLS versioon 1.3, kuid selle laiemasse kasutusse jõudmine võtab veel veidi aega.

Mõlemad on olnud haavatavad tänu mitmetele nõrkustele, mis kandnud vahvaid nimesid nagu POODLE, BEAST, FREAK, BREACH, CRIME jt ning nende ja muude selliste aukude lappimine ei ole lihtsalt jätkusuutlik.

Sinu, minu, meie andmed ehk vastutav ja volitatud töötleja

Postkaste tabanud kirjadelaviin hakkab vaibuma ning kõik, kes seni ilma mõistliku aluseta andmeid töötlesid, on loodetavasti vastuse küsimusele “Kas me oleme ikka päriselt sõbrad, ütle jah?” kätte saanud või andmed hoolsasti ära kustutanud. Projektiplaani on joonistatud suur roheline linnuke “GDPR – tehtud!” ning elu läheb vanamoodi edasi.

Oleks vaid asi meie suhtega niisama lihtne… sest meil on ju andmed! Minu andmed, Sinu andmed, meie andmed ning lisaks nendega seotud ootused, lootused ja lubadused. Kes vastutab, kes kamandab, kes otsustab, keda volitab andmetega tegelema? Me peame sellest rääkima!

Kui lugemine tundub igav, siis võid vaadata ka ettekannet, mille tegin 22. mail toimunud Andmekaitseinpsektsiooni ja TTÜ teabepäeval ja kus räägin enam-vähem sama juttu.

Mis andmetest Sa räägid?

Peamiselt isikuandmetest. Zone teenustega seoses võiks need jagada kolmeks:

  • kliendiandmed (üks sõna) – enamasti seotud kliendikonto ja registreeritud domeenidega ning vajalikud teenuste osutamiseks (nt kontaktisiku andmed ja kontoga seotud tegevused); Zone on vastutav töötleja;
  • kliendi andmed (kaks sõna, laiema mõistena kliendi infovarad) – kõik see, mille Zone klient on teenuste kasutamise käigus serveri(te)sse üles laadinud või mis on tekkinud serveri(te) kasutamise käigus, näiteks registreerunud kasutajad ja e-poe tellimused, suhtlus ja logid; klient on vastutav töötleja, Zone on volitatud töötleja;
  • kasutusandmed – Zone infrastruktuuri ja teenuste turvalisuse tagamiseks, analüüsiks või arenduseks kogutavad andmed, nt erinevad logid ja analüütikalahendused, mis võivad sisaldada andmeid kasutajate ehk otseselt või kaudselt tuvastatavate füüsiliste isikute kohta; Zone on vastutav töötleja.

Kliendiandmete ja kasutusandmetega on lihtne: Zone on vastutav töötleja, need käivad meie privaatsuspoliitika alla, meil on paigas infoturbe juhtimissüsteemi põhimõtted ning protsessid privaatsuse ja eraelu puutumatuse tagamiseks (nt ligipääs andmetele on rangelt piiratud töökohustuste täitmisega, iganenud andmed kustutatakse jne), meie poolt kasutatavad volitatud töötlejad on hoolega valitud ja nimekiri veebis näha ning keskkasutajalepingu ja teenuste üldtingimuste punktid 9 ja 10 on senisest veidi põhjalikumalt lahti kirjutatud kasutades üldmäärusega sobituvat sõnastust. Kui on mingi mure, võid kirjutada andmekaitse@zone.ee, see jõuab joonelt Peeter Marveti (andmekaitsespetsialisti rollis) ja Ardi Jürgensi (infoturbejuhi rollis) postkasti. Kõik asjassepuutuvad viited leiab zone.ee veebi jaluses viidatud Isikuandmete kaitse (s.h GDPR) lehelt, sealt asub ka mõnede suuremate organisatsioonide poolt vajalikuks peetava isikuandmete lisakokkuleppe vorm (meie hinnangul täidab ka keskkasutajaleping kõik nõudmised ning see pole tegelikult vajalik).

Kliendi andmete osas on lugu aga keerulisem – kuna andmed on salvestatud meie serverisse ja liiguvad meie võrgus, siis oleme paratamatult volitatud töötlejaks. Serveriteenuse olemusest lähtuvalt me aga ei tea, mis andmeid klient meie serveris töötleb ja käsitleme neid kui “potentsiaalselt isikuandmeid” (ehk ülima ettevaatlikkusega). Ja klient on vastutav töötleja.

Vastutav… mille eest?

Vastutav töötleja on see, kes “määrab kindlaks isikuandmete töötlemise eesmärgid ja vahendid” ning “rakendab […] asjakohaseid tehnilisi ja korralduslikke meetmeid, et tagada ja suuta tõendada isikuandmete töötlemist kooskõlas [isikuandmete kaitse üld]määrusega” (ehk GDPR-iga).

Kes tahab põhjalikumat ülevaadet, see vaatab AKI Isikuandmete töötleja üldjuhendit

Praktikas tähendab see ennekõike seda, et klient:

  • omab ülevaadet töödeldavatest andmetest: mida täpselt kogutakse, mis eesmärgil, millisel alusel, kaua säilitatakse, kuidas turvatakse ja kellele edastatakse;
  • paneb selle kõik “mehele Kopli trammis” arusaadavalt andmekaitsetingimustesse (“privaatsusteade”) kirja;
  • oskab vastata küsimusele “mis andmeid te minu kohta töötlete?” ning suudab need soovi korral masinloetavalt väljastada või ära kustutada;
  • on volitatud töötlejate valikul olnud hoolas ning nendega töötlemise tingimustes kokku leppinud (kirjalikult);
  • teab mida teha juhul, kui peaks juhtuma andmeleke.

Praktika läks vist ikka veidi teoreetiliseks – proovime veelkord…

Praktiline näide: WordPress ja kontaktivorm

Üldistame ühe reaalse kliendiküsimuse, mis puudutas enam-vähem sellist olukorda:

  • Zone Virtuaalserver
  • paigaldatud WordPress
  • kontaktivorm: Gravity Forms (või Contact Form 7)
  • privaatsuspoliitika veebis olemas
  • kogutud kontaktid eksporditakse perioodiliselt turundus-assistendi poolt ja imporditakse kliendihaldustarkvarasse (nt Pipedrive) ja nõusoleku-linnukese olemasolul ka e-posti-turundus-lahendusse (nt Mailchimp)
  • samas Virtuaalserveris on ka üks vana kampaania-maandumisleht (Drupal, misiganes põhjusel)

Hakkame ülevalt pihta:

  • kasutajakonto loomisel nõustus klient Zone teenuste üldtingimustega ja sõlmis keskkasutajalepingu, see on kirjalik leping volitatud töötlejaga, milles on alati olnud punktid isikuandmete kaitse ning konfidentsiaalsuse kohta, uues versioonis oleme need ka täpsemalt lahti kirjutanud;
  • lepingu ja teenuse (eri)tingimuste alusel Zone poolt turvatav ja hallatav osa ulatub Virtuaalserveri puhul tarkvaraplatvormi ehk veebi- ja andmebaasiserverini ehk see “punane ala” on kaetud:

  • “halli ala” ehk WordPressi haldamine ja turvamine on aga tavapäraselt kliendi vastutus, loodetavasti on selleks tööks palgatud veebiagentuur või -meister ning vastutuse ja igakuise töömahu kohta leping sõlmitud;
  • ülejäänud teenused: Pipedrive kasutustingimused katavad üldmääruse nõuded kenasti ära ja tegu on EL ettevõttega, MailChimp on aga USAst ning nende puhul tasub veenduda Privacy Shield sertifikaadi olemasolus ning sõlmida andmetöötlust puudutava lisakokkulepe ehk data processing amendement.

Juriidiliselt peaks nüüd kõik korras olema, aga vaatame igaks juhuks ka sisulise/tehnilise poole üle:

Kuidas andmed liiguvad?

Kontaktivorm salvestab andmeid veebiga samasse andmebaasiserverisse:

  • andmed on näha WordPressis haldusliideses – kas sellele pääsevad ligi kõik kasutajad või ainult need, kellel on vaja?
  • andmed on WordPressiga samas andmebaasis – kas on kindel, et arendustööks WordPressi kopeerides ei satu need veebimeistri arvutisse?

Kontaktivorm saadab e-posti iga uue kontakti kohta:

  • kas e-postis sisaldub isikuandmeid või ainult teave uue kontakti kohta?
  • kas teavitus läheb ainult asjakohase töötaja e-postile või üldaadressile?

Kontaktid eksporditakse .csv faili ja imporditakse CRMi ja otseturunduslahendusse:

  • kas see tegevus on turvaline, mh assistendi arvutis viirusetõrje ja tugev parool?
  • kas allalaetud fail saab pärast importi kustutatud?
  • kas kontaktid kustutatakse pärast eksporti WordPressist (lõplikult, mitte ei satu “prügikasti”)?
  • kuidas on tagatud, et nt uudiskirjast loobumisel kajastub “nõusoleku tagasivõtmine” ka CRMis ja aadress nt mõne segmendi alusel uuesti otseturundust saama ei hakka?

Need sammud on hea meeles pidada, sest varem või hiljem tekib kellelgi küsimus:

Aga mis siis saab, kui juhtub andmeleke?

Tõepoolest, meil on ju varuks “must luik” ehk üks vana Drupal. Ilmselt on selles paikamata Drupalgeddon nime all tuntud haavatavus, see veeb häkitakse ühel päeval maha ja esilehele riputatakse ISISe lipp.

Kuna isikuandmed on sisuliselt “kõrvalkataloogis”, siis võib tegu olla ka isikuandmete lekkega ning tuleks hinnata selle mõju ning vajadusel teavitada Andmekaitseinspektsiooni ja lekkest puudutatud isikuid.

Veebiserveri puhul on seejuures üsna raske tuvastada, kas sissetungija midagi peale näotustamise veel tegi, aga üldmääruse kontekstis võiks kliendiandmete kopeerimine ja “tagasimüümine” olla kurjategijatele heaks lisateenistuseks.

Kuidas paremini teha?

Võimalusi on mitmeid – aga need kõik sisaldavad mingil moel avaliku veebi ja isikuandmete lahus hoidmist ning lepingut kellegagi, kes tagab turvalisuse:

  • alustame sellest, et levinud soov “paneme ühte Virtuaalserverisse kõik veebid kokku” ei ole riskide maandamise seisukohalt üldse hea mõte – kui häkitakse maha üks veeb on sisuliselt kompromiteeritud ka kõik ülejäänud ning nende puhastamine tükk tööd mille hind saab olema oluliselt suurem, kui eraldi Virtuaalserverite aastamaks;
  • kontaktide registreerimise saaks teostada ka nii, et veebilehel kuvatakse Pipedrive veebivormi (või Mailchimp’i oma) ning andmed lähevad otse nende vastutuse all olevasse serverisse – siis kaob kogu WordPressi ja veebiserveri probleem üldse ära;
  • … ning Pipedrive ning Mailchimpi ühendamisega tegeleb uus startup Outfunnel, mis on võtnud eesmärgiks lahendada ühelt poolt turunduse ja teiselt poolt andmekaitse küsimused.

Lisaks võib ka Zonega rääkida WordPressi (ja teiste veebirakenduste) haldamisest, aga selleks saab olema üks teine leping ning see on alles tegemisel 🙂

Küsida saab kommentaariumis – kui oskame, siis vastame (kui ei oska, siis õpime ja seejärel vastame).

Gitea – Alternatiiv GitHubile, mis töötab Zone Virtuaalserveris

See blogipostitus täidab kaht eesmärki: ühelt poolt on see ajendatud GitHubi ümber toimuvast, mis on pannud paljusid mõtlema võimalustele, kuidas oma lähtekoodi üle suuremat kontrolli omada; teiselt poolt demonstreerib see taas Zone Virtuaalserveri kasutusvõimalusi väljaspool sisseharjunud mustreid (antud juhul siis Go’s kirjutatud rakenduse majutamisel).

Mis on Gitea?

Gitea on GO’s kirjutatud avatud lähtekoodiga alternatiiv populaarsetele versioonihaldusteenustele Github ja Gitlab. Täpsemat infot Gitea kohta leiad aadressilt https://gitea.io/ ning põhjaliku dokumentatsiooniga saab tutvuda siin: https://docs.gitea.io/en-US/

 

Gitea logo

Nõuded Zone teenusele

Kasutusel peab olema Zone tarkvaraplatvormi kasutav server (kõlbab nii Virtuaalserver, Nutikas Pilveserver kui ka Nutikas Privaatserver). Käesolevas õpetuses on virtuaalserveri nimeks git.miljonivaade.eu

Virtuaalserveril peab olema eraldatud IP aadress portide suunamise tarvis. Pakett III sisaldab ühte tasuta eraldatud IP aadressi. Kui see aktiveeritud pole, tuleb ühendust võtta Zone klienditoega, kes selle tasuta aktiveerib.

1. Seadistame Zone virtuaalserveri

1.1 SSH

Kui teil on juba SSH ligipääs virtuaalserverile seadistatud võib jätkata punktist 1.2

Virtuaalserveri Haldus -> SSH -> Ligipääs

  • Lisame oma avaliku SSH võtme
  • Lubame ligipääsu oma IP aadressilt (või kõikjalt)

1.2 MySQL

Virtuaalserveri Haldus -> Andmebaasid -> MySQL

  • Lisame uue andmebaasi nimega d73643_gitea. Collation väljale valime utf8mb4_general_ci
  • Lisame uue kasutaja nimega d73643_gitea
  • Anname kasutajale d73643_gitea kõik õigused andmebaasis d73643_gitea

1.3 HTTP ligipääsu seadistamine (http proxy)

Virtuaalserveri Haldus -> Veebiserver -> Seaded HTTPS seadete all vajutame nuppu muuda

  • SSL/VHosti IP: XXX.XXX.XXX.XXX, mille väätuseks on virtuaalserverile eraldatud IP aadress.
  • Määrame mod_proxy sihtpordiks 3000
  • Ning vajutame Salvesta muudatused nuppu

 

1.4 Gitea SSH ligipääsu seadistamine GITile (portide suunamine)

Gitea kasutab oma sisest SSH serverit, mis annab võimaluse git repositooriumite ning kasutajate ligipääse Giteas endas hallata.

Virtuaalserveri Haldus -> Veebiserver -> Portide Suunamine

  • Lisa uus portide suunamine all tuleb täita väljad
    • IP: Valime Zone poolt eraldatud IP aadressi
    • Port: 2222
    • Kommentaar: gitea-ssh (vabalt valitud näidis)
    • Ning vajutan nuppu Lisa

HTTP proxy ja portide suunamise muudatused jõuavad serverisse umbes 10 minuti jooksul, aga DNS A kirje levimine eraldatud IP aadressile võib võtta ka üle tunni. Kui on soov rakendus enne kirjete levimist seadistada, siis võib IP enda tööjaama hosts faili lisada.

2. Paigaldame Gitea

2.1 Laadime alla ning paigaldame Gitea binaarfaili

Siseneme virtuaalserverisse SSH abil ning käivitame järgmised read:

mkdir domeenid/www.git.miljonivaade.eu/gitea
cd domeenid/www.git.miljonivaade.eu/gitea
wget -O gitea https://dl.gitea.io/gitea/1.4.2/gitea-1.4.2-linux-amd64
chmod +x gitea

Et Gitea esialgse konfiguratsioonifaili genereeriks, tuleb gitea korraks käivitada. Antud juhul see ebaõnnestub, aga tekitatakse custom/conf/app.ini fail.

Käivitame käsu:

./gitea web

Tulemus peaks olema järgmine:

2.2 Seadistame rakenduse konfiguratsioonid

Avame konfiguratsioonifaili

nano custom/conf/app.ini

Kogu sisu tuleb üle kirjutada järgnevaga:

RUN_USER = virt73403
RUN_MODE = prod

[database]
DB_TYPE = mysql
HOST = d73643.mysql.zonevs.eu:3306
USER = d73643_gitea
NAME = d73643_gitea

[repository]
ROOT = /data03/virt73403/domeenid/www.git.miljonivaade.eu/gitea/repositories

[server]
PROTOCOL = http
DOMAIN = git.miljonivaade.eu
HTTP_ADDR = 127.1.69.203
HTTP_PORT = 3000
DISABLE_SSH      = false
START_SSH_SERVER = true
SSH_PORT = 2222
SSH_LISTEN_HOST = 127.1.69.203

[log]
MODE      = file
LEVEL     = Info
ROOT_PATH = /data03/virt73403/domeenid/www.git.miljonivaade.eu/gitea/log

Virtuaalserveri põhised muutujad konfiguratsioonis:

  • RUN_USER – kasutaja, kelle õigustes rakendus käivitatakse. Selleks on virtuaalserveri SSH kasutajanimi.
  • database.HOST – andmebaasi hosti nimi, mille leiab Virtuaalserver Haldus -> Andmebaasid -> MySQL alampunktist. Lisaks tuleb määrata port, milleks on 3306.
  • database.USER – loodud MySQL kasutaja kasutajanimi.
  • database.NAME – loodud andmebaasi nimi.
  • repository.ROOT – asukoht, kuhu pannakse loodud repositooriumite andmed. Selle peaks määrama kujul: /dataXX/{ssh-kasutaja}/domeenid/www.{domeen}/vabalt/valitud/asukoht
  • server.PROTOCOL – konfiguratsioonis määrame protokoliks “http”, kuna HTTPS eest hoolitseb Zone seadistatud proxy.
  • server.DOMAIN – virtuaalserveri nimi ehk domeen.
  • server.HTTP_ADDR – virtuaalserveri loopback IP, mille saab teada kui käivitada virtuaalserveris SSH konsoolis käsk vs-loopback-ip -4.
  • server.HTTP_PORT – port, mille määrasime mod_proxy pordiks serveri seadetes.
  • server.SSH_PORT – port, mille määrasime portide suunamisel.
  • server.SSH_LISTEN_HOST – sama mis server.HTTP_ADDR.
  • log.ROOT_PATH – logifailide kataloog, mille võib määrata järgmiselt: /dataXX/{ssh-kasutaja}/domeenid/www.{domeen}/vabalt/valitud/asukoht

2.3 Paigaldame ning käivitame rakenduse

Pärast seda käivitame rakenduse uuesti

./gitea web

Ning kui kõik õnnestub, peaks pilt välja selline:

Veebiliides peaks tööle hakkama minnes aadressile: https://git.miljonivaade.eu ning avanema peaks järgmine pilt:

Põhikonfiguratsioon on sellega paigas. Antud lehel tuleb siis lisaks

  • sisestada MySQL kasutaja parool
  • kustutada pordi number Application URL väärtusest ning scheme määrata HTTPS. Antud juhul on lõppväärtus https://git.miljonivaade.eu/

Lõplikuks paigaldamiseks vajutame nuppu Install Gitea.

Õnnestunud paigalduse korral peaks avanema järgmine pilt:

Selles vaates tuleb teha endale konto. Esimesena registreeritud kontole antakse ka administraatori õigused.

Selle alampunkti lõpuks on meil olemas täisväärtuslik töötav Gitea rakendus. Nüüd on vaja lisada seaded, et Zone oskaks seda vajadusel automaatselt käivitada ja/või restartida

3. Seadistame Zone virtuaalserveri töötamaks Giteaga

3.1 Seadistame Gitea teenuse PM2’s

Kui Gitea töötab, peatame rakenduse klahvikombinatsiooniga ctrl + c.

Järgmiseks tuleb seadistada PM2, et Gitea jätkaks tööd ka pärast SSH’st välja logimist ning pärast Zone poolset serveri taaskäivitust. Selleks lisame PM2 teenuse. Samuti aitab PM2 rakendust automaatselt taaskäivitada, kui mingi probleemi tõttu peaks see “maha surema”.

Tekitame PM2 konfiguratisoonifaili:

nano /data03/virt73403/domeenid/www.git.miljonivaade.eu/gitea/gitea-pm2.json

Faili sisu peab olema selline:

{
 "apps" : [{
 "name" : "gitea-service",
 "script" : "gitea",
 "cwd" : "/data03/virt73403/domeenid/www.git.miljonivaade.eu/gitea",
 "args" : "web"
 }]
}

Salvestame faili ning Virtuaalserveri haldusliideses lisame rakenduse:

Virtuaalserveri Haldus -> Veebiserver -> Node.js ja PM2

  • Vajutame nuppu “Lisa uus Node.js rakendus”
  • Täidame väljad
    • Rakenduse nimi: gitea-service (vabalt valitud näids)
    • Skript või pm2.json: domeenid/www.git.miljonivaade.eu/gitea/gitea-pm2.json
    • Maksimaalne mälukasutus: kuna .json faili puhul see seade mõju ei avalda, võib see jääda 1MB peale.
  • Vajutame Lisa nuppu

Rakenduse käivitamiseks läbi PM2 peame ootama paar minutit. Veendumaks, et rakendus toimib, proovime selle aja möödudes minna brauseris rakenduse vaatesse – https://git.miljonivaade.eu/.

Kui antud aadressil avaneb Gitea rakendus, võib kontrollida, et rakendus sai ikka PM2 poolt käivitatud. Seda saab teha SSH konsoolis käsuga

pm2 status

Avaneda võiks järgmine pilt:

4. Hakkame rakendust kasutama ja/või testima

Järgnev tekst on juba töötava rakenduse näide, kui esimene kasutajakonto on loodud. Gitea on Zone virtuaalserveris paigaldatud, seadistatud õigesti käivituma ning järgnev on pigem väga lühike sissejuhatus rakendusse esimese repositooriumi loomiseks ning giti SSH ligipääsu seadistamiseks.

4.1 Sisestame SSH avaliku võtme git ligipääsuks

  • Klikime paremal üleval ikoonil ning avame menüüpunkti Your Settings
  • Avanenud lehel avame kaardi SSH / GPG Keys
  • SSH võtme all vajutame nuppu Add key

4.2 Loome uue respositooriumi

Siseneme Dashboard vaatesse. Visuaalne pilt on sarnane Githubi ja Gitlabiga ning neid kasutanud ei tohiks ka siin repositooriumi seadistamisega hätta jääda.

4.3 Hakkame kasutama

Repositooriumi vaates Clone this repository alt tuleb valida SSH ning kopeerida vastav URL.

Näiteks

git clone ssh://virt73403@git.miljonivaade.eu:2222/ingmar/zone-test.git
touch README.md
git add .
git commit -m "added readme"
git push

Ning giti kasutanud inimesel ei tohiks olla raske veenduda, et kõik töötab.

Edasi tuleb vaid Giteaga lähemat tutvust sobitada ning see enda vajaduste järgi ära seadistada.