目前看，LoRa是一个在IOT方案领域替换GSM的初步可行方案，主要从距离和功耗两个考虑方面。
介绍如下：
http://www.lora-alliance.org/What-Is-LoRa/Technology
http://www.rfwireless-world.com/Terminology/LoRa-technology-basics.html
http://www.rfwireless-world.com/Terminology/IoT-wireless-technologies.html
芯片厂商目前也已经有了量产的芯片可供评估，成本在1-2个美金。
http://www.microchip.com/design-centers/wireless-connectivity/embedded-wireless/lora-technology
http://www.semtech.com/wireless-rf/lora.html
在很多安全服务中，我们都需要签名的安全证书。
注意 如果不生成证书，后面配置部分的配置中用 pubkey 认证的 conn 都不能用，甚至不能保留在配置中。
每一个完整的 ssl 证书都有一个公钥和一个私钥，它们可以在一起也可以分开放（当然如果你要在网络上传输，肯定只能用公钥）。公钥是在网络上传输的，而私钥是藏好用来和接收到的公钥配对的（因此私钥里也有整个公钥，用来配对）。
生成一个私钥：
ipsec pki --gen --outform pem > ca.pem
没什么好解释的，--outform 一共有三个格式可选，但是另外两个是 der 和 pgp...
基于这个私钥自己签一个 CA 证书：
ipsec pki --self --in ca.pem --dn "C=CN, O=strongSwan, CN=strongSwan CA" --ca --outform pem > ca.cert.pem
这里 --self 表示自签证书，--in 是输入的私钥，--dn 是判别名，--ca 表示生成 CA，其它同上。这里需要解释下判别名：
C 表示国家名，同样还有 ST 州/省名，L 地区名，STREET（全大写） 街道名。
O 表示组织名。
CN 为通用名。
具体见微软的文档：Distinguished Names
同样生成私钥：
ipsec pki --gen --outform pem > server.pem
用我们刚才自签的 CA 证书给自己发一个服务器证书：
ipsec pki --pub --in server.pem | ipsec pki --issue --cacert ca.cert.pem \
--cakey ca.pem --dn "C=CN, O=strongSwan, CN=forum.suse.org.cn" \
--san="forum.suse.org.cn" --flag serverAuth --flag ikeIntermediate \
--outform pem > server.cert.pem
这条命令的意思解释下：
ipsec pki --pub --in server.pem
是从我们刚生成的私钥里把公钥提取出来，然后用公钥去参与后面的服务器证书签发（这个是 VPN 连接时候要用的，你不想把私钥也给它吧？那样跟没签证书一样...）。
--issue, --cacert 和 --cakey 就是表明要用刚才自签的 CA 证书来签这个服务器证书。
--dn, --san，--flag 是一些客户端方面的特殊要求：
iOS 客户端要求 CN 也就是通用名必须是你的服务器的 URL 或 IP 地址;
Windows 7 不但要求了上面，还要求必须显式说明这个服务器证书的用途（用于与服务器进行认证），--flag serverAuth;
非 iOS 的 Mac OS X 要求了“IP 安全网络密钥互换居间（IP Security IKE Intermediate）”这种增强型密钥用法（EKU），--flag ikdeIntermediate;
Android 和 iOS 都要求服务器别名（serverAltName）就是服务器的 URL 或 IP 地址，--san。
依然是生成私钥：
ipsec pki --gen --outform pem > client.pem
然后用刚才自签的 CA 证书来签客户端证书：
ipsec pki --pub --in client.pem | ipsec pki --issue --cacert caCert.pem \
--cakey caKey.pem --dn "C=CN, O=strongSwan, CN=client" \
--outform pem > client.cert.pem
这时命令行会提示你输入两遍密码，这个就是你的客户端证书密码。
看懂了服务器的，客户端的也就不难理解了。除了没有那一堆特殊要求别的都一样。
客户端证书可以每个客户端签一个，也可以让它们公用一个。是否多签看用途，一般用于区分设备（计费是不用这样的，是用账户来区分的）。
你可能还想生成一个可以直接导入的 pkcs12 证书（用于手机，诺基亚没这东西还不行）：
openssl pkcs12 -export -inkey client.pem -in client.cert.pem -name "client" \
-certfile ca.cert.pem -caname "strongSwan CA" -out client.cert.p12
cp -r ca.cert.pem /etc/ipsec.d/cacerts/
cp -r server.cert.pem /etc/ipsec.d/certs/
cp -r server.pem /etc/ipsec.d/private/
cp -r client.cert.pem /etc/ipsec.d/certs/
cp -r client.pem /etc/ipsec.d/private/
CA 证书、客户证书（两个）和 .p12 证书用 FTP 复制出来给客户端用。有几种 Android 配置还需要服务器证书（server.cert.pem）。
在很多的docker的说明中，我们都能看到“layer”的身影，那么到底什么是”layer“？
参见http://docker-doc.readthedocs.org/en/latest/terms/layer.html中的说明：
When Docker mounts the rootfs, it starts read-only, as in a traditional Linux boot, but then, instead of changing the file system to read-write mode, it takes advantage of a union mount to add a read-write file system over the read-only file system. In fact there may be multiple read-only file systems stacked on top of each other. We think of each one of these file systems as a layer.
简单翻译如下：
当docker加载rootfs时，和传统的linux系统中一样，它是只读的，但是随后，不是将当前文件系统变成可读写，而是利用union mount添加一个可读写的文件系统在当前的只读系统上。实际上将会有很多的只读文件系统叠加在彼此之上。我们将这里的每一层文件系统称之为"layer"。
参考阅读：
https://docs.docker.com/engine/understanding-docker/#how-does-a-docker-image-work
https://www.ctl.io/developers/blog/post/caching-docker-images/
docker好文，短小精炼。水平有限，请不吝指教。
http://developerblog.redhat.com/2016/02/24/10-things-to-avoid-in-docker-containers/
ps：为了保证一致性，文中的容器即container，是docker container的简称。
最终，你选择了容器技术并且发现它解决了很多问题并且有着很多的优点：
1. 第一：不可变更－因为OS，库文件，配置参数，文件夹，应用等都包含在容器中，所以只要你保证你生产环境中使用的是和QA一样的镜像，那么它的行为就一定是一样的。
2. 第二：轻量级－容器的内存占用很小。不需要成百上千MB，只需要为主进程分配数十MB的内存就可以。
3. 第三：运行超快－启动容器就像开启一个单进程，不需要几分钟，只要短短几秒就可以完成。
但是很多用户仍然将容器仅仅当作虚拟机使用，而另外的人仅仅知道：容器是一次性的，而忘记了它还有其他很多优点。
关于容器的口头禅：容器是短暂的。
这一特性“本身”迫使用户去改变他们关于如何处理和管理容器的想法。而我也将阐述为了获取最佳性能而需要避免做的事情：
1）不要在容器中存储数据－容器可以被停止，销毁，或者替换。一个1.0版的应用应该很容易的就被替换成1.1而不应有任何影响和数据丢失。基于这个原因，如果你需要存储数据，把它存储在宿主的硬盘上，但是要避免两个容器同时写数据，造成数据异常，确保你的应用是将数据写到共享的数据路径的。
2）不要把你的应用分成两部分－因为很多人把容器当虚拟机使用，所以他们的做法是部署应用到已经在运行的容器中。也许开发中确实如此，因为你要不间断的部署和调试，但是在正式的QA和生产环节流程中，你的应用应该是容器的一部分。请记住：容器应该是不可变更的。
3）不要创建过大的镜像－镜像过大不易分发。请确认你只包含了必要的文件和库，不要包含不必要的开发包，也不要在容器运行时运行"updates"(yum update)。
4）不要使用单层的镜像－合理的使用分层的文件系统，OS是一层，安全和用户定义组件是一层，库文件是一层，配置文件是一层，最后是你的应用独立为一层。这样将使镜像的重建和管理变的容易同时易于分发。
译者：这里的层指得是"layer"，关于什么是"layer"，请参见docker中的”layers”指的是什么东西
5）不要从运行的容器中创建镜像－换个说法，不要用"docker commit"去创建镜像。这样创建的镜像不可准确重建和版本化管理，应该彻底避免。要使用Dockerfile或者其他可重建的S2I(source to image)方式。
6）不要只使用最新标签的版本－最新的标签就想maven中的"SNAPSHOT"。应该使用特定的标签的版本。我想你应该不想在你2个月后重新编译镜像时，收到惊奇，发现你的应用不能运行是因为顶层的layer使用了新的版本，没有向前兼容或者最新的版本是有问题的。当部署容器到生产环境时也要避免使用新的版本。
7）不要在一个容器中运行多于1个的进程－容积最好是运行单一的进程（http守护进程，应用服务器，数据库）。当你运行多个时，你将会遇到要单独管理，处理日志，以及更新的困难。
8）不要存储身份数据到镜像中，尽量使用环境变量－你应该不希望直接存储你的用户名，密码到镜像中。所以使用容器外的环境变量去获取相关的信息，一个较好的例子是postres image。
9）请使用非root权限运行进程－“docker默认是以root身份运行的。当docker运行时，将会获取到默认的安全选项。而被他人获取root是危险的，并且也不是所有环境都支持的。你的镜像应该使用 USER 指令去指定一个非root用户来运行容器”（摘自Guidance for Docker image Authors）。
10）不要依赖特定的IP－每一个容器都有它们自己的内部ip，而且这个ip可能在开启或者停止时变化。假如你的应用或者微服务需要和其他的容器通讯，请使用名称或者环境变量去传递相关的信息。
更多关于容器的信息请参见：http://developers.redhat.com/containers/