What’s the point of being able to create new DH users under the one DH account? What is the benefit? I understand that each user (assuming your account uses a shared server) gets their own home folder. But the contents of a domain you have registered and/or hosted with DH resides in only one user’s home folder. Or if I have multiple domains hosted with DH, can each domain’s contents be stored in the home folders of different users? And what would be the pros and cons to storing the content of multiple domains under different user folders versus creating multiple sub-folders under the one user to store the content of different domains? Basically, why have the ability to create different DH users under the same DH account?
you can give someone access to their own private domain without them being able to see or change anything in other domains on the same account. Try read the Wiki, that is what it is there for
There may also be security and performance benefits to each domain having its own user.
I read the wiki, so now I understand more about the different types of users. So here is what I’m faced with:
I manage one domain for a church. We use Joomla, and it is installed on one FTP/SSH User we created. We are still in the process of building the site, but I foresee in the future the need for some of the various teams in the church to be able to upload files to the server that the site is stored on.
For example, the AV Team will need to upload mp3s of sermons and then add them to a page on the site. Now I know that Joomla itself provides the ability to upload media, and of course it would store said media in a subdirectory under the main Joomla installation directory. But I was hoping to enable the AV Team to upload the unedited sermons - in perhaps wav format - to the server. This way we (1) have a copy of the raw sermon, and (2) anybody on the AV Team can download unedited sermons and clean them up when they have time.
In this scenario I was thinking of creating a separate FTP/SSH user for the AV Team, to allow them to save raw copies of the sermons. I could then go in and copy the edited mp3 to the Joomla folder. But I suppose the problem with that is I would need to copy a file from one FTP user’s home to another FTP user’s home. The problem though with giving out the login info for the FTP user whose directory contains the Joomla installation is that potentially a lot of people might be given the info, and that’s not safe or secure.
So any suggestions for what I can do?
It’s been a long time ago, but I was part of a team that set something like this up back in 2002. This wasn’t done on dreamhost at the time, but i believe you should be able to set it up here. Others may have another approach based on tools we didn’t have back then.
We set up a user for the media team to use as both working storage and as the gateway to publication. When the team was ready to publish a file they created a 3 line text file with a specific format, all 3 lines were quoted text strings. line 1 was the filename of the media “example.mpg”, line 2 was the title “candidates speech at some event on 1/1/2002”, line 3 was a longer description enclosed in quotes. Then they moved both the media file and the text file to a specific “/publish” directory on this user.
As I recall this user had a cron job that ran at :28 and :58 to set the group and file permissions of every file that existed in /publish
There was a second cron job that ran at :30 and :00 from the user associated with the website. That script:
captured a listing of files ending in .txt on the other users /publish directory
Did basic validity checking on the contents of any .txt file found, that it contained 3 lines only, that the file named on line 1 was available in /publish also, etc
It performed some basic checks/test on the media file to ensure it was playable and not corrupt.
if any test failed it renamed the files .rejected and left them in the /publish directory
If the basic checks succeed it moved and renamed the media files to the website user, changed the file owner, changed the file group and set the permissions of the media file.
updated the database with the file name, title and description.
copied detailed information to a .log file on both users and emailed errors
 later functionality replace and delete a file as well as just publish, but i dropped off the (unpaid) team before that happaned.
[*] later functionality was added that created a publish now functionality when a user created an empty file called publish.now in the /publish directory.
There are a few thoughts on at one approach.
Interesting approach, and thanks for the suggestion. I’ll look into what you outlined. I must confess though that my UNIX administration abilities are fairly basic; I’m not sure how to get a cron job to perform the checks you mentioned, at least on the media files. But for now I can implement a mix of checks involving the AV team and the cron jobs. So in this case I will go ahead and create a new FTP user for the AV team.
I suppose another option (which I’ll Google later) is creating a sub-directory under the main FTP user’s home directory, and then seeing if I can create a new FTP user that will only have access to that sub-directory - akin to making that sub-directory the new user’s home. I suppose this is similar in concept to chroot.
Since it’s a church you might ask the membership if anyone has unix/bash scripting skills and an advanced understanding of permissions, users and groups.
I think the checks on the media file consisted of a few checks concerning file length and marks in the file, as well as checking the internal and external file types matched, followed by a virus scan, followed by playing it in a player with output piped to /dev/null and watching for the exit code of the player. There maybe better tools to achieve these steps today (remember i worked on this in 2002).
Once your custom script is written and debugged it’s a simple matter to have cron start it at specific intervals.