Users issues


#1

Not sure what happened this time, but I’ve contacted support and their answer didn’t seem get what I was asking. Rather than replying and waiting over 24hrs, again, I’m posting here.

Ok, so I created the user newUser. Then I created the subdomain lpnw.domain.com and set it to run as the user newUser, in the directory /home/me/lpnw.domain.com (I’ve done this a few times before, maybe I messed it up this time?)
When I FTP in as newUser, I’m not sure where my files end up (/home/newUser?). When I FTP in as me, I can get into lpnw.domain.com and see the files. I FTP into lpnw.domain.com as newUser, don’t actually end up there. The web panel shows: Home Directory: /home/newUser

I don’t remember setting it up this way (I always put my stuff in /home/me, I suppose I could have made a mistake.)

Since I can’t edit newUser’s home directory, I tried to delete it but get a message stating it’s tied to lpnw.domain.com. When I look at that domain, its root is /home/me/lpnw.domain.com…

This is not making sense to me. I want newUser’s home directory /home/me/lpnw.domain.com - How can I do this?


so that’s basically what I sent to support. I realize something went wrong somewhere along the way, so I would just delete the user and domain and start over, if I could. The part that gets me is that if I FTP into lpnw.domain.com I end up in /home/newuser/. When I view the site, lpnw.domain.com is at /home/me/lpnw.domain.com/. When I try to delete the newUser, I get the message it can’t be deleted because it is being utilized by lpnw.domain.com service: http. But that’s not the case because http for it is in /home/me/lpnw.domain.com

I think the key to the reason it didn’t work this time is
Tech support: You can no longer specify a users home
directoy. Home directories are now assigned, /home/username.

What I want is a directory inside my main directory, which is only accessible to that user name (newUser), but since it’s inside the main directory, my main user (me) can access it. (This is where my lack of *nix permissions gets the better of me)

am I making sense at all? I might have to try that callback option which I haven’t used it…


#2

Well like support said, the web panel no longer allows you to put a user home directory as a subdirectory of another user. In other words,

/home/first_user/second_user/some.domain.com

is not possible.

What you ended up with is:

/home/first_user/some.domain.com

/home/second_user

I don’t know why this change was made. However to do what you want, I feel its best to just put the domain in second_user’s home directory and just login as second_user.

I believe you mispoke there. You would not want a users home directory to be used for HTTP DocumentRoot. You want a subdirectory of his to be used for HTTP DocumentRoot instead. A user home directory is used for a lot more than web files and it is not a good idea to make it available through the web.

:cool: Perl / MySQL / HTML CSS


#3

good point on the root directory stuff. I have multiple people logging in for access on this stuff, now it seems I’ll have to give different instructions based on when the domain was created.

Right now, I have users’s roots setup like /home/me/client.domain.com/user’s root

All I want is so if a user FTPs into the site, they only get the site root, but if I FTP in, I have direct access to all site roots. Can you think of any way of doing that? I guess the user’s root can be elsewhere, I don’t care, I just want their FTP to be a specific place.

thanks.


#4

This can’t be done using the setup DreamHost provides. You do not get a “file manager” FTP user that is somehow more powerful than your other FTP users. Techically you don’t have a “main” directory either. Might want to check into WebDAV if it suits you.

A single user owns a file or directory. In addition to his own set of permissions, the owner gets to grant separate sets of permissions to members of his group and the public. In addition, applications, such as FTP or Web servers, may apply their own model on top - for example DreamHost’s web servers will not execute CGI files if group/public write permission is enabled. A directory is treated like a file but it is special because it is a list of files, and permissions on a directory have to do with handling this list of files.

If you try to “manage” files using more than one user, you then have to worry about ownership and permissions, which may be fustrating if you don’t keep them straight. For example, if you make a file as user A, then user B won’t be able to edit it if you don’t ensure you set the permissions correctly (since that is the job of user A).

That’s why I suggest not even trying to do that. Using the web panel, you can always get the login details of a user and login as that user. This will avoid ownership issues when “managing” the files.

Well that has to do with the filesystem. Now on to FTP…

FTP is a program and it can be configured to do things certain ways. One of them is that for regular FTP, the “root” that the user sees in his FTP client is not actually the root of the filesystem. The FTP client is tricked into thinking the user can only access his own home directory. This is not always the case though (SFTP for sure) and one should not be alarmed if they login and can traverse outside of their home directory. It’s just annoying when you click on the “Move up directory” too many times =)

:cool: Perl / MySQL / HTML+CSS


#5

I realize I’m using my terminology a little loosely. I also know when I use the word “root” I’m thinking of it less in *nix terms but share points of http and ftp

[quote]If you try to “manage” files using more than one user, you then have to worry about ownership and permissions, which may be fustrating if you don’t keep them straight. For example, if you make a file as user A, then user B won’t be able to edit it if you don’t ensure you set the permissions correctly (since that is the job of user A).
[/quote]
That’s what I’ve been doing for several years on DH, longer on other web servers. I wish I could find some way to keep doing what I’ve been doing. You mentioned WebDAV as well, but then the server owns everything so users can’t FTP in and edit those files.

Looks like me using the same process as the last several years messed it up for me this time. Now I’ve got a web site’s root which is different than that site’s FTP root - but I can’t delete the user because the web panel says a web site’s root is in its directory - but its not. I guess I have to delete the web site as well?


#6

I would contact support to have them fix this, they might be able to do it without you having to wait for changes made using web panel to be completed. I’m not even sure the web panel is able to cope in the situation that you make a user home directory the same as HTTP DocumentRoot for a domain and wish to undo that. I tried that once long ago when I first saw the idea here myself and couldn’t undo it and had to get support to undo it.

Perhaps thats a reason why they would stop allowing customers to specify the location of user home directory. I imagine you and I aren’t the only ones who tried to make a home directory be HTTP DocumentRoot or under it before.

:cool: Perl / MySQL / HTML+CSS


#7

Maybe I’m missing something elementary, but I still can’t figure out how to allow my users access to their web sites…

Is this what remapping the subdomains is for?


#8

[quote]Maybe I’m missing something elementary, but I still can’t figure out how to allow my users access to their web sites…

Is this what remapping the subdomains is for?[/quote]
OK Here’s an overview.

With you DreamHost account, you have access to a machine cluster which shares its files using a filesystem. You get a “user” which and space is set aside on the filesystem for this user to use for his files, such as mail and web files, among other things. This space is called the “home directory”. And each additional user you create gets his own home directory, too.

Now the web server is a program and it needs to know in what directory the files are for a certain domain. The “root” directory for a domain is called DocumentRoot in Apache, however the web panel calls it “Web Directory”.

Scenario A:

You just registered yourdomain.com and first day at DreamHost. Your username is “yourself” and this means you when you log into FTP as “yourself” you are accessing
/home/yourself
on the filesystem. You’ll probably see a directory named “yourdomain.com” there, because usually DreamHost sets DocumentRoot for your domain to “/home/yourself/yourdomain.com”.
So all files inside that directory show up at “http://yourdomain.com/” in your browser. Note: The directory does not have to have the same name as the domain.

OK Lets say you need to make a subdomain call “subdomain.yourdomain.com” and another person needs to upload files himself to that subdomain. First create the user, “someone”. Then create the subdomain. When creating the subdomain, chose his “someone” in all the drop-down menus. Then you will have:
someone’s home directory = /home/someone
subdomain.yourdomain.com Web Directory / DocumentRoot = /home/someone/subdomain.yourdomain.com
CGI runs as user: someone
When “someone” logs into FTP, he will be accessing his home directory, and he should have a directory called “subdomain.yourdomain.com” there. All files in that directory will show up at
"http://subdomain.yourdomain.com/"

Now you’ll notice throughout that whole process of the new user and new subdomain we never mentioned “yourself” or “/home/yourname” or “/home/yourname/yourdomain.com” - this means “yourself” and its files are out of the FTP picture when it comes to the files used for the subdomain.

Now, if on the other hand you want
http://yourdomain.com/users/someone/
to show files that “someone” uploaded, but
http://yourdomain.com/
to show files that “yourself” uploaded, you want to use the “Re-map Sub-Dir” function of the web panel. The setup is a bit different, for example you have to create the directory that your re-mapping to if it doesn’t already exist. However the same thing about FTP applies: only login as the user that is supposed to have access to the files.


#9

Yes! Now that makes sense to me, thank you.

It also worked one other way:

Domains > Manage
Set the web and log directory to be under the correct username. The result seems to be similarly effective.