Cronjob handling, webpage users shell doesn't change - Bug?

Discussion in 'Installation/Configuration' started by foxx, Oct 29, 2012.

  1. foxx

    foxx New Member

    I'm very confused how user cronjobs are handled.

    I've created a user which at first had only URL cron rights.
    This worked quite well and all the URLs were executed as expected.

    Than I added a new PATH cronjob as admin to this user. There wasn't any error and I haven't seen that this user should only be able to have URL crons.

    This cron didn't worked as expected and I found the problem: The webpage users (webXX) shell was set to Jailkit but Jailkit wasn't configured properly:

    abort, homedir '/var/www/clients/clientX/webXY' for user webXY (5008) does not contain the jail separator <jail>/./<home>
    I decided to add the jail seperator manually and the cronjob started working - but only inside chrooted Jailkit (I haven't found any way to choose between Jailkit/Full execution as admin).

    My aim was and is to get the cronjob work in the full environment - not chrooted.

    So I changed the users Cron Type Limit to "Full Cron" - nothing changed.
    Than I recreated the cronjob inside ISPConfig as the user - nothing changed.

    The cronjob is still executed by the webpage UNIX User webXX and it's shell is still the jailkit shell.

    This is very confusing. Is this the desired behaviour or should I fill a bug report.

    Is there any way of changing the webpage users shell to the default bash/sh... with ISPConfig or do I have to do this manually?
  2. till

    till Super Moderator Staff Member ISPConfig Developer

    This problem has already been fixed in 3.0.5 alpha 1. The problem occurs when tere are applications running under the same user at the time the shell gets chnaged as the linux usermod command fails then and we had to write our own code instaed of using the linux tools for user management.
  3. foxx

    foxx New Member

    Thank you for your quick response!

    Than it might be the bug I experienced earlier with Shell accounts. But for them it's very obvious what should happen: There I can choose between None/Jailkit environment and can see if this change is working or not.
    I reported this and it's nice to see this fixed.

    For cronjobs I don't know what's the expected behavior, I tried it with ISPConfig 3.0.5 from svn trunk:

    - If I change the "Max allowed cronjob types" in the admin panel for a user the users shell doesn't change

    - User X has cronjob type "URL only", it's shell is /bin/false
    - User X adds /var/www/userdomain.tld/web/ to its cronjobs. There is no error message and the user isn't aware in any way that he's only allowed to add URL crons. It just works for him but doesn't get executed (because of /bin/false shell)

    - I decided that User X should be able to have full shell cronjobs. That's why I changed the "Max allowed cronjob types" in Limit tab of the user settings to "Full cron".

    I would expect that the shell of all sites of this user is now changed to /bin/sh or /bin/bash or anything different from /bin/false

    BUT: There is no change in shell. And it's 3.0.5 so it shouldn't be a problem if the users is logged in. There is no error message or anything for the change of the limit. At least the job executes properly.

    - Even if the users adds a new cronjob or edits a previously added one the shell doesn't change and the cronjobs aren't working magically as there doesnt seem to be a possibility for the user to see if it's cronjobs executes properly. (Would be great to have a cron log for the user).

    - I realized later that the cron insert/delete jobs doesn't move away from the job queue and had a look at the cron log:

    mkdir: cannot create directory `/var/www/clients/client2/web1/var': File exists
    mkdir: cannot create directory `/var/www/clients/client2/web1/var/run': File exists
    mkdir: cannot create directory `/var/www/clients/client2/web1/var/run/mysqld': File exists
    ln: failed to create hard link `/var/www/clients/client2/web1/var/run/mysqld/mysqld.sock': File exists
    usermod: user web1 is currently logged in
    failed to execute usermod -d /var/www/clients/client2/web1/. -s /usr/sbin/jk_chrootsh web1
    failed to modify user web1
    usermod: user web1 is currently logged in
    PHP Fatal error: Call to a member function mkdir() on a non-object in /usr/local/ispconfig/server/plugins-available/ on line 302
    So it's still the same problem and at least the cronjob jobs stay in the queue but HOW do I get them to execute again or at least remove them from queue?
    I don't even know why the user is logged in as he's not loggedin in a shell (uptime says 1 user logged in and thats root) and there is no process in process table with "web1"

    This can't be the final expected behavior.

    - (minor) What should happen if I add a executable cronjob /var/www/.../ as admin to a user which is only allowed to run URL cronjob? If that shouldn't be possible there should be an error message
  4. till

    till Super Moderator Staff Member ISPConfig Developer

    The 3.0.5 release is developed in its own branch, so svn trunk does not contain the latest changes.

    All settings that you do in the client limits affect only new items, not existing ones.

    Thats not intended as you can see in the php error message that there is coding error. 3.0.5 is alpha software for testing and might contain programming bugs like the one you noticed yet.

    The linux usermod defines a user as logged in when there is at least one process running under this uid. The problem is that usermod has no options to force a change. So basically this problems are all in usermod which rejects to do the cahnges in /etc/passwd and ispconfig has to work around these issues.

    Admins can always override limits of a client, thats intended and works like the root user on the Linux shell.
  5. foxx

    foxx New Member

    Thanks for this notice but I thought that between revision 3594 and 3609 nothing regarding this issue has been changed after having a look at the svn log.
    But I will try the latest 3.0.5 branch soon and even reinstall the whole system as some SQL incremental dumps weren't executed properly or just doesn't exists for alpha so my database structure seems to make some problems (directive_snippets table does not exists).

    Ok, good to know. But how is that possible for cron jobs? e.g if a user was allowed to add full shell cronjobs (e.g /bin/sh shell) and the admin decides to limit to URL only cron. What happens if the user adds a new cronjob?
    - Will there be a new unix user created which has /bin/false shell?
    - Is the existing unix user used - this would result in either a change of existing user to /bin/false and therefore a not working old cronjob or the unix users shell stays at /bin/sh and also new cron jobs are executed with non chrooted shell.

    I'm aware of that - that's why I'm testing 3.0.5 only in a virtual machine. But I thought public testing access is intended for finding bugs etc. and because its still alpha I didn't filled a bug report and just asked here.

    Ok that makes sense for me. It's why I asked for the intended behavior. How do you work around those issues? As I don't see a retry button or at least the possibility of canceling the jobs and deleting the cronjobs. (Sure, this might be due to bugs in the alpha code - than I don't want to complain :))

    Sure but how are these jobs handled? What happens if the admin adds a executable cronjob for a user which has /bin/false shell?

    I primarily wanted to mention that it's not very transparent how cronjobs are handled as users are able to add any kind of cronjob regardless of there limit settings (sure they aren't executed to to the shell limit) and if changes in the limit are made it's not obvious which shell is used for the new job and existing jobs when adding a new job.

    There might be a perfectly well designed backend and concept behind the current behavior but in my opinion it's just a bit intransparent. And that's not just for the bleeding edge alpha code but for the current stable too.
  6. till

    till Super Moderator Staff Member ISPConfig Developer

    We force a update of the user manually when usermod fails. I will check if this is not working correctly for cronjobs yet, I know that it works for ssh users.

    I'am aware that this has to be improved. I havent written the cronjob part and did not had the time to write it again yet.
  7. foxx

    foxx New Member

    Ok sounds good. As I wrote already I will try the 3.0.5 branch soon and continue monitoring the svn commit history. By the way: 3.0.5 looks really great especially the APS module. Looking forward to a beta/RC.

    I don't wanted to complain - I like this piece of software and really appreciate your work. I want to support your work and that's why I have a howtoforge subscription from time to time and place bug reports.
    I would change the code on my own and publish the patches but currently I don't have the time...

    Thank you for your quick responses and keep up the great work :)

Share This Page