I tried to setup an cronjob, and apparently it doesn't work. I searched a bit in the logs and found the following three lines is auth.log: server2 usermod[17924]: change user 'web7' home from '/var/www/clients/client2/web7' to '/var/www/clients/client2/web7/./var/www/clients/client2/web7' server2 usermod[17924]: change user 'web7' shell from '/bin/false' to '/usr/sbin/jk_chrootsh' server2 usermod[17924]: change user 'web7' home from '/var/www/clients/client2/web7/./var/www/clients/client2/web7' to '/var/www/clients/client2/web7/./home/web7' looks very strange to me then a bit later: server2 jk_chrootsh[22742]: path /var/www/clients/client2/web7/./home/web7 is not owned by user 5008 server2 jk_chrootsh[22742]: path /var/www/clients/client2/web7/./home/web7 is not owned by group 5005 server2 jk_chrootsh[22742]: abort, path /var/www/clients/client2/web7/./home/web7 is not owned by 5008
Moved your post to ispconfig 3 forums. The lines above are ok. You enabled chrooting for the user and the lines are the usermod changes required for a chrooted enviroment. Cronjobs are working fine in ispconfig 3.0.3.1, so it dont think you found a bug. Most likely you try to execute a command which is not inside the jail.
hmmm... why do the error messages then appear? the cron job should just execute a php file situated in the webroot of web7. what's wrong?
These are just notices from the jail creation script. They are ok. When you use a jailed cronjob, then all apps that you want to execute have to be in the jail. The php binary is not in the jail, so executing a php file with /usr/bin/php /path/to/my/file.php will not work. There are several possible solutions: a) When you want to use a jail, then use a command that is available inside the jail like wget to execute the php. The php script has to be put in the web dir so that wget can fetch it with a http url. b) install php into the jail. Thats a bit complicated as php jhas a lot of dependencies. You might want to consult the jailkit doczúmentation if you like to do this. c) Do not enable jails for thsi website. But thats not as secure as all system commands and files that can be accessed by a normal not jailed shell user are accessible by the cronjob.
err.. I didn't make a conscious choice of using a jail or not, I just setup a cron job in the ISPconfig panel. So I am a bit lost regarding the cron jobs. Is it enough to create a cron job by writing something similar to /usr/bin/php /var/www/clients/client2/web7/web/myscript.php ? Or are there other things to do for this to work? Another question: would the creation of that cronjob cause /etc /usr /bin /var directories to appear in the user's directory under client/web7 ?
The cronjob limits are set in the client settings and get applied automatically to all websites that belong to that client. This will work if the cronjob is not jailed. If its a jailed cronjob, then yes. Otherwise, no. The main problem now might be that a website can not unjailed by simply changing the client settings, as the jail creation affects the whole setup of the website. So even if you want to unjail the site, you should first set the "max type of cronjobs" setting in the client limits to full cron. Then edit the /etc/passwd file and change the shell of the web7 user from /usr/sbin/jk_chrootsh back to /bin/false and change the path from /var/www/clients/client2/web7/./var/www/clients/client2/web7 back to /var/www/clients/client2/web7
*scratch head* you need to make this simpler currently, the client is set at URL cron and max cron 0 (default settings) => I have no idea if the cronjob is jailed, but since the directories appeared, I guess it is jailed? => max cron = 0, will this prevent the cron job from being executed? (it could be useful to display the settings in the cron screen) Sooo... but since the Cron is jailed, you say that /usr/bin/php /var/www/clients/client2/web7/web/myscript.php will not work. So I should set the client to "Full cron" with a sufficent limit, right?
Yes, you have to set it to full cron as I wrote in my post above. The "max cron" number says only how many cronjobs the client is allowed to create.
I think you can use mailto to verify jobs functionality or execute some sort of script that gives you alert on failure or success. here is a post on cron jobs to know more about cron thing and have a look at ispconfig manuals
just as an idea, it could be useful to have a cron screen for the server admin, separate from the user crons.
yes, I meant a screen where the server admin can setup cron jobs on server level independently of client's settings. i.e. for admin to run his own crons under root user
