View Single Post
  #5  
Old 29th October 2012, 14:50
foxx foxx is offline
Junior Member
 
Join Date: Feb 2010
Posts: 5
Thanks: 1
Thanked 2 Times in 1 Post
Default

Quote:
Originally Posted by till View Post
The 3.0.5 release is developed in its own branch, so svn trunk does not contain the latest changes.
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).

Quote:
Originally Posted by till View Post
All settings that you do in the client limits affect only new items, not existing ones.
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.

Quote:
Originally Posted by till View Post
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.
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.

Quote:
Originally Posted by till View Post
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.
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 )

Quote:
Originally Posted by till View Post
Admins can always override limits of a client, thats intended and works like the root user on the Linux shell.
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.
Reply With Quote