一、使用场景服务器端一般是类Unix系统，多使用Linux的CentOS。无论使用什么样的类Unix系统，服务器端都不会安装窗口插件，而是使用命令和脚本来完成一切。在这样的场景下，登录、执行命令、执行脚本、查看服务运行状态、查看服务产生的日志、查看配置等基本操作会被频繁使用，但是在命令行模式。比如查看一个服务是否正在运行，需要先登录服务器，然后查看进程中是否存在该服务的进程。在这里我们将介绍如何通过web执行服务器端动作，简化操作，提高工作效率。2.选择实现方式在设计这个实现的时候，我们比较了两种实现方式：1.通过java的Runtime类来执行命令和脚本。需要创建和维护项目，方便在项目中控制接口权限，但添加脚本和操作时需要修改项目，重新发布项目。2、使用CGI接口，配置方便，使用灵活。直接在服务器上写脚本，通过接口的公共路径就可以访问和使用，但是无法控制接口的访问权限。由于这个接口是在测试系统中使用的，方便灵活是首选，权限问题不是那么重要。CGI是一项非常古老的技术。后来随着javaservlet技术的兴起，CGI在生产场景中已经没有立足之地，只是在测试环境中使用它的灵活性和方便性。3、配置CGI接口3.1．打开tomcat的CGI配置。tomcat、apache等中间件内置了CGI功能，但默认是不启用的。这里以tomcat为例，配置CGI接口。修改点1.在Tomcat的conf/web.xml中放出以下两段CGI相关的内容。第一段：cgiorg.apache.catalina.servlets.CGIServletcgiPathPrefixWEB-INF/cgi5第二段:cgi/cgi-bin/*修改点2.给标签添加属性在Tomcat的conf/context.xml中。在标签中添加属性privileged="true"，因为Tomcat默认不允许web应用使用容器中的Servlet，web应用只能使用自己项目的Servlet。3.2.创建一个空项目并定义要执行的脚本。tomcat中开启CGI配置时，不修改文件路径和访问路径，空项目按照默认路径创建目录即可。在tomcat路径下直接执行mkdir-pwebapps/test/WEB-INF/cgi创建CGI工程目录。然后在webapps/test/WEB-INF/cgi路径下创建一个文件a，a的内容如下：web终端执行服务器的命令和脚本是类Unix系统，多用linux的CentOS.无论使用什么样的类Unix系统，服务器都不会安装窗口插件，而是使用命令和脚本来完成一切。在这样的场景下，登录，执行命令，执行脚本，查看服务的运行状态，查看服务产生的日志，查看配置。这些基本操作是经常用到的，但是在命令行方式下操作这些操作是非常繁琐的。比如查看一个服务是否正在运行，需要先登录服务器，然后查看进程中是否存在该服务的进程。在这里我们将介绍如何通过web执行服务器端动作，简化操作，提高工作效率。2.选择实现方式在设计这个实现的时候，我们比较了两种实现方式：1.通过java的Runtime类来执行命令和脚本。需要创建和维护项目，方便在项目中控制接口权限，但添加脚本和操作时需要修改项目，重新发布项目。2、使用CGI接口，配置方便，使用灵活。直接在服务器上写脚本，通过接口的公共路径就可以访问和使用，但是无法控制接口的访问权限。由于这个接口是在测试系统中使用的，方便灵活是首选，权限问题不是那么重要。CGI是一项非常古老的技术。后来随着javaservlet技术的兴起，CGI在生产场景中已经没有立足之地，只是在测试环境中使用它的灵活性和方便性。3、配置CGI接口3.1．打开tomcat的CGI配置。tomcat、apache等中间件内置了CGI功能，但默认是不启用的。这里以tomcat为例，配置CGI接口。修改点1.在Tomcat的conf/web.xml中放出以下两段CGI相关的内容。第一段：cgiorg.apache.catalina.servlets.CGIServletcgiPathPrefixWEB-INF/cgi5第二段:cgi/cgi-bin/*修改点2.给标签添加属性在Tomcat的conf/context.xml中。在标签中添加属性privileged="true"，因为Tomcat默认不允许web应用使用容器中的Servlet，web应用只能使用自己项目的Servlet。3.2.创建一个空项目并定义要执行的脚本。tomcat中开启CGI配置时，不修改文件路径和访问路径，空项目按照默认路径创建目录即可。在tomcat路径下直接执行mkdir-pwebapps/test/WEB-INF/cgi创建CGI工程目录。然后在webapps/test/WEB-INF/cgi路径下创建一个文件a，a的内容如下#!/bin/bashecho"Content-Type:text/plain"echo#以上内容为CGI脚本格式并且必须存在#below内容是自定义要执行的动作echo"Todayis:"date3.3,接口访问路径执行一个http://localhost:8080/test/cgi-bin/a4,参数化cgi界面4.1，这里的实际场景当时已经配置好了CGI界面。虽然功能已经完成，但还是不符合实际的使用场景。当前接口只对应一个功能，不能复用。为满足实际使用场景，需要参数化。传递的参数可以是脚本名、机器ip、服务名、进程名等，使接口的通用性大大增加。4.2.初步解决如果要对脚本进行参数化，必须解决server端传递的参数和url传递的参数不一致的问题。url中使用“&”和“参数名=参数值”的参数传递形式，而服务器端使用空格+直接参数值的形式。在执行脚本之前，需要先传递一个转换脚本。转换脚本需要先对url进行切割，分成几部分，取出参数和要执行的a脚本，然后重新组合在一起执行。那么就变成了url，需要先访问转换成Script，实际的ascript和参数作为参数传入，处理流程变得复杂。4.3.网上的一个神脚本，直到最后在网上找到了完美的解决方案。我找到了一个名为“proccgi.sh”的脚本，它是FrankPilhofer在1995年编写的，如脚本中的注释所述。我原封不动的拿来用了（脚本下载：链接：https://pan.baidu.com/s/1oZbN13Eog3OKld93f6hEkw?pwd=chen，提取码：chen）。这个剧本设计得很巧妙。它在传输中间不对url进行处理再进行拼接，而是直接将url传入执行的a脚本中，然后利用a脚本中的“eval”命令的二次扫描功能扫描出需要的参数，然后把参数放在一个专门的key-value环境变量中，使用的时候直接从环境变量中取。例如：url:http://localhost:8080/test/cgi-bin/a?ip=115&servername=customer&thread=aabbcca脚本修改如下：#!/bin/basheval`proccgi.sh$*`#解析parameterecho"Content-Type:text/plain"echo#############echo$FORM_ipecho$FORM_servernameecho$FORM_thread5、网页处理有以下几种情况：1、如果没有样式要求对于页面显示，接口链接直接打开一个新的浏览器窗口，接口返回的数据会直接显示在浏览器中。2.如果页面有格式，需要通过ajax触发接口，接口的返回值通过innerHTML直接填充到页面的显示区域。3、对于那些耗时较长的任务，当接口还没有返回值时，页面停留在loading状态。这个时候无法从页面判断是否存在未知问题。这时候可以在页面放一张等待的图片，定义一个flag，给它放一个默认值，然后js轮播训练判断这个flag的值。当接口的shell处理完成，接口返回时，必须改变标志的值。轮训发现变化后，可以替换接口返回的内容，等待页面显示所有图片。6.结论在定义环境时，尽量把它定义得一般和规则。这样可以维护一些常用的脚本，通过传入可变参数来执行动作。让服务器中的环境维护和定位问题不再繁琐。
