Sign In
Sign In

Installing and Configuring cloud-init in Linux

Installing and Configuring cloud-init in Linux
Hostman Team
Technical writer
Linux
26.09.2024
Reading time: 10 min

cloud-init is a free and open-source package designed for configuring Linux-based virtual machines during their startup.

In a traditional (home) environment, we would install systems from a CD or USB drive and manually configure them via a standard installer. However, in a cloud environment, we may need to configure systems regularly and frequently create, delete, and restart instances. In such cases, manual configuration becomes impractical and unfeasible.

cloud-init automates the configuration process and standardizes the setup of virtual machines.

What Is cloud-init

The main task of cloud-init is to process input metadata (such as user data) and configure the virtual machine before it starts. This allows us to pre-configure servers, install software, prepare working directories, and create users with specific permissions.

Cloud-init and Hostman Cloud Servers

Hostman cloud servers support working with cloud-init scripts through the control panel. Hostman’s documentation includes a brief guide on using cloud-init scripts directly on their cloud servers. Essentially, Hostman offers a text editor for cloud-init scripts accessible via a web browser, allowing users to pass configuration data directly to the utility before the system starts.

Installing Cloud-init

There are several ways to get a Linux OS with cloud-init:

  • Use a specialized Linux OS image with pre-installed cloud-init (we’ll mention some key examples below).

  • Use pre-built distributions from cloud providers (most cloud platforms support cloud-init, though the setup processes may vary).

  • Build a custom OS image using HashiCorp Packer.

  • Manually install the cloud-init package.

Cloud-init Images

  • Ubuntu: The most common cloud-init image is Ubuntu 22.04 Cloud Images, officially created by Canonical for public cloud use. These images are optimized and tailored for cloud tasks.

  • Debian: Similarly, Debian Cloud offers specialized cloud images for Debian users.

  • Alma Linux: Another distribution designed for cloud deployment is Alma Linux Cloud.

  • VMware: VMware’s Photon image, built for cloud environments, also comes with pre-installed cloud-init.

Alternatively, you can install cloud-init manually.

Installation via APT

In most Linux distributions, cloud-init is installed like any other package and includes three systemd services located in the /lib/systemd/system/ directory:

  • cloud-init.service

  • cloud-config.service

  • cloud-final.service

Additionally, there are two more auxiliary systemd services:

  • cloud-init-local.service

  • cloud-init-hotplugd.service

Before installing, it's best to update the list of available repositories:

sudo apt update

Then, download the cloud-init package via APT:

sudo apt install cloud-init

In some Linux images, cloud-init may already be installed by default. If so, the system will notify you after running the install command.

cloud-init also supports additional modules that expand configuration capabilities. The full list of modules is available in the official documentation.

Running cloud-init

Since cloud-init operates as a service, it starts immediately after the systemd utility starts, i.e., when the physical machine starts and before the system connects to the network. This allows for pre-configuring network settings, gateways, DNS addresses, etc.

Cloud-init Workflow

There are three main stages in cloud-init’s workflow, during which the system is configured. Each stage triggers specific cloud-init services:

  1. Before networking (init): Initial setup before the network starts, including system settings, network configurations, and disk preparation.

    • cloud-init-local.service

    • cloud-init.service

  2. After networking (config): Network is available, so updates and required packages are installed.

    • cloud-config.service

  3. Final stage (final): Final configurations, such as user creation and permission assignments, are applied.

    • cloud-final.service

    • cloud-init-hotplugd.service

Cloud-init Modules

cloud-init offers additional modules that enhance system configuration. These modules run in sequence at various stages. Depending on the specific use case, they can be triggered during any of the three stages. Module execution is managed through three lists in the configuration file:

  • cloud_init_modules: Modules run during the initialization (init) stage before the network starts.

  • cloud_config_modules: Modules run during the configuration (cloud) stage after the network is up.

  • cloud_final_modules: Modules run during the final stage.

In more detail, cloud-init’s stages can be broken down into five steps:

  1. systemd checks if cloud-init needs to run during system boot.

  2. cloud-init starts, locates local data sources, and applies the configurations. At this stage, the network is configured.

  3. During the initial setup, cloud-init processes user data and runs the modules listed under cloud_init_modules in the configuration file.

  4. During the configuration phase, cloud-init runs the modules listed under cloud_config_modules.

  5. In the final stage, cloud-init runs the modules from cloud_final_modules, installing the specified packages.

You can find more details on the cloud-init workflow in the official documentation.

Each module also has an additional parameter that specifies how often the module runs during system configuration:

  • per instance: The module runs each time a new system instance (clone or snapshot) boots.

  • per once: The module runs only once during the initial system boot.

  • per always: The module runs at every system startup.

Cloud-init Configuration

In public (AWS, GCP, Azure, Hostman) or private clouds (OpenStack, CloudStack), a service usually provides the virtual machine with environment data. cloud-init uses these data in a specific order:

  • User data (user-data): Configurations and directives defined in the cloud.cfg file. These may include files to run, packages to install, and shell scripts. Typically, user-data configure specific virtual machine instances.

  • Metadata (meta-data): Environment information, such as the server name or instance ID, used after user-data.

  • Vendor data (vendor-data): Information from cloud service providers, used for default settings, applied after metadata.

Metadata is often available at a URL like http://localhost/latest/meta-data/, and user data at http://localhost/latest/user-data/.

Cloud-init Scripts

When the system boots, cloud-init first checks the YAML configuration files with the scripts and then executes the instructions. YAML is a format for data serialization that looks like markup but is not.

The primary YAML configuration file for cloud-init is located at /etc/cloud/cloud.cfg. This file serves as the main configuration script, with directives and parameters for specific cloud-init modules.

You can write scripts as YAML files (using #cloud-config) or as shell scripts (using #!/bin/sh).

Here’s a simple example of a cloud-init script setting a hostname:

#cloud-config
hostname: my-host
fqdn: my-address.com
manage_etc_hosts: true

In this example:

  • #cloud-config: indicates that the instructions are for cloud-init in YAML format.

  • hostname: sets the short hostname.

  • fqdn: sets the fully qualified domain name.

  • manage_etc_hosts: allows cloud-init to manage the /etc/hosts file.

If this option is set to false, cloud-init won’t overwrite manual changes to /etc/hosts on reboot.

Cloud-init Script Examples

Cloud-init configuration using YAML should start with #cloud-config.

Users and Groups

When a virtual machine starts, you can predefine users with the users directive:

#cloud-config
users:
  - name: userOne
    gecos: This is the first user
    groups: sudo
    shell: sh
    system: true

  - name: userTwo
    gecos: This is the second user
    groups: sudo
    shell: /bin/bash
    system: false
    expiredate: '2030-01-02'

As shown, each new user entry begins with a dash, and parameters are specified in a "key: value" format.

These parameters mean:

  • name: User account name

  • gecos: Brief info about the user

  • groups: Groups the user belongs to

  • shell: Default shell for the user, here set to the simplest sh.

  • system: If true, the account will be a system account without a home directory.

  • expiredate: The user's expiration date in the "YYYY-MM-DD" format.

Changing User Passwords

Another simple directive is chpasswd, used to reset an existing user's password. Example configuration:

#cloud-config
chpasswd:
  list: |
    userOne:passOne
    userTwo:passTwo
    userThree:passThree
  expire: false

This sets a list of users and their new passwords. The | symbol indicates a multi-line entry. The expire parameter defines whether the password will need to be changed after expiration.

Updating the Repository List

cloud-config has a directive for updating the available package list: package_update. It's the declarative equivalent of running

 sudo apt update 

By default, it's set to true, meaning cloud-init will always update the package list unless explicitly disabled:

#cloud-config
package_update: false

Installing Specific Packages

For updating or installing specific packages, use the packages directive:

#cloud-config
packages:
  - nginx
  - nodejs

Running Commands

The runcmd directive allows you to execute console commands through cloud-config. Simply pass a list of commands that cloud-init will run in sequence:

#cloud-config
runcmd:
  - echo 'This is a string command!' >> /somefile.txt
  - [ sh, -c, "echo 'This is a list command!' >> /somefile.txt" ]

Here, two types of commands are used:

  1. As a simple string.

  2. As a YAML list specifying the executable and its arguments.

Another similar directive is bootcmd. While runcmd runs commands only on the system's first boot, bootcmd runs commands on every boot:

#cloud-config
bootcmd:
  - echo 'Command that runs at every system boot!'

Creating and Running a Script

You can combine runcmd with the write_files directive to create and run a script:

#cloud-config
write_files:
  - path: /run/scripts/somescript.sh
    content: |
      #!/bin/bash
      echo 'This script just executed!'
    permissions: '0755'
runcmd:
  - [ sh, "/run/scripts/somescript.sh" ]

The permissions parameter (set to 0755) means the script is readable and executable by all, but only writable by the owner.

Overriding Module Execution

You can override the list of modules to be executed at specific configuration stages. For example, the default cloud_config_modules list might look like this:

#cloud-config
cloud_config_modules:
  - emit_upstart
  - snap
  - ssh-import-id
  - locale
  - set-passwords
  - grub-dpkg
  - apt-pipelining
  - apt-configure
  - ubuntu-advantage
  - ntp
  - timezone
  - disable-ec2-metadata
  - runcmd
  - byobu

Remember, there are three stages:

  • cloud_init_modules

  • cloud_config_modules

  • cloud_final_modules

If you remove runcmd, for example, the commands within it won’t execute.

Updating Repositories and Installing Packages via Shell Script

cloud-init configurations can also consist purely of shell scripts. In this case, the script starts with #!/bin/sh instead of #cloud-config:

#!/bin/sh
apt update
apt -y install nodejs
apt -y install nginx

The -y flag automatically answers "yes" to any prompts during installation.

Conclusion

In this guide, we covered the theoretical and practical aspects of using cloud-init:

  • How cloud-init works.

  • How to interact with cloud-init for system configuration.

  • Writing scripts in YAML or shell format.

  • Example configurations.

cloud-init runs before the system boots, ensuring that the instance follows the desired configuration (network, directories, packages, updates). cloud-init uses modules for specific configuration tasks, and the system configuration is done in phases:

  • init (before networking)

  • config (after networking)

  • final (last stage)

More detailed information is available in the official documentation maintained by Canonical, the primary developer of Ubuntu.

Linux
26.09.2024
Reading time: 10 min

Similar

Linux

NATS Installation, Configuration, and Usage Guide

NATS is a simple, fast, and lightweight message broker written in the Go programming language. NATS has several data organization features: Key-Value: Data within NATS is stored in "key-value" format, where each key corresponds to a specific value. Subjects: Data within NATS is organized into so-called "Subjects," which are named channels for message transmission. Subjects can be divided into segments with hierarchical structures. Publish/Subscribe (Pub/Sub): Data within NATS is transmitted through a model where "Publishers" send messages to "Subjects," and "Subscribers" can subscribe to these "Subjects" to receive messages. Unlike many other message brokers (such as Apache Kafka or RabbitMQ), NATS has several significant advantages: Simplicity and Performance: Messages are transmitted through a simple and fast Pub/Sub protocol. When a message is sent to a subject, all subscribers immediately receive it. This minimizes delays and other overhead costs. Stateless: Information about the state of messages transmitted through the broker is not stored within it, nor is data about subject subscribers. The absence of complex state synchronization allows NATS to scale easily. No Default Queues: In standard configuration, NATS does not form message queues. This is important in cases where data timeliness is more important than persistence. It also eliminates queue management overhead. Reliable Protocol: Messages within the broker are transmitted using the "at-most-once delivery" method. This means a subscriber either receives a message once or not at all. This increases communication reliability and prevents duplicate responses to forwarded messages. Thus, NATS enables building fast and reliable communication between multiple different services. In this guide, we will thoroughly examine how to install, configure, and correctly use NATS in projects running on Ubuntu 22.04. Downloading NATS Package Updates Before installation, it's recommended to update the list of available repositories in the system: sudo apt update Downloading the Archive Next, you need to manually download the ZIP archive with NATS from its official GitHub repository: wget https://github.com/nats-io/nats-server/releases/download/v2.10.22/nats-server-v2.10.22-linux-amd64.zip After the download is complete, you can check the file list: ls Among them will be the NATS archive: nats-server-v2.10.22-linux-amd64.zip  resize.log  snap Extracting the Archive Next, install the package that performs ZIP archive extraction: sudo apt install unzip -y The -y flag is added so that the installer automatically answers 'yes' to all questions. Now extract the NATS archive using the installed extractor: unzip nats-server-v2.10.22-linux-amd64.zip Check the file list: ls As you can see, a new folder with the archive contents has appeared: nats-server-v2.10.22-linux-amd64  nats-server-v2.10.22-linux-amd64.zip  resize.log  snap We no longer need the archive, so delete it: rm nats-server-v2.10.22-linux-amd64.zip Installing NATS Server Installation Let's look at the contents of the created folder: ls nats-server-v2.10.22-linux-amd64 Inside it is the main directory with the NATS server: LICENSE  nats-server  README.md This is what we need to copy to the system catalog with binary files: sudo mv nats-server-v2.10.22-linux-amd64/nats-server /usr/local/bin/ After copying, you need to set the appropriate access permissions: sudo chmod +x /usr/local/bin/nats-server The folder with NATS contents, like the archive, can now also be deleted: rm nats-server-v2.10.22-linux-amd64 -R Server Verification Let's verify that the NATS server is installed by requesting its version: nats-server -v A similar output should appear in the console terminal: nats-server: v2.10.22 However, this command doesn't start the server; it only returns its version. You can start the server as follows: nats-server [3704] 2024/11/07 02:59:53.908362 [INF] Starting nats-server [3704] 2024/11/07 02:59:53.908623 [INF] Version: 2.10.22 [3704] 2024/11/07 02:59:53.908669 [INF] Git: [240e9a4] [3704] 2024/11/07 02:59:53.908701 [INF] Name: NC253DIPURNIY4HUXYQYC5LLAFA6UZEBKUIWTBLLPSMICFH3E2FMSXB7 [3704] 2024/11/07 02:59:53.908725 [INF] ID: NC253DIPURNIY4HUXYQYC5LLAFA6UZEBKUIWTBLLPSMICFH3E2FMSXB7 [3704] 2024/11/07 02:59:53.909430 [INF] Listening for client connections on 0.0.0.0:4222 [3704] 2024/11/07 02:59:53.909679 [INF] Server is ready In this case, the server starts with binding to the console terminal, not as a background service. Therefore, to return to command input mode, you need to press Ctrl + C. NATS Configuration Creating a Configuration File After the broker server is started, you can create a separate directory for the NATS configuration file: mkdir /etc/nats And then create the configuration file itself: sudo nano /etc/nats/nats-server.conf Its contents will be as follows: cluster { name: "test-nats" } store_dir: "/var/lib/nats" listen: "0.0.0.0:4222" Specifically in this configuration, the most basic parameters are set: name: Server name within the NATS cluster store_dir: Path to the directory where working data will be stored listen: IP address and port that the NATS server will occupy Creating a Separate User For all directories related to NATS, you need to create a separate user: useradd -r -c 'NATS service' nats Now create the directories specified in the configuration file: mkdir /var/log/nats /var/lib/nats For each directory, assign appropriate access permissions to the previously created user: chown nats:nats /var/log/nats /var/lib/nats Creating a Background Service Earlier we started the NATS server with binding to the console terminal. In this case, when exiting the console, the server will stop working. To prevent this, you need to create a file for the systemd service: sudo nano /etc/systemd/system/nats-server.service Its contents will be: [Unit] Description=NATS message broker server After=syslog.target network.target [Service] Type=simple ExecStart=/usr/local/bin/nats-server -c /etc/nats/nats-server.conf User=nats Group=nats LimitNOFILE=65536 ExecReload=/bin/kill -HUP $MAINPID Restart=on-failure [Install] WantedBy=multi-user.target This file contains several key parameters: Description: Short description of the service ExecStart: NATS server startup command with the configuration file explicitly specified User: Name of the user created for NATS Now we need to set up the service to start up at boot:  systemctl enable nats-server --now The --now flag immediately starts the specified service. The corresponding message will appear in the console: Created symlink /etc/systemd/system/multi-user.target.wants/nats-server.service → /etc/systemd/system/nats-server.service. Now check the status of the running service: systemctl status nats-server If the NATS server service started successfully, the corresponding message will be among the console output: ... Active: active (running) ... Connecting to NATS You can connect to the NATS server through the console terminal and thus perform message broker testing. For example, publish messages or subscribe to subjects. Client Installation To manage the NATS server, you need to install the natscli client. You can download it from the official GitHub repository: wget https://github.com/nats-io/natscli/releases/download/v0.1.5/nats-0.1.5-amd64.deb After this, the downloaded archive can be extracted and installed: dpkg -i nats-0.1.5-amd64.deb The archive itself can be deleted as it's no longer needed: rm nats-0.1.5-amd64.deb Sending Messages Now you can send a message to the message broker: nats pub -s 127.0.0.1 "someSubject" "Some message" In this command, we send the message "Some message" to the subject "someSubject" to the message broker running on IP address 127.0.0.1 and located on the standard NATS port - 4222. After this, information about the sent data will appear in the console terminal: 10:59:51 Published 12 bytes to "someSubject" Reading Messages Currently, no one will see this message since there's no agent subscribed to the specified subject. We can simulate a service subscribed to the subject and reading messages using another SSH session. To do this, you need to open another console terminal, connect to the remote machine, and subscribe to the previously specified subject: nats sub -s 127.0.0.1 "someSubject" A message about successful subscription will appear in the terminal: 11:11:10 Subscribing on someSubject Now repeat sending the message from the first terminal: nats pub -s 127.0.0.1 "someSubject" "Some message" Information about the new message will appear in the second terminal: [#1] Received on "someSubject" Some message Let's send another message from the first terminal: nats pub -s 127.0.0.1 "someSubject" "Some message again" The corresponding notification will appear in the second terminal: [#2] Received on "someSubject" Some message again Note that the console output of received messages has numbering in square brackets. Go Program + NATS Let's create a small program in the Golang programming language using the NATS message broker. Installing Go First, you need to ensure that the Go compiler is installed in the system: go version If the following message appears in the console terminal, then Go is not yet installed: Command 'go' not found, but can be installed with: snap install go # version 1.23.2, or apt install golang-go # version 2:1.18~0ubuntu2 apt install gccgo-go # version 2:1.18~0ubuntu2 See 'snap info go' for additional versions. In this case, you need to download it as an archive from the official website: wget https://go.dev/dl/go1.23.3.linux-amd64.tar.gz -O go.tar.gz And then extracted: sudo tar -xzvf go.tar.gz -C /usr/local As we no longer need the downloaded archive, we can delete it: rm go.tar.gz Next, you need to add the Go compiler to the PATH variable so it can be called from the console terminal: echo export PATH=$HOME/go/bin:/usr/local/go/bin:$PATH >> ~/.profile Then apply the changes: source ~/.profile Verify that Go is installed successfully by requesting its version: go version You will see a similar output: go version go1.23.3 linux/amd64 Creating a Project Let's create a separate folder for the Golang program: mkdir nats_go Then navigate to it: cd nats_go And initialize the Go project: go mod init nats_go Installing the Module After project initialization, you need to install the NATS client from the official GitHub repository. You don't need to download anything manually; it's enough to use the built-in Golang function: go get github.com/nats-io/nats.go/ Writing Code Now you can create a file with the program code: nano nats_go.go Its contents will be: package main import ( "fmt" // module for working with console "os" // module for working with system functions "time" // module for working with time "github.com/nats-io/nats.go" // module for working with NATS server ) func main() { // get NATS server address from environment variable url := os.Getenv("NATS_URL") // if there's no address in environment variable, use default address if url == "" { url = nats.DefaultURL } // connect to NATS server nc, _ := nats.Connect(url) // defer message broker cleanup until main() function completion defer nc.Drain() // send message to subject without subscribers to ensure it disappears nc.Publish("people.philosophers", []byte("Hello, Socrates!")) // subscribe to all sub-subjects in "people" subject sub, _ := nc.SubscribeSync("people.*") // extract message msg, _ := sub.NextMsg(10 * time.Millisecond) // output message status (it's not there because it was sent before subscribing to subjects) fmt.Printf("No message? Answer: %v\n", msg == nil) // send message to "philosophers" sub-subject of "people" subject nc.Publish("people.philosophers", []byte("Hello, Socrates!")) // send message to "physicists" sub-subject of "people" subject nc.Publish("people.physicists", []byte("Hello, Feynman!")) // extract message and output to console msg, _ = sub.NextMsg(10 * time.Millisecond) fmt.Printf("Message: %q in subject %q\n", string(msg.Data), msg.Subject) // extract message and output to console msg, _ = sub.NextMsg(10 * time.Millisecond) fmt.Printf("Message: %q in subject %q\n", string(msg.Data), msg.Subject) // send message to "biologists" sub-subject of "people" subject nc.Publish("people.biologists", []byte("Hello, Darwin!")) // extract message and output to console msg, _ = sub.NextMsg(10 * time.Millisecond) fmt.Printf("Message: %q in subject %q\n", string(msg.Data), msg.Subject) } Now you can run the created program: go run . The program's output will appear in the console terminal: No message? Answer: true Message: "Hello, Socrates!" in subject "people.philosophers" Message: "Hello, Feynman!" in subject "people.physicists" Message: "Hello, Darwin!" in subject "people.biologists" Python Program + NATS As another example, let's consider using the NATS message broker in the Python programming language. First, you need to ensure that the Python interpreter is installed in the system by requesting its version: python --version The corresponding message will appear in the console: Python 3.10.12 Note that this guide uses Python version 3.10.12. Installing PIP To download the NATS client for Python, you first need to install the PIP package manager: apt install python3-pip -y The -y flag helps automatically answer positively to all questions during installation. Installing the Client Now you can install the NATS client for Python: pip install nats-py Creating a Project For the Python program, let's create a separate directory: mkdir nats_python And navigate to it: cd nats_python Writing Code Let's create a file with the program code: nano nats_python.py Its contents will be: import os import asyncio # import NATS client import nats from nats.errors import TimeoutError # get environment variable containing NATS server address servers = os.environ.get("NATS_URL", "nats://localhost:4222").split(",") async def main(): # connect to NATS server nc = await nats.connect(servers=servers) # send message to subject without subscribers to ensure it disappears await nc.publish("people.philosophers", "Hello, Socrates!".encode()) # subscribe to all sub-subjects in "people" subject sub = await nc.subscribe("people.*") try: # extract message msg = await sub.next_msg(timeout=0.1) except TimeoutError: pass # send message to "philosophers" sub-subject of "people" subject await nc.publish("people.philosophers", "Hello, Socrates!".encode()) # send message to "physicists" sub-subject of "people" subject await nc.publish("people.physicists", "Hello, Feynman!".encode()) # extract message and output to console msg = await sub.next_msg(timeout=0.1) print(f"{msg.data.decode('utf-8')} in subject {msg.subject}") # extract message and output to console msg = await sub.next_msg(timeout=0.1) print(f"{msg.data.decode('utf-8')} in subject {msg.subject}") # send message to "biologists" sub-subject of "people" subject await nc.publish("people.biologists", "Hello, Darwin!".encode()) # extract message and output to console msg = await sub.next_msg(timeout=0.1) print(f"{msg.data.decode('utf-8')} in subject {msg.subject}") # unsubscribe from subjects await sub.unsubscribe() # clean up message broker await nc.drain() if __name__ == '__main__': asyncio.run(main()) Now you can run the created script: python nats_python.py The result of its operation will be the following output in the console terminal: Hello, Socrates! in subject people.philosophers Hello, Feynman! in subject people.physicists Hello, Darwin! in subject people.biologists As you can notice, the logic of this Python program doesn't differ from the logic of the Go program. The difference is only in the syntactic constructions of the specific programming language. Conclusion This guide examined the use of the NATS message broker in sequential stages: Downloading and installing NATS from the official GitHub repository Minimal NATS server configuration Managing the NATS server through the console terminal client Using NATS in a Golang program Using NATS in a Python program We downloaded all NATS clients used in this guide (for terminal, Go, and Python) from the official NATS repository on GitHub, which hosts modules and libraries for all programming languages supported by NATS. You can find more detailed information about configuring and using NATS in the official documentation. There are also many examples of using NATS in different programming languages.
24 June 2025 · 13 min to read
Linux

Listing and Deleting Iptables Firewall Rules

The iptables application is a firewall essential for securely working with network resources on the Linux platform. While there is extensive material dedicated to configuring iptables, we will focus on a few specific tasks: how to view rule lists, delete unnecessary rules, flush chains, and clear the packet count and byte size counters.  We do not recommend modifying the SSH connection on port 22 unless you are absolutely sure of your actions, as you might accidentally block remote access to your test host. In this guide, we will use a Hostman cloud server running Ubuntu. The setup process will be similar on CentOS and Debian. Before proceeding, make sure you have a user with sudo privileges. Viewing Rules In iptables, you can view the rules set by default or by a previous administrator. Execute the command: sudo iptables -S The result will be displayed like this: -P INPUT DROP -P FORWARD DROP -P OUTPUT ACCEPT -N ICMP -N TCP -N UDP -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT -A INPUT -i lo -j ACCEPT -A INPUT -m conntrack --ctstate INVALID -j DROP -A INPUT -p udp -m conntrack --ctstate NEW -j UDP -A INPUT -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -m conntrack --ctstate NEW -j TCP -A INPUT -p icmp -m conntrack --ctstate NEW -j ICMP -A INPUT -p udp -j REJECT --reject-with icmp-port-unreachable -A INPUT -p tcp -j REJECT --reject-with tcp-reset -A INPUT -j REJECT --reject-with icmp-proto-unreachable -A TCP -p tcp -m tcp --dport 22 -j ACCEPT Viewing a Specific Chain This function is used when you want to exclude a specific chain (e.g., INPUT, OUTPUT, TCP, etc.) from the general output. Specify the chain name after the -S option. Example: sudo iptables -S TCP The result: -N TCP -A TCP -p tcp -m tcp --dport 22 -j ACCEPT View Rules as a Table This method is convenient for comparing different rules. The tabular format is built into the utility and is activated using the -L option. Enter: sudo iptables -L You can also limit the output to a specific chain: sudo iptables -L INPUT Sample output: Chain INPUT (policy DROP) target prot opt source destination ACCEPT all -- anywhere anywhere ctstate RELATED,ESTABLISHED ACCEPT all -- anywhere anywhere DROP all -- anywhere anywhere ctstate INVALID UDP udp -- anywhere anywhere ctstate NEW TCP tcp -- anywhere anywhere tcp flags:FIN,SYN,RST,ACK/SYN ctstate NEW ICMP icmp -- anywhere anywhere ctstate NEW REJECT udp -- anywhere anywhere reject-with icmp-port-unreachable REJECT tcp -- anywhere anywhere reject-with tcp-reset REJECT all -- anywhere anywhere reject-with icmp-proto-unreachable Explanation: target – action taken when a packet matches the rule (e.g., ACCEPT, DROP, redirect to another chain). prot – protocol used (UDP, TCP, ALL). opt – IP options, if any. source – source IP/subnet (e.g., "anywhere" = from anywhere). destination – destination IP/subnet. The last column (without a header) contains additional rule parameters like port numbers or connection states. Viewing Packet and Byte Counters You can also display the packet and total byte count per rule. This is useful for estimating traffic by rule. Available with -L and -v: sudo iptables -L INPUT -v Sample output: Chain INPUT (policy DROP 0 packets, 0 bytes) pkts bytes target prot opt in out source destination 284K 42M ACCEPT all -- any any anywhere anywhere ctstate RELATED,ESTABLISHED 0 0 ACCEPT all -- lo any anywhere anywhere 0 0 DROP all -- any any anywhere anywhere ctstate INVALID 396 63275 UDP udp -- any any anywhere anywhere ctstate NEW 17067 1005K TCP tcp -- any any anywhere anywhere tcp flags:FIN,SYN,RST,ACK/SYN ctstate NEW 2410 154K ICMP icmp -- any any anywhere anywhere ctstate NEW 396 63275 REJECT udp -- any any anywhere anywhere reject-with icmp-port-unreachable 2916 179K REJECT all -- any any anywhere anywhere reject-with icmp-proto-unreachable 0 0 ACCEPT tcp -- any any anywhere anywhere tcp dpt:ssh ctstate NEW,ESTABLISHED Compare this to previous output and you’ll see two new columns: pkts and bytes. Resetting Packet and Byte Counters You can reset these counters using the -Z option. This happens automatically on reboot, but can also be done manually to test for new traffic: sudo iptables -Z To reset a specific chain: sudo iptables -Z OUTPUT To reset a specific rule in a chain by number: sudo iptables -Z OUTPUT 2 Deleting Rules Deleting by Specification Use -D followed by the full rule specification. View existing rules first. For example, to remove the rule that drops invalid outgoing traffic: sudo iptables -D OUTPUT -m conntrack --ctstate INVALID -j DROP No need to use -A when deleting. Deleting by Rule Number Use --line-numbers to get rule numbers: sudo iptables -L --line-numbers Sample output: Chain INPUT (policy DROP) num target prot opt source destination 1 ACCEPT all -- anywhere anywhere ctstate RELATED,ESTABLISHED 2 ACCEPT all -- anywhere anywhere 3 DROP all -- anywhere anywhere ctstate INVALID ... Then delete by number: sudo iptables -D INPUT 3 Flushing Chains Be cautious when flushing chains; you could block your SSH connection. Flush a Single Chain sudo iptables -F INPUT Flush All Chains sudo iptables -F This command allows all traffic (inbound, outbound, forwarded), essentially disabling the firewall. If you run it on a production system, you’ll need to reconfigure the firewall from scratch. Always back up your current rules: iptables-save > iptables_backup.txt Restore them later with: iptables-restore < iptables_backup.txt Before flushing, set the default policy to ACCEPT to avoid losing SSH access: sudo iptables -P INPUT ACCEPT sudo iptables -P FORWARD ACCEPT sudo iptables -P OUTPUT ACCEPT Then flush everything: sudo iptables -t nat -F sudo iptables -t mangle -F sudo iptables -F sudo iptables -X This allows all traffic. If you list rules after this, only the default chains (INPUT, FORWARD, OUTPUT) will be present. Conclusion This tutorial provides practical guidance on how to view, reset, and delete iptables firewall rules and perform similar actions on specific chains. Keep in mind that any changes will be lost upon server reboot unless saved.
23 June 2025 · 6 min to read
Linux

How to Mount an SMB Share in Linux

The Server Message Block (SMB) protocol facilitates network file sharing, allowing applications to read and write to files and request services from server programs. This protocol is pivotal for seamless communication between different devices in a network, particularly in mixed OS environments like Windows and Linux. Mounting an SMB share in Linux enables users to access files on a Windows server or another SMB-enabled device directly from their Linux system. This tutorial will guide you through the process of mounting an SMB share on Linux, ensuring smooth file sharing and network communication. Prerequisites for Mounting SMB Shares Before mounting an SMB share, ensure the following prerequisites are met: A Linux system, such as a Hostman cheap cloud server, with root or sudo privileges. The cifs-utils package installed on your Linux system. Access credentials (username and password) for the SMB share. Network connectivity between your Linux system and the SMB server. Installing Necessary Packages The cifs-utils package is essential for mounting SMB shares on Linux. Additionally, the psmisc package provides the fuser command, which helps manage and monitor file usage. Update Package List and Upgrade System First, update your package list and upgrade your system: sudo apt update Install cifs-utils and psmisc Install the necessary packages: sudo apt install cifs-utils psmisc Verify Installation Verify the installation of cifs-utils and availability of the fuser command: mount -t cifsfuser Finding SMB Share Details Identify the SMB share details, including the server name or IP address and the share name. You might need to consult your network administrator or check the server configuration. Example: Server: smbserver.example.com Share: sharedfolder Mounting SMB Shares Using the mount Command To mount the SMB share, use the mount command with the -t cifs option, specifying the SMB protocol. Create a directory to serve as the mount point: sudo mkdir /mnt/smb_share Mount the SMB share using the following command: sudo mount -t cifs -o username=your_username,password=your_password //192.0.2.17/SharedFiles /mnt/smb_share Replace your_username and your_password with your actual username and password. Ensure /mnt/smb_share is an existing directory. Verifying the Mount To confirm that the SMB share is successfully mounted, use the mount command: mount -t cifs Navigate to the mount point and list the files: cd /mnt/smb_sharels Creating a Credentials File To avoid entering credentials each time, create a credentials file. This file should be hidden and secured. Use a text editor to create the file: nano ~/.smbcredentials Add the following content, replacing with your actual credentials: username=your_usernamepassword=your_password Set appropriate permissions for the file: sudo chown your_username: ~/.smbcredentialssudo chmod 600 ~/.smbcredentials Mount Using the Credentials File Mount the SMB share using the credentials file: sudo mount -t cifs -o credentials=~/.smbcredentials //192.168.2.12/SharedFiles /mnt/smb_share Automating SMB Share Mounts To automate the mounting process, add an entry to the /etc/fstab file. This will ensure the SMB share is mounted at boot. 1. Open /etc/fstab for editing: sudo nano /etc/fstab 2. Add the following line: //smbserver.example.com/sharedfolder /mnt/smbshare cifs username=johndoe,password=securepassword,iocharset=utf8,sec=ntlm 0 0 3. Save and close the file. 4. Test the fstab entry: sudo mount -a Ensure no errors are displayed. Troubleshooting Common Issues Permission Denied Check your credentials and permissions on the SMB server. No Such File or Directory Ensure the server IP, share path, and mount point are correct. Mount Error 13 = Permission Denied Double-check your username and password. Mount Error 112 = Host is Down Verify network connectivity and server availability. Unmounting an SMB Share To unmount the SMB share, use the umount command followed by the mount point: sudo umount /mnt/smb_share Conclusion Mounting an SMB share in Linux is a straightforward process that enhances file sharing capabilities across different operating systems. By following this tutorial, you can efficiently set up and troubleshoot SMB share mounts, facilitating seamless network communication and file access. Don't forget to check how to configure server image on Lunix! Frequently Asked Questions What is Samba in Linux and how does it relate to SMB? Samba is an open-source implementation of the SMB/CIFS protocol in Linux. It allows Linux systems to share files and printers with Windows devices over a network. What is the command to mount a Windows share in Linux? Use mount -t cifs //server/share /mnt/share -o username=your_user. How can I auto-mount an SMB share on boot in Linux? Add the mount configuration to /etc/fstab using proper credentials. Do I need root access to mount an SMB share? For traditional mounting, yes. But user-space tools like gio mount can be used without root.
16 June 2025 · 4 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.
Email us
Hostman's Support