shell升级完整记录

[root@localhost bash-4.3.30]# cat Makefile |grep prefix

prefix = /usr/local

exec_prefix = ${prefix}

datarootdir = ${prefix}/share

bindir = ${exec_prefix}/bin

libdir = ${exec_prefix}/lib

includedir = ${prefix}/include

prefix=${prefix} exec_prefix=${exec_prefix} \

[root@localhost bash-4.3.30]# whereis bash

bash: /usr/bin/bash /usr/local/bin/bash /usr/share/man/man1/bash.1.gz

[root@localhost bash-4.3.30]# /usr/bin/bas

base64 basename bash bashbug bashbug-32

[root@localhost bash-4.3.30]# /usr/bin/bash --version

GNU bash, version 4.2.45(1)-release (i686-redhat-linux-gnu)

Copyright (C) 2011 Free Software Foundation, Inc.

License GPLv3+: GNU GPL version 3 or later

This is free software; you are free to change and redistribute it.

There is NO WARRANTY, to the extent permitted by law.

[root@localhost bash-4.3.30]# /usr/local/bin/bash --version

GNU bash, version 4.3.30(1)-release (i686-pc-linux-gnu)

Copyright (C) 2013 Free Software Foundation, Inc.

License GPLv3+: GNU GPL version 3 or later

This is free software; you are free to change and redistribute it.

There is NO WARRANTY, to the extent permitted by law.

[root@localhost bash-4.3.30]#

库文件查询

[root@localhost bash-4.3.30]# ldd bash

linux-gate.so.1 => (0xb779a000)

libtinfo.so.5 => /lib/libtinfo.so.5 (0x4e41c000)

libdl.so.2 => /lib/libdl.so.2 (0x4c65c000)

libc.so.6 => /lib/libc.so.6 (0x4c49c000)

/lib/ld-linux.so.2 (0x4c473000)

[root@localhost bash-4.3.30]#

[root@localhost shell_up_zhb]# chsh -l

/bin/sh

/bin/bash

/sbin/nologin

/usr/bin/sh

/usr/bin/bash

/usr/sbin/nologin

[root@localhost shell_up_zhb]# lsof /bin/sh

COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME

bash 8522 root txt REG 253,1 917564 11014242 /usr/bin/bash

[root@localhost shell_up_zhb]# lsof /bin/bash

COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME

bash 8522 root txt REG 253,1 917564 11014242 /usr/bin/bash

sh 8914 root txt REG 253,1 917564 11014242 /usr/bin/bash

[root@localhost shell_up_zhb]#

1以前的思路是拷贝升级后的可执行文件，库，配置文件（如果有），开始按此思路升级，失败，并且没法登陆。

3 bash升级只是为了修补心血漏洞，估计只需升级可执行文件即可。通过lsof发现，实际上使用的是/usr/bin/sh的shell，/bin/sh其实是连接，那就只拷贝/usr/bin/sh，/usr/bin/bash,拷贝时发现在使用，那就先复制在拷贝。

4 拷贝成功后，用测试例子试一下，发现可以

[NTP-Fedora20 shell_up_zhb]#env x='() { :;}; echo vulnerable' bash -c "echo this is a test"

vulnerable

this is a test

[NTP-Fedora20 shell_up_zhb]#env x='() { :;}; echo vulnerable' ./bash -c "echo this is a test"

this is a test

5 reboot发现成功

Original: https://www.cnblogs.com/zhouhbing/p/5189286.html
Author: 周人假的
Title: shell升级完整记录

相关阅读1

Title: 秒搞VirtualBox 、CentOS 的安装过程

镜像下载、域名解析、时间同步请点击阿里云开源镜像站

一、介绍背景：

VirtualBox ： 由德国 InnoTek 软件公司出品 Open Source Software, OSS（开源软件） 的⼀种 Hypervisor ，现在则由 Oracle 公司进⾏开发（2008年02⽉ SUN 收购 InnoTek ，2010年01⽉ Oracle 收购 SUN ），⽬前是 Oracle 公司 xVM 虚拟化平台技术的⼀部分
CentOS ： 全称 Community Enterprise Operating System ，是⼀种 主要在服务器上使⽤ 的 Linux Distro ，它是来⾃于 Red Hat Enterprise Linux（RHEL） 依照开放源代码规定发布的源代码所编译⽽成。由于出⾃同样的源代码，因此有些要求⾼度稳定性的服务器以 CentOS 替代商业版的 RHEL 使⽤。两者的不同，在于 CentOS 并不包含封闭源代码软件。 CentOS 对上游代码的主要修改是为了移除不能⾃由使⽤的商标。2014年， CentOS 组织宣布与 Red Hat 公司合作，但 CentOS 组织将会在新的委员会下继续运作，并不受 RHEL 的影响。

二、准备工作：

VirtualBox 安装包：https://download.virtualbox.org/virtualbox/6.1.4/VirtualBox-6.1.4-136177-Win.exe

CentOS镜像安装包：http://mirrors.aliyun.com/centos/7/isos/x86_64/CentOS-7-x86_64-Minimal-1908.iso

三、安装VirtualBox：

找到下载后的压缩包，双击执行

然后一直跟着执行下一步，直到完成

点击完成，VirtualBox就安装成功了

四、在VirtualBox安装CentOS：

点击新建

名称命名xxx_linux,选择D盘或者你喜欢的光盘新建一个文件夹，其他不要动

内存至少1024MB,我这边选择2048MB

现在创建虚拟机硬盘，下一步

选择VDI

直接下一步

空间建议20g以上

这里我讲一下，第6步右键选择第二个Choose a disk file

后面就不用什么讲了，直接跟着

点击左上角完成

密码设置完，点击完成

完成，结束！账号为root,密码你自己设置的， 鼠标进入虚拟机如何退出,按右手边Ctrl。

本文转自：https://blog.csdn.net/A6_107/article/details/123660408

Original: https://www.cnblogs.com/helong-123/p/16070819.html
Author: 萌褚
Title: 秒搞VirtualBox 、CentOS 的安装过程

相关阅读2

Title: docker安装portainer详细步骤

镜像下载、域名解析、时间同步请点击阿里云开源镜像站

docker安装portainer详细步骤

portainer是一款容器管理可视化界面，不想在虚拟中使用命令管理容器的小伙伴，可以选择安装portainer对容器进行管理，查看日志、启动、停止容器等非常方便。

1. 搜索portainer镜像

docker search portainer

2. 拉取portainer镜像

docker pull lihaixin/portainer

3. 启动portainer容器

# 启动镜像
docker run -d -p 9000:9000 --restart=always \
-v /var/run/docker.sock:/var/run/docker.sock \
--name portainer lihaixin/portainer

4. docker ps查看容器

docker ps
# 查看日志
docker logs -f portainer

5. 浏览器中ip+端口访问

首次登录，需要你创建管理员admin的密码，

密码创建好后，进入docker连接管理界面：

可以选择管理本地Local和远程Remote的Docker两个选项，我们安装在本机，直接选择Local，然后Connect进入管理界面：

继续点击右边的local条目，点击【Connect】进入容器管理界面：

继续点击右边的local条目，进入容器管理界面：

点击左边菜单栏的Containers，打开容器管理界面。

查看运行容器日志

本文转自：https://blog.csdn.net/qq_38066812/article/details/122727904

Original: https://www.cnblogs.com/helong-123/p/16163997.html
Author: 萌褚
Title: docker安装portainer详细步骤

相关阅读3

Title: Redis故障案例(一)-特定key批量丢失

作者：RogerZhuo
来源：DBACoder

TroubleShooting-排障是DBA一项重要技能，通过故障表现的症状，先让业务高速恢复止损，同一时候分析故障的根因(rootCause),给出解决方式并从根本上修复故障。最后总结从产品或流程上怎么规避同类型故障再次发生。

DBA排障非常像医生治病、刑警破案。

医生通过了解病人病情症状(故障症状），先让病人病情缓解(服务止损）相似止痛，同一时候分析病灶（故障根因），给出可行的治疗方案（故障解决方式），病人全然恢复；最后给出医疗建议怎样预防病情或避免恶化(故障规避）；当然还有现多的相似急救(紧急故障-7位数级损失）、会诊、不治、AI医疗(AI故障根因分析）、医疗事故(背锅)；事实上非常多相通之处。

刑警通过真凶（故障根因）留下的犯罪现场(故障症状）。根据罗卡定律，各种技术分析和寻找证据，终于找出真凶和证据。（段子非常多。先回到主题）

在Redis早期的运维过程中。也遇过不少Redis故障。现总结当中几个有意思的案例，希望对刚開始用Redis的DB A同学有所帮助。

故障因与业务、故障场景结合较密切(脱敏)。笔者尽量提炼成技术和还原现场。故障系列文章包含下面几部分：

故障背景：主要交待技术和故障背景[可选]。

故障描写叙述：故障的简单描写叙述、根本原因和影响。

故障监控告警：故障相关的监控告警信息；

故障分析：文章核心 提供相似故障的分析思路、和技术点；

故障阶段性总结：文章核心 总结相似故障的通用性预防；

本文是Redis故障案例(一)关于一次Redis特定key丢失排查分析。

1 故障背景

A业务有一个3分片的Redis Cluster缓存集群,会定期生成数据写入Redis;某一天。A业务的研发project师(下文简称RD)突然找到DBA,非常激动地说："我们Redis集群突然掉非常多key..." ,然后故事就開始了....

RD: "我们Redis集群中，以"t_list:"前缀的90000多key今早发现都掉了，其它key还在，是不是DBA有清理操作啊？"
DBA: "没有维护性操作(一脸懵B和无辜),先止损，把Key从Primary store中导入Redis；"
RD: "已经从MySQL把key导入到Redis，如今业务功能恢复。影响非常小。

但请帮忙追查原因。"
DBA: "这部分key确认近期一次还在是什么时候?

然后最早发现丢失是在什么时候？" 备注:DBA開始和当事人了解案发时间，为排查问题提供根据。
RD: "昨晚20:30前key肯定还在，最早发现key不见是今早9:20同事发现新測试功能有异常" 备注：灰度功能
DBA: "好的，我先分析一下原因，有结果了通知你；定位问题前，你也关注一下服务。避免问题二次发生"。

然后RD就下楼了，DBA扣上他的几十元买来的boss耳机。開始自言自语Troubleshooting.

2 故障描写叙述

因RD1同学为重写t_list的90000多个KEY, 通过keys t_list*命令获取并删除。但未及时把key新内容重到redis中；使得RD2同学以为数据灵异丢失。

但由于是灰度功能使用数据。服务影响范围较小。

3 故障告警

1 业务告警缺失。见故障总结
2 Redis側无法监控此类告警

4 故障分析

通过RD提供的线索：

• 特定t_list:前缀90000个List元素丢失；
• 数据丢失时间范围前日20：30~9:20之间（案发时间段。分析各种监控范围）。

通过故障症状初步分析，故障可能的根因：

• 执行了flushall/flushdb命令删除所有key,其它key是后来写入的。造成了仅仅丢失t_list的假象
• 这90000个List元素因运行LPOP/RPOP，导致key被删除的现象;(List中元素被所有pop完后，list相当于被删除了）
• 这部分key因设置了TTL。在此期间内所有过期，被redis自己主动删除;
• 这部分key因LRU淘汰。被redis所有驱赶淘汰；
• 程序BUG或人为删除导致。

每一个可能故障根因排查分析：

• 排除flushall/flushdb导致。因此集群两个命令是被rename了，同一时候观察集群监控dbsize为了跌为0的区段； info Commandstats中没cmdstat_flushdb、cmdstat_flushall输出都可确认，不是flush造成的。
• 排队List pop操作导致的；通过分析案发时间段内的监控图，并未发现cmdstat_rpop和cmdstat_lpop输出；
• 排除过期删除导致； 分析监控，近期24小时expired_keys监控指标值基本为0
• 排除LRU淘汰导致；本集群实例未设置淘汰，maxmemory-policy为noeviction；分析监控，近期24小时evicted_keys监控指标值都是0。
• 确认是程序BUG或人为删除导致；最后定位是RD1同学。为重写这部分key。通过脚本keys t_list:*获取，并通过del命令删除。具体分析步骤例如以下：

通过分析redis监控单个分片key个数。发现22:00到22:40时间段内，key个数下降约30000个；此集群共3个数据分片,且每一个分片slots分配均匀，三个分片同一时候段key个数下降约90000个；和故障丢失key个数相符。

图1. 数据key个数监控图

再分析DEL的操作。22:00~22:40时间段内，每一个Redis的每秒del操作12次，持续40min; 约30000个del操作； 3个分片。共运行约90000次DEL操作

图2. 删除操作DEL的每秒请求数监控图

查看slowlog监控。2015-12-03 22:01:01 时间点，运行KEYS "tlist*" 获取所有key的前缀， 目的应该是运行后面的DEL操作

图3. slowlog分析图

5 故障阶段性总结和预防

• 禁用keys命令(程序历史原因)。DBA提供删除特定key的自助化服务；尽量避免RD直接操作Redis集群数据，通过review的流程降低误操作的发生。
• 业务方加强监控告警，业务异常能及时发现。

非技术类总结：

• 数据是公司重要的资产和生命线。DBA除了本职工作做好数据的安全和可靠外；实际工作也有非常多相似的"数据丢失"场景，怎么从技术层面不做背锅侠。
• 做好完好的监控，是精细化运营管理和自我保护的前提。

-END-

推荐订阅原文作者公众号 DBACoder

▼

Original: https://www.cnblogs.com/ljbguanli/p/9897761.html
Author: ljbguanli
Title: Redis故障案例(一)-特定key批量丢失