Vastauksien varmuuskopiointi toiseen koneeseen - [merged] #2818

Closed dezhidki closed 2 years ago

In GitLab by @Smibu on Apr 23, 2021, 16:52

Merges answer-backup -> master

Toteuttaa kortin #2244.

Tässä lisätään 4 konffimuuttujaa, joilla määritetään, minne vastaukset lähetetään ja mikä on tarvittava salainen token.

Vastaukset tallentuu vastaanottavassa koneessa tim_files:in alle tiedostoon answers.backup. Yksi rivi on yksi vastaus JSONina.

Esimerkki yhdestä tiedoston rivistä:

{"content":"{\"usercode\": \"        System.Console.WriteLine(\\\"Hello\\\");\\n\"}","email":"test1@example.com","points":null,"task":"efefef","time":"2021-04-22T08:14:58.367329+00:00","valid":true,"doc":"users/test-user-1/csplugin","host":"http://localhost"}

ja sama muotoiltuna:

{
    "content": "{\"usercode\": \"        System.Console.WriteLine(\\\"Hello\\\");\\n\"}",
    "email": "test1@example.com",
    "points": null,
    "task": "efefef",
    "time": "2021-04-22T08:14:58.367329+00:00",
    "valid": true,
    "doc": "users/test-user-1/csplugin",
    "host": "http://localhost"
}

Harkitsin tiedostolle JSON-päätettä, mutta tarkalleen ottaen tiedoston sisältöä ei voi ihan suoraan antaa JSON-parserille, vaan kukin rivi pitää joinata pilkuin erotelluksi jonoksi ja laittaa ympärille hakasulut, jotta siitä muodostuu validi JSON-taulukko.

Backup-tiedostoon tallentuu kunkin vastauksen osalta myös lähettävän koneen nimi.

In GitLab by @vesal on Apr 23, 2021, 17:05

Mites kannattaako tämä olla miten sidoksissa TIMiin, vai voiko vastaanottava palvelin olla melkein mikä tahansa ja vaikka PHP (Tai toki flaskilläkin) tai millä tahansa tehty. Toki TIMikin voi olla yksi vastaanottava palvelin. Kuitenkin niin että sen voisi pistää Aallonkin tapauksessa fyysisesti eri paikassa olevaan varmuuskopiointifarmiin pystyyn.

In GitLab by @vesal on Apr 23, 2021, 18:30

Mites jos aloittaisi tyhjän tiedoston [ ja laittaisi joka rivin perään pilkun ja sitten "liimausvaiheessa" tarviisi vain sen lopettavan hakasulun?

Se on täysin konfiguroitavissa tässä MR:ssä. Varmuuskopio voi lähettää mielivaltaiseen osoitteeseen.

Toisin sanoin toisessa päässä voi olla mikä tahansa palvelin, jolla on POST-polku ja joka ottaa vastaan JSONia muodossa

"answer": { ... }, /* Vastausdata JSON-muodossa */
"token": "TARKISTUS_AVAIN" /* Tarkistusavain, jolla voi varmistaa, että vastaus tuli sallitulta TIM-palvelimelta. */

TIM voi olla vastaanottava palvelin, tämä MR toteuttaa sille toiminnallisuuden.

approved this merge request

resolved all threads

Ainakin puolestani LGTM

In GitLab by @vesal on Apr 24, 2021, 12:15

"token": "TARKISTUS_AVAIN" / Tarkistusavain, jolla voi varmistaa, että vastaus tuli sallitulta TIM-palvelimelta. /

Miten tämän avaimen kanssa toimitaan ja miten se tehdään niin ettei siä voi käyttää väärin? Sehän pitää levittää kaikkiin koneisiin jotta osaavat lähettää.

Samalla tavalla kuin muiden TIM-salaisuuksien kanssa: arvot määritellään prodconfig.py:ssa ja siirretään muihin koneisiin käsin SSH:lla etukäteen. Lisäksi varmistetaan kyseisen tiedoston oikeudet, jotta siihen pääsevät vain docker-ryhmään kuuluvat.

In GitLab by @vesal on Apr 26, 2021, 08:25

onkos tämä ensimmäinen missä mennään koneesta toiseen? Voisiko tuossa olla joku julkisen avaimen menetelmään perustuva avain niin että se voisi olla toisessa päässä julkisesti? Vai tuleeko silloin liikaa liikennettä?

In GitLab by @Smibu on Apr 26, 2021, 09:57

Mitäs lisähyötyä julkinen avain toisi, eli mikä on se uhkaskenaario, jota sillä ehkäistäisiin?

Mutta tosiaan tähän MR:ään ei liene syytä ruveta virittämään mitään monimutkaisempaa, jo pelkästään ajan puutteen vuoksi.

In GitLab by @Smibu on Apr 26, 2021, 10:02

Tuo oli mielessä, mutta se ei lopulta varmaan tuo mitään etua. Tuon JSONin muodostamisen voi yhtä hyvin suorittaa silloin kun tiedosto luetaan ja parsitaan.

In GitLab by @Smibu on Apr 26, 2021, 10:05

Taidan ennen mergeä vielä nimetä TOKEN -> SECRET tai SECRET_KEY, koska TOKEN kai viittaa enemmän sellaiseen lyhytikäiseen autentikointiavaimeen, ja tässähän se on enemmän pysyväisluonteisempi, koska se ei koskaan vanhene.

In GitLab by @vesal on Apr 26, 2021, 10:19

Entä edes se pilkku loppuun, niin ei tarvii muuta kuin sulut lisätä?

In GitLab by @vesal on Apr 26, 2021, 10:23

Lähinnä kai se on että jos se vastaanottava kone korkataan, niin silloin voi ruveta muualtakin syöttämään näitä tietoja. Mutta toki jos se korkattaisiin, voisi niitä tietoja syöttää suoraankin. Nyt kun käyttötarkoitus on vielä aika rajattu, niin uhkatkin ovat pieniä. Muttaa jos rupeaa tulemaan muutakin koneiden välistä kommunikaatiota, niin sitten sille kannattaisi tehdä riittävän luotettava tapa. Mutta ei siis ehkä tähän tapaukseen.

In GitLab by @Smibu on Apr 26, 2021, 10:49

Siinä onkin muuten se huono, että JSON ei salli ylimääräistä pilkkua viimeisen taulukon alkion jälkeen, eli se pitäisi erikseen poistaa. Eli lopulta on helpompaa olla laittamatta pilkkua tiedostoon ja sitten joinata pilkuilla koodissa, jolloin ei tarvitse mitään erikoistapauksia käsitellä.

In GitLab by @Smibu on Apr 26, 2021, 16:53

added 11 commits

24b371af...ba7d6fb1 - 8 commits from branch master
f9c5a753 - Answer export/import: Include/require document path
d07cd843 - Add a simple answer backup mechanism to another host
ba85d64d - answer backup: Rename "token" to "secret"

Compare with previous version

In GitLab by @Smibu on Apr 26, 2021, 18:56

resolved all threads

TIM-JYU / TIM

Vastauksien varmuuskopiointi toiseen koneeseen - [merged] #2818