分类 Linux 相关 下的文章

netcat(nc) 的各种操作

  1. 扫描端口

    nc -vzu 192.168.0.1 80-90
nc -v -z www.tianxiaohui.com 90-100
nc -v -n -z -w 1 192.168.1.2 1-1000

  2. 从客户端传文件到服务端
    服务端先起来

    nc -l 8080 > file.txt
nc -v remote_server 8080 > localfile.txt
带压缩:
nc -l -p 1234 | uncompress -c | tar xvfp -
tar cfp - /some/dir | compress -c | nc -w 3 [destination]:1234

  3. 从服务端传文件到客户端

    nc -4 -v -l 7070 < myfile.txt
客户端可用浏览器或者 nc 命令
nc -v www.tianxiaohui.com 7070

  4. 作为代理

    单向代理: nc -l 12345 | nc www.google.com 80
双向:
mkfifo backpipe
nc -l 12345 0<backpipe | nc www.google.com 80 1>backpipe

  5. 让任何命令作为网络服务器 (网络后门)

    服务端: nc -4 -l -p 1234 -e /bin/sh
客户端: nc remote_server 1234
ls -lah

    如果遇到:

close: Bad file descriptor
加上 -4 参数.

使用 telnet, nc, openssl 浏览网站

LM-SHC-16507776:~ xiatian$ telnet www.tianxiaohui.com 80
Trying 156.236.115.130...
Connected to www.tianxiaohui.com.
Escape character is '^]'.

GET /about.html HTTP/1.1
Host: www.tianxiaohui.com

HTTP/1.1 400 Bad Request
Date: Sat, 02 Nov 2019 03:18:30 GMT
Server: Apache
Accept-Ranges: bytes
Connection: close
Content-Type: text/html

printf "GET /index.html HTTP/1.0\r\nHost: www.tianxiaohui.com\r\n\r\n" | nc www.tianxiaohui.com 80

使用 openssl 浏览 https 的
LM-SHC-16507776:~ xiatian$ openssl

OpenSSL> s_client -crlf -connect www.bing.com:443 -quiet

depth=2 C = IE, O = Baltimore, OU = CyberTrust, CN = Baltimore CyberTrust Root
verify return:1
depth=1 C = US, ST = Washington, L = Redmond, O = Microsoft Corporation, OU = Microsoft IT, CN = Microsoft IT TLS CA 2
verify return:1
depth=0 CN = www.bing.com
verify return:1

GET / HTTP/1.1
Host:www.bing.com

HTTP/1.1 302
Cache-Control: private
Content-Length: 137
Content-Type: text/html; charset=utf-8
Location: https://cn.bing.com/
Date: Sat, 02 Nov 2019 03:11:59 GMT

<html><head><title>Object moved</title></head><body>
Object moved to https://cn.bing.com.<;/body></html>

GET / HTTP/1.1
Host:cn.bing.com

HTTP/1.1 200 OK
Cache-Control: private, max-age=0
Content-Length: 114805

诊断 puppet agent 导致的 CPU 使用率非常高的问题

问题描述:
看到有一台机器表现很突出, CPU 使用率比其它高, 干活却没比其它机器多:
PerfMon.png

搜集数据:
登录机器, 查看各个进程 CPU 使用情况: 以 root 运行的 puppet 就是那个嫌疑犯
top -i
top.png
嫌疑犯近照:
ps -auxwwww <pi>

pdetail.png

因为 strace 只针对一个线程, 如果一个进程里面有多个线程, 首先要查出是哪个线程使用 CPU 比较高, 否则可能出错.
使用 top -i 命令出来之后, 输入 大写的 H 则能进入 thread 模式.
或者 使用 top -H -p <pid>
threads.png

然后在使用 strace 命令

诊断:
使用 strace 诊断, 发现较短时间内狂调 sched_yield, google 一下, 发现已知问题
sudo strace -p 14194 -c
strace.png
https://bugs.launchpad.net/debian/+source/ruby2.3/+bug/1834072

修复:

  1. 重启能临时解决
  2. 升级 ruby 能长期解决

strace 常用命令

strace 是一款基于 linux ptrace 系统调用的命令行工具, 对于没有源代码去黑盒 triage 问题很有帮助. 它主要通过拦截分析 进程和系统调用的交互, 产生相应的输出.

常见命令:
strace -p 26380
strace -p 26380 -c
sudo strace -p 4599 -e trace=all

它还可以用来做错误注入 (fault injection)

-e trace=%desc     Trace all file descriptor related system calls.
         %file     Trace all system calls which take a file name as an argument.
         %fstat    Trace fstat and fstatat syscall variants.
         %fstatfs  Trace fstatfs, fstatfs64, fstatvfs, osf_fstatfs, and osf_fstatfs64 system calls.
         %ipc      Trace all IPC related system calls.
         %lstat    Trace lstat syscall variants.
         %memory   Trace all memory mapping related system calls.
         %network  Trace all the network related system calls.
         %process  Trace all system calls which involve process management.
         %pure     Trace syscalls that always succeed and have no arguments.
         %signal   Trace all signal related system calls.
         %stat     Trace stat syscall variants.
         %statfs   Trace statfs, statfs64, statvfs, osf_statfs, and osf_statfs64 system calls.
         %%stat    Trace syscalls used for requesting file status.
         %%statfs  Trace syscalls related to file system statistics.

由 hypervisor 驱动内存泄漏导致的 VM CPU飙高的问题

今天有开发人员说他们同一个 cluster 里面运行同一版本的某些 server 出现 JVM CPU 非常高的情况, 而其它 server 的JVM
CPU 维持正常. 他们表示说以前没出现过这种情况, 而出现这种情况的server 比正常其它server 的CPU usage 要高很多, 所以被内部某些监控工具自动重启了. 据他们观察这些机器可能正在被内部的某些漏洞扫描工具在扫描, 但是又不能确认, 想请SRE帮忙确认一下原因是什么?

SRE 首先确认了这些 CPU usage 非常高的server 跟内部的漏洞扫描基本没关系, 因为这些漏洞扫描的 traffic 基本进不了程序内部代码逻辑, 在应用框架层就被拦截了, 基本不会造成CPU usage 高. 另外还有其它被漏洞扫描的server 并没有出现 CPU 飙高的情况.

SRE 另外明确看到, 这些出问题的server(其实都是通过OpenStack 虚拟出来的VM)的CPU usage大概都在40%左右, 不出问题的server 的CPU usage 大概在3%左右. 出问题server 的JVM CPU usage 大概在8%左右, 而没有问题的 server 的 JVM CPU usage 大概在1%左右. 所以可以大概得出结论, 这些CPU 大部分并不是被 JVM 所占用, 但是 JVM 也受到了一定的影响.

进一步观察发现出现问题的server 都是在同一台 hypervisor 上, 进一步去查看同一台 hypervisor 上面的其它 vm server, 也都表现出了 CPU 较高的情况.

登录到这台 Hypervisor 上面, 使用下面的命令可以看到, 这些Hypervisor 有kernel的内存泄漏问题:

admin@hv-8hhy:~$ smem -twk
Area                           Used      Cache   Noncache
firmware/hardware                 0          0          0
kernel image                      0          0          0
kernel dynamic memory        159.2G       6.5G     152.7G
userspace memory             139.3G     196.2M     139.1G
free memory                   15.6G      15.6G          0
----------------------------------------------------------
                             314.1G      22.3G     291.8G

在 kernel dynamic memory 这行的 Noncache 这列, 我们看到它使用了152.7G, 这明显是个问题. 对于 Cloud team来说这是一个已知的issue, 并且给出了 kernel 的fix link:
https://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git/commit/drivers/net/ethernet/intel/i40e/i40e_txrx.c?id=2b9478ffc550f17c6cd8c69057234e91150f5972

  1. 1
  2. ...
  3. 5
  4. 6
  5. 7
  6. 8
  7. 9
  8. 10
  9. 11
  10. 12