R.T.
一台运行编译安装配置 CentOS 系统、用于处理 Web 请求的服务器应该怎样处理一下关系：
天蓬老师2017-04-17 11:49:48
I was writing a set of virtual host panels before and now, so I have some ideas about permission control. I will share here the permission control scheme I designed. It should be considered relatively strict. Of course, this may not be the mainstream scheme.
The services below refer to software such as databases, and applications refer to programs written by yourself.
All data is placed in /home, for example, mysql data is placed in /home/mysql/data; application files are placed in /home/myapp/web, and each application uses a separate user to isolate permissions. Because the data is all in /home, just mount /home separately.
Each service is run by a separate user. Various services do not listen to local ports, but to unix sockets, because this allows the file system to be used for more flexible permission control.
Most files have permissions of 750, which means that they have full permissions, and users in the same group can read and run them, but other users cannot read them. When a service needs to read a file from another application, add the service's user to the group of the application that is using the file. For example, if nginx needs to read the static files of myapp, then add http to the myapp group.
Unix sockets are slightly different. For example, myapp (Python App) monitors a unix socket to provide HTTP services. Nginx needs to reverse this service, so the permissions of this unix socket file need to be 770, otherwise Nginx cannot write this. The file cannot be requested on your behalf.
When using a database, each application must use a different account, such as the very good permission system that comes with MySQL.
For services without permission control such as memcached, you should run a separate instance for each application, and then use unix socket for permission control.
As for the deployment of source code, I personally prefer to push the code to a separate source code server (it can be Github or a self-built GitLab), and then manually pull it from the server when publishing. The advantage of this is that it has a production environment Independent history, the source code server does not need to contain sensitive information such as account and password, this information only exists in the history of the production environment.
SELinux has never been used.
PHP中文网2017-04-17 11:49:48
Share my organizational method. I feel that the application scenarios are similar to the topic.
Directory structure and multiple disk mount points
Create a /data in the root directory and mount a separate disk here.
This directory contains many subdirectories.
/data
|-- app/ # 网站程序
|-- log/ # 各种日志
|-- ftp/ # ftp 的根
|-- db/ # 数据库的数据文件
|-- op/ # op 专用的目录，放一些运维相关的脚本文档什么的
|-- ... # 更多的分类，根据需求添加
If you have multiple disks, do not create multiple roots. Instead, use a soft link to link a directory under /data to the new disk. For example, the above ftp/ can be a soft link pointing to other disks, so that it does not take up the space of /data~ As for where the other disks are hung, it doesn’t matter. You can just put them in /mnt, which is easy to find. That’s it.
I will install the system program normally in /usr/local/*, put the configuration in the common /etc/ of the system, and put some temporary files during runtime in /var/run/*, but the program log must be managed. I'll put it in /data/log/*.
For example, mysql, binary is placed in /usr/local/bin/mysql*, configuration is placed in /etc/mysql/*, data is placed in /data/db/mysql/3306/*, and log is placed in /data/log/mysql/3306/mysql_err.log. Among them, binlog is part of the data, so it is placed in /data/db.
Multi-user management
I usually disable system default account login for security reasons, CentOS is root, and disable password login. All can only be logged in with key, and enable UsePAM yes. For details, you can look at /etc/ssh/sshd_config, which has very detailed notes. If you are not sure, you can look it up online.
The fewer users who can log in, the better. I usually only have two, one ordinary user and one super user who can sudo put these two in different groups. Use the PAM policy to only allow users from these two groups to log in. /etc/sudoers also authorizes the groups. This way, if you need to add an account temporarily in the future, it will be convenient, and you only need to put it in the corresponding group.
Generally use www-data to enable an application. This is a user who is not allowed to log in, and the shell is set to /sbin/nologin.
For example, mysql likes to use the user mysql. It will be automatically created during installation, so just let it go.
ftp is special. Generally, the user name is called ftp, and home is set at the root of ftp, not /home. If you need to have multiple ftp accounts, you can consider using proftpd's virtual account to avoid the security issues of creating many accounts that can be logged in. However, I have not actually encountered this need myself, so I don't know what other problems there may be with virtual accounts.
Directory permissions
I don’t think you need to worry too much about directory permissions. After all, you are not building a VPS for many people, so just make sure the owner/group is correct and try to give normal permissions.
For example, the owner of the directory where the web code is placed is www-data, the group is its group, and the directory permissions are 0755. The directories inside are authorized according to the situation. Generally, it is 0644. If it needs to be executable, it can be changed to 0754 or 0755. Some content that needs to be kept confidential from ordinary users (password configuration, etc.) can be set to 0600.
/data/op This directory is special because operation and maintenance scripts are generally very sensitive. I tend to set the owner to root and the permissions to 0700. But remember not to set the directories inside /data/op to have such permissions. It is unnecessary and difficult to manage. Just keep it normal.
SELinux
Disable it, it’s very annoying and I don’t want to use it.