Currently I have in my params: CGCOIF=$(ssh root@gw "/sbin/uci -p /var/state get network.wan0.ifname") IGSIF=$(ssh root@gw "/sbin/uci -p /var/state get network.wan1.ifname") PPPEIF=$(ssh root@gw "/sbin/uci -p /var/state get network.pppoe_ether.device") CGCO_GATEWAY=$(ssh root@gw "/sbin/uci -p /var/state get network.wan0.gateway") IGS_GATEWAY=$(ssh root@gw "/sbin/uci -p /var/state get network.wan1.gateway") IGS_ADDRESS=$(ssh root@gw "/sbin/uci -p /var/state get network.wan1.ipaddr") Which is a whole lotta round trips all requiring their own crypto authentication, etc. I wonder if there is an available hook that I could use to go fetch all of that in a single round-trip (i.e. and store it locally and then source that local file for the values). I suppose if params is just sourced and executed sh script I could just do the single execution and use the result. I''m not sure that it is though. Thoughts? b. ------------------------------------------------------------------------------ Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d
On 02/21/2012 01:23 PM, Brian J. Murrell wrote:> Currently I have in my params: > > CGCOIF=$(ssh root@gw "/sbin/uci -p /var/state get network.wan0.ifname") > IGSIF=$(ssh root@gw "/sbin/uci -p /var/state get network.wan1.ifname") > PPPEIF=$(ssh root@gw "/sbin/uci -p /var/state get network.pppoe_ether.device") > CGCO_GATEWAY=$(ssh root@gw "/sbin/uci -p /var/state get network.wan0.gateway") > IGS_GATEWAY=$(ssh root@gw "/sbin/uci -p /var/state get network.wan1.gateway") > IGS_ADDRESS=$(ssh root@gw "/sbin/uci -p /var/state get network.wan1.ipaddr") > > Which is a whole lotta round trips all requiring their own crypto > authentication, etc. > > I wonder if there is an available hook that I could use to go fetch > all of that in a single round-trip (i.e. and store it locally and then > source that local file for the values). > > I suppose if params is just sourced and executed sh script I could just > do the single execution and use the result. I''m not sure that it is though. > > Thoughts?I guess my first question is "How are you using these variables?". In configuration files, the first three can be replaced by "Runtime Address Variables"; see http://www.shorewall.net/configuration_file_basics.htm#Variables. Shorewall will detect the gateway addresses for you and store them in shell variables in the generated script, but so far I haven''t implemented gateway Runtime Address Variables, though. Not hard to do, though... The params file is process by ${LIBEXEC}/shorewall/getparams which simply sources it using ''.'' (assuming that EXPORT_PARAMS=No). -Tom -- Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________ ------------------------------------------------------------------------------ Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d
On 12-02-21 04:38 PM, Tom Eastep wrote:> On 02/21/2012 01:23 PM, Brian J. Murrell wrote: >> Currently I have in my params: >> >> CGCOIF=$(ssh root@gw "/sbin/uci -p /var/state get network.wan0.ifname") >> IGSIF=$(ssh root@gw "/sbin/uci -p /var/state get network.wan1.ifname") >> PPPEIF=$(ssh root@gw "/sbin/uci -p /var/state get network.pppoe_ether.device") >> CGCO_GATEWAY=$(ssh root@gw "/sbin/uci -p /var/state get network.wan0.gateway") >> IGS_GATEWAY=$(ssh root@gw "/sbin/uci -p /var/state get network.wan1.gateway") >> IGS_ADDRESS=$(ssh root@gw "/sbin/uci -p /var/state get network.wan1.ipaddr")FWIW, the following seems to do the trick in params: ssh root@gw "echo CGCOIF=\$(/sbin/uci -p /var/state get network.wan0.ifname) echo IGSIF=\$(/sbin/uci -p /var/state get network.wan1.ifname) echo PPPEIF=\$(/sbin/uci -p /var/state get network.pppoe_ether.device) echo CGCO_GATEWAY=\$(/sbin/uci -p /var/state get network.wan0.gateway) echo CGCO_ADDRESS=\$(/sbin/uci -p /var/state get network.wan0.ipaddr) echo IGS_GATEWAY=\$(/sbin/uci -p /var/state get network.wan1.gateway) echo IGS_ADDRESS=\$(/sbin/uci -p /var/state get network.wan1.ipaddr)" > foo eval $(cat foo) rm foo I''m sure there''s some quoting magic to eliminate the "foo" intermediate, but it''s just too late in the day to keep messing with it.> I guess my first question is "How are you using these variables?".Some examples: ./masq:$IGSIF !$IGS_ADDRESS $IGS_ADDRESS ./interfaces:pppe $PPPEIF detect maclist,routeback,optional ./rules:Ping/ACCEPT fw net:$CGCO_GATEWAY ./accounting:DONE - - $CGCO_ADDRESS ./rules:#Ping/ACCEPT fw net:$IGS_GATEWAY> In > configuration files, the first three can be replaced by "Runtime Address > Variables"; see > http://www.shorewall.net/configuration_file_basics.htm#Variables.Ahhh. &<ifname>? Note that those first three variables in my list above are interface names not their addresses. The .ipaddr ones are addresses. Can I assume these runtime variables will work for shorewall-lite installations?> Shorewall will detect the gateway addresses for you and store them in > shell variables in the generated script, but so far I haven''t > implemented gateway Runtime Address Variables, though. Not hard to do, > though...Is this answering my question about application in shorewall-lite configurations perhaps? I guess ultimately it would be nice to generalize my above ssh-and-eval for an arbitrary list of <variable>=<the-result-of-some-command-on-gateway> but with optimizing the remote executions into a single round-trip. The above trick does work though it not entirely straightforward for the average user to figure out. Cheers, b. ------------------------------------------------------------------------------ Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d
ll.net/configuration_file_basics.htm#Variables.> > Ahhh. &<ifname>? Note that those first three variables in my list > above are interface names not their addresses. The .ipaddr ones are > addresses. Can I assume these runtime variables will work for > shorewall-lite installations?Yes.> >> Shorewall will detect the gateway addresses for you and store them in >> shell variables in the generated script, but so far I haven''t >> implemented gateway Runtime Address Variables, though. Not hard to do, >> though... > > Is this answering my question about application in shorewall-lite > configurations perhaps?Yes.> > I guess ultimately it would be nice to generalize my above ssh-and-eval > for an arbitrary list of <variable>=<the-result-of-some-command-on-gateway> > but with optimizing the remote executions into a single round-trip. > > The above trick does work though it not entirely straightforward for > the average user to figure out.You could run a script on the remote system that simply returned a list of assignment statements separated by semicolons or newlines that you could then just source locally. -Tom -- Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________ ------------------------------------------------------------------------------ Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d
On 12-02-21 05:14 PM, Tom Eastep wrote:>So I eliminate two of my "remote variables" using &<ifname> but since I have to fetch others anyway...> You could run a script on the remote system that simply returned a list > of assignment statements separated by semicolons or newlines that you > could then just source locally.Right which is effectively what I have done with: ssh root@gw "echo CGCOIF=\$(/sbin/uci -p /var/state get network.wan0.ifname) echo IGSIF=\$(/sbin/uci -p /var/state get network.wan1.ifname) echo PPPEIF=\$(/sbin/uci -p /var/state get network.pppoe_ether.device) echo CGCO_GATEWAY=\$(/sbin/uci -p /var/state get network.wan0.gateway) echo CGCO_ADDRESS=\$(/sbin/uci -p /var/state get network.wan0.ipaddr) echo IGS_GATEWAY=\$(/sbin/uci -p /var/state get network.wan1.gateway) echo IGS_ADDRESS=\$(/sbin/uci -p /var/state get network.wan1.ipaddr)" > foo eval $(cat foo) rm foo and indeed, I can replace the "eval $(cat foo)" with ". ./foo". Also, my remote address resolution provides the right level of abstraction for openwrt. wan0 and wan1 are consistent across routers whereas their real interface values (eth0.2 and pppoe-wan1) are implementation dependent. That said, ð0.2 and &pppoe-wan1 in my config files instead of the ${CGCO,IGS}_ADDRESS variables does have the desired effect. I do like their true run-time evaluation effect also. They would be much more flexible in dealing with a dynamic IP address change (i.e. assuming one''s router is configured to shorewall restore on interface changes). I wonder how easily (and still generically) find_first_interface_address_if_any() could be contorted to dive through openwrt''s wan* abstraction so that I could use &wan0 and &wan1. Would it make you wretch to see platform specific (i.e. openwrt) code in functions such as find_first_interface_address_if_any()? i.e.: find_first_interface_address_if_any() # $1 = interface { ifname="$1" if which uci >/dev/null; then ifname=$(/sbin/uci -p /var/state get network.$ifname.ifname) fi # # get the line of output containing the first IP address # addr=$(${IP:-ip} -f inet addr show $ifname 2> /dev/null | grep ''inet .* global'' | head -n1) # # Strip off the trailing VLSM mask (or the peer IP in case of a P-t-P link) # along with everything else on the line # [ -n "$addr" ] && echo $addr | sed ''s/\s*inet //;s/\/.*//;s/ peer.*//'' || echo 0.0.0.0 } And then the addition of some remote variable types like an the gateway for an interface and the ability to resolve the openwrt wan* interface abstraction elsewhere (like in rules) would elim- inate all of this remote execution stuff and make the resulting ruleset much more flexible. Cheers, b. ------------------------------------------------------------------------------ Virtualization & Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/