I have a bunch of tasks in a role that repeatedly use:
sudo: yes
sudo_user: my_user
Isn't there a way that I can set these attributes for multiple tasks, so it will be more DRY?
I know I can change the user in the playbook, but other tasks need user root, so I can't change that.
In your inventory file you can have multiple groups, ie: root_access group or deploy_user group. So you define your hosts, say like this;
[web]
webby-1 ansible_ssh_host=192.168.1.1
webby-2 ansible_ssh_host=ec2-192-168-1-1.compute-1.amazonaws.com
[foo:children]
web
[foo:vars]
ansible_ssh_user=foo
ansible_ssh_private_key_file=~/.ssh/foo.pem
[bar:children]
web
[bar:vars]
ansible_ssh_user=bar
ansible_ssh_private_key_file=~/.ssh/bar.pem
and then you can call them based on the inventory groups.
Related
I am using Ansible tower 3.4.3.
As part of one of my jobs, I need to generate a log file and logfile name should contain Tower_Job_ID to easily recognize which log is generated by which tower job id.
I guess there will be some global variables like "ansible_tower_job_id" but unable to find any documentation or the variable name.
Can some one help, how to capture the current running job ID in ansible tower.
The callback link contains the ID in it.
From the docs: "The ‘1’ in this sample URL is the job template ID in Tower." .
We have some scripts to help us set up VPCs with up to 6 VMs in AWS. Now I want to log in to each of these machines. For security reasons we can only access one of them via SSH and then tunnel/proxy through that to the other machines. So in our inventory we have the IP address of the SSH host (we call it Redcarpet) and some other hosts like Elasticsearch, Mongodb and Worker:
#inventory/hosts
[redcarpet]
57.44.113.25
[services]
10.0.1.2
[worker]
10.0.5.77
10.0.1.200
[elasticsearch]
10.0.5.30
[mongodb]
10.0.1.5
Now I need to tell each of the groups, EXCEPT redcarpet to use certain SSH settings. If these were applicable to all groups, I would put them in inventory/group_vars/all.yml, but now I will have to put them in:
inventory/group_vars/services.yml
inventory/group_vars/worker.yml
inventory/group_vars/elasticsearch.yml
inventory/group_vars/mongodb.yml
Which leads to duplication. Therefore I would like to use an include or include_vars to include one or two variables from a common file (e.g. inventory/common.yml). However, when I try to do this in any of the group_var files above, it does not pick up the variables. What is the best practice to use with variables that are common to multiple groups?
If you want to go with the group_vars approach, I would suggest you add another group, and add the dependent groups as children to that group.
#inventory/hosts
[redcarpet]
57.44.113.25
[services]
10.0.1.2
[worker]
10.0.5.77
10.0.1.200
[elasticsearch]
10.0.5.30
[mongodb]
10.0.1.5
[redcarpet_deps:children]
mongodb
elasticsearch
worker
services
And now you can have a group_vars file called redcarpet_deps.yml and they should pickup the vars from there.
I am trying to set the correct values for LDAP properties of a SonarQube Server. I am having difficulty finding a resource that explains the list of possible values for these properties, and understand which one to use in which scenario?
I am referring to https://docs.sonarqube.org/display/PLUG/LDAP+Plugin
For example,
Property1: ldap.user.request
Default_Value: (&(objectClass=inetOrgPerson)(uid={login}))
Example for AD: (&(objectClass=user)(sAMAccountName={login}))
Here what are all the possible values for objectClass?
When do i use value inetOrgPerson?
When do I use value user?
When do I use uid?
When do I use sAMAccountName? What does it mean?
There are several other properties like memberAttribute , idAttribute which I dont understand.
Is there a guide available which describes ALL ldap properties and ALL their possible values? I tried searching on LDAP.com, openldap.org but couldnt find relevant answers.
This is what i use as my LDAP configuration in the conf file.
Hope that helps you make a good start.
# LDAP configuration
# General Configuration
sonar.security.realm: LDAP
sonar.security.savePassword: true
sonar.authenticator.createUsers: true
sonar.security.localUsers: admin,sonar-build
ldap.url: ldap://ipadress:389
ldap.bindDn: CN=SonarUser,OU=Service Accounts,DC=domain,DC=com
ldap.bindPassword: {aes}xxx
# User Configuration
ldap.user.baseDn: DC=domain,DC=com
ldap.user.request: (&(objectClass=user)(sAMAccountName={login}))
ldap.user.realNameAttribute: cn
ldap.user.emailAttribute: mail
# Group Configuration
ldap.group.baseDn: DC=domain,DC=com
ldap.group.request: (&(objectClass=group)(memberUid={uid}))
What is different between:
test = self.env['my.example'].sudo().create({'id':1, 'name': 'test'})
test = self.env['my.example'].create({'id':1, 'name': 'test'})
All example work, but what is the advantages when using sudo()?
Odoo 8–12
Calling sudo() (with no parameters) before calling create() will return the recordset with an updated environment with the admin (superuser) user ID set. This means that further method calls on your recordset will use the admin user and as a result bypass access rights/record rules checks [source]. sudo() also takes an optional parameter user which is the ID of the user (res.users) which will be used in the environment (SUPERUSER_ID is the default).
When not using sudo(), if the user who calls your method does not have create permissions on my.example model, then calling create will fail with an AccessError.
Because access rights/record rules are not applied for the superuser, sudo() should be used with caution. Also, it can have some undesired effects, eg. mixing records from different companies in multi-company environments, additional refetching due to cache invalidation (see section Environment swapping in Model Reference).
Odoo 13+
Starting with Odoo 13, calling sudo(flag) will return the recordset in a environment with superuser mode enabled or disabled, depending if flag is True or False, respectively. The superuser mode does not change the current user, and simply bypasses access rights checks. Use with_user(user) to actually switch users.
You can check the comments on sudo in Odoo code at odoo -> models.py -> def sudo().
Returns a new version of this recordset attached to the provided
user.
By default this returns a ``SUPERUSER`` recordset, where access
control and record rules are bypassed.
It is same as:
from odoo import api, SUPERUSER_ID
env = api.Environment(cr, SUPERUSER_ID, {})
In this example we pass SUPERUSER_ID in place of uid at the time of creating a Enviroment.
If you are not use Sudo() then the current user need permission to
create a given object.
.. note::
Using ``sudo`` could cause data access to cross the
boundaries of record rules, possibly mixing records that
are meant to be isolated (e.g. records from different
companies in multi-company environments).
It may lead to un-intuitive results in methods which select one
record among many - for example getting the default company, or
selecting a Bill of Materials.
.. note::
Because the record rules and access control will have to be
re-evaluated, the new recordset will not benefit from the current
environment's data cache, so later data access may incur extra
delays while re-fetching from the database.
The returned recordset has the same prefetch object as ``self``.
I am creating a group of users within TFS 2013 and I want to add them to the none default access level (ex. the full access group) but I noticed I am only able to do this through the web interface by adding a TFS Group under that certain level. I am wondering if there is a way to do this via the developer tool (command line) as everything I am doing is being done in a batch script.
Any input would be appreciated. Thanks!
Create 3 TFS server groups; add these groups to the different access levels (e.g. TFS_ACCESS_LEVEL_(NONE|STANDARD|FULL)). Now use the TFSSecurity commandline tool to add groups to these existing and mapped groups(tfssecurity /g+ TFS_ACCESS_LEVEL_NONE GroupYouWantToHaveThisAccessLevel). There is no other way to directly add people to the access levels, except probably through the Object Model using C#.
For the record, tfssecurity may require the URI, which can be obtained via API. This is easy to do in Powershell, here is how to create a TFS group
[psobject] $tfs = get-tfs -serverName $collection
$projectUri = ($tfs.CSS.ListAllProjects() | where { $_.Name -eq $project }).Uri
& $TFSSecurity /gc $projectUri $groupName $groupDescription /collection:$collection
Full script at TfsSecurity wrapper.