Git repokrol biztonsagi mentes

Linux-kezdő

Udv,

Jelenleg egy minden nap hajnalban lefuto script segitsegevel keszitek egy mentest a git repoimrol, majd ezeket a file-okat tarolom Nextcloud-ban. Innen aztan szinkronizalodik tobb helyre. Hogyan tudnam megoldani azt, hogy csak azok a repok keruljenek mentesre amelyek valtoztak?Maga a script igy fest:

#!/bin/bash

GIT_DIR="/home/git/repositories/"
BACKUP_DIR="/home/kukukk/Multimedia/nextcloud/kukukk/files/Backup/GitRepos/"
GROUP="www-data"
USER="www-data"

cd $GIT_DIR
for GIT_REPO in $(find $GIT_DIR -mindepth 1 -maxdepth 1 -type d);
do
    REPO="$(basename $GIT_REPO)"
    ZIP_FILE="$BACKUP_DIR$REPO.zip"
    zip -r $ZIP_FILE $REPO
    chown $USER:$GROUP $ZIP_FILE
done

sudo -u www-data php /home/kukukk/www/nextcloud/occ files:scan --path kukukk/files/Backup/GitRepos

Nem feltetlen ragaszkodom ehhez a megoldashoz, ha van jobb modszer szivesen lecserelem. En csak ezt tudtam osszehozni :}
Szivesen veszek konkret megoldast is :}, de amugy eleg az otlet is, hogy milyen iranyban keresgeljek.

  • 1535 megtekintés

( uid_17626 | 2017. 04. 10., h – 10:13 )

Amúgy te felhasználóként használsz git-et?

Nem vagyok benne biztos, hogy pontosan ertem a kerdest, de, azt hiszem, is-is.
Arrol van szo, hogy a sajat kis projekteimhez hasznalok git-et. Nehany projektet tobb geprol is el kell ernem, vagy meg kell osztanom masokkal. Ezert beallitottam egy git szervert, ami be van allitva mint remote repository. Ezen a git szerveren levo repokat szeretnem backupolni. Mivel mar ugyis van Nextcloud a szerveren, ami szinkronizalodik tobb helyre, es a mentese is meg van oldva, ezert gondoltam, hogy egyszerubb ha oda mentem a git repokat is. A dolog mukodik is, ezzel nincs gond. Egy apro szepseghiba van csak, hogy minden reporol keszul mentes, meg ha nem is valtozott.

Sic Transit Gloria Mundi

( mn3monic v | 2017. 04. 10., h – 10:19 )

létrehozod a repot a backup szerveren, local repo-ban hozzáadod új remote-ként, és git push --all remote_name nem jó?

Nem volt teljesen pontos a leirasom. Nincs masodik backup server.
Van egy szerver, amin fut tobb szolgaltatas: git szerver, Nextcloud, stb. A git szerveren tarolt repokat backupolom a Nextcloudba, ami onnan szinkronizalodik telefonra es laptopra. Laptoprol idonkent kiirom kulso hardra es feltoltom (jelszavazva) OneDrive-ra.
A git repok ritkan valtoznak. Van olyan koztuk, ami mar tobbet nem is fog soha.

Sic Transit Gloria Mundi

( nxu | 2017. 04. 10., h – 10:47 )

A backup scriptet rakd bele a szerveren a git push hookba, és futtasd csak akkor, ha push érkezik.

Erre gondoltam en is, de mivel gitolite-ot hasznalok a hozzaferesek kontrollalasara, ezert a script "git" user neveben futna, igy nem tudna atrakni a www-data tulajdonaba a file-okat. Anelkul pedig a Nextcloud nem tudja rendesen kezelni.
Egy kerdes: ha megis ebbe az iranyba megyek tovabb, ezt minden egyes uj git repo eseten be kell allitani, vagy megoldhato globalisan, hogy minden uj git repo eseten aktivalodjon?

Sic Transit Gloria Mundi

( Sea-you | 2017. 04. 10., h – 11:11 )

Van barmi oka annak, hogy nem GitHubon tarolod a repokat?

Vannak helyzetek amikor nem szabad a cég dolgait külső cégre bízni, meg vannak olyan helyzetek is amikor az adatok nem vihetőek külföldre. Nyilván ilyen esetekben saját git repó kell, és menteni is kell, nem tudom melyik cég nézné jó szemmel azt ha lehalna, és majd a felhasználóktól kérnéd be a repókat... és vagy meglesznek, vagy nem.

Tudom, ez most épp saját repók gyüjteménye, de mi van ha pl az új gépeden nincs minden git repó klónozva, és valahogy elveszik a szerveren tárolt? Olyankor azért jól jön ha van mentés.

Ez igy van, viszont ez nem ved veletlen/szandekos repo pusztitas ellen (ha valaki mondjuk direkt visszaall egy korabbi commitra es azt force pusholja, akkor ha jol tudom, a tobbi commit "elveszett"). Ilyen esetben jo lehet egy 3rd party mentes, viszont OP egyedul hasznalja a repot, szoval ennek nem kene problemanak lennie.

Van amit nem szabad githubra tenni szerződések miatt (privátra sem).

Vagy pl egyszemélyes projekt esetén ha a fejlesztő gépemet felnyomják, akkor egy rosszakaratú cracker le tudja törölni a helyi és a távoli másolatot is (ha a branch védelem nincs beállítva pl). Ezenkívül egy régebbi projektnek lehet hogy letörlöm a repóját a gépemről - vagy nem viszem át költözéskor az új gépemre. De attól még garanciális javítás miatt hozzá kellhet nyúlnom. Ha össze van lőve rendesen egy backup, akkor a fejlesztői gépemre nem kell koncentrálnom, ha összetörik, csak veszek egy másikat, újrahúzom az oprendszert, belövök egy új ssh kulcsot és megy az ipar tovább.

Vagy egy kis csapat esetén egy adatvesztés után vadászgathatod, hogy kinél van meg a legújabb változat. Azon múlik, hogy ki dolgozott a repón utoljára.

Ezenkívül nem feltétlenül tarthatod megbízhatónak a githubot, mert harmadik fél egy idegen országban, ezért nem építhetsz légvárakat a megbízhatóságára, ha neked viszont valamiféle rendelkezésre állást kell garantálnod, akkor valamit tenned kell.

A lényeg, hogy én jobban alszom, ha fizikailag egymástól távoli, saját vason tárolt backupjaim vannak, és arról napi log - aminek hiányára egy felügyeleti rendszer riaszt, hogy minden rendben megy. Bocsásd meg nekem ezt a gyengeségemet, kérlek!

Arra a cinikus hangnem, hogy már jóideje látszik, hogy a "felhő" nem szól másról mint globális léptékű kémkedésről. Vannak dolgok amire használható, de mint tutibiztos backupot ajánlani igencsak naív dolog. De még az is beleférne, ha nem kötnéd az ebet a karóhoz, miután pontosan meg lett mondva miért nem github.

Peldaul mert a githubon a privat repo penzbe kerul.

Gitlabon tudsz privat repot csinalni ingyen. Persze ettol ezt meg a Gitlab ugyanugy latja, csak a vilag fele nincs nyitva - tehat ha tenyleg fontos, hogy "privat-privat" legyen, akkor muszaj sajat kezbe venni a dolgokat - mondjuk ez esetben a zippelest nem gondolom kielegito titkositasi algoritmusnak :)

szerk: elvileg a Nextcloud tud encrypted storage-et.

Igy hirtelen 3 ok jut az eszembe:
1. Vannak projektek, amelyek nem publikusak, igy a ingyenes GitHub account nem elegseges. Fizetni meg nem szeretnek olyasmiert, amit meg tudok oldani en is viszonylag kenyelmesen.
2. Nem tudom, hogy GitHub eseten mennyire tortenhet ilyen, de talan Google Drive vagy OneDrive eseten olvastam olyat, hogy valami szerver oldali problema miatt torlodtek a file-ok a szolgaltato szervererol, majd ez szepen szinkronizalodok a felhasznalo gepere.
3. Az utobbi idoben kezdek nem bizni a kulonbozo szolgaltatokban szemelyes adatok kezelese kapcsan, igy, amit nem muszaj, nem bizok rajuk.

Sic Transit Gloria Mundi

1. gitlab.com
2. Ha a git-et a sajat interfeszen keresztul hasznalod (tehat nem a fajlokat masolgatod kozvetlenul - nem tudom, egyaltalan lehet-e ilyet), magyarul ha nem direkt csinalod, nem tortenhet ilyen. Ennel sokkal valoszinubb, hogy elrontasz valamit a backup scriptedben, ami viszont tenylegesen tonkrevaghatja az adataidat.
3. Milyen szemelyes adatot tarolsz a git repo-idban?

3-as kapcsan annyiban pontositanek, hogy a sajat projektjeim, amiket nem szeretnek publikussa tenni, azokhoz a kulonbozo szolgaltatok se ferjenek hozza. Tehat nem kimondottan csak szemelyes adatokrol van szo, hanem barmilyen szemelyes dologrol. Valoszinuleg van jobb dolguk is mint minden egyes privat repot atnyalazni, hogy vajon mi van benne, es nagyreszt paranoja, de, ha kenyelmesen megoldhatom, hogy ne kelljen harmadik fellel megosztanom, akkor nem teszem. Ilyen megfontolasbol ugrik a gitlab hasznalata is, haba van privat repo lehetoseg naluk.

A 2-es pont kapcsan pedig annyit tennek hozza, hogy backup-ot ugyis meg kell oldanom, mert nem bizom abban, hogy az ilyen szolgaltatok garantaljak az en adataimat. Ha valami tortenik naluk, es (nyilvan tulzo pelda) felrobban az adatkozpontjuk, akkor csak megvonjak a vallukat, hogy "sajnaljuk, de ugrottak a repoid". Kulonbozo cloud szolgaltatok nalam csak 4-ed szintu backup megoldasnak foghatok be (munkageo, sajat szerver, kulso hard, cloud).

Nem mondom, hogy az erveim es elkepzeleseim sziklaszilard alapokon nyugszanak, es nem lehet belejuk kotni. Ezek az elmult evek alatt alakultak ki, es jelenleg igy latom a dolgokat. Lehet jovore meggondolom magam, es mindent csak cloud-ban fogok tarolni. Bar ketlem :}}

Sic Transit Gloria Mundi

( asch v | 2017. 04. 10., h – 11:30 )

Pár hónapja ugyanezzel a témával foglalkoztam. Azóta összeraktam az itt leírtaknak megfelelően, és szépen működik: https://hup.hu/node/151046

Az elv az, hogy a backup erre dedikált, fizikailag elszórt gépeken fut, amik tisztán kliens módban, periódikusan pollozzák a bekonfolt forrásokat. A sávszélesség igény a változásokkal skálázódik, a tárolandó adat pedig pont akkora mint egy sima klón. Bármit tud backupolni, amihez anoním, vagy kulcsos read only elérésed van.

A command line java program itt van, sajnos még nincs rendesen release-elve, csak magamnak exportáltam binárist: https://github.com/qgears/opensource-utils/blob/master/commons/hu.qgear…

Ha érdekel, csinálok hozzá tisztességes leírást, meg release buildet. Egy systemd időzítő futtatja rendszeresen, és git-be logol, aminek a meglétét tudod felügyelni. Így a backup gépre soha nem kell belépned (biztonsági frissítések autó telepítése nem árt), le lehet tenni megbízható, de informatikához nem értő ismerősöknél. Így a szervízhez fizikai hozzáférés kell, viszont cserébe minimális a támadási vektor.

Alapból annyit tud, mint amit fentebb is írt valaki: git clone, majd utána rendszeresen pull. Amivel több, az az hogy "garantáltan"* nem tud adatot veszíteni akkor sem, ha a klónozott szerveren bármilyen rossz szándékú tettet tesz egy tettes. Illetve a frissítések időpontjaiban lévő pillanatképek visszaállíthatóak forced push után is.

* garantáltant úgy kell érteni, hogy ha nincs hiba az okoskodásban. Illetve most nézem, hogy a beállításos repóval gyanús hogy lehet támadni, úgyhogy még van mit csiszolni rajta.

Hmm ezt egyszerűbben meg lehet oldani:

1. git clone
2. periodikus "git pull ;rdiffbackup " futtatása, megfelelő időközönként

Az rdiffbackup nagyon jó program, tetszőleges időpontra vissza lehet vele állni, szinte nulla a dependency-je, és minden linux-ból és unix-ból elérhető a standard csomagok között. Ha csak annyi a cél hogy ne lehessen távolról gonosz módon adat törlést sync-elni akkor ez bőven elég.

Ez jónak tűnik. Megjegyzem, kellhet még.

Nekem annyiból tetszik jobban a saját megoldásom, hogy a git már eleve hash-el, deduplikál meg minden, akkor teljesen felesleges egy hasonló rendszeren még egyszer megjáratni a fájlokat (CPU-ban biztos, hogy optimálisabb csak tag-elni). A poén pont az benne, hogy a git önmagában mindent tud, ami egy backuphoz kell, csak a megfelelő parancsokat kell hívogatni. Kicsit belezúgtam a gitbe, és tetszik, hogy mennyi mindenre jó.

( manfreed (nem ellenőrzött) | 2017. 04. 10., h – 12:24 )

"Hogyan tudnam megoldani azt, hogy csak azok a repok keruljenek mentesre amelyek valtoztak?"

szerk, rájöttem, hogy a válaszom nem jó, viszont alternatívaként javaslom a következőket

1) Git hook:

Ezt fentebb írták, azzal egészíteném ki, hogy a jogosultság problémát kerüld ki azzal, hogy a hook csak lerak egy fájlt, a cron pedig a fájl megléte alapján backupol.

2) Módosítás dátumának ellenőrzésével (Csak elmélet, erősítsetek meg/cáfoljatok ha tévedek)

Az, hogy a repó változott kideríthető onnan, hogy a fájljai változtak-e, az pedig kideríthető elvileg a repó összes mappájának mappák utolsó módosítási idejéből. Ebből kell venni egy maximumot, és ezzel lehet dolgozni. Az így kitalált időt össze kell hasonlítani egy korábbi állapottal, tehát a cron minden futáskor eltárolja az aktuális állást, és az előzővel hasonlítja össze. Ha változott, kell backup. Ha nincs előző, kell backup.

Ez a megoldás egyébként a hook-oshoz képest talán feleslegesen komplikált

Fentebb is irtam, hogy a git hook + cron parosnak utana nezek.

Viszont a 2-es opcio biztos ilyen komplikalt? Az nem jarhato ut, hogy maga a repo konyvtar utolso modositasi idejet nezem, es ha az kisebb mint 24 ora, akkor volt modositas az elmult nap folyaman es kell backup?

Sic Transit Gloria Mundi

Nem igazán.

Bizonytalan voltam, ezért ráteszteltem: Egy mappa módosítási dátuma akkor frissül, ha közvetlen benne lévő fájl vagy mappa változik. Ha mappán belüli mappán belül történik valami, akkor nem fog a mappa módosítási dátuma változni.

Legalábbis ez történik nálam Ubuntun, nem merem biztosra mondani, hogy ez a működés azonos mindenhol.

Namost, azt kellene tudni, hogy garantálható-e, hogy bármilyen változás, ami a repót érinti érinti a .git alatt közvetlen lévő dolgokat. Ha igen, akkor oké, a .git módosítási dátuma frissül, ellenőrizheted azt. Ha viszont nem, akkor minden mappára rá kell nézned.

"Namost, azt kellene tudni, hogy garantálható-e, hogy bármilyen változás, ami a repót érinti érinti a .git alatt közvetlen lévő dolgokat."

A döntő többség igen, többnyire azért, mert frissítik az indexet, ami közvetlenül a .git könyvtárban van.
De azért akadnak kivételek: 

$ ls -ld .git
drwxr-xr-x 10 sz sz 4096 Apr 10 13:35 .git
$ date
Mon Apr 10 13:36:20 CEST 2017
$ git branch tmp
$ ls -ld .git
drwxr-xr-x 10 sz sz 4096 Apr 10 13:35 .git

Es ha sorban ellenorzom ennek a parancsnak a kimenetet, hogy valamelyik frisebb-e mint 1 nap, az mar jo lenne?
git for-each-ref --sort=-committerdate --format='%(committerdate:local)'
Ha jol ertem ez a parancs kilistazza az osszes branch utolso commitjanak az idopontjat.

Sic Transit Gloria Mundi

1. Nem kell sorban ellenőrizned kimenetét, elég, ha a legfrissebbet megnézed. Ha az 1 naptól frissebb, akkor kell menteni, ha nem, nem.
2. Jól érted, de tag-eknek nincs committerdate-jük, így ez a parancs a tag-ek dátumait nem listázza ki. Vagyis ha egy napon keresztül csak tag-eket csinálsz, de commit-ot egyet se, akkor nem készül új mentés. Persze ilyet te úgyse fogsz csinálni, de akkor is jobb lenne creatordate-et használni committerdate helyett.
3. De még jobb lenne nem hagyatkozni a dátumokra, mert nagyjából bármilyen dátumú commit-ot létre lehet hozni. Persze te valószínűleg ilyet se fogsz csinálni... de a hash-ek akkor is megbízhatóbbak. Mentsd file-ba a for-each-ref default kimenetét minden nap, diffeld az előző napival, és ha van különbség, akkor van mentenivaló.

1. Igaz. Keso volt mar, valahogy nem kattant, hogy eleve sorba van rendezve datum szerint.
2. Valoban nem szoktam egesz nap csak tag-eket csinalni, de, ha a creatordate figyelembe veszi a tag-eket is, akkor valoban jobb az.
3. Ez az egesz elkepzeles onnan indult, hogy scripten kivuli modositas nelkul kideritsem volt-e valtozas. Ha mar file-ba mentek, es diffelek, akkor lehet jobb a "post-receive" hook-ban letrehozni egy file-t, majd a scriptben annak a file-nak a megletet ellenorizni. Ha letezik a file, akkor kell menteni, es torolni azt a file-t.

Sic Transit Gloria Mundi