NFS Mount

原文

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
# On the Host
sudo apt install nfs-kernel-server
sudo mkdir /var/nfs/general -p
sudo chown nobody:nogroup /var/nfs/general
sudo vim /etc/exports

# exports on the host
# /var/nfs/general x.x.x.x(rw,sync,no_subtree_check)
sudo systemctl restart nfs-kernel-server

# On the Client
sudo apt install nfs-common

sudo mkdir -p /nfs/general
sudo mount x.x.x.x:/var/nfs/general /nfs/general

# At Boot
sudo vim /etc/fstab
# /etc/fstab
# x.x.x.x:/var/nfs/general /nfs/general nfs auto,nofail,noatime,nolock,intr,tcp,actimeo=1800 0 0

# Unmounting
sudo umount /nfs/home

NFS 权限

转载

默认规则

默认的权限规则是,root用户被映射成nfsnobody用户,对于客户端机器上和NFS服务器上UID相同的用户会对应映射,其它非root用户被映射成nobody用户。当root用户访问共享目录时是以nfsnobody用户访问共享目录的,具有什么权限看下共享目录权限便知。客户端机器上和NFS服务器上的相同UID用户,以NFS服务器上的用户访问共享目录,看戏目录权限便知。其它非root用户则映射成nobody用户,有啥权限一看便知。

选项

  • ro:默认选项,以只读的方式共享。
  • rw:以读写的方式共享。
  • no_root_squash:将客户端使用的是root用户时,则映射到FNS服务器的用户依然为root用户。
  • all_squash:默认选项,将所有访问NFS服务器的客户端的用户都映射为匿名用户,不管客户端使用的是什么用户。
  • anonuid:设置映射到本地的匿名用户的UID
  • anongid:设置映射到本地的匿名用户的GID
  • sync:默认选项,保持数据同步,数据同步写入到内存和硬盘。
  • async:异步,先将数据写入到内存,在将数据写入到硬盘。
  • secure:NFS客户端必须使用NFS保留端口(通常是1024以下的端口),默认选项。
  • insecure:允许NFS客户端不使用NFS保留端口(通常是1024以上的端口)。

EXAMPLE

配置文件: /etc/exports
/mount/www 192.168.x.x/24(rw,all_squash,anonuid=500,anongid=500)

PowerShell Remoting && Job

远程

WinRM 打开: Enable-PSRemoting -force

1
2
3
4
5
6
7
8
##交互
Enter-PSSession -ComputerName XXXName -Credential domainxxx\userxx
##运行远程命令
Invoke-Command -ComputerName SErver01, SErver02 -ScriptBlock {...}
Invoke-Command -ComputerName SErver01, SErver02 -FielPath c:\Scripts\...
##建立连接
$s = New-PSSession -ComputerName SErver01, SErver02
Invoke-Command -Session $s ...

远程编辑

  • 使用vs code 中的powershell插件 ,进入其集成的PS环境,远程后调用psedit.

JOB

1
2
3
4
5
6
7
8
9
10
11
Start-Job -ScriptBlock {...}
$job = Get-Job -Id 1
##查询结果
Receive-Job -Job $job
##删除
Remove-Job -Job $job
##查找失败原因
$job.ChildJobs[0].JobStateInfo.Reason
##远程
Invoke-Command -ComputerName SErver01 -ScriptBlock {...} -asjob
Invoke-Command -Session $s -ScriptBlock { start-job -ScriptBlock { ... }}

PowerShell && FireWall

PowerShell 设置防火墙

1
2
3
4
5
##关闭防火墙
Get-NetFirewallProfile | Set-NetFirewallProfile -enabled false
##允许ping
Set-NetFirewallRule –Name “FPS-ICMP4-ERQ-In” –Enabled True
Set-NetFirewallRule –Name “FPS-ICMP4-ERQ-Out” –Enabled True

netsh 命令行修改网络配置

netsh example

1
2
3
4
5
6
7
netsh
netsh>interface ip show config
netsh>netsh interface ip set address "connection name" static 192.168.x.x 255.255.255.0 192.168.x.x
netsh>netsh interface ip add dns "connection name" 8.8.8.8
netsh>netsh interface ip add dns "connection name" 114.114.114.114 index=2
netsh>netsh interface ip set address "connection name" dhcp
netsh>netsh interface ip set dns "connection name" dhcp

Docker entrypoint vs cmd

原文

Docker has a default entrypoint which is /bin/sh -c but does not have a default command.

When you run docker like this: docker run -i -t ubuntu bash the entrypoint is the default /bin/sh -c, the image is ubuntu and the command is bash.

The command is run via the entrypoint. i.e., the actual thing that gets executed is /bin/sh -c bash. This allowed Docker to implement RUN quickly by relying on the shell’s parser.

Later on, people asked to be able to customize this, so ENTRYPOINT and –entrypoint were introduced.

Everything after ubuntu in the example above is the command and is passed to the entrypoint. When using the CMD instruction, it is exactly as if you were doing docker run -i -t ubuntu . will be the parameter of the entrypoint.

You will also get the same result if you instead type this command docker run -i -t ubuntu. You will still start a bash shell in the container because of the ubuntu Dockerfile specified a default CMD: CMD [“bash”]

As everything is passed to the entrypoint, you can have a very nice behavior from your images. @Jiri example is good, it shows how to use an image as a “binary”. When using [“/bin/cat”] as entrypoint and then doing docker run img /etc/passwd, you get it, /etc/passwd is the command and is passed to the entrypoint so the end result execution is simply /bin/cat /etc/passwd.

Another example would be to have any cli as entrypoint. For instance, if you have a redis image, instead of running docker run redisimg redis -H something -u toto get key, you can simply have ENTRYPOINT [“redis”, “-H”, “something”, “-u”, “toto”] and then run like this for the same result: docker run redisimg get key.