30选5玩法|福彩30选5开奖结果321|
 

分类:网络技术

网站建设

一看必会系列:k8s 练习8 ingress https ssl

No Comments 网络技术

 

k8s ingress-nginx ssl

生成证书
https://github.com/kubernetes/ingress-nginx/blob/master/docs/examples/PREREQUISITES.md

生成证书和key
$ openssl req -x509 -sha256 -nodes -days 365 \
         -newkey rsa:2048 \
         -keyout tls.key \
         -out tls.crt \
         -subj "/CN=nginxsvc/O=nginxsvc"
Generating a 2048 bit RSA private key
…………….+++
…………….+++
writing new private key to ‘tls.key’
—–

命令格式
kubectl create secret tls ${CERT_NAME} –key ${KEY_FILE} –cert ${CERT_FILE}

制作secret,后面在容器里用 tls名字进行挂载
$ kubectl create secret tls tls-secret –key tls.key –cert tls.crt
secret "tls-secret" created  #引号里为名字

使用真?#26723;膆ttps证书
[[email protected] ssl]# ll
total 16
-rw-r–r– 1 root root 3622 Mar  4 07:17 ccie.wang.crt    -证书
-rw-r–r– 1 root root 1732 Jan 28 16:41 ccie.wang.key    -key
-rw-r–r– 1 root root  308 Apr  2 04:57 ccie.wang.yaml
-rw-r–r– 1 root root 2992 Mar 31 19:38 multi-tls.yaml
[[email protected] ssl]# kubectl create secret tls tls.ccie.wang –key ccie.wang.key –cert ccie.wang.crt
secret/tls.ccie.wang created  #生成密文成功

配置ingress service

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: nginx-ccie-wang-test
spec:
  tls:
    – hosts:
        #写成其它host也能?#23567;?#19981;知为啥
      – in4ssl.ccie1.wang
      secretName: tls.ccie.wang
  rules:
      #这个host一定要对,这个对应nginx的 server_name
    – host: in4ssl.ccie.wang
      http:
        paths:
        – path: /
          backend:
             #service必须先存在,端口也要存在
            serviceName: frontend-svc
             #启动后会自动开启443端口,不用定义
            servicePort: 80

验证:
进入ingress的pod查看配置
kubectl exec nginx-ingress-controller-7966d94d6c-8prth \
-n ingress-nginx — cat /etc/nginx/nginx.conf > nginx.conf

直接请求https页面,出现如?#24405;?#27491;常
[[email protected] ssl]# curl -s https://in4ssl.ccie.wang |head -5
<html ng-app="redis">
  <head>
    <title>Guestbook</title>
    <link rel="stylesheet" href="bootstrap.min.css">
    <script src="angular.min.js"></script>
[[email protected] ssl]#

直接请求http页面,发现被重定向即为正常
[[email protected] ssl]# curl in4ssl.ccie.wang
<html>
<head><title>308 Permanent Redirect</title></head>
<body>
<center><h1>308 Permanent Redirect</h1></center>
<hr><center>nginx/1.15.9</center>
</body>
</html>

 

————–知识扩展

https://kubernetes.github.io/ingress-nginx/user-guide/tls/

TLS Secrets?
Anytime we reference a TLS secret, we mean a PEM-encoded X.509, RSA (2048) secret.

You can generate a self-signed certificate and private key with:

生成证书
$ openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout ${KEY_FILE} -out ${CERT_FILE} -subj "/CN=${HOST}/O=${HOST}"
Then create the secret in the cluster via:

创建密文
kubectl create secret tls ${CERT_NAME} –key ${KEY_FILE} –cert ${CERT_FILE}
The resulting secret will be of type kubernetes.io/tls.

Default SSL Certificate?
NGINX provides the option to configure a server as a catch-all with server_name for requests that do not match any of the configured server names. This configuration works without out-of-the-box for HTTP traffic. For HTTPS, a certificate is naturally required.

For this reason the Ingress controller provides the flag –default-ssl-certificate. The secret referred to by this flag contains the default certificate to be used when accessing the catch-all server. If this flag is not provided NGINX will use a self-signed certificate.

For instance, if you have a TLS secret foo-tls in the default namespace, add –default-ssl-certificate=default/foo-tls in the nginx-controller deployment.

SSL Passthrough?
The –enable-ssl-passthrough flag enables the SSL Passthrough feature, which is disabled by default. This is required to enable passthrough backends in Ingress objects.

Warning

------中间广告---------

This feature is implemented by intercepting all traffic on the configured HTTPS port (default: 443) and handing it over to a local TCP proxy. This bypasses NGINX completely and introduces a non-negligible performance penalty.

SSL Passthrough leverages SNI and reads the virtual domain from the TLS negotiation, which requires compatible clients. After a connection has been accepted by the TLS listener, it is handled by the controller itself and piped back and forth between the backend and the client.

If there is no hostname matching the requested host name, the request is handed over to NGINX on the configured passthrough proxy port (default: 442), which proxies the request to the default backend.

Note

Unlike HTTP backends, traffic to Passthrough backends is sent to the clusterIP of the backing Service instead of individual Endpoints.

HTTP Strict Transport Security?
HTTP Strict Transport Security (HSTS) is an opt-in security enhancement specified through the use of a special response header. Once a supported browser receives this header that browser will prevent any communications from being sent over HTTP to the specified domain and will instead send all communications over HTTPS.

HSTS is enabled by default.

To disable this behavior use hsts: "false" in the configuration ConfigMap.

Server-side HTTPS enforcement through redirect?
By default the controller redirects HTTP clients to the HTTPS port 443 using a 308 Permanent Redirect response if TLS is enabled for that Ingress.

This can be disabled globally using ssl-redirect: "false" in the NGINX config map, or per-Ingress with the nginx.ingress.kubernetes.io/ssl-redirect: "false" annotation in the particular resource.

Tip

When using SSL offloading outside of cluster (e.g. AWS ELB) it may be useful to enforce a redirect to HTTPS even when there is no TLS certificate available. This can be achieved by using the nginx.ingress.kubernetes.io/force-ssl-redirect: "true" annotation in the particular resource.

Automated Certificate Management with Kube-Lego?
Tip

Kube-Lego has reached end-of-life and is being replaced by cert-manager.

Kube-Lego automatically requests missing or expired certificates from Let’s Encrypt by monitoring ingress resources and their referenced secrets.

To enable this for an ingress resource you have to add an annotation:

kubectl annotate ing ingress-demo kubernetes.io/tls-acme="true"
To setup Kube-Lego you can take a look at this full example. The first version to fully support Kube-Lego is Nginx Ingress controller 0.8.

Default TLS Version and Ciphers?
To provide the most secure baseline configuration possible,

nginx-ingress defaults to using TLS 1.2 only and a secure set of TLS ciphers.

Legacy TLS?
The default configuration, though secure, does not support some older browsers and operating systems.

For instance, TLS 1.1+ is only enabled by default from Android 5.0 on. At the time of writing, May 2018, approximately 15% of Android devices are not compatible with nginx-ingress’s default configuration.

To change this default behavior, use a ConfigMap.

A sample ConfigMap fragment to allow these older clients to connect could look something like the following:

kind: ConfigMap
apiVersion: v1
metadata:
  name: nginx-config
data:
  ssl-ciphers: "ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA"
  ssl-protocols: "TLSv1 TLSv1.1 TLSv1.2"

Kubernetes部分Volume类型介绍及yaml示例–emptyDir

No Comments 网络技术

Kubernetes部分Volume类型介绍及yaml示例–emptyDir(本地数据卷)

说明
EmptyDir类型的volume创建于pod被调度到某个宿主机?#31995;?#26102;候,而同一个pod内的容器都能?#21015;碋mptyDir中的同一个文件。一旦这个pod离开了这个宿主机,EmptyDir中的数据就会被永久删除。所以目前EmptyDir类型的volume主要用作临时空间,比如Web服务器写日志或者tmp文件需要的临时目录。
实战使用共享卷的标准单容器POD
#创建yaml文件
cat >> emptyDir.yaml << EOF
apiVersion: v1
kind: Pod
metadata:
    labels:
        name: test-emptypath
        role: master
    name: test-emptypath
    namespace: test
spec:
    containers:
        – name: test-emptypath
            image: nginx:1.7.9
            volumeMounts:
             – name: log-storage
                 mountPath: /tmp/
    volumes:
    – name: log-storage
        emptyDir: {}
#启动emptyDir.yaml
kubectl create -f ./emptyDir.yaml
#查看Pod运行状态
kubectl get po -n test
NAME                         READY     STATUS    RESTARTS   AGE
test-emptypath               1/1       Running   0          3h
##说明:当 Pod 被分配给节点时,首先创建 emptyDir 卷,并且只要该 Pod
##在该节点上运行,该卷就会存在。正如卷的名字所述,它最初是空的。
实战使用共享卷的标准多容器POD、
#创建yaml文件
cat  >> emptyDir2.yaml << EOF
apiVersion: v1
kind: Pod
metadata:
    name: datagrand
    namespace: test
spec:
    containers:
    – name: test1
        image: nginx:1.7.9
        volumeMounts:
        – name: log-storage
            mountPath: /usr/share/nginx/html
    – name: test2
        image: centos
        volumeMounts:
        – name: log-storage
            mountPath: /html
        command: ["/bin/sh","-c"]
        args:
            – while true;do
                    data >> /html/index.html;
                    sleep 1;
                done
volumes:
    – name: log-storage
        emptyDir: {}
##说明:在这个例子中,我们定义了一个名为HTML的卷。它的类型是emptyDir,
##这意味着当一个POD被分配到一个节点时,卷先被创建,并只要Pod在节点上
##运行时,这个卷仍存在。正如名字所说,它最初是空的。第一容器运行nginx的
##服务器并将共享卷挂载到目录/ usr /share/ nginx /html。第二容器使用centos
##的镜像,并将共享卷挂载到目录/HTML。每一秒,第二容器添加当前日期和时
##间到index.html文件中,它位于共享卷。当用户发出一个HTTP请求到POD,
##nginx的服务器读取该文件并将其传递给响应请求的用户。
#运行yaml
kubectl create -f ./emptyDir2.yaml
#查看Pod运行状态
kubectl get po -n test
NAME                         READY     STATUS    RESTARTS   AGE
datagrand                    2/2       Running   0          22m
#进入容器test1
kubectl exec -it datagrand -c test1 /bin/bash -n test
[email protected]:/# cd /usr/share/nginx/html
[email protected]:/usr/share/nginx/html# ls
index.html
##添加内容
[email protected]:/usr/share/nginx/html# echo "this is a test" >> index.html
#进入容器test2
kubectl exec -it datagrand -c test2 /bin/bash -n test
[[email protected] /]# cd html
[[email protected] html]# ls
index.html
[[email protected] html]# cat index.html
this is a test
##emptyDir卷是两个容器(test1和test2)共享的
参考文档
https://www.kubernetes.org.cn/2767.html

linux 踢用户

No Comments 网络技术

kill –9 pts

# w    显示当前用户
11:50:21 up 14 min,  2 users,  load average: 0.27, 0.42, 0.26
USER     TTY      FROM             [email protected]   IDLE   JCPU   PCPU WHAT
ops      pts/2    10.23.1.15       11:44    5.00s  0.12s  0.27s sshd: ops [priv]   
ops      pts/3    10.23.1.15       11:47    2:29   0.04s  0.04s –bash

ps -t pts/0 | awk ‘/[0-9]/ {print $1}’ | xargs sudo kill -9

TIME_WAIT状态原理

No Comments 网络技术

TIME_WAIT状态原理

—————————-

通信双方建立TCP连接后,主动关闭连接的一方就会进入TIME_WAIT状态。

客户端主动关闭连接时,会发送最后一个ack后,然后会进入TIME_WAIT状态,再停留2个MSL时间(后有MSL的解释),进入CLOSED状态。

下图是以客户端主动关闭连接为例,说明这一过程的。

TIME_WAIT状态存在的理由

—————————-

TCP/IP协议就是这样设计的,是不可避免的。主要有两个原因:

1)可靠地实现TCP全双工连接的终止

TCP协议在关闭连接的四次握手过程中,最终的ACK是由主动关闭连接的一端(后面统称A端)发出的,如果这个ACK丢失,对方(后面统称B端)将重发出最终的FIN,因此A端必须维护状态信息(TIME_WAIT)允许它重发最终的ACK。如果A端不维持TIME_WAIT状态,而是处于CLOSED 状态,那么A端将响应RST分节,B端收到后将此分节解释成一个错误(在java中会抛出connection reset的SocketException)。

因而,要实现TCP全双工连接的正常终止,必须处理终止过程中四个分节任?#25105;?#20010;分节的丢失情况,主动关闭连接的A端必须维持TIME_WAIT状态 。

2)允许?#31995;?#37325;复分节在网络中消逝

TCP分节可能由于路由器异常而“迷途?#20445;?#22312;迷途期间,TCP发送端可能因确认超时而重发这个分节,迷途的分节在路由器修复后也会被送到最终目的地,这个迟到的迷途分节到达时可能会引起问题。在关闭“前一个连接”之后,马上又重新建立起一个相同的IP和端口之间的“新连接?#20445;?#21069;一个连接”的迷途重复分组在“前一个连接”终止后到达,而被“新连接”收到了。为了避免这个情况,TCP协议不允许处于TIME_WAIT状态的连接启动一个新?#30446;?#29992;连接,因为TIME_WAIT状态?#20013;?MSL,就可以保证当成功建立一个新TCP连接的时候,来自旧连接重复分组已经在网络中消逝。

MSL时间

—————————-

MSL就是maximum segment lifetime(最大分节生命期),这是一个IP数据包能在互联网上生存的最长时间,超过这个时间IP数据包将在网络中消失 。MSL在RFC 1122上建议是2分钟,而源自berkeley的TCP实现传?#25104;?#20351;用30秒。

TIME_WAIT状态维持时间

—————————-

TIME_WAIT状态维持时间是两个MSL时间长度,也就是在1-4分钟。Windows操作系统就是4分钟。

用于统计当前各种状态的连接的数量的命令

—————————

#netstat -n | awk ‘/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}’

返回结果如下:

LAST_ACK 14

SYN_RECV 348

ESTABLISHED 70

FIN_WAIT1 229

FIN_WAIT2 30

CLOSING 33

TIME_WAIT 18122

对上述结果的解?#20572;?/p>

CLOSED:无连接是活动的或正在进行

LISTEN:服务器在等待进入呼叫

SYN_RECV:一个连接请求已经到达,等待确认

SYN_SENT:应用已经开始,打开一个连接

ESTABLISHED:正常数据传输状态

FIN_WAIT1:应用说它已经完成

FIN_WAIT2:另一边已同意释放

ITMED_WAIT:等待所有分组死掉

CLOSING:两边同时尝试关闭

TIME_WAIT:另一边已初始化一个释放

LAST_ACK:等待所有分组死掉

进一步论述这个问题:

===============================

————–客户端主动关闭连接———————–

注意一个问题,进入TIME_WAIT状态的一般情况下是客户端。

大多数服务器端一般执行被动关闭,服务器不会进入TIME_WAIT状态。

当在服务器端关闭某个服务再重新启动时,服务器是会进入TIME_WAIT状态的。

举例:

1.客户端连接服务器的80服务,这时客户端会启用一个本地的端口访问服务器的80,访问完成后关闭此连接,立刻再次访问服务器的

80,这时客户端会启用另一个本地的端口,而不是刚才使用的那个本地端口。原因就是刚才的那个连接还处于TIME_WAIT状态。

2.客户端连接服务器的80服务,这时服务器关闭80端口,立即再次重启80端口的服务,这时可能不会成功启动,原因也是服务器的连

接还处于TIME_WAIT状态。

服务端提供服务时,一般监听一个端口就够了。例如Apach监听80端口。

客户端则是使用一个本地?#30446;障?#31471;口(大于1024),与服务端的Apache的80端口建立连接。

当通信时使用短连接,并由客户端主动关闭连接时,主动关闭连接?#30446;?#25143;端会产生TIME_WAIT状态的连接,一个TIME_WAIT状态的连接就占用了一个本地端口。这样在TIME_WAIT状态结束之前,本地最多就能承受6万个TIME_WAIT状态的连接,就无端口可用了。

客户端与服务端进行短连接的TCP通信,如果在同一台机器上进行压力测试模拟上万?#30446;?#25143;请求,并且循环与服务端进行短连接通信,那么这台机器将产生4000个左?#19994;腡IME_WAIT socket,后续的短连接就会产生address already in use : connect的异常。

关闭的时候使用RST的方式,不进入 TIME_WAIT状态,是否可行?

————–服务端主动关闭连接——————————

服务端提供在服务时,一般监听一个端口就够了。例如Apach监听80端口。

客户端则是使用一个本地?#30446;障?#31471;口(大于1024),与服务端的Apache的80端口建立连接。

当通信时使用短连接,并由服务端主动关闭连接时,主动关闭连接的服务端会产生TIME_WAIT状态的连接。

由于都连接到服务端80端口,服务端的TIME_WAIT状态的连接会有很多个。

假如server一秒钟处理1000个请求,那么就会积压240秒*1000=24万个TIME_WAIT的记录,服务有能力维护这24万个记录。

大多数服务器端一般执行被动关闭,服务器不会进入TIME_WAIT状态。

服务端为了解决这个TIME_WAIT问题,可选择的方式有三种:

    ?  保证由客户端主动发起关闭(即做为B端)

    ?  关闭的时候使用RST的方式

    ?  对处于TIME_WAIT状态的TCP允许重用

一般Apache的配置是:

Timeout 30 

KeepAlive On   #表示服务器端不会主动关闭链接 

MaxKeepAliveRequests 100 

KeepAliveTimeout 180 

表示:Apache不会主动关闭链接,

两种情况下Apache会主动关闭连接:

1、Apache收到了http协议?#20998;?#26377;客户端要求Apache关闭连接信息,如setRequestHeader("Connection", "close"); 

2、连接保持时间达到了180秒的超时时间,将关闭。

如果配置如下:

KeepAlive Off   #表示服务器端会响应完数据后主动关闭链接 

————–?#20889;?#29702;时——————————

nginx代理使用了短链接的方式和后端交互,如果使用了nginx代理,那么系统TIME_WAIT的数量会变得比较多,这是由于nginx代理使用了短链接的方式和后端交互的原因,使得nginx和后端的ESTABLISHED变得很少而TIME_WAIT很多。这不但发生在安装nginx的代理服务器上,而且也会使后端的app服务器上?#20889;?#37327;的TIME_WAIT。查阅TIME_WAIT资料,发现这个状态很多也没什?#21019;?#38382;题,但可能因为它占用了系统过多的端口,导致后续?#37027;?#27714;无法获取端口而造成障碍。

对于大型的服务,一台server搞不定,需要一个LB(Load Balancer)把流量分配到若干后端服务器上,如果这个LB是以NAT方式工作的话,可能会带来问题。假如所?#20889;覮B到后端Server的IP包的source address都是一样的(LB的对内地址),那么LB到后端Server的TCP连接会受限制,因为频繁的TCP连接建立和关闭,会在server上留下TIME_WAIT状态,而且这些状态对应的remote address都是LB的,LB的source port撑死也就60000多个(2^16=65536,1~1023是保留端口,还有一些其他端口缺省也不会用),每个LB?#31995;?#31471;口一旦进入Server的TIME_WAIT黑名单,就有240秒不能再用来建立和Server的连接,这样LB和Server最多也就能支持300个左?#19994;?#36830;接。如果没有LB,不会有这个问题,因为这样server看到的remote address是internet上广阔无垠的集合,对每个address,60000多个port实在是够用了。

一开始我觉得用上LB会很大程度上限制TCP的连接数,但是实验表明没这回事,LB后面的一台Windows Server 2003每秒处理请求数照样达到了600个,难道TIME_WAIT状态没起作用?用Net Monitor和netstat观察后发现,Server和LB的XXXX端口之间的连接进入TIME_WAIT状态后,再来一个LB的XXXX端口的SYN包,Server照样接收处理了,而是想像的那样被drop掉了。翻书,从书堆里面?#39029;?#35206;满?#23601;?#30340;大学时代买的《UNIX Network Programming, Volume 1, Second Edition: Networking APIs: Sockets and XTI》,中间提到一句,对于BSD-derived实现,只要SYN的sequence number比上一次关闭时的最大sequence number?#25346;?#22823;,那么TIME_WAIT状态一样接受这个SYN,难不成Windows也算BSD-derived?有了这点线索和关键字(BSD),?#19994;?#36825;个post,在NT4.0的时候,?#25925;?#21644;BSD-derived不一样的,不过Windows Server 2003已经是NT5.2了,也许有点差别了。

做个试验,用Socket API编一个Client端,?#30475;?#37117;Bind到本地一个端口比如2345,重复的建立TCP连接往一个Server发送Keep-Alive=false的HTTP请求,Windows的实现让sequence number不?#31995;?#22686;长,所?#36816;?#28982;Server对于Client的2345端口连接保持TIME_WAIT状态,但是总是能够接受新?#37027;?#27714;,不会拒绝。那如果SYN的Sequence Number变小会怎么样呢?同样用Socket API,不过这次用Raw IP,发送一个小sequence number的SYN包过去,Net Monitor里面看到,这个SYN被Server接收后如泥牛如海,一点反应没有,被drop掉了。

按照书?#31995;?#35828;法,BSD-derived和Windows Server 2003的做法有安全隐患,不过至少这样至少不会出现TIME_WAIT阻止TCP请求的问题,?#27604;唬?#23458;户端要配合,保证不同TCP连接的sequence number要上涨不要下降。

——————————————-

Q: 我正在写一个unix server程序,不是daemon,经常需要在命令行?#29616;?#21551;它,绝大

多数时候工作正常,但是某些时候会报告"bind: address in use",于是重启失

败。

A: Andrew Gierth

server程序总是应该在调用bind()之前设置SO_REUSEADDR套接字选项。至于

TIME_WAIT状态,你无法避免,那是TCP协议的一部分。

Q: 编写 TCP/SOCK_STREAM 服务程序时,SO_REUSEADDR到?#36164;?#20040;意思?

A: 这个套接字选项通知内核,如果端口忙,但TCP状态位于 TIME_WAIT ,可以重用

端口。如果端口忙,而TCP状态位于其他状态,重用端口时依旧得到一个错误信息,

指明"地址已经使用中"。如果你的服务程序停止后想立即重启,而新套接字依旧

使用同一端口,此时 SO_REUSEADDR 选项非常有用。必须意识到,此时任何非期

望数据到达,都可能导致服务程序反应混乱,不过这只是一种可能,事实上很不

可能。

一个套接字由相关五元组构成,协议、本地地址、本地端口、远程地址、远程端

口。SO_REUSEADDR 仅仅表示可以重用本地本地地址、本地端口,整个相关五元组

?#25925;?#21807;一确定的。所以,重启后的服务程序有可能收到非期望数据。必须慎重使

用 SO_REUSEADDR 选项。

linux lsof 查看进程打开那些文件 或者 查看文件给那个进程使用

No Comments 网络技术

查文件谁在使用。

lsof |grep /datashare/log/uat/frontend-api/nginx_log/apiuatacc.log

lsof命令是什么?

可以列出被进程所打开的文件的信息。被打开的文件可以是

1.普通的文件,2.目录  3.网络文件系统的文件,4.字符设备文件  5.(函数)共享库  6.管道,命名管道 7.符号链接

8.底层的socket字流,网络socket,unix域名socket

9.在linux里面,大部分的东西都是被当做文件的…..还有其他很多

怎样使用lsof

这里主要用案例的?#38382;?#26469;介绍lsof 命令的使用

1.列出所?#20889;?#24320;的文件:

lsof

备注: 如果不加任何?#38382;?#23601;会打开所有被打开的文件,建议?#30001;?#19968;下?#38382;?#26469;具体定位

2. 查看谁正在使用某个文件

lsof   /filepath/file

3.递归查看某个目录的文件信息

lsof +D /filepath/filepath2/

备注: 使用了+D,对应目录下的所有子目录和文件都会被列出

4. 比使用+D选项,遍历查看某个目录的所有文件信息 的方法

lsof | grep ‘/filepath/filepath2/’

5. 列出某个用户打开的文件信息

lsof  -u username

备注: -u 选项,u其实是user的缩写

6. 列出某个程序所打开的文件信息

lsof -c mysql

备注: -c 选项将会列出所有以mysql开头的程序的文件,其实你也可以写成 lsof | grep mysql, 但是第一种方法明显比第二种方法要少打几个字符了

7. 列出多个程序多打开的文件信息

lsof -c mysql -c apache

8. 列出某个用户以及某个程序所打开的文件信息

lsof -u test -c mysql

9. 列出除了某个用户外的被打开的文件信息

lsof   -u ^root

备注:^这个符号在用户名之前,将会把是root用户打开的进程不让显示

10. 通过某个进程号显示该进行打开的文件

lsof -p 1

11. 列出多个进程号对应的文件信息

lsof -p 123,456,789

12. 列出除了某个进程号,其他进程号所打开的文件信息

lsof -p ^1

13 . 列出所有的网络连接

lsof -i

14. 列出所有tcp 网络连接信息

lsof  -i tcp

15. 列出所有udp网络连接信息

lsof  -i udp

16. 列出谁在使用某个端口

lsof -i :3306

17. 列出谁在使用某个特定的udp端口

lsof -i udp:55

特定的tcp端口

lsof -i tcp:80

18. 列出某个用户的所有活跃的网络端口

lsof  -a -u test -i

19. 列出所有网络文件系统

lsof -N

20.域名socket文件

lsof -u

21.某个用户组所打开的文件信息

lsof -g 5555

22. 根据文件描述列出对应的文件信息

lsof -d description(like 2)

23. 根据文件描述范围列出文件信息

lsof -d 2-3

http://blog.csdn.net/kozazyh/article/details/5495532

一看必会系列:解决vmware 虚拟机占空间越来越大的问题

No Comments 网络技术

 

用长后 会出现 Windows 7 x64-0-000001-s003

虚机名-0-000001-s003  类似的文件还都挺大,现在需要清理。

image

方式如下

 

1.右键点击相应VM

2.管理

3.磁盘清理。

4.完成

 

5. 右键设置 ?#25165;?碎片整理

6.压缩

 

方案2

  • 虚拟机内部执行
  • cat /dev/zero > zero.fill;sync;sleep 1;sync;rm -f zero.fill后关闭虚拟机
  • 宿主win10机器上进入虚拟机文件目录执行
  • "C:\Program Files (x86)\VMware\VMware Workstation\vmware-vdiskmanager.exe" -k Ubuntu64.vmdk
    最终效果也可以将空间降下来。不需要额外工具,更方便些。
  •  

     

    image

    一看必会系列:confluence 不显示验证码的解决方案

    真正的解决方案

    Cause

    This is caused because of missing fonts, due to which the application cannot perform graphics rendering. Although we support OpenJDK it’s likely that this issue was caused because, the package manager used to install Java didn’t install "Java fonts".

    Resolution

    1. Install the JDK Fonts package on top of the Oracle JDK by running:

      sudo apt-get install deja*

     

     

     

    下面的都没毛用,不用看

     

    https://confluence.atlassian.com/confkb/captcha-image-does-not-display-when-confluence-is-hosted-on-a-non-english-system-310379212.html

    Resolution

    • Restart Confluence

    o configure System Properties in Linux installations:

    1. Edit the <installation-directory>/bin/setenv.sh file. 
    2. Find the section CATALINA_OPTS=

      (this is JAVA_OPTS= in Confluence 5.5 and earlier)

    3. Refer to the list of parameters in Recognized System Properties.

    (info) Add all parameters in a space-separated list, inside the quotations.

     

     

    Windows (starting from .bat file)

    To Configure System Properties in Windows Installations When Starting from the .bat File:

    1. Edit the <installation-directory>/bin/setenv.bat file. 
    2. Find the section set CATALINA_OPTS=%CATALINA_OPTS%

      (this is JAVA_OPTS=%JAVA_OPTS% in Confluence 5.5 and earlier)
    3. Refer to the list of parameters in Recognized System Properties.

    (info) Add all parameters in a space-separated list. Make sure to keep the string %CATALINA_OPTS% in place.

    30选5玩法