Hey Nils,
On Sun, 2008-08-03 at 05:57 -0700, Nils Goroll wrote:
> This does sound like a valid alternative solution for this requirement if you
> want to avoid using "at", though this will involve additional complexity for
> parsing timestamps of existing snapshots and calculating intervals, which
> I think is not that trivial in shells (consider timezone changes, leap years
> etc).
Right - the code I have is good enough: you're absolutely correct that
it drifts across unequal months and leap years, but I'm happy with it.
The code I have right now does basically this: get the last snapshot
taken for this schedule, then:
----
# all calculations done according to time since epoch.
LAST_SNAP_TIME=$(zfs get -H -p -o value creation $LAST_SNAPSHOT)
LAST_SNAP_TIME_HUMAN=$(zfs get -H -o value creation $LAST_SNAPSHOT)
NOW=$(perl -e 'print time;')
MINUTE_S=60
HOUR_S=$(( $MINUTE_S * 60 ))
DAY_S=$(( $HOUR_S * 24 ))
MONTH_S=$(( $DAY_S * 30 ))
case $INTERVAL in
"minutes")
MULTIPLIER=$MINUTE_S
;;
"hours")
MULTIPLIER=$HOUR_S
;;
"days")
MULTIPLIER=$DAY_S
;;
"none")
return 0
;;
"*")
print_log "WARNING - unknown interval encountered in
check_missed_snapshots!"
return 1
esac
PERIOD_S=$(( $MULTIPLIER * $PERIOD ))
AGO=$(( $NOW - $LAST_SNAP_TIME ))
if [ $AGO -gt $PERIOD_S ] ; then
print_log "Last snapshot for $FMRI taken on LAST_SNAP_TIME_HUMAN"
print_log "which was greater than the $PERIOD $INTERVAL schedule.
Taking snapshot now."
take_snapshot $FMRI
fi
----
Suggestions welcome?
> # Adding a cron job that runs exactly every x time-intervals is hard to do
> # properly.
Absolutely.
> > Hard to please everyone! If you felt like it, it'd be great to get the
> > "offset" property working - that'd make the use of cron a lot more
> > flexible for admins I think.
>
> OK, I'll let you know when (if) I start working on it so we don't do double
> work.
Thanks!
> > Would the conditional-snapshot-on-start-method solution work for you?
>
> I think so, on the other hand I don't see why exactly you want to avoid
> supporting
> "at" as well.
I'd like to avoid adding at(1) support because while I think it's a
pretty neat hack, I think it also duplicates functionality, causes more
maintenance and doesn't have a clean interface with the rest of the
service (imho).
If cron not being expressive enough is the problem, yet cron is an
already accepted way of running periodic system services, wouldn't it
make more sense to spend time getting cron up to spec on Solaris than
having to always hack around it?
> > I've attached some sample code - see what you think.
>
> This is basically a simpler version of the same idea - put svcprops in
> variables.
> There are a couple of obstacles here:
>
> - If you create variables with the names of svc properties, you run into the
> issue that shell variables cant contain all characters valid for svc
> properties,
> which you need to work around then (you are using sed to filter out some
> characters (e.g. by mapping - to _), but this will make more than one svc-
> prop onto the same cache entry, which might work for zfs-auto-snapshot,
> but is not a general solution).
I'm not sure it needs to be a general solution, it just needs to work
for this service. I'm just filtering out the key values though, I think
this should be safe.
> My suggested code uses associative arrays which don't have this limitation.
>
> - For your solution, how do you invalidate the cache if a property is being
> changed or deleted (this is trivial, but not yet implemented)?
Right, the cache gets created once at the beginning of a method call, if
a user changes an SMF property in the middle of that method running, the
results should be undefined.
> - Does your solution handle white space, quotes etc. in svcprop values
> properly
> (I think there is an issue regarding white space, but I have not tested it)?
Very good point - I'll dig into this.
> - Does your solution impose a security risk? (consider the eval $NAME)
Not that I'm aware of - at least no more than the "zfs/backup-save-cmd"
property, which allows an administrator to set an arbitrary command to
process the zfs send stream. The point is, if a user can set any SMF
property for this service, then they're already privileged (or should
know better)
With the upcoming change to running this stuff under a restricted role,
this will be even less of a concern.
cheers,
tim
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
