Steve Werby wrote: > > Jeff, I think if you're saying that most people whose *nix experience is > limited to Cobalt servers use the system crontab handled by /etc/crontab > then I'm with you.
Yes, that was my point. > But my guess is most are doing so because they notice > that all of Cobalt's automated scripts are handled by /etc/crontab and > either don't realize there are user crontabs or don't understand their > purpose. Yes, that's probably the reason. You've probably noticed that my answers to Cobalt list questions are usually limited to the way Cobalt does things, through the gui if possible. Though I've never thought about it, I guess the reason is because most people running RaQs have extremely limited experience, and don't have a system for experimenting. It's much easier to get something right the first time when you have an example to copy; at least that's always been true for me, so it's the way I tend to explain things on the list. The only time I can remember preaching a way other than Cobalt was a few years ago, before Cobalt made it easier to run DNS properly on a RaQ using the GUI; I used to recommend, and actually set up for clients, DNS outside the RaQ gui. I still use DNS outside the gui, and it's a lot faster to do, and for me much easier, but I now teach DNS to Cobalt users the Cobalt way. > And there *is* a purpose for the user crontabs. I can think of several, and I certainly agree with you on that. But I'd still bet that on most Cobalt RaQs crontabs are used close to exclusively for systemwide tasks. > > I know I do it, and just about > > everyone I've discussed it with does it that way. > > Maybe you're not talking with the right people. :p I'm probably not, from your point of view. I'm talking to my clients about their needs. Most of my clients are people with no more than a few Cobalt RaQs, using them mostly for the purpose for which they were made, but with some special needs now and then. Some have no special needs, but like someone else to watch over their systems either with them or instead of them. > Apparently, none of these companies you've worked with allow users to setup > their own cron jobs. I don't think any of them allowed "users" per se into the systems at all. In fact I can't remember any clients at all who had more than one person in charge of a system, and they used the cron jobs entirely for systemwide tasks, such as backup, backchannel DNS transfers, etc. > Or if they do, they have some sort of mechanism for > users to submit cron jobs and feed them to a script (or person) which writes > a nice line for /etc/crontab and drops the script in the system crontab. Thanks for the idea <smile>. > In > any case, I work with a lot of ISPs and hosting companies myself and when I > need to schedule a job on one of their boxes I use the crontab that's the > best fit for the situation. Based on my own criteria of what makes the most > sense, more often than not it's the user crontab system. Maybe my needs and > criteria are not the norm. Or maybe mine aren't <smile>. I'm often quite simplistic. If you would give me an idea of a job more suited to a user crontab, please do, I'd like to learn, and I bet a lot of us on these lists would as well <smile>. > Much of the software I build involves a lot of > shell scripting and automated jobs do crunch numbers for front-end tools, > generate reports, analyze data, etc. so cron jobs are an integral part of my > daily routine. Are you doing these on production hosting RaQs? I'm not. Do you think many RaQ owners are? Perhaps my original response WAS too simplistic. I agree that if I were doing something like your example above I wouldn't use a systemwide crontab unless I needed root access of files. > > Do you think the method you document is used by hosting companies as > > well? > > Absolutely. I couldn't tell you how many use one method over the other or > use some combination of the two, but there are definitely hosting companies > using the user crontabs. And I've been in plenty of boxes of hosting > companies and I've talked to quite a few folks who run hosting companies and > offer user crons to their clients. That's something we've never done, for the some reason we haven't allowed shell access since around 1996. Oh, I'm a hacker (NOT cracker) at heart, and I'd love to offer shell access to our clients, but every time I write on ISP-oriented lists about shell-access I get lots of replies against, and only one or two in favor, and even the replies in favor explain how much work I'll have to do keep users from misusing my system. It seems to be a common belief nowadays that anyone who buys an account with shell access is up to no good. > I was going to say I've talked to *a > lot* of people running hosting companies that do, but honestly when I talk > to folks running hosting companies "do you offer user crons?" and "which > cron system do you use?" are pretty far down my list of questions. <g> Okay, I'll agree with that <smile>. But I know my customers; some of them don't even know what "user access" is <smile>. They come from a pure hosting background, or a site-design background, or a "don't know anything at all but owning a RaQ seemed cool" background <smile, again>. Again, not to say anything against my clients, and others, who want to learn. As I've said above, perhaps my response was TOO simplistic, and too "do it the Cobalt way" oriented. However, if I go into depth in answering questions, I can't answer many. I suppose there's a fine line and perhaps I've been drawing it too far to the "little blue" side of center. Thanks for your well-taken points. Jeff -- Jeff Lasman <[EMAIL PROTECTED]> Linux and Cobalt/Sun/RaQ Consulting nobaloney.net P. O. Box 52672, Riverside, CA 92517 voice: (909) 778-9980 * fax: (702) 548-9484 _______________________________________________ cobalt-developers mailing list [EMAIL PROTECTED] http://list.cobalt.com/mailman/listinfo/cobalt-developers
