I am having production systems which are running on outdated rsyslog version 7.4.4, hence I need to update using latest v-8 version , as in http://www.rsyslog.com/ubuntu-repository/
Only 3 things need to be done
1. sudo add-apt-repository ppa:adiscon/v8-stable
{After This step, it asks to press [ENTER]
2. sudo apt-get update
3. sudo apt-get install rsyslog
so i wrote the following tasks in playbooks as:
- name: Updating rsyslog from 7.4.4 to v-8 stable| Adding PPA
apt_repository:
repo='ppa:adiscon/v8-stable'
state=present
update_cache=yes
- name: Running Updates
apt: update_cache=yes
- name: Install rsyslog (v-8)
apt: name=rsyslog
state=present
update_cache=yes
at the first task Ansible{Updating rsyslog from 7.4.4 to v-8 stable| Adding PPA} just sits/hangs there.. I am guessing because it expects {ENTER}
What should i do ?
I figured it out - my proxy server were not allowing this traffic!
#NishantSingh
Related
I am trying to install a deb package on a remote server using ansible, using the following construction
- name: Install deb
delegate_to: app1
apt:
deb: https://example.com/deb/package.deb
or
- name: Install deb
delegate_to: app1
apt:
deb: /path/to/deb
playbook works, says that everything is ok, but in fact the package is not installed, if you connect to a remote server and manually run apt install /path/to/deb, then the package is installed. I tried to copy deb to the server using ansible and install it by downloading the package from an Internet resource, the result is always the same
You have to use the privilege escalation methods become and become_method: sudo for Ansible. Installing a package need sudo privilege.
- name: Install deb
delegate_to: app1
apt:
deb: /path/to/deb
become: yes
The following modification of the task helped
- name: Install deb
command: apt install /path/to/package.deb -y --allow-downgrades
The allow_downgrade directive for the apt module appeared, starting with the ansible 2.12 version in my 2.9 it did not work, as the force directive did not work, I had to implement the task using a not very nice method.
Could anyone please support with equivalent tasks for clean and remove ?
yum clean expire-cache
yum -y remove packageX-S
yum -y install packageX-S
I got install already...
- name: deploy
yum:
name: llc-html-clients-S
state: latest
TL;DR;
Here are your equivalent tasks:
- name: clean
command: yum clean expire-cache
- name: remove
yum:
name: pkg-to-remove
state: absent
- name: install
yum:
name: pkg-to-install
state: present
Installing and removing is done with the same module yum.
When installing would test the installed or present state, removing is about testing removed or absent state.
Install:
- name: install
yum:
name: pkg-to-install
state: present
Take care: yum install and state: latest are not the same, when the yum command will install if the package is absent and do nothing if it is present already, state: latest will do an install if the package is absent but also a yum update pkg-to-install if the package is not at its latest version.
The real equivalent is state: present.
present and installed will simply ensure that a desired package is installed.
latest will update the specified package if it's not of the latest available version.
Source: https://docs.ansible.com/ansible/latest/modules/yum_module.html#parameter-state
Remove:
- name: remove
yum:
name: pkg-to-remove
state: absent
Then for the clean, sadly, there was a choice to not implement it, as this is not something that can be done in an idempotent way.
See this note on yum module page
The yum module does not support clearing yum cache in an idempotent way, so it was decided not to implement it, the only method is to use command and call the yum command directly, namely “command: yum clean all”
https://github.com/ansible/ansible/pull/31450#issuecomment-352889579
Source: https://docs.ansible.com/ansible/latest/modules/yum_module.html#notes
So as pointed in the note, you could actually go by a simple command.
- name: clean
command: yum clean expire-cache
So those are equivalent:
in bash
yum clean expire-cache
yum -y remove pkg-to-remove
yum -y install pkg-to-install
in playbook
- name: clean
command: yum clean expire-cache
- name: remove
yum:
name: pkg-to-remove
state: absent
- name: install
yum:
name: pkg-to-install
state: present
trying to add epel and then do a yum update via ansible on a amazon-linux-2 server. The URL im using based on : https://aws.amazon.com/premiumsupport/knowledge-center/ec2-enable-epel/
My ansible script is:
---
- hosts: all
remote_user: cloud_user
tasks:
- name: 01 add epel
yum_repository:
name: epel
description: EPEL YUM repo
baseurl: https://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm
become: yes
- name: 02 yum update
yum: name=* state=latest
become: yes
and my error is on task 02 is (task 01 has a "changed" notice):
FAILED! => {"changed": false, "msg": "https://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm/repodata/repomd.xml:
[Errno 14] HTTPS Error 404 - Not Found\nTrying other mirror.\n\n\n One of the configured repositories failed (EPEL YUM repo),\n and yum doesn't have enough cached data to continue. At this point the only\n safe thing yum can do is fail. There are a few ways to work \"fix\" this:\n\n
1. Contact the upstream for the repository and get them to fix the problem.\n\n
2. Reconfigure the baseurl/etc. for the repository, to point to a working\n upstream. This is most often useful if you are using a newer\n distribution release than is supported by the repository (and the\n packages for the previous distribution release still work).\n\n
3. Run the command with the repository temporarily disabled\n yum --disablerepo=epel ...\n\n
4. Disable the repository permanently, so yum won't use it by default. Yum\n
will then just ignore the repository until you permanently enable it\n again or use --enablerepo for temporary usage:\n\n
yum-config-manager --disable epel\n
or\n
subscription-manager repos --disable=epel\n\n
5. Configure the failing repository to be skipped, if it is unavailable.\n Note that yum will try to contact the repo. when it runs most commands,\n
so will have to try and fail each time (and thus. yum will be be much\n
slower). If it is a very temporary problem though, this is often a nice\n
compromise:\n\n yum-config-manager --save --setopt=epel.skip_if_unavailable=true\n\nfailure: repodata/repomd.xml from epel:
[Errno 256] No more mirrors to try.\nhttps://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm/repodata/repomd.xml:
[Errno 14] HTTPS Error 404 - Not Found\n", "rc": 1, "results": []}
Any guidance,or help would be great.
https://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm is not a yum repository, it is a yum package.
As you can see it in the documentation you are linking, they do a yum install of it:
sudo yum install -y https://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm
Then they enable it via the command yum-config-manager
sudo yum-config-manager --enable epel
On the other hand, https://dl.fedoraproject.org/pub/epel/$releasever/$basearch/ is a yum repository URL.
So your first task should be
- name: 01 add epel
yum_repository:
name: epel
description: EPEL YUM repo
baseurl: https://dl.fedoraproject.org/pub/epel/$releasever/$basearch/
become: yes
Your error actually shows it:
https://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm/repodata/repomd.xml
See how it is trying to fetch a folder repodata and a file repomd.xml?
Now if you browse https://dl.fedoraproject.org/pub/epel/ and you look under the folder 7 for example, and then under any subfolder, you will find that exact repodata folder and that exact repomd.xml file.
Note: extra info on the variables $releasever and $basearch can be found: following this link
Also since your knowledge article instruct you to use the version 7 (see the 7 in epel-release-latest-7.noarch.rpm), what you can do is to pass it as an attribute to your yum task.
- name: 02 yum update
yum:
name: '*'
state: latest
releasever: 7
become: yes
Note: I also changed your syntax, I would say it is a bad idea to mix the attribute=value and the YAML syntax in the same playbook.
To have EPEL installed it is enough to just install the epel-release package from the base repo. Also, considering it is recommended not to use shell or command modules wherever possible, we may enable the repo through a direct update of its config file. So I would suggest the following:
- name: Install EPEL repository
yum:
name: epel-release
state: present
- name: Ensure EPEL repo is enabled
ini_file:
dest: /etc/yum.repos.d/epel.repo
section: epel
option: enabled
value: '1'
- name: Conduct yum update
yum:
name: *
state: latest
become: True
update_cache: True
Thanks for all the input. Not sure if its a amazon-linux-2 thing but the only one i got working was to use a galaxy role, code is below:
roles:
- role: geerlingguy.repo-epel
vars:
epel_repo_url: "https://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm"
epel_repo_gpg_key_url: "/etc/pki/rpm-gpg/RPM-GPG-KEY-EPEL-7"
become: yes
I'm trying to use Ansible to run the following two commands:
sudo apt-get update && sudo apt-get upgrade -y
I know with ansible you can use:
ansible all -m shell -u user -K -a "uptime"
Would running the following command do it? Or do I have to use some sort of raw command
ansible all -m shell -u user -K -a "sudo apt-get update && sudo apt-get upgrade -y"
I wouldn't recommend using shell for this, as Ansible has the apt module designed for just this purpose. I've detailed using apt below.
In a playbook, you can update and upgrade like so:
- name: Update and upgrade apt packages
become: true
apt:
upgrade: yes
update_cache: yes
cache_valid_time: 86400 #One day
The cache_valid_time value can be omitted. Its purpose from the docs:
Update the apt cache if its older than the cache_valid_time. This
option is set in seconds.
So it's good to include if you don't want to update the cache when it has only recently been updated.
To do this as an ad-hoc command you can run:
$ ansible all -m apt -a "upgrade=yes update_cache=yes cache_valid_time=86400" --become
ad-hoc commands are described in detail here
Note that I am using --become and become: true. This is an example of typical privilege escalation through Ansible. You use -u user and -K (ask for privilege escalation password). Use whichever works for you, this is just to show you the most common form.
Just to add a flavour on the answer. This one is an executable playbook in all the hosts specified in your inventory file.
- hosts: all
become: true
tasks:
- name: Update and upgrade apt packages
apt:
upgrade: yes
update_cache: yes
cache_valid_time: 86400
Using Ubuntu 16.04, I did a little adjustement:
- name: Update and upgrade apt packages
become: true
apt:
update_cache: yes
upgrade: 'yes'
I juste put the upgrade yes between apostrophe to avoid un annoying warning:
[WARNING]: The value True (type bool) in a string field was converted to u'True' (type string). If this does
not look like what you expect, quote the entire value to ensure it does not change.
At 2020, I would like just to comment into the original answer, but no enough reputation at that time...
Ref:
The value True (type bool) in a string field was converted to u'True' (type string)
We use the following command to update and upgrade all packages :
ansible all -m apt -a "name='*' state=latest update_cache=yes upgrade=yes" -b --become-user root
When setting up a new Linux server, I typically run apt-get update and then apt-get upgrade. The first command updates the list of available packages and their versions, but it does not install or upgrade any packages. The second command actually installs newer versions of the packages I have.
What is the correct way to do this in Ansible? One way you could do it is like this:
- name: update and upgrade apt packages
apt: >
upgrade=yes
update_cache=yes
cache_valid_time=3600
Or you could do it in two separate steps:
- name: update apt packages
apt: >
update_cache=yes
cache_valid_time=3600
- name: upgrade apt packages
apt: upgrade=yes
If you do it the first way, is Ansible smart enough to know that it should run 'update' before 'upgrade'? The Ansible apt documentation doesn't address this finer point.
The apt module documentation does actually state that it will run the update first:
Run the equivalent of apt-get update before the operation. Can be run
as part of the package installation or as a separate step.
(emphasis mine)
So both of those plays should be functionally the same.
Here is the better version of upgrading and updating packages. The below executable playbook will update and upgrade packages to all hosts specified in the inventory file.
- hosts: all
become: yes
tasks:
- name: Update and upgrade apt packages
apt:
upgrade: yes
update_cache: yes
cache_valid_time: 86400 # 1 day
The cache_valid_time value is optional. The docs says:
Update the apt cache if its older than the cache_valid_time. This option is set in seconds.
I think its good practice to include this if you don't want to update the cache when it has only recently been updated.