From 3d911a4cba691117775b5e59d24e7e15911beba0 Mon Sep 17 00:00:00 2001 From: Xingyu Wang Date: Thu, 24 Dec 2020 22:18:14 +0800 Subject: [PATCH] TSL&PRF --- ...your first 10 minutes on a Linux server.md | 175 ------------------ ...your first 10 minutes on a Linux server.md | 167 +++++++++++++++++ 2 files changed, 167 insertions(+), 175 deletions(-) delete mode 100644 sources/tech/20201215 9 things to do in your first 10 minutes on a Linux server.md create mode 100644 translated/tech/20201215 9 things to do in your first 10 minutes on a Linux server.md diff --git a/sources/tech/20201215 9 things to do in your first 10 minutes on a Linux server.md b/sources/tech/20201215 9 things to do in your first 10 minutes on a Linux server.md deleted file mode 100644 index e277ec66a6..0000000000 --- a/sources/tech/20201215 9 things to do in your first 10 minutes on a Linux server.md +++ /dev/null @@ -1,175 +0,0 @@ -[#]: collector: (lujun9972) -[#]: translator: (wxy) -[#]: reviewer: ( ) -[#]: publisher: ( ) -[#]: url: ( ) -[#]: subject: (9 things to do in your first 10 minutes on a Linux server) -[#]: via: (https://opensource.com/article/20/12/linux-server) -[#]: author: (Gaurav Kamathe https://opensource.com/users/gkamathe) - -9 things to do in your first 10 minutes on a Linux server -====== -Before putting a newly provisioned server to work, make sure you know -what you're working with. -![Parts, modules, containers for software][1] - -When I test software on Linux (a regular part of my job), I need to use multiple servers with various architectures running Linux. I provision the machines, install the required software packages, run my tests, gather the results, and return the machine to the pool so that others can use it for their tests. - -Since I do this so often (even multiple times a day), my first 10 minutes on a Linux server have become a daily ritual. When I first log into a Linux server, I look for certain things using commands to gather the information I need. I'll go through my process in this article, but please note that, in most cases, I'll just give the command name, so you will need to identify the specific flags for those commands to get the information that you need. Reading man pages for the commands is a good starting point. - -### 1\. First contact - -As soon as I log into a server, the first thing I do is check whether it has the operating system, kernel, and hardware architecture needed for the tests I will be running. I often check how long a server has been up and running. While this does not matter very much for a test system because it will be rebooted multiple times, I still find this information helpful. - -Use the following commands to get this information. I mostly use Red Hat Linux for testing, so if you are using another Linux distro, use `*-release` in the filename instead of `redhat-release`: - - -``` -cat /etc/redhat-release -uname -a -hostnamectl -uptime -``` - -### 2\. Is anyone else on board? - -Once I know that the machine meets my test needs, I need to ensure no one else is logged into the system at the same time running their own tests. Although it is highly unlikely, given that the provisioning system takes care of this for me, it's still good to check once in a while—especially if it's my first time logging into a server. I also check whether there are other users (other than root) who can access the system. - -Use the following commands to find this information. The last command looks for users in the `/etc/passwd` file who have shell access; it skips other services in the file that do not have shell access or have a shell set to `nologin`: - - -``` -who -who -Hu -grep sh$ /etc/passwd -``` - -### 3\. Physical or virtual machine - -Now that I know I have the machine to myself, I need to identify whether it's a physical machine or a virtual machine (VM). If I provisioned the machine myself, I could be sure that I have what I asked for. However, if you are using a machine that you did not provision, you should check whether the machine is physical or virtual. - -Use the following commands to identify this information. If it's a physical system, you will see the vendor's name (e.g., HP, IBM, etc.) and the make and model of the server; whereas, in a virtual machine, you should see KVM, VirtualBox, etc., depending on what virtualization software was used to create the VM: - - -``` -dmidecode -s system-manufacturer -dmidecode -s system-product-name -lshw -c system | grep product | head -1 -cat /sys/class/dmi/id/product_name -cat /sys/class/dmi/id/sys_vendor -``` - -### 4\. Hardware - -Because I often test hardware connected to the Linux machine, I usually work with physical servers, not VMs. On a physical machine, my next step is to identify the server's hardware capabilities—for example, what kind of CPU is running, how many cores does it have, which flags are enabled, and how much memory is available for running tests. If I am running network tests, I check the type and capacity of the Ethernet or other network devices connected to the server. - -Use the following commands to display the hardware connected to a Linux server. Some of the commands might be deprecated in newer operating system versions, but you can still install them from yum repos or switch to their equivalent new commands: - - -``` -lscpu or cat /proc/cpuinfo -lsmem or cat /proc/meminfo -ifconfig -a -ethtool <devname> -lshw -lspci -dmidecode -``` - -### 5\. Installed software - -Testing software always requires installing additional dependent packages, libraries, etc. However, before I install anything, I check what is already installed (including what version it is), as well as which repos are configured, so I know where the software comes from, and I can debug any package installation issues. - -Use the following commands to identify what software is installed: - - -``` -rpm -qa -rpm -qa | grep <pkgname> -rpm -qi <pkgname> -yum repolist -yum repoinfo -yum install <pkgname> -ls -l /etc/yum.repos.d/ -``` - -### 6\. Running processes and services - -Once I check the installed software, it's natural to check what processes are running on the system. This is crucial when running a performance test on a system—if a running process, daemon, test software, etc. is eating up most of the CPU/RAM, it makes sense to stop that process before running the tests. This also checks that the processes or daemons the test requires are up and running. For example, if the tests require httpd to be running, the service to start the daemon might not have run even if the package is installed. - -Use the following commands to identify running processes and enabled services on your system: - - -``` -pstree -pa 1 -ps -ef -ps auxf -systemctl -``` - -### 7\. Network connections - -Today's machines are heavily networked, and they need to communicate with other machines or services on the network. I identify which ports are open on the server, if there are any connections from the network to the test machine, if a firewall is enabled, and if so, is it blocking any ports, and which DNS servers the machine talks to. - -Use the following commands to identify network services-related information. If a deprecated command is not available, install it from a yum repo or use the equivalent newer command: - - -``` -netstat -tulpn -netstat -anp -lsof -i -ss -iptables -L -n -cat /etc/resolv.conf -``` - -### 8\. Kernel - -When doing systems testing, I find it helpful to know kernel-related information, such as the kernel version and which kernel modules are loaded. I also list any [tunable kernel parameters][2] and what they are set to and check the options used when booting the running kernel. - -Use the following commands to identify this information: - - -``` -uname -r -cat /proc/cmdline -lsmod -modinfo <module> -sysctl -a -cat /boot/grub2/grub.cfg -``` - -### 9\. Logs - -By now, I have a good idea about the server, including what software is installed and what processes are running. One other thing I cannot escape is log files—I need to know where to check the information that is continuously being updated. - -Use the following commands to see your system's logs: - - -``` -dmesg -tail -f /var/log/messages -journalctl -``` - -### Next steps - -While commands and utilities will change, the underlying information they show remains more or less the same. You need a high-level view of the information you are looking for and what category it falls into before you can focus on which commands to master. - -Since Linux saves most information in files, these commands basically read information from the files and present them in an easy-to-understand way. A good next step is to identify the files each command uses to get the information to display. A hint for finding that information is the `strace` command. - --------------------------------------------------------------------------------- - -via: https://opensource.com/article/20/12/linux-server - -作者：[Gaurav Kamathe][a] -选题：[lujun9972][b] -译者：[译者ID](https://github.com/译者ID) -校对：[校对者ID](https://github.com/校对者ID) - -本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出 - -[a]: https://opensource.com/users/gkamathe -[b]: https://github.com/lujun9972 -[1]: https://opensource.com/sites/default/files/styles/image-full-size/public/lead-images/containers_modules_networking_hardware_parts.png?itok=rPpVj92- (Parts, modules, containers for software) -[2]: https://www.oreilly.com/library/view/red-hat-enterprise/9781785283550/ch10s05.html diff --git a/translated/tech/20201215 9 things to do in your first 10 minutes on a Linux server.md b/translated/tech/20201215 9 things to do in your first 10 minutes on a Linux server.md new file mode 100644 index 0000000000..59a68bedde --- /dev/null +++ b/translated/tech/20201215 9 things to do in your first 10 minutes on a Linux server.md @@ -0,0 +1,167 @@ +[#]: collector: (lujun9972) +[#]: translator: (wxy) +[#]: reviewer: (wxy) +[#]: publisher: ( ) +[#]: url: ( ) +[#]: subject: (9 things to do in your first 10 minutes on a Linux server) +[#]: via: (https://opensource.com/article/20/12/linux-server) +[#]: author: (Gaurav Kamathe https://opensource.com/users/gkamathe) + +初次登录 Linux 服务器马上要做的 9 件事 +====== + +> 在将新配置的服务器投入工作之前，请确保你知道你正在使用什么。 + +![软件的部件、模块、容器][1] 。 + +当我在 Linux 上测试软件时（这是我工作中的一个常规部分），我需要使用多台运行 Linux 的不同架构的服务器。我整备机器，安装所需的软件包，运行我的测试，收集结果，并将机器返回到仓库中，以便其他人可以使用它进行测试。 + +由于我经常这样做（甚至一天多次），我初次登录 Linux 服务器的前 10 分钟内的工作已经成为每天的仪式。当我初次登录 Linux 服务器时，我会使用命令来收集我需要的信息来寻找某些东西。我将在本文中介绍我的过程，但请注意，在大多数情况下，我只给出命令名称，所以你需要确定这些命令的具体选项，以获得你需要的信息。阅读命令的手册页是一个很好的起点。 + +### 1、第一次接触 + +当我登录到一台服务器时，我做的第一件事就是检查它是否拥有我将要运行的测试所需的操作系统、内核和硬件架构。我经常会检查一台服务器已经运行了多久。虽然这对测试系统来说并不重要，因为它会被多次重启，但我还是发现这些信息很有帮助。 + +使用下面的命令来获取这些信息。我主要使用 Red Hat Linux 进行测试，所以如果你使用其他 Linux 发行版，请在文件名中使用 `*-release` 而不是 `redhat-release`： + +``` +cat /etc/redhat-release +uname -a +hostnamectl +uptime +``` + +### 2、有人登录在上面吗？ + +一旦我知道这台机器符合我的测试需求，我需要确保没有其他人同时登录该系统运行他们自己的测试。虽然可能性很小，但考虑到整备系统会帮我处理好这个问题，偶尔检查一下还是有好处的 —— 尤其是当我第一次登录服务器的时候。我还会检查是否有其他用户（除了 root）可以访问系统。 + +使用下面的命令来查找这些信息。最后一条命令是查找 `/etc/passwd` 文件中具有 shell 访问权限的用户；它会跳过文件中没有 shell 访问权限或 shell 设置为 `nologin` 的其他服务： + +``` +who +who -Hu +grep sh$ /etc/passwd +``` + +### 3、物理机还是虚拟机 + +现在我有了属于自己的机器，我需要确定它是一台物理机还是一台虚拟机（VM）。如果是我自己整备的这台机器，我可以确定有我要求的东西。但是，如果你使用的是一台不是你自己整备的机器，你应该检查该机器是物理机还是虚拟机。 + +使用以下命令来识别这些信息。如果是物理系统，你会看到供应商的名称（如 HP、IBM 等）以及服务器的品牌和型号；而在虚拟机中，你应该看到 KVM、VirtualBox 等，这取决于创建虚拟机时使用了什么虚拟化软件： + +``` +dmidecode -s system-manufacturer +dmidecode -s system-product-name +lshw -c system | grep product | head -1 +cat /sys/class/dmi/id/product_name +cat /sys/class/dmi/id/sys_vendor +``` + +### 4、硬件 + +因为我经常测试连接到 Linux 机器的硬件，所以我通常使用物理服务器，而不是虚拟机。在物理机器上，我的下一步是确定服务器的硬件能力 —— 例如，运行的是什么类型的 CPU，它有多少个核心，启用了哪些标志，以及有多少内存可用于运行测试。如果我正在运行网络测试，我会检查连接到服务器的以太网或其他网络设备的类型和容量。 + +使用以下命令来显示连接到 Linux 服务器的硬件。其中一些命令在新的操作系统版本中可能会被废弃，但你仍然可以从 yum 存储库中安装它们或切换到它们的等效新命令： + +``` +lscpu or cat /proc/cpuinfo +lsmem or cat /proc/meminfo +ifconfig -a +ethtool +lshw +lspci +dmidecode +``` + +### 5、已安装的软件 + +测试软件总是需要安装额外的依赖包、库等。然而，在安装任何东西之前，我都会检查已经安装了什么（包括是什么版本），以及配置了哪些存储库，这样我就知道软件来自哪里，并可以调试任何软件包安装问题。 + +使用下面的命令来确定安装了什么软件： + +``` +rpm -qa +rpm -qa | grep +rpm -qi +yum repolist +yum repoinfo +yum install +ls -l /etc/yum.repos.d/ +``` + +### 6、运行的进程和服务 + +检查了安装的软件之后，自然就会检查系统上有哪些进程在运行。当在系统上运行性能测试时，这一点至关重要 —— 如果一个正在运行的进程、守护进程、测试软件等占用了大部分 CPU/RAM，那么在运行测试之前停止该进程是有意义的。这也可以检查测试所需的进程或守护进程是否已经启动并运行。例如，如果测试需要 `httpd` 运行，那么即使安装了软件包，启动守护进程的服务也可能没有运行。 + +使用以下命令来识别系统上正在运行的进程和已启用的服务： + +``` +pstree -pa 1 +ps -ef +ps auxf +systemctl +``` + +### 7、网络连接 + +如今的机器网络化程度很高，它们需要与网络上的其他机器或服务进行通信。我识别服务器上哪些端口是开放的，是否有任何从网络到测试机器的连接，是否启用了防火墙，如果启用了，是否屏蔽了任何端口，以及机器与哪些 DNS 服务器对话。 + +使用以下命令来识别网络服务相关信息。如果一个过时的命令不可用，请从 yum 存储库中安装它或使用等效的新命令： + +``` +netstat -tulpn +netstat -anp +lsof -i +ss +iptables -L -n +cat /etc/resolv.conf +``` + +### 8、内核 + +在进行系统测试时，我发现了解内核相关的信息是很有帮助的，比如内核版本和加载了哪些内核模块。我还会列出任何[可调整的内核参数][2]以及它们的设置，并检查启动运行中的内核时使用的选项。 + +使用以下命令来识别这些信息： + +``` +uname -r +cat /proc/cmdline +lsmod +modinfo +sysctl -a +cat /boot/grub2/grub.cfg +``` + +### 9、日志 + +现在，我已经对服务器有了很好的了解，包括安装了哪些软件，运行了哪些进程。还有一件事我无法逃避，那就是日志文件 —— 我需要知道在哪里可以查看不断更新的信息。 + +使用以下命令查看系统的日志： + +``` +dmesg +tail -f /var/log/messages +journalctl +``` + +### 接下来的步骤 + +虽然命令和实用程序会发生变化，但它们所显示的基本信息大致不变。在你专注于掌握哪些命令之前，你需要对你要寻找的信息以及它属于什么类别有一个更高层面的看法。 + +由于 Linux 将大部分信息保存在文件中，这些命令基本上是从文件中读取信息，并以一种易于理解的方式呈现出来。下一步的好做法是找出每个命令用来获取信息显示的文件。一个提示：寻找这些信息的方法是 `strace` 命令。 + +-------------------------------------------------------------------------------- + +via: https://opensource.com/article/20/12/linux-server + +作者：[Gaurav Kamathe][a] +选题：[lujun9972][b] +译者：[wxy](https://github.com/wxy) +校对：[wxy](https://github.com/wxy) + +本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出 + +[a]: https://opensource.com/users/gkamathe +[b]: https://github.com/lujun9972 +[1]: https://opensource.com/sites/default/files/styles/image-full-size/public/lead-images/containers_modules_networking_hardware_parts.png?itok=rPpVj92- (Parts, modules, containers for software) +[2]: https://www.oreilly.com/library/view/red-hat-enterprise/9781785283550/ch10s05.html