Hi. > let's start with the example of /etc/config/dhcp from my build for a > [...] the last two types of which have "names", so i can use "uci > show" to show either all of uci dhcp configuration with: > > # uci show dhcp > > or i can be pickier and more specific. first, i can show > configuration based specifically on the *name* of a dhcp config > option, such as: > > root@OpenWrt:/# uci show dhcp.lan dhcp.lan=dhcp > dhcp.lan.interface=lan dhcp.lan.start=100 dhcp.lan.limit=150 > dhcp.lan.leasetime=12h dhcp.lan.dhcpv6=server dhcp.lan.ra=server > root@OpenWrt:/#
Yes. > so given that this format uses a specific *name* from the uci config > file, it should be obvious that no two config stanzas in a uci > config file can have the same name, even if they are of different > types, correct? Yes > (i tried that and i got weird behaviour -- only the second instance > of the name appeared in the output of "uci show", but that config > option included the info from *both* stanzas. regardless, it seems > pretty clear that you're not supposed to do that. should that > generate an error?) Likely yes, but so far the uci implementaiton is quite forgiving in some cases. > > the second question is what the first line of output above means: > > dhcp.lan=dhcp It means: the section called "lan" in the config file (or package) "dhcp" is of type "dhcp". > next, regarding config types that have no associated name, as in: > > config dnsmasq option ... etc etc ... > > as i read it, if a config line has no name, you *must* refer to it > using the array reference syntax, as in: > > # uci show dhcp.@dnsmasq[0] Yes. > if a config type *has* a name, then i could (if i wanted) use either > form, as in either one of these would work: > > # uci show dhcp.lan # uci show dhcp.dhcp[0] > > and i should get *exactly* the same output in either case, yes? Yes. > (obviously based on the ordering in the config file.) > > next question based on the same file and the command: > > root@OpenWrt:/# uci show dhcp.@dnsmasq[0] [...] root@OpenWrt:/# > > ok, where is that "cfg02411c" component coming from? It is autogenerated by libuci, those dynamic identifiers are provided so that it is possible to refer to anonymous sections in a somewhat stable way. The hash is based on the current config file layout and changes after a uci commit (if something changed in the file). > i'm sure it's dynamically generated based on something, but i have no > idea what, and the wiki page doesn't appear to explain it. > > finally, some observations about the wiki page. first, the section on > Command Line Utility: > > http://wiki.openwrt.org/doc/uci#command.line.utility > > uses the example of "timeserver.@timeserver[0]", but that appears to > be obsolete based on the very link from that same wiki page: > > http://wiki.openwrt.org/doc/uci/timeserver > > a better example to show indices would probably be firewall rules: > > # uci show firewall.@rule[0] # uci show firewall.@rule[1] ... etc etc > ... > > another oddity from the wiki page is the example for how to export an > entire configuration: > > http://wiki.openwrt.org/doc/uci#export.an.entire.configuration > > that uses the example of the "httpd" service, but there is no such > thing on my system -- perhaps that could be replaced with a service > that's far more likely to be on someone's system, something as > simple as, say, dropbear. > > and speaking of /etc/config/dropbear, this has the potential to be > totally confusing if one examines it for the first time. here's the > config file for dropbear: > > config dropbear option PasswordAuth 'on' option RootPasswordAuth > 'on' option Port '22' # option BannerFile '/etc/banner' > > and here's what you get if you show: > > # uci show dropbear dropbear.@dropbear[0]=dropbear > dropbear.@dropbear[0].PasswordAuth=on > dropbear.@dropbear[0].RootPasswordAuth=on > dropbear.@dropbear[0].Port=22 # > > that first line, where the word "dropbear" appears three times, > thoroughly threw me until i pulled it apart and realized what each > part meant. It would probably be less confusing if the the section type would be "instance" instead of "dropear", because that's what it actually represents. > one more thing ... i notice the file /etc/config/ucitrack which is > part of the luci-base package, but this wiki page: > > http://wiki.openwrt.org/inbox/procd-init-scripts > > suggests that feature is obsolete. should that file be removed from > the package? or is it still doing something? It is still doing something. LuCI does not use all of the newer procd facilities yet. HTH, Jow _______________________________________________ openwrt-users mailing list [email protected] https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-users
