yum install drupal命令通过资源库下载安装
To be compliant with FHS guidelines on architecture independent system components (http://www.pathname.com/fhs/pub/fhs-2.3.html#THEUSRHIERARCHY) vs transient data placement (http://www.pathname.com/fhs/pub/fhs-2.3.html#THEVARHIERARCHY) and to enforce Fedora-ish system segregation Fedora and its derivatives place the code part of systems like Drupal and WikiMedia in /usr/share and the data elements (like files/ and images/) in /var/www. These parts are bound together through a series of symlinks, as the original development concept behind Drupal and other such systems did not take the FHS into account (there is a pretty big generation/culture gap between core Unix developers and web developers -- and embedding code to this extent inside of what used to be public data files (.html files becoming .php files and totally bypassing cgi-bin) was never thought of when the FHS was originally conceived). This can be confusing for newcomers.
In either case, the placement of the Drupal code (all those .php files) within the filesystem is irrelevant to the function of SELinux. Apache's daemon, httpd, has a context group within the Fedora SELinux policy structure. Any files or directories that Apache needs to interact with must be placed within an httpd_* type context. Yum will handle this for you if you do a
yum install drupalinstall and the stickiness of the /var/www filesystem hierarchy will do it for you if you unpack it directly into a sub-directory there. However, installation cases outside of this where SELinux is set to enforce but the default SELinux policies are either grossly underdeveloped (Ubuntu, for example) or nonexistant (Slackware / LFS + SELinux -- yes, some people do this) will have to make the change on their own:
chcon -R -t httpd_sys_content_t /path/to/drupal/files
The other area where SELinux can trip one up is basic policy permissions for allowing Apache to do things like send email (to prevent compromised systems from becoming proxy spam-generators -- a problem far more common than most Ubuntu new administrators seem to be aware), make calls across network sockets to database servers (a wonderful way to bypass password protections and steal user data from a site), or directly alter files on behalf of scripts (an entry to the first two). To enable this small list of abilities but keep your system otherwise locked down with an SELinux policy set to "enforce" run the following three commands:
# setsebool -P httpd_can_network_connect_db=1 # setsebool -P httpd_can_sendmail=1 # setsebool -P httpd_unified=1
Unfortunately, in an excited rush to get things up quickly most people who opt for the increased security that SELinux provides by choosing a Fedora-based distro usually toss all their gains at the first sign of SELinux conflicts by turning SELinux off instead of digging further (because learning 4 more file security attributes is hard -- and admittedly, SELinux is rarely explained so simply in currently available resources). Outside of granting Apache permission to do things Drupal needs to work correctly (those three setsebool commands) and then telling SELinux where these permissions should apply (the chcon command above), the installation process is no different from any other system. It is useful to remember if you run into an FHS-compliant installation where /var/www/html/drupalxx is largely empty but for a few symlinks and data folders (like config/) that all of the code is over in /usr/share and conceptually nothing has really changed. tl;dr reference: http://zxq9.com/archives/442