On SonarCloud, I created an organization and a user (from GitHub), plus a project. For the user I created a token. Then I ran the command
mvn org.sonarsource.scanner.maven:sonar-maven-plugin:3.5.0.1254:sonar -Dsonar.projectKey=<project key> -Dsonar.organization=<my org> -Dsonar.host.url=https://sonarcloud.io -Dsonar.login=<token>
I come up with the error message
[ERROR] Failed to execute goal org.sonarsource.scanner.maven:sonar-maven-plugin:3.5.0.1254:sonar (default-cli) on project XXX: You're not authorized to run analysis. Please contact the project administrator.
In the project settings > Administration > Permissions, the user does have "Execute Analysis" permission.
If I add the "Execute Analysis" permission to Anyone, the command above works (it does not need the -Dsonar.login option).
Does anyone have a clue?
Adding the "Execute Analysis" permission to the SonarCloud user who generated the token should be enough.
Can you retry with:
mvn sonar:sonar
"-Dsonar.projectKey=<project key>" \
"-Dsonar.organization=<my org>" \
"-Dsonar.host.url=https://sonarcloud.io" \
"-Dsonar.login=<token>"
In case it doesn't work, can you provide the output of the command?
It turns out that SonarCloud works as expected. I had forgotten that some people in my organization seem to enjoy making their colleagues' life miserable. Sneakily removing items such as sonar.login from the requests is one among their tricks.
Related
Much like this thread: Publishing and Consuming GitHub Package Repository with NuGet: Unable to load the service index error
I have the csproj correct, the nuget.config correct (same as in that thread, but for my username), and following the answer where the token has all the rights, and I do the dotnet nuget add source, and the dotnet nuget push (same formatting/syntax).
However, I always always get this:
warn: <username> does not have the correct permissions to execute 'CreatePackageVersion'
Forbidden https://nuget.pkg.github.com/(username)/ 687ms
error: Response status code does not indicate success: 403 (Forbidden).
I've tried with/without the -k (git token) in the dotnet nuget push, no effect. The --interactive that it recommends, doesn't change anything.
I'm running this in a standard command line in the \bin\Release\netstandard2.0\publish directory, after having published to that folder.
Did already restart computer even after adding appropriate csproj and nuget.config data. Also tried doing #username and username (my username with and without an at sign, since all docs have no actual username examples, many blackened out).
(I do want it to be public readable, already added source .../(username)/index.json).
Check the RepositoryUrl in your csproj. It should match the repository you're uploading packages to. You may also need to set PublishRepositoryUrl.
I was trying to showcase binary authorization to my client as POC. During the deployment, it is failing with the following error message:
pods "hello-app-6589454ddd-wlkbg" is forbidden: image policy webhook backend denied one or more images: Denied by cluster admission rule for us-central1.staging-cluster. Denied by Attestor. Image gcr.io//hello-app:e1479a4 denied by projects//attestors/vulnz-attestor: Attestor cannot attest to an image deployed by tag
I have adhered all steps mentioned in the site.
I have verified the image repeatedly for few occurances, for example using below command to force fully make the attestation:
gcloud alpha container binauthz attestations sign-and-create --project "projectxyz" --artifact-url "gcr.io/projectxyz/hello-app#sha256:82f1887cf5e1ff80ee67f4a820703130b7d533f43fe4b7a2b6b32ec430ddd699" --attestor "vulnz-attestor" --attestor-project "projectxyz" --keyversion "1" --keyversion-key "vulnz-signer" --keyversion-location "us-central1" --keyversion-keyring "binauthz" --keyversion-project "projectxyz"
It throws error as:
ERROR: (gcloud.alpha.container.binauthz.attestations.sign-and-create) Resource in project [project xyz] is the subject of a conflict: occurrence ID "c5f03cc3-3829-44cc-ae38-2b2b3967ba61" already exists in project "projectxyz"
So when I verify, I found the attestion present:
gcloud beta container binauthz attestations list --artifact-url "gcr.io/projectxyz/hello-app#sha256:82f1887cf5e1ff80ee67f4a820703130b7d533f43fe4b7a2b6b32ec430ddd699" --attestor "vulnz-attestor" --attestor-project "projectxyz" --format json | jq '.[0].kind' \
> | grep 'ATTESTATION'
"ATTESTATION"
Here are the screen shots:
Any feedback please?
Thanks in advance.
Thank you for trying Binary Authorization. I just updated the Binary Authorization Solution, which you might find helpful.
A few things I noticed along the way:
... denied by projects//attestors/vulnz-attestor:
There should be a project ID in between projects and attestors, like:
projects/my-project/attestors/vulnz-attestor
Similarly, your gcr.io links should include that same project ID, for example:
gcr.io//hello-app:e1479a4
should be
gcr.io/my-project/hello-app:e1479a4
If you followed a tutorial, it likely asked you to set a variable like $PROJECT_ID, but you may have accidentally unset it or ran the command in a different terminal session.
After pointed to another repository problem solved, but before that you were having problems and there could be many reasons. please contact support with error message if you are having the same problem.
Occasionally the first upload of artifacts during a GitLab pipeline fail.
I'm getting the following error message in the logs:
2019-08-01 13:43:14,149 [http-nio-8082-exec-187] [ERROR]
(o.j.s.b.p.t.FilePersistenceHelper:87) - Failed moving
'path_to_artifactory\filestore_pre\dbRecord123.bin' to
'path_to_artifactory\filestore\5e\5ecc5f719b4442b9b04f9010646d34917aca8ca2'.
Access to file denied null 2019-08-01 13:43:14,149
[http-nio-8082-exec-187] [ERROR] (o.a.w.s.RepoFilter :251) - Upload
request of products-stage-qa:file_to_upload failed due to {}
java.nio.file.AccessDeniedException: Failed to persist file with sha1:
5ecc5f719b4442b9b04f9010646d34917aca8ca2
This seems to happen only during builds, but not during other uploads directly by a user.
It doesn't happen all the time, and only on first tries. But I haven't found any logic when the first try fails or succeeds. It doesn't seem to have anything to do with file types or the like. I can't really determine if it has anything to do with network speeds though since I only have access to part of the infrastructure.
I found an open ticket with the same error message, but only for Conan and for us it only happens with ivy repositories
We are using Artifactory 6.9.1 and GitLab 12.0.3 starter
This looks to be a permission issue. You are getting an error message that states that the move failed due to "Access to file denied".
You can try to log in to the server using the "artifactory" user and manually move the file called "path_to_artifactory\filestore_pre\dbRecord123.bin" to "path_to_artifactory\filestore\5e\5ecc5f719b4442b9b04f9010646d34917aca8ca2" and see if you have any issues with this. To log in to the server with the "artifactory" user you can use the command "sudo -s -u artifactory".
You will also need to make sure that all filestore and its subdirectories are owned by the "artifactory" user and have the correct permissions.
Hope this helps.
I am trying to find out how to create a new user in OpenShift enterprise.
According to the documentation (on https://docs.openshift.com/enterprise/3.0/architecture/core_concepts/projects_and_users.html):
Regular users are created automatically in the system upon first login...
This sounds illogical. How does a user login if they dont have a username and password?
Can someone please clarify this - I'm sure there must be some command for creating a new user, but it is not clear.
Thanks
The OpenShift master-config (/etc/openshift/master/master-config.yaml) describes the configuration about authentication. By default the master-config shows something like this for the authentication-part:
identityProviders:
- challenge: true
login: true
name: anypassword
provider:
apiVersion: v1
kind: AllowAllPasswordIdentityProvider
This means that every user with every password can authenticate. By performing oc get users as system:admin you'll see all the users.
This configuration is not recommended. You're able to configure another form of authentication (htpasswd, ldap, github, ...).
I'm using htpasswd. So than you have to create a file (with htpasswd) which will contain your username + encrypted password. After that you'll need to edit your master-config.yaml. You have to tell it to use HTPasswdPasswordIdentityProvider and link to your file.
You can find those steps here. Don't forget to restart your OpenShift master after performing those steps: sudo service openshift-master restart (origin-master for origin).
After creating users you can assign roles to users
Log in with the default admin (system:admin) and assign roles.
I am creating a script for simply adding a user if OpenShift using HTPasswdPasswordIdentityProvider
wget https://github.com/stedolan/jq/releases/download/jq-1.5/jq-linux64
mv jq-linux64 jq && chmod 755 jq
FILE=$(cat /etc/origin/master/master-config.yaml | python -c 'import sys, yaml, json; y=yaml.load(sys.stdin.read()); print json.dumps(y,indent=4, sort_keys=True)' | ./jq '.oauthConfig.identityProviders[0].provider.file')
FILE=$(sed -e 's/^"//' -e 's/"$//' <<<"$FILE")
htpasswd $FILE user1
I'm about to deploy my first Play app, (very excited). I read on playframework.org about the framework id and I want to rejigger my config to take advantage of it. I'm currently on dev but I want to deploy to stage. I want to edit my config to differentiate between dev and stage settings.
My problem, when I type play id I get the following error, "[Errno 13] Permission denied: '/opt/play-1.2.3/id'"
I'm new to Linux BTW.
So I thought, hmmm, maybe I need to sudo? So I use "sudo su -" and try again, but now I get the error, "command not found".
The issue was that play-1.2.3 was not in my path for my sudo account. Once sudo(ed) in, I ran export PATH=$PATH:/opt/play-1.2.3 and then I was able to run the play id command. I AM SO SMART SMRT, learning Linux all on my own baby!