Yes they are persistent across reboots (they're just files in a spool).
Regarding having access to them, as a regular user you won't have access to the files, but you could build a system to back them up. Maybe something like this:
MYAT=~/atjobs
/bin/rm -rf $MYAT/*
at -l >$MYAT/JOBS
for j in `cat $MYAT/JOBS | cut -f1`
do
at -c $j >$MYAT/$i
done
If you needed to reload the job later:
for j in `cat $MYAT/JOBS | cut -f1`
do
# make sure the job isn't defined
atrm $j
# reload it from the file
at -f $MYAT/$j `grep ^$j $MYAT/JOBS | awk '{ print $3, $2 }'`
done
(this is all mostly untested. The basic command are right but there's sure to be a bug in the logic in there somewhere)
Having said all that though, I'm not sure I'd use at for the task you describe. I'd probably use a preexisting calendaring system. Failing that though, I would user a cron job that ran daily that checked a file to see if there were any messages to send. Much more portable than at jobs, and much more likely to be remembered if you switch machines...
From what I understand you want trafic that come from ProviderA to go back to ProviderA and trafic that come from ProviderB to go back to ProviderB.
I don't really understand "I don't want to hardcode the IP addresses", as a /24 will not be dynamic. So I would do a route-map based on the source address. It's not 100% good because you may have received trafic on ProviderA IPs from the ProviderB link even with AS prepending and you will send back the trafic to ProviderA instead of ProviderB but it will be Ok most of the time.
access-list 101 permit ip PROVIDER_A_SUBNET 0.0.0.255 any
access-list 102 permit ip PROVIDER_B_SUBNET 0.0.0.255 any
route-map SOURCE_ROUTING permit 10
match ip address 101
set ip next-hop PROVIDER_A_ROUTER
route-map SOURCE_ROUTING permit 20
match ip address 102
set ip next-hop PROVIDER_B_ROUTER
Then apply policy route-map SOURCE_ROUTING on the interface that receive data that need to go out.
Best Answer
In RHEL, there's two places where these things should probably go.
For adding static routes in RHEL, you add them to /etc/sysconfig/network-scripts/route-INTERFACE where INTERFACE matches the name of the ifcfg-INTERFACE entries. The statements in the route-* files will be passed to
ip route addandip route delwhen the interface is brought up or down.Now, for the
ip rulecommands, the best place I can think of would probably be in/sbin/ifup-local. If this file exists, it gets run after an interface is brought up. One note with this one, if/sbin/ifup-localexists, it will get called as an executable and passed an argument of the interface name. So you'll have to write handler code to check that argument against the interfaces you want to add configs for and then take the appropriate action.As an example:
If you wanted to, you could include the ip route rules for each interface in
ifup-local, too. If you wanted to remove the corresponding rules when an interface is downed, you could create a similar/sbin/ifdown-localscript to handle that.If it were me, even though RHEL provides a standardized way of handling static routes, I'd probably do everything in
ifup-localandifdown-local, just to keep all my interface specific bits together.