- Nem ismertem 7 év 10 hónap
- Van itt még néhány feldolgozás 7 év 10 hónap
- Nekem így néz ki a "mariadb 8 év 3 hónap
- jegyzet 8 év 10 hónap
- Köszönet! 8 év 10 hónap
- FYI: PuTTY telepített 9 év 7 hónap
- InnoDB - file per table 10 év 3 hónap
- Great post! 10 év 4 hónap
- Az „IPCConnectTimeout” 10 év 6 hónap
- Saját domain beállítása 10 év 6 hónap
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
AddHandler
Ü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
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ő,
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?
www-data
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.
apache saját user nevében
"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
valóban
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
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
"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
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öszi
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
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?
beállítás?
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?
A /etc/apache2/mods-available
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
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
Adj futási jogot
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
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á...
kiírtanii a PHP processzeket
É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
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:
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...
aldomain
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.
közvetlen
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!
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
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.
virtuális hálózati kapcsolat
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.
error.log
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.
kis logikai probléma
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.szimbólikus link
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 domain a fejlesztéshez
FastCGI fájl/könyvtár jogok
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:
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
Drush probléma
A Drush részben az alábbi hibát kapom (ubuntu12.04), szerinted lehet valamit kezdeni vele?
csomagok
Köszönöm
Saját domain beállítása
Tovább debugolva az ubuntu12.04 localhost beállításokat, a
sudo service dnsmasq restart
parancsra az alábbi hibaüzit kaptam:
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”