This shows you the differences between two versions of the page.
Next revision | Previous revision | ||
mission:log:2014:11:04:howto-setup-use-and-secure-a-local-spark-cloud-server [2014/11/04 10:21] – created chrono | mission:log:2014:11:04:howto-setup-use-and-secure-a-local-spark-cloud-server [2016/09/02 19:19] (current) – [HOWTO: Set up and secure a local Spark-Core Cloud] chrono | ||
---|---|---|---|
Line 9: | Line 9: | ||
//Do we really want to give out our complete sensory data (sys/ | //Do we really want to give out our complete sensory data (sys/ | ||
- | In the year 2014, in a post [[http:// | + | Some people may haven' |
+ | |||
+ | In the year 2014, in a post [[http:// | ||
The current software implementation (firmware- and server-side) has no concept of mesh/p2p or direct networking/ | The current software implementation (firmware- and server-side) has no concept of mesh/p2p or direct networking/ | ||
- | ==== Remote Spark-Cloud (AWS) Dataflow ==== | ||
{{: | {{: | ||
- | In this picture the blue lines represent the data flow of the Cores, the clients and the central server. All points marked with a red C show where the current implementation/ | + | In this picture the blue lines represent the data flow of the Cores, the clients and the central server. All points marked with a red C show where the current implementation/ |
+ | |||
+ | ===== ===== | ||
==== Local Spark-Cloud Server Dataflow ==== | ==== Local Spark-Cloud Server Dataflow ==== | ||
{{: | {{: | ||
- | When you follow this howto and secure your network access with a strong VPN you'll end up with something that looks like this image, where we effectively mitigate all these issues and take back control of our privacy & autonomy. | + | When you follow this howto and secure your network access with a strong VPN ([[https:// |
==== Key Features/ | ==== Key Features/ | ||
Line 35: | Line 39: | ||
^ OTA Update capability | Yes (But potentially insecure) | **Yes** | | ^ OTA Update capability | Yes (But potentially insecure) | **Yes** | | ||
^ Minimum Avg. Non-US Network Latency | >100ms | <10ms (LAN/WiFI) | | ^ Minimum Avg. Non-US Network Latency | >100ms | <10ms (LAN/WiFI) | | ||
- | |||
- | ===== ===== | ||
===== Installation ===== | ===== Installation ===== | ||
Line 65: | Line 67: | ||
At this time is wasn't possible yet to use a gentoo crossdev toolchain to compile | At this time is wasn't possible yet to use a gentoo crossdev toolchain to compile | ||
the firmware since it seems to require newlib-nano instead of the plain newlib gentoo | the firmware since it seems to require newlib-nano instead of the plain newlib gentoo | ||
- | would like to merge. | + | would like to merge. There wasn't enough time to hunt down this particular bug further so the |
- | + | ||
- | There wasn't enough time to hunt down this particular bug further so the | + | |
[[https:// | [[https:// | ||
Line 432: | Line 432: | ||
==== Compile firmware ==== | ==== Compile firmware ==== | ||
+ | |||
+ | === Default Firmware === | ||
< | < | ||
Line 466: | Line 468: | ||
</ | </ | ||
+ | === How do I create my own firmware? === | ||
+ | |||
+ | Basically you can just go into core-firmware/ | ||
+ | https:// | ||
==== OTA firmware update ==== | ==== OTA firmware update ==== | ||
- | It's possible to update the cores via Wifi, also called OTA (Over the Air) update. This is really | + | It's possible to update the cores via Wifi, also called OTA (Over the Air) update. This is a really |
< | < | ||
Line 505: | Line 511: | ||
* Compiling through the local cloud is on the road map but doesn' | * Compiling through the local cloud is on the road map but doesn' | ||
- | {{tag> | + | ==== Final Notes ==== |
+ | |||
+ | Depending on your state of mind, you might perceive this as paranoid but I can guarantee you, this has nothing to do with paranoia in any way, neither should this be perceived as a rant against spark-core or Amazon Web Services for that matter. Amazon Web Services is just the cloud provider used by spark.io and therefore got mentioned because it is so. What applies here applies to any other cloud platform one could choose, in general. From a business standpoint of view the decision to put things into a AWS seems absolutely valid to me. Of course, it's a little more expensive when you crunch the numbers but in return you get the full orchestra of AWS products, which in my experience do a good job working together, route53, elb, multiple geolocations and the whole shabang. And you can react very quickly to changes in demand of requests. In a perfect world, I would just use it as it is, because the setup isn't bad when we consider bandwidth not a problem. But when government agencies run haywire and military/ | ||
+ | |||
+ | {{tag> | ||
- | {{keywords> | + | {{keywords> |
~~DISCUSSION~~ | ~~DISCUSSION~~ | ||