How to use YUM to manage packages in CentOS
CentOS
15.04.2024
Reading time: 3 min
Share
yum is a package manager used in some Linux distributions like CentOS, Fedora and RedHat.
It’s a tool used in the command line that simplifies the process of installing, updating, and removing software packages, but also to upgrade the distribution.
In this article, we'll delve into some of the main Yum commands along with code snippets to illustrate their usage.
Prerequisites
You can deploy a cloud server on systems such as CentOS/RHEL 7, Fedora 21, or earlier versions of these distributions. Other Linux distributions that use the YUM package manager are also supported. Use Hostman services to create your cloud server.
Installing Packages
Installing software packages is a breeze with yum. The install command fetches and installs the specified package along with its dependencies.
sudo yum install <package>For example, to install the Apache web server:
sudo yum install httpdWhen asked for confirmation, you should type y (yes) then press Enter to confirm the installation, like this:
Checking for Updates
Before performing system updates, it's a good practice to check for available updates using the check-update command.
yum check-updateUpdating Packages
Keeping your system up to date is crucial for security and performance. The update command updates all installed packages to their latest versions.
sudo yum updateYou need to confirm the installation like mentioned above:
Removing Packages
When a package is no longer needed, you can easily remove it using the remove command.
sudo yum remove <package>For instance, to remove the Apache web server:
sudo yum remove httpdA confirmation is needed to remove the package and its dependencies:
Searching for Packages
The search command allows you to search for packages based on keywords.
yum search <package>For example, to search for packages related to Python:
yum search pythonThis is how it looks:
Listing Installed Packages
To view a list of all installed packages, you can use the list installed command.
yum list installedCleaning Package Cache
Over time, the package cache can consume a significant amount of disk space. You can clean up the cache using the clean command.
sudo yum clean allCentOS Repositories
CentOS repositories are collections of software packages specifically curated for the CentOS Linux distribution. These repositories contain a wide range of software applications, libraries, and tools that users can easily install and manage using yum.
Listing Repositories
To view a list of enabled and disabled repositories:
yum repolist allThe output looks like this:
Enabling a Repository
To be able to use the commands below with yum-config-manager, you need to install yum-utils. (In some CentOS versions, it is installed by default.)
sudo yum install yum-utilsTo enable a repository:
sudo yum-config-manager --enable <repositoryName>For example, here the baseos-source repo is disabled, you can enable it like this:
sudo yum-config-manager --enable baseos-sourceThen you can check the new status of the repository with grep to filter the results:
yum repolist all | grep baseos-sourceIt shows:
Disabling a Repository
To disable a repository:
sudo yum-config-manager --disable <repositoryName>For example, the baseos-source repo was enabled, and we need to disable it:
sudo yum-config-manager --disable baseos-sourceNow, you can check the new status:
Conclusion
yum is a powerful package management utility that simplifies software management on CentOS systems. By mastering these essential commands, you can efficiently install, update, and manage software packages, ensuring the stability and security of your CentOS environment. Whether you're a system administrator, developer, or Linux enthusiast, understanding yum commands is indispensable for effective system administration and software development on CentOS.
CentOS
15.04.2024
Reading time: 3 min
Share
Similar
Apache
How to Install Apache on CentOS
The Apache web server is the most widely used platform for deploying HTTP-based services. Its popularity is due to its support for dynamically loadable modules, compatibility with various file formats, and integration with other software tools.
Prerequisites
To install the Apache HTTP server following this guide, you will need:
A local computer or a cloud server with CentOS 9 installed
A user with sudo privileges or root
Enabled firewalld
Step 1: Install Apache
The Apache package is available in the official CentOS repository, so you can install it using dnf.
First, update the package list:
sudo dnf update -y
Run the following command to install Apache:
sudo dnf install httpd -y
The package manager will install the Apache web server and all necessary dependencies on CentOS.
Step 2: Configuring the Firewall
To operate the web server, you’ll need to configure the firewall to allow HTTP and HTTPS traffic:
sudo firewall-cmd --permanent --add-service=httpsudo firewall-cmd --permanent --add-service=https
After running these commands, restart the firewall to apply the new rules:
sudo firewall-cmd --reload
The Apache installation is now complete, and you can start the web server and check its functionality.
Step 3: Checking the HTTP Server
Once installed, Apache isn’t running yet, so you need to enable and start it using these commands:
sudo systemctl enable httpdsudo systemctl start httpd
To verify if the Apache service has started, use this command:
sudo systemctl status httpd
If the web server is running correctly, you should see a message showing the status as active (running):
● httpd.service - The Apache HTTP Server Loaded: loaded (/usr/lib/systemd/system/httpd.service; enabled; preset: disabled) Active: active (running) since Thu 2024-11-07 07:34:27 GMT; 6s ago
Another way to check is to open the server’s IP address in a browser:
http://your_server_ip
You can find your server’s IP on the server's Dashboard or in an email received after setting up the server.
Step 4: Managing the Apache Service
Now, you can try some systemctl commands for interacting with the Apache service.
For example, to stop the HTTP server, use:
sudo systemctl stop httpd
To start it again, use:
sudo systemctl start httpd
For a complete restart, such as when applying configuration changes:
sudo systemctl restart httpd
To reload Apache without interrupting active connections, use:
sudo systemctl reload httpd
We enabled Apache to start automatically when the server boots. If you prefer to disable this option, run:
sudo systemctl disable httpd
These commands allow you to manage the Apache process easily.
Step 5: Setting Up Virtual Hosts
The default Apache HTTP server configuration allows for hosting only one site. However, you can set up virtual hosts to host multiple sites with separate resources.
Virtual hosts in Apache work similarly to those in Nginx. They allow you to separate configurations and host multiple domains on a single virtual or physical server. In this guide, we’ll use a placeholder site called example.com. When configuring, replace it with your actual domain.
Create the html directory for example.com:
sudo mkdir -p /var/www/example.com/html
Create a directory for log files:
sudo mkdir -p /var/www/example.com/log
Set permissions for the html directory. Assign ownership to the $USER environment variable.
sudo chown -R $USER:$USER /var/www/example.com/html
Verify standard permissions for the root directory:
sudo chmod -R 755 /var/www
Create an index.html file. You can use any code editor to create this file. For example, with vi:
sudo vi /var/www/example.com/html/index.html
Add simple content to the file:
<html>
<head>
<title>Welcome to Example.com!</title>
</head>
<body>
<h1>Success! The example.com virtual host is working!</h1>
</body>
</html>
After saving index.html, you’re nearly ready to set up the configuration files for each domain. These files will tell Apache how to handle requests for each virtual host.
Create directories for virtual host configurations. The configuration files for individual domains are stored in a sites-available directory, while the sites-enabled directory will contain symbolic links to sites that are ready to receive traffic:
sudo mkdir /etc/httpd/sites-available /etc/httpd/sites-enabled
Now, you need to instruct the HTTP server to find virtual hosts in the sites-enabled directory. To do this, modify the main Apache configuration file by running the following command:
sudo vi /etc/httpd/conf/httpd.conf
Then, move the cursor to the very end of the file and add the following lines:
# Supplemental configuration
#
# Load config files in the "/etc/httpd/conf.d" directory, if any.
IncludeOptional conf.d/*.conf
IncludeOptional sites-enabled/*.conf
Now, it’s time to create the virtual host configuration file:
sudo vi /etc/httpd/sites-available/example.com.conf
In this file, add the following configuration:
<VirtualHost *:80>
ServerName www.example.com
ServerAlias example.com
DocumentRoot /var/www/example.com/html
ErrorLog /var/www/example.com/log/error.log
CustomLog /var/www/example.com/log/requests.log combined
</VirtualHost>
Make sure to replace example.com with your actual domain name. This configuration tells the web server where to find the site’s root directory and where to store the error and access logs.
After saving and closing the file, you need to activate the virtual host by creating a symbolic link for the domain in the sites-enabled directory:
sudo ln -s /etc/httpd/sites-available/example.com.conf /etc/httpd/sites-enabled/example.com.conf
At this point, the configuration is complete, and the host is ready to function. However, before restarting the web server, it’s a good idea to check if the SELinux module is correctly handling requests.
Step 6: Configuring Permissions in SELinux
The SELinux (Security-Enhanced Linux) module enhances the operating system's security. CentOS comes with a preconfigured SELinux package that works with Apache. However, since we've made changes, starting the web server services might result in an error. To resolve this, you need to adjust SELinux policies for Apache. There are two ways to adjust these policies: a universal approach and a folder-specific approach.
Option 1: Universal Approach
This method allows the SELinux security module to use any Apache processes via the httpd_unified boolean variable. It’s convenient but doesn’t allow separate policies for individual directories and files. To enable the universal policy, run:
sudo setsebool -P httpd_unified 1
The setsebool command is used to modify boolean values, and the -P flag ensures that the change is persistent across reboots. In this case, the httpd_unified boolean is activated with the value 1.
Option 2: Adjusting SELinux Policies for Specific Directories
This approach requires more steps but allows for more granular control over permissions for each directory or file. You’ll need to specify the context type for each new folder manually. For example, to check the parameters of the /var/www/example.com/log directory, run:
sudo ls -dlZ /var/www/example.com/log/
You’ll see something like this:
drwxr-xr-x. 2 root root unconfined_u:object_r:httpd_sys_content_t:s0 6 Nov 07 09:01 /var/www/example.com/log/
You can see that the context used is httpd_sys_content_t, meaning Apache can only read files placed in this folder. To change the context to httpd_log_t so that the web server can write to log files, run:
sudo semanage fcontext -a -t httpd_log_t "/var/www/example.com/log(/.*)?"
This command will set the correct context for the log directory and its contents, allowing Apache to write log entries.
Apply the changes using the following command:
sudo restorecon -R -v /var/www/example.com/log
The -R flag allows the command to run recursively, updating existing files, and the -v flag will display the changes being made. You should see an output like this:
Relabeled /var/www/example.com/log from unconfined_u:object_r:httpd_sys_content_t:s0 to unconfined_u:object_r:httpd_log_t:s0
If you want to verify that the context type has been updated, check the current status again:
sudo ls -dlZ /var/www/example.com/log/
The output should look like this:
drwxr-xr-x. 2 root root unconfined_u:object_r:httpd_log_t:s0 6 Nov 07 09:01 /var/www/example.com/log/
Step 7: Testing the Virtual Host
After adjusting the SELinux permissions, the Apache server should now be able to write data to the /var/www/example.com/log directory. Let’s restart the Apache service:
sudo systemctl restart httpd
Next, list the contents of the /var/www/example.com/log directory to verify that the system has created the log files:
ls -lZ /var/www/example.com/log
You should see output similar to this:
-rw-r--r--. 1 root root system_u:object_r:httpd_log_t:s0 0 Nov 07 09:06 error.log-rw-r--r--. 1 root root system_u:object_r:httpd_log_t:s0 0 Nov 07 09:06 requests.log
The first line confirms the existence of the error.log file, and the second confirms the presence of the requests.log file.
Now, you can check the functionality of the domain through a browser. You should see a message like:
Success! The example.com virtual host is working
This confirms that the virtual host has been successfully set up and is serving content. Repeat steps 5 and 6 for each new site, replacing the domain with the appropriate one.
Conclusion
In this tutorial, we've walked through installing and configuring Apache on CentOS 9, including setting up virtual hosts for multiple domains. We covered installation with dnf, configuring firewall rules, enabling Apache to start on boot, and managing its service using systemctl. We also explored SELinux configuration for proper permissions, ensuring Apache can read and write log files. With these steps, you'll have a functional web server ready to host sites and deploy content.
11 November 2024 · 8 min to read
CentOS
Configuring Firewalld on CentOS
Firewalld is a firewall management tool that comes pre-installed on most RHEL-based distributions. In this article, we will look at setting up a firewall with firewalld on a CentOS server using the firewall-cmd utility.
Prerequisites
To follow this guide, you will need:
A cloud server running CentOS
A root user or a user with sudo privileges
What is firewall?
A firewall is a program for access control at the network level. Based on the set up rules, the firewall determines which devices can access this or that part of the network, which traffic is allowed and which is blocked. In Linux, these functions are performed by the netfilter program built into the kernel.
So, netfilter works at the kernel level. To configure the firewall, you need tools in user space. ip_tables/nf_tables, implemented as kernel modules, are used as frameworks for managing netfilter. And on top of them, at the user level, either iptables or nft are used.
Experienced system administrators know that manually writing rules for iptables or nft is not so easy, especially when you need to set up a large network or transfer rules to another system. That's where more user-friendly and feature-rich add-ons come into play. For example, in Ubuntu such an add-on is a tool with the self-explanatory name ufw (Uncomplicated Firewall). And in RedHat distributions (CentOS, Alma, Fedora, RHEL, OpenSUSE, SUSE Linux Enterprise), it is firewalld.
Our cloud-based firewall provides cutting-edge defense tailored for businesses of all sizes.
Working with firewalld
There are two programs to manage firewalld: firewall-cmd for working in the terminal and firewall-config GUI.
In this article, we will work with firewall-cmd.
Installation
Connect to your server and check the service status:
sudo systemctl status firewalld
As mentioned before, in RHEL-based distributions, firewalld is pre-installed. If you wish to use it on Ubuntu/Debian, you can easily install it manually:
sudo apt install firewalldsudo systemctl enable firewalld --now
Don't forget to disable ufw, as using two utilities for iptables/nftables may cause issues.
Active rules
Check the existing active rules by using the command:
sudo firewall-cmd --list-all
Note that you need superuser privileges for this, so log in as root or use sudo/su.
In the command output you can see many different parameters. Let's look at them in order.
Configuring ports
The ports field shows the ports on which connections are allowed.
To better understand how it works, let's change the listening port of the OpenSSH daemon from 22 to 3333 in the /etc/ssh/sshd_config file:
Port 3333#AddressFamily any#ListenAddress 0.0.0.0#ListenAddress ::
sudo systemctl restart sshd
List the ports listened by sshd:
sudo ss -nl4p | grep sshd
Output:
tcp LISTEN 0 128 *:3333 *:* users:(("sshd",pid=7602,fd=3))
As you can see, the port 3333 is now listening. The current session has not been interrupted, but if we try to connect again using the standard or new port, we won't be successful:
ssh [email protected]: connect to host 166.1.227.252 port 22: Connection refused
ssh [email protected] -p 3333ssh: connect to host 166.1.227.252 port 3333: No route to host
You need to add an allowing rule to firewalld that allows you to connect via 3333/tcp:
sudo firewall-cmd --add-port=3333/tcp
Or:
sudo firewall-cmd --add-port=3333/tcp --permanentsudo firewall-cmd --reload
In the first case, the changes are active only in the current runtime, and when the machine or service is restarted, everything is reset. In the second case, the --permanent flag indicates that we are changing the settings permanently, so you need to restart the firewall (the --reload option).
Let's check which ports are now allowed:
sudo firewall-cmd --list-ports
Output:
3333/tcp
Now everything works:
ssh [email protected] -p [email protected]'s password:
You might wonder how we managed to connect via SSH earlier, as at first the ports field in the policy output was empty. The fact is that the settings were specified using service descriptions.
Configuring services
Services in firewalld are service descriptions that make configuration more convenient and centralized. Let's look up the current services and information about them:
sudo firewall-cmd --list-services
sudo firewall-cmd --info-service=ssh
Note that SSH still has port 22. The fact is that the daemons' own parameters are in no way related to their descriptions in firewalld. Let's try to remove the standard port and add 3333 to the ssh service description (don't forget to remove port 3333/tcp from the policies):
sudo firewall-cmd --service=ssh --remove-port=22/tcp --permanentsudo firewall-cmd --remove-port=3333/tcp --permanentsudo firewall-cmd --service=ssh --add-port=3333/tcp --permanentsudo firewall-cmd --reload
Now let's check again:
sudo firewall-cmd --info-service=ssh
Let's try to remove and add a service:
sudo firewall-cmd --remove-service=dhcpv6-clientsudo firewall-cmd --add-service=mysqlsudo firewall-cmd --runtime-to-permanent
Check the list of services:
sudo firewall-cmd --list-services
The --runtime-to-permanent option makes the runtime permanent. You don't have to specify --permanent after each command, but execute a set of commands and only after that make the settings permanent (please note that it does not always work since some commands require the --permanent option).
Files with predefined services are located at /lib/firewalld/services. Let's list them:
sudo firewall-cmd --get-services
You can create your own services. To do this, create an .xml file in the /etc/firewalld/services directory. For convenience, you can copy a configuration from /etc/firewalld/services and make the necessary changes. Then restart the firewall with the --reload flag.
ICMP, protocols and targets
The output of --list-all has the following fields:
sudo firewall-cmd --list-all | grep -E '(target|icmp|protocols)'
In firewalld, you can configure not only services and ports, but also protocols. Let's say we set up a firewall on a router. It makes sense to indicate a list of allowed protocols. To illustrate, let's enable the OSPF dynamic routing protocol:
sudo firewall-cmd --add-protocol=ospfsudo firewall-cmd --list-protocols
The icmp-blocks and icmp-blocks-inversion fields contain parameters for the ICMP protocol used for network testing and error notifications. It is used by ping and traceroute utilities.
Using icmp-blocks you can block specific ICMP messages. The icmp-blocks-inversion inverts the logic, as in the listed message types become allowed and the rest are blocked. This functionality can be used to hide network information since many scanning engines use ICMP. Let's test the blocking using the ping utility.
Prohibit all types of ICMP messages (since nothing is listed in icmp-block, all messages become prohibited):
sudo firewall-cmd --add-icmp-block-inversion
Now let's try to ping the server:
ping -c 3 166.1.227.252PING 166.1.227.252 (166.1.227.252) 56(84) bytes of data.From 166.1.227.252 icmp_seq=1 Destination Host ProhibitedFrom 166.1.227.252 icmp_seq=2 Destination Host ProhibitedFrom 166.1.227.252 icmp_seq=3 Destination Host Prohibited--- 166.1.227.252 ping statistics ---3 packets transmitted, 0 received, +3 errors, 100% packet loss, time 2004ms
The machine does not respond to ping. This method is often used by providers to hide router addresses. However, it is clear from the errors that the packets on the target devices are being filtered by the firewall. To hide your computer, you need to use targets.
A target is an action that needs to be done with the package if any of the rules are triggered. The most used are DROP, ACCEPT, REJECT. In the example above, the target was REJECT, i.e. returning the reason for the error. To drop a packet without sending anything, you need to use DROP:
sudo firewall-cmd --set-target=DROP --permanentsudo firewall-cmd --reload
Let's ping the server again:
ping -c 3 166.1.227.252PING 166.1.227.252 (166.1.227.252) 56(84) bytes of data.--- 166.1.227.252 ping statistics ---3 packets transmitted, 0 received, 100% packet loss, time 2050ms
Zones
When working with firewalld, zones are often used. A machine may have multiple interfaces: one for Internet, another for LAN, and third for dmz. Different networks have different levels of trust, and traffic coming from them must be controlled by different firewall rules. To achieve this, firewalld uses zones, sets of rules that apply to different parts of the network.
All the firewall rules we configured above were applied for the public zone (by default):
sudo firewall-cmd --get-default-zone
Firewalld initially contains several zones. However, you can create your own zones. Let's display a list of available zones:
sudo firewall-cmd --get-zones
The --zone option allows you to set and view rules for a specific zone (without it, everything is applied to the default zone). Let's look at the policies for the drop zone:
sudo firewall-cmd --list-all --zone=drop
In our case, the interface eth0, which provides access to the Internet, is in the public zone. This means that the policies of the public zone are applied to incoming traffic. To add the interface to another zone, use the --change-interface switch. Let's move our eth0 to the home zone:
sudo firewall-cmd --change-interface=eth0 --zone=homesudo firewall-cmd --list-interfaces --zone=home
Sometimes, you may need to configure traffic rules for a specific address. It's done like this:
sudo firewall-cmd --zone=drop --add-source=192.168.3.1
Now check:
sudo firewall-cmd --zone=drop --list-all
Now, even if packets from the address 192.168.3.1 arrive on the eth0 interface, the rules will be applied not for the zone in which the interface is located, but for the zone we manually specified (drop).
NAT setup
NAT stands for Network Address Translation. There are two types of NAT: source and destination. In the first case, the router replaces home IP addresses with its external ones, i.e. changing the sender's (source) address. In Linux, this is called masquerade. In the second case, the recipient address is replaced (port forwarding). For example, a packet arrives at the router port, and the router forwards the packet to some other port.
Let's say you need to configure a firewall on a router. Enable masquerading:
sudo firewall-cmd --add-masquerade
Run --list-all:
sudo firewall-cmd --list-all
Enable port forwarding:
sudo firewall-cmd --add-forward-port=port=3333:proto=tcp:toport=22sudo firewall-cmd --list-all
You may also notice the source-ports option. Firewalld can allow specific outgoing ports, but this is rarely used since dynamic 5-digit ports are usually used as source ports.
Rich rules
We looked at how to use different firewalld rules for different network areas (interfaces, IP addresses). But sometimes you need to create very distinctive rules, like allowing connections from a specific address to a specific port, using such and such protocols, etc. Of course, you can create your own zone, but it may be better to use rich-rules.
Rich-rules in firewalld have a different syntax which you can find in the manual:
man firewalld.richlanguage
It also provides many examples.
And that's how you add a rich-rule manually:
sudo firewall-cmd --add-rich-rule=’rule'
Conclusion
A properly functioning firewall greatly improves network security. In this article, we looked at the basics of working in firewalld, which are necessary for proper configuration. Firewalld allows you to easily divide your network into sections and set your own security policies for each section.
27 May 2024 · 9 min to read
Do you have questions,
comments, or concerns?
Our professionals are available to assist you at any moment,
whether you need help or are just unsure of where to start.
whether you need help or are just unsure of where to start.
