# 一些想法

## 服务解耦

将core服务和web服务解耦合，让core服务不直接访问数据库。

优点：

- 简化core服务代码，不用直接访问数据库，C++访问数据库比python访问数据库代码复杂度更高。
- 通过web提供的rpc接口来访问数据库，限定数据库访问点仅通过web进行，容易做多类型的数据库的支持，比如从sqlite迁移到mysql。

缺点：

- 需要web提供特别的rpc接口，web服务和core服务的交互增加了。



目前的core服务中直接访问数据库，涉及到

- 生成会话ID，需要根据认证ID获取认证信息；
- 更新当前连接状态（连接、结束，出错等）；

可改为web查询数据库，然后将数据传递给core服务。_但是这里有一个潜在的安全漏洞：认证信息中包含的私密信息会在网络上传播了。_解决的办法是：如果core和web在同一台主机上，没有漏洞，如果不在同一台主机上，core需要配置一个密钥放在配置文件中，web配置时需要输入此密钥才能与指定的core连接，且传输隐秘数据时使用此密钥进行加密。




## 会话ID

关于会话ID的有效期，现有版本是设置一个引用计数，对于rdp可以使用两次，而ssh只能使用一次，原因是rdp连接时，通常第一次连接用于协商子协议，然后会断开，并立即重连并使用确定好的子协议进行后续操作。

改进的方法是：为一个会话ID设置一个标志及一个最后活动时间，会话ID刚生成时标志为false，调用take_session()时设置为true，当连接断开时（或者未能连接成功时）重置为false并更新最后活动时间为当前时间。标志为true时不允许重复take_session()，每次调用take_session()时检查标志为false的回话ID的最后活动时间，如果超过5秒未活动，则删除此会话ID。

这样做可以适配各种连接方式。



## 用户体验

纯净安装：基本上就是复制文件，没有别的操作了。安装完成后，提示teleport的运维管理WEB服务的URL，让用户进行访问。

### 纯净安装

**尽可能使用WEB-UI进行配置**

完全新安装的服务端，仅启动了web服务（但是web服务的监听IP和端口如何设定？监听IP可以设置为在0.0.0.0上监听，但是端口如何设定？）。因此，端口必须用配置文件的方式进行设定。其次，对于log级别、log输出路径等设定，涉及到系统的调试（可能web服务根本就启动不了，所以无法通过web界面进行设置），因此也需要通过配置文件的方式设定。

core与web之间通过JSON-RPC方式进行通讯，core并不直接操作数据库，而是转由web提供RPC接口进行操作。web服务并不直接读取core的配置，而是通过core提供的RPC接口获取或修改其配置。

core服务提供RPC接口，能够获取其内部状态，例如当前连接数、网络IO负载等等。

可以通过RPC接口停止或重启core和web服务。

web服务启动后，访问登录页面，但是如果缺少配置数据表，就跳转到配置页面。

- 设定所用数据库（可选本地sqlite，或者MySQL，如果是MySQL，需要给出root权限，或者指定有权限访问的数据库和用户名及密码，以及teleport相关表的前缀，默认为“tp_”），注意，这些信息必须存放在配置文件中，因此配置文件需要支持写入操作；
- 创建配置数据库（包括用户表、配置表等）;
- 设定管理员密码（管理员用户名固定为admin）；
- 设置core服务的地址和端口（默认是本机127.0.0.1，端口包括RPC端口、SSH/RDP/Telnet端口等）；
- 设定core服务存放日志回放记录文件的目录地址；
- core和web的配置信息均存放在.ini配置文件中，方便特定情况下用户手工编辑；


安装时需要用户选择安装core还是web，还是二者皆安装。

安装完成后，core服务和web服务均会启动，在第一次启动时，需要创建config数据库，里面是一堆空表，只有用户表里面有一个管理员账号admin，安装部署人员可以使用此账号登陆系统。

需要增强服务的自检功能，例如端口已经被占用等，需要在日志中给出明确的错误信息。另外，考虑到将来core服务可能部署到多个主机上以提升承载能力，所以web需要访问core的数据时（包括取日志回放文件数据等），均使用RPC接口进行。

第一次登陆系统，会自动跳转到配置向导界面，让用户一步一步进行服务器配置。



- ​