Teljes értékű Drupal fejlesztőkörnyezet kialakítása Ubuntu Linux rendszeren

Az Integral Vision Workshopra készülve eszembe jutott, hogy hasznos lenne bemutatni egy olyan alaprendszer elkészítését, amely könnyebbé teszi a Drupallal való munkát. Egy olyan teljes értékű, Linux alapú fejlesztőkörnyezetről lesz szó, amelyikkel könnyedén használhatóvá válik a Drupal. Hogy a lépéseket követve biztosan így lesz, mi sem bizonyítja jobban, mint hogy az általam a mindennapokban használt rendszert mutatom be. Ezért ez a bejegyzés önmagamnak is szól, hogy ha bármikor újra el kell készítenem egy ilyen rendszert, ne felejtsek ki belőle semmit. A leírásban külön jelzem azokat a parancsokat, amelyeket terminálban ki kell adni, illetve így jelölöm a módosítani szükséges fájlok tartalmát is. A kiadott parancsok elé $ jelet teszek, ezeket természetesen nem kell beírni, csak a parancsot jelzik.
A telepítést Ubuntu Linux 11.04 (Natty Narwhal) rendszeren mutatom be, de valószínűleg néhány apróbb módosítással sikeresen alkalmazható akár régebbi, akár teljesen más Linux alapú rendszeren is. A leírás nem tartalmazza az Ubuntu telepítését, mivel az számtalan helyen fellelhető, ezért egy frissen telepített, módosításokat nélkülöző rendszerből indul ki.

1. A célok

  • szükség van Apache webszerverre, MySQL adatbázis-szerverre és a legfrissebb PHP-re
  • legyen phpMyAdmin, használhassunk Drush-t
  • a PHP a rendszert használó felhasználó nevében fusson, így elkerülve a jogosultsági problémákat
  • legyen egy .l legfelsőbb-szintű domain, amelyik a gépre mutat, így virtualhostok állítgatása nélkül adhatunk hozzá új oldalt a rendszerhez

A rendszer akkor van kész, ha:

  • az l10n_install segítségével fel tudunk telepíteni egy Drupal 7 alaprendszert a fordításokkal együtt (PHP túlfutási-veszély!)
  • az új oldalt az Apache állítgatása nélkül elérjük a http://enoldalam.hu.l/ címen

2. Telepítsük a hiányzó csomagokat

Mivel az Ubuntu asztali-rendszerként való telepítése nem tartalmazza a kiszolgálóként való használathoz szükséges csomagokat, azokat nekünk külön kell feltenni.

$ sudo apt-get install apache2 apache2-suexec libapache2-mod-fcgid php5-cgi php5-curl php5-gd php5-mcrypt php5-mysql phpmyadmin mysql-server mysql-client

A parancs kiadása meg kell adnunk a jelszavunkat, majd engedélyezzük a további szükséges csomagok telepítését is, állítsuk be a MySQL rendszergazdai jelszavát („While not mandatory, it is highly recommended that you set a password for the MySQL administrative "root" user.”) és a phpmyadmin konfigurálásánál a szóköz billentyűvel válasszuk ki az apache2-őt („Please choose the web server that should be automatically configured to run phpMyAdmin”), végül engedélyezzük, hogy a dbconfig-common beállítsa a phpmyadmin-t, itt is megadva egy jelszót (lehet ugyanaz, mint a MySQL-nél).

Ha mindent jól csináltunk, akkor a böngészőbe beírva a http://localhost/ címet egy „It works!” szöveg fog minket fogadni. Ez mutatja, hogy az Apache működésre kész.

Amennyiben a fenti szöveg nem jelenne meg a böngészőben, úgy indítsuk újra a webszervert:

$ sudo service apache2 restart

3. A PHP megszelidítése

Sajnos ennyivel nem úsztuk meg, mivel a PHP még nem működőképes. Első lépésként állítsuk át az Apache alapértelmezett munkakönyvtárának jogosultságait, a parancsban a kiemelt „felhasznalo” szavak helyére a saját Ubuntus felhasználónevünket írjuk be.

$ sudo chown felhasznalo:felhasznalo -R /var/www/

Hozzunk létre egy /var/www/cgi-bin könyvtárat:

$ mkdir /var/www/cgi-bin/

Majd abban egy php-fcgid nevű fájlt:

$ gedit /var/www/cgi-bin/php-fcgid

A fájl tartalma legyen a következő:

#!/bin/sh
PHPRC=/etc/php5/cgi/
export PHPRC
export PHP_FCGI_MAX_REQUESTS=5000
export PHP_FCGI_CHILDREN=8
exec /usr/lib/cgi-bin/php

Miután elmentettük és kiléptünk, adjunk rá futtatási jogot:

$ chmod u+x /var/www/cgi-bin/php-fcgid

Engedélyezzük az Apache Suexec kiterjesztését és a rövid URL-ek használatát:

$ sudo a2enmod suexec rewrite

Nyissuk meg szerkesztésre a /etc/apache2/sites-available/default állományt:

$ sudo gedit /etc/apache2/sites-available/default

A vége felé találunk benne egy ilyen részt:

Alias /doc/ "/usr/share/doc/"
<Directory "/usr/share/doc/">
    Options Indexes MultiViews FollowSymLinks
    AllowOverride None
    Order deny,allow
    Deny from all
    Allow from 127.0.0.0/255.0.0.0 ::1/128
</Directory>

Ez a rész után és a fájlt lezáró </VirtualHost> elé szúrjuk be a következő szöveget, a kiemelt „felhasznalo” szavak helyére a saját Ubuntus felhasználónevünket írva:

<IfModule mod_fcgid.c>
  SuexecUserGroup felhasznalo felhasznalo
  <Directory /var/www/>
      Options +ExecCGI
      AddHandler fcgid-script .php .phtml
      AddType application/x-httpd-php .php .phtml
      FCGIWrapper /var/www/cgi-bin/php-fcgid .php
      FCGIWrapper /var/www/cgi-bin/php-fcgid .phtml
  </Directory>
</IfModule>

A PHP-t már működésre bírtuk, de a phpMyAdminért még dolgozni kell. Nyissuk meg a konfigurációs állományát:

$ sudo gedit /etc/apache2/conf.d/phpmyadmin.conf

A fájl legvégére illesszük be a következő részt, a kiemelt „felhasznalo”-t itt is cseréljük le az Ubuntus felhasználónevünkre:

<IfModule mod_fcgid.c>
  SuexecUserGroup felhasznalo felhasznalo
  <Directory /usr/share/phpmyadmin>
      Options +ExecCGI
      AddHandler fcgid-script .php .phtml
      AddType application/x-httpd-php .php .phtml
      FCGIWrapper /var/www/cgi-bin/php-fcgid .php
      FCGIWrapper /var/www/cgi-bin/php-fcgid .phtml
  </Directory>
</IfModule>

Futassuk le a következő parancsot, a kiemelt „felhasznalo” helyett itt is a telepített rendszeren használt felhasználónév kell:

$ sudo chown :felhasznalo /etc/phpmyadmin/config-db.php

Végül indítsuk újra az Apache webszervert:

$ sudo service apache2 restart

Amennyiben a phpMyAdminba történő bejelentkezés után a „Cannot start session without errors, please check errors given in your PHP and/or webserver log file and configure your PHP installation properly.” hibaüzenetet kapjuk, akkor ürítsük a böngésző gyorsítótárát.

4. PHP finomhangolása

Ha létrehozunk egy teszt.php fájlt a /var/www alatt, amelynek a tartalma a következő:

<?php
phpinfo();

Akkor a böngészőben a http://localhost/teszt.php oldalt meglátogatva részletes információt kaphatunk a PHP beállításairól. Ahhoz, hogy a rendszer munkára alkalmas legyen, további teljesítmény-hangolást célszerű végeznünk. Először is szerkesszük a PHP beállításait tartalmazó fájlt:

$ sudo gedit /etc/php5/cgi/php.ini

A fájlban a „max_execution_time” szóra rákeresve az értékét emeljük fel az alapértelmezett 30 másodpercről, ugyanezt tegyük meg a „max_input_time” és „memory_limit” változók értékével is. A kiemelt „256M” érték határozza meg a PHP által felhasználható legnagyobb memóriamennyiséget (256 megabyte), kevesebb memóriával rendelkező gépen érdemes lehet csökkenteni, de nem érdemes 128 alá menni.

max_execution_time = 600
max_input_time = 600
memory_limit = 256M

Hogy nagyobb fájlok feltöltésével se legyen gond, emeljük meg ugyanitt a „post_max_size” és „upload_max_filesize” értékét.

post_max_size = 256M
upload_max_filesize = 2G

A mod-fcgid (PHP futtatásához használt CGI környezet) beállításait a következő fájlban érjük el:

$ sudo gedit /etc/apache2/mods-available/fcgid.conf

A fájlt megnyitva a tartalmát cseréljük le erre:

<IfModule mod_fcgid.c>
  AddHandler fcgid-script .fcgi
  FcgidConnectTimeout 20
  ProcessLifeTime 7200
  IPCCommTimeout  7200
  IPCConnectTimeout 7200
  FcgidMaxRequestLen 1073741824
  PHP_Fix_Pathinfo_Enable 1
</IfModule>

Mentés és kilépés után a szokásos módon indítsuk újra az Apache-t:

$ sudo service apache2 restart

5. Kell egy Drush

A Drush a Drupal fejlesztőknek egy igazi svájcibicska. Persze nem csak ők veszik a hasznát, hanem mindenki, aki komolyabban üzemeltet Drupal alapú rendszert.

A használatához kell egy újabb csomag:

$ sudo apt-get install php5-cli

A telepítése után töltsük le a Drush-t, most éppen a 4.4 az aktuális kiadás:

$ mkdir ~/bin
$ wget http://ftp.drupal.org/files/projects/drush-7.x-4.4.tar.gz
$ tar xf drush-7.x-4.4.tar.gz
$ rm drush-7.x-4.4.tar.gz
$ ln -s ~/drush/drush ~/bin/drush
$ ~/bin/drush

Ezután a következő ki- és bejelentkezés (vagy újraindítás) után már lehetőség lesz a Drush használatára.

6. Saját domain beállítása

Azt szeretnénk, hogy ne kelljen minden egyes oldal fejlesztésekor új bejegyzést felvenni az Apache-ba, hanem a rendszer kezelje ezt automatikusan. Először is készítsünk egy munkakönyvtárat, amelyben az oldalak kódjait fogjuk tárolni. Ennek a neve bármi lehet, én „Virtualhosts” néven nevezem:

$ mkdir ~/Virtualhosts
$ sudo apt-get install dnsmasq resolvconf

Szerkesszük a konfigurációs állományát:

$ sudo gedit /etc/dnsmasq.conf

Keressünk benne egy ilyen bejegyzést:

# Add domains which you want to force to an IP address here.
# The example below send any host in double-click.net to a local
# web-server.
#address=/double-click.net/127.0.0.1

Írjuk utána egy új sorba a következőt:

address=/l/127.0.0.1

Itt a „l” azt a domaint jelenti, amelyet szeretnénk a gépünkre irányítani.

Mentsük el, lépjünk ki a szerkesztőből majd indítsuk újra a szolgáltatást (vagy ami még érdemesebb, az egész gépet):

$ sudo service dnsmasq restart

Ezután, ha megpingelünk egy tetszőleges .l végződésű hosztot, sikeresnek kell lennie:

$ ping foobar.l
PING foobar.l (127.0.0.1) 56(84) bytes of data.
64 bytes from localhost (127.0.0.1): icmp_req=1 ttl=64 time=0.025 ms
64 bytes from localhost (127.0.0.1): icmp_req=2 ttl=64 time=0.038 ms
64 bytes from localhost (127.0.0.1): icmp_req=3 ttl=64 time=0.040 ms

Hozzunk létre egy új Apache konfigfájlt:

$ sudo gedit /etc/apache2/sites-available/virtualhost_wildcard

A tartalma legyen a következő:

<VirtualHost *:80>
        ServerAlias *.l
        VirtualDocumentRoot "/home/felhasznalo/Virtualhosts/%0/"
        <Directory "/home/felhasznalo/Virtualhosts/">
                Options FollowSymLinks
                AllowOverride All
                Order allow,deny
                Allow from all
                DirectoryIndex index.html index.php
        </Directory>
        ScriptAlias /cgi-bin/ /usr/lib/cgi-bin/
        <Directory "/usr/lib/cgi-bin">
                Order allow,deny
                Allow from all
        </Directory>
        ErrorLog ${APACHE_LOG_DIR}/virtualhost-error.log
        # Possible values include: debug, info, notice, warn, error, crit,
        # alert, emerg.
        LogLevel info
        CustomLog ${APACHE_LOG_DIR}/virtualhost-access.log combined
  <IfModule mod_fcgid.c>
    SuexecUserGroup felhasznalo felhasznalo
    <Directory "/home/felhasznalo/Virtualhosts">
      Options +ExecCGI
      AddHandler fcgid-script .php .phtml
      AddType application/x-httpd-php .php .phtml
      FCGIWrapper /var/www/cgi-bin/php-fcgid .php
      FCGIWrapper /var/www/cgi-bin/php-fcgid .phtml
    </Directory>
  </IfModule>
</VirtualHost>

A fájl tartalmában két dologra figyeljünk: A „felhasznalo” helyett itt is az Ubuntu rendszerünkön használt felhasználónevünket kell megadni, a „/home/felhasznalo/Virtualhosts” pedig annak a könyvtárnak a teljes elérési útja, ahol az oldalainkat tárolni szeretnénk.

Mentés és kilépés után engedélyezzük az új beállítást, majd a szokásos Apache újraindítás:

$ sudo a2enmod vhost_alias
$ sudo a2ensite virtualhost_wildcard
$ sudo service apache2 restart

Ezek után hozzunk létre egy új könyvtárat:

$ mkdir ~/Virtualhosts/enoldalam.hu.l

Ha a könyvtárban létrehozunk egy index.html fájlt, akkor láthatjuk, hogy a könyvtár tartalmát elérjük a http://enoldalam.hu.l/ címről. Amennyiben a könyvtárba Drupalt telepítünk, nyissuk meg szerkesztésre a Drupalhoz mellékelt .htaccess fájlt, és keressük meg a következő részt:

# If your site is running in a VirtualDocumentRoot at http://example.com/,
# uncomment the following line:
# RewriteBase /

Itt az utolsó (RewriteBase) sor elől töröljük ki a # jelet, majd mentsük el a fájlt, ezzel válik lehetővé a rövid URL-ek használata is.

Szükség esetén a konfigurációs fájl elején a ServerAlias direktíva után elhelyezhetjük a következő sort, amellyel egyéni .htaccess fájlokat rendelhetünk a Virtualhost-okhoz, így a Drupalhoz adott eredeti fájlt nem kell módosítani a fejlesztéshez:

AccessFileName .htaccess.l # egyeni .htaccess fajlok a virtualhosztokhoz

Az alkalmazása után szükség van az Apache újraindítására a fentebb leírt módon.

7. HTTPS beállítása

Fejlesztés során szükségünk lehet arra, hogy a gépen futó oldalainkat titkosított HTTPS kapcsolattal érjük el. Önaláírt (self-signed) hitelesítést hozunk létre, erre a legtöbb böngésző figyelmeztetést dob majd az oldal első meglátogatásakor, nyugodtan figyelmen kívül hagyhatjuk és engedélyezzük az oldal letöltését.

Az önaláírt hitelesítés elkészítéséhez szükség van egy újabb csomagra:

$ sudo apt-get install ssl-cert

Majd engedélyezzük az Apache webszerver számára az SSL kiegészítés betöltését:

$ sudo a2enmod ssl

Nyissuk meg szerkesztésre a beállításokat tartalmazó fájlt:

$ sudo gedit /etc/apache2/sites-available/virtualhost_wildcard

Az állomány végére illesszük be a következő sorokat, akár néhány sortöréssel elválasztva a korábbi tartalomtól:

<IfModule mod_ssl.c>
<VirtualHost *:443>
        ServerAlias *.l
        VirtualDocumentRoot "/home/felhasznalo/Virtualhosts/%0/"
        <Directory "/home/felhasznalo/Virtualhosts/">
                Options FollowSymLinks
                AllowOverride All
                Order allow,deny
                Allow from all
                DirectoryIndex index.html index.php
        </Directory>
        ScriptAlias /cgi-bin/ /usr/lib/cgi-bin/
        <Directory "/usr/lib/cgi-bin">
                Order allow,deny
                Allow from all
        </Directory>
        ErrorLog ${APACHE_LOG_DIR}/virtualhost-error.log
        # Possible values include: debug, info, notice, warn, error, crit,
        # alert, emerg.
        LogLevel info
        CustomLog ${APACHE_LOG_DIR}/virtualhost-access.log combined
	<IfModule mod_fcgid.c>
               SuexecUserGroup felhasznalo felhasznalo
		<Directory "/media/data/Virtualhost">
			Options +ExecCGI
			AddHandler fcgid-script .php .phtml
			AddType application/x-httpd-php .php .phtml
			FCGIWrapper /var/www/cgi-bin/php-fcgid .php
			FCGIWrapper /var/www/cgi-bin/php-fcgid .phtml
		</Directory>
	</IfModule>
	SSLEngine on
	SSLCertificateFile    /etc/ssl/certs/ssl-cert-snakeoil.pem
	SSLCertificateKeyFile /etc/ssl/private/ssl-cert-snakeoil.key
	<FilesMatch "\.(cgi|shtml|phtml|php)$">
		SSLOptions +StdEnvVars
	</FilesMatch>
	<Directory /usr/lib/cgi-bin>
		SSLOptions +StdEnvVars
	</Directory>
	BrowserMatch "MSIE [2-6]" \
		nokeepalive ssl-unclean-shutdown \
		downgrade-1.0 force-response-1.0
	BrowserMatch "MSIE [17-9]" ssl-unclean-shutdown
</VirtualHost>
</IfModule>

Itt is figyeljünk arra, hogy a „felhasznalo” szöveget cseréljük ki a rendszerben használt felhasználónevünkre, a „/home/felhasznalo/Virtualhosts” helyett pedig azt a könyvtárat adjuk meg, ahol az oldalainkat tároljuk.

Ha mindent jól csináltunk, akkor már csak egy Apache újraindításra van szükség:

$ sudo service apache2 restart

8. És ha PHP 5.2 kell?

A következő műveletet kellő óvatossággal kell végezni, mivel mélyebben megvariálja a rendszer működését.

Hozzunk létre egy új fájlt:

$ gedit ~/php.sh

A tartalma pedig legyen a következő:

#!/bin/sh
# Script to install PHP 5.2 from 9.10 on 10.04
# And pin it so it does not get updated
PKGS=`dpkg -l | grep php | awk '{print $2}'`
apt-get remove $PKGS
sed s/natty/karmic/g /etc/apt/sources.list | 
  tee /etc/apt/sources.list.d/karmic.list
mkdir -p /etc/apt/preferences.d/
for PACKAGE in $PKGS
do
  echo "Package: $PACKAGE
Pin: release a=karmic
Pin-Priority: 991
" | tee -a /etc/apt/preferences.d/php
done
apt-get update
apt-get install $PKGS

A fájlban több helyen szerepel a rendszer verziójának kódneve („natty”), ha régebbi Ubuntu kiadást használunk, akkor ezt módosítani kell. Mentés és kilépés után futtassuk le:

$ sudo ~/php.sh

Én nem engedtem, hogy a dbconfig piszkálja a phpMyAdmin beállításait, és a csomagok konfigurálásakor is ragaszkodtam ahhoz, hogy tartsa meg az eredeti fájlokat. A fenti szkript eltávolítja a PHP 5.3-as csomagokat, és az Ubuntu „Karmic Koala” verziójából feltelepíti a megfelelő PHP 5.2-eset. Valamiért a phpMyAdmin egyelőre nem működik ez a varázslás után, de ha rájövök, akkor mindenképpen megosztom itt az eredményt.

9. Kapcsolódó bejegyzések

Régebbi bejegyzéseim között megtalálható, hogy milyen Xdebug beállítást használok a hibakereséshez, és hogy milyen módon kerül fel a fájlok feltöltéséhez használt uploadprogress a gépre.
Továbbá készült leírás arról is, milyen módon lehet az így elkészített fejlesztői környezet teljesítményét tovább fokozni: Tuningoljuk a fejlesztőkörnyezetet!

Hozzászólások

Üdv.

Az AddHandler-nek van egy kevesse ismert mellekhatasa: nem csak a fajlnevek vegen levo utolso kiterjesztesre matchel:
http://ilia.ws/archives/226-Beware-of-the-default-Apache-2-config-for-PH...
https://bugzilla.redhat.com/show_bug.cgi?id=537535
http://www.mail-archive.com/suphp%40lists.marsching.biz/msg00067.html

nem probaltam ki a leirasod, de meg kellene nezni, hogy mihez kezd egy user altal feltoltott foobar.php.txt fajllal a fastcgi.
ranezesre meg fog hivodni az fcgid-script, igaz az application/x-httpd-php mimetype nelkul, de ettol meg szerintem vegre fogja hajtani php kodkent a fajl tartalmat.

Tyrael

Köszönöm a megjegyzésed, én nem tudtam róla, de ettől még simán lehetséges. Ha esetleg fellép (ki fogom próbálni), akkor mit javasolsz megoldásnak?

Ui: Kipróbáltam a fejlesztéshez használt rendszeremen, „Internal Server Error”, a logban pedig „Premature end of script headers: teszt.php.txt”. Az „AddType”-ot kipróbálom majd ez alapján, és ha beválik, módosítom a leírást.

Nem vagyok Drupal fejlesztő, de azért átolvastam és a dnsmasq-t érdekesnek találtam, meg fogom vizsgálni :)

Viszont azt nem értem, hogy ha ez egy privát fejlesztői rendszer (akár Virtualboxra telepítve is), akkor a PHP miért nem modulként van az Apache-ban, miért kell "cigizni"...? Egy fejlesztői rendszernél, amit jó esetben egyedül használunk nincs sok haszna a cgi-s jogosultság dolognak. Vagy más oka van?

Apache modulként futtatva a PHP-t az az Apache-t futtató felhasználó nevében fog futni, ami a legtöbb rendszeren a www-data. Nagyon sok kellemetlenséget tud ez okozni, mert pl. PHP nem tud dolgozni egy könyvtárba, amibe te igen, nem tudod letörölni a PHP által létrehozott fájlokat, már régóta szerkesztesz egy fájlt, amit nem tudsz elmenteni, mert a PHP hozta létre és neked nincs jogod írni bele, stb. A végén már az volt a megoldás, hogy a problémákat megelőzendő mindenre teljes jogosultságot adott az ember, de nyilván ez sem túl életszerű.
Ezért volt a rendszer létrehozásának egyik alapkitétele, hogy a PHP a rendszert használó felhasználó nevében fusson, ezt pedig Apache modulként nem tudod megtenni.

"ezt pedig Apache modulként nem tudod megtenni."
dehogynem, egyreszt debian-on a /etc/apache2/envvars fajlban atirhatod a kovetkezo sorokat:
export APACHE_RUN_USER=www-data
export APACHE_RUN_GROUP=www-data

masreszt http://httpd.apache.org/docs/2.2/mod/mpm_common.html User/Group direktivan keresztul is szabalyozhato.

ps: de tobb php verzio parhuzamos egymas mellett futtatasara tenyleg kenyelmesebb a fastcgi

Tyrael

Oké, valóban, eleve egy nyílt forráskódú rendszeren minden átírható. Én azért erősen gyanítom, hogy nagyobb munka lenne készre csiszolni a rendszert, ha elvennénk az Apache-tól a www-data felhasználót. Az is igaz, hogy nem próbáltam, mert amikor beleuntam a "www-data" hülyülésbe, akkor kerestem egy megoldást és az ez lett. Természetesen ettől függetlenül létezhetnek más jó megoldások is. :)

AddHandler/SetHandler is jo lehet, csak vizsgald meg, hogy tenyleg megadott kiterjesztesre vegzodik a script, debian lenny ezt csinalta:

SetHandler application/x-httpd-php

SetHandler application/x-httpd-php-source

# To re-enable php in user directories comment the following lines
# (from to .) Do NOT set it to On as it
# prevents .htaccess files from disabling it.

php_admin_value engine Off

vagy hasznalhatsz AddType-ot is.

Tyrael

"hogy nagyobb munka lenne készre csiszolni a rendszert, ha elvennénk az Apache-tól a www-data felhasználót. "
en igy hasznalom a sajat devel kornyezete(i)mben, mukodik szepen, annyi kellett neki, hogy a DocumentRoot konyvtara(ka)t at kellett chown-olni a sajat nevemre, de ezt a te megoldasodnal is meg kell csinalni, igaz ott vhostonkent allithato a user(bar te is csak a www-data meg a sajat useredet hasznalod).

Tyrael

nem szereti a forummotor az apache xml configjat(pontosabban plain text-kent kellett volna bekuldjem), szoval inkabb belinkelem:
http://kimbriggs.com/computers/computer-notes/linux-notes/apache2-virtua...

Tyrael

Köszönöm ezt a "receptet" - pont a legjobbkor találtam meg, mostanában készülök Ubuntu-t felrakni Drupal-ozáshoz, szóval ki fogom próbálni :)

Sziasztok, felraktam virtualbox -ra egy ubuntut és a leírás alapján csináltam mindent azonban a loc -ra végződő domain -eknél Forbiddent kapok, nem ad hozzáférést a Virtualhost könyvtárban szereplő oldalakhoz. Valakinek van ötlete, mi lehet a baj?

Ezek megvoltak?

sudo a2enmod vhost_alias
sudo a2ensite virtualhost_wildcard
sudo service apache2 restart

Próbáltad, hogy újraindítod a virtuális gépet?

Az /etc/apache2/mods-available/fcgid.conf fájlba még érdemes beírni a "FcgidMaxRequestLen 1073741824" sort, mivel nekem enélkül nem ment hibátlanul Drupal 7 alatt a fájlfeltöltés.
Bövebb info: http://httpd.apache.org/mod_fcgid/mod/mod_fcgid.html#fcgidmaxrequestlen

Kiegészítettem a leírást azzal, hogy az Apache virtualhostnál megadható egyedi .htaccess fájl, amelyet a használt verziókezelőben letiltva nem mentjük el a kódbázisba a módosításai:

AccessFileName .htaccess.loc # egyeni .htaccess fajlok a virtualhosztokhoz

Ebbe érdekes módon most én is belefutottam (pedig nem először csinálom már, biztosan pontosan, és korábban szerintem nem fordult ez elő, ugyanígy Ubuntu 11.04 rendszeren, sőt szimplán csak modulként PHP verzió esetén is ez volt, amikor saját pulic_html-t akartam beállítani). Ha esetleg aktuális még, vagy más is ebbe botlana, nálam csak annyi kellett, hogy futási jogot adjak a home-omra:
chmod +x ~

Rendszergazdai szemmel a FastCGI jobb megoldás, ugyanis azt el lehet szeparálni a többi site-tól (más userrel futtatni), így egy esetleges sikeres támadás esetén csak az adott applikációt tudják elérni, a többihez nincs joguk. Ha semmiképpen sem szeretjük a FastCGI-t, akkor egy esetleges megoldás lehet, hogy több Apache-ot futtatunk a gépen más-más user nevében más-más porton, majd ezeket a "pound" reverse proxy segítségével össze lehet vonni a 80-as port alá...

Én azért is szeretem a FastCGI-t, mert programhiba esetén könnyen ki lehet írtani az elszabadult PHP processzeket, még mielőtt megeszik a rendszer erőforrásait.

Ez egy alap dolog, nyilván a webszervert futtató usernek hozzá kell férnie az adott könyvtárhoz, ehhez kell a $HOME-ra a "futtatás" jog...

Pár észrevétel:

1. se dnsmasq, se resolvconf nem kell, elég a /etc/hosts fájlba beírni, hogy "127.0.0.1 foobar.loc".
2. az Apache szereti, ha van megadva ServerName, különben dob egy warningot, azt pedig a rendszergazdák nem nagyon szeretik.
3. sudo chown :felhasznalo ... nem igazan helyes szintaktika, túl sok a ":"
4. ahogy az korábban is felmerült, ahhoz, hogy a /home/felhasznalo alol elérhetőek legyenek a weboldalak, a /home/felhasznalo könyvtáron szükség van futtatási jogra, va /home/felhasznalo/Virtualhosts könyvtáron pedig extraként olvasási jogra is. Épp ezért nem szokták a felhasználó HOME könyvtárába tenni a vhostokat. Erre egyszerűbb a /var/www alatt létrehozni egy vhosts könyvtárat, melyet aztán át lehet adni a felhasználónak...
5. az "apt-get remove $PKGS" nem törli a konfigot, ezért korábbi phpmyadmint visszatolva nem biztos, hogy minden működni fog. "aptitude purge" vagy "apt-get remove --purge" törli a konfigot is, de ez általam nem tesztelt, backup nélkül nem javasolt míg nem tudod pontosan hogyan működik...

Szia!
Sikerült a leírás alapján felraknom egy Ubuntu 11.04-re a fejlesztőkörnyezetet.
Aldomaint hogyan lehetne rajta "modellezni"? Tehát van a domain.hu.loc, ez alá a sites könyvtárba csinálnék egy aldomain.domain.hu.loc könyvtárat, url valamint mysql elérés ennek megfelelően beállítva, viszont nem tudok hozzá így csatlakozni.

Aldomaint szerintem közvetlenül állítanék be a „default” Apache konfigurációs fájl másolásával és szerkesztésével. Esetleg a „virtualhost_wildcard” fájlban megadható másféle behelyettesítési minta is a „%1%-2” helyett, erről itt találsz több információt: http://httpd.apache.org/docs/2.0/mod/mod_vhost_alias.html
Néha szoktam azt is alkalmazni, hogy a böngészőbe beírom a használni kívánt címet, majd az Apache hibanaplóban megnézem, hogy milyen néven kereste a könyvtárat, majd azt hozom létre.
Ha jól értelmezem, akkor te több címet szeretnél egy Drupallal kiszolgálni (multisite), akkor pedig a sima linkelés is segíthet, pl így:
ln -s ~/Virtualhosts/enoldalamhu ~/Virtualhosts/enoldalam2hu
Ezután a Drupal telepítés már nem csak az http://enoldalam.hu.loc/ címen lesz elérhető, hanem az http://enoldalam2.hu.loc/ címről is.

Szia!
11.11-en ezt a hibaüzenetet hozza a localhost/teszt.php böngészőbe meghívásakor:
Connection reset by peer: mod_fcgid: error reading data from FastCGI server

Az így kialakított környezetet hogyan lehet elérni virtualboxból? Addig megvan, hogy xpből a http://10.0.2.2/ ipcímen elérem a ~/public_html könyvtárat, de onnan meg le akar tölteni mindent, hiába tekergettem .htaccesst.

A virtualbox és a hoszt-rendszer között milyen virtuális hálózat van? Meg kellene nézni, hogy a hoszt-rendszer milyen IP-címen érhető el a virtuális gép felöl. Ebben segít Linux alatt az „ifconfig -a”, Windows alatt pedig az „ipconfig /all” parancs.

Mindent pontosan így csináltál? Milyen verzió alatt? Az Apache error log nem tartalmaz semmit? Ez utóbbit a /var/log/apache2 könyvtár alatt találod.

Eddig ez volt benne:
VirtualDocumentRoot "/home/felhasznalo/Virtualhosts/%1%-2/"
Így az enoldalam.hu.loc meglátogatása esetén a /home/felhasznalo/Virtualhosts/enoldalamhu könyvtárat kereste.
Nem tudom már pontosan, hogy ezt miért gondoltam jó logikának, hiszen a könyvtárnévben is lehet pont.
Most már VirtualDocumentRoot "/home/felhasznalo/Virtualhosts/%0/" van, így az enoldalam.hu.loc domain az /home/felhasznalo/Virtualhosts/enoldalam.hu.loc könyvtárra mutat. Ez sokkal érthetőbb és probléma nélkül lehet aldomain-eket használni.

Nemrég belefutottam abba, hogy nekem is kellett volna aldomain. Bár megoldható volt, de a probléma rámutatott egy logikai hibára, amely miatt javítottam a leírást, a változást itt találod:
http://nevergone.hu/comment/829#comment-829

Ezek után már egyszerűen kezelhetsz szimbólikus linkkel aldomaint, akár multisite-tal is:
ln -s ~/Virtualhosts/enoldalam.hu.loc ~/Virtualhosts/aldomain.enoldalam.hu.loc

Új domaint vezettem be a fejlesztéshez, az eddigi „.loc” helyett „.l” lett beüzemelve. A leírást ennek megfelelően módosítottam, viszont a hozzászólásokhoz nem nyúltam.

Korábban már sikerült beindítani a localhostot a leírás alapján (kösz nevergone!), de most a 12.04 alatt belefutottam az alábbi 500-as hibába:

[warn] [client 127.0.0.1] (104)Connection reset by peer: mod_fcgid: error reading data from FastCGI server
[error] [client 127.0.0.1] Premature end of script headers: teszt.php

Az alábbi módon sikerült csak megoldani:
sudo chmod 551 /var/www/cgi-bin
sudo chmod 551 /var/www/cgi-bin/php-fcgid

A Drush részben az alábbi hibát kapom (ubuntu12.04), szerinted lehet valamit kezdeni vele?

szt@szt-ubuntu12:/var/www$ sudo apt-get install php5-cli
Csomaglisták olvasása… Kész0%
Függőségi fa építése
Állapotinformációk olvasása… Kész
Néhány csomagot nem lehetett telepíteni. Ez azt jelentheti, hogy
egy lehetetlen állapotot kért, vagy ha az unstable disztribúciót
használja, akkor néhány igényelt csomag még nem készült el vagy ki
lett mozdítva az Incoming-ból.
Az alábbi információk segíthetnek megoldani a problémát:

Az alábbi csomagoknak teljesítetlen függőségei vannak:
php5-cli : Függ ettől: php5-common (= 5.3.10-1ubuntu3.5) de csak 5.3.10-1ubuntu3.6 telepíthető
E: A problémák nem javíthatók, sérült csomagokat fogott vissza.

Én leszedném a teljes PHP-t, majd átnézném a csomagforrásokat, majd feltenném újra. Szerintem valami forrás kavar be neked.

Köszönöm, nekem is volt valami ilyesmi gondom, de olyan gyorsan javítottam, hogy elfelejtettem leírni.

Tovább debugolva az ubuntu12.04 localhost beállításokat, a
sudo service dnsmasq restart
parancsra az alábbi hibaüzit kaptam:

* Restarting DNS forwarder and DHCP server dnsmasq
dnsmasq: failed to create listening socket for port 53: A cím már használatban van
[fail]

Megoldást itt találtam: http://sokratisg.net/2012/03/31/ubuntu-precise-12-04-get-rid-of-nms-dnsm...

Azaz:

sudo gedit /etc/NetworkManager/NetworkManager.conf

kikommenteztem a "dns=dnsmasq" sort, mentés, majd:

sudo restart network-manager

Utána már rendben lefutott a cucc:

sudo service dnsmasq restart

És a ping is rendben volt:

ping foobar.loc

Az „IPCConnectTimeout” értékét a kezdeti 300-ról 7200-re módosítottam a /etc/apache2/mods-available/fcgid.conf fájlban, ugyanis a 300-as értéktől az Xdebug öt perc után megszakotta a PHP process futását és ezzel a hibakeresési folyamatot, ami egy összetett folyamat megfigyelésekor elég kellemetlen volt. A 7200-as érték másodpercben számolva egy órás futási limitet jelent.

Új hozzászólás