From 3d3eadb883fd9adc45dfc0c5f4d4e3df2b86d57c Mon Sep 17 00:00:00 2001 From: nishaaaaaant Date: Wed, 27 Mar 2024 22:54:53 -0400 Subject: [PATCH] #1867 fix markdown violation in automation folder --- docs/guides/automation/anacron.md | 26 +-- docs/guides/automation/cron_jobs_howto.md | 66 +++--- docs/guides/automation/cronie.md | 50 ++--- .../templates-automation-packer-vsphere.md | 198 +++++++++--------- 4 files changed, 168 insertions(+), 172 deletions(-) diff --git a/docs/guides/automation/anacron.md b/docs/guides/automation/anacron.md index 2a9a0e09b2..ecedeb6c84 100644 --- a/docs/guides/automation/anacron.md +++ b/docs/guides/automation/anacron.md @@ -5,22 +5,22 @@ contributors: Steven Spencer, Ganna Zhyrnova update : 2021-10-20 --- -# `anacron` - Run Commands Regularly +# `anacron` - Run Commands Regularly -## Prerequisites +## Prerequisites -* A computer running Rocky Linux. -* Know how to use your favorite editor to change the configuration file (such as *vim*) in the command line environment. -* Understand basic RPM package management. +- A computer running Rocky Linux. +- Know how to use your favorite editor to change the configuration file (such as *vim*) in the command line environment. +- Understand basic RPM package management. -## Assumptions +## Assumptions -* You have the basic knowledge of bash, python or other scripting or programming tools, and want to run the script automatically. -* You connected in as the root user, or switch to root with `su - root`. +- You have the basic knowledge of bash, python or other scripting or programming tools, and want to run the script automatically. +- You connected in as the root user, or switch to root with `su - root`. -## `anacron` Introduction +## Introduction -**`anacron` runs commands on a regular basis, and the operating frequency is defined in units of days. It is suitable for computers that do not run 24/7, such as laptops and desktops. Suppose you have a scheduled task (such as a backup script) to be run in the early morning of every day using crontab. When you fall asleep, your desktop or notebook is off. Your backup script will not run. However, if you use `anacron`, you can rest assured that the next time you turn on the desktop or notebook, the backup script will run.** +`anacron` runs commands on a regular basis, and the operating frequency is defined in units of days. It is suitable for computers that do not run 24/7, such as laptops and desktops. Suppose you have a scheduled task (such as a backup script) to be run in the early morning of every day using crontab. When you fall asleep, your desktop or notebook is off. Your backup script will not run. However, if you use `anacron`, you can rest assured that the next time you turn on the desktop or notebook, the backup script will run.** The appearance of `anacron` is not to replace `crontab`, but to complement `crontab`. Their relationship is as follows: @@ -45,6 +45,7 @@ shell > rpm -ql cronie-anacron ``` First check the default configuration file: + ```bash shell > cat /etc/anacrontab # /etc/anacrontab: configuration file for anacron @@ -75,7 +76,8 @@ PATH=/sbin:/bin:/usr/sbin:/usr/bin MAILTO=root 01 * * * * root run-parts /etc/cron.hourly ``` -``` + +```bash shell > journalctl -u crond.service - Logs begin at Wed 2021-10-20 19:27:39 CST, end at Wed 2021-10-20 23:32:42 CST. - October 20 19:27:42 li systemd[1]: Started Command Scheduler. @@ -86,7 +88,6 @@ October 20 20:01:01 li CROND[1897]: (root) CMD (run-parts /etc/cron.hourly) October 20 21:01:01 li CROND[1922]: (root) CMD (run-parts /etc/cron.hourly) October 20 22:01:01 li CROND[1947]: (root) CMD (run-parts /etc/cron.hourly) October 20 23:01:01 li CROND[2037]: (root) CMD (run-parts /etc/cron.hourly) - ``` For more configuration file information, [browse the manual page](https://man7.org/linux/man-pages/man5/anacrontab.5.html) @@ -95,7 +96,6 @@ For more configuration file information, [browse the manual page](https://man7.o To make certain files run within these automatically defined times, all you need to do is to copy the script file to the relevant directory and verify that it has **execution permission (chmod +x)**. Therefore, you only need to let the system automatically run the script at one of these scheduled times, which simplifies the automation task. - Let us use cron.daily to illustrate the run process of /etc/anacrontab: 1. `anacron` reads the **/var/spool/anacron/cron.daily** file, and the content of the file shows the time of the last run. diff --git a/docs/guides/automation/cron_jobs_howto.md b/docs/guides/automation/cron_jobs_howto.md index 51564a5063..dbca51b8d9 100644 --- a/docs/guides/automation/cron_jobs_howto.md +++ b/docs/guides/automation/cron_jobs_howto.md @@ -13,28 +13,28 @@ tags: ## Prerequisites -* A computer running Rocky Linux -* Some comfort with modifying configuration files from the command-line by using your favorite editor (using `vi` here) +- A computer running Rocky Linux +- Some comfort with modifying configuration files from the command-line by using your favorite editor (using `vi` here) -## Assumptions +## Assumptions -* Basic knowledge of bash, python, or other scripting or programming tools, and you want to have a script run automatically -* That you are running as the root user or have the ability to `sudo -s` +- Basic knowledge of bash, python, or other scripting or programming tools, and you want to have a script run automatically +- That you are running as the root user or have the ability to `sudo -s` **(You can run certain scripts in your own directories as your own user. In this case, switching to root is not necessary.)** ## Introduction -Linux provides the _cron_ system, a time-based job scheduler, for automating processes. It is simplistic and yet quite powerful. Want a script or program to run every day at 5 PM? This is where you set that up. +Linux provides the *cron* system, a time-based job scheduler, for automating processes. It is simplistic and yet quite powerful. Want a script or program to run every day at 5 PM? This is where you set that up. -The _crontab_ is essentially a list where users add their own automated tasks and jobs, and it has many options that can simplify things even further. This document will explore some of these. It is a good refresher for those with some experience, and new users can add the `cron` system to their toolbox. +The *crontab* is essentially a list where users add their own automated tasks and jobs, and it has many options that can simplify things even further. This document will explore some of these. It is a good refresher for those with some experience, and new users can add the `cron` system to their toolbox. Discussed briefly here is `anacron` in reference to the `cron` "dot" directories. `cron` runs by `anacron`, and is helpful for machines that are not up all the time, such as workstations and notebooks. The reason for this is that while `cron` runs jobs on a schedule, if the machine is off at the scheduled job time, the job does not run. With `anacron` the job will run when the machine is on again, even if the scheduled run was in the past. `anacron` though, uses a more randomized approach to running tasks where the timing is not exact. This makes sense for workstations and notebooks, but not for servers. This can be a problem for things such as server backups, for instance, needing to run a job at a specific time. That is where `cron` provides the best solution for server administrators. Still, server administrators and workstation or notebook users can gain something from both approaches. You can mix and match based on your needs. For more on `anacron` see [anacron - Automating commands](anacron.md). -### Starting easy - the `cron` dot directories +### Starting easy - the `cron` dot directories Built into every Linux system for many versions now, the `cron` "dot" directories help to automate processes quickly. These show up as directories that the `cron` system calls based on their naming conventions. These run differently, however, based on the process assigned to call them, `anacron` or `cron`. The default behavior is to use `anacron`, but this is changeable by a server, workstation or notebook administrator. -#### For servers +#### For servers As stated in the introduction, `cron` normally runs `anacron` these days to run scripts in these "dot" directories. You *may* want to use these "dot" directories on servers as well, and if that is the case, it requires two steps to verify that these "dot" directories run on a strict schedule. To do this, you need to install a package and remove another one: @@ -46,7 +46,7 @@ and As you might expect, this removes `anacron` from the server and reverts to running tasks within the "dot" directories on a strict schedule. `/etc/cron.d/dailyjobs` is the file that controls the schedule, which has the following contents: -``` +```bash # Run the daily, weekly, and monthly jobs if cronie-anacron is not installed SHELL=/bin/bash PATH=/sbin:/bin:/usr/sbin:/usr/bin @@ -60,18 +60,18 @@ MAILTO=root This translates to the following: -* run scripts in `cron.daily` at 04:02:00 every day. -* run scripts in `cron.weekly` at 04:22:00 on Sunday every week. -* run scripts in `cron.monthly` at 04:42:00 on the first day of every month. +- run scripts in `cron.daily` at 04:02:00 every day. +- run scripts in `cron.weekly` at 04:22:00 on Sunday every week. +- run scripts in `cron.monthly` at 04:42:00 on the first day of every month. -#### For workstations +#### For workstations If you want to run scripts on a workstation or notebook in the `cron` "dot" directories, you need not do anything complicated. Copy your script file into the directory in question, and ensure it is executable. Here are the directories: -* `/etc/cron.hourly` - Scripts placed here will run one minute past the hour every hour (run by `cron` regardless of whether `anacron` exists or not) -* `/etc/cron.daily` - Scripts placed here will run every day. `anacron` adjusts the timing of these (see tip) -* `/etc/cron.weekly` - Scripts placed here will run every 7 days, based on the calendar day of the last run time (see tip) -* `/etc/cron.monthly` - Scripts placed here will run monthly based on the calendar day of the last run time (see tip) +- `/etc/cron.hourly` - Scripts placed here will run one minute past the hour every hour (run by `cron` regardless of whether `anacron` exists or not) +- `/etc/cron.daily` - Scripts placed here will run every day. `anacron` adjusts the timing of these (see tip) +- `/etc/cron.weekly` - Scripts placed here will run every 7 days, based on the calendar day of the last run time (see tip) +- `/etc/cron.monthly` - Scripts placed here will run monthly based on the calendar day of the last run time (see tip) !!! tip @@ -91,7 +91,7 @@ If the automated, randomized times do not work well in [For Workstations above]( This will pull up root user's `crontab` as it exists at this moment in your chosen editor, and might look something like this. Read this commented version, as it has descriptions of each field that you will use next: -``` +```text # Edit this file to introduce tasks to be run by cron. # # Each task to run has to be defined through a single line @@ -119,17 +119,17 @@ This will pull up root user's `crontab` as it exists at this moment in your chos Notice that this particular `crontab` file has some of its own documentation built-in. That is not always the case. When modifying a `crontab` on a container or minimalist operating system, the `crontab` will be an empty file unless an entry is in it. -Assume that you have a backup script that you want to run at 10 PM at night. The `crontab` uses a 24 hour clock, this would be 22:00. Assume that you backup script is "backup" and that it is currently in the _/usr/local/sbin_ directory. +Assume that you have a backup script that you want to run at 10 PM at night. The `crontab` uses a 24 hour clock, this would be 22:00. Assume that you backup script is "backup" and that it is currently in the */usr/local/sbin* directory. !!! note Remember that this script needs to also be executable (`chmod +x`) in order for the `cron` to run it. -To list the present jobs running +To list the present jobs running `crontab -l` -To list all jobs created by user +To list all jobs created by user `crontab -l -u ` @@ -139,13 +139,13 @@ To add the job, you: `crontab` stands for "cron table" and the format of the file is, in fact, a loose table layout. Now that you are in the `crontab`, go to the bottom of the file and add your entry. If you use `vi` as your default system editor, you will do this with the following keys: -SHIFT+:+$ +++shift+colon+"$"++ Now that you are at the bottom of the file, insert a line and enter a brief comment to describe what is going on with your entry. You do this by adding a "#" to the beginning of the line: `# Backing up the system every night at 10PM` -Hit ENTER. You should still be in the insert mode, so the next step is to add your entry. As shown in our empty commented `crontab` (above) this is **m** for minutes, **h** for hours, **dom** for day of month, **mon** for month, and **dow** for day of week. +Hit ++enter++. You should still be in the insert mode, so the next step is to add your entry. As shown in our empty commented `crontab` (above) this is **m** for minutes, **h** for hours, **dom** for day of month, **mon** for month, and **dow** for day of week. To run our backup script every day at 10:00, the entry looks like this: @@ -157,12 +157,12 @@ This says run the script at 10 PM, every day of the month, every month, and ever Another way to run jobs at a strictly scheduled time (i.e., day, week, month, year, and so on.) is to use the @options, which offer the ability to use more natural timing. The @options consist of: -* `@hourly` runs the script every hour of every day at 0 minutes past the hour (this is exactly the result of placing your script in `/etc/cron.hourly` too). -* `@daily` runs the script every day at midnight. -* `@weekly` runs the script every week at midnight on Sunday. -* `@monthly` runs the script every month at midnight on the first day of the month. -* `@yearly` runs the script every year at midnight on the first day of January. -* `@reboot` runs the script on system startup only. +- `@hourly` runs the script every hour of every day at 0 minutes past the hour (this is exactly the result of placing your script in `/etc/cron.hourly` too). +- `@daily` runs the script every day at midnight. +- `@weekly` runs the script every week at midnight on Sunday. +- `@monthly` runs the script every month at midnight on the first day of the month. +- `@yearly` runs the script every year at midnight on the first day of January. +- `@reboot` runs the script on system startup only. !!! note @@ -192,9 +192,9 @@ When determining when to run a script, you need to take time and plan it out, pa ## Conclusions -The _cron/crontab_ system is a powerful tool for the Rocky Linux systems administrator or desktop user. It allows you to automate tasks and scripts so that you do not have to remember to run them manually. More complex examples are here: +The *cron/crontab* system is a powerful tool for the Rocky Linux systems administrator or desktop user. It allows you to automate tasks and scripts so that you do not have to remember to run them manually. More complex examples are here: -* For machines that are **not** on 24 hours a day, explore [anacron - Automating commands](anacron.md). -* For a concise description of `cron` processes, check out [cronie - Timed Tasks](cronie.md) +- For machines that are **not** on 24 hours a day, explore [anacron - Automating commands](anacron.md). +- For a concise description of `cron` processes, check out [cronie - Timed Tasks](cronie.md) While the basics are not difficult, the options can be more complex. For more on `crontab` head up to the [crontab manual page](https://man7.org/linux/man-pages/man5/crontab.5.html). On most systems, you can also enter `man crontab` for additional command details. You can also do a web search for "crontab" which will give you a wealth of results to help you fine-tune your `crontab` skills. diff --git a/docs/guides/automation/cronie.md b/docs/guides/automation/cronie.md index 54d98c491b..7450c90c6d 100644 --- a/docs/guides/automation/cronie.md +++ b/docs/guides/automation/cronie.md @@ -5,27 +5,27 @@ contributors: Steven Spencer, Ganna Zhyrnova update: 2021-10-26 --- -# Prerequisite +# Prerequisite * A computer running Rocky Linux. * Know how to use your favorite editor to change the configuration file in the command line environment (this article will use `vi`). * You have understood the basic knowledge of bash, python or other scripting or programming tools, and expect to run the script automatically. * You have connected to your computer by SSH (it can be root user or ordinary user with UID greater than 1000). -## cron Introduction +## cron Introduction GNU/Linux provides the *cron* system, which is a time-based `cron` jobs program for automated processes. It is not hard, but quite powerful. Want a script or program to run at 5 pm every day? `cron` can do it. There are different branches (or variants) of `cron`, which have the same functions. In this document, **cronie** is used, and the version is 1.5.2. You can click [here](https://github.com/cronie-crond/cronie) to find the latest version and update log. -## cronie's Description +## cronie's Description -* **cronie** -package name, Rocky Linux includes cronie by default; -* **crontab** -command to maintain `crontab` (task schedule) for each user; -* **crond.service** -cronie's daemon, you can manage the daemon by `systemctl start | restart | stop | status` ; -* **/etc/crontab** -Assign cron jobs to different users, usually we are more accustomed to using `crontab -e` . For example, if you are currently logged in as the root user, type `crontab -e` and you will see specific cron jobs in the file /var/spool/cron/root after saving. -* **/var/log/cron** \* -Cronie's log, by default, does log rotation and ends with a date suffix. Here, it means wildcard. -* **anacron** -part of cronie . For more information about `anacron`, see [anacron-automation commands](anacron.md). +* **cronie** -package name, Rocky Linux includes cronie by default; +* **crontab** -command to maintain `crontab` (task schedule) for each user; +* **crond.service** -cronie's daemon, you can manage the daemon by `systemctl start | restart | stop | status` ; +* **/etc/crontab** -Assign cron jobs to different users, usually we are more accustomed to using `crontab -e` . For example, if you are currently logged in as the root user, type `crontab -e` and you will see specific cron jobs in the file /var/spool/cron/root after saving. +* **/var/log/cron** \* -Cronie's log, by default, does log rotation and ends with a date suffix. Here, it means wildcard. +* **anacron** -part of cronie . For more information about `anacron`, see [anacron-automation commands](anacron.md). -## `crontab` Command +## `crontab` Command `crontab` is a command obtained after installation of the cronie package. Compared with `anacron`, it is more suitable for servers that work 7 \* 24 hours a day. Common options of `crontab` are: @@ -35,7 +35,7 @@ the -l # View crontab task -r # delete all the current user's crontab tasks ``` -## Use of cronie +## Use of cronie To allow different users to execute different commands (or scripts) at different times, they can be written into this file. However, usually we are more accustomed to using `crontab -e`. @@ -63,9 +63,9 @@ MAILTO=root |The 4th\*|The month of the year|1-12| |The 5th\*|Day of the week|0-7 (0 and 7 both indicate Sunday)| -In the example that follows, assuming you are performing this operation as the root user, type the following: +In the example that follows, assuming you are performing this operation as the root user, type the following: -* `crontab -e` which will bring up the timed tasks of the root user. If you use `vi` as the default system editor, press i key to enter the insert mode. +* `crontab -e` which will bring up the timed tasks of the root user. If you use `vi` as the default system editor, press ++i++ key to enter the insert mode. * "#" means this is a line of comment. ```bash @@ -73,8 +73,8 @@ In the example that follows, assuming you are performing this operation as the r 00 22 * * * /usr/local/sbin/backup ``` -* Once the above has been entered (again assuming `vi` is the system editor), press ESC to exit insert mode. -* Save and exit your file with SHIFT+:+wq! (displayed at the bottom of the editor). +* Once the above has been entered (again assuming `vi` is the system editor), press ++escape++ to exit insert mode. +* Save and exit your file with ++shift+colon+"w"+"q"+exclam++ (displayed at the bottom of the editor). Now the script will run every night at 22:00. This is a simplistic example. Things can become more complicated if you need something more elaborate. @@ -82,7 +82,7 @@ Now the script will run every night at 22:00. This is a simplistic example. Thin The script needs to have execute permission (`chmod +x`) before cronie can run it. -#### Complex Options +### Complex Options The content discussed so far are simplistic options, but what about more complex timed tasks? @@ -97,26 +97,26 @@ The content discussed so far are simplistic options, but what about more complex |Special Symbols|Meaning| |---|---| -|* | represents any time. For example, the first * means any minute, and the second * means any hour | -|, | stands for discontinuous time, such as "0 8,12,16 * * * ", which means that the command will run once every day at 8:00, 12:00, and 16:00 | -|- | represents a continuous time range, such as "0 5 * * 1-6 ", which means that a command will run at five o'clock in the morning every day from Monday to Saturday | -|*/n | Represents how often the interval will run, such as "*/10 * * * *" means that it every 10 minutes | +|`*` | represents any time. For example, the first `*` means any minute, and the second `*` means any hour | +|`,` | stands for discontinuous time, such as `0 8,12,16 * * *`, which means that the command will run once every day at 8:00, 12:00, and 16:00 | +|`-` | represents a continuous time range, such as `0 5 * * 1-6`, which means that a command will run at five o'clock in the morning every day from Monday to Saturday | +|`*/n`| Represents how often the interval will run, such as `*/10 * * * *` means that it every 10 minutes | !!! tip "Attention" The smallest time unit that cronie can recognize is 1 minute; when using, for example, `30 4 1,15 * 5 command` , it will cause the command to run on the 1st and 15th of each month and 4:30 in the morning of every Friday ; The output information of some scripts or commands will prevent the execution of timed tasks, and output redirection is required, such as this- `*/10 * * * * /usr/local/sbin/backup &> /dev/null` -## Q and A +## Q and A 1. /etc/crontab and `crontab -e` , is there any difference between the two methods? `crontab -e` does not need to specify a user (the currently logged-in user is used by default), while /etc/crontab needs to specify a user. 2. What should you do if the specified command or script is not run correctly? Check the /var/log/cron* file, use `journalctl -u crond.service` to check the information about the daemon process, whether the script has x permission, etc., for troubleshooting. 3. In addition to cronie, what cron variants are there? -[ fcron ](http://fcron.free.fr/), the latest version is 3.3.0 (dev, 2016-08-14). -[ bcron ](http://untroubled.org/bcron/), the latest version is 0.11 (2015-08-12). -[ cronsun ](https://github.com/shunfei/cronsun), the latest version 0.3.5 (2018-11-20). +[fcron](http://fcron.free.fr/), the latest version is 3.3.0 (dev, 2016-08-14). +[bcron](http://untroubled.org/bcron/), the latest version is 0.11 (2015-08-12). +[cronsun](https://github.com/shunfei/cronsun), the latest version 0.3.5 (2018-11-20). -## Summary +## Summary For Rocky Linux desktop users or system administrators, cronie is a very powerful tool. It allows you to automate tasks and scripts so you do not have to remember to run them manually. Although the basic knowledge is not hard, the actual task can be complex. For more information about `crontab`, visit [crontab man page](https://man7.org/linux/man-pages/man5/crontab.5.html). You can also search for "crontab" on the Internet, which provides you with a large number of search results and help you fine-tune the `crontab` expression. diff --git a/docs/guides/automation/templates-automation-packer-vsphere.md b/docs/guides/automation/templates-automation-packer-vsphere.md index 4375688720..9f4e3fe33d 100644 --- a/docs/guides/automation/templates-automation-packer-vsphere.md +++ b/docs/guides/automation/templates-automation-packer-vsphere.md @@ -6,20 +6,20 @@ contributors: Steven Spencer, Ryan Johnson, Pedro Garcia, Ganna Zhyrnova # Automatic template creation with Packer and deployment with Ansible in a VMware vSphere environment -**Knowledge**: :star: :star: :star: -**Complexity**: :star: :star: :star: +**Knowledge**: :star: :star: :star: +**Complexity**: :star: :star: :star: **Reading time**: 30 minutes ## Prerequisites, Assumptions, and General Notes -* A vSphere environment is available, and a user with granted access -* An internal web server to store files -* Web access to the Rocky Linux repositories -* An ISO of Rocky Linux -* An Ansible environment is available -* It is assumed that you have some knowledge of each product mentioned. If not, dig into that documentation before you begin. -* Vagrant is **not** in use here. It was pointed out that with Vagrant, an SSH key that was not self-signed would be provided. If you want to dig into that you can do so, but it is not covered in this document. +- A vSphere environment is available, and a user with granted access +- An internal web server to store files +- Web access to the Rocky Linux repositories +- An ISO of Rocky Linux +- An Ansible environment is available +- It is assumed that you have some knowledge of each product mentioned. If not, dig into that documentation before you begin. +- Vagrant is **not** in use here. It was pointed out that with Vagrant, an SSH key that was not self-signed would be provided. If you want to dig into that you can do so, but it is not covered in this document. ## Introduction @@ -37,23 +37,23 @@ You can also choose not to convert the virtual machine into a template. In this ### Introduction to Packer -Packer is an open-source virtual machine imaging tool, released under the MPL 2.0 license, and created by HashiCorp. It will help you automate the process of creating virtual machine images with pre-configured operating systems and installed software from a single source configuration in both, cloud and on-prem virtualized environments. +Packer is an open-source virtual machine imaging tool, released under the MPL 2.0 license, and created by HashiCorp. It will help you automate the process of creating virtual machine images with pre-configured operating systems and installed software from a single source configuration in both, cloud and on-prem virtualized environments. With Packer you can create images to be used on the following platforms: -* [Amazon Web Services](https://aws.amazon.com). -* [Azure](https://azure.microsoft.com/en-us/). -* [GCP](https://cloud.google.com). -* [DigitalOcean](https://www.digitalocean.com). -* [OpenStack](https://www.openstack.org). -* [VirtualBox](https://www.virtualbox.org/). -* [VMware](https://www.vmware.com). +- [Amazon Web Services](https://aws.amazon.com). +- [Azure](https://azure.microsoft.com/en-us/). +- [GCP](https://cloud.google.com). +- [DigitalOcean](https://www.digitalocean.com). +- [OpenStack](https://www.openstack.org). +- [VirtualBox](https://www.virtualbox.org/). +- [VMware](https://www.vmware.com). You can have a look at these resources for additional information: -* The [Packer website](https://www.packer.io/) -* [Packer documentation](https://www.packer.io/docs) -* The builder `vsphere-iso`'s [documentation](https://www.packer.io/docs/builders/vsphere/vsphere-iso) +- The [Packer website](https://www.packer.io/) +- [Packer documentation](https://www.packer.io/docs) +- The builder `vsphere-iso`'s [documentation](https://www.packer.io/docs/builders/vsphere/vsphere-iso) ### Installing Packer @@ -63,58 +63,55 @@ There are two ways to install Packer on your Rocky Linux system. HashiCorp maintains and signs packages for different Linux distributions. To install packer in our Rocky Linux system, please follow the next steps: - -#### Download and install from the Packer website - 1. Install dnf-config-manager: -```bash -$ sudo dnf install -y dnf-plugins-core -``` + ```bash + sudo dnf install -y dnf-plugins-core + ``` 2. Add the HashiCorp repository to the available repos in our Rocky Linux system: -```bash -$ sudo dnf config-manager --add-repo https://rpm.releases.hashicorp.com/fedora/hashicorp.repo -``` + ```bash + sudo dnf config-manager --add-repo https://rpm.releases.hashicorp.com/fedora/hashicorp.repo + ``` 3. Install Packer: -```bash -$ sudo dnf -y install packer -``` + ```bash + sudo dnf -y install packer + ``` #### Download and install from the Packer website - You can start by downloading the binaries for your own platform with [Packer downloads](https://www.packer.io/downloads). 1. On the download page, copy the download link in the Linux Binary Download section that corresponds to your system architecture. 2. From a shell or terminal download it using ```wget``` tool: -```bash -$ wget https://releases.hashicorp.com/packer/1.8.3/packer_1.8.3_linux_amd64.zip -``` -This will download a .zip file. + ```bash + wget https://releases.hashicorp.com/packer/1.8.3/packer_1.8.3_linux_amd64.zip + ``` -3. To decompress the downloaded archive, run the following command in the shell: + This will download a .zip file. -```bash -$ unzip packer_1.8.3_linux_amd64.zip -``` +3. To decompress the downloaded archive, run the following command in the shell: + + ```bash + unzip packer_1.8.3_linux_amd64.zip + ``` -!!! tip + !!! tip - If you get an error and you don’t have the unzip app installed on your system, you can install it by executing this command ```sudo dnf install unzip```. + If you get an error and you don’t have the unzip app installed on your system, you can install it by executing this command ```sudo dnf install unzip```. 4. Move the Packer app to the bin folder: -```bash -$ sudo mv packer /usr/local/bin/ -``` + ```bash + sudo mv packer /usr/local/bin/ + ``` -#### Verification of the correct installation of Packer +#### Verification of the correct installation of Packer If all the steps of the previous procedures have been completed correctly, we can proceed to verify the installation of Packer on our system. @@ -147,7 +144,7 @@ As we will connect to a VMware vCenter Server to send our commands via Packer, w Let us create a hidden file with our credentials in our home directory. This is a json file: -``` +```bash $ vim .vsphere-secrets.json { "vcenter_username": "rockstar", "vcenter_password": "mysecurepassword" @@ -158,7 +155,7 @@ Those credentials need some grant access to your vSphere environment. Let us create a json file (in the future, the format of this file will change to the HCL): -``` +```json { "variables": { "version": "0.0.X", @@ -221,13 +218,14 @@ Let us create a json file (in the future, the format of this file will change to ] } ``` + Next, we will describe each section of this file. ### Variables section In a first step, we declare variables, mainly for the sake of readability: -``` +```json "variables": { "version": "0.0.X", "HTTP_IP": "fileserver.rockylinux.lan", @@ -243,19 +241,19 @@ A Kickstart file contains the answers to the questions asked during the installa The author likes to store his `ks.cfg` file in an internal web server accessible from his template, but other possibilities exist that you may choose to use instead. -For example, the `ks.cfg` file is accessible from the VM at this URL in our lab: http://fileserver.rockylinux.lan/packer/rockylinux/8/ks.cfg. You would need to set up something similar to use this method. +For example, the `ks.cfg` file is accessible from the VM at this URL in our lab: . You would need to set up something similar to use this method. Since we want to keep our password private, it is declared as a sensitive variable. Example: -``` - "sensitive-variables": ["vcenter_password"], +```json +"sensitive-variables": ["vcenter_password"], ``` ### Provisioners section Next part is interesting, and will be covered later by providing you the script for `requirements.sh`: -``` +```json "provisioners": [ { "type": "shell", @@ -274,8 +272,7 @@ You can declare one or more builders to target something other than your vSphere But here we are using the `vsphere-iso` builder: - -``` +```json "builders": [ { "type": "vsphere-iso", @@ -283,25 +280,25 @@ But here we are using the `vsphere-iso` builder: This builder lets us configure the hardware we need: -``` - "CPUs": 2, - "CPU_hot_plug": true, - "RAM": 2048, - "RAM_hot_plug": true, - "disk_controller_type": "pvscsi", - "guest_os_type": "centos8_64Guest", - "network_adapters": [ - { - "network_card": "vmxnet3", - "network": "net_infra" - } - ], - "storage": [ - { - "disk_size": 40000, - "disk_thin_provisioned": true - } - ], +```json +"CPUs": 2, +"CPU_hot_plug": true, +"RAM": 2048, +"RAM_hot_plug": true, +"disk_controller_type": "pvscsi", +"guest_os_type": "centos8_64Guest", +"network_adapters": [ + { + "network_card": "vmxnet3", + "network": "net_infra" + } +], +"storage": [ + { + "disk_size": 40000, + "disk_thin_provisioned": true + } +], ``` !!! "Note" @@ -312,21 +309,21 @@ You can do more cool things with the disk, cpu, etc. You should refer to the doc To start the installation, you need an ISO image of Rocky Linux. Here is an example of how to use an image located in a vSphere content library. You can of course store the ISO elsewhere. In the case of a vSphere content library, you have to get the full path to the ISO file on the server hosting the content library. In this case it is Synology, so directly on the DSM explorer. -``` - "iso_paths": [ - "[datasyno-contentlibrary-mylib] contentlib-a86ad29a-a43b-4717-97e6-593b8358801b/3a381c78-b9df-45a6-82e1-3c07c8187dbe/Rocky-8.4-x86_64-minimal_72cc0cc6-9d0f-4c68-9bcd-06385a506a5d.iso" - ], +```json +"iso_paths": [ + "[datasyno-contentlibrary-mylib] contentlib-a86ad29a-a43b-4717-97e6-593b8358801b/3a381c78-b9df-45a6-82e1-3c07c8187dbe/Rocky-8.4-x86_64-minimal_72cc0cc6-9d0f-4c68-9bcd-06385a506a5d.iso" +], ``` Then you have to provide the complete command to be entered during the installation process: configuration of the IP and transmission of the path to the Kickstart response file. -!!! note "Note" +!!! note "Note" This example takes the most complex case: using a static IP. If you have a DHCP server available, the process will be much easier. This is the most amusing part of the procedure: I'm sure you will go and admire the VMware console during the generation, just to see the automatic entry of the commands during the boot. -``` +```json "boot_command": [ " text ip=192.168.1.11::192.168.1.254:255.255.255.0:template:ens192:none nameserver=192.168.1.254 inst.ks=http://{{ user `HTTP_IP` }}/{{ user `HTTP_PATH` }}" ], @@ -334,20 +331,20 @@ This is the most amusing part of the procedure: I'm sure you will go and admire After the first reboot, Packer will connect to your server by SSH. You can use the root user, or another user with sudo rights, but in any case, this user must correspond to the user that is defined in your ks.cfg file. -``` +```json "ssh_password": "mysecurepassword", "ssh_username": "root", ``` At the end of the process, the VM must be stopped. It is a little bit more complicated with a non-root user, but it is well documented: -``` +```json "shutdown_command": "/sbin/halt -h -p", ``` Next, we deal with the vSphere configuration. The only notable things here are the use of the variables defined at the beginning of the document in our home directory, as well as the `insecure_connection` option, because our vSphere uses a self-signed certificate (see note in Assumptions at the top of this document): -``` +```json "insecure_connection": "true", "username": "{{ user `vcenter_username` }}", "password": "{{ user `vcenter_password` }}", @@ -365,7 +362,7 @@ And finally, we will ask vSphere to convert our stopped VM to a template. At this stage, you could also elect to just use the VM as is (not converting it to a template). In this case, you can decide to take a snapshot instead: -``` +```json "convert_to_template": true, "create_snapshot": false, ``` @@ -376,7 +373,7 @@ As noted above, we need to provide a kickstart response file that will be used b Here's an example of that file: -``` +```bash # Use CD-ROM installation media repo --name="AppStream" --baseurl="http://download.rockylinux.org/pub/rocky/8.4/AppStream/x86_64/os/" cdrom @@ -487,7 +484,7 @@ As Packer relies on VMware Tools to detect the end of the installation, and the If you do not have access to the external repos, you can use either a mirror of the repo, a squid proxy, or the DVD. -``` +```bash # Use CD-ROM installation media repo --name="AppStream" --baseurl="http://download.rockylinux.org/pub/rocky/8.4/AppStream/x86_64/os/" cdrom @@ -495,14 +492,14 @@ cdrom Let us jump to the network configuration, as once again, in this example we are not using a DHCP server: -``` +```bash # Network information network --bootproto=static --device=ens192 --gateway=192.168.1.254 --ip=192.168.1.11 --nameserver=192.168.1.254,4.4.4.4 --netmask=255.255.255.0 --onboot=on --ipv6=auto --activate ``` Remember we specified the user to connect via SSH with to Packer at the end of the installation. This user and password must match: -``` +```bash # Root password rootpw mysecurepassword ``` @@ -513,7 +510,7 @@ rootpw mysecurepassword Here is the selected partition scheme. Much more complex things can be done. You can define a partition scheme that suits your needs, adapting it to the disk space defined in Packer, and which respects the security rules defined for your environment (dedicated partition for `/tmp`, etc.): -``` +```bash # System booloader configuration bootloader --location=mbr --boot-drive=sda # Partition clearing information @@ -538,7 +535,7 @@ The `openssh-clients` package seems to be required for Packer to copy its script The `open-vm-tools` is also needed by Packer to detect the end of the installation, this explains the addition of the AppStream repository. The packages `perl` and `perl-File-Temp` will also be required by VMware Tools during the deployment part. This is a shame because it requires a lot of other dependent packages. `python3` (3.6) will also be required in the future for Ansible to work (if you won't use Ansible or python, remove them!). -``` +```bash %packages --ignoremissing --excludedocs openssh-clients open-vm-tools @@ -556,7 +553,7 @@ wget You can not only add packages but also remove them. Since we control the environment in which our hardware will work, we can remove any of the firmware that will be useless to us: -``` +```bash # unnecessary firmware -aic94xx-firmware -atmel-firmware @@ -565,7 +562,7 @@ You can not only add packages but also remove them. Since we control the environ The next part adds some users. It is interesting in our case to create an `ansible` user, without password but with a public key. This allows all of our new VMs to be accessible from our Ansible server to run the post-install actions: -``` +```bash # Manage Ansible access groupadd -g 1001 ansible useradd -m -g 1001 -u 1001 ansible @@ -580,7 +577,7 @@ chmod 440 /etc/sudoers.d/ansible Now we need to enable and start `vmtoolsd` (the process that manages open-vm-tools). vSphere will detect the IP address after the reboot of the VM. -``` +```bash systemctl enable vmtoolsd systemctl start vmtoolsd ``` @@ -595,7 +592,7 @@ There are different types of provisioners, we could also have used Ansible. You This file can be completely changed, but this provides an example of what can be done with a script, in this case `requirements.sh`: -``` +```bash #!/bin/sh -eux echo "Updating the system..." @@ -643,12 +640,11 @@ truncate -s 0 /etc/machine-id echo "Clear the history so our install commands aren't there" rm -f /root/.wget-hsts export HISTSIZE=0 - ``` Some explanations are necessary: -``` +```bash echo "Installing cloud-init..." dnf -y install cloud-init @@ -678,7 +674,7 @@ Now it is time to launch Packer and check that the creation process, which is co Simply enter this at the command line: -``` +```bash ./packer build -var-file=~/.vsphere-secrets.json rockylinux8/template.json ``` @@ -696,7 +692,7 @@ For this, we will use a simple Ansible playbook, which uses the `vmware_guest` m This playbook that we provide you, must be adapted to your needs and your way of doing things. -``` +```ansible --- - name: Deploy VM from template hosts: localhost @@ -745,7 +741,7 @@ You can store sensitive data in the `./vars/credentials.yml`, which you will obv If you do not use something like Rundeck or Awx, you can launch the deployment with a command line similar to this one: -``` +```bash ansible-playbook -i ./inventory/hosts -e '{"comments":"my comments","cluster_name":"CS_NAME","esxi_hostname":"ESX_NAME","state":"started","storage_folder":"PROD","datacenter_name":"DC_NAME}","datastore_name":"DS_NAME","template_name":"template-rockylinux8-0.0.1","vm_name":"test_vm","network_name":"net_prod","network_ip":"192.168.1.20","network_gateway":"192.168.1.254","network_mask":"255.255.255.0","memory_mb":"4","num_cpu":"2","domain":"rockylinux.lan","dns_servers":"192.168.1.254","guest_id":"centos8_64Guest"}' ./vmware/create_vm.yml --vault-password-file /etc/ansible/vault_pass.py ``` @@ -759,4 +755,4 @@ At the same time, this represents an undeniable saving of time, especially in cl ## Other References -For a detailed project that also covers the deployment of Rocky Linux and other operating systems using the latest in vSphere, Packer, and the Packer Plugin for vSphere, please visit [this project](https://github.com/vmware-samples/packer-examples-for-vsphere). +For a detailed project that also covers the deployment of Rocky Linux and other operating systems using the latest in vSphere, Packer, and the Packer Plugin for vSphere, please visit [this project](https://github.com/vmware-samples/packer-examples-for-vsphere).