Chápu přínos té konfigurační vrstvy např. pro webové rozhraní. Nicméně při konfiguraci přes terminál jsem musel u některých softů UCI ve startovacích skriptech vyhodit (změnou cesty ke konfiguráku), protože shellovské skripty konvertující jednotné příkazy UCI na konkrétní konfigurační soubory programů nepodporovaly celou šíři a možné kombinace finálních parametrů. Navíc se liší názvy parametrů v UCI a u softu, takže manuálové stránky a ukázky konfigurace se daly použít jen po podrobném prostudování bludiště konverzních skriptů, co se jak převádí. Konkrétně např. dnsmasq mi nešlo přes UCI detailně nastavit, zatímco na webu jsou ukázky hotových a funkčních konfiguráků.
souhlasim, tenhle podivny system konfigurace me absolutne irituje. hlavne kvuli tomu ze vetsinou nepomaha originalni dokumentace k danemu kusu software.
Naštěstí obvykle stačí změnit cestu ke konfiguráku v /etc/init.d/sluzba z nejakeho /var/tmp/sluba.conf generovaného uci na fixní /etc/sluzba.conf. Ale je to opruz.
Rresne toto je hlavny problem UCI/OPENWRT. Snazi sa byt univerzalne ale nefunguje to, rozhodne nieje univerzalne ako moznosti samotneho OS. Ja to riesim tak ze mi modifikovane uci nahodi zakladnu konfiguraciu systemu (to od openwrt nevie ani aliasy a neriesi ani race conditions sposobene hotplugovym systemom…)a zvysnu konfiguraciu riesim externym konfiguracnym systemom (pracovny nazov spyder) ktory cez definovane rozhranie nahra potrebnu konfiguraciu do boxu v nativnej forme, tzn iptabulky/tc v dump formate atd. Tymto smerom by mal ist aj vyvoj openwrt tzn mat tzv tazky konfiguracny server ktory dokaze v realnom case generovat nativnu konfiguraciu. To je uplne mimo schopnosti samostaneho vacsinou jednouceloveho a na tento ucel nekonecne pomaleho zariadenia kde sa openwrt OS prevadzkuje.
