What is an OpenWhisk 'collection'? - openwhisk

What causes an action to give an error "Resource by this name exists but is not in this collection?"
From this question, there is a specific case of name collisions between triggers, rules, and actions. But for me, there is nothing except a single action that I can not modify.
$ wsk -i rule list
rules
$ wsk -i trigger list
triggers
$ wsk -i action list
actions
/guest/getgoods/getgoods private rust:1.34
$ wsk -i action delete getgoods
error: Unable to delete action 'getgoods': Resource by this name exists but is not in this collection. (code tv2u2w09oog8Z5y2ONGuGvLCvBErctga)
Run 'wsk --help' for usage.
For added info, I got an action into this state by using wskdeploy with a Rust action. I am able to deploy the same action (under a different name) with a wsk action create command just fine.

This error also comes while accessing action as a package, the name of your package and action is the same.
Try this
wsk -i action delete getgoods/getgoods

Related

Trigger remote jenkins job with specific build id

I have pipeline that triggers multiple builds on remote jenkins job.
Problem is, when there are multiple builds triggered at same time, following command:
JENKINS_BUILD_ID=$(curl -k --silent --netrc-file "$HOME/.netrc" "${JENKINS_URL}/job/${JOB_NAME}/api/json" | grep -Po '"nextBuildNumber":\K\d+')
returns same build numbers( for example 125 is next build id).
In jenkins job configuration, I set up build name to be:
${ENV,var="WORKFLOW_NAME"}
But in api, to get logs, I need to use that build number(for example 125), is there way to use parameter in api (jenkins_job/WORKFLOW_NAME instead of default build number), where WORKFLOW_NAME is parameter parsed with remote trigger:
curl -k -X POST --netrc-file "$HOME/.netrc" "${JENKINS_URL}/job/{$JOB_NAME}/buildWithParameters" \
-F WORKFLOW_NAME="$WORKFLOW_NAME"

How do I get make to run a command that uses a make variable in it to create an azure service principal

I have the following rule in my Makefile:
setSPRole:
az role assignment create --assignee $(appId) --scope $(az acr show --name $(acr_name) --query id --output tsv) --role acrpush
At the top of the file I have
include .env
so that I can use appId and acr_name
however when I run make setSPRole the result I get is:
az role assignment create --assignee "MY_ACTUAL_APP_ID" --scope --role acrpush
As you can see the scope is empty but the appId gets filled in correctly.
How do I get scope to use the value of the az acr show command?
What I have tried:
I have tried assigning the value and then using it on the next line like so:
setSPRole:
ACR_REG_ID = az acr show --name $(acr_name) --query id --output tsv; \
az role assignment create --assignee $(appId) --scope $(ACR_REG_ID) --role acrpush
but that did not work either.
Recipes in make rules are shell scripts. Make invokes the shell to run them. So, the command you put into a recipe (indented with a TAB) must be a valid shell command.
Knowing that, maybe you can see why your second example doesn't work: that's not a valid shell script (if you type it at your shell prompt you'll get the same error you get when make runs it).
However make uses the $ prefix for its own variable (and function, in GNU make) expansion. So text like $(foo) or ${foo} is expanded by make, before invoking the shell, and it sends the result of the expansion to the shell to be run.
Knowing that, maybe you can see why your first example doesn't work: the string $(az acr show ...) is considered a long make variable name, which has never been set, so it expands to the empty string.
In a make recipe if you want to hide the $ from make so it's passed to the shell instead, you escape it by writing it twice: $$(az acr show ...).

wrap ansible task with two tasks (including conditional)

I have a couple of immutable files on my server, like for example /etc/passwd. This means that every time a user is added, edited or removed on the system (manually, by dpkg or any other way), we need to run chattr -i /etc/passwd and chattr +i /etc/passwd before and after the command in question. The problem is that we don't always know up front this will happen.
Is there a way in ansible to plan the following in a playbook or role:
do a task
check if there's an error like operation not permitted: <filename>
chattr -i <filename>
redo the task
chattr +i <filename> (even if the task gave another error this time round)
In more general terms: is it possible to wrap an ansible task in two other tasks?
Or, if I put the chattr +i in a handler, is there a way to have the chattr -i defined somewhere and have it run when necessary?

AWS Launch Configuration not picking up user data

We are trying to build an an autoscaling group(lets say AS) configured with an elastic load balancer(lets say ELB) in AWS. The autoscaling group itself is configured with a launch configuration(lets say LC). As far as I could understand from the AWS documentation, pasting a script, as-is, in the user data section of the launch configuration would run that script for every instance launched into an auto scaling group associated with that auto scaling group.
For example pasting this in user data would have a file named configure available in the home folder of a t2 micro ubuntu image:
#!/bin/bash
cd
touch configure
Our end goal is:
Increase instances in auto scaling group, they launch with our startup script and this new instance gets added behind the load balancer tagged with the auto scaling group. But the script was not executed at the instance launch. My questions are:
1. Am i missing something here?
2. What should I do to run our startup script at time of launching any new instance in an auto scaling group?
3. Is there any way to verify if user data was really picked up by the launch?
The direction you are following is right. What is wrong is your user data script.
Problem 1:
What you have to remember is that user data will be executed as user root, not ubuntu. So if your script worked fine, you would find your file in /root/configure, NOT IN /home/ubuntu/configure.
Problem 2:
Your script is actually executing, but it's incorrect and is failing at cd command, thus file is not created.
cd builtin command without any directory given will try to do cd $HOME, however $HOME is NOT SET during cloud-init run, so you have to be explicit here.
Change your script to below and it will work:
#!/bin/bash
cd /root
touch configure
You can also debug issues with your user-data script by inspecting /var/log/cloud-init.log log file, in particular checking for errors in it: grep -i error /var/log/cloud-init.log
Hope it helps!

Remove User in snmp by agent

I could quickly go through the snmp installation and it works fine.
In one of the agent modules I am currently looking into and trying to modify the source. I came across an issue where I need to remove the user by the agent.
Stuck with to complete this:
Just like the way net-snmp-create-v3-user creates an user at server side I was wondering if there is something similar to remove the user.
In my understandings, the net-snmp-create-v3-user would simply do the following:
service stop snmpd
$EDITOR /var/lib/net-snmp/snmpd.conf
[add *usmUser* lines]
$EDITOR /etc/snmp/snmpd.conf
[add *rouser* and *rwuser* lines]
service start snmpd
The snmpd should be stopped before adding new user data in the .conf files.
Equivalent to net-snmp-create-v3-user, removing an user would be something similar:
service stop snmpd
$EDITOR /var/lib/net-snmp/snmpd.conf
[find and remove *usmUser* info]
$EDITOR /etc/snmp/snmpd.conf
[find and remove *rouser* and *rwuser* info]
service start snmpd
Rather than printable characters, the usmUser fields are expressed as hex strings. They are simply not encrypted.
I just had a similar issue. I had added an user, and wanted to delete it again. However, net-snmp removes the createUser statements from the /var/net-snmp/snmpd.conf file for security reasons, thus Ashwin kumar's answer did not work for me (* see EDIT below).
snmpusm has a delete option, which can be used to remove users. snmpusm requires another user to authenticate the delete request (I haven't tested without, but I would assume that the other user has to have RW access). The following example has enabled me to remove a user from my snmp configuration:
snmpusm -v 3 -u <RWUSER> -l authNoPriv -a MD5 -A <PASSWORD_OF_RWUSER> localhost delete <USERNAME_TO_DELETE>
This solution is inspired by this page http://www.mkssoftware.com/docs/man1/snmpusm.1.asp which also describes how to create a user and change the Passphrase of a user with snmpusm.
EDIT: My bad, I didn't notice that the /var/net-snmp/snmpd.conf actually contained more lines than what vim displayed without scrolling. The "usmUser" lines that Ashwin mentions are there. I haven't tried to remove the lines, but I assume that would work as well.

Resources