Server propriu svnserve
Programul svnserve este un server ușor care poate comunica cu clienții prin TCP / IP folosind propriul protocol simplu. Clienții accesează serverul, svnserve, folosind o adresă URL care începe cu svn: // sau svn + ssh: //. În această secțiune, vorbește despre modalități diferite de a începe sănnserve. Despre modul în care clienții sunt autentificați pe server și despre stabilirea regulilor corespunzătoare pentru accesarea depozitului.
Pornirea serverului
Există câteva moduri diferite de a porni programul svnserve. Dacă începeți fără parametri, nu veți vedea altceva decât mesajul de ajutor. Dacă intenționați să începeți procesul prin inetd. trebuie să specificați opțiunea -i (--inetd):
Când rulați cu opțiunea --inetd. svnserve va încerca să comunice cu clientul Subversion prin stdin și stdout folosind propriul protocol. Acesta este comportamentul implicit pentru programele care se execută prin inetd. IANA a rezervat portul 3690 pentru protocolul Subversion, deci pentru sistemele de tip unix, puteți adăuga linii în / etc / services like this (poate că le au deja):
Dacă sistemul folosește un inetd clasic daemon de tip Unix. în /etc/inetd.conf puteți adăuga această linie:
Asigurați-vă că utilizatorul "svnowner" are drepturile necesare pentru a accesa depozitul. După aceasta, când o cerere de conectare de la client către portul 3690 vine, inetd va porni procesul svnserve pentru a răspunde acestei solicitări.
Pe sistemele Windows, există unelte de la terțe părți care rulează svnserve ca serviciu. O listă a acestor instrumente poate fi vizualizată pe site-ul Subversion.
Al doilea parametru pornește svnserve ca proces independent - un "daemon". Pentru aceasta, utilizați opțiunea -d:
Dacă svnserve este pornit în modul daemon, puteți folosi opțiunile --listen-port = și -listen-host =. pentru a atribui portul dorit și numele gazdei la care svnserve este "legat".
Există încă una, a treia modalitate de a începe să svnserve. cu opțiunea -t - acesta este așa-numitul "mod tunel". Acest mod presupune că programele de acces de la distanță, cum ar fi RSH sau SSH, au deja autentificat cu succes utilizatorul și execută procesul privat svnserve în numele acelui utilizator. Programul svnserve funcționează în modul normal (funcționând prin stdin și stdout) și presupune că traficul va fi automat redirecționat de-a lungul unui anumit tunel către client. Când svnserve este pornit de un agent de tunel similar, asigurați-vă că utilizatorul autentificat are acces de citire și scriere completă la fișierele bazei de date de stocare. De fapt, aceasta corespunde accesării spațiului de stocare al utilizatorului local printr-o adresă URL a fișierului formular: ///.
Utilizarea parametrului -r modifică eficient locația considerată de program ca fiind rădăcina sistemului de fișiere. Clienții utilizează adresa URL din care se elimină această cale, rezultând o adresă URL mai scurtă (și mai puțin dezvăluită):
Când clientul se conectează la svnserve. apar următoarele:
Clientul specifică magazinul necesar.
clientului i se poate permite să efectueze apeluri anonime, fără o cerere de autentificare, SAU
clientul poate fi rugat să identifice în orice moment, SAU
când lucrează în modul "tunel", clientul se declară deja identificat.
Creați fișierul de utilizator și zona de stocare
Acum, secțiunea [general] din svnserve.conf are toate variabilele de care aveți nevoie. Să începem prin definirea unui fișier care conține nume de utilizator și parole, precum și din zona de stocare:
tărâmul este numele pe care îl definiți. Acesta îi spune clienților ce "zonă de identificare" se conectează; clientul Subversion îl afișează în promptul de autentificare și este utilizat ca cheie (împreună cu numele și portul serverului) pentru a arhiva informațiile de identificare ale clientului pe disc (a se vedea "Informații despre identitatea clientului de cache"). Parola variabilă-db indică un fișier separat care conține o listă de utilizatori și parole în același format simplu. De exemplu:
Valoarea parolei-db poate fi o cale absolută sau relativă la fișierul de utilizator. Pentru majoritatea administratorilor, este mai ușor să îl păstrați în zona conf / storage, alături de svnserve.conf. Pe de altă parte, poate doriți să partajați același fișier de utilizator pentru două sau mai multe depozite, caz în care acest fișier trebuie plasat într-o locație mai accesibilă. Magazinele care separă fișierul utilizator trebuie, de asemenea, să fie configurate cu aceleași zone, deoarece lista de utilizatori definește în esență domeniul de autentificare. Oriunde se termină fișierul, asigurați-vă că acesta are permisiunile corespunzătoare de citire / scriere. Dacă știți în numele utilizatorilor care vor fi porniți svnserve. restricționează accesul la citire numai de către utilizatorul care are nevoie de el.
Setarea controlului accesului
Există două variabile suplimentare în svnserve.conf. ele determină faptul că utilizatorii neidentificați (anonimi) și identificați vor putea să facă acest lucru. Variabilele anon-access și auth-access pot avea valorile: none. citește. sau scrie. Setarea valorii pentru nici unul nu permite accesul de orice fel; citiți - acces numai în citire și depozitați - permite accesul cititorului / scriitorului complet la depozit. De exemplu:
Valorile stabilite în exemplu sunt de fapt valori implicite, acestea vor fi setate dacă nu doriți să le definiți. Dacă doriți să fiți mai conservatori, puteți bloca accesul complet anonim:
Procesul de server nu numai că înțelege aceste controale de acces "pătură" la depozit, dar și restricții de acces mai fin, introduse pe anumite fișiere și directoare din depozit. Pentru a utiliza această caracteristică, trebuie să definiți un fișier care conține reguli mai detaliate și apoi să setați variabila authz-db pentru ao indica:
Sintaxa fișierului authzfile este discutată detaliat în "Autorizarea bazată pe cale". Rețineți că variabila authz-db nu se exclud reciproc cu variabilele de acces anon și auth-access; dacă toate variabilele sunt definite simultan, atunci toate regulile trebuie îndeplinite înainte ca accesul să fie permis.
Identificarea integrată a conectorului poate fi mai convenabilă, deoarece evită necesitatea creării de conturi de sistem reale. Cu alte cuvinte, unii administratori au deja bine configurate shell-uri SSH pe sistemele lor. În această situație, toți utilizatorii proiectului au deja conturi de sistem și abilitatea de a intra în "SSH în" serverului.
Cea mai ușoară cale este să utilizați SSH împreună cu svnserve. Clienții utilizează pur și simplu schema svn + ssh pentru conexiunea: //:
Lucrul important de înțeles este că clientul Subversion nu se conectează la daemonul svnserve care rulează. Această metodă de acces nu necesită un daemon și nici nu notifică, chiar dacă este prezentă. Utilizează capacitatea generală a ssh de a executa un proces temporar svnserve. care se termină atunci când conexiunea la rețea este închisă.
Când accesați depozitul, utilizați adresa URL a formularului svn + ssh: //. rețineți că acest program ssh necesită autentificare, nu programul client svn. Aceasta înseamnă că nu există nici o memorare automată a cache-ului pentru parole (a se vedea "Informații privind identificarea clientului în cache"). Subversion clienții fac adesea mai multe conexiuni la depozit, deși utilizatorii de obicei nu sunt conștienți de acest lucru din cauza posibilității de cache parola. Cu toate acestea, atunci când utilizați un URL precum svn + ssh: // URL-uri, utilizatorii pot fi deranjați de ssh din cauza cererilor de parole repetate pentru fiecare conexiune de ieșire. Soluția la această problemă constă în folosirea unui instrument separat pentru caching-ul parolelor SSH, cum ar fi ssh-agent pe sistemele de tip Unix sau un ecran în Windows.
Atunci când este executat prin tunel, autentificarea este inițial controlată de drepturile sistemului de operare la fișierele bazei de date de stocare; este foarte mult ca și cum Harry ar fi accesat depozitul direct prin fișierul URL: ///. Dacă mai mulți utilizatori ai sistemului accesează direct depozitul, este posibil să doriți să le puneți într-un grup partajat și va trebui să fiți foarte atenți cu permisiunile (umasks). (Citiți "Sprijinirea metodelor de accesare a mai multor depozite"). Dar în fiecare caz de tunel, fișierul svnserve.conf poate continua să fie folosit pentru a bloca accesul, pur și simplu prin setarea auth-access = read sau auth-access = none. [42]
Nu trebuie să te gândești că povestea despre Tunelul SSH va fi terminată aici. Subversiunea vă permite să creați un comportament tunel personalizat în fișierul de configurare (consultați "Parametri de rulare"). De exemplu, să presupunem că doriți să utilizați RSH în loc de SSH. În secțiunea [tuneluri] din fișierul [tuneluri], specificați următoarele:
Acum puteți utiliza noua definiție a tunelului utilizând schema de adrese URL care corespunde cu numele variabilei dvs. noi: svn + rsh: // host / path. Apoi, utilizând noua schemă de adrese URL, clientul Subversion va executa comanda rsh host svnserve -t în spatele scenei. Dacă includeți numele de utilizator în URL (de exemplu, svn + rsh: // username @ host / path), clientul îl va include și în această comandă (rsh username @ host svnserve -t). Dar puteți defini o nouă schemă de tunel care va fi mai inteligentă decât aceasta:
Acest exemplu prezintă lucruri conexe. De la început, arată cum puteți face clientul Subversion să ruleze un program de tuneluri foarte specific (este localizat în / opt / alternate / ssh) cu un anumit parametru. În acest caz, accesarea svn + joessh: // va implica un program SSH special cu argumente -p 29934 - util dacă doriți să conectați programul de tuneluri la un port non-standard.
Apoi, vă arată cum să definiți o variabilă de mediu personalizată care poate suprascrie numele programului de tunel. Setarea variabilei de mediu SVN_SSH este o modalitate convenabilă de a înlocui agentul de tunel SSH în mod implicit. Dar dacă aveți nevoie de mai multe suprapuneri diferite, pentru diferite servere, fiecare poate interacționa cu diferite porturi sau poate transfera diferite seturi de parametri în SSH, puteți utiliza mecanismul prezentat în acest exemplu. Acum, dacă setați variabila de mediu JOESSH. valoarea lui va suprascrie conținutul variabilei tunel - $ JOESSH va fi executat în loc de / opt / alternate / ssh -p 29934.
SSC trucuri de configurare
Este posibilă nu numai gestionarea modului în care clientul execută ssh. dar, de asemenea, să controleze comportamentul sshd pe mașina serverului tău. În această secțiune, vom arăta cum să controlam ce comenzi svnserve sunt numite sshd. precum și modul în care mai mulți utilizatori pot utiliza un cont de sistem.
Articole similare
Trimiteți-le prietenilor: