技术博客

root账户却无法修改ssh的配置文件，修改下文件属性就好了

chattr -V -ia sshd_config

有时候业务上要做做评论框或者聊天页面会用到emoji表情包，当然使用比较广泛的非微信表情包莫属了。做表情包可以使用阿里的矢量图库或svg，不讲究的话也可以直接叫UI切一堆png图片给你（如果UI不怼你的话^_^）。以前都是UI直接丢一张大图过来我用精灵css（国内也有叫雪碧图）来自己做的。原理就是用css中background-position属性来给整个大图定位以此分割成（视觉上）不同的小图来展示。好处就是可以减少http请求也省了切图的功夫，不好的地方就是其中要改某个图片很麻烦必须更新整张图甚至重写css。下面直接上代码：>>>这个是微信表情包的雪碧图>>>纯js+css代码

当我正沉浸在国庆黄金周的悠闲时光里面的某一个下午突然收到报告称：xxx服务器CPU连续几天占用超过99%疑似遭到攻击。PS：我只是公司打杂的，偶尔写写脚本处理一些业务顺便帮忙买下云服务器什么的。不知道从什么时候开始服务器出了比较大的问题都优先找到我 (^=^)姨母微笑。我登到控制台一看果然那台Linux服务器宕机了，top命令看到是业务上的关键服务和守护进程占满了CPU。作为外行的我又在休假期间，本着不行就重启试试的基本原则reboot了一下服务器。ssh重新登陆进去查了一圈histroy命令行操作日志、ssh登陆日志和可疑进程，然后是crontab计划任务和rc.local开机启动，都没有找到异常。看了下CPU占用下来了但是业务服务却没有自动重启，问了下业务都是docker跑的于是手动运行了docker发现也无法正常启动直接报docker.service找不到，socket文件无法创建。然后df -h 查看硬盘占用100%，果然是硬盘满了导致服务无法正常运行CPU100%。100多G的服务器硬盘，docker占了90%以上，先删了他们业务10多G的日志（你问我什么业务有10多G的日志我也表示疑惑，^_^）先保证服务能正常启动。接着用du -sh 挨个目录检查占用情况，最后查到了/var/lib/docker/containers目录占了70-80个G。我水平比较一般，平常部署项目没有直接在服务器上搞过docker所以不太明白容器目录为啥会占这么多，懂的大神可以跟我科普下，哈哈。然后发现有一个巨大无比的.log文件占了70G。终于找到罪魁祸首，上网查了下这个日志文件可以清理就直接 echo ''> xxx.log了。顺带又查了下docker的幽灵镜像，也用docker rmi 删了。然后服务器回归平静。为了防止下次又产生这么大的日志文件，我在/etc/docker/daemon.json加了个docker配置愿下次出问题的时候我正在无聊摸鱼而不是度假中，Amen～