DA cant delete users properly

[pucky]

After, lets see, i think its like 3yrs now DA still cant do a clean delete of a domain + user.

The older the site domain on the box the worst the problem it seems.

I just found a bunch of these. These should have been deleted years, weeks and months ago. The directory and files in those directories still exist.
Should not have to sit at the server level babying deletion to make sure the user has been removed from the system.

drwx--x--x 3 1024 1024 512 Mar 23 15:05 boar1com
drwx--x--x 3 1040 1040 512 Apr 8 17:30 green
drwx--x--x 3 1187 1187 512 Apr 8 17:21 gwenw
drwx--x--x 3 1189 1189 512 Sep 6 2009 lloydj
drwx--x--x 3 1108 1108 512 Aug 27 2008 luthcross
drwx--x--x 3 1256 1256 512 Apr 12 18:14 privateart

UID is a dead giveaway.

 

[floyd]

I believe it is a server configuration or something that is preventing DA from deleting the users completely. The reason I come to that conclusion is because I have been using DA for over 5 years and have over 100 licenses on servers and VPS's and thousands of users and have never experienced that problem.

Try creating a test user and then deleting and find the parts that are not deleted and then find out why. Check the DA logs.

If the UID username is showing up then that means that the user did not get deleted from the password file otherwise it would just show a number. If directories still exist maybe there are files that cannot be deleted for some reason.

 

[pucky]

There are all kinds of directories under these directories that dont get deleted for some reason.

1) Installatron
2) Gallery


And i havent looked any deeper. Not sure what config issue there would be. Its a standard Freebsd installation and the perms on those directories when they are create are correct.

The problem arises when the site had been around for years and then a reseller or the admin removes that user.

Creating a test site does not reveal an issue. Its deleted properly. Cannot duplicate it. It happens at random times most of the times.

Most of our users have hosted for more than 4yrs, some 8. I can almost guarantee that when we delete those sites they will not be removed from the server peoperly.

Those users do not exist in the passwd file by the way. Its not that.

 

[LawsHosting]

Must be a permission issue, then again, I imagine DA uses some root-like-activity to delete mysql, mail and file stuff?

 

[floyd]

Those users do not exist in the passwd file by the way. Its not that.

I do not know anything about debian. I do know that on CentOS that if the users are not in the passwd file then the usernames will not show up as owning files. Only the UID number will show as owning files.

Just using some deductive reasoning though, if nobody else using DA is having the problem then the problem is probably not with DA. You say this has been going on for 3 years yet nobody that I know of has reported the problem.

This is not a defense of DA. I am just saying if it were me I would be looking at what my system is doing different than everybody else's.

Try adding the same users again and then delete and see if the files are removed.

 

[SeLLeRoNe]

prolly that directories has been created via apache, gallery and stuff like that are created from many cms using 777 permission and the owner of those file is apache... so... when user test is deleted, he have no ownership to delete apache's files... thats why does files have not been deleted.

At least, this is happend to me, but just for that reason, nothing concerned to DA in any case.

You see the UID and GID just cause the user and the group doesnt exist anymore, so, DA did his job, but wasnt able to delete some files cause of file ownership not matched.

Regards

 

[nobaloney]

I do not know anything about debian. I do know that on CentOS that if the users are not in the passwd file then the usernames will not show up as owning files. Only the UID number will show as owning files.

This is true in any posix-compliant operating system, including all versions of Linux and BSD. The only place UIDs are connected to users is in the /etc/passwd file.

Internally in posix-compliant systems all ownership is by UID; they're only translated to usernames on presentation and back to UIDs when parsed.
Jeff