WordPress Install Script Incomplete (nginx)

Bug #800386 reported by Brian Chabot
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Easy Hosting Control Panel for Ubuntu
Invalid
Wishlist
Unassigned

Bug Description

I'm using EHCP 0.29.15.4 on Ubuntu 10.04.2 LTS VPS (OpenVZ).
Set up EHCP - no errors.
Changed EHCP to use nginx - no errors
Added domain - no errors.
Ran install script for WordPress - No errors reported.

So here's the issue:
1. No db is created. (Feature Request) A complete installation which creates a db (with associated user/pass) and writes the wp-config.php would be necessary to complete installation. (Also requires a few user prompts).
2. When a db is manually created and wp-config.php is ready to be saved, it seems nginx does NOT have write permission to save it by default. This may be an issue with how EHCP controls user directories or how nginx is configured. Either way, nginx can't write to the user directories and it really needs to for many applications such as WordPress.
3. The default nginx configuration needs modification to work with WordPress permalink structure. EHCP does not offer anything like that. See:
http://wiki.nginx.org/Wordpress
http://codex.wordpress.org/Nginx

I'm guessing other installable scripts also have these issues. Is there any way to address this so the install links just work?

Revision history for this message
Brian Chabot (bchabot) wrote :

A temporary fix for the permissions is to chown -R the httpdocs directory to www-data. This could be less secure than a suexec equivalent.

Revision history for this message
Brian Chabot (bchabot) wrote :

Another possible fix to the permissions issue is found here:
http://wiki.nginx.org/Faq

-----------------------------------------------
What about support for something like mod_suexec?

mod_suexec is a solution to a problem that Nginx does not have. When running servers such as Apache, each instance consumes a significant amount of RAM, so it becomes important to only have a monolithic instance that handles all one's needs. With Nginx, the memory and CPU utilization is so low that running dozens of instances of it is not an issue.

A comparable Nginx setup to Apache + mod_suexec is to run a separate instance of Nginx as the CGI script user (i.e. the user that would have been specified as suexec user under Apache), and then proxy to that from the main Nginx instance.

Alternatively, PHP could simply be executed through FastCGI, which itself would be running under a CGI script user account. (Note that mod_php - the module suexec is normally utilized to defend against - does not exist with Nginx.)
-------------------------------------------------

Support for a choice of allowing nginx to run as the user would really be awesome.

Revision history for this message
Brian Chabot (bchabot) wrote :

Possible cause:
line 181 of classapp.php

Currently:
$wwwowner="vsftpd:nogroup";

....obviously wwwowner is www-data.www-data not vsftpd:nogroup

...or do the files have to be owned by vsftpd in order for ftp to function?

Revision history for this message
Brian Chabot (bchabot) wrote :

...further...

Replace vsftpd with $wwwowner throughout classapp.php where ownership is concerned and set the www-data as the owner of the vsftpd process in /etc/vsftpd.config

Revision history for this message
ehcpdeveloper (ehcpdeveloper) wrote : Re: [Bug 800386] Re: WordPress Install Script Incomplete (nginx)

very nice suggestions,
* permission has been an issue for a long time...
* script/program installation is mostly a matter of coding.. many
things possible.
I will try to sum them all, together..

Revision history for this message
ehcpdeveloper (ehcpdeveloper) wrote :

yes, the owner of files, should be the owner of vsftpd process. your
suggestion seems a solution. will check that.
as you find line 181 of classapp.php, you are an experienced
programmer, so, your contribution and suggestions are important.
most things are done in classapp.php , in ehcp.

Revision history for this message
Brian Chabot (bchabot) wrote :

Thanks! I'm only kind of a programmer. I'm more of a sysadmin who needs to be able to fix things. :)

The short answer is I just got hired by a new start-up company and EHCP is our best solution for virtual hosting because of many factors (templates, script installs, and nginx)

The places that need to be changed in classapp.php are also:

Line 6397:
passthru2("chown vsftpd $homedir ");

Change to (I think):
passthru2("chown -R $wwwuser $homedir ");

and

Line 8513:
passthru2("chown vsftpd -Rf ".$dom['homedir']."/httpdocs");

Change to:
passthru2("chown $wwwuser -Rf ".$dom['homedir']."/httpdocs");

Revision history for this message
ehcpdeveloper (ehcpdeveloper) wrote :

Your suggestions are absolutely true.
all chmod commands should use $wwwuser variable
I want to state that: not all code is perfect in ehcp yet, (maybe
nothing is perfect, another point of discussion)
so, you may find some points that needs editing, I am completely open
to suggestions.

since you got the point, I can say this about Easy Install Scripts:

ehcp's function about those: instead of manually downloading them, and
uploading to server,

ehcp does: download using wget, extracts, puts in target dir, executes
some preliminary commands.
all things done using scripts table ,
fields of that table, that needs explanation for you and similar programmers:
filetype: identifies if fileinfo is a url or something else, currently
constant of "directurl" this field is used in code,
fileinfo: url of file to download, for ex, http://blah.com/this.tgz
scriptdirtocopy: some downloads have a directory structure inside it.
for ex, doc, upload; this field id the "directory" that contents
should be put in target dir of user's choice. for ex, "upload" in
some cases.
for new/changed downloads: this is identified by manually extracting
the file and examining contents, once..

commandsaftercopy: these are commands that should be executed on
target files, such as chmod, config file creation etc... as you asked
in your first posts.. this is an important place..

Revision history for this message
ehcpdeveloper (ehcpdeveloper) wrote :

ehcp version 0.30 on the way,
wwwuser is vsftpd:www-data by default; I mean, it is fixed.

apache-nginx switchover is more smooth, even with custom http.

about easy install scripts:
ehcp does NOT install all scripts automatically, and does all needed actions.
ehcp does this:
* download that script for you, (if not done already), thus, eliminating many ftp transfers..
* extracts the script to some folder,
* runs some additional "command line commands" after "file extraction". So, if something can be done in "console commands", we can write all in there.. however, if a script/program installation requires some, for example, "web based actions", ehcp does not do that automatically (at least yet.. ), so, you should do those web-based actions yourself. such as, joomla's web install and so on..

see you

Revision history for this message
Salman (salman-chohan) wrote :

VSFTPD:WWW-DATA

This doesnot gives any problem in modify files , delete or upload. Owner goes to 5001/33. Site is working perfectly fine.

Their are few thing i have noticed is that suppose for a saving a page generated a file on server, this newly generated file has permission www-data:www-data This file is deletable but we cannot modify or change its permission.

Another permission error occured due to majority website didnot set their ftp accounts, such as in joomla, their is FTP details and path need to be set in configuration, if you donot set , and tries to upload some new component , it will execute it as root ownership which is unmodifiable and undeletable.

FTP Server or IP within script is mostly 127.0.0.1 just like you use it too connect to NET2FTP

Changed in ehcp:
status: New → Invalid
importance: Undecided → Wishlist
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Related blueprints

Remote bug watches

Bug watches keep track of this bug in other bug trackers.