事情是这样的
出生于2009年的高贵的CentOS7.9已经要停止维护了
大人,食大便了
然而作为牛马实习生的我,用惯了5.x和6.x内核的Debian和Ubuntu,但ld只会用CentOS7.9(他在口嗨),还是内核3.10那种,于是乎开始恶补相关知识
但是呢,在网上很多很多很多博客的源、教程都已经过时了,在折腾一天之后终于忍不住了,不行!我一定要拿小本本记下来,不然我下次还得找!
事情是这样的
出生于2009年的高贵的CentOS7.9已经要停止维护了
大人,食大便了
然而作为牛马实习生的我,用惯了5.x和6.x内核的Debian和Ubuntu,但ld只会用CentOS7.9(他在口嗨),还是内核3.10那种,于是乎开始恶补相关知识
但是呢,在网上很多很多很多博客的源、教程都已经过时了,在折腾一天之后终于忍不住了,不行!我一定要拿小本本记下来,不然我下次还得找!
ELK 是 Elasticsearch、Logstash 和 Kibana 三个开源项目的首字母缩写,通常一起使用构成一个强大的日志管理和分析解决方案。下面将介绍它们各自的功能和ELK的优势:
– Elasticsearch:
是一个基于 Lucene 构建的高性能搜索引擎。
主要用于全文搜索和分析。
具有高伸缩性,可以水平扩展,并且能够快速处理大量数据。
– Logstash:
是一个强大的数据处理管道工具。
能够动态地收集、处理和转发日志和事件数据。
支持多种输入、过滤、编解码和输出插件。
– Kibana:
是一个为 Elasticsearch 提供数据可视化的 Web 应用程序。
允许用户创建和分享图表、地图、表格等,以图形化展示 Elasticsearch 索引中的数据。
通常用于日志和时间序列分析、应用监控等。
ELK 相比于 MySQL 的优势主要在以下几点:
1. 文本搜索处理能力: Elasticsearch 提供全文搜索功能,对于复杂的文本查询和大数据集的文本处理有明显优势。
2. 数据处理及实时分析: Logstash 能够实时处理和分析数据,适用于日志管理和复杂事件处理,而 MySQL 更多用于结构化数据存储。
3. 数据可视化: Kibana 提供了丰富的数据可视化选择,能够以图表、地图等形式直接在 Web 界面上展示数据分析结果。
4. 扩展性与高可用性: 集群/分你手机友好
5. 大数据兼容性: 对日志和非结构化数据友好
由于网上都是Docker/二进制文件分开部署,让我非常烦躁,怎么这么好的东西就不能一次搞完呢!
PS:这样不方便集群管理,不过本地跑还是很爽的🤣
ELK不支持使用latest部署,我们需要自己指定版本
在测试中8.x版本无法正常部署,建议使用7.x
version: '3'
services:
elasticsearch:
image: elasticsearch:7.17.19
environment:
- ES_JAVA_OPTS=-Xms512m -Xmx512m
- discovery.type=single-node
- cluster.name=es-docker-cluster
- http.host=0.0.0.0
volumes:
- ./es-data:/usr/share/elasticsearch/data
- ./es-plugins:/usr/share/elasticsearch/plugins
- ./es-logs:/usr/share/elasticsearch/logs
networks:
- elk-net
ports:
- "9200:9200"
- "9300:9300"
privileged: true
kibana:
image: kibana:7.17.19
environment:
- ELASTICSEARCH_HOSTS=http://elasticsearch:9200
- I18N_LOCALE=zh-CN
networks:
- elk-net
ports:
- "5601:5601"
depends_on:
- elasticsearch
logstash:
image: logstash:7.17.19
networks:
- elk-net
ports:
- "5044:5044"
- "9600:9600"
depends_on:
- elasticsearch
networks:
elk-net:
driver: bridge
如果配置正常的话会自动连接配置,等一会访问 http://127.0.0.1:5601 就行
docker log查看kibana的配置code(实际上并不需要,自动配置失败的话,只要访问那个端口就行)
http://0.0.0.0:5601/?code=xxxxxx
替换 http://0.0.0.0:5601 为 http://127.0.0.1:5601 访问Kibana的管理界面
在这个界面可能需要输入token,token可以docker log查看elasticsearch控制台
如果不行的话可以尝试
docker exec <DOKCER_ID> bin/elasticsearch-create-enrollment-token --scope kibana
# 返回如下
WARNING: Owner of file [/usr/share/elasticsearch/config/users] used to be [root], but now is [elasticsearch]
WARNING: Owner of file [/usr/share/elasticsearch/config/users_roles] used to be [root], but now is [elasticsearch]
<一串JWT密钥>
左边三道杠 -> Management(管理) -> 堆栈监测
可以看到ELK都正常工作
左边三道杠 -> Management(管理) -> Stack Management
logstash
TODO:等我nas配起来后去写这个,不然还没有地方存数据
总所周知Web手除了Web啥都学
最近开了个新坑,在学Rust和OS,就在想为什么不结合起来rCore!
实验使用的文档为中山大学YatSenOS操作系统时间课程v2
引用实验文档中的实验说明
本文档提供了一套基于 Rust、面向 UEFI 和 x86_64 的操作系统课程实验方案。
本实验设计期望基于低汇编、避免重复造轮子的宗旨,利用 Rust 语言优秀的包管理和底层支持,借助现有的优秀工程化底层封装,为学生提供一个低负担、现代、面向高级语言的操作系统实验指南。
废话少说,直接开始干活
为了不让自己在离开的时候后悔,不留遗憾的退场多好呢
从19年起,我一直相信着这句话,直到如今,
我所做的事情,仅仅只是不让自己后悔罢了。
这一年里,我从一个烂摊子去了另一个烂摊子,熟悉的流程,熟悉的那批人,
再一步一步将这个小团队建设起来,招募了一批新成员,送走了一批老队员。
也参加了不少比赛,取得了一些名次,还是感觉技不如人,仍需努力。
同时幸运的得到了份实习,去了不少地方,接触到了几个有趣的项目。
……
一年的时光就这样流逝了。
值得吗,不值得。
我燃尽了一切,舍弃了不少东西,却只换得满身伤痕。
但倘若给我机会再来一次,我还会毅然决然做出选择。
我做到了自己该做的,纵使遭众人唾弃,我无怨无悔。
首先我们要搞清楚一个问题,Wireguard和OpenVPN的区别在哪里
OpenVPN基于TCP或UDP协议,由SSL/TLS实现身份加密,没有Wireguard效率高,但是支持多种管理方式
在实际使用上,TCP和UDP也有较大区别
UDP:UDP可以提供更快的速度和较低的延迟,适用于实时应用程序和视频流等对延迟敏感的情况。UDP模式还可以避免TCP拥塞控制的限制,适用于高带宽环境
UDP在实际使用上可能会被QOS限速,但是在长距离、高延迟的VPN环境中还是可以发挥不错的效果,不容易出现TCP经常断连的情况。
在某个实际应用场景中,我需要将在B地不同地区访问位于A地的局域网,A地与B地物理相隔较远并且网络条件较差,但是对业务实时性没有太多要求,并且A地存在NAT
全部走OpenVPN,对A-B两地互联的机器使用UDP协议,确保可以通讯
B地对B地其他地区使用TCP协议,确保连接稳定性
方案一可以参考
Windows上使用OpenVPN实现于异地访问公司内网资源(Tunnel方式、公网服务器frp转发)
在A-B两地之间使用Wireguard
在B地服务器是用OpenVPN供B地其他地区使用
网络结构如下
A地内网<--->A地服务器<- Wireguard-UDP ->B地服务器<- OpenVPN TCP/UCP ->B地其他地区用户
两方案相比,方案一更加简单,但是没有方案二稳定,并且AB两地如果存在高带宽情况用OpenVPN可能会消耗大量资源,在技术难度上方案二要设置转发,需要对两个VPN进行分别配置
最终选择方案二进行
这是一段简单的Flask代码
from flask import Flask
app = Flask(__name__)
@app.route("/")
def index():
return "Hello World"
app.run(debug=True)
我们开启了调试模式,与此同时控制台输出
> python test.py
* Serving Flask app 'test'
* Debug mode: on
WARNING: This is a development server. Do not use it in a production deployment. Use a production WSGI server instead.
* Running on http://127.0.0.1:5000
Press CTRL+C to quit
* Restarting with stat
* Debugger is active!
* Debugger PIN: XXX-XXX-XXX
Mysql主从复制的模板题,以及一些需要注意的地方
复现了一波SYCTF2023,算是我见到的比较有新意的题目之一,至少不是纯牛马套娃题
这是一篇知识星球同步博文,旨在测试知识星球博文同步正常使用,为建设更加多元化的知识星球提供技术支持。
不知不觉任职已经快一年了。电协也已经走过了属于它的第二十七个年头。
2022年5月27日,我用着同样的PPT,与21级的各位,将生活和电协联系在了一起。
不知道大家是否还记得这个教室,在这里,我遇见了你们,我们的故事从这里开始,兜兜转转走过繁忙的四季,留下了弥足珍贵的回忆,最后又回到这里,这可能就是所谓的缘分吧。
此刻,是华章,亦是序章,我们的故事并不会就此结束,只是长江后浪推前浪,我相信你们有能力做的更好
V2更新了一些小东西
!!!NeedStar!!!Github-CTFd-docker
该版本的CTFd全部运行在docker中,并且通过映射unix在docker里面控制宿主机的docker,以管理docker动态容器。使用该项目可以在5-10min之内构建出支持动态容器的靶场。
旧的文章-【CTFd】靶场安装与配置(Docker一键配置版)
前面一段时间,想基于CTFd进行二开一下。有不少前辈给CTFd写过插件,例如赵总的Whale,H1ve的Owl,和支持AWD的glowworm。
他们写的插件各有好处,Whale支持swarm的部署,Owl支持docker-compose(暂时不支持swarm,后面可以改,不过暂时没空),glowworm是目前唯一一个AWD插件。其中Whale和Owl都以来与Frp进行流量转发,通过不断重载frpc的配置实现,但是他们两个插件并不是增量刷新,而是以直接覆盖的形式进行。于是我整合了两个插件的内容和,让他们共用一个frps模块(现在才想到为什么不能用两个呢,但是这就要两个域名了不是吗)。
然而事情不是一帆风顺的,在修改了插件的目录结构后,整个插件都不能正常初始化了,还得对他们进行依赖的修改。然后对旧版的owl插件进行一定的修改,使用了新版的docker-compose工具以支持swarm的使用。
TODO: owl插件更新swarm支持(已更新)
另外作为一个安全平台,不更新到最新版本的CTFd内核总是有点不太合适,于是更新到了CTFd 3.5.2版本,也修改了不少安装流程,优化了安装体验,可以在docker-compose里面自定义域名等,也会自动生成密钥不容易被攻击。
同时也测试了很多不同系统,也用该系统在本校新生赛中构建了一个全新的靶场,体验很棒。
小记而已,暂时就这样了。