Tiedostomuutosten seurantajärjestelmä?

[reboot]

Hei!

Olisi tarkoitus toteuttaa joko jo olemassa olevien työkalujen tai itse toteuttamalla (bash, perl tms.) tiedostoihin tehtävien muutosten tallennus ja seuranta. Eli lähinnä kuka on muokannut (?), milloin (stat) ja mitä osia on muutettu (cvs). Samoin pitäisi olla jonkinlainen automatiikka, joka ilmoittaisi esim. emaililla, jos jotakin tiedostoa on muutettu.

Kysymys kuuluu, miten em. tehtävän voisi suorittaa helpoiten?

[mikko_h]

Gamin tarkkailee kernelin antamia inotify-tapahtumia ja lienee asennettua oletuksena. Tiedostojen sisällön muutoksien seuraamiseen tarvittaneen erikseen versionhallintajärjestelmä tai versioita tallentava tiedostojärjestelmä.

[Tha-Fox]

Subversionin luulisi taipuvan ainakin muuten tuohon, mutta sähköpostin lähettämisestä en ole varma.

[reboot]

Kiireessä kun tuota viestiäni kirjoittelin, niin jäi pari oleellista asiaa pois. Eli ko. toteutuksen olisi tarkoitus pyöriä serverillä, jossa ei X-serveriä tai muutakaan GUI-hömppää ja se tarkistaisi / sille kerrottaisiin säännöllisesti onko jotain muuttunut n+1 ulkopuolisella serverillä. Myöskin serveri on CentOS-pohjainen, joten puhtaat Ubuntu-sovellukset eivät sellaisenaan käy. Mutta ajatuksena kuitenkin toteuttaa sen verran universaali sovellus, jota voi pyörittää mahdollisimman monella distrolla.


Edit:

find <dir> -ctime -1 -print -komennolla näkee, mitkä <dir>-hakemiston tiedostot ovat muuttuneet viimeisen vuorokauden aikana.

Pystyykö tuota jotenkin "huijaamaan", kuten touch-komennolla access- ja modification-aikoja eli olisi mahdollista tehdä tiedostoon muutos ja sitten palauttaa aiempi timestamp tiedostolle, jolloin muutos jäisi huomaamatta?

Inotify-jutut jäänevät pois laskuista, koska tosiaan tarkoitus olisi tehdä mahdollisimman yksinkertainen ja portattava ratkaisu.

[Nocando]

Edit:

find <dir> -ctime -1 -print -komennolla näkee, mitkä <dir>-hakemiston tiedostot ovat muuttuneet viimeisen vuorokauden aikana.

Ainakin omalla ubuntulla tuo kyllä listaa kaikki tiedostot mitä hakemistosta löytyy.

[retu]

En tiedä onko sopiva, mutta olen käyttänyt rdiff-bkup ohjelmaa vähän samantapaiseen tarkoitukseen. (Kyseessä web-palvelin, jota muokkaa useampi henkilö, joiden käsityskyvyn/viitsimiskynnyksen normaali versiohallinta ylittää).

[Ganymedes]

...
Pystyykö tuota jotenkin "huijaamaan", kuten touch-komennolla access- ja modification-aikoja eli olisi mahdollista tehdä tiedostoon muutos ja sitten palauttaa aiempi timestamp tiedostolle, jolloin muutos jäisi huomaamatta?
...

En tiedä mitä oikeastaan tarkoitat kun en tiedä täsmällistä käyttökohdetta, mutta totta kai pystyy huijaamaan. Jos "huijaaminen" on jotenkin oikeasti huolenaiheena, niin seuraavia asioita tulee heti mieleen:

- tiedoston kopiointi omalle koneelle ja sen unohtaminen sinne
- kahden samansisältöisen tiedoston syntyminen eri paikkaan ja niiden molempien muuttaminen samaan aikaan
- tiedoston kopiointi hieman eri nimellä ilman että käyttäjä edes tajuaa (vrt. isot ja pienet kirjaimet)

Edellä mainituista syistä johtuen varsinaisissa dokumentin hallintajärjestelmissä tiedostot identifioidaan metadatalla ja varsinainen tiedosto levyllä on käyttäjän ulottumattomissa. Tiedostojen synnyttämistä, lukemista, muuttamista, jäädyttämistä ja revisiointia hallitaan. Organisaatiossa ja sen ulkopuolella eri ihmisillä on näihin liittyen erilaisia oikeuksia. Tällöin ei voi tulla epäselvyyttä siitä, että mitä mikäkin tiedosto tarkoittaa, koska metadata identifioi tiedoston käyttötarkoituksen yksiselitteisesti.

En tiedä miten paljon tästä on hyötyä, koska tämä projekti pompsahtaa jos näitä asioita alkaa oikeasti toteuttamaan. Mutta ainakin tätä voi käyttää sen aprikointiin, että mitkä ovat hyväksyttyjä sotkuja ja mitkä eivät - ja toisaalta miten tämä pitää implementoida suhteessa käyttäjiin.

[tjok]

Hei

En nyt osaa sanoa kuinka hyvin sopii, mutta yksi työkalu jota voisi käyttää muutosten seurantaan on Tripwire. Minulla on aikanaan ollut se palvelimilla käytössä vahtimassa /etc hakemistoa ja binäärejä. Tuota voisi ehkä hyödyntää itse seurantaan ja rakentaa siitä sitten halutut toimenpiteet (muutettu tiedosto CVS:n, nofitikaatiot jne.)

http://en.wikipedia.org/wiki/Open_Source_Tripwire

  Toni

[reboot]

Edit:

find <dir> -ctime -1 -print -komennolla näkee, mitkä <dir>-hakemiston tiedostot ovat muuttuneet viimeisen vuorokauden aikana.

Ainakin omalla ubuntulla tuo kyllä listaa kaikki tiedostot mitä hakemistosta löytyy.

Esimerkiksi...

Koodia: [Valitse]

:~$ cd Desktop/
:~/Desktop$ find . -ctime -1 -print
:~/Desktop$ touch muokattu_tänään.txt
:~/Desktop$ find . -ctime -1 -print
.
./muokattu_tänään.txt
:~/Desktop$

toimii oikein itselläni. Desktop-kansiossa ei siis tiedostoja, joita olisi muutettu viimeisimmän vuorokauden aikana.
Miksiköhän sinulla tuo em. komento ei sitten toimi?



@ Ganymedes :

Tarkoitus olisi siis pähkinänkuoressaan seurata tiedostoja, ja jos tiedostoa jollakin tapaa muokataan siitä pitää lähteä ilmoitus esim. meilillä.

Seuraava askel on saada tiedostojen muutoshistoria versionhallintaan, eli päivitetään kun havaitaan muutos tiedostoissa. Tämä onnistuu mukavasti shell-scriptillä. Subversion näyttää lupaavimmalta ja toteuttamiskelpoisimmalta vaihtoehdolta tällä hetkellä versionhallintaan.

Lisäksi tärkeää on toteutuksen yksinkertaisuus, ja sen toimivuus unix/linux-ympäristöissä. Oma toive on, että koko seuranta-automatiikka voidaan toteuttaa sh-scriptauksella, jolloin mitään uutta softaa (versionhallinta pl.) ei tarvitse asentaa ja säätää toimintakuntoon.

[reboot]

En tiedä mitä oikeastaan tarkoitat kun en tiedä täsmällistä käyttökohdetta, mutta totta kai pystyy huijaamaan. Jos "huijaaminen" on jotenkin oikeasti huolenaiheena, niin seuraavia asioita tulee heti mieleen:

Huijaamisella tarkoitan esim. touch-komennolla A- ja M-aikojen muuttamista, tyyliin seuraavasti:

Koodia: [Valitse]

$ stat info.txt
File: `info.txt'
Size: 70 Blocks: 8 IO Block: 4096 regular file
Device: fc01h/64513d Inode: 142389 Links: 1
Access: (0644/-rw-r--r--) Uid: ( 1000/ user) Gid: ( 1000/ user)
Access: 2010-08-19 10:49:42.523413250 +0300
Modify: 2010-08-16 14:03:43.514539678 +0300
Change: 2010-08-16 14:03:43.514539678 +0300

$ nano info.txt

$ stat info.txt
File: `info.txt'
Size: 102 Blocks: 8 IO Block: 4096 regular file
Device: fc01h/64513d Inode: 142389 Links: 1
Access: (0644/-rw-r--r--) Uid: ( 1000/ user) Gid: ( 1000/ user)
Access: 2010-08-20 12:40:02.548126086 +0300
Modify: 2010-08-20 12:40:25.568175642 +0300
Change: 2010-08-20 12:40:25.568175642 +0300

$ touch -t 06060606 info.txt

$ stat info.txt
File: `info.txt'
Size: 102 Blocks: 8 IO Block: 4096 regular file
Device: fc01h/64513d Inode: 142389 Links: 1
Access: (0644/-rw-r--r--) Uid: ( 1000/ user) Gid: ( 1000/ user)
Access: 2010-06-06 06:06:00.000000000 +0300
Modify: 2010-06-06 06:06:00.000000000 +0300
Change: 2010-08-20 12:42:29.385163827 +0300

Käsittääkseni Change-aikaa ei pysty (ainakaan kovin helposti edes admin-oikeuksilla?) muuttamaan, joten jos ko. aika otettaisiin vertailupisteeksi, niin eikö muutoksia pystyisi valvomaan ihan vain stat-tietojen perusteella?

Stat-komento hyväksyy option -t, jolla tuon outputin saisi kompaktiin muotoon eikä näin ollen veisi kovinkaan paljoa levytilaa. SSH-yhteyden yli voisi ajaa scriptin, missä stat-komennolla käytäisiin halutut tiedostot/hakemistot läpi etäkoneelta ja tallennettaisiin ne valvontakoneen levylle. Esim. vuorokauden kuluttua sama homma uudelleen, ja jos eilisen ja nykyisen stat-infon tiedoissa on eroa, päivitetään ko. tiedosto versionhallintaan.

Tuollaisia olen ideoinut, mutta koska erheitä ja ajattelukatkoksia sattuu aina välillä, niin palaute on aina tervetullutta! 

[reboot]

Projekti on aika hyvin mallillaan, muutamia juttuja vielä on toki avoinna.

Eli systeemi toimii nyt niin, että seurattavan hakemiston/palvelimen muutoksia seurataan bash-scriptillä joka kopioi muutetut tiedostot ja/tai hakemistot omaan kansioonsa. Toinen bash-scripti sitten noutaa ajastetusti Subversioniin. Periaatteessa toimii hyvin.

Mutta seuraava ongelma tuli vastaan testaillessani systeemiä:

Jos palvelimella, jota seurataan, jokin hakemisto nimetään uudelleen hakemiston sisällön pysyessä samana tulee ongelmia versionhallintaan (Svn) tuotaessa; Svn ei suoraan tunnista tätä, vaan ilmoittaa että vanhalla nimellä ollut hakemisto on poistettu (!) ja working copyyn on luotu uusi hakemisto (?).  Kun yrittää svn commit -komennolla päivittää muutokset repositoryyn, Svn heittää herjaa eikä suostu tekemään mitään.

Mieleen on tullut, että bashilla vääntää skriptin joka jotenkin haistelee onko em. kaltaisia muutoksia tapahtunut, tai sitten mahdollisesti moiseen on jo tehty kykenevä sovellus/scripti. Olisiko jollakulla kokemusta tällaisesta pikku pähkinästä?

[mrl586]

Jos palvelimella, jota seurataan, jokin hakemisto nimetään uudelleen hakemiston sisällön pysyessä samana tulee ongelmia versionhallintaan (Svn) tuotaessa; Svn ei suoraan tunnista tätä, vaan ilmoittaa että vanhalla nimellä ollut hakemisto on poistettu (!) ja working copyyn on luotu uusi hakemisto (?).  Kun yrittää svn commit -komennolla päivittää muutokset repositoryyn, Svn heittää herjaa eikä suostu tekemään mitään.

Mitä subversion herjaa?

[retu]

Hakemiston tai tiedoston nimen muuttuessa inode numerot ei muutu. Samoin jos tiedosto siirretään hakemistosta toiseen.

[mikko_h]

Jos palvelimella, jota seurataan, jokin hakemisto nimetään uudelleen hakemiston sisällön pysyessä samana tulee ongelmia versionhallintaan (Svn) tuotaessa; Svn ei suoraan tunnista tätä, vaan ilmoittaa että vanhalla nimellä ollut hakemisto on poistettu (!) ja working copyyn on luotu uusi hakemisto (?).  Kun yrittää svn commit -komennolla päivittää muutokset repositoryyn, Svn heittää herjaa eikä suostu tekemään mitään.

Tämä on versiohallinan ominaisuus, ei bugi. SVN ei tajua hakemistojen uudelleennimeämistä automaagisesti, vaan operaatio on tehtävä eksplisiittisesti svn mv -komennolla, ja sen jälkeekin tästä saattaa aiheutua joitain mielenkiintoisia efektejä versiohistoriaan. Git on näissä asioissa pykälää fiksumpi siinä mielessä, että se pystyy tuottamaan tiedostojen ja hakemistojen historian heuristisen haun avulla ja arvaamaan uudelleennimeämisiä ja muita operaatioita, mutta Gitiäkin käytettäessä uusi hakemisto täytyy enemmän tai vähemmän eksplisiittisesti lisätä indeksiin.

Mieleen on tullut, että bashilla vääntää skriptin joka jotenkin haistelee onko em. kaltaisia muutoksia tapahtunut, tai sitten mahdollisesti moiseen on jo tehty kykenevä sovellus/scripti. Olisiko jollakulla kokemusta tällaisesta pikku pähkinästä?

Itselläni ei ole, mutta tämä lienee näitä CVS:n ja Subversionin suurkäyttäjien perusongelmia. Isommilla kehitysputiikeilla on usein melkoiset kokoelmat skriptejä Subversionin (tms.) ympärillä. Hakemalla heitä ehkä löytyy valmiina. Vaihtoehtoisesti voinee käyttää Gitiä ja lisätä seurattavan hakemiston alihaemistoineen kokonaisuudessaan indeksiin joka kerta (git add) ja sitten tallettaa version (git commit). Gitin työkalut osaavat veikata uudelleennimeämisoperaatiot versiohistoriassa yleensä oikein.

Mitä subversion herjaa?

Veikkaisin, että operaation 'mv source destination' jälkeen rutina on mallia

> svn commit

svn: Commit failed (details follow):

svn: Directory '/path/to/source' is missing

Hakemiston tai tiedoston nimen muuttuessa inode numerot ei muutu. Samoin jos tiedosto siirretään hakemistosta toiseen.

Subversionia ja kumppaneita tuo ei taida lämmittää, ne kun toimivat käsittääkseni puhtaasti tiedostonimien varassa ja myös muissa käyttöjärjestelmissä, joissa inoden konsepti ei välttämättä ole samanlainen.