Saját szerver svnserve
Saját szerver svnserve
Az svnserve program egy egyszerű szerver, amely képes kommunikálni az ügyfelekkel a TCP / IP protokollon keresztül, saját egyszerű protokollt használva. Az ügyfelek a kiszolgálót, svnserve-t, az svn: // vagy svn + ssh: Ebben a részben az svnserve különböző módjairól beszél. Az ügyfelek hitelesítésének módja a szerveren, valamint a tárolóhoz való hozzáférésre vonatkozó szabályok meghatározása.
A szerver indítása
Az svnserve program elindításának számos módja van. Ha paraméterek nélkül indul, akkor nem fog látni semmit, csak a súgó üzenetet. Ha a folyamatot az inetd segítségével kívánja elindítani. meg kell adnia a -i (--inetd) opciót:
Amikor a --inetd opcióval fut. Az svnserve megpróbálja kommunikálni a Subversion klienssel a stdin és a stdout segítségével saját protokollal. Ez az inetd által futtatott programok alapértelmezett viselkedése. IANA fenntartotta a 3690-es portot a Subversion protokollhoz, így unix-szerű rendszereknél is hozzáadhat ilyen vonalakat az / etc / serviceshez (talán már van):
Ha a rendszer klasszikus Unix-szerű démont használ inetd. az /etc/inetd.conf fájlban hozzáadhatod ezt a sort:
Győződjön meg róla, hogy a felhasználó "svnowner" rendelkezik a szükséges hozzáférési jogosultságokkal a repository-hoz. Ezt követően, amikor az ügyféltől a 3690-es portra irányuló kapcsolódási kérelem érkezik, az inetd elindítja a svnserve folyamatot a kérés teljesítéséhez.
Windows rendszereken vannak olyan külső eszközök, amelyek az svnserve szolgáltatást szolgáltatásként futtatják. Ezen eszközök listáját megtekintheti a Subversion weboldalán.
A második paraméter az svnserve egy önálló folyamatként indul - egy "démon". Ehhez használja a -d opciót:
Ha az svnserve démon módban indul el, használhatja a --listen-port = és a -listen-host = opciókat. hogy hozzárendelje a kívánt portot és gazdanevet, amelyhez az svnserve kapcsolódik.
Van még egy, a harmadik út az svnserve indításához. a -t opcióval - ez az úgynevezett "alagút mód". Ez a mód feltételezi, hogy a távoli hozzáférési programok, például az RSH vagy az SSH sikeresen hitelesítik a felhasználót, és futtatják a privát svnserve folyamatot a felhasználó nevében. Az svnserve program normál üzemmódban működik (stdin és stdout), és feltételezi, hogy a forgalmat automatikusan átirányítják egy bizonyos alagút mentén az ügyfél számára. Ha az svnserve egy hasonló alagút ügynök által indított, győződjön meg róla, hogy a hitelesített felhasználó teljes hozzáférést biztosít a tárolási adatbázis fájlokhoz. Valójában ez megfelel a helyi felhasználó tárolójának eléréséhez az űrlap fájl URL-jén keresztül: ///.
A -r paraméter használata hatékonyan módosítja a program által a fájlrendszer gyökerének tekintett helyet. Az ügyfelek azt az URL-címet használják, amelyből ezt az elérési utat eltávolítják, és rövidebb (és kevésbé feltűnő) URL-t eredményez:
Amikor az ügyfél csatlakozik az svnserve-hez. a következők fordulnak elő:
Az ügyfél megadja a szükséges tárolót.
az ügyfél engedélyt kap anonim hívások kezdeményezésére hitelesítési kérelem nélkül, OR
az ügyfelet bármikor fel lehet kérni, OR
amikor az "alagút üzemmódban" dolgozik, az ügyfél már kijelentette magát.
Felhasználói fájl és tárterület létrehozása
Az svnserve.conf [általános] szakaszában minden szükséges változó megtalálható. Kezdjük egy felhasználónevekkel és jelszavakkal, valamint a tárterületet tartalmazó fájl megadásával:
A realm a megnevezett név. Megmondja az ügyfeleknek, hogy milyen "azonosítási terület", amelyhez kapcsolódnak; a Subversion ügyfél megjeleníti azt a hitelesítési parancssorban, és kulcsként szolgál (a kiszolgáló nevével és portjával együtt), hogy az ügyfél azonosító adatait tárolja a lemezen (lásd "Az ügyfélazonosító adatok tárolása"). A "password-db" változó olyan különálló fájlra mutat, amely ugyanazt az egyszerű formátumban tartalmazza a felhasználók és a jelszavak listáját. Például:
A jelszó-db érték lehet abszolút vagy relatív elérési út a felhasználói fájlhoz. A legtöbb rendszergazdának könnyebb megtartani a konf / tárolási területen az svnserve.conf mellett. Másrészt ugyanazt a felhasználói fájlt szeretné megosztani két vagy több adattárhoz, amely esetben ezt a fájlt inkább elérhető helyen kell elhelyezni. A felhasználói fájlokat elkülönítő üzletek ugyanolyan területekkel is konfigurálhatók, mivel a felhasználói listák alapvetően meghatározzák a hitelesítési körzetet. Ahol végül a fájl véget ér, győződjön meg arról, hogy a megfelelő olvasási / írási jogosultságokkal rendelkezik. Ha tudja, melyik felhasználó indítja el az svnserve-t. korlátozza a hozzáférést csak a felhasználó számára, aki szüksége van rá.
Hozzáférés-vezérlés beállítása
Az svnserve.conf két további változót tartalmaz. úgy határozzák meg, hogy az azonosítatlan (névtelen) és az azonosított felhasználók számára megengedett. Az anon-access és auth-access változók értékei: none. olvasni. vagy írni. Az érték beállítása semmivel sem tiltja meg a hozzáférést; csak olvasható - csak olvasható hozzáférés az adattárhoz, és írása - lehetővé teszi a teljes olvasási / írási hozzáférést a tárhelyhez. Például:
A példában megadott értékek valójában az alapértelmezett értékek, ha nem szeretné őket definiálni, akkor beállíthatók. Ha konzervatívabb akar lenni, teljesen névtelen hozzáférést blokkolhat:
A kiszolgálófolyamat nem csak megérti ezeket a "takaró" hozzáférési vezérlőket a tárhelyre, hanem finomabb szemcsés hozzáférési korlátozásokat is, amelyek a tárolóban lévő egyes fájlokra és könyvtárakra helyezhetők. Ennek a funkciónak a használatához meg kell határoznia egy részletesebb szabályokat tartalmazó fájlt, majd állítsa be az authz-db változót arra, hogy pontra mutasson:
Az authzfile fájl szintaxisa részletesen tárgyalt a "Path-Based Authorization" -ban. Megjegyezzük, hogy az authz-db változó nem kölcsönösen kizárja az anon-access és auth-access változókat; ha minden változót egyszerre definiálunk, akkor a szabályok teljesítése meg kell, hogy feleljen, mielőtt a hozzáférés engedélyezett.
A beépített svnserve azonosítás kényelmesebb lehet, mivel elkerüli a tényleges rendszerfiókok létrehozásának szükségességét. Más szavakkal, egyes rendszergazdáknak már jól konfigurált SSH-kagylójuk van a rendszerükön. Ebben a helyzetben minden projektfelhasználónak van rendszerszámlája, és képesnek kell lennie az "SSH beillesztésére" a kiszolgáló gépre.
A legegyszerűbb módja az SSH használata az svnserve-rel együtt. Az ügyfelek egyszerűen használják az svn + ssh sémát a kapcsolathoz: //:
Fontos megérteni, hogy a Subversion kliens nem csatlakozik a futó svnserve démonhoz. Ez a hozzáférési módszer nem igényel démont, és nem is jelenti azt, ha jelen van. Az ssh átfogó képességét használja egy ideiglenes svnserve folyamat futtatására. amely a hálózati kapcsolat bezárásakor fejeződik be.
A tároló elérésekor használja az svn + ssh: // űrlap URL-jét. ne feledje, hogy ez az ssh program hitelesítést igényel, nem az svn kliens programot. Ez azt jelenti, hogy nincs automatikus jelszó gyorsítótárazása (lásd "Az ügyfélazonosító adatok tárolása"). A Subversion ügyfelek gyakran többszörös kapcsolatot létesítenek az adattárral, habár a felhasználók általában nem tudnak erről a jelszó-gyorsítótár lehetőségéről. Ugyanakkor, ha olyan URL-t használ, mint az svn + ssh: // URL, a felhasználókat az ssh bosszanthatja az egyes kimenő kapcsolatokra vonatkozó ismételt jelszókérések miatt. A probléma megoldása az SSH jelszavak gyorsítótárazására szolgáló külön eszköz használata, például az ssh-agent Unix-szerű rendszereken vagy a Windows-ban megjelenő lapok.
Ha kész a ágyazása azonosító elsődlegesen a operációs rendszer jogosultságokat az adatbázis fájl tárolására; ez nagyon hasonlít, ha Harry közvetlenül az URL-fájlon keresztül elérte a tárhelyet: ///. Ha több rendszert felhasználó használja az adattár közvetlenül, akkor érdemes őket egy közös csoportot, és akkor kell, hogy legyen nagyon óvatos, a felbontás (umasks). (Read «támogatása Multiple Access Repository Methods».) De minden esetben, az alagútépítés svnserve.conf fájl továbbra is lehet használni, hogy blokkolja a hozzáférést, állításával egyszerűen auth-hozzáférés = olvasni vagy auth-hozzáférés = nincs. [42]
Nem kell azt gondolnia, hogy az SSH Tunneling története itt befejeződik. A Subversion lehetővé teszi az egyéni alagút viselkedését a konfigurációs fájlban (lásd "Futtatási idő paraméterek"). Tegyük fel például, hogy az SSH helyett az RSH-t szeretné használni. Az [alagutak] fájl [alagutak] szakaszában egyszerűen adja meg a következőket:
És most használhatja az új alagútdefiníciót az új változó nevéhez tartozó URL-séma használatával: svn + rsh: // host / path. Ezután az új URL-séma használatával a Subversion kliens végrehajtja az rns host svnserve -t parancsot a jelenetek mögött. Ha beírja a felhasználónevet az URL-be (például svn + rsh: // felhasználónév @ host / path), az ügyfél ezt a parancsot is tartalmazza (rsh username @ host svnserve -t). De meghatározhat egy új alagútrendszert, amely ennél okosabb lesz:
Ez a példa a kapcsolódó dolgokat mutatja. Az elejétől kezdve megmutatja, hogyan tudja végrehajtani a Subversion kliensnek egy nagyon specifikus alagútprogramot (az / opt / alternate / ssh-ban található) néhány paraméterrel. Ebben az esetben az svn + joessh: // elérése speciális SSH programot tartalmaz az argumentumokkal - p 29934 - hasznos, ha az alagútprogramot nem szabványos portra kívánja csatlakoztatni.
Ezután megmutatja, hogyan definiálhat egy egyedi környezeti változót, amely felülbírálhatja a tunneling program nevét. Az SVN_SSH környezeti változó beállítása alapértelmezés szerint kényelmes módja annak, hogy felülbírálja az SSH tunneling ügynököt. De ha több különböző átfedésre van szükséged, a különböző szerverekhez mindegyik kapcsolódhat a különböző portokhoz vagy különböző paramétercsoportokat továbbít az SSH-ba, akkor használhatja a példában bemutatott mechanizmust. Most, ha beállítja a JOESSH környezeti változót. annak értéke felülbírálja az alagútváltozó tartalmát - $ JOESSH kerül végrehajtásra a / opt / alternate / ssh -p 29934 helyett.
SSH konfigurációs trükkök
Lehetőség nem csak arra, hogy hogyan kezelje az ügyfél az ssh-t. hanem szabályozza az sshd viselkedését a kiszolgáló gépén. Ebben a részben bemutatjuk, hogy hogyan lehet ellenőrizni, hogy mely svnserve parancsokat hívják sshd-nek. és azt is, hogy több felhasználó hogyan használhat egy rendszerfiókot.