Re: [cobalt-developers] Raq 4 scheduled backup using ftp , set start time ?

["Steve Werby" <steve-lists@xxxxxxxxxxxx>]

Jeff, I wish I had time to answer all of the points I want to answer, but I
was out of the office for a few days so I'm only going to get to a few...

"Jeff Lasman" <jblists@xxxxxxxxxxxxx> wrote:
> But I'd still bet that on most Cobalt RaQs crontabs are used close to
> exclusively for systemwide tasks.

That may be.  There are hosting companies who have customers who want to
schedule scripts.  And for the most part those scripts can and should be run
as one of the site's users, not root.  That's what the user crontab is for.

> 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.

If most of your clients are using the boxes for "the purpose for which they
were made" (your quote) then most probably are hosting sites for customers.
Most of these customers probably have users and some probably want to be
able to schedule scripts.  I suppose if your clients don't allow customers
to schedule scripts the customers might not even think that there is a
possibility to do so though.

> > 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?

Yes.

> I'm not.  Do you think many RaQ owners are?

I think the typical RaQ owner isn't.  But that's at least in part because
the typical RaQ owner doesn't have a strong background in building software
or administering servers and probably doesn't realize that automating tasks
can improve save the box owner and site owners a lot of time and improve
site performance for data-driven sites.

> That's something we've never done, for the some reason we haven't
> allowed shell access since around 1996.

User management of crontabs does not necessarily require shell access.  Of
course, there are performance and security concerns related to allowing
users run CGI and other scripts, but that's the case whether they're
automated or not.  And I imagine you have clients who have customers running
scripts of some kind.

> 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.

I don't think there's anything wrong with a "Cobalt way" oriented approach.
As you can probably guess, that's not my approach.  That doesn't mean I
recommend or implement solutions without considering how they'll affect the
Cobalt software, but I won't think twice about implementing something that's
not the Cobalt way.  Most RaQs are probably used pretty much as Cobalt
intended, but there are a lot of RaQs out there running all kinds of
non-standard software and being used in ways most RaQ owners would probably
never consider...or never know is possible.  It's fun seeing what these
boxes can do.  <g>

> Thanks for your well-taken points.

You're welcome Jeff.  Thanks for giving me some new insight as well.

--
Steve Werby
President, Befriend Internet Services LLC
http://www.befriend.com/