[megoldva] svn témakörben szájbarágást szeretnék kérni

Linux-kezdő

Üdv.

szeretném érteni az svn körüli dolgokat, mert feladatom lenne vele.
Amit tudok róla, közelítsük a 0-hoz.
A feladat abból áll, hogy egy BSD-n működik egy svn, amit win alól TortoiseSVN-nel SSH-n keresztül használnak (a putty-ban megadott beállításokra építve).
A BSD private key azonosítást alkalmaz ssh-n, tehát a puttyba be van állítva egy private key file, ami miatt a sessionre kattintva azonnal promptnál találja magát az ember.
A BSD-hez root jogokkal a valós konzolon hozzáférünk.

Van egy linux is, ahol teljes jogunk van, és tetszőleges dolgokat meg tudunk valósítani (akár egy aranyos TurNkey Linuxot is futtathatunk a célra VM-ben, ha van ilyen repo - egyelőre nem találtam, persze a host gépen is lehet az SVN-fa).
A teljes svn-anyagot át kell ültetni a linux alá, ahol egyelőre nincs private keyre épülő auth. Ha nem szükséges, nem is tervezzük egyelőre.

Mi kell ahhoz, hogy elérjük ugyanazzal a klienssel a linuxon az (egyelőre üres) svn-t?
Gyermeteg próbálkozásaimnak az lett az eredménye, hogy a TortoiseSVN folyamatosan jelszót kér, és semmi eredménye nincs a csatlakozási kísérletnek.

Mit kell biztosítanom és hogyan, hogy a feladatot meg tudjam oldani?

  • 3674 megtekintés

( gd | 2011. 04. 06., sze – 17:31 )

Gondolom, ssh-n keresztul akarjatok elerni a repot. Akkor az kell, hogy ssh-val (putty-val) be tudj jelentkezni a szerverre, akkor mukodik az svn is. Szoval az kell, hogy a Linux szerveren legyen ssh szerver, amit el lehet erni, akar jelszoval, akar kulccsal.

Nem cel a private key-jel csatlakozas (egyelore).

A linuxon az sshd jol megy, nev + jelszo megadasa utan (nem a 22-es porton figyel) be lehet lepni.
Putty-ban el van mentve a session, azt elohivva mar keri is a nevet+ jelszot.

A BSD-hez csatlakozva igy nez ki a checkout, amit megadunk:
ssh+svn://puttysessionname/valamilyen/mappa/struktura/neve

A BSD alatt a valamilyen/mappa/struktura/neve valahol a /usr alatt meg is van (most mar nem vagyok a gep mellett, es csak helyi root hozzaferesem van).

Linuxhoz amikor ehhez hasonloan csatlakozni akarok, akkor jelszot ker, majd ismet, majd ismet, majd ismet, stb. A felhasznalonevvel putty-ban be tudunk lepni, tehat a rossz jelszo eset mar nem jatszik.

Ket dolog nem vilagos szamomra ezzel kapcsolatban:

1) mitol fugg, hogy a puttysessionname utan megadott mappa hol van a rendszeren? Ez egy globalis svn beallitas?
2) Miert nem tudok ugyanigy csatlakozni a linuxhoz (egyszeri jelszo megadassal)? Csak az a laikus otletem tamadt (amit nem is tartok hihetonek), hogy minden elemre, amit lekerdez, ujra keri a jelszot (tehat ha nem ures a mappa, akkor minden benne levo filera). Vagy masik otlet, hogy a sessionname utan megadott mappa linuxon nem ugyanazon az elv szerint keresodik, igy nem letezo mappat adtam meg.

Gondolom ebbol is latszik, hogy eddig nem voltam svn admin, de meg felhasznalo sem.

"mitol fugg, hogy a puttysessionname utan megadott mappa hol van a rendszeren?"

Hát attól, hogy hova rakták. Azt kell megadni, amelyik könyvtárban az svn repó van (ebben az esetben a Linux szerveren). svn repót az svnadmin paranccsal lehet létrehozni - ehhez nem értek, de lejjebb belinkelték a dokumentációt. (Amúgy a doksit elnézve nem tűnik egy ördöngösségnek, talán egy "svnadmin create /valahol/egy/könyvtár" megteszi.) Vagy át is másolhatjátok a BSD-n lévő repót (mint könyvtárat; jogosultságokra talán nem árt figyelni).

A terv valoban az atmasolas volt, viszont amig nem tudom, hogy a svn+ssh://egyik/repo miert a /usr/kiscica/gombolyag/egyik/repo mappat jelenti az egyik rendszeren, addig nem tudom, hogy a masik rendszeren "mindenkeppen letre kell-e hoznom egy /usr/kiscica/gombolyag mappat, hogy a masolas utan _tenyleg_ugyanott_ legyen", vagy valahol meg lehet adni, hogy "ezen a gepen a /usr/nagykutya/nyakorve" alatt lesznek a checkoutban megadott mappanevek.

A proba egyebkent arra ment ki a linuxon, hogy hatha a linux_root-tol kezdve kell megadni, tehat valami svn+ssh://usr/svn/egyrepo probalkozas volt, amikor vegtelennek tuno ciklusban kert jelszot anelkul, hogy latvanyosan vegzett volna valami hasznosat a kliens.

Masreszrol BSD-t me'g erintolegesen sem ismerem, es _ott_nem_a_root-bol_vonatkoztatott_mappat_ kell megadni a checkout-hivatkozasban...

Szoval nem ertem en ezt...

Ahol az svnserve indul, ott kell megnézni a paramétereket. man-ból: 

-r root, --root=root

Ez lesz a repók gyökere, ehhez kell viszonyítani az URL-eket, innen nem tudunk svn-en keresztül kilépni.

Ha esetleg http(s)-en, apache dav_svn-nel csináljátok, akkor az apacskonfigban (nálam dav_svn.conf) az SVNParentPath beállítását kell hasonlóan elvégezni.

Azaz mindegy, hogy adott rendszeren hogy hívják a gyökeret - csak onnantól lefelé érdekesek a nevek.

Amúgy a másolás mikéntjére még rá kellene keresni. A checkout nem jó, munkakönyvtárat csinál. Az export-import csak az aktuális állapotot másolja, a történetet nem. Szerintem kis próbálkozással, odafigyeléssel át lehet másolni a repót másik szerverre.

Ja, akkor ez lesz a kulcsa a dolognak. Ahol én használom, teljes útvonalat használunk, nem ismertem ezt a --root dolgot. Viszont ha jól gondolom, ssh-s elérés esetén az svnserve csak az adott ssh bejelentkezéskor indul el, és így a paramétereit a kliens ssh konfigurációjában kell megadni; akkor már egyszerűbbnek tűnik megadni a teljes útvonalat.

"Amúgy a másolás mikéntjére még rá kellene keresni."

Csinál belőle tar-t, átviszi, kibontja. Vagy simán áttolja sftp-n. Csináltam már, nem lett baja. Egy repónak az összes cucca a repó könyvtárában van.

Megvan már, hogy hol indul az svnserve?

Most látom, nem reagáltam egy dologra:
az svnserve szerverfunkció, azaz nem csak ssh-bejelentkezéskor indul el, hanem amikor a szerver bootol, valamelyik initszkript indítja vélhetőleg. Az ssh csak arra való, hogy titkosítsa a kapcsolatot, ha egy kliens csatlakozik.

A -root is a szerveroldalon kell; innen dől el, hogy a szerver által figyelt útvonalak (amiket a kliens checkout-ol pl.) a szerveren belül hol terülnek el.

Lehet valahogy listáztatni, milyen reposity-k vannak?

Kicsit felemás késztetést éreztem ennek a kérdésnek a felvetésére, mivel az eddig bennem kialakult kép alapján szerintem nem, hiszen bárhol el tudok helyezni reposity-t, és csak az fér hozzá az itteni adatokhoz, aki megjelöli a repo-t is. Viszont honnan tudja az svn, hogy a beírt mappában tényleg svn-repo van, és nem valami odamásolgatott textfájl-gyűjtemény?

( Cajga | 2011. 04. 06., sze – 17:38 )

Ha nem ragaszkodtok az SSH-s kulcsos auth hasznalatahoz, akkor hasznalhatsz mod_svn-t apache-hoz es http-n tudod elerni a kivant repot (apache fog authenticalni ha akarod).

Köszönöm.
Eredményes volt a rávezetés, már csak egy bizonytalanságot kellene eloszlatni: jól értem, hogy ahány
svnserve.conf
fájlt találok a könyvtárszerkezetben, az azokhoz képest 3 szinttel feljebb lévő könyvtár adja a reposity-t? (Egy szinttel feljebb a conf, kettővel a projectmappa, hárommal a repo mappa?) Tehát ezeket a mappákat/repokat kell dump-olnom a költöztetéshez?

Idevágó rész a howto-ból: 


Eljött az idő, hogy elkészítsük projectjeink tárolóját.
...
A parancs a következő könyvtárakat és fájlokat hozza létre:
...
svnrepos/MyProject1/conf:
authz  passwd  svnserve.conf
...

( dash | 2011. 04. 09., szo – 10:22 )

subscribe

---
színes
Hogyha egy üvegfenekű űrhajóval fénysebességgel közlekedünk a kilövés pillanatát látjuk állóképen.

( pezo v | 2013. 01. 08., k – 09:36 )

Nem mostani téma, és akkoriban lassan meg is oldódott, de idejegyzem a megoldást, hátha másnak jól jön.

1) Alapvető gondom volt, hogy svn-t sosem használtam, így nem tudtam, hogy hogy is kell működjön (csak a célját ismertem).
Egy túlegyszerűsített leírás erről, röviden:

Tehát egy kupac fájl (szakszóval repository) különböző verziójú állapotait a serveren tárolja valahogy (most ne legyen érdekes, hogy hogyan, annyit csak arről, hogy hatékonynak csak szöveges jellegű fájloknál bizonyul). Bármelyik létező verziót lekérhetjük, illetve új verziókat tudunk "feldni" neki.

SERVER
Kell a kiszolgálón valami, ami képes a verziókövetésre. Több lehetőség van, a legelterjedtebb alapszintű kiszolgáló ehhez a subversion (svn).
KLIENS
Mi windows alatt a "Tortoise svn"-t használjuk, ami jól támaszkodik a putty-ban elmentett session-ökre.
A kliensben úgy lehet megadni a (cél vagy forrás) repository-t, hogy svn+ssh://PUTTYSESSIONNAME/full/path/on/server
Konkrét példa: svn+ssh://svnserverünk/home/svn/cprogramunk
Ez esetben a putty-ban van egy svnserverünk nevű session elmentve; az svn-repository neve cprogramunk, és a /home/svn/cprogramunk mappában van a kiszolgálón.

LÉTREHOZÁS
Egy reposiory-t létrehozni legkönyebben a serveren az "svnadmin create NEV" paranccsal lehet. Ezt bárhol ki lehet adni a könyvtárszerkezetben (persze célszerű szépen összefogni valamilyen elv szerint a repositorykat), a kiadáskori aktuális könyvárban létrehoz egy NEV nevű mappát, és abban egy mindenféle titkokat rejtő .svn mappát. Ebben a NEV mappában fog gyűlni a repositoryban tárolt fájlok halmaza, aminek a verzióit eltároljuk benne. Fontos, hogy itt nem találjuk meg a fájlokat a hagyományos módon, tehát fájlrendszerszinten nem hozzáférhető a reposity tartalmának egyik verziója sem.
CHECKOUT
Ez után egy svn kliens programmal kell csatlakozni, és "kikéréssel" (szakszóval checkout) megadni a repository szerveren található helyét valahogy. Ezzel egy "üres", 0. verziójú állapothoz jutunk hozzá abban a helyi mappában, ahová "kicheckoutoltuk" a repositoryt.
COMMIT
Ebbe a helyi, kicheckoutolt, 0. verziójú mappába rakhatunk fájlokat (vagy később a már létezőket módosíthatjuk), amit vissza"küldhetünk" a serverre (szakszóval "commit"). Ezzel létrejön az 1. verzió az adott repository-ban (revision 1). A helyi mappában végzett további változtatások után újra commitolhatunk, így létrejön a 2. verzió.
Ha ekkor egy másik helyen (másik gép, másik meghajtó, vagy csak másik mappa) checkout-olunk, akkor megadhatjuk, melyik verzió kell nekünk, tehát akár az 1. verziót is kikérhetjük, hogy az hogyan is nézett ki. Vagy kicheckoutolhatjuk az utolsó verziót (ami akárhanyadik is, mindig HEAD revision, tehát HEAD verzió névvel érhető el).
Mivel csak egy egyszerűsített leírást akarok ide írni, nem foglalkozom azzal, hogy mi van, ha két különböző helyen ugyanazon a verzión más-más változtatásokat alkalmaznak, és mindkettőt be akarják commitolni.

--> Ezzel az én esetemben annyi volt a feladat, hogy felraktam debian alatt a subversion csomagot. Így már lehet repository-t létrehozni, illetve létező repository-kat checkoutolni, commitelni.

2) a BSD alól át kellett költöztetni a megfelelő repository-kat a debian alá. Itt arra támaszkodtam, hogy a kliensprogramok, illetve az userek emlékeztek teljes elérési utakra, vagy repo nevekre. Ezeket megkerestem a BSD fájlrendszerén, és mappástól összetömörítettem, kimentettem hordozható adathordozóra, ahonnan a Debianra kerültek fel. Ott kitömörítettem, majd megkíséreltük a checkoutot. Sikerült.

3) tapasztalat szerint egy checkout vagy commit esetén nagyon sokszor akarta magát authentikálni a fenti módszerrel (talán fájlonként?), így meg kellett oldani, hogy a puttyos (ssh) bejelentkezés ne kérjen jelszót. Ezt kétkulcsos authentikációval oldottuk meg, amit nem célom kifejteni ebben a témában.

Remélem, csak kevéssé köthető bele a fentiekbe annak fényében, hogy csak egy speciálisnak tekinthető alapesetre vonatkozóan fejtettem ki, illetve arra szántam, hogy a kezdeti lépést snv-hez talán ezáltal könyebb megtennie annak, akinek egyedül nem nagyon ment.