I am having trouble getting the right variable based on a Role.
Perhaps I have the answer but I am not sure and could not find it in the documentation and here in the other questions.
TL;DR:
Multiple Roles on a variable use an OR, not an AND?
Intro
In Infrastructure I have multiple roles assigned to a machine:
WebServer
ApplicationServer
ApplA
ApplB
A variable has two values, each value has the role WebServer and ApplA or ApplB.
In Process the same combination of the Roles WebServer and ApplA is used (or WebServer and ApplB).
Problem
The value of the variable of ApplB is used in the step with ApplA.
It seems that this is because it uses an OR between the Roles and not a AND.
Correct?
That's right. If multiple roles are applied in the scope, it means that the variable will have that value for both of those roles individually, not together. You can combine scopes of different types (like DEV and ApplA) but not of the same time.
This section from the docs has a little more information on scope precedence and what happens if there are conflicting values.
In your deployment process, the "Deploy site" steps will run for all targets that have WebServer or ApplA. That might not be what you want.
In this case, you can consider dropping the webserver role for the purposes of scoping the variables and the deployment steps or combine it with your other tags to make them a little more specific. Instead of WebServer, ApplA, and ApplB, you can replace those with ApplA-Web and ApplB-Web for use in your steps and variables.
I hope that helps!
Related
I am writing a cleanup script that cleans up after Ansible's iam_role inability to clean instance profiles. In general, this instance profile has no roles attached, so I would like to filter all instance profiles that has empty roles object. However, jmespath has not_null function but not is_null function. So, my question is - how can filter out only instance profiles with no roles attached (boto3 or shell). Thanks!
Using boto3, you can try this. This is assuming the Roles value is an empty list, []. If it's something else, you just have to fix the code to what is returned.
client = boto3.client('iam')
r = client.list_instance_profiles()
for ip in r['InstanceProfiles']:
if len(ip['Roles']) == 0:
print(ip)
I have a console task ran through:
$schedule->command('process:job')
->cron('* * * * *')
->withoutOverlapping();
The task is run, it can invoke different services, everything is fine in the world. However I have one specific tasks invoking a different class where the configuration is not loaded.
For specific reasons I wish to read my configuration in $_ENV (it allows me to do some key value iteration and process some keys specifically based on a pattern). But here $_ENV remains empty, I can read configuration through config() or env().
This never happens through HTTP calls nor through some command lines call (I haven't been able to understand the difference in the scheduler call and command line invocation).
Laravel 5.6
EDIT: this question is kept here because I didn't manage to find the existing relevant one Why is my $_ENV empty?
Found my solution here: Why is my $_ENV empty?
Basically $_ENV is not populated on a systematic basis but only if the flag E is in your variables_order ini variable. So if you stumble one the same problem, I suggest a quick check.
var_dump(ini_get('variables_order'));
The fix is obviously to fix your ini file.
Do scheduled jobs in Tower use the extra vars set in the original template the job was based on?
Scheduled Jobs have extra vars also, but it seems like you'd want to still utilize the extra vars set in the template, and I'd rather not have to duplicate them. A change would require a change in the template and a change in every related scheduled job. It seems like extra vars could be set in a scheduled job, and it would have precedence over any variable in the template.
According to the Ansible Job Templates documentation, the answer appears to be yes, unless they are overridden:
Prompt for Extra Variables: If this is checked, the user is prompted for Extra Variables at job execution. The set of extra variables defaults to any Extra Variables already configured for the job template.
Also from the same document:
... passing extra variables to a job template (as you would do with a survey) can override other variables being passed from the inventory and project.
And from the Variables documentation:
Inside a template you automatically have access to all of the variables that are in scope for a host.
So if you don't prompt for user-specified variables, or otherwise override the extra vars already set, Ansible will use any extra variables that are currently set.
Tower does use the extra vars set in an underlying template. And if any Extra Vars are set in a Scheduled Job, they will take precedence. This behavior is what you would expect, now that I've used it a bit.
I'm using a control-repo for my puppet master profiles/roles.
I'm using Hiera and I would like to add role in the hierarchy
My hiera.yaml looks like :
:backends:
- yaml
:yaml:
:datadir: "/etc/puppetlabs/code/environments/%{::environment}/hieradata"
:hierarchy:
- "nodes/%{::trusted.certname}"
- "roles/%{::role}"
- "common"
site.pp
node xx01 {
include role::cassandra
}
node xx02 {
include role::mysql
}
node xx03 {
include role::cassandra
}
For example I should add role fact for node xx01 and xx03. So it would useless to add fact for every new node in the future. so I want the fact to be added for every new node.
So the best way is to add a code to add a the fact for role in the control repo. not in the modules.
The puppet agent doesn't seem to intrinsically have the role fact, so I added a role fact in /etc/puppetlabs/facter/facts.d
I think it's useless to compare with hostname to add the fact for roles if the hostname reflects the role. so I could use the hierarchy with a hostname rather than role.
You can either do this with an external fact or a custom fact. I should also note that your hiera file is completely fine and will automatically pick up your role fact for data resolution once that fact is populated. I am also going to assume from that hiera file that you are using Puppet 4, Facter 3, and Hiera 3 (not the Puppet Data Provider with module data lookups etc.), since you are using syntax and conventions consistent with those.
Let us say you have roles app, db, and report.
For custom facts, you would want to write some code like the following in the lib/facter/role.rb directory of a compiled module:
Facter.add('role') do
setcode do
case Facter.value(:hostname)
when /db/ then role = 'db'
when /app/ then role = 'app'
when /report/ then role = 'report'
else role = default
role
end
end
This would be a simple example of how to do this.
You can also do this with an external fact placed in the lib/facts.d directory of a compiled module, like a role.yaml or role.sh file. The yaml would be good for static data, and the shell script would be an example of how to dynamically ascertain the role of the server without using ruby.
You can check additional documentation here: https://docs.puppet.com/facter/3.4/custom_facts.html
I'm trying to define the type of entered credentials with:
SID_NAME_USE pe;
...
resolved=LookupAccountNameW (NULL,L"builtin\users",&sid,&cbsid,buff,&dd,&pe);
No matter if I enter "builtin\users" or "users" it resolves successfully but returns SidTypeAlias in pe enum.
But I expect SidTypeWellKnownGroup or SidTypeGroup.
Question: How to reliably define if given string is a Windows Group name ?
The MSDN page Well-known SIDs briefly describes the meaning of "alias" in this context:
The following table has examples of domain-relative RIDs that you can use to form well-known SIDs for local groups (aliases).
One of the table entries is for the Users group, so the behaviour you are describing is as expected.
You can continue to use LookupAccountName() as you planned, you simply need to modify your code to recognize that any of SidTypeAlias, SidTypeWellKnownGroup, or SidTypeGroup represent groups.
The Glossary of the Security Account Manager Remote Protocol specification gives some hints as to what SidTypeAlias might be:
alias object: See resource group.
resource group: A group object whose membership is added to the authorization context only if the server receiving the context is a member of the same domain as the resource group.
This suggests that "alias" means "Domain Local group" in this context.
I confirmed this in my domain, by obtaining all domain groups using DirectorySearcher and calling LookupAccountName on each. Results:
all Global and Universal groups had SidTypeGroup;
all non-builtin Domain Local groups (groupType 0x80000004) had SidTypeAlias;
builtin Domain Local groups (those with groupType 0x80000005 = system-created domain local, such as Account Operators or Users) also had SidTypeAlias, but I had to run the code on a DC - when executed on a member workstation, LookupAccountName failed (ERROR_NONE_MAPPED) for all such groups except IIS_IUSRS.
Bottom line - SidTypeAlias should be treated as a group.