I have a Jenkins user that I want to give rights to run the remote CLI towards the Jenkins instance. The first command is to fetch the config.xml:
java -jar jenkins-cli.jar -s http://jenkins:8080/hudson get-job thejob
However when he invokes the command, it fails with:
Caught: java.lang.RuntimeException: \
hudson.security.AccessDeniedException2: \
USER is missing the Job/ExtendedRead permission \
at hudson.security.ACL.checkPermission(ACL.java:54)
I have given the rights to execute scripts, read/create/configure jobs and more in our matrix-based security grid. There is another user who has EXACTLY the same permissions in the grid, but for this other user, everything works fine.
I don't have any of the plugins 'Extended Read permission' or 'Read-only configurations' installed.
I cannot see why it fails for this new user. Suggestions anyone?
Differences in the 2 users config.xml file:
<com.cloudbees.plugins.credentials.UserCredentialsProvider_-UserCredentialsProperty plugin="credentials#1.4">
<credentials/>
vs:
<com.cloudbees.plugins.credentials.UserCredentialsProvider_-UserCredentialsProperty plugin="credentials#1.8.3">
<domainCredentialsMap class="hudson.util.CopyOnWriteMap$Hash"/>
And a final one:
<hudson.security.HudsonPrivateSecurityRealm_-Details>
<passwordHash>some values...</passwordHash>
</hudson.security.HudsonPrivateSecurityRealm_-Details>
I don't know if you are facing the same problem I had, but take a look here:
Jenkins CLI: using Anonymous permissions instead of the user defined ones
It looks like you have upgraded the credentials plugin but somehow the first user didn't get its record updated.
If you can I would suggest trying to update to the latest (1.9.1 for me). You could also edit the user record manually and force the real plugin version number in there (then restart Jenkins) and see if it processes this user more accurately.
Related
I have registered a personal GitLab runner several months ago, which I no longer use. How do I completely delete it so that it does not show up on my GitLab CI/CD settings page?
List runners to get their tokens and URLs:
sudo gitlab-runner list
Verify with delete option specifying runner's token and URL:
sudo gitlab-runner verify --delete -t YMsSCHnjGssdmz1JRoxx -u http://git.xxxx.com/
Get your runner token and id
First, go to the GitLab settings page and find the token (e.g. 250cff81 in the image below) and the id (e.g. 354472 in the image below) of the GitLab runner which you wish to delete.
Use the gitlab-runner CLI to unregister the runner
If you have access to the machine which was used to register the GitLab runner, you can unregister the runner using the following command, where you replace {TOKEN} with the token of your GitLab runner (e.g. 250cff81 in the example above).
gitlab-runner unregister --url https://gitlab.org/ --token {TOKEN}
Use the GitLab API to unregister the runner
If you no longer have access to the machine which was used to register the runner, or if the runner is associated with multiple projects, you can use the following Python script. Set RUNNER_ID to the id of your runner (e.g. 354472 in the example above) and GITLAB_AUTH_TOKEN to a GitLab token which you can generate from your profile page.
import os
import requests
GITLAB_AUTH_TOKEN = ...
RUNNER_ID = ...
headers = {"PRIVATE-TOKEN": GITLAB_AUTH_TOKEN}
r = requests.get(f"https://gitlab.com/api/v4/runners/{RUNNER_ID}", headers=headers)
runner_data = r.json()
for project in runner_data.get("projects", []):
r = requests.delete(
f"https://gitlab.com/api/v4/projects/{project['id']}/runners/{RUNNER_ID}",
headers=headers,
)
if not r.ok:
print("Encountered an error deleting runner from project:", r.json())
r = requests.delete(f"https://gitlab.com/api/v4/runners/{RUNNER_ID}", headers=headers)
if not r.ok:
print("Encountered an error deleting runner:", r.json())
Here's one-liner to remove offline runners (for GitLab 14.5):
curl --header "PRIVATE-TOKEN: <private_token>" "https://<your-instance-address>/api/v4/runners/all?scope=offline&per_page=100" | jq '.[].id' | xargs -I runner_id curl --request DELETE --header "PRIVATE-TOKEN: <private_token>" "https://<your-instance-address>/api/v4/runners/runner_id"
You might run this more than once if you have more than 100 offline runners (per_page=100).
If you are talking about the runners listed in "Available group runners: ...", they can be deleted at the runner settings page of your group.
If you no longer have enough information related to a runner, GitLab (UI) will only allow you to disable it.
However, there is a workaround to delete runners via the GitLab UI (if you lost your info).
Create a new blank project within GitLab (called dummy, for instance)
Go to the CI/CD settings page (Settings -> CI/CD -> Runners)
Enable all runners you want to delete to be able to edit them
Lock every runner you wish to delete to the dummy project as shown below
Delete the dummy project
The runners are gone.
The overall idea was to lock all of the orphan runners to a dummy project, then delete that dummy.
PS: If runners are not visible in the dummy project, you may want to unlock them from the project they are associated with, then do the procedure again.
EDIT: This process is most particularly useful when
You do not have access to the machine host (especially in big organisations where rights are segmented), only to your GitLab instance.
You think that creating a runner via the UI should also give you the ability to delete a runner via the UI
You have enough rights but you don't want to fire up a Ruby instance (like described in the GitLab doc) to delete a runner.
With GitLab 15.5 (October 2022), you can also use the Web UI:
Bulk delete runners in the Admin Area
Bulk editing is a powerful and valuable feature when you need to visualize or manage large data sets. For administrators that manage a fleet of runners, the lack of a bulk delete option is a productivity drain and increases the operational overhead of maintaining runners.
Now, in the Admin Area, you can select multiple runners and delete them at the same time. You can also select and delete a full page of runners at once.
See Documentation and Issue.
You must make sure that you copy the value of thetoken=... entry from the config.toml file, or from the settings page.
Do not use the registration_token . The registration_token is different from the token.
In my case I had just created a runner, immediately realized that I had misconfigured the runner (or chosen the wrong executor), and wanted to delete it after first use:
This happened because I still had the gitlab CI/CD Settings webpage with the "Specific Runners // Shareed" Runners Section open and in focus.
I tried
# bad -long registration token
gitlab-runner unregister --url https://git.mycompany.de/ \
--token GR1348941LXUymFTPN5sdKFu1F5mQ`
#ERROR: Unregistering runner from GitLab forbidden runner=GR1348941LXUymFTP
#FATAL: Failed to unregister runner
# GOOD -shorter token from config.yml
gitlab-runner unregister --url https://git.mycompany.de/ \
--token N8Gsyebw_mpYnUBMKB25`
# Unregistering runner from GitLab succeeded runner=N8Gsyebw
If you've deleted the specific runner in your gitlab server, try to remove the unused runner through config.toml file (locally).
To show all runners:
$ gitlab-runner list
Or
$cat /Users/yourUser/.gitlab-runner/config.toml
If you try to delete a runner with this command:
$ gitlab-runner verify --delete -t Token-From-Your-Runner -u https://gitlab.com/
-> You'll have an error (Verifying runner... error) 'cause the process doesn't not match with your remote runner...
Then (To solve this trouble)
Delete all runners by the name with their indentation!
If you only have one, the file shows as:
concurrent = 1
check_interval = 0
[session_server]
session_timeout = 1800
[[runners]]
I am using Hadoop 3.2.0 and trying to run a simple application in a docker container and I have made the required configuration changes both in yarn-site.xml and container-executor.cfg to choose LinuxContainerExecutor and docker runtime.
I use the example of distributed shell in one of the hortonworks blog. https://hortonworks.com/blog/trying-containerized-applications-apache-hadoop-yarn-3-1/
The problem I face here is when the application is submitted to YARN it fails with a reason related to directory creation issue with the below error
2019-02-14 20:51:16,450 INFO distributedshell.Client: Got application
report from ASM for, appId=2, clientToAMToken=null,
appDiagnostics=Application application_1550156488785_0002 failed 2
times due to AM Container for appattempt_1550156488785_0002_000002
exited with exitCode: -1000 Failing this attempt.Diagnostics:
[2019-02-14 20:51:16.282]Application application_1550156488785_0002
initialization failed (exitCode=20) with output: main : command
provided 0 main : user is myuser main : requested yarn user is
myuser Failed to create directory
/data/yarn/local/nmPrivate/container_1550156488785_0002_02_000001.tokens/usercache/myuser
- Not a directory
I have configured yarn.nodemanager.local-dirs in yarn-site.xml and I can see the same reflected in YARN web ui localhost:8088/conf
<property>
<name>yarn.nodemanager.local-dirs</name>
<value>/data/yarn/local</value>
<final>false</final>
<source>yarn-site.xml</source>
</property>
I do not understand why is it trying to create usercache dir inside the nmPrivate directory.
Note : I have verified the permissions for myuser to the directories and also have tried clearing the directories manually as suggested in a related post. But no fruit. I do not see any additional information about container launch failure in any other logs.
How do I debug why the usercache dir is not resolved properly??
Really appreciate any help on this.
Realized that this is all because of the users the services were started with and the permissions to the directories the services work on.
After making sure the required changes are done, I am able to seamlessly run the examples and other applications..
Thanks Hadoop user community for the direction. Adding the link here for more details.
http://mail-archives.apache.org/mod_mbox/hadoop-user/201902.mbox/browser
Is it possible to delete old builds in Gitlab CI?
I tested a few things and have now about 20 builds that are useless (most are failed anyway).
It also shows stages that I don't have anymore which kinda clutters the Pipelines page and some of the uploaded artifacts are a bit big.
I wasn't able to find any documentation on this, only that disabling CI in the settings doesn't remove the builds.
Using Gitlab 8.10 Community (hosted by Gitlab.com)
There is currently no option in the GUI to completely get rid of a build other than expunge related data from the build. (The erase option in the build)
If you would have a local installation you could modify the database directly but I would advise caution. (I'll put the guide here for completeness sake)
Login to the GitLab database. If you use the default PostgreSQL :
sudo -u gitlab-psql /opt/gitlab/embedded/bin/psql -h /var/opt/gitlab/postgresql -d gitlabhq_production
Check if there is a table ci_builds. For pSQL: \dt
Delete the builds with normal SQL. For example: DELETE FROM ci_builds WHERE id = 2
(Optional) If you want to cleanup a list of commits which triggered a build you need to midify the table ci_commits.
Trying to set up Jenkins on one of my servers for the first time and think I might be missing something.
Jenkins 1.545
Phing 2.6.1
Jenkins builds give me the following output.
Building in workspace /var/www/vhosts/domain.co.uk/httpdocs
looking for '/var/www/vhosts/domain.co.uk/httpdocs/build.xml' ...
looking for '/var/www/vhosts/domain.co.uk/httpdocs/build.xml' ...
looking for 'build.xml' ...
buildfile 'build.xml' not found.
Build step 'Invoke Phing targets' marked build as failure
Finished: FAILURE
If I run my build.xml on it's own it works fine.
I'm using a custom workspace at the moment, before I tried a symlink from the default workspace to my webroot, when I did that it found the build file but failed when trying to run phing. I know it's a problem with permissions but I'm not sure exactly what.
I'm running this on a plesk web server and have tried adding the jenkins user to the psacln and psaserv groups but that didn't work either.
I use hudson but I think is the same problem.
Provide to ant job the full path (advanced settings)
${WORKSPACE}/buil.xml
Assuming the correct set of jenkins user
RUN_AS_USER=jenkins
Go to the custom workspace and
chown -R jenkins:jenkins myworkspace
if it doesn't work
chmod -R 777 myworkspace
then you will fix later.
I hope it helps.
I've installed Trac .10.5, configured the trac.htpasswd file, and am able to log in and view/create tickets.
The problem is that I am currently unable to administer ticket components such as the versions that appear in the drop list on New Ticket.
From command line, I issued the following command:
trac-admin /foo/bar/trac/ permission add myusername TRAC_ADMIN
User "myusername" is listed in /foo/bar/trac/conf/trac.htpasswd, and I am able to successfully log in with that account.
Is there another step I'm missing in order to get access to a system configuration area? (for instance, setting up version numbers)
EDIT:
I discovered that version .10.* and below do not have web admin capabilities installed by default. http://trac.edgewall.org/wiki/WebAdmin
I downloaded the plugin source:
svn export http://svn.edgewall.com/repos/trac/plugins/0.10/webadmin/
Then ran setup.py, which generated a dist/TracWebAdmin-0.1.2dev-py2.6.egg file.
I then issued
easy_install TracWebAdmin-0.1.2dev-py2.6.egg.
Here's the output:
Processing TracWebAdmin-0.1.2dev-py2.6.egg
removing '/usr/lib/python2.6/site-packages/TracWebAdmin-0.1.2dev-py2.6.egg' (and everything under it)
creating /usr/lib/python2.6/site-packages/TracWebAdmin-0.1.2dev-py2.6.egg
Extracting TracWebAdmin-0.1.2dev-py2.6.egg to /usr/lib/python2.6/site-packages
TracWebAdmin 0.1.2dev is already the active version in easy-install.pth
Installed /usr/lib/python2.6/site-packages/TracWebAdmin-0.1.2dev-py2.6.egg
Processing dependencies for TracWebAdmin==0.1.2dev
Finished processing dependencies for TracWebAdmin==0.1.2dev
My trac/conf/trac.ini file has this section:
[components]
webadmin.* = enabled
I restarted the httpd server (trac uses Apache), and still have no Admin button.
Help greatly appreciated.
You're a bit too hastily seeking advice. Quoting my recent replies to trac-users mailing-list here:
This is most probably a permission issue and will continue with any more
recent Trac environment. Do something like
trac-admin permission add TRAC_ADMIN
to grant full permission to an admin user account, that is usable for
administration tasks. As known elsewhere, you should create a less
privileged account for your regular work to just use Trac.
But please note: Because you've got Python2.6, go for Trac-1.0, don't dare to use anything before this current stable version for a new project, really. Trac-0.10 has been abandoned long ago and 0.11 is unchanged since 2010 too.
You'll have no luck on almost any issue you may encounter, and you miss
a truck-load of great features that have been introduced. Trac 0.11 had
major API changes in many respects, 0.12 went for full i18n support, if
you care for that, and 1.0 is just on the edge, supporting the new db
access API as well as retaining compatibility code for not-yet-updated
plugins (quite a lot to be honest).
I had a similar issue with 0.11.x (minus the plug-in installation), and it turned out that the user account I was logging into via the shell was not the user account that owned the installation. This meant that the changes I was making did not have the right permissions - it is a requirement that all trac-admin changes are made by the installation owner.
Let's say the user that installed Trac was "jim", and I'd logged in as "bob" to use trac-admin in interactive mode. Reapplying a pre-existing permission to a will cause Python to throw an error and kick you off trac-admin. You have to remove the permission first, then reapply it as the other shell user.
The solution was to:
log back in as "bob" via the shell (e.g. "ssh -l bob trac.url.com")
trac-admin path/to/my/project
permission remove TRAC_ADMIN
exit (trac-admin)
exit (ssh)
log in as "jim" via the shell (e.g. "ssh -l jim trac.url.com")
trac-admin path/to/my/project
permission add TRAC_ADMIN
exit (trac-admin)
exit (ssh)
Now when you log into Trac as via a web browser, hopefully you should see the Admin button top right.