FollowSymlinks σε cgi-bin directory στον Apache

George Notaras gnot at g-loaded.eu
Mon Apr 27 14:36:59 EEST 2009


Alexandros Kosiaris wrote:
>> Το πακέτο awstats του fedora κάνει ένα central setup, δηλαδή, όλα τα
>> configurations στο /etc/awstats/, όλα τα databases στο
>> /var/lib/awstats/, το processing γίνεται με το awstats_updateall.pl κτλ.
>> Το μόνο στραβό είναι ότι για να τρέξει κανείς το awstats.pl ως cgi
>> script, θα πρέπει να έχει το awstats.pl και το configuration αρχείο στο
>> cgi-bin directory. Οπότε είναι απαραίτητο είτε να χρησιμοποιηθούν
>> symlinks ή να μεταφέρονται τα αρχείο αυτά από το κεντρικό installation
>> στο cgi-bin του κάθε χρήστη κάθε φορά που γίνεται αναβάθμιση του πακέτου
>> awstats ή που γίνονται αλλαγές στο configuration αρχείο για κάποιο vhost.
> 
> Με μπέρδεψες λιγάκι. Τα configurations είναι το /etc/awstats αλλά πρέπει
> να βρίσκεται το configuration στο cgi-bin directory ? Κάτι δεν λες καλά
> εδώ...

Η αλήθεια είναι ότι τα 'γραψα λίγο χύμα. :)
Τα configurations βρίσκονται στο /etc/awstats, ώστε κάνοντας χρήση του
script awstats_updateall.pl να ενημερώνονται τα awstats databases για
όλα τα sites.

Όμως, το awstats.pl τρέχει ως cgi script ως εξής:

  http://www.example.org/awstats/awstats.pl
ή
  http://www.example.org/awstats/awstats.pl?config=www.example.org

Και στις δύο περιπτώσεις το awstats.pl ψάχνει το configuration αρχείο
awstats.www.example.org.conf στον κατάλογο από τον οποίο τρέχει. Δεν
μπορεί να ρυθμιστεί (ή τουλάχιστον εγώ δεν ξέρω πως θα γίνει αυτό χωρίς
να πειραχτεί ο κώδικας) να ψάχνει τα configs στο /etc/awstats/.

Οπότε, είναι αναγκαίο σε κάθε script aliased directory από το οποίο θα
τρέχει το awstats.pl, να υπάρχουν δύο symlinks:

  cd /home/user1/www.example.org/awstats/
  ln -s /usr/share/awstats/wwwroot/cgi-bin/awstats.pl awstats.pl
  ln -s /etc/awstats/awstats.www.example.org.conf \
    awstats.www.example.org.conf

Ελπίζω τώρα να είναι λίγο πιο ξεκάθαρο πού αντιμετωπίζω πρόβλημα γιατί
είναι μάλλον απαραίτητο να υπάρχουν τα παραπάνω symlinks μέσα στο
script-aliased directory.

> Από εκεί και πέρα το να μετακινούνται(ή κοπιάρονται) τα αρχεία είναι
> εντομάκι που περιμένει να σε δαγκώσει. Και τα symlinks εκτός εάν
> φτιάξεις σταθερή διαδικασία που θα την τηρείς ευλαβικά κάποια φορά θα τα
> ξεχάσεις.

Γενικά για τα περισσότερα administration tasks φτιάχνω κάποιο script για
να κανει τις αλλαγές αμεσα σε όλα τα vhosts ή σε καθένα ξεχωριστά, οπότε
αυτο πιθανότατα δε θα είναι πρόβλημα.

> Μπορείς να κάνεις μία παρασπονδία όμως φτιάχνοντας πχ ένα
> ειδικό cgi directory που θα περιέχει μόνο το awstats και θα είναι shared
> μεταξύ των vhosts.Πχ
> 
> Εκτός των vhost declarations
> 
> Alias /awstats "/usr/local/www/awstats/cgi-bin/"
> <Location /awstats>
>     AddHandler cgi-script .pl
>     Options +ExecCGI
>     DirectoryIndex awstats.pl
> </Location>
> 
> <Directory "/usr/local/www/awstats/">
>     Options None
>     AllowOverride None
>     Order allow,deny
>     Allow from all
> </Directory>

Το παραπάνω προϋποθέτει ότι όλα τα awstats configurations θα βρίσκονται
στο /usr/local/www/awstats/cgi-bin/ ? Αυτό είναι πολύ καλή ιδέα, αλλά θα
πρέπει ίσως να βρεθεί και κάποιος τρόπος ώστε να μην μπορεί ο ένας
χρήστης να βλέπει τα στατιστικά του άλλου.

>>> Κακώς ο apache σου εκτελεί όλα τα php scripts ανεξαρτήτως virtualhost.
>>> Είτε με το mod_php είτε μέσω CGI μπορείς να αποφασίσεις ποια
>>> virtualhosts θα έχουν η όχι δυνατότητα να έχουν PHP
>> Πάλι όμως, θεωρητικά τουλάχιστον, δύο χρήστες, των οποίων τα
>> virtualhosts υποστηρίζουν php scripts, δε θα μπορούν να βλέπουν ο ένας
>> το περιεχόμενο των αρχείων του άλλου;
> Ναι έχεις δίκιο. Αλλά μπορείς να βάζεις ένα
> 
> php_admin_value open_basedir "/path/to/vhost:/path/to/shared/dirs/:ktl"

Αυτό δε θα το 'βρισκα ούτε σε χίλια χρόνια. Thanks

> Στο definition του VirtualHost.Tρελό scaling δεν κάνει προφανώς κάτι
> τέτοιο αλλά εάν δεν έχεις να προσθαφαιρείς 20 vhosts την ημέρα είναι οκ.
> 
>> Πάντως. τώρα που χρησιμοποιώ το mod_fcgid δεν εκτελεί παντού php
>> scripts. (γραφω το config παρακάτω)
>>
>>> Παραδείγματος χάρη εγώ χρησιμοποιώντας mod_cgid(και όχι mod_fcgid γιατί
>>> απλά δεν ασχολήθηκα ποτέ να το στήσω) έχω ANA Directory ANA VirtualHost
>>> που με ενδιαφέρει το απλό(και OXI μέσα στο κεντρικό configuration σε
>>> κάνα <Directory /> directive)
>>>
>>> <VirtualHost TADE>
>>> <Directory DEINA>
>>> 	Action php4-script /cgi-bin/php4
>>> 	AddHandler php4-script .php
>>> </Directory>
>>> </VirtualHost>
>>>
>>> Προφανώς πολύ εύκολα κάνεις το ίδιο με mod_php
>>> 	AddType application/x-httpd-php .php
>>>         AddType application/x-httpd-php-source .phps
>>>
>>> Το /cgi-bin είναι ένα κοινό script-alias για όλα τα virtualhosts. Εκεί
>>> μέσα υπάρχει μόνο το php4 cgi και τίποτε άλλο(και εάν δεν έχεις root στο
>>> μηχάνημα δεν μπαίνει και τίποτε άλλο εκεί)
>> Το mod_cgid τρέχει την php ως FastCGI ή ως απλό CGI script; (δεν ξέρω κι
>> αν χρησιμοποιώ σωστά τους όρους) Δηλαδή, όταν εκτελείται ένα php script,
>> ο apache δημιουργεί ένα process της php, το οποίο εξυπηρετεί περισσότερα
>> του ενός http requests?
> 
> To mod_cgid κάνει ένα από τα apache children να ανοίγει ένα socket στο
> filesystem και να περιμένει connections από τα υπόλοιπα με τα cgis που
> θέλουν να εκτελεστούν. Μετά κάνει εκείνο spawn τα processes. Ο λόγος που
> γίνεται αυτό είναι γιατί εάν έχεις multi-threaded server όταν γίνεται
> fork ένα καινούριο process τότε κοπιάρονται και τα threads. Οπότε δεν
> εξυπηρετεί περισσότερα requests αλλά μειώνει το κόστος του να φτιάχνεις
> παιδιά.
> Δεν είναι χρήσιμο εκτός εάν έχεις multi-threaded server αλλά από τα
> πράγματα μάλλον θα έχεις κέρδος εάν ενεργοποιήσεις το multi threaded
> server σε σύστημα με πολλά vhosts. Αλλά δεν είναι το ίδιο με το FastCGI.

Thanks. Δεν το είχα υπόψη μου.

>> Το mod_fcgid το χρησιμοποιώ χονδρικά όπως παρακάτω. Έχω δει κάποια πολύ
>> μυστήρια setups, αλλά αυτό είναι πιστεύω το πιο απλό που μπορεί να κάνει
>> κανείς.
>>
>> Στον main server:
>>
>>   LoadModule fcgid_module modules/mod_fcgid.so
>>   AddHandler fcgid-script .php
>>   FCGIWrapper /usr/bin/php-cgi .php
>>
>> Και σε κάποιο directoryA σε κάποιο virtualhostA, το μόνο που κάνω είναι
>> να προσθέτω το option ExecCGI. Πχ
>>
>>   <Virtualhost A>
>>     <Directory /path/to/Α>
>>       Options +ExecCGI
>>     </Directory>
>>   </Virtualhost>
>>
>> Πιθανότατα το 'FCGIWrapper /usr/bin/php-cgi .php' να είναι πολύ πιο
>> σωστό να μπει μέσα στο <Directory> όπου θα εκτελούνται τα php scripts.
> 
> Ε το τυπικό setup έχεις. Εντάξει αυτό για το directory ισχύει αλλά οκ,
> εύκολα φτιάχνεται.
> 
>>>> Τρέχω την php ως fastcgi μέσω του mod_fcgid. Αν χρησιμοποιούσα το
>>>> mod_php θα μπορούσα να κάνω χρήση του παραπάνω directive (SuexecUserGroup)?
>>> Τσου. Το mod_php σημαίνει ότι ο κώδικας εκτελείται από τον apache και
>>> άρα δεν έχει νόημα το suexec μία και είναι μόνο για CGI. Για mod_php
>>> χρησιμοποιείς open_basedir και παλιότερα έβαζες και safe_mode αλλά είναι
>>> πλέον deprecated και δεν σου προτείνω να το χρησιμοποιήσεις.
>> Μάλιστα. Δεν έχω σκοπό να χρησιμοποιήσω ξανά το mod_php. Ένας επιπλέον
>> λόγος είναι ότι με το mod_fcgid μπορώ πλέον να χρησιμοποιήσω το threaded
>> MPM του apache.
> 
> E πρακτικά αυτό, το performance και η δυνατότητα να έχεις ταυτόχρονα
> πολλές διαφορετικές εκδόσεις php στον ίδιο server είναι οι λόγοι να
> έχεις threaded MPM. Μόνο πρόβλημα εάν θυμάμαι καλά είναι ότι δεν
> δουλεύουν μετά τα persistent connections προς βάσεις δεδομένων.

Κυρίως για την απόδοση με ενδιέφερε η χρήση του threaded mpm. Με τις
ρυθμίσεις του apache και το hardware που έχω (pentium2 350mhz με 512ΜΒ
RAM) νομίζω πως έχει πραγματική διαφορά (σε σχέση με το prefork mpm) στο
πώς φορτώνεται μια σελίδα με πολλά αντικείμενα (πχ images, css,
javascript), τα οποία προκαλούν επιπλέον http requests sto server,
παρόλο που γινόταν χρήση του 'keepalive' feature. Εκτός κι αν οι
ρυθμίσεις μου για το προηγούμενο setup (prefork mpm) ήταν τόσο κακές.

Πάντως, ενώ περίμενα να δω και βελτίωση στην κατανάλωση μνήμης,
εντούτοις, ο apache αν "δει" μνήμη ελεύθερη, δεν θα την αφήσει, όποιο
mpm κι αν χρησιμοποιείται.


ΥΓ: Λυπάμαι για το πολύ quoted text.




More information about the Linux-greek-users mailing list