查看防火墙状态: systemctl status firewalld.service 如图 绿的running表示防火墙开启 执行关闭命令: systemctl stop firewalld.service 再次执行查看防火墙命令:systemctl status firewalld.service 如下图所示表示防火墙已经关闭 执行开机禁用防火墙自启命令 : systemctl disable firewalld.service 完成 ============================================================ 关于防火墙的其他命令: 启动:systemctl start firewalld.service 防火墙随系统开启启动 : systemctl enable firewalld.service from:https://blog.csdn.net/ViJayThresh/article/details/81284007
View Details我们一般想到测试连通性时第一考虑到的就是使用ping命令。 但是我们知道ping命令使用的是icmp协议,属于tcp/ip协议中的一个子协议,所以我们可以用ping命令来测试tcp的连通性还可以测试延迟情况。tcp相关协议了解可以参考:TCP/IP四层模型讲解【笔记整理通俗易懂版】 但是当我们需要测试udp连接的时候ping命令显然没有任何作用。 这时候我们可以用到netcat,这个命令被誉为是网络中的“瑞士军刀”,功能非常强大,测试udp只是其中的一个功能变通。 在安全领域nc常用来端口监听转发,用的比较多的也是windows版的NC,在运维中需要常用到linux上的nc,而一般linux会默认集成这个命令,根据不同系统命令不同,有的为“nc”,有的为“netcat”,大家可以根据实际系统尝试下。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 |
netcat 命令一览 [v1.10] connect to somewhere: netcat [-options] hostname port[s] [ports] … listen for inbound: netcat -l -p port [-options] [hostname] [port] options: -g gateway source-routing hop point[s], up to 8 -G num source-routing pointer: 4, 8, 12, … -h this cruft -i secs delay interval for lines sent, ports scanned -l listen mode, for inbound connects -n numeric-only IP addresses, no DNS -o file hex dump of traffic -p port local port number -r randomize local and remote ports -s addr local source address -t answer TELNET negotiation -u UDP mode -v verbose [use twice to be more verbose] -w secs timeout for connects and final net reads -z zero-I/O mode [used for scanning] port numbers can be individual or ranges: lo-hi [inclusive] 基本格式:nc [-options] hostname port[s] [ports] … nc -l -p port [options] [hostname] [port] -d 后台模式 -e prog 程序重定向,一旦连接,就执行 [危险!!] -g gateway source-routing hop point[s], up to 8 -G num source-routing pointer: 4, 8, 12, … -h 帮助信息 -i secs 延时的间隔 -l 监听模式,用于入站连接 -L 连接关闭后,仍然继续监听 -n 指定数字的IP地址,不能用hostname -o file 记录16进制的传输 -p port 本地端口号 -r 随机本地及远程端口 -s addr 本地源地址 -t 使用TELNET交互方式 -u UDP模式 -v 详细输出–用两个-v可得到更详细的内容 -w secs timeout的时间 -z 将输入输出关掉–用于扫描时 端口的表示方法可写为M-N的范围格式。 |
测试udp连接方法 a机器上运行: nc -ul 1080 或:netcat -ul -p 1080 #使用udp模式监听1080 端口 b机器上运行: nc -u x.x.x.x 1080 或:netcat -u x.x.x.x 1080 #使用udp模式向该ip的1080端口发送信息。 效果如图,在任意一边输入内容,另一边则会收到相应内容,以此就可以测试该端口的udp连接是否通常。 from:http://www.vuln.cn/2922
View Details备份源yum源 如果是国内下载的CentOS很可能国内YUM源已经设置好了。 备份/etc/yum.repos.d/下的*.repo文件。 在CentOS中配置使用网易和阿里的开源镜像 wget http://mirrors.aliyun.com/repo/Centos-7.repo wget http://mirrors.163.com/.help/CentOS7-Base-163.repo 或者手动下载repo文件并上传到/etc/yum.repos.d/目录 清除系统yum缓存并生成新的yum缓存 yum clean all # 清除系统所有的yum缓存 yum makecache # 生成yum缓存 安装epel源 yum list | grep epel-release yum install -y epel-release 再次清除系统yum缓存,并重新生成新的yum缓存 yum clean all yum makecache 查看系统可用的yum源和所有的yum源 yum repolist enabled yum repolist all 测试安装 yum install openssh-server from:cnblogs.com/cerana/p/11179728.html
View DetailsCI, CD AND CD 当我们在谈论现代的软件编译和发布流程的时候,经常会听到CI 和CD这样的缩写短语。CI很容易理解,就是持续集成。但是CD既可以指代码持续交付,也可理解为代码持续部署。CI和CD之间有很多相似的部分,但是也有很大的区别。这里我们将给大家介绍它们之间的区别和联系。 持续集成(CONTINUOUS INTEGRATION) 在持续集成环境中,开发人员将会频繁的提交代码到主干。这些新提交在最终合并到主线之前,都需要通过编译和自动化测试流进行验证。这样做是基于之前 持续集成过程中很重视自动化测试验证结果,以保障所有的提交在合并主线之后的质量问题,对可能出现的一些问题进行预警。 持续交付(CONTINUOUS DELIVERY) 持续交付就是讲我们的应用发布出去的过程。这个过程可以确保我们尽可能快的实现交付。这就意味着除了自动化测试,我们还需要有自动化的发布流,以及通过一个按键就可以随时随地实现应用的部署上线。 通过持续交付,您可以决定每天,每周,每两周发布一次,这完全可以根据自己的业务进行设置。 但是,如果您真的希望体验持续交付的优势,就需要先进行小批量发布,尽快部署到生产线,以便在出现问题时方便进行故障排除。 持续部署(CONTINUOUS DEPLOYMENT) 如果我们想更加深入一步的话,就是持续部署了。通过这个方式,任何修改通过了所有已有的工作流就会直接和客户见面。没有人为干预(没有一键部署按钮),只有当一个修改在工作流中构建失败才能阻止它部署到产品线。 持续部署是一个很优秀的方式,可以加速与客户的反馈循环,但是会给团队带来压力,因为不再有“发布日”了。开发人员可以专注于构建软件,他们看到他们的修改在他们完成工作后几分钟就上线了。基本上,当开发人员在主分支中合并一个提交时,这个分支将被构建、测试,如果一切顺利,则部署到生产环境中。 合并CI CD and CD? 当然,正如我所说,他们每部分都更加接近生产环境。你可以构建自己的持续集成环境,然后,一旦团队适应,你可以添加持续交付流,最后,可以添加持续部署流到整个工作流中。 举例CI, CD and CD 流水线 到底值不值这样做呢? 持续集成: 你需要具备哪些条件: 你的团队需要为每个新功能,代码改进,或者问题修复创建自动化测试用例。 你需要一个持续集成服务器,它可以监控代码提交情况,对每个新的提交进行自动化测试。 研发团队需要尽可能快的提交代码,至少每天一次提交。 你能获得什么呢?: 通过自动化测试可以提早拿到回归测试的结果,避免将一些问题提交到交付生产中 发布编译将会更加容易,因为合并之初已经将所有问题都规避了 减少工作问题切换,研发可以很快获得构建失败的消息,在开始下一个任务之前就可以很快解决。 测试成本大幅降低-你的CI服务器可以在几秒钟之内运行上百条测试。 你的QA团队花费在测试上面的时间会大幅缩短,将会更加侧重于质量文化的提升上面。 持续交付 需要具备什么条件?: 你需要有强大的持续集成组件和足够多的测试项可以满足你代码的需求 部署需要自动化。触发是手动的,但是部署一旦开始,就不能人为干预。 你的团队可能需要接受特性开关,没有完成的功能模块不会影响到线上产品。 你能收获什么?: 繁琐的部署工作没有了。你的团队不在需要花费几天的时间去准备一个发布。 你可以更快的进行交付,这样就加快了与客户之间的反馈环。 轻松应对小变更,加速迭代 持续部署 需要具备的条件: 研发团队测试理念比较完善。测试单元的健壮性直接决定你的交付质量。 你的文档和部署频率要保持一致。 特征标志成为发布重大变化过程的固有部分,以确保您可以与其他部门(支持,市场营销,公关…)协调。 可以获得什么?: 发布频率更快,因为你不需要停下来等待发布。每一处提交都会自动触发发布流。 在小批量发布的时候,风险降低了,发现问题也可以很轻松的修复。 客户每天都可以看到我们的持续改进和提升,而不是每个月或者每季度,或者每年。 如前所述,您可以采用持续集成,持续交付和持续部署。你怎么做取决于你的需求和你的业务情况。如果你刚刚开始一个项目,并且还没有客户,那么你就可以去创建这些工作流,最好是将这三个方面都实现,并且在你的项目迭代和需求增长中同时迭代它们。如果您已经有一个生产项目,那么您可以一步一步地分阶段去实现他们。 原文链接:http://www.ttlsa.com/news/ci-cd-cd/ from:https://www.cnblogs.com/soymilk2019/p/11445773.html
View Details