When deployed to a production environment, you cannot use the highest permissions such as root. Everything is given the minimum permissions. In RedHat systems, there are also restrictions such as SELinux. The company should make you familiar with the corresponding environment. If you are not restricted from using the highest authority such as root, and you use yum update to upgrade system components, and you can install all the software you want into the system, other people's things may be messed up.
The system running in the production environment may already have many things running. Once the system things are changed, it will affect the original environment. Many things can be compiled statically and do not need to be limited to the environment of the server itself.
Although things like yum are convenient, they are not very helpful for demanding environments, so many things on Linux need to be compiled by yourself.
Nginx itself can add many third-party modules. If you are not used to the happy time of compilation under Linux, but rely on yum and apt, it may affect future development.
The developer's identity on the production server is limited to updating the program code under strict logging and monitoring after the programming is completed, which is reasonable.
But at the same time, for the development work itself, it is also necessary to prepare a debugging server with a complete and accurate environment for developers, relatively loose permission control, and limited resources. Otherwise, you won’t be able to do the developer’s job.
Instead of using a software repository, you waste your energy on the useless labor of manually compiling modules. This pushes developers too far.
Don’t even want to separate the production server and the debugging server. This is a way to die. Such a waste of human and financial resources will never be worth the value of a mere debugging environment.
Supplement: If you insist on making the debugging server and the production server exactly the same, it would be too dogmatic. Debugging is debugging. It is very normal for permissions to be relaxed midway, new software to be temporarily introduced, or even wrong software to be installed and then deleted. As long as the programmer can accurately grasp the system requirements and dependency requirements of the code, there will be no problem.
No. When installing software, try to use it from the source. But I'm from Debian system, so I don't know what's going on with rpm.
Of course the service program does not require the root user. However, the service program should not use the developer's user identity, but should use a separate user for each service.
I think your problem is not about whether the service needs root permissions, but about server management. A server administrator should be designated to uniformly manage operations such as installation and upgrade of services. Or give you su permissions, but there must be a set of specifications.
![[Web front-end] Node.js quick start](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
When deployed to a production environment, you cannot use the highest permissions such as root. Everything is given the minimum permissions. In RedHat systems, there are also restrictions such as SELinux. The company should make you familiar with the corresponding environment. If you are not restricted from using the highest authority such as root, and you use yum update to upgrade system components, and you can install all the software you want into the system, other people's things may be messed up.
The system running in the production environment may already have many things running. Once the system things are changed, it will affect the original environment. Many things can be compiled statically and do not need to be limited to the environment of the server itself.
Although things like yum are convenient, they are not very helpful for demanding environments, so many things on Linux need to be compiled by yourself.
Nginx itself can add many third-party modules. If you are not used to the happy time of compilation under Linux, but rely on yum and apt, it may affect future development.
This is too stingy.
The developer's identity on the production server is limited to updating the program code under strict logging and monitoring after the programming is completed, which is reasonable.
But at the same time, for the development work itself, it is also necessary to prepare a debugging server with a complete and accurate environment for developers, relatively loose permission control, and limited resources. Otherwise, you won’t be able to do the developer’s job.
Instead of using a software repository, you waste your energy on the useless labor of manually compiling modules. This pushes developers too far.
Don’t even want to separate the production server and the debugging server. This is a way to die. Such a waste of human and financial resources will never be worth the value of a mere debugging environment.
Supplement: If you insist on making the debugging server and the production server exactly the same, it would be too dogmatic. Debugging is debugging. It is very normal for permissions to be relaxed midway, new software to be temporarily introduced, or even wrong software to be installed and then deleted. As long as the programmer can accurately grasp the system requirements and dependency requirements of the code, there will be no problem.
How to monitor port 80 without root privileges?
A bit ridiculous?
No. When installing software, try to use it from the source. But I'm from Debian system, so I don't know what's going on with rpm.
Of course the service program does not require the root user. However, the service program should not use the developer's user identity, but should use a separate user for each service.
I think your problem is not about whether the service needs root permissions, but about server management. A server administrator should be designated to uniformly manage operations such as installation and upgrade of services. Or give you su permissions, but there must be a set of specifications.