Running with Ruby

Tag: PHP (page 3 of 5)

Debian (lub Ubuntu) i SVN (Submin, WebSVN) – instalacja i konfiguracja

Ostatnio stawiając serwer deweloperski, spotkałem się z zadaniem postawienia na nim Subversion. Proces stawiania i konfiguracji SVNa miałem przygotować też na zajęcia, więc skoro i tak muszę zebrać to i spisać, postanowiłem zrobić z tego wpis.

Co to jest SVN i z czym to się je?

Subversion (znany również jako SVN) – system kontroli wersji, który powstał w celu zastąpienia CVS. SVN jest wolnym i otwartym oprogramowaniem na licencji Apache.

System kontroli wersji sam w sobie służy do śledzenia zmian głównie w kodzie źródłowym oraz pomocy programistom w łączeniu i modyfikacji zmian dokonanych przez wiele osób w różnych momentach. Mówiąc obrazowo, system kontroli wersji pozwala nam  “upilnować” swój kod. O ile pisząc w pojedynkę małe projekty, system wersjonowania nie przyda się zbytnio, o tyle pisząc coś większego (niezależnie czy samemu czy też w grupie), system kontroli wersji staje się niezbędny.

SVN posiada szereg zalet z których główne to:

  1. Pilnowanie zmian w nazwach plików i katalogów,
  2. Możliwość użycia serwera Apache lub dedykowanego serwera uruchamianego jako inetd albo osobny demon,
  3. Atomowość transakcji, dzięki czemu jesteśmy pewni, że każda zmiana jest zapamiętana w całości i żadna awaria w komunikacji nie jest w stanie zepsuć nam naszej pracy,
  4. Efektywne zarządzaniu repozytorium poprzez stosowanie aliasów, a nie kopiowanie kodu,
  5. Przywracanie dowolnej wersji repozytorium, bądź poszczególnych plików,
  6. Kontrola dostępu do poszczególnych plików (wiadomo kto, kiedy i jakich dokonał zmian),
  7. Możliwość jednoczesnej pracy wielu osób nad różnymi fragmentami kodu, bez ryzyka powstawania konflików.

SVN jest systemem wersjonowania scentralizowanym. Oznacza to że oparty jest on na architekturze klient-serwer, gdzie istnieje jedno repozytorium (źródło kodu) z którym wszyscy użytkownicy systemu synchronizują swoje zmiany. Istnieją także systemy typu P2P lecz nimi w tym artykule zajmować się nie będziemy.

Dlaczego warto używać właśnie SVNa? Oprócz plusów wymienionych parę linijek wyżej, SVN posiada jeszcze jedną bardzo ważną zaletę. Mianowicie jest sprawdzony i popularny. Dzięki temu że jest on popularny, istnieją programy wspomagające korzystanie z tego systemu, zarówno na systemie Linux jak i Windows. Można oczywiście korzystać z SVNa z pomocą wiersza poleceń, lecz na dłuższą metę nie jest to wygodne. Zanim przejdziemy jednak do opisu narzędzi wspomagających, skupmy się może na samym procesie instalacji.

Wymagania wstępne

Aby postawić SVNa i wszystkie związane z nim “bajery”, musimy posiadać serwer. Fajnie by było jakby był na Debianie lub Ubuntu, ponieważ proces instalacji opiszę właśnie pod te systemy. Na początek ustalmy sobie co już mamy mieć:

  • Serwer i prąd
  • Podłączenie do internetu
  • Zainstalowany OS (Debian/Ubuntu)
  • Platformę LAMP (Linux, Apache, MySQL, PHP)
  • Trochę czasu ;)

Jakie są wymagania względem naszego systemu:

  • Możliwość zarządzania użytkownikami (prawa dostępu R i RW)
  • Możliwość tworzenia repozytoriów
  • Możliwość tworzenia grup użytkowników
  • Możliwość przeglądania kodu repozytorium z poziomu przeglądarki internetowej
  • Wszystko co wyżej tylko że wygodnie ;)

Aby osiągnąć powyższe cele, musimy zainstalować i skonfigurować następujące rzeczy:

  • Subversion
  • libapache2-svn (dodatek do Apache umożliwiający korzystanie z SVNa)
  • Submina
  • WebSVN

Instalacja

Proces instalacji wyżej wymienionych komponentów jest bardzo prosty. Aby zainstalować SVNa, wystarczy wpisać to:

sudo apt-get install subversion

Po tej operacji, mamy już dostęp do obsługi SVNa z linii poleceń. Jednak obsługę wiersza poleceń póki co pominiemy. Zajmijmy się dostępem przez http:

sudo apt-get install libapache2-svn

po instalacji musimy zresetować Apache:

sudo /etc/init.d/apache2 restart

Po tej operacji otrzymamy dostęp do naszych repozytoriów (o ile będą widoczne dla Apache) przez http.

Mając już SVNa i wsparcie dla niego z poziomu Apache, przejdźmy dalej. Zainstalujmy i skonfigurujmy sobie Submina. Submin jest przyjaznym interfejsem do zarządzania SVNem z poziomu przeglądarki internetowej. Umożliwia łatwe tworzenie repozytoriów, grup i użytkowników. Aby go zainstalować, musimy do pliku:

/etc/apt/sources.list

dodać następujące repozytorium oprogramowania:

deb http://debian.supermind.nl/ current main

Następnie aktualizujemy bazę oprogramowania oraz instalujemy submina (po każdej linijce zatwierdzamy naciskając enter):

sudo apt-get update
sudo apt-get install submin

Przy instalacji submina, możemy dostać info że pakiety nie są podpisane. Nie jest to nic groźnego (w tym przypadku), zatwierdzamy więc i kontynuujemy. Po instalacji paczek, musimy jeszcze utworzyć całą konfigurację. Zostanie ona utworzona w katalogu /etc/submin, a tworzymy ją następującym poleceniem:

sudo submin-admin create default

Po wygenerowaniu plików, musimy powiadomić Apache, że ma nowy plik konfiguracyjny do uwzględnienia. Najprościej zrobić to, tworząc link symboliczny:

sudo ln -s /etc/submin/default-apache-cgi.conf /etc/apache2/conf.d/submin.conf
# I reset apache
sudo /etc/init.d/apache2 restart

Aby móc korzystać z Submina, musimy jeszcze wyedytować plik konfiguracyjny /etc/submin/default.conf. Ma on wyglądać tak:

[svn]
authz_file = /var/lib/submin/authz
userprop_file = /var/lib/submin/userproperties.conf
access_file = /var/lib/submin/htpasswd
repositories = /var/lib/submin/svn

[www]
base_url = /submin
svn_base_url = /svn
trac_base_url = https://example.com/trac

[backend]
bindir = /usr/share/submin/bin

[generated]
session_salt = SÓL_GENEROWANA_AUTOMATYCZNIE

[trac]
enabled = False
basedir = /tmp

Obsługa tracka jest wyłączona. W sekcji [generated] klucz będzie wygenerowany automatycznie. Podaję cały plik konfiguracyjny, ponieważ nie pamiętam, które wiersze są generowane domyślnie, a które trzeba dopisać samemu. Po wszystkim resetujemy raz jeszcze Apache:

/etc/init.d/apache2 restart

Teraz wchodzimy pod adres http://adres_naszego_serwera/submin, logujemy się korzystając z domyślnego loginu: admin oraz hasła: admin i korzystamy :)

Pozostało nam zainstalowanie WebSVNa. Służyć on będzie administratorowi do przeglądania wszystkich repozytoriów. Dostęp do niego będzie miał główny administrator, z tego względu skorzystamy z najprostszej metody autoryzacji jaką jest AuthType Basic. Zanim jednak do tego przystąpimy, zainstalujmy WebSVNa:

# To nie jest wymagana - koloruje w websvnie składnię
sudo apt-get install enscript
# To już jest wymagane :)
sudo apt-get install websvn

W czasie instalacji, zostaniemy zapytani o kilka rzeczy. Pierwsze pytanie dotyczyć będzie tego, czy WebSVN ma się skonfigurować:

Websvn1

Akceptujemy konfigurację zaznaczając Yes i naciskając Enter. Na następnym ekranie także naciskamy Enter:

Websvn2

Po zatwierdzeniu przechodzimy do trzeciego ekranu, w którym musimy podać miejsce gdzie znajdują się nasze repozytoria:

Websvn3

W tym miejscu wpisujemy adres, gdzie Submin trzyma repozytoria. W naszym wypadku jest to: /var/lib/submin/svn

Zatwierdzamy naciskając Enter. Następne okno zostawiamy puste. Od tego momentu mamy dostęp do WebSVNa pod adresem: http://adres_naszego_serwera/websvn/.

Po wejściu pod powyższy adres ukaże się nam panel. Póki co mamy z nim dwa problemy:

  1. Wyświetla się nieistniejące repozytorium o nazwie “Repos 1”
  2. System nie pyta ani o login ani o hasło

Rozwiązanie pierwszego problemu opisałem w osobnym poście (link).

Jeśli chodzi o drugi problemy, rozwiązaniem jest dodanie autoryzacji. Z pomocą przyjdzie nam sam Apache. Otwieramy plik /etc/websvn/apache.conf i edytujemy go aby wyglądał tak:

# Configuration for websvn using php4.

Alias /websvn /usr/share/websvn

<Directory /usr/share/websvn>
  DirectoryIndex index.php
  Options FollowSymLinks
  Order allow,deny
  allow from all
  AuthType Basic
  AuthName "Subversion Repository"
  AuthUserFile /etc/apache2/dav_svn.passwd
  Require valid-user
  <IfModule mod_php4.c>
    php_flag magic_quotes_gpc Off
    php_flag track_vars On
  </IfModule>
</Directory>

Włączyliśmy w ten sposób autentykację. Dane do weryfikacji brane są z pliku /etc/apache2/dav_svn.passwd, którego póki co nie ma. Aby go utworzyć przechodzimy do katalogu /etc/apache2/, po czym wydajemy następujące polecenie:

# Podstaw za username własny login
sudo htpasswd -c dav_svn.passwd username

Dostaniemy monit o podanie hasła oraz jego potwierdzenie. Po tym plik zostanie utworzony a my będziemy cieszyć się autoryzacją do naszego WebSVNa.

To by było na tyle. Nie pozostaje nam nic innego jak cieszyć się całkiem sprawnie działającym systemem wersjonowania projektów.

ecenter (fr.pl) – czyli kolejna firma krzak na rynku hostingowym w Polsce

Od kilku dni przyszło mi się użerać (tak użerać) z wyżej wspomnianą firmą. Zaczynam dochodzić do wniosku, że zrobię osobną zakładkę, na firmy których nie polecam. Od razu dodam, że żeby zajść mi za skórę, trzeba być wybitnie kiepskim providerem. Zwłaszcza jeśli nie chodzi o Rubiego i Railsy, ale o samo PHP. A właśnie tak jest w tym wypadku.

Cała sprawa jest dość prosta (a przynajmniej tak by się wydawało). Ot okazało się, że pora przenieść usługi na inny hosting. Nic trudnego! Toż to tylko skopiowanie plików po FTP i przeniesienie bazy. Zmiana pliku konfiguracyjnego i przepięcie domeny. Marzenie ściętej głowy.

Problem nr 1 – główne konto FTP

Pierwszy problem był dość prozaiczny, mianowicie nie istnieje (czyt. nie działa) konto główne FTP. Czyli de facto nie da się zgrać całej zawartości konta. Ten problem udało się rozwiązać “na około”. Udało mi się zdobyć wystarczająco dużą ilość kont FTP które mają dostęp do subkatalogów. Dzięki temu uzyskałem dostęp do wszystkich zasobów krytycznych. Tak przynajmniej myślałem …

Problem nr 2 – masz dostęp po FTP – ale nie masz praw do plików

Człowiek cieszy się że ma dostęp do FTP a tu… zonk. Brak praw do odczytu plików. Próba zmiany uprawnień nic nie dała. Dalej to samo. Chmod z shella nie wchodzi w grę bo shella nie ma. Jedynym uprawnionym do odczytu jest Apache.

Problem nr 3 – pomoc i wsparcie? Zapomnij!

Moje e-maile były zbywane. Tzn. może ktoś je odczytał ale odpowiedzi czy też potwierdzenia nie dostałem. Dla mnie jest to jednoznaczne. Klient czeka 10 dni na odpowiedź i się nie doczeka ==> mamy gdzieś klienta. Jest jeszcze druga metoda kontaktu: telefon. Na podaną na ich stronie infolinię nie ma sensu dzwonić. W przeciągu 10 dni, nie odebrał nikt. Trzeba było więc kombinować inaczej. Rożnymi “drogami” udało mi się pozyskać dodatkowe 2 numery telefonów do pracowników tej firmy. Pracownik do którego się dodzwoniłem był na urlopie – ok zdarza się. Z początkiem tygodnia miał być w pracy i dziwnym trafem tego dnia, nie odbierał telefonu ;)

Spróbuj z pomocą wyższych instancji

Aby uzyskać jakąś reakcję ze strony ecenter, musiałem w proces “wyciągania” plików, zaangażować osoby mające “więcej do powiedzenia”. Dopiero po ich telefonach i mailach udało mi się uzyskać dostęp do plików.

Damy Ci dostęp ale utrudnimy życie …

Tak jak napisałem wyżej, otrzymałem dostęp do plików. Można wręcz powiedzieć że otrzymałem dostęp wyjątkowy i nie byle jaki. Mianowicie na serwerze w piątek znalazła się paczka z plikami z danych katalogów. Tu 2.5GB tam paręset mega … Z racji tego że miałem inne zajęcia, ściąganie pozostawiłem na niedzielny wieczór, żeby mieć dane na poniedziałek rano. Jakie było moje zdziwienie kiedy okazało się że … plików już nie ma. Admin je usunął. Na moje głuche telefony, dostałem jednego smsa w którym proszono abym napisał co sie dzieje smsem. No to napisałem. Wiadomość zwrotna była zadziwiająca. Zawierała info że pliki zostały usunięte bo się nam … śpieszyło. Ja się pytam: co to ku**a ma byc? Czy ja czegoś nie wiem? Od kiedy firma hostingowa może usuwać pliki z kont bo wydaje jej się że nie są już potrzebne… Szkoda że nie zapytali, bo dowiedzieliby się, że np. nie tylko ja zamierzałem pobrać te paczki ale także ludzie którzy pracują od poniedziałku do piątku…

Problem 4 – znowu to samo

Teraz trzeba było powiadomić ecenter o tym że pliki są nam potrzebne. Mail nie działa, telefon nie odpowiada… Ale w końcu się udało… no może prawie… Tym razem tar.gz był, ale żeby nie było zbyt pięknie, tylko do jednego z subkatalogów. Reszty nie ma ale będzie jak ściągniemy ten plik który mamy. Powód tym razem jest następujący: brak miejsca na serwerze. A przedtem to było?

2.5 tygodnia – udało się! (prawie)

Po okresie około 20 dni, udało się załatwić sprawę. Udało się dodzwonić do jednego z pracowników i “lekko” wzburzonym głosem poprosić o przelecenie chmod’em plików na koncie, tak aby user FTP mógł je pobrać. Bardzo trudna sprawa dla adminów. Nie ma co…

3 tygodnie – przenosiny

Po ponad 3 tygodniach rozpoczęliśmy procedurę przenosin do innej firmy hostingowej. Zgrywanie danych zajęło trochę czasu, ponieważ było ich dość sporo. Oczywiście pliki nowo utworzone przez panel www, znowu nie miały poprawnych ustawień. Na szczęście było ich tylko 16 – więc zgrałem je wpisując adres każdego pliku w oknie przeglądarki.

Całość przenosin trwałaby góra 2 dni (a co za tym idzie kosztowała dużo mniej), gdyby nie podejście “administratorów” firmy ecenter.

Podsumowanie

Podsumowując firmę ecenter, mogę śmiało powiedzieć, że NIE POLECAM tej firmy. Sam u nich nie mam konta, jednak doświadczenia z poprzednich 3 tygodni pokazały mi, jak użytkownicy są w tej firmie traktowani. Na domiar wszystkiego, klient którego usług migrację robiłem, miał tam konto prestiż. Prestiż czekania na chmoda, nie ma co. Problemy z uprawnieniami do plików, jakieś dziwne “obchodzenie” wszystkiego naokoło, problemy z panelem admina oraz parę innych problemów – to są wystarczające powody aby NIE korzystać z usług tej “firmy”.

Olderposts Newerposts

Copyright © 2020 Running with Ruby

Theme by Anders NorenUp ↑