Hi, I have ispconfig 3.0.1.6 and ubuntu 9.04 I was trying to add new domain after some time and all web folders (web, ssl, tmp etc) are with root owner instead client/group. Of course this cause forbidden when i'm trying to access the page. Someone else encounter this problem? Or what to check to see why folders have owner root. Also in web_domain table system_user and system_group are ok. And, for new ftp user i can't login. For old users all is ok. Thank you VM
Make sure that you set securite mode to high in the ispconfig server settings if you want that the folders are owned by the web admin user and not root.
The settings was already to high. Still the owner is root and i have forbidden message. I've set the level to medium and recreate the site. Now the owner is still root but i can access the page. Switching back to high all older sites created with medium level are working but new ones created with high level are not working. Thank you VM
root@miniserver:~# grep sshusers /etc/group root@miniserver:~# Doesn't give any result. Also ftp login don't work in any case. Thank you, VM
I have the same problem. The case is: 1. Web sites are added (I guess properly) to web_domain table 2. system_user and system_group are set (properly?) to web1119 and client1111 3. There's NO web1119 user and NO client1111 group added to system's config files! I have over 1000 web sites added. Every new website is created in ISPCONFIG, but there's no corresponding system user/group created in OS (/etc/passwd /etc/group /etc/shadow.....shows nothing). It looks like 1100 web sites was some kind of LIMIT - no web site system users created above that number... Ispconfig 3.0.1.4, Debian 5.0 XXX:~#:cat /etc/passwd .......,A LOT OF webXXXX web1098:x:6097:6095::/var/www/clients/client1091/web1098:/bin/false web1099:x:6098:6096::/var/www/clients/client1092/web1099:/bin/false XXX:~#:cat /etc/group .......,A LOT OF clientXXXX client1109:x:6113:www-data client1110:x:6114:www-data I've run manually: XXX:~# bash /usr/local/ispconfig/server/server.sh useradd: unknown group client1111 chown: wrong user: `web1119:client1111' chown: wrong user: `web1119:client1111' usermod: user web1119 does not exists chown: wrong user: `web1119:client1111' finished. The site IS CREATED: XXX:~# ls /var/www/stgtest2.XXX.XXX/ cgi-bin log ssl tmp web And I am privileged to perform useradd and stuff: XXX:~# whoami root Cheers, JMB
Please answer the same question that I asked in this thread in #4. Also you should check if there are any jobs are still waiting in the jobqueue.
Sorry, forgot to include: XXX:~# grep sshusers /etc/group lots of webXXXX,web1096,web1097,web1098,web1099 No web1100! XXX:~# jobs XXX:~# ps waux | grep php root 22855 0.0 0.0 89944 792 ttyp0 R+ 14:47 0:00 grep php Ispconfig's "Monitor > System State > Show Jobqueue" shows nothing.
XXX:~# cat /etc/group | grep sshusers sshusers:x:5002:web2,web4,web5,web6,web7,web8,web9,web10,web11,web12,web13....lots of webXXXX, web1096,web1097,web1098,web1099 XXX:/var/www/demo2.expecto.pl# cat /etc/group | grep sshusers | wc -l 1 XXX:~# groups web1099 client1092 sshusers Assuming - there's such a group. I did some aditional digging... /var/www/clients/client1092/web1099 web1099 client1092 - WORKS /var/www/clients/client1093/web1100 web1100 client1093 - This and all above (web1101....) doesn't work I run out of ideas. Maybe you could point me to the file that actually runs "useradd" - I could try unit-test it.
Ok. Then your problem is not related to this thread. To find out wahts wrong with your setup, enable debugging in ispconfig, then create a new website and check if you get any errors in the debug output. http://www.faqforge.com/linux/controlpanels/ispconfig3/how-to-enable-debugging-in-ispconfig-3/
Should I open another thread? If no, there's debug info (looks OK): XXX:~# cat /var/log/ispconfig/ispconfig.log 22.03.2010-15:24 - DEBUG - Set Lock: /usr/local/ispconfig/server/temp/.ispconfig_lock 22.03.2010-15:24 - DEBUG - Found 1 changes, starting update process. 22.03.2010-15:24 - DEBUG - Call function 'ssl' in plugin 'apache2_plugin' raised by event 'web_domain_insert'. 22.03.2010-15:24 - DEBUG - Call function 'insert' in plugin 'apache2_plugin' raised by event 'web_domain_insert'. 22.03.2010-15:24 - DEBUG - Creating Symlink: ln -s /var/log/ispconfig/httpd/X.Y.Z /var/www/clients/client1111/web1120/log 22.03.2010-15:24 - DEBUG - Creating Symlink: ln -s /var/www/clients/client1111/web1120/ /var/www/X.Y.Z 22.03.2010-15:24 - DEBUG - Creating Symlink: ln -s /var/www/clients/client1111/web1120/ /var/www/clients/client1111/X.Y.Z 22.03.2010-15:24 - DEBUG - Adding the user: web1120 22.03.2010-15:24 - DEBUG - exec: chown -R web1120:client1111 /var/www/clients/client1111/web1120 22.03.2010-15:24 - DEBUG - exec: chown web1120:client1111 /var/www/clients/client1111/web1120 22.03.2010-15:24 - DEBUG - exec: chmod 751 /var/www/clients/client1111/web1120/ 22.03.2010-15:24 - DEBUG - exec: chmod 751 /var/www/clients/client1111/web1120/* 22.03.2010-15:24 - DEBUG - exec: chmod 710 /var/www/clients/client1111/web1120/web 22.03.2010-15:24 - DEBUG - exec: chmod 777 /var/www/clients/client1111/web1120/tmp 22.03.2010-15:24 - DEBUG - exec: usermod --groups sshusers web1120 22.03.2010-15:24 - DEBUG - exec: chown web1120:client1111 /var/www/clients/client1111/web1120 22.03.2010-15:24 - DEBUG - Disable SSL for: X.Y.Z 22.03.2010-15:24 - DEBUG - Writing the vhost file: /etc/apache2/sites-available/X.Y.Z.vhost 22.03.2010-15:24 - DEBUG - Creating the symlink: /etc/apache2/sites-enabled/X.Y.Z.vhost => /etc/apache2/sites-available/X.Y.Z.vhost 22.03.2010-15:24 - DEBUG - Processed datalog_id 11804 22.03.2010-15:24 - DEBUG - Call function 'restartHttpd' in module 'web_module'. 22.03.2010-15:24 - DEBUG - Remove Lock: /usr/local/ispconfig/server/temp/.ispconfig_lock 22.03.2010-15:25 - DEBUG - Set Lock: /usr/local/ispconfig/server/temp/.ispconfig_lock 22.03.2010-15:25 - DEBUG - No Updated records found, starting only the core. 22.03.2010-15:25 - DEBUG - Remove Lock: /usr/local/ispconfig/server/temp/.ispconfig_lock 22.03.2010-15:26 - DEBUG - Set Lock: /usr/local/ispconfig/server/temp/.ispconfig_lock 22.03.2010-15:26 - DEBUG - No Updated records found, starting only the core. 22.03.2010-15:26 - DEBUG - Remove Lock: /usr/local/ispconfig/server/temp/.ispconfig_lock And in: /var/log/ispconfig/cron.log useradd: unknown group client1111 chown: invalid user: `web1120:client1111' chown: invalid user: `web1120:client1111' usermod: user web1120 does not exist chown: invalid user: `web1120:client1111' And the site's: XXX:~# ls -l /var/www/X.Y.Z/ total 16 drwxr-x--x 2 root root 4096 mar 22 15:24 cgi-bin lrwxrwxrwx 1 root root 54 mar 22 15:24 log -> /var/log/ispconfig/httpd/X.Y.Z drwxr-x--x 2 root root 4096 mar 22 15:24 ssl drwxrwxrwx 2 root root 4096 mar 22 15:24 tmp drwx--x--- 4 root root 4096 mar 22 15:24 web And there's of course no web1120 user in /etc/passwd... If you could point me to the file that runs "useradd" via server.sh - I could probably fix (workaround) it myself.
No, thats not nescessary. But the next time you have an issue, please make a new thread instead of posting at the end of another thread To your problem. I think that I haven an idea what gets wrong here. 1) Either the field "system_group" is empty for this website in the mysql database table web_domain. Please check that e.g. with phpmyadmin. 2) If thats not the case, then there must be a problem with the function $app->system->is_group('groupname'); so that it returns true while there is no such group. So after you checked 1) and made sure that this field is not empty in the database, check the integrity of the groupfile with the command: grpck on the shell. the apache plugin uses a function to find out if a group exists
Update. Just that you know where I came to the above conclusion. If you look at the apache plugin, there must have been the debug output: 22.03.2010-15:24 - DEBUG - Adding the group: client1111 right before the line: 22.03.2010-15:24 - DEBUG - Adding the user: web1120 but its not there. So the system seems to assume that this group is there or that the field for the group in the DB is empty.
ad. 1. The system_group is set ad. 2. grpck shows something like that: 'www-data' is a member of the 'client1111' group in /etc/group but not in /etc/gshadow but that's for all the records client2..client1111, if that's the case - shouldn't the error occur muche earlier? I did something like that i apache2_plugin file: $app->log("X1: ".$data["new"]["system_group"],LOGLEVEL_DEBUG); $groupname = escapeshellcmd($data["new"]["system_group"]); $app->log("X2: ".$groupname,LOGLEVEL_DEBUG); $MY_X3 = ($data["new"]["system_group"] != '') ? 'TRUE' : 'FALSE'; $MY_X4 = (!$app->system->is_group($data["new"]["system_group"])) ? 'TRUE' : 'FALSE'; $app->log("X3: ".$MY_X3,LOGLEVEL_DEBUG); $app->log("X4: ".$MY_X4,LOGLEVEL_DEBUG); //$groupname = escapeshellcmd($data["new"]["system_group"]); And the output is: 22.03.2010-16:38 - DEBUG - X1: client1111 22.03.2010-16:38 - DEBUG - X2: client1111 22.03.2010-16:38 - DEBUG - X3: TRUE 22.03.2010-16:38 - DEBUG - X4: FALSE 22.03.2010-16:38 - DEBUG - Adding the user: web1122 So you are right - is_group returns TRUE while it should return FALSE. I'll investigate it further...
You can find the code for the function in /usr/local/ispconfig/server/lib/classes/system.inc.php and the no_comments subfunction which is used to read the data is in /usr/local/ispconfig/server/lib/classes/file.inc.php The easiest way to debug this might be to copy just the is_group, no_comments, unix_nl and rf functions into a test file. I guess the problem might be that some kind of PHP in memory limit gets reached or so while parsing the large group file.
Hi, I've rewritten the is_group function to perform better on large group files. May you please test the following script on your server if it gives correct results. Code: <?php $test_group = 'client1'; function is_group($group) { $groupfile = '/etc/group'; if(is_file($groupfile)) { $handle = fopen ($groupfile, "r"); while (!feof($handle)) { $line = trim(fgets($handle, 4096)); if($line != ""){ $parts = explode(":", $line); if($parts[0] == $group) { fclose ($handle); return true; } } } fclose ($handle); } return false; } if(is_group($test_group)) { echo 'found '.$test_group; } else { echo 'not found '.$test_group; } ?> Please replace client1 in the line $test_group = 'client1'; with the groupname that you want to test for.
The function works, but I figured out - the old one works too. I've been adding web sites as ONE client (so the group wasn't created - that's why it didn't appear). The problem lies elsewhere. I've echoed the "useradd statement" used to create user for the site and tried to perform it manually: XXX:~/test_ispconfig# useradd -d /var/www/clients/client1111/web1124 -g client1111 -G sshusers web1124 -s /bin/false useradd: unknown group client1111 XXX:~/test_ispconfig# cat /etc/group | grep client1111 client1111:x:6116:www-data XXX:~/test_ispconfig# grpck | grep client1111 'www-data' is a member of the 'client1111' group in /etc/group but not in /etc/gshadow XXX:~/test_ispconfig# groupadd client1111 groupadd: group client1111 exists I'm wondering if the sshusers group isn't cousing the problem: XXX:~/test_ispconfig# cat /etc/group | grep sshusers | wc -m 7652 That's a lot of characters....maybe useradd can't allocate it properly? Tried to modify existing users with default existing group "usermod -g client2 dummyuser" - "group client2 doesn't exist".....the problem's probably in /etc/group file itself.... JMB
Thats possible. I will try to do some research if there is a limit for group files. You might try this: make a backup of the /etc/group file, remove the sshusers group temporarily and try the usermod test again. Do you offer ssh logins for your clients? If not, it might be temporary solution to modify the apache plugin on your server so that the new system users were not added to the sshusers group. The website functions should not be affected by this.
