2.17 新手必看的Linux服务器管理和维护注意事项

Why can’t the remote server shut down? The reason is very simple, the remote server is not placed locally, who will help you press the power button to start the server after shutdown? Although computer technology is changing with each passing day, tasks such as plugging in power and turning on the computer still need to be done by hand. If the server is remote, once it is turned off, you can only turn it on to the administrator in the hosting room.

There are two things to be aware of when the remote server is restarted.

The computer’s hard disk is most afraid of power outage or reboot during high-speed storage, which is very easy to cause hard disk damage. So, stop your service before restarting, or even consider temporarily disconnecting the network that provides services.

Maybe you think the server is so delicate? My laptop is often forcibly shut down, but I don’t find that the hard drive is damaged. This is because your personal computer is not accessed by many people, and the hard disk does not exchange data during a forced power outage. Caution is the parent of safety!

Restart and shutdown are also operating specifications that servers need to pay attention to, and incorrect restarts and shutdowns cause server failures.

At the peak of server access, if you use some commands that are under great pressure on the server, it may cause the server to respond slowly or even crash.

The peak of server access is generally considered to be between 17:00 and 24:00. Of course, the specific services provided by each server are different, and the peak periods of access sometimes vary. For example, if the server is mainly accessed by the American people, you have to consider the jet lag; or the service provided by the server is very special, and the peak periods of access may be different.

Heavy load commands are generally recommended to be executed between 4:00 and 5:00 in the morning. So, does that mean we need to work in the wee hours of the morning? Of course not. Who can stand that? We can use the scheduled tasks of the system to allow the operation to be performed automatically within a specified period of time.

Firewalls can be hardware firewall devices or firewall software installed on the server.

To put it simply, a firewall is a network device that determines whether a packet is allowed to pass through according to its own parameters. If our server is to be used safely in the public network, we need to use a firewall to filter harmful packets.

Firewall configuration is completed entirely by manual commands, configuration rules and configuration commands are also relatively complex, in case the setting is absent-minded, a tragedy occurs. How can this situation be avoided?

The best way, of course, is to configure a firewall locally on the server, so that even if your remote login is filtered, you can restore it through local login. If the server is already logged in remotely and you want to configure a firewall, it is best to upload it after the local test is complete, which will minimize the probability of failure.

Although it has been tested locally, problems can still occur when uploading to the remote server. So the author thought of a stupid way, if you need to configure the firewall remotely, first write a system timing task and let it clear the firewall rules every 5 minutes, even if you write it wrong, there is still a chance to go back on your promise. Wait until there is no problem with the test, and then delete the system timing task.

In short, you can use a variety of methods, as long as you are careful not to kick yourself off the server when configuring the firewall.

In addition to the previous introduction that setting passwords requires compliance with the three principles of complexity, easy memory and timeliness, we also need to pay attention to the preservation of passwords.

Our simplest principle for daily use is to write down passwords. There may be many servers, it is not possible for all servers to use the same password, it is best to have different passwords for each server (but it is not realistic in actual work). The general practice is to classify the servers, and each type of server has the same password, which can effectively reduce the number of passwords. But with a large number of servers, the number of passwords is frightening.

For example, when the author was engaged in game operation and maintenance, there were more than 2000 servers, plus network equipment such as switches and routers, although the method of using the same password for each type of server was adopted, the total number of passwords was still more than 100. Memorizing the password at this time is basically an impossible task. So, how do you save these passwords? Can only be saved through documents, of course, these documents can not be saved in clear text, but to be encrypted.

In short, a reasonable password needs to be saved in an appropriate way, which must be considered when building a server architecture.

The management server should follow the most basic principle of “giving users minimum permissions”.

In the actual work, the more important the server, the stricter the management of permissions. In principle, on the premise that the work can be done, the smaller the permissions assigned, the safer it is. Of course, the smaller the permissions, the more planning and permission allocation tasks you need to do, but the more reliable the server is.

If there is no backup server, it is killing!

There are a lot of people around me, the phone is broken or dead, the address book is gone; the hard drive of my computer is broken, the information above can no longer be found, and I have no sense of backup at all. Individual losses are often bearable, but corporate server losses can be staggering.

Some people know that backup is important, but because they are lazy or forget, it is too late to regret. A lot of things are easier known than done, backup is not the slightest fluke. If the main profit item of the company is the business on the Internet, then the loss of data may result in the direct loss of profits of the company.