1:系统环境变量 用户环境变量
环境变量就是一些被指定的文件夹路径,目的是为了更快速方便的找到想要的文件和文件夹。
按变量的生存周期来划分,Linux变量可分为两类:
1 永久的:需要修改配置文件,变量永久生效。
2 临时的:使用export命令声明即可,变量在关闭shell时失效。
1 在/etc/profile文件中添加变量【对所有用户生效(永久的)】
例如:编辑/etc/profile文件,添加CLASSPATH变量
# vi /etc/profile
exportCLASSPATH=./JAVA_HOME/lib;
$JAVA_HOME/jre/lib
注:修改文件后要想马上生效还要运行# source /etc/profile不然只能在下次重进此用户时生效。
2 在用户目录下的.bash_profile文件中增加变量【对单一用户生效(永久的)】
例如:编辑guok用户目录(/home/guok)下的.bash_profile
vi/home/guok/.bash.profile添加如下内容:exportCLASSPATH=./JAVAHOME/lib;JAVA_HOME/jre/lib
3 直接运行export命令定义变量【只对当前shell(BASH)有效(临时的)】
在shell的命令行下直接使用[export 变量名=变量值] 定义变量,该变量只在当前;的shell(BASH)或其子shell(BASH)下是有效的,
如我们在安装node.js的时候,需要给node和npm设置全局环境使用,我们可以使用软连接:
ln -s /opt/nodejs/node-v9.8.0-linux-x64/bin/node /usr/local/bin/node
ln -s /opt/nodejs/node-v9.8.0-linux-x64/bin/npm /usr/local/bin/npm
因为/usr/local/bin/已经被添加到.bash_profil文件中,所以我们使用node或者npm命令的时候,会被快捷链接到opt目录下的目录
比如我们需要配置npm全局安装
//1.新建一个全局安装的路径
mkdir ~/.npm-global
//2.配置npm使用新的路径
npm config set prefix '~/.npm-global'
//3.打开或者新建~/.profile,加入下面一行
export PATH=~/.npm-global/bin:$PATH
//4、更新系统环境变量
source ~/.profile
2:用户与用户组
超级用户root(0)
程序用户(1~499)
普通用户(500~65535)
与用户相关的配置文件
/etc/passwd: #用户的配置文件, 保存用户账户的基本信息
/etc/shadow #用户影子口令文件
在passwd文件中,第一行内容就是超级用户root行,可以看到它的uid和gid都为0.为了方便理解,下面是各字段的描述:
root:x:0:0:root:/root:/bin/bash
字段1:帐号名,这是用户登陆时使用的账户名称,在系统中是唯一的,不能重名
字段2:密码占位符x;早期的unix系统中,该字段是存放账户和密码的,由于安全原因,后来把这个密码字段内容移到/etc/shadow中了。
这里可以看到一个字母x,表示该用户的密码是/etc/shadow文件中保护的。
字段3:UID;范围是0-65535
字段4:GID;范围是0-65535;当添加用户时,默认情况下会同时建立一个与用户同名且UID和GID相同的组。
字段5:用户说明;这个字段是对这个账户的说明
字段6:宿主目录;用户登陆后首先进入的目录,一般与"/home/用户名"这样的目录
字段7:登录Shell 当前用户登陆后所使用的shell,在centos/rhel系统中,默认的shell是bash;如果不希望用户登陆系统,可以通过usermod
或者手动修改passwd设置,将该字段设置为/sbin/nologin 即可。大多数内置系统账户都是/sbin/nologin,这表示禁止登陆系统。
这是出于安全考虑的。
passwd中有关UID的限制说明
0:当用户的UID为0时,表示这个账户为超级用户;如果要增加一个系统管理员账户的话,只需将该账户的UID改为0即可。不建议
1~499:这个范围是保留给系统用户使用的UID
500~65535:普通账户UID
用户的影子口令文件/etc/shadow
与用户组相关的配置文件
/etc/group #用户组配置文件
/etc/gshadow #用户组的影子文件
/etc/group的文件内容为:
adm:x:4:adm,daemon
group文件各个字段的详细说明:
字段1:组账户名称
字段2:密码占位符x;通常不需要设置该密码,由于安全原因,该密码被记录在/etc/gshadow中,因此显示为'x'。这类似/etc/shadow
字段3:组账户GID号,用户组ID
字段4:本组的成员用户列表;加入这个组的所有用户账号
用户组的影子文件/etc/gshadow
3:权限控制
Linux的文件和目录有以下三种方式:
r 、w 、x:可读,可写 、可执行
Linux的文件和目录又可以有三个所有者概念
u、g 、o: 所有者 、所属组 、其他人
Linux中,常用的文件类型为以下三种:
d :目录 directory, - : 二进制文件 binary, l : 软链接文件 link
查看文件权限:
ls -l /
dr-xr-xr-x : 我们可以把它拆开来解读 , d r-x r-x r-x
d表示文件类型,这里是目录
第一个r-x表示所属用户的权限
第二个r-x表示所属组的权限
第三个r-x表示其他用户的权限
权限管理命令:chmod命令
命令名称:chmod
命令英文原意:change the permission mode of a file
语法: chmod 【mode】 文件或目录 此处mode是啥???是数字
前面我们说了一个文件或者目录分别有所有者 (u)、所属组u(g)和其他人(o)对其的权限,
而权限又分为:(r)可读 、(w)可写 、(x)可执行
为了方便表示,linux用了一个很简单的方法来区别,r用4表示,w用2表示,x用1表示,把他们对号入座:
r - 4
w - 2
x - 1
所以
(r-xr-xr-x)就可以这么转换啦!!!
(4+0+1)+(4+0+1)+(4+0+1)= 555
例如 764 :对应的就是将7分解为4 、2 、1,将6分解为4 、2 、0,将4分解为4 、0 、0,所有对应权限为rwxrw-r—
关于系统用户与普通用户的权限交叉问题
比如现在我们有一个系统用户gitlab-runner:他负责监听git合并命令,并执行shell脚本,来拉取代码
我们遇到的第一个问题是:gitlab-runner没有权限cd到指定目录,因为指定目录是有权限限制的,如果指定目录是一个叫admin的用户创建的,gitlb-runner也许就没有cd到该目录的权限,这里有两个解决方案:
1:给gitlab-runner设置为root权限,就是在/etc/passwd里面找到gtilab-runner 给他的uid设置为0,表示root用户,
2:将gitlab-runner拉入admin用户所属的组中,然后将该目录的读写权限赋予这个组,这个时候gitlab-runner就有这个目录的cd权限了
在项目开发中,我一开始使用的第一个方案,毕竟简单 一劳永逸,但是会遇到一个问题,使用gitlab-runner拉去的git代码,当前admin用户并没有权限读取,这很好理解,因为gitlab-runner是root用户,而使用gitlab-runner去拉取代码,相当于使用root去创建一个文件,普通用户admin当然是没有权限读取这个文件的,
这个时候我是这样解决的:
首先将gitlab-runner的uid设置为0,这样gitlab-runner就会拥有所有文件的读写权限,然后将gitlab-runner的gid改为admin所属的组,这样使用gitlab-runner创建的文件,因为admin与gitlab-runner属于同一个组,所以admin也就可以读取这个文件了
这里还有一个插曲,我现在本地使用git clone代码的时候,clone下来的代码文件所属用户和所属组都是root,这个权限太高了,所以在clone下来后,我把文件的所属用户和所属组改为admin,
4:ssh
定义:
安全外壳协议(SSH)是一种在不安全网络上提供安全远程登录及其它安全网络服务的协议。
密钥生成:ssh-keygen
Linux系统中默认生成的位置是/root/.ssh目录,如果我们是以普通用户登录的我们最好将位置切换成/home/你的用户名/.ssh目录里,就是你生成sshkey的时候不是要选择位置吗,那个时候选择你的home下的位置
ssh连接;
fuser -n tcp 3000 查询3000被哪个pid占用
kill pid
npm安装环境问题
linux采用严格的用户环境区分,a用户安装的npm不可能给到b用户使用,这是显而易见的,通常的误区在于当前用户与超级用户之间的关系,你要确定你安装的npm是希望安装给超级用户还是当前用户 通常在安装Node或者npm的时候 某些时候需要管理员权限,然后我们直接sudo –s切换到超级用户环境 这就悲剧了 我们在不知情的情况下在超级用户中安装了npm