File provisioner in Packer for Windows Server - windows

Issue with File Provisioner for Windows Azure VM
We tried implementing the Packer template referring the Microsoft Docs-
https://learn.microsoft.com/en-us/azure/virtual-machines/windows/build-image-with-packer#create-azure-resource-group
Also, we replaced the script with the provisioner block
Below is the JSON script used to deploy the File Provisioner
{
builders: [{
type: "azure-arm",
"client_id": "",
"client_secret": "",
"tenant_id": "",
"subscription_id": "",
"managed_image_resource_group_name": "Packer-RG",
"managed_image_name": "myPackerImage",
"os_type": "Windows",
"image_publisher": "MicrosoftWindowsServer",
"image_offer": "WindowsServer",
"image_sku": "2016-Datacenter",
"communicator": "winrm",
"winrm_use_ssl": true,
"winrm_insecure": true,
"winrm_timeout": "5m",
"winrm_username": "packer",
"azure_tags": {
dept: "Engineering",
"task": "Image deployment"
},
"location": "East US",
"vm_size": "Standard_DS2_v2"
}],
"provisioners": [{
"type": "file",
"source": "C:/Test-1",
"destination": "C:/Test-1"
}]
}
After implementing the steps, the builds were finished but no artifacts were created.

Related

Guest can't submit answer Adaptative Card on Microsoft Teams

I'm having an error with a custom bot when I send an adaptative card to a meeting and a guest tries to submit an answer. It works when a logged user tries to submit it. It used to work perfectly with a Guest. It seems like the problem is something about the bot login process.
Uncaught TypeError: Cannot read property '*BotId*' of undefined
at t.recordBotMriUsage (3.2-app.min-2477809.js:4)
at _.debounce.trailing (3.2-app.min-2477809.js:3)
at e (2-vendor.min-9ae85bb.js:64)
at f (2-vendor.min-9ae85bb.js:65)
at t.e.buttonClicked (3.2-app.min-2477809.js:3)
at o (lazy-ng1-mod-adaptive-card-components.min-1b02b78.js:1)
at c (lazy-ng1-mod-adaptive-card-components.min-1b02b78.js:1)
at t.handleOnExecuteAction (lazy-ng1-mod-adaptive-card-components.min-1b02b78.js:1)
at adaptiveCard.onExecuteAction (lazy-ng1-mod-adaptive-card-components.min-1b02b78.js:1)
at p (3.2-app.min-2477809.js:3)
Failed to get app entitlement for botId 28:*BotId*
500 Invoke failed due to internal error: Invoke failed: something went wrong in ProcessInvoke
[BotCardService::onButtonClicked_messageback()] sendInvoke failed: {"statusCode":500,"headers":{"cache-control":"no-store, must-revalidate, no-cache","content-length":"119","content-type":"application/json; charset=utf-8","contextid":"tcid=******,server=*****,cv=*******/hfA.1.0","pragma":"no-cache","set-registrationtoken":"**redacted**"},"errorMessage":"Error Code: 500 ","errorCode":500,"request":{}}
error log
EDIT: Here is the manifest.json of the app
{
"$schema": "https://developer.microsoft.com/en-us/json-schemas/teams/v1.7/MicrosoftTeams.schema.json",
"manifestVersion": "1.7",
"version": "1.0.0",
"id": "redacted",
"packageName": "redacted",
"developer": {
"name": "redacted",
"websiteUrl": "redacted",
"privacyUrl": "redacted",
"termsOfUseUrl": "redacted"
},
"icons": {
"color": "color.png",
"outline": "outline.png"
},
"name": {
"short": "redacted",
"full": "redacted"
},
"description": {
"short": "redacted",
"full": "redacted"
},
"accentColor": "#FFFFFF",
"bots": [
{
"botId": "redacted",
"scopes": ["personal", "groupchat"],
"supportsFiles": false,
"isNotificationOnly": false
}
],
"composeExtensions": [
{
"botId": "redacted",
"canUpdateConfiguration": true,
"commands": [
{
"id": "getPollCM",
"type": "action",
"title": "Generar encuesta prestador",
"description": "Genera una encuesta para prestadores",
"initialRun": true,
"fetchTask": false,
"context": ["commandBox", "compose"],
"parameters": [
{
"name": "NIT",
"title": "NIT del prestador",
"description": "Solo números",
"inputType": "text"
}
]
}
]
}
],
"permissions": ["identity", "messageTeamMembers"],
"validDomains": ["redacted"]
}

How can new docker image have dependent child images

I am new to Docker and want to understand image management better. A new image that I just created using
docker image build -t jefe/mh_db:v.1.1.0 ./
When I try to delete using
docker image rm d4c0c9225252
where d4c0c9225252 is the Image ID, returns
Error response from daemon: conflict: unable to delete d4c0c9225252 (cannot be forced) - image has dependent child images
Yes it's related to other posts regarding cannot delete. But I want to understand why a dependency exists.
How can this child image have images that are dependent upon it? I literally just created it
The dockerfile that is used in building the image
FROM mysql:5.7.27
MAINTAINER jefe
# Specify ports
EXPOSE 3306
Update
docker image ls | grep d4c0c9225252
jefe/mh_db v.1.1.0 d4c0c9225252 2 hours ago 373MB
Additionally
docker inspect d4c0c9225252
[
{
"Id": "sha256:d4c0c922525201d62e49ac73d03e27653e77e2ac5e3f11334a7a09d7c6d977fe",
"RepoTags": [
"jefe/mh_db:v.1.1.0"
],
"RepoDigests": [],
"Parent": "sha256:b0fead29523e498fd0f990abcc2b2bbb46952ad3361fbebcc304e31be69bd840",
"Comment": "",
"Created": "2019-08-08T15:24:57.324861036Z",
"Container": "6abc71375823faeb4819720a09ae348b0da4d9ae213c167c3911ca706d7c8b92",
"ContainerConfig": {
"Hostname": "6abc71375823",
"Domainname": "",
"User": "",
"AttachStdin": false,
"AttachStdout": false,
"AttachStderr": false,
"ExposedPorts": {
"3306/tcp": {},
"33060/tcp": {}
},
"Tty": false,
"OpenStdin": false,
"StdinOnce": false,
"Env": [
"PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin",
"GOSU_VERSION=1.7",
"MYSQL_MAJOR=5.7",
"MYSQL_VERSION=5.7.27-1debian9"
],
"Cmd": [
"/bin/sh",
"-c",
"#(nop) ",
"EXPOSE 3306"
],
"ArgsEscaped": true,
"Image": "sha256:b0fead29523e498fd0f990abcc2b2bbb46952ad3361fbebcc304e31be69bd840",
"Volumes": {
"/var/lib/mysql": {}
},
"WorkingDir": "",
"Entrypoint": [
"docker-entrypoint.sh"
],
"OnBuild": null,
"Labels": {}
},
"DockerVersion": "19.03.1",
"Author": "jefe",
"Config": {
"Hostname": "",
"Domainname": "",
"User": "",
"AttachStdin": false,
"AttachStdout": false,
"AttachStderr": false,
"ExposedPorts": {
"3306/tcp": {},
"33060/tcp": {}
},
"Tty": false,
"OpenStdin": false,
"StdinOnce": false,
"Env": [
"PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin",
"GOSU_VERSION=1.7",
"MYSQL_MAJOR=5.7",
"MYSQL_VERSION=5.7.27-1debian9"
],
"Cmd": [
"mysqld"
],
"ArgsEscaped": true,
"Image": "sha256:b0fead29523e498fd0f990abcc2b2bbb46952ad3361fbebcc304e31be69bd840",
"Volumes": {
"/var/lib/mysql": {}
},
"WorkingDir": "",
"Entrypoint": [
"docker-entrypoint.sh"
],
"OnBuild": null,
"Labels": null
},
"Architecture": "amd64",
"Os": "linux",
"Size": 373273403,
"VirtualSize": 373273403,
"GraphDriver": {
"Data": {
"LowerDir": "/var/lib/docker/overlay2/11891a42dc63fb6851e3fb12a1dd7e7285d18df83ecfd1f5aa40e44466921c58/diff:/var/lib/docker/overlay2/e0c695335789cba5a8e6524804bd1c2d1836db16650105e6863e7023bc289753/diff:/var/lib/docker/overlay2/2b4e10627f78a0185f8975b62b954a14e79fc6fb71a3caae07180e8e00f51b44/diff:/var/lib/docker/overlay2/f9dd057675e39a3eab99143f07bcb7df8a44eba5d1f1d15e567471a7c3a9e491/diff:/var/lib/docker/overlay2/c28612d7a8d1b187ddb7fc995c5fe733e0c18def13df798f1de5af2bdac9d3f4/diff:/var/lib/docker/overlay2/f8e41886d7ae8d8939ae2dc11b4ff941ef931aa18bc2f8cb0f724cc9e270ab3c/diff:/var/lib/docker/overlay2/8796390ee625b42b56d7822d128cc50bf88fbfd1f7f5ac9e7ecda9e721944946/diff:/var/lib/docker/overlay2/86552fa54367c794979383dbba257f1292f2a137dae0304d1eb036ba2249bc7b/diff:/var/lib/docker/overlay2/168353bdf70d8140026c2cf58da64eee7409f710832be601dad3e0cc6a02c01a/diff:/var/lib/docker/overlay2/ac908915344e5f65df6e0121f77bd48fdaa822974317cdb83a59f0618893ddb2/diff",
"MergedDir": "/var/lib/docker/overlay2/1826972009d9ce18265129a2d4928b708bf6780370530e4c1be8b1efd096b2cd/merged",
"UpperDir": "/var/lib/docker/overlay2/1826972009d9ce18265129a2d4928b708bf6780370530e4c1be8b1efd096b2cd/diff",
"WorkDir": "/var/lib/docker/overlay2/1826972009d9ce18265129a2d4928b708bf6780370530e4c1be8b1efd096b2cd/work"
},
"Name": "overlay2"
},
"RootFS": {
"Type": "layers",
"Layers": [
"sha256:d56055da3352f918f4d8a42350385ea5b10d0906e746a8fbb4b850f9284deee5",
"sha256:b78ec9586b345b0efdb0297261c0044652563045a28a7cc6d27dd314eda1e0eb",
"sha256:c6926fcee1912ebb41215a70b1d0ed77e3b8db38cfe69b936d18b346096e144c",
"sha256:007a7f930352c0fd98663021fb1ee08768462eb5bc9045342da9e9f73fd79a7f",
"sha256:2f1b41b24201f4ae635819b1d7717ab04c000f04e7708de3bb012a60d3ef630b",
"sha256:77737de99484a6e2e2ae4bea0cf7ec4d3063827a6dd49a243694ef00929350d2",
"sha256:7e7fffcdabb3e0655bf46756dd04018ce051f81fbaba8bff3703ac987def88be",
"sha256:83bba64580292cc5af1fd3cabb74b18c143e05cd45d882c9e09edc8ff79a1119",
"sha256:94f63a189eef2bdb32668faa0ce08dc5da01eccb91ad548f28052048e810e5f8",
"sha256:0c3e10ddbe75e0a4efcee6aa06716b651227ceb358e78922b9fe9ea7f5a63992",
"sha256:5572431ce4dea5defe6a0d0586ad3b25a74d59bfbbb05c2a257c5d71a27eba4c"
]
},
"Metadata": {
"LastTagTime": "2019-08-08T15:24:57.393863976Z"
}
}
Docker wont let you delete an image if you have more than one tag on it. To find out the tags you can filter the output of docker image ls
docker image ls | grep d4c0c9225252

Download .mp4 from Google Photo using Google Drive API will get wrong md5Checksum

When we try to download a file with an extension of .mp4 from Google Photo using Google Drive API, the downloaded file always has different md5 hash value with the md5Checksum field provided by remote metadata.
For example, assume there exists a file name video.mp4 on Google Photo. After we download the file using either one of the following URL:
(v2) https://doc-14-6c-docs.googleusercontent.com/docs/securesc/[SOME_VALUES]?h=[SOME_VALUES]&e=download&gd=true
(v3) https://www.googleapis.com/drive/v3/files/[FILEID]?alt=media
Both methods will download the file correctly on a local machine. The file size is also the same as the fileSize field of remote metadata.
However, the md5 hash value is inconsistent with the md5Checksum field of remote metadata. For example, if we enter $md5sum video.mp4 command, we may got 5cf9fb1bb88dc9bf38d1de5c9180dc4e video.mp4. This is not the hash recorded at remote metadata.
All other files work fine (size and hash are consistent), except for the files with an extension of .mp4. By the way, we use CURL to send a request to Google Drive API to download these files, instead of using any of Google Drive SDK.
Hope someone can help us, thanks!
[Update] more explanation
These files are from our customer's Google Photo. We don't know the exact way to reproduce such situaion. We provide the metadata of one of problematic file for your reference. (we remove some private information.)
{
"kind": "drive#file",
"id": "(REMOVED)",
"etag": "(REMOVED)",
"selfLink": "(REMOVED)",
"webContentLink": "(REMOVED)",
"alternateLink": "(REMOVED)",
"embedLink": "(REMOVED)",
"iconLink": "(REMOVED)",
"thumbnailLink": "(REMOVED)",
"title": "(REMOVED)",
"mimeType": "video/mp4",
"description": "",
"labels": {
"starred": false,
"hidden": false,
"trashed": false,
"restricted": false,
"viewed": false
},
"createdDate": "2016-10-10T11:42:25.000Z",
"modifiedDate": "2016-10-18T23:01:19.000Z",
"modifiedByMeDate": "2016-10-18T23:01:19.000Z",
"markedViewedByMeDate": "1970-01-01T00:00:00.000Z",
"version": "133589",
"parents": [
{
"kind": "drive#parentReference",
"id": "(REMOVED)",
"selfLink": "(REMOVED)",
"parentLink": "(REMOVED)",
"isRoot": false
}
],
"downloadUrl": "(REMOVED)",
"userPermission": {
"kind": "drive#permission",
"etag": "(REMOVED)",
"id": "me",
"selfLink": "(REMOVED)",
"role": "owner",
"type": "user"
},
"originalFilename": "(REMOVED)",
"fileExtension": "mp4",
"md5Checksum": "c5a208198614c34b6fc61186d025df77",
"fileSize": "15284923",
"quotaBytesUsed": "0",
"ownerNames": [
"(REMOVED)"
],
"owners": [
{
"kind": "drive#user",
"displayName": "(REMOVED)",
"picture": {
"url": "(REMOVED)"
},
"isAuthenticatedUser": true,
"permissionId": "(REMOVED)",
"emailAddress": "(REMOVED)"
}
],
"lastModifyingUserName": "(REMOVED)",
"lastModifyingUser": {
"kind": "drive#user",
"displayName": "(REMOVED)",
"picture": {
"url": "(REMOVED)"
},
"isAuthenticatedUser": true,
"permissionId": "(REMOVED)",
"emailAddress": "(REMOVED)"
},
"capabilities": {
"canCopy": true,
"canEdit": true
},
"editable": true,
"copyable": true,
"writersCanShare": true,
"shared": false,
"explicitlyTrashed": false,
"appDataContents": false,
"headRevisionId": "(REMOVED)",
"videoMediaMetadata": {
"width": 720,
"height": 1280,
"durationMillis": "43697"
},
"spaces": [
"photos",
"drive"
]}
As you can see, the md5Checksum field shows c5a208198614c34b6fc61186d025df77 in the metadata. However, the actual md5 hash value equals to 95be52d721e2f5d8d02650b27095d466 instead.

Docker Windows bridge ip conflict

I have used Docker on a Linux machine and just started using it on Windows too.
I am on a unfortunate location where they use 172.17.0.0/16 subnet that conflicts with default Docker bridge subnet.
C:\>docker network inspect bridge
[
{
"Name": "bridge",
"Id": "d6ae8949e4e098ad4443ba2cd72bed5f9f96d81f5d2d00197b9443b8a8c1d1f6"
,
"Scope": "local",
"Driver": "bridge",
"EnableIPv6": false,
"IPAM": {
"Driver": "default",
"Options": null,
"Config": [
{
"Subnet": "172.17.0.0/16"
}
]
},
"Internal": false,
"Containers": {},
"Options": {
"com.docker.network.bridge.default_bridge": "true",
"com.docker.network.bridge.enable_icc": "true",
"com.docker.network.bridge.enable_ip_masquerade": "true",
"com.docker.network.bridge.host_binding_ipv4": "0.0.0.0",
"com.docker.network.bridge.name": "docker0",
"com.docker.network.driver.mtu": "1500"
},
"Labels": {}
}
]
I know there is an option for Linux (https://docs.docker.com/engine/reference/commandline/dockerd/ bip) to change this. But is there also an option for Windows?
PS. I have tried adding "bip": "10.11.12.0/24" to JSON Daemon configuration but Docker crashes on startup:

Where can I get a list of Ansible pre-defined variables?

I see that Ansible provide some pre-defined variables that we can use in playbooks and template files. For example, the host IP address is ansible_eth0.ipv4.address. Googleing and searching the docs I couldn't find a list of all available variables.
Would someone list them for me?
From the FAQ:
How do I see a list of all of the ansible_ variables?
Ansible by default gathers “facts” about the machines under management, and these facts can be accessed in playbooks and in templates. To see a list of all of the facts that are available about a machine, you can run the setup module as an ad hoc action:
ansible -m setup hostname
This will print out a dictionary of all of the facts that are available for that particular host. You might want to pipe the output to a pager.This does NOT include inventory variables or internal ‘magic’ variables. See the next question if you need more than just ‘facts’.
Here is the output for my vagrant virtual machine called scdev:
scdev | success >> {
"ansible_facts": {
"ansible_all_ipv4_addresses": [
"10.0.2.15",
"192.168.10.10"
],
"ansible_all_ipv6_addresses": [
"fe80::a00:27ff:fe12:9698",
"fe80::a00:27ff:fe74:1330"
],
"ansible_architecture": "i386",
"ansible_bios_date": "12/01/2006",
"ansible_bios_version": "VirtualBox",
"ansible_cmdline": {
"BOOT_IMAGE": "/vmlinuz-3.2.0-23-generic-pae",
"quiet": true,
"ro": true,
"root": "/dev/mapper/precise32-root"
},
"ansible_date_time": {
"date": "2013-09-17",
"day": "17",
"epoch": "1379378304",
"hour": "00",
"iso8601": "2013-09-17T00:38:24Z",
"iso8601_micro": "2013-09-17T00:38:24.425092Z",
"minute": "38",
"month": "09",
"second": "24",
"time": "00:38:24",
"tz": "UTC",
"year": "2013"
},
"ansible_default_ipv4": {
"address": "10.0.2.15",
"alias": "eth0",
"gateway": "10.0.2.2",
"interface": "eth0",
"macaddress": "08:00:27:12:96:98",
"mtu": 1500,
"netmask": "255.255.255.0",
"network": "10.0.2.0",
"type": "ether"
},
"ansible_default_ipv6": {},
"ansible_devices": {
"sda": {
"holders": [],
"host": "SATA controller: Intel Corporation 82801HM/HEM (ICH8M/ICH8M-E) SATA Controller [AHCI mode] (rev 02)",
"model": "VBOX HARDDISK",
"partitions": {
"sda1": {
"sectors": "497664",
"sectorsize": 512,
"size": "243.00 MB",
"start": "2048"
},
"sda2": {
"sectors": "2",
"sectorsize": 512,
"size": "1.00 KB",
"start": "501758"
},
},
"removable": "0",
"rotational": "1",
"scheduler_mode": "cfq",
"sectors": "167772160",
"sectorsize": "512",
"size": "80.00 GB",
"support_discard": "0",
"vendor": "ATA"
},
"sr0": {
"holders": [],
"host": "IDE interface: Intel Corporation 82371AB/EB/MB PIIX4 IDE (rev 01)",
"model": "CD-ROM",
"partitions": {},
"removable": "1",
"rotational": "1",
"scheduler_mode": "cfq",
"sectors": "2097151",
"sectorsize": "512",
"size": "1024.00 MB",
"support_discard": "0",
"vendor": "VBOX"
},
"sr1": {
"holders": [],
"host": "IDE interface: Intel Corporation 82371AB/EB/MB PIIX4 IDE (rev 01)",
"model": "CD-ROM",
"partitions": {},
"removable": "1",
"rotational": "1",
"scheduler_mode": "cfq",
"sectors": "2097151",
"sectorsize": "512",
"size": "1024.00 MB",
"support_discard": "0",
"vendor": "VBOX"
}
},
"ansible_distribution": "Ubuntu",
"ansible_distribution_release": "precise",
"ansible_distribution_version": "12.04",
"ansible_domain": "",
"ansible_eth0": {
"active": true,
"device": "eth0",
"ipv4": {
"address": "10.0.2.15",
"netmask": "255.255.255.0",
"network": "10.0.2.0"
},
"ipv6": [
{
"address": "fe80::a00:27ff:fe12:9698",
"prefix": "64",
"scope": "link"
}
],
"macaddress": "08:00:27:12:96:98",
"module": "e1000",
"mtu": 1500,
"type": "ether"
},
"ansible_eth1": {
"active": true,
"device": "eth1",
"ipv4": {
"address": "192.168.10.10",
"netmask": "255.255.255.0",
"network": "192.168.10.0"
},
"ipv6": [
{
"address": "fe80::a00:27ff:fe74:1330",
"prefix": "64",
"scope": "link"
}
],
"macaddress": "08:00:27:74:13:30",
"module": "e1000",
"mtu": 1500,
"type": "ether"
},
"ansible_form_factor": "Other",
"ansible_fqdn": "scdev",
"ansible_hostname": "scdev",
"ansible_interfaces": [
"lo",
"eth1",
"eth0"
],
"ansible_kernel": "3.2.0-23-generic-pae",
"ansible_lo": {
"active": true,
"device": "lo",
"ipv4": {
"address": "127.0.0.1",
"netmask": "255.0.0.0",
"network": "127.0.0.0"
},
"ipv6": [
{
"address": "::1",
"prefix": "128",
"scope": "host"
}
],
"mtu": 16436,
"type": "loopback"
},
"ansible_lsb": {
"codename": "precise",
"description": "Ubuntu 12.04 LTS",
"id": "Ubuntu",
"major_release": "12",
"release": "12.04"
},
"ansible_machine": "i686",
"ansible_memfree_mb": 23,
"ansible_memtotal_mb": 369,
"ansible_mounts": [
{
"device": "/dev/mapper/precise32-root",
"fstype": "ext4",
"mount": "/",
"options": "rw,errors=remount-ro",
"size_available": 77685088256,
"size_total": 84696281088
},
{
"device": "/dev/sda1",
"fstype": "ext2",
"mount": "/boot",
"options": "rw",
"size_available": 201044992,
"size_total": 238787584
},
{
"device": "/vagrant",
"fstype": "vboxsf",
"mount": "/vagrant",
"options": "uid=1000,gid=1000,rw",
"size_available": 42013151232,
"size_total": 484145360896
}
],
"ansible_os_family": "Debian",
"ansible_pkg_mgr": "apt",
"ansible_processor": [
"Pentium(R) Dual-Core CPU E5300 # 2.60GHz"
],
"ansible_processor_cores": "NA",
"ansible_processor_count": 1,
"ansible_product_name": "VirtualBox",
"ansible_product_serial": "NA",
"ansible_product_uuid": "NA",
"ansible_product_version": "1.2",
"ansible_python_version": "2.7.3",
"ansible_selinux": false,
"ansible_swapfree_mb": 766,
"ansible_swaptotal_mb": 767,
"ansible_system": "Linux",
"ansible_system_vendor": "innotek GmbH",
"ansible_user_id": "neves",
"ansible_userspace_architecture": "i386",
"ansible_userspace_bits": "32",
"ansible_virtualization_role": "guest",
"ansible_virtualization_type": "virtualbox"
},
"changed": false
}
The current documentation now has a complete chapter about Discovering variables: facts and magic variables.
ansible -m setup hostname
Only gets the facts gathered by the setup module.
Gilles Cornu posted a template trick to list all variables for a specific host.
Template (later called dump_variables):
HOSTVARS (ANSIBLE GATHERED, group_vars, host_vars) :
{{ hostvars[inventory_hostname] | to_yaml }}
PLAYBOOK VARS:
{{ vars | to_yaml }}
Playbook to use it:
- hosts: all
tasks:
- template:
src: templates/dump_variables
dest: /tmp/ansible_variables
- fetch:
src: /tmp/ansible_variables
dest: "{{inventory_hostname}}_ansible_variables"
After that you have a dump of all variables on every host, and a copy of each text dump file on your local workstation in your tmp folder. If you don't want local copies, you can remove the fetch statement.
This includes gathered facts, host variables and group variables.
Therefore you see ansible default variables like group_names, inventory_hostname, ansible_ssh_host and so on.
There are 3 sources of variables in Ansible:
Variables gathered from facts. You can get them by running command: ansible -m setup hostname
Built-in (pre-defined) Ansible variables (AKA 'magic' variables). They are documented in Ansible documentation: http://docs.ansible.com/playbooks_variables.html#magic-variables-and-how-to-access-information-about-other-hosts
Here is the list extracted from Ansible 1.9 documentation:
group_names
groups
inventory_hostname
ansible_hostname
inventory_hostname_short
play_hosts
delegate_to
inventory_dir
inventory_file
Variables passed to ansible via command line. But obviously you know what they are
I use this simple playbook:
---
# vars.yml
#
# Shows the value of all variables/facts.
#
# Example:
#
# ansible-playbook vars.yml -e 'hosts=localhost'
#
- hosts: localhost
tasks:
- fail: "You must specify a value for `hosts` variable - e.g.: ansible-playbook vars.yml -e 'hosts=localhost'"
when: hosts is not defined
- hosts: "{{ hosts }}"
tasks:
- debug: var=vars
- debug: var=hostvars[inventory_hostname]
There is lot of variables defined as Facts -- http://docs.ansible.com/ansible/playbooks_variables.html#information-discovered-from-systems-facts
"ansible_all_ipv4_addresses": [
"REDACTED IP ADDRESS"
],
"ansible_all_ipv6_addresses": [
"REDACTED IPV6 ADDRESS"
],
"ansible_architecture": "x86_64",
"ansible_bios_date": "09/20/2012",
"ansible_bios_version": "6.00",
"ansible_cmdline": {
"BOOT_IMAGE": "/boot/vmlinuz-3.5.0-23-generic",
"quiet": true,
"ro": true,
"root": "UUID=4195bff4-e157-4e41-8701-e93f0aec9e22",
"splash": true
},
"ansible_date_time": {
"date": "2013-10-02",
"day": "02",
"epoch": "1380756810",
"hour": "19",
"iso8601": "2013-10-02T23:33:30Z",
"iso8601_micro": "2013-10-02T23:33:30.036070Z",
"minute": "33",
"month": "10",
"second": "30",
"time": "19:33:30",
"tz": "EDT",
"year": "2013"
},
"ansible_default_ipv4": {
"address": "REDACTED",
"alias": "eth0",
"gateway": "REDACTED",
"interface": "eth0",
"macaddress": "REDACTED",
"mtu": 1500,
"netmask": "255.255.255.0",
"network": "REDACTED",
"type": "ether"
},
"ansible_default_ipv6": {},
"ansible_devices": {
"fd0": {
"holders": [],
"host": "",
"model": null,
"partitions": {},
"removable": "1",
"rotational": "1",
"scheduler_mode": "deadline",
"sectors": "0",
"sectorsize": "512",
"size": "0.00 Bytes",
"support_discard": "0",
"vendor": null
},
"sda": {
"holders": [],
"host": "SCSI storage controller: LSI Logic / Symbios Logic 53c1030 PCI-X Fusion-MPT Dual Ultra320 SCSI (rev 01)",
"model": "VMware Virtual S",
"partitions": {
"sda1": {
"sectors": "39843840",
"sectorsize": 512,
"size": "19.00 GB",
"start": "2048"
},
"sda2": {
"sectors": "2",
"sectorsize": 512,
"size": "1.00 KB",
"start": "39847934"
},
"sda5": {
"sectors": "2093056",
"sectorsize": 512,
"size": "1022.00 MB",
"start": "39847936"
}
},
"removable": "0",
"rotational": "1",
"scheduler_mode": "deadline",
"sectors": "41943040",
"sectorsize": "512",
"size": "20.00 GB",
"support_discard": "0",
"vendor": "VMware,"
},
"sr0": {
"holders": [],
"host": "IDE interface: Intel Corporation 82371AB/EB/MB PIIX4 IDE (rev 01)",
"model": "VMware IDE CDR10",
"partitions": {},
"removable": "1",
"rotational": "1",
"scheduler_mode": "deadline",
"sectors": "2097151",
"sectorsize": "512",
"size": "1024.00 MB",
"support_discard": "0",
"vendor": "NECVMWar"
}
},
"ansible_distribution": "Ubuntu",
"ansible_distribution_release": "precise",
"ansible_distribution_version": "12.04",
"ansible_domain": "",
"ansible_env": {
"COLORTERM": "gnome-terminal",
"DISPLAY": ":0",
"HOME": "/home/mdehaan",
"LANG": "C",
"LESSCLOSE": "/usr/bin/lesspipe %s %s",
"LESSOPEN": "| /usr/bin/lesspipe %s",
"LOGNAME": "root",
"LS_COLORS": "rs=0:di=01;34:ln=01;36:mh=00:pi=40;33:so=01;35:do=01;35:bd=40;33;01:cd=40;33;01:or=40;31;01:su=37;41:sg=30;43:ca=30;41:tw=30;42:ow=34;42:st=37;44:ex=01;32:*.tar=01;31:*.tgz=01;31:*.arj=01;31:*.taz=01;31:*.lzh=01;31:*.lzma=01;31:*.tlz=01;31:*.txz=01;31:*.zip=01;31:*.z=01;31:*.Z=01;31:*.dz=01;31:*.gz=01;31:*.lz=01;31:*.xz=01;31:*.bz2=01;31:*.bz=01;31:*.tbz=01;31:*.tbz2=01;31:*.tz=01;31:*.deb=01;31:*.rpm=01;31:*.jar=01;31:*.war=01;31:*.ear=01;31:*.sar=01;31:*.rar=01;31:*.ace=01;31:*.zoo=01;31:*.cpio=01;31:*.7z=01;31:*.rz=01;31:*.jpg=01;35:*.jpeg=01;35:*.gif=01;35:*.bmp=01;35:*.pbm=01;35:*.pgm=01;35:*.ppm=01;35:*.tga=01;35:*.xbm=01;35:*.xpm=01;35:*.tif=01;35:*.tiff=01;35:*.png=01;35:*.svg=01;35:*.svgz=01;35:*.mng=01;35:*.pcx=01;35:*.mov=01;35:*.mpg=01;35:*.mpeg=01;35:*.m2v=01;35:*.mkv=01;35:*.webm=01;35:*.ogm=01;35:*.mp4=01;35:*.m4v=01;35:*.mp4v=01;35:*.vob=01;35:*.qt=01;35:*.nuv=01;35:*.wmv=01;35:*.asf=01;35:*.rm=01;35:*.rmvb=01;35:*.flc=01;35:*.avi=01;35:*.fli=01;35:*.flv=01;35:*.gl=01;35:*.dl=01;35:*.xcf=01;35:*.xwd=01;35:*.yuv=01;35:*.cgm=01;35:*.emf=01;35:*.axv=01;35:*.anx=01;35:*.ogv=01;35:*.ogx=01;35:*.aac=00;36:*.au=00;36:*.flac=00;36:*.mid=00;36:*.midi=00;36:*.mka=00;36:*.mp3=00;36:*.mpc=00;36:*.ogg=00;36:*.ra=00;36:*.wav=00;36:*.axa=00;36:*.oga=00;36:*.spx=00;36:*.xspf=00;36:",
"MAIL": "/var/mail/root",
"OLDPWD": "/root/ansible/docsite",
"PATH": "/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin",
"PWD": "/root/ansible",
"SHELL": "/bin/bash",
"SHLVL": "1",
"SUDO_COMMAND": "/bin/bash",
"SUDO_GID": "1000",
"SUDO_UID": "1000",
"SUDO_USER": "mdehaan",
"TERM": "xterm",
"USER": "root",
"USERNAME": "root",
"XAUTHORITY": "/home/mdehaan/.Xauthority",
"_": "/usr/local/bin/ansible"
},
"ansible_eth0": {
"active": true,
"device": "eth0",
"ipv4": {
"address": "REDACTED",
"netmask": "255.255.255.0",
"network": "REDACTED"
},
"ipv6": [
{
"address": "REDACTED",
"prefix": "64",
"scope": "link"
}
],
"macaddress": "REDACTED",
"module": "e1000",
"mtu": 1500,
"type": "ether"
},
"ansible_form_factor": "Other",
"ansible_fqdn": "ubuntu2.example.com",
"ansible_hostname": "ubuntu2",
"ansible_interfaces": [
"lo",
"eth0"
],
"ansible_kernel": "3.5.0-23-generic",
"ansible_lo": {
"active": true,
"device": "lo",
"ipv4": {
"address": "127.0.0.1",
"netmask": "255.0.0.0",
"network": "127.0.0.0"
},
"ipv6": [
{
"address": "::1",
"prefix": "128",
"scope": "host"
}
],
"mtu": 16436,
"type": "loopback"
},
"ansible_lsb": {
"codename": "precise",
"description": "Ubuntu 12.04.2 LTS",
"id": "Ubuntu",
"major_release": "12",
"release": "12.04"
},
"ansible_machine": "x86_64",
"ansible_memfree_mb": 74,
"ansible_memtotal_mb": 991,
"ansible_mounts": [
{
"device": "/dev/sda1",
"fstype": "ext4",
"mount": "/",
"options": "rw,errors=remount-ro",
"size_available": 15032406016,
"size_total": 20079898624
}
],
"ansible_nodename": "ubuntu2.example.com",
"ansible_os_family": "Debian",
"ansible_pkg_mgr": "apt",
"ansible_processor": [
"Intel(R) Core(TM) i7 CPU 860 # 2.80GHz"
],
"ansible_processor_cores": 1,
"ansible_processor_count": 1,
"ansible_processor_threads_per_core": 1,
"ansible_processor_vcpus": 1,
"ansible_product_name": "VMware Virtual Platform",
"ansible_product_serial": "REDACTED",
"ansible_product_uuid": "REDACTED",
"ansible_product_version": "None",
"ansible_python_version": "2.7.3",
"ansible_selinux": false,
"ansible_ssh_host_key_dsa_public": "REDACTED KEY VALUE"
"ansible_ssh_host_key_ecdsa_public": "REDACTED KEY VALUE"
"ansible_ssh_host_key_rsa_public": "REDACTED KEY VALUE"
"ansible_swapfree_mb": 665,
"ansible_swaptotal_mb": 1021,
"ansible_system": "Linux",
"ansible_system_vendor": "VMware, Inc.",
"ansible_user_id": "root",
"ansible_userspace_architecture": "x86_64",
"ansible_userspace_bits": "64",
"ansible_virtualization_role": "guest",
"ansible_virtualization_type": "VMware"
The debug module can be used to analyze variables. Be careful running the following command. In our setup it generates 444709 lines with 16MB:
ansible -m debug -a 'var=hostvars' localhost
I am not sure but it might be necessary to enable facts caching.
If you need just one host use the host name as a key for the hostvars hash:
ansible -m debug -a 'var=hostvars.localhost' localhost
This command will display also group and host variables.
Note the official docs on connection configuration variables or "behavioral" variables - which aren't listed in host vars, appears to be List of Behavioral Inventory Parameters in the Inventory documentation.
P.S. The sudo option is undocumented there (yes its sudo not ansible_sudo as you'd expect ...) and probably a couple more aren't, but thats best doc I've found on em.
Some variables are not available on every host, e.g. ansible_domain and domain. If the situation needs to be debugged, I login to the server and issue:
user#server:~$ ansible -m setup localhost | grep domain
[WARNING]: provided hosts list is empty, only localhost is available
"ansible_domain": "prd.example.com",
I know this question has been answered already, but I feel like there are a whole other set of pre-defined variables not covered by the ansible_* facts. This documentation page covers the directives (variables that modify Ansible's behavior), which I was looking for when I came across this page.
This includes some common and some specific use-case directives:
become: Controls privilege escalation (sudo)
delegate_to: run task on another host (like running on localhost)
serial: allows you to run a play across a specific number/percentage of hosts before moving onto next set
https://github.com/f500/ansible-dumpall
FYI: this github project shows you how to list 90% of variables across all hosts. I find it more globally useful than single host commands. The README includes instructions for building a simple inventory report. It's even more valuable to run this at the end of a playbook to see all the Facts. To also debug Task behaviour use register:
The result is missing a few items:
- included YAML file variables
- extra-vars
- a number of the Ansible internal vars described here: Ansible Behavioural Params

Resources