I am trying to rebuild the metadata for a particular artifact in Nexus. I want to use the REST API:
DELETE /service/local/metadata/repositories/myRepository/content
So far it is working well. However, I need the Nexus Administrator Role for the command to work. Since I am building in a large environment with lots of users using Ant (which is automated by Jenkins) I would love to use another user, possibly just dedicated to refreshing the metadata, with only the required privileges (but it seems like that privilege is admin). I don't want my build.xml to have admin credentials!
I am thinking of some workarounds such as calling a separate Jenkins job with hidden credentials, or add a post-build step in the build job... It all just sounds too ugly.
Any thoughts or suggestions?
Thanks
Phil
They need the "Rebuild Maven Metadata" privilege.
You can use Mask+Passwords+Plugin to hide the passwords in the job, and pass it as a parameter to your ant script.
Related
I am willing to create a private maven repository, where the access rules are not based on groups/patterns, but on completely custom rules. I've checked both nexus and jfrog, both of them keeping the simple user/group/pattern approach. And (AFAICS), although they provide custom ways to authenticate, they don't provide a was for custom access rules.
For this reason I have started thinking the opposite: what if I can create a simple repository with my custom rules. But when I searched in the Apache documentation, there was no clear explanation how authentication is performed on the back side.
Does anyone knows how this is done, and maybe point me to the correct documentation?
Authentication is done by HTTP Basic Authentication which basically concats the username and password and base64 encodes that. So Maven and Apache do understand each other.
But out of the box the Apache authorization is based on, you guessed, it. Directories (which represent Maven's artifact groups), username and groups. So unless you are willing to write a custom Apache model you won't gain a lot. Probably IP based access control can be done with Apache alone better than with Nexus/JFrog but I haven't looked at the authentication settings for ages.
In Artifactory what you can do, in order to achieve what you mentioned, is to create permission target per user. Meaning that all of your Maven users will deploy to the same repository BUT each to a different name space. For example, 'com/{company}/{project}/' (please replace the company and project with real values)
This is done on the permission target using the 'Include Pattern' so let's say that my company name is JFrog, and I'm working on a project named 'artifactory' I will have a permission target with the following include pattern '/com/jfrog/artifactory/**/*'.
You can also create those permission targets using a script that will automate it for you using this REST API.
That means that I will only be able to reach this namespace.
Does that help?
When configuring a build job for the first time that uses Subversion for SCM you get an error that looks like this:
I'm aware that to enter my credentials I simply need to use this url.
http://< my-server >/scm/SubversionSCM/enterCredential
But I'm trying to completely automate the set up/configuration of my jenkins server. Is there a way to give jenkins svn credentials without having to access the UI?
My jenkins server is on Windows and is the latest version. Subversion is on linux.
Edit: I've come across a screenshot online similar to the one above except the is a Credentials field! Does anyone know why I can't see this field. Here is the url of the image
http://michal.karzynski.pl/images/illustrations/2014-04-19/jenkins-source-code-management-configuration.png
Thanks
https://wiki.jenkins-ci.org/display/JENKINS/Subversion+Plugin
this can provide credentials to svn repo.
what actually you gonna do? just access the SVN or looking for the SVN SCM change or any other. simply enter password i don't forsee a need of jenkins plugin
The solution is to create some "domain credentials" in the "Manage credentials" section (admin part: http://<server>:8080/credentials/):
One way around this is to use the Subversion command line. Jenkins doesn't need the command line client and you might have to install it.
However, for a particular repository, do a checkout of a project via the command line with the user you want to use. Then, say "Yes" when Subversion asks if you want to cache the credentials.
When Jenkins does a checkout, it will use these cached credentials if you didn't specify a particular Jenkins credential to use. This works per Subversion repository.
We currently use TeamCity to build a deployment artifact, then a further TeamCity task takes that artifact and deploys it to our development and testing servers on demand.
We can store the passwords and other secret data in properties files that we can check into source control, as these are all internal servers and the developers have full access to them.
However for release to Production (and our final test layer) there are secret passwords and configuration that we don't want checked into the normal source control, or to have development be able to discover the passwords. So to do 'real' deployments we have to hand the artifact over to another team and they maintain a properties file with the production values.
What methods exist to store these secrets and allow TeamCity to run a deploy without ever leaking the secrets out?
(note I am one of the devs and it is not a trust issue... I don't want to have the ability to find out prod passwords so I can never accidently know them and do some horrific damage!)
Probably what you need here, is to create a separate project with narrower scope of permissions (for example, allow only certain people to edit build configurations). In this project create a build configuration, responsible for deployment. In this configuration, you can define a Typed Parameter of type 'password' to store the password to the production environment.
Another option is to use Deployer Plugin, especially its ability to deploy over ssh with private key authentication
If you are OK to use a third party solution, consider using a solution like CloudMunch which can help you to perform release management functions with these secure parameters collected at deploy time and encrypted post deployment.
Disclaimer: I work with CloudMunch
You can do 2 things.
Use a teamcity project to deploy artefacts for production only. This will only be accessible to ops members.
Teamcity also supports running agents with different user ids. You can create a new user id which can have access to the production "secrets" (passwords and configuration). Use this id to run the targets in the 1st step.
I'm running the maven release plugin (org.apache.maven.plugins:maven-release-plugin:2.3.2) and noticed that the password to the scm is saved in clear text in the release.properties file when passed in via the command line. I want to know if there is a way to turn this off.
I'm using Hudson to automate the release process, and the svn username and password are passed in to the command line via Hudson. The reason for this is that the person doing the release preparation can change and I have multiple hudson jobs sharing a settings.xml to release different projects.
I'm passing in parameters such as:
-Dtag=${svn.label} -DreleaseVersion=${maven.releaseVersion} -DdevelopmentVersion=${maven.developmentVersion} -Dusername=${svn.username} -Dpassword=${svn.password} -DscmCommentPrefix='[maven-release-plugin] ${env.BUILD_URL} '
The release.properties file gets created during the release:prepare, but I don't think it should be necessary as I'm passing in all the information along the command line. When this release.properties file is created it includes the password in plain text. This is problematic because it's possible to use hudson to browse the workspace, so anyone with access to hudson can see the password by opening the file via the browser.
Is there a way to not create the release.properties file, or to not save the password in the file? I realize that an encrypted password could be saved in a settings.xml file but this file is shared among multiple jobs and is not editable by the people running the jobs.
We avoided such problems letting the svn-client caching the password for us.
For this purpose we have a special account with adequate rights in subversion.
On our build server the password is stored plain text by the svn-client in the account for the user who runs hudson. For us it's no problem because only to hudson administrators have access to this account.
But you can also configure the svn-client to store the password encrypted. The configuration depends on your operating system.
svn-client configuration is stored in .subversion (linux) or "ApplicationData/Subversion" (windows).
See
here, here or here.
Just a couple of days ago somebody asked for this improvement: https://jira.codehaus.org/browse/MRELEASE-846
I configured a hudson instance and have created jobs. While creating builds, I was able to see this option "Trigger the build by accessing this URL + SecretTOKEN" option. Now, I am unable to see that for any new jobs I create. Am I missing some setting or a configuration? The only change I made was running the servlet container from Root to a regular user.
In my Hudson (1.349) when creating a new job, there's an option under Build Triggers called Trigger Builds Remotely (e.g. from scripts), which when selected allows you to enter an Authentication Token (which has the descriptive text from your question).
I'm not aware of any system configuration that disables this. It doesn't sound like a Hudson user permissions problem if you can have permissions to create/edit jobs.
What appears under Build Triggers when you create a new job?
I had the same problem with the missing Trigger Builds Remotely option. The fix in my case was to enable security in the main Hudson configuration (with Anyone can do anything selected)