前端学习nginx二

这一期我们来分享几个nginx容易遇到的问题：

nginx: [emerg] bind() to 0.0.0.0:80 failed (48: Address already in use)

ryan:~ ryan$ sudo nginx    //启动nginx
nginx: [emerg] bind() to 0.0.0.0:80 failed (48: Address already in use)
nginx: [emerg] bind() to 0.0.0.0:80 failed (48: Address already in use)
nginx: [emerg] bind() to 0.0.0.0:80 failed (48: Address already in use)
nginx: [emerg] bind() to 0.0.0.0:80 failed (48: Address already in use)
nginx: [emerg] bind() to 0.0.0.0:80 failed (48: Address already in use)
nginx: [emerg] still could not bind()

错误提醒的多明显。”bind() to 0.0.0.0:80 failed “。

1. 我们可以很容易猜到大概意思就是不能使用80端口。
2. 再猜一下，80端口可能被占用了。
3. 我们先验证下80端口有没有被占用。
4. 如果被占用关闭之前的进程，再启动一次nginx.

mac 查看端口是否被占用。

// 查80端口是被什么进程占用
lsof -i tcp:80

kill -9 pid

window 查看端口是否被占用。

//cmd下运行如下命令
netstat  –ano

Proto Local Address	Foreign Address	State	PID
TCP	0.0.0.0:80	0.0.0.0:0 LISTENING	656

上面找到了占用80的pid,然后

C:\>Taskkill /PID 656 /F

当然也可以能过运行

C:\>tasklist   //找到656这个进程所对应的程序名。然后直接通过任务管理器关闭相应的进程就行了。

ps

有时候我们可能已经开启了nginx服务。再次开启nginx服务，毫无疑问会报上面的错误。如果是在生产环境，就不要中断服务了。可以如下操作

sudo nginx -s reload

如果确实想重启nginx。可以如下操作：

sudo nginx -s stop
sudo nginx

当我们重新配置一个新的nginx服务访问时出现”403 Forbidden“解决方法

当我们在访问 http://localhost 时屏幕显示”403 Forbidden
nginx/1.12.0”。 当然里的前端我们先配置了80端口下的这个服务。
现在我们先来猜问题：

1. 403 forbidden => 懂点英文的都会知道。被禁止了。
2. 我们再顺着被禁止了去猜。假如我们被禁止进入某一场所，说明我们是没有权限。
3. 大概猜到是权限问题。大致会出现两种权限的可能： 我们没有权限访问服务器。我们的服务器没有权限访问网站所对应的文件。
4. 再稍稍猜一下。自已配置的服务器怎么会不让自己访问。我们就可以排除第一种可能啦。我们先假设可能是服务器不能访问网站所对应的文件去试试。

修改文件访问权限

shell>chmod-R 755 /usr/local/nginx/html

重启了下nginx服务器好像真的可以访问。验证了我们的猜想。
我自己遇到过一次改了权限，仍不能访问的情况。
最终发现是文件组受了限制。

//不可访问路径
drwxrwxrwx   4 ryan（用户/属主）  staff(属组)  136  9 26 00:12 nginx

//可访问路径
drwxr-xr-x  2 ryan  admin      68  9 26 00:11 www

//改变所属的组
chown -R ryan:admin /Users/ryan/Documents/www/nginx/test/

拓展

按如上的方式修改文件所属的组，细想不是很合理，上面只是说了是权限问题,没有说得足够细，以及为什么要将staff组改成admin组。这里继续补充。

liunx下的用户和用户组

linux是多用户和多任务的系统，很可能存在多人同时使用一台liunx主机工作的情况。为了考虑每个人的隐私权，以及每个人的喜欢的工作环境。因此设计了“用户和用户组”这样的“文件所有者”。正因为此所以某一用户在访问其他用户的文件时为存在权限问题。

上面所讲的内容如何和我们遇到的nginx的问题关联起来。

//linux 命令行下执行
ps aux | grep nginx
nobody           64601   0.0  0.0  4304288   1224   ??  S     3:07下午   0:00.00 nginx: worker process
root             64600   0.0  0.0  4301984    580   ??  Ss    3:07下午   0:00.00 nginx: master process nginx
// 我们可以看到nginx 的工作进程的用户是nobody，即nobody这个用户运行的nginx的工作进程。 root这个用户运行的nginx的主进程。
//这里就要发问了，为什么主进程是root用户的，工作进程是nobody这个用户的？
//主进程归root用户是因为启动nginx的时候使用的是"sudo nginx",明白了吧！工作进程归nobody是因为在nginx.conf配置当中我们设置的user是nobody(user设置运行nginx的用户);   user user [group];    

//这个时候我们去查看网站根目录所属的用户及用户组
ls -l
drwxr-xr-x   6 ryan  staff      192  6  2 00:56 website.root
//我们可以看到用户是ryan 用户组是staff.

//到这里很清楚了吧。  一个nobody的用户想要去访问ryan的文件。你死不死当然没有权限啦！

//悟性高的可能已经知道要怎么改了。这里我们先不说怎么改，引了别一个问题。眼尖的同学可能会问了，  staff是什么用户组？

Linux 中的 wheel 组和 staff 组 及admin组区别。

The wheel group is used to control those people that can su to the root user (though this is made irrelevant by the sudo command).

All of the users on your system will be in the staff group, so by changing group ownership of files to staff the group permissions will apply to all users. All of the administrators on your system will be in the wheel group, so by changing group ownership of the files to wheel group permissions will apply to all of the administrators, global permissions will apply to any other users.

My advice is that, except for files that you have created, you leave the group ownership and permissions alone. Unix is very particular about file ownership and permissions in certain areas and changing them only leads to trouble.

所有的用户都属于 staff 组，

只有具有管理员性质的用户位于 wheel 组中。

wheel 是一个特殊的用户组，该组的用户可以使用 su 切换到 root，而 staff 组是所有普通用户的集合。

admin组就不用说了，翻译过来就知道了管理员组。

讲到这里可能不用说如何修改上述403的问题都知道如何修改了。

把nginx的启动用户改成root；

user root staff;

//我试着直接设置，重载nginx的时候报错了。看来限制了root用户必须要带上组。
user root;

//设置user nobody,并没有报错，说明对nobody并没有此限制，我猜想原因是有nobody用户，也有nobody组，而有root用户而没有root组。

有兴趣的可以去了解一下”/etc/group和/etc/passwd及/etc/shadow文件”主个文件的内容。

今天的分享先到这里了。