-
基于阿里云 ECS 内网穿透 SSH 访问家庭 Linux 服务器
2023-07-03 14:09[root@k8s-master-02:~ 14:06:08] # wc -l lastb.log 250176 lastb.log [root@k8s-master-02:~ 14:08:18] # head lastb.log ueb ssh:notty 127.0.0.1 Mon Jul 3 12:18 - 12:18 (00:00) lkr ssh:notty 127.0.0.1 Mon Jul 3 12:17 - 12:17 (00:00) nlq ssh:notty 127.0.0.1 Mon Jul 3 12:17 - 12:17 (00:00) thy ssh:notty 127.0.0.1 Mon Jul 3 12:16 - 12:16 (00:00) vil ssh:notty 127.0.0.1 Mon Jul 3 12:16 - 12:16 (00:00) vry ssh:notty 127.0.0.1 Mon Jul 3 12:15 - 12:15 (00:00) fto ssh:notty 127.0.0.1 Mon Jul 3 12:15 - 12:15 (00:00) qit ssh:notty 127.0.0.1 Mon Jul 3 12:15 - 12:15 (00:00) ipb ssh:notty 127.0.0.1 Mon Jul 3 12:14 - 12:14 (00:00) zpx ssh:notty 127.0.0.1 Mon Jul 3 12:14 - 12:14 (00:00)
-
记一次令人心悸的 GitLab 升级经历
2022-02-11 22:411.企业中依赖的重要系统,能不升级就不升级,保证能用就行,除非升级能解决现有的重要 bug
2.“我以为”是运维大忌,主观性太强,容易误操作
3.重大变更之前,做好数据备份,想好执行步骤和可能的意外情况,想好如果出现问题,如何快速回滚让系统恢复正常,让公司损失最小,影响面降到最低
4.每一个命令回车之前,想一想,执行后会有什么效果,最好能知道命令的含义,实在不行,没有经验就自己模拟一个环境自己先测试(如果是虚拟化的机器,可以提前打快照准备好退路)
5.有时候自己是出于好心,但是却能办了坏事,这种心态,还是憋着为好
以上,经验之谈,大佬勿喷
-
公司给换了新 Mac,加班迁移数据中……
2020-07-08 11:24推荐使用
carbon copy cloner
这个软件,直接硬盘对拷的,速度取决于硬盘的速度,恢复之后,和原机的设置,文件位置和 dashboard 中软件排列一模一样,个人不推荐使用时光机那种恢复贼慢的工具,恢复完成之后还要手动设置一些东西,特别是 dashboard 中的软件排列,之前分类好的恢复之后还得重新调,很浪费时间 -
记一次令人心悸的 GitLab 升级经历
2020-03-05 17:55 -
solo 页面无法正常加载
2020-02-10 10:06location / { proxy_set_header Host $http_host; proxy_pass http://127.0.0.1:8080; }
-
2019 看房记
2019-10-21 14:30这三个小区都有地下停车库,车位比例大概都在 1:1.15 以上,我当时的打算就是,最坏最坏住一辈子,第一个也够了,实在不行后面再换,89 平的升值空间也可以,二手也好出
-
关于 Solo 的图片上传的问题
2019-09-27 08:57网站建立好之后,数据备份是必须的,所以这个问题无须担心,我们使用者需要做的就是每天能备份一下 solo 数据库里的数据,这才是最关键的