I have installed gerrit with http auth type. now i want to add reviewers and users to it.
How can i add users?
I have tried using gerrit web ui to add users. no no response from it.
if we are using auth type as http, we need to add users/ reviewers through command line.
cat ~/.ssh/id_watcher.pub | ssh -p 29418 review.example.com gerrit create-account --group "'Non-Interactive Users'" --ssh-key - watcher
where watcher is the username and Non-Interactive Users is group name.
Related
I've assigned ownership of one of my google sheets to a service account from a gcloud project I am working on (not a smart thing to do, I know...). How can I re-assign ownership of this sheet to my main user account?
If you have permissions on the service account (e.g. you're owner of the GCP project), you can use the command line tools to authenticate as the service account and modify the permissions there.
Step by step process (you might have already some of those steps done):
Download and install the GCP SDK:
curl https://sdk.cloud.google.com | bash
exec -l $SHELL
gcloud init
During the initialization, follow the steps to authenticate with the account owner of the GCP project, and select the project in question. You can ignore the rest of the steps.
Create and download a key for the service account that is the current owner of the file (change the service account in this command):
gcloud iam service-accounts keys create key --iam-account service_account_id#project_id.iam.gserviceaccount.com
Hack the SDK to include the Drive scope:
sed -i 's/\(^CLOUDSDK_SCOPES = (\)/\1"https:\/\/www.googleapis.com\/auth\/drive",/' $(gcloud info --format 'value(installation.sdk_root)')/lib/googlecloudsdk/core/config.py
Activate the service account (change the service account in this command):
gcloud auth activate-service-account service_account_id#project_id.iam.gserviceaccount.com --key-file key
Make a call to the Drive API giving back the ownership (change the drive file ID and the new owner email address in this command):
curl -H"Authorization: Bearer $(gcloud auth print-access-token)" https://www.googleapis.com/drive/v3/files/DRIVE_FILE_ID/permissions?transferOwnership=true -d '{"role":"owner","type":"user","emailAddress":"YOUR_EMAIL#example.com"}' -H'content-type:application/json'
After these steps, your regular email account should be the new owner.
This is a pretty bad solution (hacking the SDK, etc..), but it's barely 7 bash commands, so I think it's likely the fastest/simplest one, at least for a one-off situation.
If this happens often (I guess not), it's likely that a real script would be more useful.
I am new to Azure platform. I have followed this link to generate service principle : https://learn.microsoft.com/en-us/azure/azure-resource-manager/resource-group-create-service-principal-portal
When I reach to step : Assign application to role > point 6 (Search for your application, and select it.) I can't see my application in result of search.
After that I have tried to create VM using ruby api :
https://github.com/Azure/azure-sdk-for-ruby/tree/master/management/azure_mgmt_compute
When I implement code to create VM, I get following error :
"message": "MsRestAzure::AzureOperationError: AuthorizationFailed: The client 'xxxx' with object id 'xxxx' does not have authorization to perform action 'Microsoft.Compute/virtualMachines/write' over scope '/subscriptions/xxxx/resourceGroups/my_group/providers/Microsoft.Compute/virtualMachines/test-ubuntu3'.",
In above error message both client and object id is same. I don't know why and what is the meaning of object id.
How I can resolve this issue ? Where I should look at in portal ? Any help will be appreciated.
Thank you
Root cause is the service principal you are using doesn't have rights within that tenant.
Tenants have subscriptions and service principals belong to tenants. Azure resource manager also exposes role based authorization for a given principal, which would give it rights on Azure resources. It appears the service principal doesn't have rights to read from that subscription.
Please use Azure CLI 2.0 to create service principal:
az ad sp create-for-rbac --role="Contributor" --scopes="/subscriptions/mySubscriptionID/resourceGroups/myResourceGroupName"
Here is the information about CLI 2.0 to create service principal:
C:\Users>az ad sp create-for-rbac -h
Command
az ad sp create-for-rbac: Create a service principal and configure its access to Azure
resources.
Arguments
--cert : PEM or DER formatted public certificate using string or `#<file path>` to
load from a file. Do not include private key info.
--create-cert : Create and upload self-signed certificate which you can use to login.
--expanded-view : Once created, display more information like subscription and cloud
environments.
--name -n : A display name or an app id uri. Command will generate one if missing.
--password -p : The password used to login. If missing, command will generate one.
--role : Role the service principal has on the resources. Default: Contributor.
--scopes : Space separated scopes the service principal's role assignment applies to.
Defaults to the root of the current subscription.
--skip-assignment: Do not create default assignment.
--years : Years the password will be valid. Default: 1 year.
Global Arguments
--debug : Increase logging verbosity to show all debug logs.
--help -h : Show this help message and exit.
--output -o : Output format. Allowed values: json, jsonc, table, tsv. Default: json.
--query : JMESPath query string. See http://jmespath.org/ for more information and
examples.
--verbose : Increase logging verbosity. Use --debug for full debug logs.
Examples
Create with a default role assignment.
az ad sp create-for-rbac
Create using a custom name, and with a default assiggment.
az ad sp create-for-rbac -n "http://MyApp"
Create without a default assignment.
az ad sp create-for-rbac --skip-assignment
Create with customized assignments
az ad sp create-for-rbac -n "http://MyApp" --role contributor --scopes
/subscriptions/11111111-2222-3333-4444-555555555555/resourceGroups/MyResourceGroup
/subscriptions/11111111-2222-3333-4444-666666666666/resourceGroups/MyAnotherResourceGroup
Create using self-signed certificte
az ad sp create-for-rbac --create-cert
Login with a service principal.
az login --service-principal -u <name> -p <password> --tenant <tenant>
Login with self-signed certificate
az login --service-principal -u <name> -p <certificate file path> --tenant <tenant>
Reset credentials on expiration.
az ad sp reset-credentials --name <name>
Create extra role assignments in future.
az role assignment create --assignee <name> --role Contributor
Revoke the service principal when done with it.
az ad app delete --id <name>
Create using certificate from Key Vault
az keyvault certificate download --vault-name vault -n cert-name -f cert.pem
az ad sp create-for-rbac --cert #cert.pem
Also, you can follow the steps below to give a role for the service principal to add permission for your app on Azure portal, as the figure below.
Move to the Subscription category.
Select the currect subscription for your app.
Click the Access control (IAM) tab.
Click the + Add button.
Select the Contributor role in the Add permission dialog.
Search with your app name, and select the app in the searched list.
Click the Save button.
I setup a gerrit server, and I can login as admin (admin/passwd).
Then I installed the gerrit command line tools and create a new user with the command
cat ~/.ssh/id_watcher.pub | ssh -p 29418 review.example.com gerrit create-account --group "'some-group'" --http-password "'passwd'" --ssh-key - watcher
user wathcer created successfully, but I can not login as wathcer user. It notice "Invalid username or password." what do I miss?
Pay attention at the "gerrit create-account" documentation:
Creates a new internal-only user account.
If the account is created without an email address, it may only be
used for batch/role access, such as from an automated build system or
event monitoring over gerrit stream-events.
You can't log in, interactively, using this account.
I previously asked how to get Jenkins to deny anonymous read access here: Jenkins security - hide all screens unless user is logged in. That solution worked great, except that it broke access to Jenkins via the CLI jar, despite the fact that we're using the CLI via an SSH key associated with a user - I guess that access doesn't constitute an "authentication". Is there a way to get the CLI to have read access, but not users using the front-end UI?
After some more experimentation, this looks to be a flat-out Jenkins bug - granting the Anonymous user Administrative rights is necessary to make access via the cli jar (with an SSH key) or via HTTP (with the user's API token) work.
When using the CLI, you can pass -jnlpCredentials or -auth parameter.
Found it through trial an error using this:
java -jar slave.jar --help
In your case, you'd use the -auth parameter to specify username:pass
I have an Ant build that will sometimes execute a 'git push' within a directory on my server. I can do this fine interactively because it asks for the passphrase for my key, but this becomes problematic if you set up a cron job to run the build unattended.
Are there options for me beyond not using a passphrase? I've heard of using ssh-agent, but I've also heard for unattended processes that route won't work. Does anyone have any recommendations for this, and perhaps an example of how to implement it?
I saw that someone suggested to run the cron as a daemon here:
Accessing SSH key from bash script running via a cron job -- but I'm not sure how I could do that or put in my passphrase without compromising it by putting it in plain text, etc.
Any help greatly appreciated.
First, set yourself up for password-less login.
Use ssh-keygen to generate a public/private key pair with no password. Append the public key to ~/.ssh/authorized_keys on the server.
Then run ssh -i /path/to/private_key server to confirm that the password-less login is working.
Finally, configure git to use that ssh -i ... command.
As #mah suggests, you might want to create a specific git account on the server. You add the public key to ~git/.ssh/authorized_keys to enable the password-less login.
authorized_keys also has options to restrict what commands the incoming connection can run. If you are interested in those features, read the SSH documentation.
And of course, you want to keep the private key file readable only by you.
I would solve this by creating a restricted account on the git server and have the ant client use a keyless cert to that restricted account.