[Commotion-dev] DR1 Quickstart

Seamus Tuohy s2e at opentechinstitute.org
Thu Feb 21 22:26:41 UTC 2013


Hey Ben,

See in-line comments below.

On 02/21/13 17:02, Ben West wrote:
> Hi Seamus,
>
> Thank you for writing such a thorough introduction on Quickstart, and
> thanks for all your hard work!
>

Happy to do it. Excited you read it.

> I'm working to get compile, working versions of Commotion DR1 /
> Quickstart on my end for ar71xx, atheros, and x86.  The latter
> platform is to permit simulation of nodes under VirtualBox/VMware.
>
> I see these repository URLs for the Quickstart tool:
> https://code.commotionwireless.net/projects/commotion-quick-start/repository
> https://code.commotionwireless.net/projects/commotion-quick-start/repository/show?rev=Version02
>
> Likewise this wiki page:
> https://code.commotionwireless.net/projects/commotion/wiki/QuickStart
>
> May I pepper you with assorted questions to help started quicker?
>
> 1. Does Quickstart depend on a specific revision of OpenWRT 12.09, or
> is whatever current revision of Attitude Adjustment so far OK?
>

Quickstart does not depend on a specific revision of OpenWRT. In fact 
all development and testing so far has been on a Attitude Adjustment 
node that does not run commotion at all. That being said, the current 
development version is almost entirely Dependant upon a testing function 
"commotionDaemon" for network information and setting configs on the 
node, which will eventually rely on the commotion daemon.


> 2. Does Quickstart still have any lingering dependencies on the
> commotionbase, luci-commotion, and luci-theme-commotion packages from
> the previous iteration of Commotion-OpenWRT?
> https://code.commotionwireless.net/projects/commotion-openwrt/repository/revisions/master/show/commotionfeed/commotionbase
> https://code.commotionwireless.net/projects/commotion-openwrt/repository/revisions/master/show/commotionfeed/luci-commotion
> https://code.commotionwireless.net/projects/commotion-openwrt/repository/revisions/master/show/commotionfeed/luci-theme-commotion
>

Not at the moment. We are currently removing its custom css and html in 
order to integrate it with the existing openwrt/luci html/css, and we 
are encountering a few problems. By the DR1 release we will be including 
a Quickstart specific set of css that will hopfully fix those problems 
and allow it to be used with any theme.

> 3. Likewise, is this collectd patch still needed?
> https://code.commotionwireless.net/projects/commotion-openwrt/repository/revisions/master/changes/patches/910-fix-out-of-bounds-index.patch
>

That is a whole other bag of worms that I don't know much about. Does 
anyone at Commotion HQ have any info on where collectD sits these days?

> 4. Is Quickstart intended to completely replace the meshconfig tool
> from the commotionbase package?

Quickstart is going to act as a new-user front end for the commotion 
daemon. So, I will contort this question for Josh, even though I beleive 
the answer will be yes. Josh, is "the commotion daemon" intended to 
completely replace the meshconfig tool from the commotionbase package?

>
> 5. Does Quickstart have any integration with the luci-splash package, yet?
>

I have a patch that I have yet to push to the repository which alters 
luci-splash to check for if quickstart has been set to "complete" and 
send the user to quickstart instead of the splash page on first boot. I 
have yet to make a patch that can be integrated into the package yet.

> 6. Finally, is the Version02 branch of Quickstart missing a Makefile?
> https://code.commotionwireless.net/projects/commotion-quick-start/repository/show?rev=Version02
>

It is missing a makefile. The makefile we were using in main should be 
able to be ported over since it merely copies all the files to the root 
directory and follows the path to their destinations. Andrew, I know you 
were working on that makefile. Is the current version in the main branch?

Finally,

The quickstart path is just finishing up review with our field team and 
will be redone based off of their critique and testing next week. At the 
end of that week, and the following week I will be working on 
documenting how communities and developers can make their own custom 
quickstart paths and functions.


s2e

> On Wed, Jan 23, 2013 at 10:24 AM, Seamus Tuohy
> <s2e at opentechinstitute.org> wrote:
>> Hello All,
>>
>> A quick update on the quickstart interface I am putting together for
>> developer-release one. The quickstart is a "on first boot" interface
>> that walks a user through customizing a node. This is intended to make
>> the initial setup of a node trivial for a new user. The current version
>> is missing the "one-button" setup. This should be added by the start of
>> next week.
>>
>> Version 001 of this quickstart was a "mostly" functional luci interface
>> which set the various configuration files on the node. Version 002 (the
>> current branch) only configures a nodeConf uci file which the upcoming
>> commotion daemon will use to configure the node at the conclusion of the
>> quickstart. As such, the current version will spend of its time
>> customizing uci files and making ubus calls to the commotion daemon to
>> fetch data.
>>
>> You can find the controlling code at
>> https://github.com/opentechinstitute/commotion-quick-start/tree/Version02 .
>> If you want to run it you will have to also grab the www directory from
>> the main branch at
>> https://github.com/opentechinstitute/commotion-quick-start which
>> contains the icons, etc.
>>
>> To put it on a router you simply copy the www folder into the main repo
>> directory (I will update the repo later today to include this) and then
>> scp it over to the routers root directory recursively. Once you have
>> done this you can go to IPADDRESS/cgi-bin/luci/QuickStart to start the
>> quickstart.
>>
>> The whole quickstart configuration can be found in
>> /etc/config/quickstart. This contains one "quickstart" section titled
>> "options" and multiple "page" sections. "options" holds the current and
>> last pages as well as a variable that controls weather the Quickstart
>> page is accessible. We disable it after completion because it allows
>> non-admin users to manipulate root level controls. A "page" contains
>> title that is either a number (this is how the controller iterates
>> through the quickstart) or a title that represents a side page.
>>
>> Each page has set of title information for its display. The page also
>> contains a "buttonText" item that specifies the text to be placed on any
>> button that links to it in the quickstart. A "page" can contain up to
>> two lists. The first list is modules. This list pulls content to
>> populate the main section. In our quickstart I have separated most pages
>> to include only one content section. There is nothing to stop someone
>> from customizing a page that holds multiple content items. Modules call
>> a <modulename>Renderer function in the controller when the page is
>> initially rendered, and a <modulename>Parser function when data from a
>> page is submitted. This means that if you want your own module you
>> simple add it to a page and create a renderer and a parser function.
>> Renderer's send initial variables to the page and parsers process user
>> input and send back errors that possible occur in the page.They stack
>> quite well. Lastly a "page" can contain a button list. Buttons call
>> <buttonname>Button functions when pressed that load up side pages.
>> noBack and noNext buttons remove the auto-generated last and next
>> buttons to allow for specialized pages.
>>
>> Lastly, when you get to the "this node will reset page" on version two
>> you will have to refresh your browser, as I have removed the actual
>> reset functionality from the quickstart to give more control to the
>> daemon. Refreshing the router here will take you to the next page.
>>
>> We still have a ways to go on "prettifying" the quickstart and updating
>> the language, and I have yet to implement the ubus calls or to upload
>> the patches I have made to take over the captive portal. But, please let
>> me know any feedback you may have. I will send the updated ux map and
>> language when it finishes our current round of feedback.
>>
>>
>> Thanks
>> s2e
>>
>>
>>
>> _______________________________________________
>> Commotion-dev mailing list
>> Commotion-dev at lists.chambana.net
>> https://lists.chambana.net/mailman/listinfo/commotion-dev
>>
>
>
>



More information about the Commotion-dev mailing list