To add a chrooted FTP user outside of Plesk properly, you need to:
Create the user with the home directory as the root of what they can access
Give the user a password
Make their primary group psacln
Add them to the psaserv group as well
# useradd username -d /var/www/html/website/slideshow/
# passwd username
Enter new password for username
# usermod -g psacln username
# usermod -G psaserv username
You also need to chmod the directory in question to 775
That’s it.
At WebSight Design we try to remain technology-agnostic. (The right tool or language for the job.) Having said that, we are primarily a PHP shop. However, with the launch of the Google App Engine, we’ve been looking seriously at Python. In recent years, I have become a big fan of development frameworks so to aide me in learning the ways of the snake, I have been using the Django framework.
Getting it all setup wasn’t difficult. The Django installation is very easy. I started to get errors when I was trying to get my models working when I ran
. Come to find out that I needed the MySQL-Python library installed to work correctly on my OSX Leopard machine. Most everything that I illustrate below is to be executed from the command-line. So if you are not familiar with working in the Terminal app, this post is gonna suck for you. So here is what I did to get it working:
First, download MySQL for Python
http://sourceforge.net/projects/mysql-python
for me it was MySQL-python-1.2.2.tar
Unpack it:
Change to the directory that is created:
Next, locate your “mysql_conf” file.
Copy the location of this file so you can use it in the next few steps.
Next, you need to edit the “site.cfg” file and add the path to your “mysql_conf” file.
Also, (very important), change the line that reads:
TO
Save and exit the file.
Now, compile and install the library:
NOTE: You may need to run “python setup.py clean” if you previously tried to build and install the library.
Next is the *really* important part. After I kept getting errors trying to run the Python server I found the missing piece on the ProjectMouse.org site.
The key is, you need to create a symbolic link in the location that Python is expecting to find MySQL. This should be a link to the MySQL library that your computer is setup to use.
See here:
NOTE: “mysql-5.0.41-osx10.4-i686″ is where MySQL is installed on my machine. Change this to the location specific to your computer.
Finally, import MySQLdb into Python and test your configuration:
NOTE: You should not see any errors or warnings. Hit “Ctrl+d” to exit the interepter.
Now go back and run
again and you should not get any errors.
As you may have found out, a web server that houses a bunch of web sites can cause some issues with file permissions when it comes to allowing PHP to write files that a web site needs, whether it is a data file, a document or an image. This is usually not an issue if PHP is installed as a cgi module because cgi programs are usually setup to run as the user that owns them, but Plesk uses PHP installed as an Apache module, and thus it runs as the same user that Apache runs as, which is usually not the same user that owns the website files.
How to solve this? It is really easy actually. There are 2 possible solutions, the first is the easiest, but really shouldn’t be considered and that is to make the folders that PHP needs to write to 0777, which opens a possible security hole and that is why you shouldn’t really consider it.
The second is to simply add the user apache uses, which under Plesk is usually “apache” to the group “psacln”. You can edit the /etc/group and /etc/group- files if you know what you are doing, or use usermod.
If you want to edit the files directly, locate the line that looks like this:
psacln:x:2524:
and just tack on “apache” to the end of it like so…
psacln:x:2524:apache
Do this for both files and restart apache and you are done.
Or, simpler
/usr/sbin/usermod -a -G psacln apache
Then simply make the folders and/or files that php needs access to 0775, which makes it more secure.
You can do similar with any server enviroment, we just happen to use Plesk here.
Rob
My company: WebSight Design, uses Subversion for source and version control for all of our web development projects. We also use the amazing hosted Subversion service: Springloops. (If you ever need a Subversion deployment tool, Springloops is it!) Springloops repositories are *only* accessible via HTTPS. In order to gain access to a repository from the command line, I had to re-configure Subversion on our servers to enable access to ssl urls. Seems simple enough and actually it is. However, as with all things Linux, the devil is in the details. I spent hours-upon-hours trying to get it to work. It simply comes down to the sequence of steps you take. What I’ve done here is list out all of the steps done to get it working to save you from the same pain I went through.
So, I am assuming that you are trying to access a Subversion repository via an https url and you are getting the message “ssl not supported” or something similar to this. I know, it sucks and it’s pretty frustrating. I promise you however, if you do *exactly* what I spell out below, in the sequence I list… you will be up and working in about 15-20mins. The only other assumption here is that you are using Ubuntu or some other Debian-based Linux distro that supports the APT package manager.
It’s important to know that Subversion uses a module called Neon to provide ssl connectivity. The key here is to use the version of Neon for your specific release of Subversion. This is key to everything else that follows. Don’t just grab the latest versions of Subversion and Neon and assume they will work correctly together. So with that… let’s get to work.
First, make sure the following packages are installed on your server:
GCC
Expat
Libxml-dev
Next, download latest Subversion files:
NOTE: “X” above is a placeholder for your version no.
Untar em’ in this order:
Once you have extracted the files, open the file ”
“. Locate the section on Neon. It will state which version you need to download and compile with this version of Subversion.
Make sure you are *not* in the Subversion directory you just created. Then go ahead and download Neon:
NOTE: The “X” above is placeholder for the version of Neon you need.
Next, extract the archive:
Now is where the fun begins. You need to compile and install Neon. Do the following from *within* the Neon directory you created:
It’s important to note that Neon gets installed to /usr/local by default. You need to note that as you will now need it when compiling and installing Subversion.
Change back to the Subversion folder:
Compile and install Subversion:
Now, realize that the Subversion compilation and installation process takes a long time to complete. So just be patient. You can ignore any warning messages that scroll by. You only need to be concerned with error messages or if the installation stops for any reason.
Once compilation and installation are complete you need to confirm that you are running the version of Subversion you just tried to install:
If you get *anything* other than the version number you thought you installed, something went horribly wrong. Go back to the very beginning of this and try again. Most time folks get errors it is because that don’t have the prerequisite tools and utilities installed. If you see the version you wanted… you’re all good!
