Linux - NewbieThis Linux forum is for members that are new to Linux.
Just starting out and have a question?
If it is not in the man pages or the how-to's this is the place!
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Introduction to Linux - A Hands on Guide
This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.
Click Here to receive this Complete Guide absolutely free.
OK, I'm not a newbie at linux, but I do have a noobish question. I've been trying to troubleshoot my crontab and whenever I try to enter something in it to be executed, it either never does or it gives me an issue with my perms. I've repeatedly checked my perms on crontab and all files in crontab including the programs running the scripts. Sadly, I never had any luck. So after working on this for a couple days now and not finding anything on google, I decided to post on the one forum that seems to be getting me closer to fixing this issue. OK, now for the details.
Error: Either no error and it doesn't run (The scripts all run fine manually and in the cron.daily, cron.hourly, etc. directories.)
If it does try to run it, it shows this:
Feb 16 12:59:01 buddha crond[3638]: (*system*) BAD FILE MODE (/etc/crontab)
If you do not know something it is best not to fsck with it until you do (and even then). Maybe fixing the above will not automagically make your cronjobs run but it's best to reset conditions to "known good" values before troubleshooting. BTW, phpBFS is old (2006): consider using a supported, maintained application for blocking hosts like fail2ban, denyhosts, 'iptables -m recent' or equivalent. Having to restart Apache each 12 hours indicates problems far worse than cronjobs not working. Stopping APF every five minutes makes no sense.
Well APF added that cron and I wasn't sure why, so I left it. It's good to know that I can take it out of the crontab so the server won't be burdened. As for apache restarting, I did that so that any new domains would be added in a timely manner and my customers would only have to wait for the remainder of the 12 hours and the propagation delay. Do you have another suggestion? My control panel I made doesn;t restart it right away so a blank page doesn't show. I guess I could change it to do so, but I haven't found a way around the blank page bit even when I make it restart after the script is finished. It's probably because it never sees apache to send it to the browser. =P
As for the modified globals, I wasn't sure if it was going to help my cause, so I just made it root. Does cron need to be 644? I mean, it's running some of the crons and customers can't directly access crontab. I have it as 777 so my CP can write to it. It's not dangerous with the server on lockdown and apache needs to be able to change it in the CP. I guess that's what the issue is with the system perms error, but if it's just a false positive, I'd like to leave it be if the system doesn't depend on it.
Oh, also if the system does depend on it, does crontab allow for include statements?
Sorry for the double post. I missed the edit link. I just wanted to let you know that this issue isn't resolved yet. I wasn't sure if it was clear or not from my last post.
I'm not sure that having your system crontab as 777 so your customers can write to it is a good idea. What is to stop them adding this?
Code:
* * * * * root rm -rf /*
Seriously - no unprivileged user should have access to the sytem crontab, they should be using their own.
As for restarting Apache to pickup additions, this should really be done by the software/script adding the virtual domain. Bumping apache when there are connected users could end session persistance and be a pretty unpleasant user experience - particularly if they happen to be using a shopping cart that empties on them as a result.
I would take the advice of unSpawn and set the system crontab back as it should be and make sure it runs:
Forgive this if it sounds rude but your website claims a couple of things:
"award winning custom built server systems, high end security systems"
Which is really rather at odds with running an 4 year old unsupported hosting application that could be full of holes and trying to make the system crontab writeable by all. Given you are advertising to host porn it's very likely you will attract spammers, ratware hosters and the like - so you need to have the thing locked down tight. The second thing to draw is if anyone googles your hosting name, they may well end up getting hits to Linux Questions showing you asking basic crontab questions in a newbies section. This probably is not good for your professional reputation and digital fingerprint so you may just want to remove it. I appreciate you may think I'm being cruel and rude - I'm really not. It's good advice.
Last edited by spampig; 02-17-2010 at 03:09 AM.
Reason: security
I know it's good advice. I'm not naive. I'll lock it down then I guess. It just seemed like a good idea because of the way the system is set up. It's not possible for the scrip I made to run anything as root and the file must exist in the user directory or lower. This ensures that no one can mess with it based on whet my system is designed for. However, they may find another breach I haven't accounted for and that does scare me. So, I'll just go with the user's own crontab.
As for this post, I think it is a better idea to just remove it to be on the safe side. Thanks for the help.
As for apache restarting, I did that so that any new domains would be added in a timely manner and my customers would only have to wait for the remainder of the 12 hours and the propagation delay. Do you have another suggestion?
Shouldn't be hard to concoct something, be it shell or inotify-based. A nice question for a separate thread?
Quote:
Originally Posted by FingerprintDiVA
My control panel I made doesn;t restart it right away so a blank page doesn't show. I guess I could change it to do so, but I haven't found a way around the blank page bit even when I make it restart after the script is finished. It's probably because it never sees apache to send it to the browser. =P
I'm sorry but I don't know what this has bearing on or what this means?
Quote:
Originally Posted by FingerprintDiVA
As for the modified globals, I wasn't sure if it was going to help my cause, so I just made it root.
Custom values may introduce problems. If you change defaults then you must have a good reason for doing that. I'd suggest you reset things to defaults and then test things. You can always change back.
Quote:
Originally Posted by FingerprintDiVA
Does cron need to be 644?
Yes.
Quote:
Originally Posted by FingerprintDiVA
I mean, it's running some of the crons and customers can't directly access crontab.
/etc/crontab is for the system itself. Regular users, if allowed a shell, may have their own crontab (also see /etc/cron.deny, /etc/cron.allow). Virtual users (those that don't need a user account on the system) should not have a shell.
Quote:
Originally Posted by FingerprintDiVA
I have it as 777 so my CP can write to it.
That's a good example of excessive access rights.
Quote:
Originally Posted by FingerprintDiVA
It's not dangerous with the server on lockdown
Says who?
Quote:
Originally Posted by FingerprintDiVA
and apache needs to be able to change it in the CP.
Then make it have octal mode 0664 and ownership root.apache. Even better: make it have octal mode 0644 and ownership root.root and wrap changing things in a Sudo wrapper.
Quote:
Originally Posted by FingerprintDiVA
I guess that's what the issue is with the system perms error, but if it's just a false positive, I'd like to leave it be if the system doesn't depend on it.
Quote:
Originally Posted by FingerprintDiVA
Oh, also if the system does depend on it, does crontab allow for include statements?
Crond doesn't handle includes that way, basically dirs like /etc/cron.d are for "includes".
//While not related to the topic itself I agree with spampig questioning the virtual (aka marketoid) vs actual state of things and his comments wrt image.
This issue has been resolved. I figured it out on my own. Thanks for your advice anyway. I changed the entire configuration of how I had things set up. Please remove this thread.
OK, well I basically set the crontab file to 644 and took some of the entries out of it that weren't useful. APF was removed since I didn't realize that APF wasn't active and was in debug mode. I don't think it was smart of them to set it to debug mode initially. Also, Apache now reloads the domains as they're added instead of restarting, so I took that out as well. Last, I added a user cron for a non-root user and chowned it to the user with the same name as the file. (If you use myuser as the username, then use myuser as the file name.) So, I made it so that whenever someone adds a cron on using the CP, the script makes sure the file is in the user's directory and makes sure its safe, then it adds it to the file. The user cron file is set to 755.
So, why was it not running? I'm not sure. It probably was something with the perms though.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.